SPB Git
spboucher.ai

spb/job-ka

Public
page 1

  1. Thu, Sep 17, 2026 1

    1. [ka6] fix connecteur psacunion: faux positif de supervision (dépublication de l'unique offre QC) — aucun défaut du connecteur, correction de deux artefacts de génération (url vide + titre de poste utilisé comme nom d'employeur) — le statut stale vient du retrait NORMAL des offres QC du tenant Workday psacunion.wd10/psac : après « Regional Representative, Gatineau » (JR100166) et « Regional Representative, Montreal » (JR100182), la dernière offre QC « Grievance & Adjudication Officer, Montreal » (JR100033, Montréal) a disparu du board au sync de 23:50 (16/09) → found=0, miss_count 1 puis 2 → active=0. Le connecteur est INTACT et vérifié live : l'API cxs répond (200, total=8 offres sur le board — 7 à Ottawa ON, 1 à Yellowknife NT, AUCUNE au Québec), searchText=Montreal retourne total=0, et le détail cxs de JR100033 renvoie 403 (réponse Workday d'une offre dépubliée). Tous les syncs sont ok=1 dans sync_log — même profil que gilead 0760e1f, samsara 1a3fe57, delos_data 5cf2a52, solmentalhealth fe2debf, autotradercanada e3bb827, hera 4990c80 et ogilvycanada c7adc0c : tenant à faible volume QC dont la dépublication fait tomber le volume à 0, compté comme non-succès par la supervision (médiane 1.0). Correction au passage de DEUX artefacts du générateur vague C : url vide dans data/sources.json → https://syndicatafpc.ca (site officiel FR de l'AFPC, vérifié 200 ; la fiche affichait « Site : []() »), et name/EMPLOYER = « Regional Representative, Gatineau » (un TITRE DE POSTE pris pour le nom de l'employeur) → « Alliance de la Fonction publique du Canada » dans sources.json et psacunion.py, plus UPDATE du champ employer des 3 offres psacunion en base (elles ne reviendront pas via l'upsert puisque dépubliées). Sync isolé rejoué : found=0 en 0,3 s, removed=1 (JR100033 à miss_count=2 → retrait normal), ok — 0 est le volume légitime tant que le tenant n'a pas de poste QC ; les offres reviendront d'elles-mêmes si republiées. 106 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 2 files +5 −5

  2. Wed, Sep 16, 2026 3

    1. [ka6] fix connecteur gilead: faux positif de supervision (dépublication de l'unique offre QC) — aucun défaut du connecteur, correction de deux artefacts de génération (url vide + titre de poste utilisé comme nom d'employeur) — le statut stale vient du retrait NORMAL de l'unique offre QC du tenant Workday gilead.wd1/gileadcareers (« Medical Scientist HIV, Quebec », R0052893, Québec) : found=1 stable depuis des semaines jusqu'au sync de 09:04 (16/09), puis found=0 à 11:24 et 13:37, offre à miss_count=2 → active=0. Le connecteur est INTACT et vérifié live : l'API cxs répond (200, total=485 offres sur le board), la facette « locations » Canada ne liste plus que Edmonton (7), Ontario (1) et Mississauga (3) — plus aucun poste au Québec —, la recherche searchText=Quebec retourne total=0, et le détail cxs de R0052893 renvoie 403 S22 « permission denied » (réponse Workday d'une offre dépubliée ; la page publique 200 n'est que le shell SPA). Tous les syncs sont ok=1 dans sync_log — même profil que samsara 1a3fe57, delos_data 5cf2a52, solmentalhealth fe2debf, autotradercanada e3bb827, hera 4990c80 et ogilvycanada c7adc0c : tenant à offre QC unique dont la dépublication fait tomber le volume à 0, compté comme non-succès par la supervision (médiane 0.5). Correction au passage de DEUX artefacts du générateur vague C : url vide dans data/sources.json → https://www.gilead.com (vérifié 200 ; la fiche affichait « Site : []() »), et name/EMPLOYER = « Medical Scientist HIV, Quebec » (un TITRE DE POSTE pris pour le nom de l'employeur) → « Gilead Sciences » dans sources.json et gilead.py — l'offre inactive en base sera renommée d'elle-même à toute republication (l'UPDATE de l'upsert rafraîchit employer). Sync isolé rejoué : found=0 en 40,5 s (scan client du board, pas de facette QC serveur), ok — 0 est le volume légitime tant que le tenant n'a pas de poste QC ; l'offre reviendra d'elle-même si republiée. 106 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +5 −5
    2. [ka6] fix connecteur talan: relance des 5xx passagers dans le GET résilient — le statut stale vient d'un 502 Bad Gateway unique de api.smartrecruiters.com (page 2, offset=100) au sync de 03:13 le 2026-09-16, qui avortait tout le sync : contrairement au POST (relances 5xx ajoutées après l'incident jci/Workday du 2026-08-27), le GET résilient de base.py ne retentait pas les 5xx transitoires hors statuts anti-bot (502 absent de BLOCK_STATUS → pas d'escalade, pas de relance, raise immédiat). L'API est saine (vérifié live : 200 sur offset=0 et 100, totalFound=466, filtre QC → ~20) — hoquet serveur ponctuel. Correctif générique dans _ka_resilient_get : 3 tentatives directes avec backoff sur 5xx non-bloquant (même logique que _ka_resilient_post), escalade proxy inchangée pour 403/429/503/52x, 4xx remontés sans relance. Test unitaire ajouté (502×2 puis 200 → survit en 3 appels ; 502 persistant → 3 tentatives puis HTTPError ; 404 → aucune relance). Sync réel rejoué : found=20 (médiane exacte), ok. 106 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +77 −16
    3. [ka6] fix connecteur eq3_ltd: retrait immédiat des offres CONFIRMÉES fermées — dans la nuit du 15 au 16/09, EQ3 a réellement fermé ses 12 postes (« Position Closed » vérifié live sur chacune des 12 pages /p/, plus aucun formulaire APPLY), étape suivante du délisting du board traité en 6012d1c ; le repli « board délisté » a fonctionné exactement comme conçu (re-vérification des 12 offres, rejet des pages fermées → found=0, volume désormais légitime), mais la garde anti-dérive du moteur (found=0 vs médiane 12 → retraits suspendus) maintenait les 12 offres fermées EN LIGNE sur le site (active=1, miss_count=0) pendant que la fenêtre de médiane (DRIFT_HISTORY=5) se vidait — correct pour un connecteur cassé, injustifié quand la fermeture est PROUVÉE page par page. Correctif tenant-spécifique dans eq3_ltd.py seul (db.py intact) : le repli collecte les uid des offres dont la page /p/ affiche « Position Closed » et les désactive directement (_deactivate_closed, UPDATE active=0), fermeture vérifiée à la source — les offres injoignables ou hors QC continuent de suivre le chemin normal miss_count. Vérifié live : la page carrières officielle eq3.com pointe toujours vers eq3-ltd.breezy.hr (pas de migration d'ATS), /json toujours [], validThrough des 12 offres tous dans le passé. Test unitaire adapté (offre « Position Closed » → retrait direct capturé, vivante conservée, hors-QC simplement lâchée). Sync réel rejoué : 12 offre(s) confirmée(s) fermée(s) — retirées, 0 offre active restante en base, found=0 légitime (le tenant n'a plus aucun poste ouvert ; dès republication le chemin normal /json reprend seul). 105 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 2 files +52 −10

  3. Tue, Sep 15, 2026 3

    1. [ka6] fix connecteur ogilvycanada: faux positif de supervision (dépublication de l'unique offre QC) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient du retrait NORMAL de l'unique offre QC du board greenhouse ogilvycanada (« Superviseur(e) De Comptes », id 4699352005, Montréal) : found=1 stable depuis des semaines jusqu'au sync de 15:17 (15/09), puis found=0 à 17:33 et 19:47, offre à miss_count=2 → active=0 (removed=1). Le connecteur est INTACT et vérifié live : l'API Greenhouse répond (200, 1 offre restante « Account Executive » à Toronto, Canada, correctement exclue par is_quebec_location — vérifié → False), l'offre retirée renvoie 404 sur l'API détail et sa page publique redirige vers le board avec ?error=true. Tous les syncs sont ok=1 dans sync_log — même profil que samsara 1a3fe57, delos_data 5cf2a52, solmentalhealth fe2debf, autotradercanada e3bb827 et hera 4990c80 : tenant à offre QC unique dont la dépublication fait tomber le volume à 0, compté comme non-succès par la supervision (médiane 0.5). Correction au passage du même artefact de génération : url vide dans data/sources.json → https://www.ogilvy.com/ca (vérifié 200 ; la fiche affichait « Site : []() »). Sync isolé rejoué : found=0 en 0,1 s, ok — 0 est le volume légitime tant que le tenant n'a pas de poste QC ; l'offre reviendra d'elle-même si republiée. 105 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +1 −1
    2. [ka6] fix connecteur eq3_ltd: repli « board délisté » — /json vide alors que les 12 offres restent EN LIGNE (re-vérification live des pages /p/) — le 2026-09-15 vers 12:07, le board Breezy eq3-ltd a cessé de lister ses postes (/json et /json?verbose=true = [] — vérifié direct, UA navigateur ET proxy résidentiel CA —, sitemap.xml sans aucune offre, HTML %LABEL_NO_POSITIONS%) alors que les 12 offres QC connues sont toutes encore en ligne et ouvertes aux candidatures (pages /p/ 200 avec JSON-LD JobPosting complet et bouton APPLY, aucune « Position Closed ») et que la page carrières officielle eq3.com/ca/en/aboutus/careers pointe toujours vers ce même board : delisting du portail côté tenant, PAS une dépublication (contrairement aux précédents hera 4990c80/autotradercanada e3bb827 où les offres retirées affichaient « Position Closed »/404). L'API Breezy est saine globalement (bellatrx 14, brandmomentum 34, recruiting 78…) ; aucun slug alternatif (eq3.breezy.hr existe mais vide) ni endpoint de rechange (embed/feed/rss → 302). Correctif tenant-spécifique dans eq3_ltd.py (breezy.py intact) : quand la liste est vide, re-vérification live de chaque offre active connue via sa page /p/ — JSON-LD JobPosting exigé, rejet des pages « Position Closed »/« no longer accepting » et hors Québec, champs frais depuis le JSON-LD (titre, description, ville, date), libellé salarial conservé du dernier état liste (8/12 avec salaire, préservés). Données réelles constatées à la source, jamais inventées ; limite assumée : pas de découverte de NOUVELLES offres tant que le board est délisté — dès que /json redevient non vide, le chemin normal reprend seul et les offres réellement fermées suivront miss_count → retrait. Correction au passage du même artefact sources.json que samsara/delos_data/solmentalhealth/hera : url vide → https://www.eq3.com. Test unitaire ajouté (offre vivante QC conservée avec salaire, « Position Closed » et hors-QC lâchées, repli jamais sollicité sur liste non vide, 0 requête si base vide). Syncs réels rejoués : found=12 (médiane exacte) ×2, updated=4 puis 0, aucune alerte, miss_count=0 partout. 105 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 3 files +196 −3
    3. [ka6] fix connecteur hera: faux positif de supervision (dépublication de l'unique offre QC) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient du retrait NORMAL de l'unique offre du board breezy hera (« Développeur·euse Full-Stack », id bb49e40b5fbd, Montréal) : found=1 stable depuis des semaines jusqu'au sync de 22:58 (14/09), puis found=0 à 01:07 et 03:35, offre à miss_count=2 → active=0. Le connecteur est INTACT et vérifié live : l'API Breezy répond (200, tableau JSON vide []), le board HTML affiche %LABEL_NO_POSITIONS% (aucun lien /p/), et la page de l'offre retirée affiche « Position Closed ». Tous les syncs sont ok=1 dans sync_log — même profil que samsara 1a3fe57, delos_data 5cf2a52, solmentalhealth fe2debf et autotradercanada e3bb827 : tenant à offre QC unique dont la dépublication fait tomber le volume à 0, compté comme non-succès par la supervision (médiane 0.5). Correction au passage du même artefact de génération : url vide dans data/sources.json → https://heraai.ca (lien « View the Hera AI website » du board, vérifié 200 ; la fiche affichait « Site : []() »). Sync isolé rejoué : found=0 en 0,1 s, ok — 0 est le volume légitime tant que le tenant n'a pas de poste publié ; l'offre reviendra d'elle-même si republiée. 104 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 1 file +1 −1

  4. Mon, Sep 14, 2026 5

    1. [ka6] fix connecteur autotradercanada: faux positif de supervision (dépublication des 2 offres QC) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut broken vient du retrait NORMAL des 2 seules offres QC du board greenhouse autotradercanada (« Gestionnaire de performance/Performance Manager - Montréal » id 7799193003 et « Performance Manager, Longueuil, QC » id 7820524003) : found=2 stable depuis des semaines jusqu'au sync de 12:40, puis found=0 dès 15:05, offres à miss_count=2 → active=0 à 16:18 (removed=2). Le connecteur est INTACT et vérifié live : l'API Greenhouse répond (200, 24 offres — 23 Toronto ON, 1 Remote Canada), les 2 offres retirées renvoient 404 sur l'API détail, et les libellés restants sont correctement exclus par is_quebec_location (vérifié : « Toronto, ON (Canada) » et « Remote (Canada) » → False). Tous les syncs sont ok=1 dans sync_log — même profil que samsara 1a3fe57, delos_data 5cf2a52 et solmentalhealth fe2debf : tenant à peu d'offres QC dont la dépublication fait tomber le volume à 0, compté comme non-succès par la supervision. Correction au passage du même artefact de génération : url vide dans data/sources.json → https://www.autotrader.ca (la fiche affichait « Site : []() »). Sync isolé rejoué : found=0 en 0,1 s, ok — 0 est le volume légitime tant que le tenant n'a pas de poste QC ; les offres reviendront d'elles-mêmes si republiées. 104 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +1 −1
    2. [ka6] fix connecteur solmentalhealth: faux positif du filtre Québec — « Quebec St. » (nom de rue à Denver) matchait \bquebec\b — le statut stale vient de la dépublication NORMALE de l'unique offre du tenant (Psychiatric Clinician, id 4704220005, 404 live, retirée à 16:08 miss_count=2 → active=0), mais cette offre n'aurait JAMAIS dû être publiée : son lieu réel est « 3401 Quebec St. Suite 8000, Denver, CO, 80207 » (bureau de SOL Mental Health sur Quebec Street à Denver), classé ville=Québec/Capitale-Nationale et géocodé à Québec parce que _QC_MARKERS (\bquebec\b) est évalué avant le rejet _NON_QC_REGION_RE (« , CO ») dans is_quebec_location. La médiane historique 1.0 est donc elle-même un artefact : le bon volume QC de ce tenant est 0 (vérifié live : API Greenhouse 200, 65 offres, toutes aux États-Unis — NY/VA/MD/CO/DC). Correctif : nouveau _QUEBEC_STREET_RE — « quebec » suivi d'un type de voie anglophone (st/street/ave/blvd/rd/dr/ct/ln/way/pl/hwy/pkwy…) = nom de rue, neutralisé avant tout matching dans is_quebec_location ET parse_location ; le garde (?!-) préserve les abréviations de saints des libellés QC légitimes vérifiés en base (« CAN Quebec St-Hubert/St-Laurent/St-Hyacinthe/Ste-Thérèse », agropur). Tests unitaires ajoutés (4 rues US rejetées, libellés agropur et QC classiques conservés). Correction au passage du même artefact sources.json que samsara/delos_data/findevcanada/dupont : url vide → https://www.solmentalhealth.com (la fiche affichait « Site : []() »). Sync isolé rejoué post-patch : found=0 en 0,2 s, ok — 0 est le volume légitime, l'offre Denver ne reviendra plus même si republiée. 104 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 3 files +27 −5
    3. [ka6] fix connecteur delos_data: faux positif de supervision (dépublication de l'unique offre QC) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient du retrait NORMAL de l'unique offre QC du board ashby delos-data (System Software Engineer - AI, id d5e28543, Montréal) : found=0 depuis 12:55, offre à miss_count=2 → active=0 au sync de 15:20 (removed=1). Le connecteur est INTACT et vérifié live : l'API Ashby répond (200, 9 offres monde — Palo Alto, Taiwan, Remote, Charlottesville…), aucune localisée au Québec (le poste montréalais réapparaît à Palo Alto seul, sous un autre id), correctement exclues par is_quebec_location. Tous les syncs sont ok=1 dans sync_log ; la supervision compte found=0 comme non-succès contre une médiane de 1.0 (même profil que samsara 1a3fe57 : tenant à offre QC unique). Correction au passage du même artefact de génération que samsara/findevcanada/dupont/telefilmcanada : url vide dans data/sources.json → https://www.delosdata.com (la fiche affichait « Site : []() »). Sync isolé rejoué : found=0 en 0,1 s, ok — 0 est le volume légitime tant que le tenant n'a pas de poste QC. 104 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +1 −1
    4. [ka6] fix connecteur lassonde: faux positif de supervision (épisode Sucuri transitoire) — repli Bright Data sur la page liste — le statut stale vient d'un unique échec à 08:17 (RuntimeError explicite de la garde du 2026-09-05 : 3× « HTTP 200 via scrapfly, 4515 octets » sans le conteneur job-result-default), combiné à la panne SQLite du matin (2b01fd4) qui avait empêché tout sync entre 05:32 et 08:17 — le connecteur est INTACT : rejeu = found=35, médiane exacte. Vraie faiblesse corrigée : pendant un épisode Sucuri, TOUTE la chaîne principale (direct→oxylabs→scrapfly) sert la même page tronquée « propre en apparence » (200 sans marqueur connu — 'access denied', 'sucuri_cloudproxy' etc. déjà couverts par is_blocked) à chaque essai, et le backoff 10-20 s ne suffit pas à sortir de l'épisode ; escalate() acceptait la réponse Scrapfly et ne tentait jamais Bright Data. La liste étant rendue serveur (render_js ne sert qu'au challenge), _fetch_list tente désormais Bright Data Web Unlocker (vendeur de déblocage différent) à chaque essai raté — vérifié live : BD livre 200/110 ko/35 cartes au moment même où le direct sert le challenge Sucuri 307. L'échec reste explicite (offres conservées) si BD échoue aussi. Test unitaire ajouté (repli BD gagnant, échec explicite si BD muet, BD jamais sollicité sur liste saine). Syncs rejoués post-patch : found=35 ok ×2. 104 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +77 −2
    5. [ka6] fix site down jobka: convoi de verrous SQLite (journal DELETE) — bascule en WAL — le site était muet (ReadTimeout public+local depuis 03:38) alors que pm2 affichait online : la BD data/jobka.db (740 Mo, 64 340 offres) tournait en journal_mode=delete, où lecteurs et écrivains se bloquent mutuellement. Un cycle de sync long (agropur 92 s, airbus suspendu ~03:36) a tenu le verrou d'écriture ; chaque requête web (SSR d'accueil = plusieurs agrégats sur la table jobs) restait coincée dans sqlite3_step jusqu'au busy_timeout de 30 s, les 40 slots du threadpool AnyIO de FastAPI se sont remplis (sample : ~24 threads dans sqlite3_step, /emploi statique répondait mais /, /health et toute route sync-def étaient muets), et job-ka-sync crashait en boucle sur « database is locked » (18 restarts, journal chaud data/jobka.db-journal). Le restart pm2 automatique ne réglait rien : le sync relançait aussitôt son cycle d'écritures et le convoi se reformait. Mesure à froid : COUNT(*) sur 64 k lignes = 60 s sous contention, 0,03 s BD libérée — volumétrie saine (freelist 6 pages), quick_check ok, 0 offre perdue. Correctif racine : PRAGMA journal_mode=WAL (persistant, appliqué à la BD après arrêt propre + sauvegarde data/backup-jobka-20260914.db) + synchronous=NORMAL, inscrits dans db.connect() ; .gitignore couvre désormais data/jobka.db-* (journal/wal/shm). Post-fix : /health ok (24 719 offres actives, sync live), / local 200 en 0,1 s, public 200 en 0,55 s pendant que le cycle de sync écrit — plus aucun « database is locked ». 103 tests pytest verts.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +8 −2

  5. Sun, Sep 13, 2026 3

    1. [ka6] fix connecteur samsara: faux positif de supervision (dépublication de l'unique offre QC) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient de la dépublication NORMALE de l'unique offre QC du board greenhouse samsara (Mid-Market Account Executive - French Fluent, id 7926750, Montréal) entre le sync de 11:58:39 (found=1, dernier « succès » daté par la supervision) et celui de 15:34:51 (found=0 ok). Le connecteur est INTACT et vérifié live : l'API liste Greenhouse répond (200, 244 offres), aucune n'est localisée au Québec (uniquement Remote-US/Canada/Toronto etc., correctement exclues par le filtre — même conclusion que l'intervention du 2026-08-29), et l'API détail de 7926750 renvoie 404. Cette offre unique du tenant fait du yo-yo : déjà dépubliée le 2026-08-29, republiée ensuite (revue stable found=1 jusqu'à ce matin), re-dépubliée aujourd'hui — found=0 est légitime (médiane 1.0 = une seule parution). Aucune erreur dans sync_log (tous les syncs ok). Correction au passage du même artefact de génération que findevcanada d333936, dupont 3d860d5 et telefilmcanada 30c58c2^ : url vide dans data/sources.json → https://www.samsara.com (la fiche affichait « Site : []() »). Sync isolé rejoué : found=0, removed=1 en 0,2 s (l'offre dépubliée atteint miss_count=2 → active=0, retrait normal), statut ok. 103 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 1 file +1 −1
    2. [ka6] fix connecteur alstom: faux positif de supervision (réponse sitemap transitoirement illisible) — garde-fou _fetch_sitemap dans la plateforme successfactors — le statut stale vient d'un unique sync found=0 à 06:14 (contre une médiane stable de 224), alors que le connecteur est INTACT : le sitemap RSS live (24 Mo, 2285 items monde) parse 224 offres QC au rejeu. Vraie faiblesse corrigée : SuccessFactorsConnector.fetch() avalait silencieusement une réponse 200 sans racine <rss>/<urlset> (page de maintenance/anti-bot, corps vide) — pas d'<item> ni de <loc> → [] → faux « 0 trouvé, ok ». Nouveau _fetch_sitemap sur le modèle de njoyn._fetch_listing (7938ca6) : 3 essais avec backoff 10-20 s, retry sur RequestException transitoire et sur réponse sans racine sitemap, échec explicite (RuntimeError, offres conservées) après 3 réponses illisibles ; un sitemap valide mais vide après 3 essais reste accepté (tenant légitimement sans offre, le garde-fou de dérive suspend déjà les retraits). Test unitaire ajouté (retry maintenance+ConnectTimeout, échec explicite après 3 corps vides, tolérance tenant vide). Sync rejoué post-patch : found=224 en 8,9 s, ok. 103 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +100 −2
    3. [ka6] fix connecteur groupe_bellemare: faux positif de supervision (micro-panne réseau vers api.scrapfly.io) — durcissement du retry de _fetch_listing aux erreurs réseau (njoyn.py) — le statut stale vient d'un unique échec à 04:28 (ConnectTimeout 180 s vers l'API Scrapfly elle-même, seul échec de tout le cycle app : 1105 connecteurs ok), alors que tous les syncs précédents étaient stables à found=34 = médiane exacte ; Scrapfly répond en 0,3 s au moment du diagnostic et le sync rejoué donne found=34 en 8,4 s — connecteur INTACT. Vraie faiblesse corrigée : le retry durci du 2026-09-09 (3 essais, ré-amorçage de session) ne couvrait que les réponses vides/anti-bot ; une requests.ConnectTimeout levée par base.scrapfly() traversait la boucle et avortait le sync au premier essai. _fetch_listing attrape désormais requests.RequestException — même traitement qu'une page vide (nouvelle session Scrapfly = nouveau proxy, backoff 10-20 s), ré-élévation après 3 échecs. Test unitaire ajouté (retry après 2 ConnectTimeout simulés + ré-élévation après 3). Sync rejoué post-patch : found=34, ok. 102 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +54 −3

  6. Sat, Sep 12, 2026 4

    1. [ka6] fix connecteur telefilmcanada: faux positif de supervision (dépublication à l'échéance) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient de la dépublication NORMALE de l'unique offre QC du tenant dayforce telefilmcanada (Conseiller.ère impact organisationel - EDIA, id 1318, Montréal) à sa date limite : postingExpiryTimestampUTC=2026-09-12T03:59Z = 2026-09-11 23:59 EDT, pile entre le sync de 23:28:54 (found=1, dernier « succès » daté par la supervision) et celui de 01:41:57 (found=0 ok). Le connecteur est INTACT et vérifié live : l'API Dayforce répond (maxCount=1), le seul poste courant du tenant est « Directeur.trice régional.e Longs métrages — Région de l'Atlantique » à Halifax NS, correctement exclu par le filtre Québec ; found=0 est légitime aujourd'hui (employeur fédéral ~200 personnes, médiane 1.0 = une seule parution). Aucune erreur dans sync_log (tous les syncs ok). Correction au passage du même artefact de génération que findevcanada d333936 et dupont 3d860d5 : url vide dans data/sources.json → https://telefilm.ca (la fiche affichait « Site : []() »). Sync isolé rejoué : found=0, removed=1 en 2,1 s (l'offre expirée atteint miss_count=2 → active=0, retrait normal), statut ok. 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +1 −1
    2. [ka6] fix connecteur dupont: faux positif de supervision (fenêtre de maintenance Workday) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale venait d'une course entre le scan de supervision (~03:54) et le sync de rattrapage : l'unique échec (2026-09-12 00:59, « Workday 5xx après 3 essais : HTTP 500 sur dupont.wd5 ») est la fenêtre de maintenance hebdomadaire Workday du vendredi nuit (même famille que altusgroup 4e9be24 et cambria eca139b), et le sync suivant (03:59:58) était déjà ok avec found=1 = médiane historique exacte. Le connecteur (tenant workday dupont.wd5, site jobs — usine DuPont de Nemours de Thetford Mines) est INTACT : l'offre QC courante General Operator 248395W est en base et active ; la baisse 2→1 vient de la dépublication normale de l'offre montréalaise 250282W (Opérateur de production H/F, miss_count=2) le 2026-09-11. Correction au passage du même artefact de génération que findevcanada d333936 : url vide dans data/sources.json → https://www.dupont.com (la fiche affichait « Site : []() »). Sync isolé rejoué : found=1 en 1,9 s, statut ok. 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +1 −1
    3. [ka6] fix connecteur cambria: ajout de Fermont au dictionnaire _QC_CITIES (normalize.py) — l'offre QC courante du tenant workday cambria.wd1 (« Mechanic » R-103013, site minier Sitec à Fermont, Côte-Nord, publiée le 2026-04-10, description en français) était INVISIBLE depuis la création du connecteur (Vague D 2026-08-25) : Workday l'affiche sous le libellé « Sitec Fermont » sans province ni code postal, et Fermont manquait au dictionnaire partagé _QC_CITIES, si bien que is_quebec_location la rejetait au filtre client ET au repli de facette serveur (_find_qc_facet — ce tenant n'expose aucune facette province, seulement pays Canada=1 + lieux plats). Le connecteur ne voyait donc que l'offre montréalaise historique (Market Sales Representative R-103079), dépubliée par l'employeur le 2026-09-02 (miss_count=2, retrait normal) → found=0 depuis, d'où le statut stale (la supervision date le succès au dernier sync found>0). L'unique vrai échec (2026-09-12 03:08, « Workday non-JSON HTTP 200 text/html ») est la fenêtre de maintenance hebdomadaire Workday du vendredi nuit, transitoire. Correctif minimal dans la couche partagée (même famille que f4038e4) : « fermont »: « Fermont » — mot à graphie unique, aucun homonyme hors QC (≠ Fremont), garde-fous _NON_QC_CITIES/_NON_QC_REGION_RE intacts ; test ajouté sur le libellé exact « Sitec Fermont ». Sync isolé rejoué : found=1, added=1 en 2,9 s — R-103013 en base, ville Fermont, région Côte-Nord, statut ok (médiane historique 0–1). 102 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 2 files +7 −2
    4. [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.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +28 −4

  7. Fri, Sep 11, 2026 3

    1. [ka6] fix connecteur findevcanada: volume 0 légitime confirmé en direct — l'employeur a dépublié ses 2 dernières parutions QC le 2026-09-11 (Principal, Financial Institutions FR+EN du 09-03 et Principal, Business Integrity Officer FR+EN du 09-04 : /j/<code> → /oops, tenant-scoped → ?not_found=true, API détail 404) entre 11h31 et 12h41 EDT. Le tenant Workable findevcanada reste le système ACTUEL et vivant (widget v1 200 {name: FinDev Canada, jobs: []} ; API v3 de la SPA total=0 — concordance parfaite) : la migration est dans l'AUTRE sens que ce que suggère la page carrières findevcanada.ca, dont le lien « View our job openings » → edc.taleo.net/careersection/findevcanada_corporate est un VESTIGE pré-migration (instantané Wayback 2026-05-30 : seul le lien Taleo existait, les boutons Workable ont été ajoutés depuis ; la zone edc.taleo.net entière renvoie 503 Zone Maintenance Oracle, et EDC société mère publie elle-même sur apply.workable.com/export-development-canada — 57 lignes vérifiées, aucun poste FinDev). Aucune offre FinDev courante ailleurs (LinkedIn : mêmes parutions désormais fermées ; ecoworks : offre de juillet périmée, Toronto). Employeur ~150 personnes, médiane 4 (2 parutions × 2 langues) : zéro ouverture ponctuelle est normal. Le connecteur est INTACT et fonctionnel — aucune modification du code (plateforme workable et tenant corrects). Correction au passage d'un artefact de génération dans data/sources.json : url vide → https://www.findevcanada.ca (la fiche affichait « Site : []() »). Sync isolé rejoué : found=0 en 0,1 s, statut ok. 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +1 −1
    2. [ka6] fix connecteur derumarketcatering: retrait définitif de la source (précédent projevia 7b871e8) — double condamnation confirmée en direct le 2026-09-11 : (1) le compte JazzHR du tenant est désactivé de façon permanente (page 200 « Inactive Career Page / this account is no longer active », détectée explicitement par jazzhr._fetch_list depuis la mission du 2026-09-04 → RuntimeError sans retry, 60 échecs consécutifs) ; (2) l'employeur était un faux positif de génération : Deru Market + Catering est un restaurant de Kirkland, État de WASHINGTON (derumarket.com, ZipRecruiter « Kirkland, WA »), pas Kirkland QC — sa seule offre jamais ingérée (FOH Staff, Kirkland WA) était américaine et est inactive en base depuis le fix is_quebec_location f4038e4. Deux missions ka6 (2026-08-26, 2026-09-04) avaient déjà conclu site_source_mort sans retirer la source : la supervision la resynchronisait donc en boucle (statut broken). Retrait complet selon le pattern maison : suppression de jobka/connectors/derumarketcatering.py (registre auto-découvrant → 1105 connecteurs), de l'entrée data/sources.json (1107 sources, employeurs_directs 1048→1047, page Sources vérifiée sans Deru) et de la fiche docs/connecteurs/derumarketcatering.md (INDEX/ats-jazzhr seront nettoyés à la prochaine régénération gen_connector_docs). Données en base conservées (offre déjà active=0, historique sync_log intact). Aucune modification de la plateforme jazzhr : non-régression tenant cliniqued found=1 ok. run.py sync derumarketcatering → « connecteur inconnu » (comportement attendu). 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 3 files +2 −136
    3. [ka6] fix connecteur euromoneyplc: balayage fr-CA + en-CA + en-GB dans la plateforme dayforce (tenant seul) — la dernière offre QC du tenant (4827 « Partenaire, Acquisition de talent », Montréal, publiée en français) a été dépubliée par l'employeur le 2026-09-11 entre 09h19 et 11h40 EDT ; le tenant euromoneyplc publie désormais 0 poste TOTAL (vérifié en direct : boards CANDIDATEPORTAL + EUROMONEY × cultures fr-CA/en-CA/en-GB/en-US = 0 partout, détail id bidon → 404) → volume 0 légitime AUJOURD'HUI. Mais la recherche Dayforce étant PARTITIONNÉE par culture de publication (cf. harrisrebar 788bfb4) et le portail officiel de l'employeur étant en-GB (delinian.com/careers → dayforcehcm CandidatePortal en-GB du même tenant), fr-CA seul rendrait le connecteur aveugle à toute future offre QC publiée en anglais : fetch() balaie désormais fr-CA PUIS en-CA PUIS en-GB (pattern harrisrebar : CULTURE permuté en attribut d'instance, dédup par jobPostingId, version française gagnante — la classe plateforme dayforce et les autres tenants sont intacts). Correction au passage de EMPLOYER, artefact de génération (intitulé de poste) : « Talent Acquisition Partner » → « Delinian (ex-Euromoney) » (Euromoney Institutional Investor plc rebrandé Delinian en 2023, bureau de Montréal au 1001 De Maisonneuve Ouest). Sync isolé rejoué : found=0 en 7,2 s (exact, l'offre 4827 avait déjà été retirée par le mécanisme normal miss_count=2 au sync de 14h04), statut ok. 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 1 file +32 −3

  8. Thu, Sep 10, 2026 6

    1. [ka6] fix connecteur quadreal: balayage des deux sites carrières du tenant workday quadreal.wd10 (Parkbridge + QuadReal) — le connecteur ne scannait que le site filiale Parkbridge, dont l'unique offre QC historique (R0006877 « Préposé à l'entretien ménager », Magog) a été dépubliée par l'employeur le 2026-09-10 (détail API 403 permission denied, recherche mot-clé/ID → 0, facette province réduite à AB/ON/BC sur 7 postes) → found=0, statut stale. Le site principal QuadReal du même tenant publie pourtant 68 postes dont 1 au Québec (R0006871 « Property Administrator/Administrateur immobilier », Montréal), invisible pour le connecteur. fetch() balaie désormais Parkbridge PUIS QuadReal (pattern harrisrebar : SITE permuté en attribut d'instance, dédup par external_id/jobReqId — la classe plateforme workday et les autres tenants sont intacts). Correction au passage de EMPLOYER : Quadreal → QuadReal (graphie officielle). Sync rejoué : found=1 en 2,7 s (+1 Montréal, -1 Magog retirée par le mécanisme normal miss_count=2), volume conforme à la médiane 0.5–1. 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +33 −3
    2. [ka6] fix connecteur harrisrebar: balayage en-CA complémentaire dans la plateforme dayforce (tenant seul) — la recherche Dayforce est PARTITIONNÉE par culture de publication, sans repli serveur (vérifié : lavieenrose fr-CA 172 / en-CA 281, soprema fr 23 / en 20). Le tenant harrisrebar (Harris Rebar, rebrandé Nucor Rebar Fabrication — harrisrebar.com redirige vers nucor.com) publie ses 12 postes actuels (ON/AB/NS/NB/BC) en en-CA seulement : la recherche fr-CA du connecteur renvoie 0 poste TOTAL. L'unique offre QC historique (16804 « AIDE À L'EXPÉDITION/À LA RÉCEPTION », Montréal, publiée en français) a été dépubliée par l'employeur le 2026-09-10 entre 10h04 et 14h35 EDT — absente des listings des 2 boards (CANDIDATEPORTAL + HarrisCanada) × 2 cultures, mot-clé compris ; le détail API 200 est un rendu résiduel (createdTimestampUTC = heure de la requête ; id bidon → 404). Volume 0 légitime AUJOURD'HUI, mais fr-CA seul rendrait le connecteur aveugle à toute future offre QC publiée en anglais : fetch() balaie désormais fr-CA PUIS en-CA (dédup par jobPostingId, version française gagnante, CULTURE restaurée en attribut d'instance — la classe plateforme et les ~124 autres tenants dayforce sont intacts). Correction au passage de EMPLOYER, artefact de génération (titre de poste) → « Nucor Rebar Fabrication (Harris Rebar) ». Test réel : fr-CA 0 + en-CA 12 postes scannés → 0 offre QC (exact). Sync isolé rejoué : found=0, removed=1 (16804 retirée par le mécanisme normal miss_count=2), statut ok. 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +28 −3
    3. [ka6] fix connecteur gus: repli sur le listing JSON embarqué de la page carrières dans la plateforme zoho_recruit — le flux RSS (/jobs/<PAGE>/rss) ne reflète que les offres « publiées aux job boards » par le tenant : chez gus il n'a jamais listé qu'1 offre et est devenu VIDE le 2026-09-10 (200, 0 <item>) alors que le site carrières publie 51 offres QC bien vivantes (page détail 200, dont l'offre en base 715384000005984001). La page /jobs/<PAGE> est une SPA mais embarque le listing complet dans un <input type=hidden id=jobs> (JSON Posting_Title/City/State/Country/Job_Description/Job_Type/Date_Opened/Publish) : quand le RSS n'a aucun item, fetch() bascule sur ce JSON embarqué (filtre Publish + Québec, villes débarrassées des suffixes de quartier Zoho « Gatineau Northeast » → « Gatineau », localité entre parenthèses extraite « Vaudreuil-Soulanges (Coteau-du-Lac) » → « Coteau-du-Lac »). Sync rejoué : found=51 en 2,7 s (+50, ~1, -0), l'offre existante réactivée miss_count=0 — le RSS sous-rapportait depuis le début (médiane 1.0). Non-régression : voie RSS inchangée pour les 16 autres tenants zoho_recruit (mallette_sag 26, altitude_sports 11, maintenancexpert 1 = volumes en base), 101 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 1 file +74 −4
    4. [ka6] snapshot pré-mission gus
      Simon-Pierre Boucher · 1 file +14 −2
    5. [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.
      Simon-Pierre Boucher · 1 file +15
    6. [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.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +22 −1

  9. Wed, Sep 9, 2026 6

    1. [ka6] connecteur pelmorex: volume 0 légitime — les 2 offres Montréal (« Rédacteur -ice- Sur appel » 8c5dada7, « Vidéaste-Météorologue » d4718376) dépubliées par l'employeur le 2026-09-09 entre 13h10 et 15h39 EDT (API détail Lever → 404 « Document not found », pages hébergées = rendus résiduels 200). Vérifications réelles : API postings 200 avec 5 offres toutes Oakville/Madrid — y compris « Producteur Media MM- Temps partiel » (francophone MétéoMédia) qui exige d'être basé dans la grande région de Toronto ; page carrières officielle pelmorex.com → même embed jobs.lever.co/pelmorex (aucune migration d'ATS), les mentions Montréal n'y sont que l'adresse du bureau (1200 av. Papineau). Connecteur sain (tous les syncs ok, 0.6 s) ; le statut stale venait du volume 0 compté comme échec par la supervision. Purge par le mécanisme normal : sync isolé rejoué → miss_count=2 → active=0 (found=0, removed=2, statut ok). Les offres QC réapparaîtront d'elles-mêmes à la prochaine publication de Pelmorex/MétéoMédia à Montréal. Même famille de vides légitimes que myview (4b92938), neweratech (c0f8946), rollstack (8636932), vasco (d6009d3), tefron (e62dc72), altom_transport (2fa16cd), onrunning (1155f22). Note de contexte ajoutée au connecteur, aucun changement de logique. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 1 file +18 −1
    2. [ka6] fix connecteur groupe_bellemare: retry avec ré-amorçage de session Scrapfly dans la plateforme njoyn — échec transitoire du 2026-09-09 12h26 (Scrapfly a renvoyé 0 octet aux 2 essais, bellemare et groupe_master tombés ensemble, repartis seuls au sync suivant) ; le retry unique de _fetch_listing rejouait la MÊME session Scrapfly (proxy collant + cookies), donc le même proxy défaillant ; désormais 3 essais, backoff 10-20 s, session Scrapfly ré-amorcée entre les essais (nouveau proxy) ; syncs rejoués : bellemare 31 offres (médiane 31.0), groupe_master 15 (médiane 14.0)
      Simon-Pierre Boucher · 1 file +11 −5
    3. [ka6] fix connecteur bayshore: retry sur réponse searchjobs non-JSON dans la plateforme taleo — le frontal a renvoyé une page HTML statut 200 au lieu du JSON (« Expecting value: line 2 column 1 », constaté 2026-09-09 06h29 sur bayshore, reparti seul), cas couvert par aucun retry existant (ni 5xx ni anti-bot); nouveau _search_page, 3 essais backoff 10-20 s avec ré-amorçage de session, échec explicite avec extrait du corps après 3 essais; sync rejoué: 11 offres (médiane 11.0)
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +22 −2
    4. [ka6] fix connecteur sante_montreal: Radware étendu au domaine personnalisé post-maintenance Njoyn — bascule Scrapfly + sessions Scrapfly pour la pagination
      …
      Depuis la maintenance Njoyn du 2026-09-05→07, Radware Bot Manager couvre aussi
emplois.santemontreal.qc.ca (avant : seulement *.njoyn.com). Chronologie des
syncs : 731 offres (08/09 14h32) → 50 (POST de pagination rejeté) → 0 (page
liste bloquée). La page « Radware Block Page » embarque l'URL Xweb.asp dans ses
paramètres et passait le garde-fou de _fetch_listing → faux « 0 offre, ok ».

- sante_montreal.py : USE_SCRAPFLY = True (pattern des 10 autres tenants Njoyn)
- njoyn.py : détection _RADWARE_RE (Radware Block Page/shieldsquare/perfdrive)
  dans _html avec bascule Scrapfly pour tout le reste du sync ; sessions
  Scrapfly (_sf_session) partagées entre GET liste / POST pagination / détails
  — sans session le tbtoken (lié aux cookies ASP du GET) est rejeté en
  400 Bad Request au POST ; casse Xweb.asp forcée sur l'action du formulaire
  (gotcha 2026-09-02)
- base.py : kwarg optionnel session sur scrapfly()/get_scrapfly()
  (session + session_sticky_proxy), rétrocompatible

Sync rejoué : 726 offres (médiane historique ~706), removed=16 offres
dépubliées pendant la panne. pm2 restart job-ka-sync OK, site 200.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 3 files +52 −12
    5. [ka6] connecteur myview: volume 0 légitime — l'unique offre QC (« Assistant technique en pharmacie » R2000587691, 1130 De La Chaudière, Québec) a été dépubliée par l'employeur le 2026-09-08 entre 21h35 et 00h37 EDT (détail → 403 S22 « permission denied » = dépublication Workday). Site Workday loblaw_careers du tenant myview.wd3 à volume QC naturellement très faible (médiane 1.0) : l'embauche de masse de Loblaw passe par careers.loblaw.ca (autre système), le site Workday ne porte qu'un filet d'offres. Vérifications réelles : API cxs 200 avec total=0 (site vivant, 0 offre au total, pas seulement 0 QC), autres sites du même tenant sondés (careers : 2 offres Edmonton/Warman SK hors QC ; sdm_careers : 0) — aucune offre QC ailleurs, pas de migration à suivre. Le statut stale venait du volume 0 compté comme échec par la supervision ; le connecteur est sain (tous les syncs ok=1, 1.2 s). Purge par le mécanisme normal : sync isolé rejoué → miss_count=2 → active=0 (found=0, removed=1, statut ok). Les offres QC réapparaîtront d'elles-mêmes quand Loblaw republiera au Québec sur Workday. Même famille de vides légitimes que neweratech (c0f8946), rollstack (8636932), vasco (d6009d3), tefron (e62dc72), altom_transport (2fa16cd), onrunning (1155f22). Note de contexte ajoutée au connecteur, aucun changement de logique. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 1 file +13 −1
    6. [ka6] fix connecteur bell_textron: retry avec backoff sur 5xx transitoire dans la plateforme taleo — un 500 isolé de l'API searchjobs (constaté 2026-09-08 23h29 sur textron, reparti seul) faisait échouer tout le sync car raise_for_status dans base.get/post n'a aucun retry; nouveau _req couvrant amorce/liste/détail, 3 essais backoff 10-20-30 s, les 4xx restent des échecs immédiats (même correctif que workday b5b4be3); sync rejoué: 16 offres (médiane 16.0)
      Simon-Pierre Boucher · 1 file +26 −5

  10. Tue, Sep 8, 2026 2

    1. [ka6] connecteur neweratech: volume 0 légitime — les 2 offres QC (« Infraction Review Technician » 8684549002 et « Représentant service à la clientèle - Révision des infractions » 8684559002, Saint-Jean-sur-Richelieu) ont été dépubliées par l'employeur le 2026-09-08 entre 14h19 et 17h39 EDT (détail → 404). Multinationale TI américaine à volume QC naturellement très faible (médiane 2.0, seules ses offres de contrôle du stationnement à Saint-Jean sont québécoises). Vérifications réelles : boards-api Greenhouse 200 avec 61 offres (É.-U./Inde/Asie-Pacifique/Remote, aucune mention Québec — toutes correctement rejetées par is_quebec_location, 0 faux positif), board vivant, neweratech.com/careers consomme toujours boards-api.greenhouse.io/v1/boards/neweratech (pas de migration d'ATS). Le statut stale venait du volume 0 compté comme échec par la supervision ; le connecteur est sain (tous les syncs ok=1, 0.1 s). Purge par le mécanisme normal : sync isolé rejoué → miss_count=2 → active=0 (found=0, removed=2, statut ok). Test final : fetch réel = 61 bruts, 0 retenus (QC) = comportement correct, les offres QC réapparaîtront d'elles-mêmes quand New Era republiera à Saint-Jean-sur-Richelieu. Même famille de vides légitimes que rollstack (8636932), vasco (d6009d3), tefron (e62dc72), altom_transport (2fa16cd), onrunning (1155f22). Note de contexte ajoutée au connecteur, aucun changement de logique. pm2 restart job-ka-sync OK, site 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +13 −1
    2. [ka6] connecteur rollstack: volume 0 légitime — l'unique offre QC (« Software Engineer - TypeScript », 0e7f20c9, localisations dont « Quebec(CA) ») a été dépubliée par l'employeur le 2026-09-08 entre 11h08 et 14h29 EDT. SaaS américain remote-first à volume QC naturellement très faible (médiane 1.0). Vérifications réelles : posting-api Ashby 200 avec 3 offres (É.-U./remote « Canada » pancanadien, aucune mention Québec — toutes correctement rejetées par is_quebec_location, 0 faux positif), board vivant, rollstack.com/careers pointe toujours vers jobs.ashbyhq.com/rollstack (pas de migration d'ATS). Le statut stale venait du volume 0 compté comme échec par la supervision ; le connecteur est sain (tous les syncs ok=1, 0.1-0.2 s). Purge par le mécanisme normal : sync isolé rejoué → miss_count=2 → active=0 (found=0, removed=1, statut ok). Test final : fetch réel = 3 bruts, 0 retenus (QC) = comportement correct, les offres QC réapparaîtront d'elles-mêmes quand Rollstack republiera au Québec. Même famille de vides légitimes que vasco (d6009d3), tefron (e62dc72), altom_transport (2fa16cd), onrunning (1155f22). Note de contexte ajoutée au connecteur, aucun changement de logique. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 1 file +10 −1

  11. Mon, Sep 7, 2026 3

    1. [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)
      Simon-Pierre Boucher · 1 file +17 −3
    2. [ka6] connecteur cgi: détection de l'état transitoire post-maintenance Njoyn (« Invalid request XWP10023-UA ») — la plateforme entière (tous tenants, vérifié même avec un vrai Chromium depuis IP résidentielle) répond 200 avec ce corps de ~41 octets depuis ~11h EDT le 2026-09-07, pendant la fenêtre de maintenance officielle (retour prévu dimanche ~21h); échec immédiat et explicite dans _fetch_listing, sans retry ni 2e crédit Scrapfly, offres conservées (292 actives cgi, 712 sante_montreal, protégées par la garde anti-dérive); rien à réparer côté connecteur — le volume reviendra à la fin de la fenêtre
      Simon-Pierre Boucher · 1 file +14 −1
    3. feat(fiche): refonte premium mobile-first de la fiche d'offre (2026-09-07)
      …
      Même socle que les fiches Lou-Ka v3 / Immo-Ka v3 (frontend/src/fiche/,
préfixe jk-, tokens --jk-*, fond papier, cartes blanches bord 1 px, cyan
réservé aux CTA/salaire ; header encre conservé en version compacte) :
héro (logo + employeur · lieu, salaire en exergue + équivalent annuel,
capsules marché / nouveau / offre directe, titre, actions favoris / partage /
Postuler) ; « En bref » déterministe (salaire vs médiane de la catégorie,
source directe ou portail, exigences, mode/type/niveau, fraîcheur et date
limite, volume de l'employeur, avantages) ; navigation sticky ; « Salaire et
marché » (KPI, jauge P25–P75 du point médian, historique du salaire affiché,
méthodologie — jamais d'estimation) ; « Le poste » (grille icône/valeur,
rangées, avantages, description tronquée, champs bruts en accordéon) ; « Où
travailler » (carte OSM) ; Dossier de l'offre ; Sources et méthodologie. CTA
sticky après le héro, aside desktop sticky, « Demander à Ka » via le widget
KA Agent. Header compact sur /emploi/ (favoris + partage via fiche/current.ts,
badge masqué). Rangées d'offres de la liste : surface blanche, bord 1 px,
ombre légère au survol. Icons.tsx (pictos partagés) ajouté. Aucun order CSS ;
pas de scrollIntoView à l'ouverture. Scripts QA : preview.mjs,
check-order.mjs, shots.mjs, interactions.mjs (Playwright via lien vers
vrai-prix/node_modules).

Validé sur M3U96a : tsc + vite build, check-order OK, interactions OK,
captures 6 largeurs ; dist basculé, aucun changement API.
      Simon-Pierre Boucher · 18 files +2,150 −193

  12. Sun, Sep 6, 2026 1

    1. [ka6] connecteur cgi: maintenance planifiée de la plateforme Njoyn (2026-09-05 ~22h30 EDT, tous les tenants *.njoyn.com ET domaines personnalisés redirigés vers maintenance.njoyn.com/platform-maintenance, page ~29 ko) — détection explicite de la page de maintenance dans _fetch_listing de la plateforme njoyn: échec immédiat sans retry ni crédit Scrapfly gaspillé, message 'plateforme Njoyn en maintenance planifiée' dans sync_log, offres conservées (292 actives cgi); le volume reviendra de lui-même à la fin de la fenêtre (retour prévu type: dimanche ~21h)
      Simon-Pierre Boucher · 1 file +15 −1
Menu

Theme
↑↓ navigate ↵ open esc close / or ⌘K anywhere