Sentinelle complète — clôture M20 : 20 exigences sur 20, registre et preuves (20/10/2026)

Spec docs/specs/2026-09-09-oboxia-sentinelle-complete-design.md. Registre complet : docs/releves/2026-10-20-sentinelle-m20-registre.md ; preuves réelles : docs/releves/2026-10-20-sentinelle-m19.md.

À observer cette nuit : la première comparaison de santé 1.1 contre 1.1 en production, et le premier passage du comparateur de notes à l'échelle du parc.

Décision à soumettre à Naouphel : un fichier de page cassé (script, feuille de style) est confirmé sur deux relevés, comme une image ; l'échéance du certificat est signalée dès qu'elle apparaît.

Sentinelle M19 — preuves réelles et contre-exemples (20/10/2026)

Spec docs/specs/2026-09-09-oboxia-sentinelle-complete-design.md, M19. Relevé complet : docs/releves/2026-10-20-sentinelle-m19.md. Aucun message envoyé, aucun historique de production modifié.

• Le zéro a été contesté avant d'être écrit : 452 constats et 32 cibles non mesurées dans le relevé, donc « rien de nouveau », pas « rien vu ».
• Première comparaison 1.1 contre 1.1 : la nuit du 19→20/10 comparait 1.0 à 1.1 et la garde de version l'a refusée, à juste titre.

Juge de l'Auditeur M7 — preuves du parcours réel (19/10/2026)

Spec docs/specs/2026-09-08-oboxia-auditeur-cycle-juge-design.md, M7. Relevé complet : docs/releves/2026-10-19-juge-m7.md. Site : avocat-brigitte-karila-fr, en lecture seule (rapport de production vérifié identique par SHA-256 avant et après).

• Empreinte du contenu : 73767c69e8add9b3c46dc0147f665792381355941478da1560fb8fbaff7113c2, identique aux passages 1 et 2.
• Empreinte du prompt : 81699bff0cc7263473875ebfed48bdef7f6653b3c554b938dd626f4c964b99c3, version 2026-10-12.1.
• Le verdict n'entre pas dans la note : il reste expérimental.
• À noter : le verdict du site a changé (genuine-local 0,85 le 11/10, puis uncertain 0,6) sur un contenu différent. Le rapport de production n'a pas été touché.

Le journal reprend — et il reprend en disant pourquoi il s'était arrêté

Le trou, acté en une ligne

Aucune entrée entre le 1er juillet 06h43 et aujourd'hui : 41 jours de silence, ~811 commits non racontés ici. Ce n'est pas une panne — rien n'appelait journal/add.mjs, c'est un geste manuel qu'on a cessé de faire. Décision de Naouphel ce 11/08 à 17h15 : on ne rattrape pas rétroactivement, on repart d'aujourd'hui. Le récit de ces six semaines n'est pas perdu pour autant : il vit dans les bilans HTML publiés (docs/bilan-general-2026-08-11.html, docs/journal-actes-2026-08-10.html), simplement pas ici.

⚠️ Ce qui n'a jamais cessé, en revanche : journal/fleet.json (la jauge de flotte) était à jour ce matin encore. C'est le récit qui s'est arrêté, pas la mesure.

Ce qui a été réparé ce matin (branche garde-toponymes, 4 commits)

Le tir réel de midi : 14 pages sur 14, zéro refus

mesures/tir-reel-2026-08-11/ — les 14 communes belges du pilote (Anderlecht, Uccle, Waterloo, Kraainem…) : 14 dossiers collectés, 0 échec, 14 pages produites, 0 refusée par le garde. Le garde réparé ce matin laisse passer le français et continue de refuser l'invention.

Et pourtant : aucune de ces pages n'est publiable en l'état

Trois pages lues en entier, à l'œil ce 11/08 à 17h — le seul contrôle qui ait jamais attrapé le pire défaut du projet, et qu'aucun test ne remplace. Trois défauts visibles :

1. Le marqueur interne [à vérifier avant publication] est DANS le texte servi — il partirait en ligne tel quel.
2. La section « Nous intervenons aussi à proximité » n'est pas une liste de communes voisines, c'est le reste du lot : la page de Waterloo annonce Meise à 29,5 km. Un lecteur belge le voit immédiatement. Défaut déjà nommé le 09/08, toujours ouvert.
3. L'intro recopie la liste des quartiers que la section suivante redonne : Anderlecht énumère ses 19 quartiers deux fois. Du bourrage, et du doublon intra-page — l'inverse de l'unicité qu'on cherche.

Verdict : 14 pages produites ≠ 14 pages publiables. Le compteur dit succès, la lecture dit non.

Le cap

V1 le lundi 17/08 : les agents tournent seuls sur le parc. Pas le plugin chez les clients, pas des pages publiées — la chaîne qui se déclenche, livre, et laisse une trace où un site en échec est nommé au lieu d'être avalé en silence. Il manque exactement trois choses : un déclencheur (il n'existe aucun cron aujourd'hui), une livraison, une trace de passage. Démonstration devant David et Slim mercredi 12/08 après 14h.

Agent 8 — Facette 2 : Détection de régression (livré 2026-07-01 soir)

Ce qui a été construit : le module @oboxia/agent-8-regression compare les deux derniers SiteSnapshot persistés d'un site et signale les signaux qui ont significativement chuté, avec gravité par signal.

11 signaux surveillés avec seuils individuels :

• Note composite : −5 (à surveiller) / −10 (critique)
• 4 dimensions (technique / positions / perf / local) : −8
• GA4 conversions : −20 % (critique) ; sessions : −25 %
• Google Business : note −0,3 (critique) ; perte d'un avis (à surveiller)
• Santé technique : nouveau problème critique (critique) ; +3 avertissements (à surveiller)
• Signal absent d'un côté = ignoré (honnêteté stricte, pas de delta fantôme)

Contrat RegressionReport v1 (versionné, @oboxia/core) : tableau de RegressionSignal (signal, ancienne valeur, nouvelle valeur, delta, gravité critique/à-surveiller).

CLI regression-cli : --persist-dir, --site (filtrage), --json, --out. Isolation d'erreur par site (un site en échec ne bloque pas le reste).

Dashboard HTML « Régressions depuis le dernier scan » : tri parc par gravité descendante, sites sans historique = « pas encore de comparatif ».

Preuve E2E : fixture synthétique 2 relevés → exactement 3 critiques + 1 à surveiller (note −12, conversions −30 %, note Google −0,4, avis perdu). JSON + dashboard produits.

