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.