SPB Git
spboucher.ai

spb/job-ka

Public
page 1

  1. Fri, Sep 18, 2026 6

    1. [ka6] fix connecteur drop_genie: faux positif de supervision (0 offre légitime — DropGenie n'a plus aucun poste ouvert) — aucun défaut du connecteur, correction d'artefacts sources.json (url vide, secteur erroné) — le statut stale vient de la définition de succès de la supervision : le tenant Breezy drop-genie n'a AUCUNE offre depuis la fermeture de son unique poste « Test Engineer - Microfluidics » 0cec9ddfa30d (Montréal, paru le 2026-06-08, page détail live = « Position Closed », miss_count=2 → active=0 déjà appliqué), donc chaque sync horaire rend ok=1 found=0 (médiane 1.0) et est compté comme non-succès depuis 4,8 h. Le connecteur est INTACT et re-vérifié live : l'API https://drop-genie.breezy.hr/json?verbose=true répond 200 avec un tableau vide [], et la page carrières affiche NO_POSITIONS (l'aveuglement type stateindustrial est exclu : zéro offre sur le board, toutes langues confondues). Même profil que altusgroup 2fc9e63, autotradercanada 77020a3, altom_transport ea13137 : tenant à volume nul compté non-succès par la supervision. Correction au passage de deux artefacts du générateur vague C dans data/sources.json : url vide → https://www.dropgenie.com (vérifié 200, titre « DropGenie – Making Personalized Possible » ; la fiche affichait « Site : [DropGenie]() ») et secteur « Logistique » → « Biotechnologie » (DropGenie automatise l'édition génique — « automate gene editing » sur son board —, son unique offre était un poste de microfluidique ; secteur déjà présent dans le vocabulaire, 7 sources). Docstring du connecteur mise à jour (0 offre, re-vérif 2026-09-18). Sync isolé rejoué : found=0 en 0,1 s, ok=1 — 0 est le volume légitime tant que DropGenie ne republie pas ; les offres reviendront d'elles-mêmes si republiées. 106 tests pytest verts. pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      Simon-Pierre Boucher · 2 files +6 −4
    2. [ka6] fix connecteur awc: ajout de Rougemont (Montérégie) au dictionnaire _QC_CITIES — le connecteur était aveugle aux offres du vignoble québécois d'Arterra — le statut broken combinait trois éléments : (1) une NameResolutionError DNS transitoire le 18/09 12:53 sur awc.wd3.myworkdayjobs.com (même vague que altusgroup/autotradercanada à 12:51, non reproduite), (2) la dépublication NORMALE de l'unique offre suivie « Représentant des ventes (SAQ/licenciés) Montréal/Brossard » R-13270 (absente du board live, miss_count=2 → active=0), qui a fait tomber found de 1 à 0, et (3) un VRAI défaut : le tenant Workday awc.wd3 n'expose qu'une facette de lieux plate au niveau ville, et sa seule localisation QC restante est « Rougemont » (Montérégie, vignoble d'Arterra) — absente du dictionnaire curé _QC_CITIES de normalize.py, donc invisible à la fois pour le filtre client is_quebec_location ET pour le repli facette-serveur de _find_qc_facet (qui agrège les valeurs de facette via la même fonction). Résultat : 2 offres QC réelles ignorées, dont « Électromécanicien - syndiqué (Qc) » R-13064 parue le 2026-08-19 (aveuglement d'un mois) et « Partenaire d'affaires en ressources humaines » R-13556 parue le 2026-09-10. Correction minimale dans normalize.py : entrée « rougemont » → « Rougemont » dans _QC_CITIES (regions-qc.json connaissait déjà rougemont → Montérégie ; le garde-fou _NON_QC_REGION_RE continue d'exclure « Rougemont, NC »). Bénéficie aussi au connecteur lassonde (Industries Lassonde, Rougemont). Sync isolé rejoué : found=2, added=2 en 4,6 s — R-13556 et R-13064 en base, actives, ville Rougemont, région Montérégie, volume 2 ≥ médiane 1.0. 106 tests pytest verts. pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 1 file +2 −1
    3. [ka6] fix connecteur g3canada: bascule CULTURE fr-CA → en-CA (le tenant Dayforce ne sert plus rien en fr-CA) + correction artefacts sources.json — le statut stale combinait deux choses : (1) la dépublication NORMALE de l'unique offre QC (« Journalier » 3773, Québec, parue le 2026-07-30) confirmée à la source (404 sur l'API détail), qui a fait tomber found de 1 à 0 (miss_count=2 → active=0), et (2) un VRAI défaut d'aveuglement du connecteur : le search Dayforce du tenant g3canada en cultureCode fr-CA renvoie désormais maxCount=0 (vérifié live, 200 JSON valide) alors que le même search en en-CA/en-US renvoie les 13 offres du board — même défaut que stateindustrial d478a07 (le fr-CA n'est pas cassé globalement chez Dayforce : lavieenrose fr-CA = 154 offres ; c'est ce tenant qui a désactivé/vidé sa culture fr-CA). Aucune offre QC live sur le board (Winnipeg ×3, Alberta ×2, Saskatchewan ×5, North Vancouver, Thunder Bay ×2 — l'unique occurrence de « quebec » dans le JSON complet est « excluding Quebec » dans une description) : 0 reste le volume légitime tant que G3 ne republie pas au Québec (terminal au Port de Québec), mais le connecteur n'est plus aveugle et les offres reviendront d'elles-mêmes. Correction minimale dans g3canada.py : CULTURE='en-CA' (le filtre Québec reste côté client via _is_qc) + correction des artefacts vague C : EMPLOYER/name « Électricien industriel » (titre de poste pris pour un nom d'employeur) → « G3 Canada » (site officiel https://www.g3.ca vérifié 200, titre « G3 - G3 Canada Limited »), url vide → https://www.g3.ca, region « G3 Québec » (nom d'élévateur) → « Québec », avec UPDATE du champ employer de l'offre inactive en base. Sync isolé rejoué : found=0 en 2,9 s, ok=1 — 13 offres lues, 0 QC après filtre, cohérent avec la médiane 0.5. 106 tests pytest verts. pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +13 −7
    4. [ka6] fix connecteur autotradercanada: faux positif de supervision (0 offre QC légitime — AutoTrader n'a plus de poste au Québec) + échec DNS transitoire ponctuel — aucun défaut du connecteur — le statut stale vient de la définition de succès de la supervision : le board Greenhouse autotradercanada n'a AUCUNE offre QC depuis la dépublication des 2 offres de Montréal/Longueuil (7799193003 et 7820524003, 404 confirmés sur l'API détail, déjà constatée le 2026-09-14), donc chaque sync horaire rend ok=1 found=0 (médiane 0.0) et est compté comme non-succès depuis le 2026-09-14 (97 h). Le connecteur est INTACT et re-vérifié live : l'API boards-api.greenhouse.io répond 200 avec 23 offres, toutes hors Québec (22 Toronto, 1 Remote-Canada Maritimes) — zéro occurrence de quebec/montréal/longueuil/laval/gatineau/sherbrooke dans le JSON complet content=true (l'aveuglement type stateindustrial est exclu ; is_quebec_location validé sur les libellés live, Remote (Canada) correctement exclu). L'unique sync en échec (18/09 12:52) est une NameResolutionError DNS transitoire sur boards-api.greenhouse.io, non reproduite (API OK en live). Même profil que altusgroup 2fc9e63, altom_transport ea13137, earthrated f7b1c35, canadasmotorcycle 175b215 : tenant à volume QC nul compté non-succès par la supervision. L'entrée sources.json est déjà propre (url https://www.autotrader.ca présente depuis la mission du 14/09) — seule la docstring du connecteur est mise à jour (23 offres, re-vérif 2026-09-18). Sync isolé rejoué : found=0 en 0,1 s, ok=1 — 0 est le volume légitime tant qu'AutoTrader ne republie pas au Québec ; les offres reviendront d'elles-mêmes si republiées. 106 tests pytest verts. pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      Simon-Pierre Boucher · 1 file +6 −1
    5. [ka6] fix connecteur altusgroup: faux positif de supervision (0 offre QC légitime — Altus n'a plus de poste au Québec) + échec DNS transitoire ponctuel — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient de la définition de succès de la supervision : le tenant Workday altusgroup.wd3 (site AltusGroup) n'a AUCUNE offre QC depuis le retrait de l'unique offre montréalaise fin août (R0013818, déjà constaté le 2026-08-26), donc chaque sync horaire rend ok=1 found=0 (médiane 0.0) et est compté comme non-succès depuis le 2026-08-26 (551 h). Le connecteur est INTACT et re-vérifié live : l'API cxs répond 200 avec 42 offres (Toronto, Calgary, Ottawa, US, UK, Paris, Sydney, Singapour, Inde…) — recherche serveur « Quebec »/« Montréal » = 0 résultat, zéro occurrence de quebec/montréal/laval/gatineau/sherbrooke dans le JSON complet des 3 pages (l'aveuglement type stateindustrial est exclu ; le hook _external_id posé le 2026-09-12 reste correct). L'unique sync en échec (18/09 12:51) est une NameResolutionError DNS transitoire sur altusgroup.wd3.myworkdayjobs.com, non reproduite (API OK en live). Même profil que altom_transport ea13137, earthrated f7b1c35, canadasmotorcycle 175b215, jsheldllc bdc5d09, psacunion 4d8080b : tenant à volume QC nul/faible compté non-succès par la supervision. Correction au passage de l'artefact du générateur vague D : url vide dans data/sources.json → https://www.altusgroup.com (vérifié 200, titre « Altus Group - Data-Powered CRE Technology & Analytics » ; la fiche affichait « Site : [Groupe Altus]() »). Le nom d'employeur « Groupe Altus » est correct. Docstring du connecteur mise à jour (42 offres, re-vérif 2026-09-18). Sync isolé rejoué : found=0 en 4,0 s, ok=1 — 0 est le volume légitime tant qu'Altus ne republie pas au Québec ; les offres reviendront d'elles-mêmes si republiées. 106 tests pytest verts. pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +4 −3
    6. [ka6] fix connecteur altom_transport: faux positif de supervision (0 offre QC légitime chez ce transporteur US) + échec DNS transitoire ponctuel — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient de la définition de succès de la supervision : le tenant Workable altom-transport n'a AUCUNE offre QC depuis la fermeture de « Chauffeur de Camion-Citerne Classe 1 » (Montréal) fin août, donc chaque sync horaire rend ok=1 found=0 (médiane 0.0) et est compté comme non-succès depuis le 2026-08-28 (509 h). Le connecteur est INTACT et re-vérifié live : l'API widget répond 200 avec 52 offres, TOUTES aux États-Unis — zéro lieu CA dans les tableaux locations, zéro poste en télétravail, zéro mention Québec/Montréal dans le JSON complet (l'aveuglement type stateindustrial est exclu). L'unique sync en échec (17/09 20:51) est une NameResolutionError DNS transitoire sur apply.workable.com, non reproduite. Même profil que earthrated f7b1c35, canadasmotorcycle 175b215, jsheldllc bdc5d09, psacunion 4d8080b : tenant à volume QC nul/faible compté non-succès par la supervision. Correction au passage de l'artefact du générateur vague C : url vide dans data/sources.json → https://altomtransport.com (vérifié 200, titre « Altom Transport | Petroleum and Chemical Transportation » ; la fiche affichait « Site : [Altom Transport]() »). Le nom d'employeur « Altom Transport » est correct. Docstring du connecteur mise à jour (52 offres, re-vérif 2026-09-18). Sync isolé rejoué : found=0 en 0,2 s, ok=1 — 0 est le volume légitime tant qu'Altom ne republie pas au Québec ; les offres reviendront d'elles-mêmes si republiées. 106 tests pytest verts. pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +9 −7

  2. Thu, Sep 17, 2026 5

    1. [ka6] fix connecteur stateindustrial: bascule CULTURE fr-CA → en-US (le tenant Dayforce ne sert plus rien en fr-CA) + correction artefacts sources.json — le statut stale combinait deux choses : (1) la dépublication NORMALE des 2 offres QC d'août (« Représentant(e) des ventes externes - Longueuil » 11661 et « Représentant(e) des ventes B2B » 11658, absentes du board dans TOUTES les cultures) qui a fait tomber found à 0 (miss_count=2 → active=0), et (2) un VRAI défaut d'aveuglement du connecteur : le search Dayforce du tenant stateindustrial en cultureCode fr-CA renvoie désormais maxCount=0 (vérifié live, 200 JSON valide) alors que le même search en en-US renvoie 29 offres, dont une offre QC RÉELLE au titre déjà francophone (« Représentant(e) des ventes externes (français/anglais) » 11795, Québec City QC, parue le 2026-09-05, détail API OK avec PayType Salary et fourchette 45-65 k) que le connecteur ne voyait pas. Le fr-CA n'est pas cassé globalement chez Dayforce (lavieenrose fr-CA = 150 offres) : c'est ce tenant qui a désactivé/vidé sa culture fr-CA. Correction minimale dans stateindustrial.py : CULTURE='en-US' (le filtre Québec reste côté client via _is_qc), plus correction des artefacts vague C dans sources.json : url vide → https://www.stateindustrial.com (vérifié 200, titre « Home - State Industrial Products ») et name/EMPLOYER « Stateindustrial » (slug collé) → « State Industrial Products », avec UPDATE du champ employer des 2 offres inactives en base. Sync isolé rejoué : found=1, added=1 en 6,9 s — l'offre 11795 est en base, active, ville Québec, région Capitale-Nationale, volume 1 ≈ médiane 0.5. 106 tests pytest verts. pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 2 files +9 −5
    2. [ka6] fix connecteur earthrated: faux positif de supervision (dépublication de l'unique offre QC Earth Rated) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient du retrait NORMAL de la dernière offre QC du tenant Greenhouse earthrated (« Social Media Video Creator & Editor/Créateur(trice) de contenu vidéo » 4327936009, Montréal, parue le 2026-07-22) : found=1 stable pendant des semaines jusqu'au sync de 12:21 (17/09), puis found=0 à 14:37 et 16:24, offre à miss_count=2 → active=0 (removed=1). Le connecteur est INTACT et vérifié live : l'API boards-api.greenhouse.io/v1/boards/earthrated/jobs répond 200 avec jobs=[] (0 offre sur TOUT le board, tous lieux confondus — le tenant n'a plus aucun poste ouvert), et le détail API de l'offre retirée renvoie 404 « Job not found » (page publique en 302 — dépublication confirmée à la source). Tous les syncs sont ok=1 dans sync_log — même profil que canadasmotorcycle 175b215, jsheldllc bdc5d09, psacunion 4d8080b, gilead 0760e1f, samsara, delos_data, solmentalhealth, autotradercanada, hera et ogilvycanada : tenant à faible volume QC 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 l'artefact du générateur vague C : url vide dans data/sources.json → https://www.earthrated.com (site officiel vérifié vivant, 200, titre « Earth Rated | Making life with dogs simpler and better. » ; la fiche affichait « Site : [Earth Rated]() »). Le nom d'employeur « Earth Rated » est correct (pas d'artefact titre-de-poste). 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 ouvert ; 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 · 1 file +1 −1
    3. [ka6] fix connecteur canadasmotorcycle: faux positif de supervision (dépublication de l'unique offre QC FortNine) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient du retrait NORMAL de la dernière offre QC du tenant JazzHR canadasmotorcycle.applytojob.com (« Warehouse Associate - Picking / Commis d'entrepôt » woW2CH6Y9y, Montréal, parue le 2026-09-01) : found=1 stable pendant des semaines jusqu'au sync de 12:24 (17/09), puis found=0 à 16:01 et 17:09, offre à miss_count=2 → active=0 (removed=1). Le connecteur est INTACT et vérifié live : le board /apply/ répond 200 et affiche explicitement « There are no open positions at this time. » (zéro lien /apply/<id>), et la page détail de l'offre retirée renvoie HTTP 410 Gone (réponse JazzHR d'une offre dépubliée — dépublication confirmée à la source). Tous les syncs sont ok=1 dans sync_log — même profil que jsheldllc bdc5d09, psacunion 4d8080b, gilead 0760e1f, samsara, delos_data, solmentalhealth, autotradercanada, hera et ogilvycanada : tenant à faible volume QC 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 l'artefact du générateur : url vide dans data/sources.json → https://fortnine.ca (site officiel vérifié vivant — 403 anti-bot en curl direct mais 200 via Scrapfly, titre « Canada's Motorcycle Powersport Online Store | FortNine » ; la fiche affichait « Site : [FortNine]() »). Le nom d'employeur « FortNine » est correct (pas d'artefact titre-de-poste). Sync isolé rejoué : found=0 en 0,2 s, ok — 0 est le volume légitime tant que le tenant n'a pas de poste ouvert ; les offres reviendront d'elles-mêmes si republiées. 106 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 jsheldllc: faux positif de supervision (dépublication des 5 offres QC Technorm) — aucun défaut du connecteur, correction d'un artefact sources.json (url vide) — le statut stale vient du retrait NORMAL des 5 offres QC du tenant SmartRecruiters JSHeldLLC (filiale Technorm : Technicien multimédia 744000138400679 Montréal, 2× Technologue en architecture codes et normes 744000137204159 Québec / 744000137204029 Montréal, 2× Architecte conseiller technique OAQ 744000137203030 Québec / 744000137201864 Montréal) : found=4 stable pendant des semaines jusqu'au sync de 08:25 (17/09), puis found=0 à 10:25 et 12:42, les 5 offres à miss_count=2 → active=0 (removed=4+1). Le connecteur est INTACT et vérifié live : l'API postings répond (200, totalFound=105 sur le board, 6 offres Canada — Burlington ON, Winnipeg MB, Halifax NS, 2× Toronto ON, Vancouver BC — AUCUNE au Québec), et le détail API des offres retirées renvoie active:false (dépublication confirmée à la source). Tous les syncs sont ok=1 dans sync_log — même profil que psacunion 4d8080b, gilead 0760e1f, samsara, delos_data, solmentalhealth, autotradercanada, hera et ogilvycanada : tenant à faible volume QC dont la dépublication fait tomber le volume à 0, compté comme non-succès par la supervision (médiane 2.0). Correction au passage de l'artefact du générateur vague C : url vide dans data/sources.json → https://www.jsheld.com (site officiel vérifié vivant — 403 anti-bot en curl direct mais 200 via Scrapfly, titre « Technical, Scientific, Financial & Strategic Consulting Expertise » ; la fiche affichait « Site : []() »). Le nom d'employeur « J.S. Held LLC » est correct (pas d'artefact titre-de-poste cette fois). Sync isolé rejoué : found=0 en 1,7 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. 106 tests pytest verts. pm2 restart job-ka-sync OK, site 200.
      Simon-Pierre Boucher · 1 file +1 −1
    5. [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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. Wed, Sep 9, 2026 2

    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
Menu

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