Qualité : design brainstorm → spec → plan → 4 tâches TDD + revue adversariale par tâche + revue finale Opus (« Ready to merge »). 446 tests verts (était 429), typecheck 0. 6 commits abf66ad → 136b8961.

Dette résiduelle loggée :

1. Testé sur fixtures uniquement — aucune donnée réelle accumulée (1re vraie valeur quand la persistance snapshot aura tourné ≥ 2× sur le parc)
2. buildSnapshot.health non peuplé en amont → signaux régression-santé (newCriticalHealth / moreSanteWarnings) inertes jusqu'au câblage de ce champ
3. Regex sanitisation site→fichier dupliquée en 3 endroits (à centraliser dans @oboxia/core)
4. Moyenne glissante / baseline / push Telegram = hors v1

Agent 8 — santé technique livrée : 8 checks, dashboard parc, preuve réelle

Construit cette session en 14 commits (6161cb6 → 051a0dd) : nouveau package @oboxia/agent-8-sante. 429 tests verts (était 403 au démarrage), typecheck 0.

Les 8 checks du contrat SiteHealth v1

1. pageDown — page injoignable (HTTP 5xx/timeout)
2. httpsExpired — certificat HTTPS expiré
3. noindex — balise meta noindex ou en-tête X-Robots-Tag: noindex (les deux sources)
4. brokenInternalLinks — liens internes cassés
5. brokenExternalLinks — liens externes cassés (avec retry)
6. brokenImages — images cassées
7. missingLocalBusinessSchema — JSON-LD LocalBusiness absent ; reconnaît les sous-types (Plombier/Électricien/etc.) — schémas partagés avec Agent 5 via @oboxia/core pour éliminer toute divergence inter-agents
8. missingTags — balises manquantes (title / H1 / meta description)

Chaque problème porte une sévérité (critique / avertissement) et un « qui répare » (Correcteur auto / humain / ops). Contrat versionné SiteHealth v1 dans @oboxia/core avec verrou registre mécanique.

CLI health-cli : flags --site, --json, --out, --persist-dir. Flux complet : découverte sitemap → scan parallèle borné → dashboard HTML « Santé du parc » → historique JSONL.

Qualité

6 tâches TDD + revue par tâche + revue finale Opus (verdict « Ready to merge ») → 4 corrections post-revue : (1) sous-types schema partagés Agent 5/8 (divergence éliminée), (2) détection X-Robots-Tag, (3) parallélisation bornée des checks, (4) persistance + lien Correcteur dans le registre.

Preuve réelle bout-en-bout

• ouadi-plomberie.fr — 20 pages, 167 s → 0 critique, 22 avertissements (20 LocalBusiness absent, 1 lien interne cassé, 1 balise manquante)
• mp-solution.fr — 16 pages → 16 LocalBusiness absent + 16 images signalées (spot-check CDN recommandé avant présentation client)

Constat LocalBusiness recoupé avec l'audit Agent 5 sur ces deux sites : deux agents, même constat → cohérence inter-agents confirmée.

Dette résiduelle loggée (non bloquante)

• Images sans retry → spot-check curl -I conseillé sur les 16 de mp-solution (faux positif CDN possible si le CDN filtre notre user-agent)
• hasLocalBusinessSchema en JSON.parse strict → un JSON-LD malformé compterait comme absent (risque faible)
• Retry 429 sans back-off exponentiel
• Champ jsonLdTypes désormais inutilisé dans Agent 8
• Reste Agent 8 = alertes sur régression des signaux dans le temps (facette « suivi continu », todo)

Session du 29-30/06 centrée sur le risque doorway/duplicate et l'outillage de pilotage.

Recalibration doorway DANS l'audit (3 bugs corrigés)

L'analyse de tout le parc (30 sites) a révélé 3 défauts de analyzeLocalSpecificity, tous corrigés en TDD :

• Multiville fiable : multiCity était codé en dur (tout site ≥2 pages = « multiville »). Désormais calculé depuis les villes distinctes dérivées (+ stoplist anti faux-positifs /contact, /tarifs…). Un mono-site n'est plus flaggé doorway.
• Verdict recalibré : ville-masquée ≥ 95% → 🔴 d'office (vmcouvreur, 100% identique après masquage, était classé 🟡 « faible » à cause d'une densité bernée). Densité effective = 0 quand les faits locaux sont identiques partout. Fixture réelle pages-vmcouvreur.json.
• Rapport actionnable : nouveaux blocs « Pour passer au vert » (cible chiffrée : gabarit < 50 % ET ville-masquée < 60 %) + « Pour mieux ranker » (GBP, preuve locale, couches data). 374 tests verts.

Juge LLM B-2 câblé (--judge-llm)

attachDoorwayJudgment + flag opt-in --judge-llm : le juge IA est appelé sur la bande grise et son verdict affiché (expérimental, hors note tant que non validé au gold-set). Contrat DoorwayJudgment + section HTML.

Analyse du parc + outillage

• Triage de 30 sites : seulement 6 vrais multivilles (≠ 30 « multiville » du flag cassé) ; 2 en 🔴 (texte ~100% copié : vmcouvreur, charpentier-couvreur-morbihan). Reco page-par-page produite sur vmcouvreur (titres spinés, JSON-LD LocalBusiness absent, 4 numéros de tél, pages démo WordPress non supprimées).
• Outils : doorway-risk-cli.ts (scan rapide), classify-multiville.py (slug↔commune).

Stratégie (council « ligne doorway »)

Council : le multiville pur plafonne ~65-70, viser « 90 interne » est la mauvaise cible ; le vrai juge = clics/CTR GSC réels ; levier de ranking = fiche Google (GBP) par artisan. Objectif produit recadré (Naouphel) : ne pas être pénalisé (doorway) + rester positionné. Doorway ≠ duplicate.

Pilotage

• Canal Telegram d'équipe câblé (groupe « Canal dev oboxia ») → remplace le WhatsApp/CallMeBot mort ; Slim + David voient les jalons.
• Hook timebox automatique + horodatage injectés à chaque tour.
• Avancement : Agent 5 = 89%, global build 22%. Tout sur master, poussé sur GitHub privé.

Grosse session de fondations : on a posé le mécanisme anti-recodage du council (séquencer par gels de contrats, pas par agents), produit 3 pilotes réels et construit la dernière brique d'Agent 5.

