# Plateforme ATS workday

232 employeurs connectés via cette plateforme — 7452 offres actives. Module partagé : jobka/connectors/workday.py ; un employeur = une sous-classe d'environ 10 lignes.

# Description & mécanique

Plateforme Workday.

L'API publique des sites carrières Workday est stable et non authentifiée :

• liste : POST https://..myworkdayjobs.com/wday/cxs///jobs body {"appliedFacets":{},"limit":20,"offset":N,"searchText":""} -> {total, jobPostings:[{title, externalPath, locationsText, postedOn, bulletFields:[req_id]}]}
• détail : GET .../wday/cxs// -> {jobPostingInfo:{jobDescription(HTML), location, timeType, jobReqId, startDate, …}}

Les sites listent souvent des postes hors Québec : on filtre côté client par is_quebec_location, puis on ne visite la page détail QUE pour les postes québécois (avec cache BD — le détail n'est re-téléchargé que si la ligne de liste change).

# Accès

• Pagination : offset/limit
• Backend : GET/POST direct requests (throttlé, User-Agent JobKaBot/1.0 identifié)
• Auth : aucune — API/pages publiques du site carrières.
• Throttle : 0.7 s entre requêtes.
• Budgets (env) : JOBKA_WORKDAY_DETAIL_LIMIT (défaut 300)

# Tenants connectés

# Licence / conformité

Flux public du site carrières officiel de l'employeur (API JSON de l'ATS ou HTML rendu serveur) — le même contenu que la page carrière affiche publiquement, prévu pour la diffusion des offres, sans authentification. Chaque offre conserve son URL originale et le bouton « Postuler chez l'employeur » renvoie chez l'employeur. Aucune donnée personnelle de candidat n'est collectée. User-Agent identifié JobKaBot/1.0 (+https://www.job-ka.com; contact@spboucher.ai) sur les accès directs ; requêtes throttlées et plafonnées par budgets.

# Historique

Mission connecteurs du 2026-08-18 — passage de 135 à 217 employeurs directs connectés, de 9 à 17 plateformes ATS, ajout de 3 portails agrégateurs et du canal de dépôt direct :