Infrastructure de contrats (council [1] → [3])

• GA4 : contrat Ga4Report + adaptateur fake/real (miroir de GSC), touch réel sur la property 543343310 → signal de conversion disponible.
• Contrat Correctif (Agent 5 → Correcteur) versionné + test-gate mécanique : il casse si la sortie d'Agent 5 dérive du schéma d'entrée du Correcteur (mutation-prouvé). C'est la « première chose à faire » du council.
• Contrat SiteSnapshot (entrée Agent 8) versionné + persistance JSONL horodatée.
• Registre de contrats (CONTRACT_VERSIONS) = source unique des versions + verrou de bump (tout changement de version casse un test = décision consciente) + harness d'intégration extensible. Le gel mécanique est généralisé : aucun contrat inter-agents ne peut dériver en silence.

3 pilotes Agent 5 publiés (preuve de valeur)

Trois recos réelles, contrastées, prêtes pour le go/no-go de Slim :

• Maison Brielle (commerce) — note 71/100, fiche Google réelle (11 avis 5/5), quick-win « saucisson aux tomates séchées ».
• MP Solution (artisan multiville) — note 63/100, doorway mis en évidence (72 % de gabarit dupliqué, le différenciateur).
• Sangaré Avocat (profession libérale) — note 52/100, annuaires métier (Doctrine/Justifit/Avocat.fr) + NAP en vrac (6 numéros de tél).

B-2 — juge sémantique anti-doorway (scaffold)

Couture du juge LLM : contrat DoorwayJudgment + adaptateur fake/real (OpenAI, modèle fort) + escalade uniquement sur la bande grise du déterministe. Run réel non exercé, validation en attente du gold-set de Slim (honnête : juge non mesuré tant que pas étiqueté).

Avancement (ancré, pas au doigt mouillé)

• Global build = 22 % (Agent 8 → 33 %, Correcteur → 50 %, Agent 5 → 94 % avec B-2 couture faite / validation todo).
• 361 tests verts, typecheck 0. Tout sur master.
• Outillage de suivi durci : jalon.sh (sync unique cockpit + journal), bandeau « Dernier jalon », fleet ré-ancré. (Le WhatsApp de jalon est mort — quota épuisé — remplacé par le bandeau du journal.)

Facteur limitant désormais = Slim : go/no-go sur les 3 pilotes + étiquetage du gold-set (débloque la validation B-2).

Nouvel agent dans la flotte : l'Agent Veille SEO. L'usine passe de 10 à 11 agents.

En travaillant sur la dimension Local, un besoin a émergé clairement : le SEO bouge (Google change ses règles, les bonnes pratiques évoluent). Un audit n'a de valeur que si le rulepack (notre base de règles notées 🔴/🟠/⚪) reste à jour. D'où un 11ᵉ agent : la Veille SEO.

Son rôle (à cadrer) : surveiller l'évolution des règles et bonnes pratiques SEO (Google + sources fiables) et maintenir le rulepack à jour — sans bruit ni faux signaux. C'est ce qui empêche l'outil de donner, dans 6 mois, des recommandations périmées.

Statut : parké en to-do (brainstorming → spec → build plus tard). Pas encore commencé.

Conséquence honnête sur le suivi : ajouter un vrai agent au décompte fait baisser l'avancement global, pas monter. Le fleet.json passe de 8 → 8 agents scope-build ? Non : de 7 → 8 (la veille rejoint a1/a5/a7/a8/a9/a10/Correcteur). Donc le global build a légèrement baissé ce jour-là (un agent de plus à 0 % dilue la moyenne). C'est volontaire : on compte le travail à faire, on ne le cache pas. (Chiffres de l'époque retirés pour éviter toute confusion avec l'avancement courant, affiché en haut de page.)

Rappel décompte : usine = 11 agents (10 du projet.md + veille). Les agents 2/3/6 (constructeur multiville) existent déjà via le plugin Obox-Multiville → « ce qu'on build » = 8 agents.

La dimension local capte maintenant la fiche Google Business (avis + NAP-fiche), via l'API Places.

Suite à tes réponses : tu es admin des fiches, OK pour lire le public, et ton signal n°1 = la fiche qui ranke sur les mots-clés (pack local) + le nombre d'avis. On a livré la brique « avis + cohérence fiche », le pack local arrive juste après (cf. plus bas).

Ce qui est construit (déterministe, lecture seule, testé sur fakePlacesClient — le réseau réel se branche dès la clé Maps créée) :

• Adaptateur PlacesClient (fake/real, miroir de GSC). real = Text Search + Place Details, derrière une clé Maps à créer côté GCP (prérequis ops).
• Résolution de fiche vérifiée (place-resolve) : on relie un client à SA fiche seulement si (téléphone OU domaine identique) ET ville cohérente → couvre le piège des franchises au même domaine. Sinon « fiche non identifiée » (jamais la mauvaise fiche, jamais de fausse note). Tu peux fournir un Place ID pour les cas ambigus.
• Score avis = qualité mène le volume (gbpScore) : un 5/5 sur 8 avis = 80 (la qualité compense le faible volume), un 3/5 sur 60 avis = 60 — fini les paliers absolus indéfendables en RDV. Les chiffres bruts « N avis, X/5 » sont toujours affichés. NAP site≠fiche → signal rouge (ton levier vs le prestataire).
• Persistance horodatée des lectures (fondation du suivi d'avis dans le temps + alertes — Agent 8).
• La dimension local = 0,55 on-site + 0,45 fiche Google ; son poids dans la note globale monte de .15 à .20. Mention explicite « présence sur Maps : à venir » (on ne promet pas un rang instable).

Conception relue par un conseil LLM (qui a corrigé un bug d'unité dans le scoring des avis + durci la vérif géo + rééquilibré le poids), puis bâtie en 6 tâches TDD avec revue adversariale par tâche : 254 tests.

Reste : créer la clé Maps (toi/nous, ~15 min GCP) pour activer le réel, puis le pack local (ta priorité n°1) en sous-piste suivante.

Une 4ᵉ note rejoint le composite : « Cohérence locale (on-site) ».

Jusqu'ici la note Agent 5 = 3 dimensions (technique / positions / performance). Pour des PME locales, il manquait le volet local. On ajoute une 4ᵉ dimension local (poids 0,15), mesurée depuis le crawl, zéro dépendance externe, lecture seule :

• Schema LocalBusiness (0,40) : complétude de la fiche d'identité structurée (JSON-LD) — parsing robuste (@graph, @type en tableau, sous-types Dentist/Restaurant…, address imbriquée ou string).
• Cohérence NAP téléphone (0,30) : même numéro partout + numéro affiché == numéro de la fiche. Aucun téléphone = malus (pas neutralisé). Multi-numéros légitimes (standard/mobile/fax) non pénalisés ; mono-page sans crédit gratuit.
• Marqueurs locaux visibles (0,30) : code postal + horaires dans le contenu (couche visible, distincte du structuré → pas de double-comptage).

Bonus actionnable : un générateur de bloc JSON-LD prêt-à-coller (« voici le code à mettre »), avec À COMPLÉTER sur les champs manquants — jamais de valeur inventée.

Nom honnête : la note s'appelle « Cohérence locale (on-site) » avec un disclaimer « hors Google Business & avis » (la fiche Google + les avis = incrément 2, en attente de tes réponses sur l'accès aux données).

Sur Maison Brielle (fixture 1-page) : local 30/100 (fiche absente + téléphone introuvable → 2 signaux rouges honnêtes), ce qui fait passer l'overall de 68 à 62 — la note descend parce qu'elle dit enfin la vérité locale.

Conception relue par un conseil LLM (rééquilibrage, malus tél-absent, anti-double-compte) puis construite en 6 tâches TDD avec revue adversariale par tâche : 233 tests, 2 bugs importants attrapés + corrigés avant merge.

Le seul angle où le prestataire nous battait — le « plan d'action narratif » — est comblé.

Jusqu'ici, le rapport listait les recommandations à plat (🔴🟠🚀). Le prestataire, lui, écrivait un récit « Axe A / B / C » qui se lit bien côté client. On a tranché le comment avec un conseil LLM (5 avis + relectures) : génération déterministe, pas de LLM en bout de chaîne — parce que notre force, c'est que chaque phrase est sourcée sur une donnée mesurée, et qu'un LLM qui « reformule » risque de réintroduire le flou invérifiable qu'on reproche au prestataire.

Ce qui est livré :

• Un module pur buildActionPlan(report) qui réorganise les constats déjà calculés en 3 axes-trajectoire : A — Stopper l'hémorragie (dimension la plus faible + correctifs imposés), B — Conquête commerciale (quick-wins dé-bruités de la marque + % de trafic de marque), C — Sécuriser & mesurer (doorway/spécificité locale + tendance). Un axe sans donnée porteuse est omis (pas de remplissage creux).
• Deux rendus : HTML (récit en tête + preuve repliable <details> par axe, déplié à l'impression PDF) et Markdown. L'ancienne liste à plat est remplacée.
• Un garde-fou (test) : tout chiffre d'un paragraphe doit tracer vers un champ du rapport — impossible d'halluciner un nombre.

Exemple réel (Maison Brielle) : « Votre trafic est à 100 % de votre nom de marque… la croissance vient de 1 requête commerciale (saucisson aux noisettes, position 17) à pousser en page 1. » Le récit du prestataire, mais honnête et vérifiable.

Qualité : 8 tâches en TDD (sous-agent + revue adversariale par tâche, en worktree isolé), 214 tests verts, typecheck 0, revue finale = 0 bug bloquant. Fixtures réelles uniquement (Brielle + Degalet pour le cas doorway).

✅ Fait cette session

• Agent 5 complet : audit on-page honnête + note composite 3 dimensions (technique / positions / performance) + reporting client + couche features spécificité locale. 115 tests verts, typecheck 0.
• Template rapport HTML/PDF réutilisable (graphes SVG : donut marque, barres de note).
• Go/no-go Brielle assemblé (rapport + duel vs partenaire) → GO de Slim obtenu.
• Pipeline LIVE prouvé : report-cli --live (real crawl accueil + real GSC 6 mois), tourné en vrai sur Ostéopathe Sicot (1er essai, 557 clics / 9 365 impressions / pos 5,7). Rapport publié : https://oboxia.taraji-conseil.fr/r/eb14fcd2b14b0317/
• Décision : rapports = HTML-first + script publish-report.sh (publication en 1 commande).
• Journal de dev en double lecture David/Slim publié.
• Mécaniques : kanban.md, hook conventions (Kanban + scan skill + WhatsApp attendu réel), canal WhatsApp réactivé.
• Specs écrites : tranche 1 live + amélioration reco n°1 (recos actionnables).

🔄 En cours

Industrialisation : tranche 1 live faite ; suite = tendance 6 mois + batch 43.

📋 Feuille de route + estimations

Cadrage global : cœur de valeur (recos n°1 + tendance + batch + dimension locale) ≈ 1–2 semaines → produit vendable solide. Puis off-page + B-2 + Agent 8 ≈ 2–4 semaines de plus. Correcteur + salle de commandement = sous-projets ultérieurs. Facteur limitant = priorisation Slim + données externes (off-page/SERP), pas le code.

🗺️ Carte de la flotte OBOXIA

graph TD
  classDef done fill:#2d7a2d,color:#fff,stroke:#1a5c1a
  classDef wip fill:#c07a00,color:#fff,stroke:#8a5800
  classDef todo fill:#555,color:#ccc,stroke:#333
  classDef external fill:#2255aa,color:#fff,stroke:#14378a
  classDef future fill:#444,color:#aaa,stroke:#333,stroke-dasharray:5 5

  subgraph Sources["Sources de données"]
    GSC["Google Search Console"]:::done
    GA4["Google Analytics 4"]:::done
    CRAWL["Crawl on-page"]:::done
  end

  subgraph Colonne["Colonne de données (fondation)"]
    SOCLE["Socle commun / adaptateurs"]:::wip
  end

  GSC --> SOCLE
  GA4 --> SOCLE
  CRAWL --> SOCLE

  SOCLE --> A5

  subgraph Flotte["Flotte — 10 agents"]
    A1["Agent 1 — Analyse du brief"]:::todo
    A236["Agents 2·3·6 — Générateur multi-ville"]:::external
    A4["Agent 4 — Figma-to-code (Slim)"]:::external
    A5["Agent 5 — Audit SEO + note composite + recos ⭐"]:::wip
    A7["Agent 7 — GEO"]:::todo
    A8["Agent 8 — Suivi / alertes"]:::future
    A9["Agent 9 — Bilan client"]:::todo
    A10["Agent 10 — Contrôle pré-vol"]:::todo
    CORR["Agent Correcteur (écrit dans WP, D4)"]:::future
  end

  A5 --> RAPPORT["Rapport HTML publié\n(ex. Ostéopathe Sicot)"]:::done
  A5 -.->|future| CORR
  A5 -.->|future| A8

  subgraph CMD["Salle de commandement (D5) — orchestration des 10 agents"]
    SALLE["Interface + orchestrateur (VoltAgent candidat)"]:::future
  end

  SALLE -.-> A1
  SALLE -.-> A5
  SALLE -.-> A8
  SALLE -.-> A9
  SALLE -.-> A10
  SALLE -.-> CORR

Légende : ■ fait · ■ en cours · ■ à venir · ■ externe (existe) · ■ futur / pointillé

Council — quel LLM pour le moteur de jugement (B-2)

Date : 2026-06-24. Conseil (5 advisors + 3 relectures) sur le choix LLM pour le jugement sémantique « local réel vs spinning ».

Verdict

• Écarter Ollama (contenu public → zéro bénéfice privé ; 8 Go sans GPU → trop faible) et Gemini (clé pour rien).
• Architecture, pas un modèle : (1) features déterministes d'abord (NAP, densité géo inter-pages, boilerplate) — ~80 % des verdicts, coût nul, bat déjà le Jaccard ; (2) gpt-4o-mini (clé Slim) = tri + plomberie ; (3) Claude Sonnet = JUGE sur le résiduel (nouvelle clé Anthropic, centimes).
• gpt-4o-mini JAMAIS juge final : il est lui-même un moteur de spinning → validerait Degalet.
• Abonnement ≠ clé API : Claude Max ne s'appelle pas en runtime ; le juge = clé Anthropic facturée.

Angles morts attrapés

• Le RUBRIC manque : définir « réellement local » (faits requis) AVANT d'étiqueter — sinon le gold set est inétiquetable.
• Gold set : 20-50 pages-villes étiquetées par Slim + accord inter-annotateur.
• Contrat adaptateur : entrée features+pages-sœurs ; sortie verdict+score+citation ; mode dégradé ; drift des spinners (juge réévalué).
• Volume jamais chiffré (43 sites × N villes).

Ce que ça débloque

La couche features est déterministe → codable MAINTENANT, sans la clé OpenAI ni Slim, et améliore déjà sur le Jaccard (cas Degalet). → slice 1 de B-2 lancé. Rubric+gold set (Slim) et juge Claude (nouvelle clé) viennent après.

Agent 5 complet + HONNÊTE — chaîne perf → composite → reporting

Date : 2026-06-24 (nuit). L'Agent 5 produit désormais un rapport client de bout en bout, sur données réelles, et honnête (c'est le différenciateur vs le partenaire). 5 commits, 97 tests verts, typecheck 0.

Construit ce soir

• Dimension perf GSC : adaptateur gsc (fake/real via service account), analyzePerformance (totals, quick-wins, brandShare, top requêtes).
• Note composite : computeComposite — technique + positions + performance, pondérée et re-normalisée, transparente.
• Reporting client : renderReportMarkdown — 6 sections (synthèse, perf, le vrai constat, opportunités, technique, recos prioritaires).
• Refinements honnêteté (marque) : pénalité part-de-marché sur le perf-score + filtre du bruit-marque sur les quick-wins.

Avant / après (Maison Brielle) — l'agent devient juste

→ Là où le partenaire écrivait « résultats encourageants », l'agent dit 67 + le seul vrai levier. C'est ça, battre le partenaire.

Reste

B-incrément-2 (vérif sémantique/locale, LLM — Context7 posé) = le gros différenciateur ; Agent 8 (suivi) ; Correcteur (D4, WP REST direct) ; salle de commandement (D5/VoltAgent).

Repo : 5 commits (baseline→perf→composite→reporting→honnêteté). Reprise : handoff.md.

Balayage MCP utiles au dev OBOXIA — décision

Date : 2026-06-24. Sweep des serveurs MCP utiles au dev (hors connecteurs déjà possédés). Principe unificateur qui ressort (cohérent avec la décision Lighthouse) : le MCP sert la couche assistant/dev + orchestration ; le runtime des agents reste en lib/CLI directe.

Tableau

Les 3 à mettre en place en premier (réalisé pour NOTRE état actuel)

1. Context7 — utile immédiatement (on code les briques 1-2), zéro surface de sécu.
2. GitHub MCP — dès qu'oboxia a un repo git + un remote.
3. Postgres MCP (read-only) — quand la colonne de données aura une vraie base.

Sécurité

WordPress (écrit sur sites clients) + Playwright/crawl sur sites clients = surfaces sensibles → credentials dédiés par client, droits minimaux, self-host pour ne rien exfiltrer, jamais de delete activé côté Correcteur.

Sources : github.com/upstash/context7 · github/github-mcp-server · crystaldba/postgres-mcp · microsoft/playwright-mcp · unclecode/crawl4ai · docdyhr/mcp-wordpress · WordPress/mcp-adapter.

Décision — outils SEO MCP : intégrer vs construire

Date : 2026-06-24. Évaluation des serveurs MCP SEO de mcpmarket (sources réelles : repos GitHub) pour ancrer le « build vs intégrer » sur la dimension technique de l'Agent 5.

Verdict

Décisions

1. Lighthouse → intégrer via la lib lighthouse npm en direct (adaptateur agent-5/adapters/lighthouse.ts), PAS le wrapper MCP. CWV = commodité, mais c'est du diagnostic lab, pas un verdict de ranking (verdict = champ/CrUX).
2. Crawler 28-règles → NON intégré (cosmétique, fragile, pas de rendu JS). Recopier sa liste de règles (Apache-2.0) dans le rulepack comme checklist (canonical, orphelines, redirect chains, headers sécu), codées par nous.
3. Différenciateur (sémantique/local, note composite, recos actionnables) → 100% en propre, aucun MCP ne le couvre.
4. Forme : libs npm directes dans des adaptateurs (agents CLI déterministes) ; MCP réservé à la salle de commandement / VoltAgent.
5. Ahrefs / DataForSEO (payants) → différés (gaps netlinking/SERP, hors priorité build-1).

Principe ancré

Commodité technique = intégrer/recopier l'existant. Différenciateur (jugement) = construire. Cohérent avec le cap « co-pilote de jugement » et le constat Degalet (le Jaccard/comptage ne bat pas le partenaire ; le jugement sémantique/local, oui).

Sources : github.com/danielsogl/lighthouse-mcp-server · github.com/houtini-ai/seo-crawler-mcp

Clôture session 2026-06-24 + planning

Ce qui a été accompli ce soir

• Socle @oboxia/core construit (cli-runner, contrats Zod, validate, journal, reject-queue).
• Agent 5 audit SEO : on-page honnête + enrichi (thin-content, schema LocalBusiness via JSON-LD réel, NAP téléphone), recos site-spécifiques (hard-code éliminé + test garde-fou), doorway/unicité. 49 tests verts, typecheck 0 erreur.
• Probe GSC réussi (accès Search Console via service account Myobox prouvé) — clé dans .secrets/.
• Conformité SEO vérifiée contre les livres du Drive : rien d'inventé ; cosmétique vs vraie valeur identifiés.
• Insight clé : le détecteur doorway par Jaccard est insuffisant (pages Obox Degalet = spinning sans spécificité locale, passent à 0.751). → le vrai différenciateur = vérif sémantique/locale (B-incrément-2).
• Mécanisations : journal HTML, kanban synchro, journal de décisions, hook conventions (mini-CR + timebox + réel-vs-estimé), bash auto-approuvé, infra WhatsApp (CallMeBot, dormante), RTK confirmé (75 % d'économie).

Calibration de mes estimations (réel vs estimé)

• Audit multi-ville Degalet : estimé 12 min → réel 2,2 min (×5 trop haut).
• Hygiène extract/typecheck : estimé 8 min → réel 3 min (×2,7 trop haut).
• Leçon : je sur-estime le temps-horloge des sous-agents ; je corrige à la baisse.

Planning des jours à venir (résumé)

Préalables : décision accès LLM (→ B-2), init git oboxia, Slim (5-10 recos partenaire pour le banc d'essai), clé CallMeBot.

• Jalon A (non bloqué) : init git + dimension perf GSC empilée sur l'agent.
• Jalon B [dépend LLM] : vérif sémantique/locale — le différenciateur qui attrape le cas Degalet.
• Jalon C [dépend Slim] : note composite + banc d'essai jugement = GO/NO-GO.
• Après GO : reporting (remplace le partenaire), Agent 8 (suivi), Correcteur (D4, dernier), salle de commandement (D5).

Détail complet : oboxia/planning.md. Reprise technique : oboxia/handoff.md.

CR — Test probant Agent 5 sur multi-ville réel (Degalet/Obox)

Date : 2026-06-24 (soir). Estimé ~12 min · réel ~2,2 min (sur-estimation ~5×).

Résultat brut

4 pages-villes de charpentier-couvreur-morbihan.fr (racine/Vannes, arradon, arzon, auray), HTTP 200. Agent 5 → score 100, 0 issue. uniqueness : multiCity:true, maxSimilarity 0.751, doorwayRisk:"none" (seuils 0.8/0.9). Toutes les règles-à-valeur (thin/schema/NAP) restent muettes → contenu mécaniquement sain.

Le vrai constat (le plus important)

La différenciation Obox = synonym spinning, pas du contenu local réel :

• Title/H1/méta 100 % templatés (seuls ville + CP varient).
• Corps = blocs identiques (devis, services) + paragraphes reformulés (même sens, phrases différentes).
• Zéro spécificité locale (pas de quartier/chantier/particularité de commune).
• Le Jaccard 0.751 passe car la reformulation baisse la similarité lexicale — mais c'est exactement le profil doorway qu'un humain/Google flaggerait en jugement qualitatif.

Conséquence projet

Le détecteur doorway par Jaccard est insuffisant (la conformité l'avait pressenti). Le levier pour battre le partenaire = vérif de spécificité locale / sémantique (= B-incrément-2, cohérence sémantique, différé). Ce test le prouve sur cas réel.

Bug trouvé

extract.ts : decodeEntities ne décode pas les entités d'accents FR (é…) → tokenisation parasitée. Pré-existant, sans impact sur ce verdict (gonfle légèrement la similarité → verdict "none" conservateur-safe). À corriger pour une mesure fine.

Fichiers

fixtures/agent-5/pages-degalet-multiville.json, scripts/capture-degalet.mjs, .work/seo_report_degalet.json.

CR — Build socle + Agent 5 + audit multi-sites

Compte-rendu factuel de la session de build : socle commun, Jalon 1 de l'Agent 5, audit multi-sites, et un bug détecté qui invalide le Jalon 1.

Socle commun — ✅ 8/8 tests

Le socle (core) est en place et vert : 8 tests sur 8 passent (cli-runner, contrats Zod, validate, journal, reject-queue). Fondation stable pour brancher les agents.

Agent 5 — Jalon 1 (annoncé)

• Produit un seo_report.json sur un site réel.
• Site de référence : Maison Brielle → score 87.
• Le rapport sort des correctifs proposés (lecture seule, l'agent n'écrit jamais).

Audit multi-sites — 5 sites

• Fourchette de scores : 87 à 94.
• Les détections fonctionnent sur l'ensemble des 5 sites.

🐛 Bug bloquant — hard-code des recommandations

Détecté : les recommandations sont hard-codées. Les citations propres à Maison Brielle fuient sur les autres sites — autrement dit, les correctifs « concrets » affichés sur les autres sites reprennent des éléments de Maison Brielle au lieu d'être tirés des vraies valeurs de chaque page.

➡️ Conséquence : le Jalon 1 n'est PAS réellement atteint. L'actionnabilité site-spécifique (le différenciateur make-or-break, faiblesse #1 du partenaire) n'est pas prouvée tant que les recos ne sont pas dérivées des signaux mesurés de chaque page. Le score sort, mais la reco ne tient pas.

Probe GSC — ✅ réussi

Le probe GSC (script-sonde de dérisquage) a réussi : l'accès aux données Google Search Console est validé sur le réel — un JSON GSC s'affiche. Le risque d'accès données (scopes / quotas / mapping de propriété) est levé.

Verdict

• Socle : solide (8/8).
• Accès données : dérisqué (probe GSC OK).
• Agent 5 : Jalon 1 à reprendre — corriger le hard-code des recos (les dériver des vraies valeurs de page) + ajouter un test garde-fou, avant de pouvoir déclarer le Jalon 1 réellement atteint.

CR — Agent 5 B-incrément-1 (réalignement + valeur SEO)

Date réelle : 2026-06-24 (soir). Résultat : 45 tests verts (était 25/12), 100% vert.

Ce qui a été fait

1. Fix hard-code des recommandations : les recos sont désormais construites depuis les vraies valeurs de page (page.title, page.h1, longueurs réelles). Test garde-fou no-hardcode.test.ts sur 2 fixtures (Brielle + Sangaré). Anti-fuite vérifié par grep : 0 occurrence des chaînes Maison Brielle sur les 4 autres sites.
2. Réalignement des sévérités sur la spec : H1 ≠ 1 → convention (Google tolère plusieurs H1) ; longueur title/méta : pénalité « trop court » retirée (seulement > 60 / > 160).
3. Contrôles à vraie valeur ajoutés (sourcés rulepack) : thin-content (< 300 mots), schema-localbusiness-missing (D.1 🔴, via extraction JSON-LD), nap-phone-missing (D.2 🔴). jsonLdTypes ajouté au contrat PageData (rétro-compatible).
4. 5 fixtures réelles re-capturées avec jsonLdTypes réels.

Tableau multi-sites (données réelles)

Nuance honnête (valeur probante)

Les 5 sites sont tous bien construits → les règles thin/schema/nap ne se déclenchent pas (vrais négatifs). Validées par tests unitaires sur entrées contrôlées. Pour prouver leur valeur sur le terrain, les lancer sur des sites faibles / pages multi-ville Obox.

Gap

pnpm typecheck échoue (@types/node absent) — pré-existant, à nettoyer.

Fichiers

Modifiés : packages/core/src/contracts/page-data.ts, packages/agent-5-audit-seo/src/rulepack.ts, adapters/crawler.ts, tests. Créés : adapters/extract.ts, test/{no-hardcode,extract}.test.ts, scripts/capture-fixtures.mjs. Aucun commit git.

OBOXIA — Journal de décisions

Contrôle de cohérence (niveau b choisi le 2026-06-24). Chaque décision : date · libellé · statut. Statuts : validé (par Naouphel) · auto (appliqué par Claude, bookkeeping/faible risque) · proposé (en attente) · différé. Règle associée : si une demande contredit une décision verrouillée du CLAUDE.md, Claude s'arrête et le signale au lieu d'appliquer.

OBOXIA — Conformité SEO de l'Agent 5 vs livres de référence (2026-06-24)

Vérification source-of-truth (demande Naouphel) : les règles de l'Agent 5 sont-elles conformes aux livres SEO du Drive, ou hors-piste ? Croisement 3 niveaux : livres Drive (« OBOXIA - SEO », id 12U8jf7peum0FHRZZzrgIFIP-K5RRQ2DA) ↔ base de référence (docs/superpowers/specs/oboxia-seo-rulepack.md) ↔ code réel (oboxia/packages/agent-5-audit-seo/src/{rulepack,uniqueness,score}.ts).

Ce que disent (et ne disent pas) les livres

• 50-Step Technical SEO Checklist : robots/sitemap/HTTPS, canonical, contenu dupliqué (step 11), thin content (step 12), JSON-LD, liens internes, click depth. N'évoque NI longueur title, NI longueur méta, NI nombre de H1, NI SEO local géo.
• SEO Best Practices 2026 : search intent > keywords (pilier #1), EEAT, NAP consistency (entity SEO), schema, « éviter les patterns de contenu templaté » (soutient l'anti-doorway). Aucune borne chiffrée title/méta/H1.
• State of SEO 2026 : enquête d'industrie (AI Overviews…), aucune mécanique on-page.

➡️ Aucun livre ne fixe de seuil chiffré title (50-60), méta (150-160) ou H1. Ce sont des conventions d'outils, pas des règles Google.

Tableau de conformité

Propositions d'enrichissement — vérdict des livres

• A. Mot-clé géo dans title/H1/méta → À NUANCER : faiblement soutenu, frôle le keyword-stuffing déconseillé par Best Practices. Le vrai levier local = NAP + GBP + LocalBusiness schema (déjà 🔴 dans le rulepack.md, section D). Préférer D.2 (NAP) au géo-dans-le-title.
• B. H1 parasités par pages légales → À NUANCER : vrai défaut technique (fuite de gabarit), mais cas particulier de la règle H1, à classer ⚪/🟠.
• C. Cohérence sémantique title↔H1↔intention → DANS LES CLOUS : pilier #1 de Best Practices 2026. Le mieux sourcé ; déplace l'agent du comptage vers le jugement = le différenciant visé. Classer 🟠.

Écarts code ↔ base de référence (à corriger)

1. H1 : rulepack.md = « ⚪ conseil, pas erreur » ; code = recommande −7. Réaligner ⚪/−3.
2. Title/méta trop court : esprit du doc = anti-troncature (donc trop-long seulement) ; code pénalise aussi trop-court. Retirer.
3. Doorway : doc = multi-signaux + « aucun seuil chiffré » + jugement humain ; code = Jaccard unique + seuils figés sans mention d'incertitude. Enrichir ou reporter l'incertitude.
4. Non implémenté alors que dans le doc (souvent 🔴) : SEO local (NAP D.2, LocalBusiness D.1), thin content (step 12), robots/sitemap/canonical, alt images, JSON-LD. Le code ne couvre que 5 contrôles cosmétiques.

Synthèse — où est la vraie valeur

Pinaillage cosmétique (faible valeur, non sourcé) : longueurs title/méta (surtout trop-court), H1=1 à −7, le barème. Vraie valeur SEO (sourcée) : title/méta présents ; doorway/dupliqué (politique 🔴, à enrichir multi-signaux) ; SEO local non codé (NAP, LocalBusiness, thin content) = là où est la valeur métier OBOXIA et où l'agent est muet ; cohérence sémantique (proposition C).

Verdict global : rien d'inventé de toxique, mais l'agent actuel est cosmétique + sur-classe le H1 + sous-implémente le doorway + n'a pas codé la partie à plus forte valeur (local). Le oboxia-seo-rulepack.md est rigoureux et honnête ; le code doit s'y réaligner.

Plan de réalignement (grounded dans les livres)

1. Fix hard-code des recos (vraies valeurs de page) + test garde-fou.
2. Réaligner aux étiquettes : H1 → ⚪/−3 ; retirer pénalité « trop court » title/méta ; doorway = reporter l'incertitude (1 signal).
3. Ajouter la vraie valeur (sourcée) : NAP consistency, présence schema LocalBusiness, thin content (comptage mots), cohérence sémantique title↔H1↔intention.
4. Démoter/garder en faible poids les contrôles cosmétiques.

OBOXIA — État d'étape (2026-06-24)

Point charnière. Document de référence stratégique : objectif visé → ce qui est fait → ce qui reste → découpage temporel → dépendances/blocages. (Complète handoff.md qui est l'état de reprise technique.)

1. L'objectif visé (à quoi tout ça répond)

Co-pilote de jugement SEO scalable. ⚠️ On quitte le partenaire parce que son travail est jugé INSATISFAISANT → il est un plancher à battre, pas une cible à reproduire. L'objectif : produire des recommandations SEO que Slim juge meilleures que celles du partenaire, à la chaîne, Slim gardant la main sur la décision finale.

Définition du succès (la seule qui compte au départ) : UNE recommandation, sur UN site, que Slim approuve sans la retoucher. Pas 43 sites, pas la note composite complète, pas un dashboard temps réel. Tant qu'on n'a pas ça, le reste est théorique.

Pourquoi maintenant : la chaîne de valeur est déjà à portée — données Google accessibles (service account Myobox sur GSC+GA4 de chaque client), parc de 43 sites réels, livrables partenaire connus (2 rapports lus). Le risque n'est pas technique, il est de construire un truc que Slim n'utilise pas ou de ne pas faire mieux que le partenaire.

1bis. Le barème à battre (les 4 faiblesses du partenaire → 4 différenciateurs)

Naouphel juge le partenaire insatisfaisant sur les 4 axes. Chacun mappe une couche de l'archi — c'est ce qui valide le design :

Nuance sur Agent 8 : le council avait déclassé le « temps réel » comme faux différenciant. La faiblesse #4 le re-valide partiellement : ce n'est pas du live seconde-par-seconde (le SEO bouge en semaines), mais une surveillance qui rattrape les chutes que le partenaire rate entre deux rapports périodiques. Différenciant réel = réactivité, pas fréquence d'affichage.

Conséquence n°1 : le différenciateur make-or-break est l'actionnabilité (faiblesse #1). Le banc d'essai / go-no-go = « l'agent sort un correctif concret là où le partenaire restait vague, et Slim le juge meilleur ».

2. Ce qu'on a fait (acquis)

Recadrage du council (endossé)

• Pas « autopilot autonome » → co-pilote de jugement (automatiser reporting+mesure, garder Slim sur la décision).
• « Temps réel » déclassé (faux différenciant : GSC a 2-3 j de latence, le SEO bouge en semaines) → périodique/à la demande suffit. Différenciant = qualité de la reco.
• Séquençage A (tranche verticale), unanime — mais livrable = une reco, pas un graphe.
• Correcteur = agent séparé, en dernier, existence à confirmer (risque juridique d'écrire dans le site d'un client).
• Upside (dataset propriétaire « avant/après » sur 43 sites, SaaS revendable aux agences) = réel mais séquencé plus tard ; pour l'instant juste garder les contrats JSON propres.
• Note composite = peut-être outil interne (un garagiste ne lit pas une note 3-dim) → à trancher en montrant la 1re sortie.

3. Ce qu'on va faire (et le découpage dans le temps)

Estimations = dev solo (Naouphel + Claude). Chaque phase a un gate (preuve à obtenir avant d'avancer).

Phase 0bis — Dérisquage & validation du jugement — 🕐 ~1-2 j

Objectif : prouver que l'accès données marche ET qu'on sait reproduire le jugement, AVANT d'investir des semaines.

1. Probe GSC réel : spikes/gsc-probe.mjs sur 1 site → sort clics/impressions/positions. 🕐 ~0,5 j. Gate : un JSON GSC réel s'affiche (sinon on a trouvé le vrai risque : scopes/quotas/mapping propriété).
2. Banc d'essai jugement : sur un même site, comparer la reco de l'agent à celle (passée) du partenaire → Slim juge laquelle est meilleure. Les recos partenaire = contre-exemples / plancher (jugées faibles), pas étalon à imiter. 🕐 ~0,5-1 j. Gate GO/NO-GO : si l'agent ne BAT pas le partenaire, on ne code pas la suite.

Phase 1 — Socle + tranche verticale A (perf GSC → 1 reco) — 🕐 ~1-1,5 semaine

Objectif : la définition du succès (1 reco approuvée par Slim sans retouche, sur 1 site).

• Socle commun (core : cli-runner, contrats Zod, validate, journal, reject-queue) — 🕐 2-3 j (déjà planifié).
• Adaptateur gsc (fake fixture + real service account) — 🕐 ~2 j.
• Dimension performance + génération de LA reco (LLM, style des rapports partenaire) — 🕐 ~2-3 j.
• Gate : Slim valide une reco sans la retoucher.

Phase 2 — Empilage dimensions → note composite — 🕐 ~1-1,5 semaine

• Positions mots-clés (GSC) — 🕐 ~1-2 j.
• Technique on-page (rulepack) — 🕐 ~3-4 j (≈ déjà dans le plan existant).
• Conception note composite 3-dim + pondération calibrée sur le réel — 🕐 ~1-2 j.
• Gate : décider note client vs interne en la montrant à un vrai client.

Phase 3 — Reporting (remplace le livrable partenaire) — 🕐 ~1 semaine

• Assemblage d'un rapport proche des 2 rapports partenaire (périodique / à la demande). Gate : Slim livre ce rapport à un client à la place du partenaire.

Phase 4 — Suivi (Agent 8) — 🕐 ~1 semaine

• Lecture continue + alertes sur chutes (positions / CWV / disponibilité).

Phase 5 — Correcteur (en dernier) — 🕐 différé, non estimé

• Applique les correctifs (écrit dans WordPress = D4, garde-fous). Pré-condition : correctifs proposés validés à la main 3-4× et avérés justes + existence confirmée.

Jalon « on remplace le rapport du partenaire » = fin Phase 3 ≈ ~3-4 semaines de dev solo effectif après le GO de Phase 0bis.

4. Dépendances & blocages

5. Décision immédiate

Comment débloquer la Phase 0bis (le probe + le banc d'essai). Trois options :

1. Tu déposes la clé dans oboxia/.secrets/ → je lance le probe (🕐 ~2 min).
2. Tu lances le probe toi-même en ! (la clé ne quitte pas ta machine) — je donne la ligne (🕐 ~2 min).
3. On commence par récupérer les recos du partenaire (banc d'essai jugement) pendant que la clé arrive.