• fd4bfc8 qualité lieux : rejet des villes hors Québec, bâtiments McGill → Montréal ;
• 5a66f48 +59 employeurs (sondage massif d'ATS + détection de pages carrières) ;
• 4917d57 8 nouveaux ATS (Taleo, Njoyn, UltiPro, iCIMS, SuccessFactors, ADP WFN, Digital Recruiters, Workland) + 23 employeurs publics/parapublics ;
• f6e7571 portails Guichet-Emplois, Jobillico, Espresso-Jobs — l'offre directe gagne toujours la canonique (dédup) ;
• 744cbfc badge « Offre directe », stats directes/portails, dépôt direct employeurs ;
• 1604ff9 reprise sur coupure WAF Guichet-Emplois (retry + acquis partiel).

Commits touchant jobka/connectors/workday.py :

• 1119e5e9 2026-10-10 [ka6] snapshot pré-mission reddyice
• c095c660 2026-09-28 [ka6] fix connecteur rbc: angle mort réel « poste multi-lieux » derrière un stale volume-QC-nul (1re intervention) — contrairement aux 19 faux positifs précédents, il y avait une VRAIE offre QC manquée. Contexte : site early talent Workday rbc.wd3/RBCEARLYTALENT1 (stages/co-op, médiane QC 0.5), l'unique offre QC en base (« 2027 Capital Markets, Global Markets Program Summer Analyst » R-0000180191, Montréal) dépubliée par RBC dans la nuit → found=0 ×2, sync_log VERT en continu (ok=1, 233+ syncs). Re-vérification live du board : 200 JSON, 46 postes (Toronto/USA/Malaisie), searchText=Quebec → 1 poste VIVANT : « 2027 Winter Change Management Intern (4 months) » R-0000186549, lieu principal MONTRÉAL Quebec + secondaire Toronto, publié 2026-09-10 — mais sa ligne de liste affiche locationsText=« 2 Locations » sans nommer les villes, que le filtre client is_quebec_location rejetait ; et ce tenant n'expose AUCUNE facette de province (State_Province sans Quebec ni Ontario) donc pas de filtre serveur possible. FIX dans workday.py (_keep) : repli sur le slug de lieu de l'externalPath (…/job/MONTRAL-Quebec-Canada/…, porte le lieu PRINCIPAL) quand le libellé est vide ou « N Locations » — zéro requête additionnelle, ne touche que les tenants filtrés client ; limite assumée documentée : un poste dont seul un lieu SECONDAIRE est QC reste manqué. La page détail remplace déjà « 2 Locations » par le vrai lieu (mécanique existante) → l'offre entre en base avec city=Montréal. Au passage, artefacts vague C corrigés (pattern ci/geox) : EMPLOYER 'Rbc' → 'RBC' (rbc.py, docstring re-vérif 2026-09-28 + chronologie), name 'Rbc' → 'RBC' et url vide → https://www.rbc.com (vérifié 200) dans sources.json — éditions ciblées, format préservé. Sync isolé rejoué : found=1 (added=1 puis stable ×2), ok=1, ~14 s ; non-régression Workday : cibc found=69 ≈ médiane 73. Fiches docs/connecteurs/ rbc.md + ats-workday.md + INDEX.md régénérées via scripts/gen_connector_docs.py (les 1130 autres fiches, dont seuls les instantanés horodatés changeaient, restaurées — hors périmètre). 106 tests pytest verts. pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
• 4e9be243 2026-09-12 [ka6] fix connecteur altusgroup: external_id régional → ID de réquisition (hook _external_id dans la plateforme workday, défaut inchangé) — le tenant altusgroup.wd3 préfixe bulletFields par la région quand il y en a une (['Ontario','R0013639'] vs ['R0013942'] seul), si bien que bullets[0] devenait l'external_id : l'offre QC historique était en base sous external_id='Quebec', et le sync du 2026-08-26 trouvait 2 offres pour 1 seule stockée (collision d'ID entre postes d'une même région). L'extraction est désormais isolée dans un hook _external_id() de WorkdayConnector (comportement par défaut strictement identique pour les autres tenants) et surchargée dans altusgroup.py : premier bullet au format réquisition R+chiffres, sinon suffixe du chemin. Vérifié live : 36 postes scannés → 36 IDs uniques au format R00xxxxx, 0 poste non conforme. Volume 0 légitime AUJOURD'HUI : 7 postes Canada, tous Toronto — aucune offre QC depuis la dépublication de l'offre montréalaise le 2026-08-26 (médiane historique 0.0). Le statut stale vient de là (la supervision date le dernier succès au dernier sync found>0, 2026-08-26 14:19) ; l'unique échec récent (2026-09-12 03:04, « Workday non-JSON HTTP 200 text/html ») est la fenêtre de maintenance hebdomadaire Workday du vendredi/samedi nuit (28 occurrences multi-sources cette nuit, mêmes plages 02h30–03h15 les 2026-08-29 et 2026-09-05), transitoire et déjà retryée. Sync isolé rejoué : found=0 en 2,4 s, statut ok. 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
• f6c59780 2026-09-10 [ka6] fix connecteur dxctechnology: repli scan client quand le filtre serveur QC est factice dans la plateforme workday — le tenant dxctechnology (dxctechnology.wd1, site DXCJobs) expose une facette « locations » (Region, State or Province) qui liste « CAN - QC - MONTREAL » count=3 mais dont le filtre serveur renvoie total=0 pour N'IMPORTE QUELLE valeur (vérifié aussi avec DUBAI count=2 → 0) : facette d'affichage seulement. Le repli serveur ajouté ce matin pour jj (ec1b90d, déployé 04h18) sélectionnait cette facette factice → pagination filtrée vide → found=0 au sync de 04h45 (missed=3), statut stale, alors que les 3 offres Montréal existent toujours sur l'API. _list_pages détecte désormais le cas : si la première page filtrée serveur est vide alors que le listing non filtré annonçait des postes (total > 0), le filtre serveur est abandonné (une seule fois) et le scan client complet reprend (938 postes < plafond 60×20, is_quebec_location côté client). Sync rejoué : found=3 (médiane 3.0), les 3 offres réactivées miss_count=0. Non-régression : jj garde son repli serveur (found=1 en 1,9 s), desjardins sa facette province (found=270). pm2 restart job-ka-sync OK, site 200.
• ec1b90d3 2026-09-10 [ka6] fix connecteur jj: filtre serveur de repli par lieux ville dans la plateforme workday — le tenant jj (Johnson & Johnson, jj.wd5) n'expose AUCUNE facette province « Quebec », seulement une facette locations plate au niveau ville (« Montréal, Quebec, Canada ») ; sans filtre serveur, le scan client plafonné à max_pages=60 (1200 postes) ratait l'unique offre QC dès que le tenant a dépassé le plafond (1692 postes le 2026-09-10) → found=0, statut stale. _find_qc_facet agrège désormais, en repli seulement, toutes les valeurs de lieu québécoises (mêmes règles que is_quebec_location) en un filtre serveur unique. Sync rejoué : found=1 en 2,8 s (vs 0 en 72,5 s), offre R-089236 Montréal réactivée (miss_count=0) ; les 2 retraits (R-093383, R-081608) vérifiés réellement dépubliés sur l'API. Non-régression : desjardins garde sa facette province Region et rapporte 270 offres. pm2 restart job-ka-sync OK, site 200.
• b5b4be3a 2026-09-07 [ka6] fix connecteur firststudent: retry avec backoff sur 5xx transitoire dans la plateforme workday — un 500 isolé de l'API CXS (constaté 2026-09-07 18h18 sur firststudent.wd1, reparti seul) faisait échouer tout le sync car raise_for_status dans base.get/post court-circuitait le retry de _req_json (qui ne couvrait que le cas 200 non-JSON); les 4xx restent des échecs immédiats; sync rejoué: 35 offres (médiane 35.0)
• c4d9bfc3 2026-09-04 [ka6] snapshot pré-mission derumarketcatering
• 86fc7812 2026-09-04 Revert "[ka6] connecteur shrinerschildrens: maintenance tenant Workday (401 'system account', 2026-09-04 ~02h EDT, portail redirigé vers community.workday.com/maintenance-page) — retry+backoff du 401 de maintenance dans _req_json de la plateforme workday et erreur explicite dans sync_log; autres tenants wd12 non touchés (cabotcorp 4 offres vérifié)"
• 540cb825 2026-09-04 [ka6] connecteur shrinerschildrens: maintenance tenant Workday (401 'system account', 2026-09-04 ~02h EDT, portail redirigé vers community.workday.com/maintenance-page) — retry+backoff du 401 de maintenance dans _req_json de la plateforme workday et erreur explicite dans sync_log; autres tenants wd12 non touchés (cabotcorp 4 offres vérifié)
• 7217386f 2026-08-31 [ka6] fix connecteur gsknch: reprise sur réponses Workday 200 non-JSON (fenêtres de maintenance nocturnes ~03h) — retry+backoff _req_json dans la plateforme workday, erreur diagnosticable, 11 offres retrouvées