System
The command center watching itself — scheduler pulse, per-site snapshots, the live monitor log, instruments, and operational memory.
- Sites
- 3
- Reporting
- 2/3
- Last run
- 7h ago
- Snapshot
- Aug 25, 10:47
Per-site telemetry
Cron monitor stream
Skills inventory
.claude/skills/rapportCockpit SEO d'Ichai — rapport INTERNE exhaustif (état + tendance monte/descend, leads, santé technique, alertes mail Google Search Console, ce qui monte/chute, opportunités chiffrées, concurrence DataForSEO, PLAN D'ACTION priorisé impact×effort, angles morts). À DÉCLENCHER sur "/rapport", "rapport", "fais un rapport", "où on en est", "cockpit SEO". Sans argument = TOUS les sites ; "rapport emet" = Emet seul, "rapport genius" = Genius Prep seul.
.claude/skills/seo-auditLance l'audit technique SEO d'un site géré par le projet /root/apps/seo (robots.txt, sitemap, title/meta, canonical, headings, JSON-LD, Open Graph, indexabilité) et résume les findings par sévérité. À DÉCLENCHER sur "audit seo", "audite <site>", "check technique SEO", "scanne le SEO de <site>".
.claude/skills/seo-cloudflareGère Cloudflare (DNS, zones, SSL, cache) pour les sites clients du projet /root/apps/seo, via l'API et la clé stockée hors repo (/root/.secrets/cloudflare.env). À DÉCLENCHER sur "cloudflare", "passer un site sur cloudflare", "DNS du domaine", "changer les nameservers", "purge cache cloudflare", "SSL cloudflare", "migrer un domaine".
.claude/skills/seo-cwvMesure les Core Web Vitals (performance, LCP, CLS, TBT/INP) des sites du projet /root/apps/seo via l'API Google PageSpeed Insights — données LAB Lighthouse + champs RÉELS CrUX, findings par sévérité, snapshots versionnés. À DÉCLENCHER sur "core web vitals", "performance <site>", "vitesse <site>", "lighthouse", "pagespeed".
.claude/skills/seo-keywordsRecherche de mots-clés, volumes de recherche réels, SERP/positions et idées de mots-clés via l'API DataForSEO (pay-per-call). Prérequis — identifiants dans /root/.secrets/seo-apis.env. À DÉCLENCHER sur "volume de recherche", "mots-clés <sujet>", "position de <site> sur <requête>", "idées de mots-clés", "rank tracking", "combien cherchent <requête>".
.claude/skills/seo-monitorSuivi Google Search Console des sites du projet /root/apps/seo (clics, impressions, CTR, position, top requêtes/pages), snapshots versionnés, détection de régressions et alerte Signal. À DÉCLENCHER sur "monitoring SEO", "données GSC", "positions <site>", "régressions SEO", "rapport Search Console".
.claude/skills/seo-onboardOnboarde un nouveau site/client dans le SEO command center (/root/apps/seo) — ajoute l'entrée dans config/sites.json, crée l'arborescence sites/<key>/, génère la fiche client memory/clients/<key>.md et affiche les prochaines étapes. Idempotent. À DÉCLENCHER sur "onboard un site", "ajoute un client SEO", "nouveau site <nom>", "brancher <client>".
.claude/skills/seo-opportunitiesTransforme la data Google Search Console déjà collectée (snapshots GSC du projet /root/apps/seo) en backlog SEO priorisé, SANS aucune API externe — striking distance (pos 5-20), requêtes/pages à fortes impressions mais faible CTR (title/meta à revoir), estimation de clics potentiels. À DÉCLENCHER sur "opportunités SEO", "striking distance", "quick wins <site>", "où gagner du trafic", "backlog SEO", "pages à optimiser".
.claude/skills/seo-reportGénère le rapport mensuel CLIENT en PDF brandé (KPIs GSC + tendance 7j vs 7j, top requêtes/pages, santé technique, ce qui a été fait, prochaines priorités) pour un site du projet /root/apps/seo. À DÉCLENCHER sur "rapport mensuel <client>", "rapport SEO", "PDF client", "reporting".
Knowledge ledger
Decisions
Décisions verrouillées
| Date | Décision | Rationale |
|---|---|---|
| 2026-06-25 | Stockage de l'état = PocketBase dédié (pocketbase-seo) |
Pattern VPS, requêtable, alimente le dashboard |
| 2026-06-25 | Trafic & conversions via GA4 (Google), PAS Wizytics | Choix utilisateur explicite |
| 2026-06-25 | Alertes via Signal CLI | Déjà en place sur le VPS |
| 2026-06-25 | Build dashboard + skills en parallèle | Choix utilisateur |
| 2026-06-25 | GSC geniusprep = réutiliser OAuth wizytics ; GSC emet = service account /root/.secrets/emet-gsc-service-account.json |
Déjà fonctionnels, testés |
| 2026-06-25 | Skills projet dans .claude/skills/, créés progressivement |
Scope au projet, pas de pollution globale |
| 2026-06-26 | Dashboard déployé comme app VPS : conteneur seo (réseau proxy) + NPM seo.vpsdashboard.space (SSL LE #335). Lit les fichiers plats via volume /root/apps/seo:/data/seo:ro (SEO_ROOT env). PocketBase différé |
Visuel live tout de suite, zéro dépendance ; PB viendra pour les vues transversales |
| 2026-06-26 | API procurées sans effort user : clé Google PSI (gratuite, gcloud) + GSC + kie.ai (LLM gpt-5.x + images, crédits en main). PSI dans /root/.secrets/seo-apis.env + config/psi.json (gitignored) |
Tout le gratuit Google + kie.ai couvre audit/monitoring/CWV/opportunités/GEO |
| 2026-06-26 | Payant (DataForSEO mots-clés, BrightLocal local) : pas de compte existant sur le VPS. Inscription+carte non automatisable de façon fiable → l'user crée le compte 1× et me file la clé, OU on reste gratuit | Limite honnête ; le gratuit suffit pour livrer maintenant |
| 2026-07-13 | Deal Emet DÉMARRÉ : retainer 500€/mois, facturation le 14 de chaque mois. Périmètre = 2-3 articles/mois + suivi positions + technique + rapport mensuel | Client signé ([[clients/emetexpertise]]) |
| 2026-07-14 | Genius Prep = PAUSE (client a mis en pause) : aucun travail actif (pas d'articles, pas d'optim CTR). Monitoring passif seulement. paused:true dans config/sites.json |
Décision client ; reprise sur feu vert |
| 2026-07-14 | Alerte lead Emet : à chaque formulaire → email au cabinet (déjà en place) + Signal à Ichai (patch mailer signalNotify, best-effort, via signal-cli:8080 sur réseau proxy ; n° dans .env hors Git) |
Ichai veut être notifié des leads en direct (obsession « 3 appels/jour » d'Avi) |
| 2026-07-16 | Analytics = SERVEUR-FIRST, pas de tracker JS client pour l'instant (méta-think 18 agents). GA4 rejeté (bandeau obligatoire en France → −25-45% de mesure à 50 visites/mois ; 141 kB = ×30 le JS du site ; CSP incompatible ; GTM nonce impossible en statique ; inutile pour Ads futur = Data Manager API + gclid côté serveur). Matomo rejeté (MySQL hors backup VPS). Plausible rejeté (Sites API absente en self-host). PostHog rejeté (1 org, accès client payant). Umami = le moins pire des clients MAIS cookieless ≠ exempt : il collecte UTM + referrer complet = « mesure des canaux d'acquisition » que la CNIL EXCLUT de l'exemption → grey zone sans bandeau, et pas d'attestation CNIL (Matomo en a une). À 50 visites/mois il est de toute façon directionnel (adblockers ciblent le chemin /umami.js même en first-party, bots ~51%). |
La seule mesure fiable + légale + imblocable à ce volume = côté serveur : leads (déjà captés à 100%) + enrichissement pays (CF-IPCountry, hors art.82, sans bandeau) + GSC (recherche). Le client-side JS = confort marginal à risque juridique sur un expert-comptable. À revisiter quand le trafic grossit (ou si le client accepte un bandeau). |
| 2026-07-16 | Umami : infra prête, site créé (36f10cc9-1651-4d1b-a1d4-60c3b5cca5c4), mdp admin rotationné (défaut public umami fermé, nouveau dans /root/.secrets/umami.env), joignable en first-party depuis le nginx d'emet. NON tagué sur le site live (cf. décision ci-dessus). Activation = proxy nginx /u/ + tag Layout + MAJ politique confidentialité, ~15 min le jour où on décide. |
Ne pas modifier la politique de confidentialité d'un cabinet + poser un tracker grey-zone sans feu vert explicite. |
2026-07-19 — Arbitrages du rapport cockpit Emet (panel 5 angles)
/expert-comptable-val-doise→ 301 vers/expert-comptable-sarcelles. Désaccord tranché : l'angle Local voulait inverser la hiérarchie (Val-d'Oise = page parent, portable au déménagement). Refusé : on ne sacrifie pas la seule page qui progresse (121 impr, pos 21,5) pour une page à pos 44 sans signal en 4 semaines, pour un déménagement sans date. La portabilité se règle par une chaîne de 301 le jour J. Et les requêtes géo se gagnent dans le pack Maps, pas en bleu.- KPI : on arrête de rapporter la position moyenne site-wide. Elle se dégrade mécaniquement quand on publie (dilution par les nouvelles requêtes mal classées) → illisible pour un client. Remplacée par une cohorte figée de 10 requêtes cœur + « nb de requêtes en top 10 / top 20 ».
- Cadence de contenu ramenée à 1-2 articles/mois. Un article de plus sur un domaine à 0 backlink ne reçoit aucun lien : la distribution est le facteur limitant, pas la production. Temps libéré → baromètre open-data + prescripteurs.
- Cluster « employeur » validé comme compatible avec la contrainte « généraliste » de Nathan. Sa contrainte porte sur la spécialisation sectorielle, pas sur une autorité fonctionnelle (paie/social). Distinction à conserver.
- « bulletin de paie » (8 100/mo) écarté délibérément : aimant à salariés, SERP institutionnelle imprenable. Trafic max, valeur commerciale nulle. Décision à ne pas re-litiger à chaque keyword research.
- Remonté à Ichai, non tranché : l'angle contrarian conteste la décision « pas d'Ads avant 6 mois » — 300 €/mois achèterait la donnée de conversion qu'on n'a jamais mesurée (0 visiteur commercial en 4 semaines).
2026-07-19 — Entités Emet : VÉRIFIÉ (fin de l'incertitude)
Via recherche-entreprises.api.gouv.fr (public, sans auth — Pappers renvoie 403) :
- METRAL CONSEIL — SIREN 103667648, NAF 69.20Z, 4 chemin des Poiriers 95200 Sarcelles, créée 01/04/2026, dirigeant MÉTRAL Nathan.
- EMET EXPERTISE — SIREN 104307871, NAF 69.20Z, même adresse, créée 09/04/2026.
⇒ Deux sociétés d'expertise comptable au même NAF à une adresse résidentielle = motif de refus GBP documenté.
La question « Metral, c'est vous ? » n'aurait jamais dû être posée au client : elle était publique.
Inconnue restante : laquelle porte l'inscription au tableau de l'Ordre (annuaire.experts-comptables.org, JS).
2026-07-19 (soir) — CORRECTION : le doublon d'entité Emet/Metral n'est PAS le problème
Vérifié sur l'annuaire officiel de l'Ordre + societe.com + API RNE. J'avais tort ce matin.
- Les DEUX sociétés sont inscrites au tableau, avec METRAL NATHAN comme expert-comptable dans les deux :
- METRAL CONSEIL →
annuaire.experts-comptables.org/expert-comptable/39865-metral-conseil-sarcelles-95200 - EMET EXPERTISE →
annuaire.experts-comptables.org/expert-comptable/40250-emet-expertise-sarcelles-95200
- METRAL CONSEIL →
- Les deux sont classées SEC (société d'expertise comptable), aucune n'est SPE (société de participations). L'hypothèse « Emet serait une holding / la marque est sur la mauvaise entité » est INFIRMÉE. La clause « peut détenir des participations sous contrôle du Conseil régional » est du boilerplate présent dans la plupart des statuts de SEC — ce n'est pas un marqueur de holding.
- Structure réelle : METRAL CONSEIL est Présidente d'EMET EXPERTISE (dirigeant personne morale). Montage classique et régulier : société d'exercice de l'EC → présidente de la structure d'exploitation. C'est pourquoi l'API ne publie aucun dirigeant personne physique pour Emet.
⇒ On ne pose PLUS la question du doublon à Nathan. Elle est répondue, et la réponse est « tout est régulier ». ⇒ Cause probable du refus GBP révisée : l'adresse résidentielle sans devanture (motif de refus n°1 chez Google), le doublon n'ajoutant que du bruit. La solution reste la vidéo bien faite (rue au sol) ou un bureau en coworking.
2026-07-19 — E-E-A-T : Organization, PAS Person
L'annuaire de l'Ordre publie des fiches cabinet, pas des fiches personne. Il n'existe aucune page publique
individuelle pour Nathan Métral, et l'annuaire ne publie pas le numéro d'inscription au tableau.
⇒ La reco « Person + sameAs vers un registre officiel » est irréalisable en l'état. On pose l'E-E-A-T sur
l'Organization/AccountingService avec sameAs vers la fiche Ordre d'Emet (URL ci-dessus) — registre
officiel, stable, canonique.
⚠️ PIÈGE D'HOMONYMIE — ne jamais mettre en sameAs : il existe un Nathan Metral acteur/artiste très visible
(nathanmetral.com, LinkedIn « Fondateur SELFTAPES PARIS », Instagram @nathan_metral). Ce n'est pas notre
expert-comptable (né en 1995 selon le RNE, aucun lien avec la compta). Un sameAs erroné dégraderait
activement la confiance E-E-A-T au lieu de la renforcer.
2026-07-20 — Faux avis : position ferme, et correction d'un glissement
Constat gênant à consigner : le 13/07 la position tenue avec le client était nette (« uniquement de vrais clients, jamais la famille »). Le 19/07, en vocal, elle est devenue « on peut mettre quelques faux clients, ça va rien faire ». Un conseil qui bouge sous pression sociale ne vaut rien — et Avi a appris que la porte s'entrouvre.
Position définitive : je ne mets pas en place de faux avis. Si ça se fait, ça se fait sans moi.
Raisons, chiffrées :
- Pénal : pratique commerciale trompeuse, 5 ans / 750 000 € quand commis en ligne (le cas d'un avis Google). Amende administrative DGCCRF sans juge : 75 k€. Outil dédié Polygraphe, 1 200 établissements contrôlés depuis 2023.
- Ordinal : Nathan est inscrit via deux entités. Échelle jusqu'à la radiation. On mettrait en jeu une carrière d'EC pour un gain espéré de +1-2 leads/mois.
- Google : sur une fiche créée le 19/07 avec 0 avis, chaque avis pèse lourd dans le profil de confiance initial → risque maximal, dilution nulle. L'argument « quelques-uns ça passe » vaudrait dans 2 ans avec 80 avis, pas aujourd'hui.
- Déclencheur le plus probable = un confrère : ~20 cabinets à Sarcelles au même Conseil régional. Une réclamation au président du Conseil régional est gratuite et déclenche une instruction disciplinaire.
POSTURE À TENIR (protège la relation) : ne pas arbitrer avec Avi. Ce n'est pas sa décision, c'est la licence de Nathan. → « Je ne peux pas trancher ça avec toi, c'est l'inscription de Nathan. Pose-lui la question, et ce que vous décidez à deux, je m'y tiens. » Neuf fois sur dix la question n'est jamais posée et le sujet meurt seul.
Et c'est inutile : 20 vrais clients existent ; 8-12 avis authentiques suffisent sur ce marché. Whitespark 2026 : la fraîcheur bat le volume (30 avis sur 6 mois > 200 sur 5 ans).
2026-07-20 — Autres arbitrages du rapport
- Wikidata : NON. Depuis que le Knowledge Panel local est alimenté par GBP, Wikidata ne pèse plus sur les entités commerciales locales. La fiche validée EST le knowledge panel. (Contredit la reco de l'angle GEO du 19/07.)
- Baromètre open-data Val-d'Oise : RETIRÉ (c'était ma reco vedette du 19/07). Géo-ancré sur un département qu'ils quittent, donnée BODACC/INSEE = commodité, et zéro relation presse pour le pitcher. → Remplacé par un observatoire des plateformes agréées (PDP) de facturation électronique : non géolocalisé, evergreen jusqu'en 2027, dans la compétence de Nathan, et le mécanisme de liens s'auto-exécute (les PDP relaient quand elles se voient listées — on les contacte pour vérification factuelle, pas pour mendier un lien).
- Rampe d'avis corrigée : 1 la 1ʳᵉ semaine, 2 la 2ᵉ, 3/semaine ensuite (au lieu de 3/semaine d'emblée). Le premier avis doit venir du compte Google le plus mûr de la liste.
- Les avis ne doivent PAS mentionner « Sarcelles » (déménagement → 20 avis géo-ancrés = passif). On pilote par question ouverte pendant l'appel : « en une phrase, sur quoi on t'accompagne ? ».
- Q&R de la fiche : posées depuis le compte du cabinet, ouvertement. L'usage du secteur (poser depuis un compte perso pour masquer) est refusé — même mécanique déguisée que les faux avis, incohérent avec la position ci-dessus.
- Call tracking sur la fiche : NON. Changer le numéro principal d'une fiche validée d'hier déclenche un ré-examen. L'onglet Performances donne déjà appels/itinéraires/clics nativement.
- 🔒 GEL des champs sensibles de la fiche jusqu'au 19/08 (nom, catégorie, téléphone, adresse). La fiche cumule 3 marqueurs de risque : adresse résidentielle, adresse masquée, 2 refus de vérification. Champs froids uniquement, une modification à la fois. Le futur 01 s'ajoutera en secondaire, jamais en remplacement avant 90 jours.
- CADRAGE CORRIGÉ — « CTR commercial 0 % » n'est PAS un signal. À pos 23,9, l'espérance est de 0,29 clic sur 144 impressions. C'est un problème de POSITION (page 3), pas de titres. Ne jamais réécrire de titles sur cette base.
2026-07-20 (soir) — ⚠️ CORRECTIONS après vérification adverse — plusieurs de mes affirmations étaient FAUSSES
Trois agents adverses lancés contre mes propres recos. Ils ont invalidé plusieurs points déjà écrits ci-dessus. Ce qui suit remplace les affirmations correspondantes des entrées du 20/07.
❌ FAUX — « Bing Places compte pour la visibilité ChatGPT »
ChatGPT lance une recherche Bing et lit des résultats WEB ; il ne voit pas les données de fiche Bing Places (source : Search Engine Land, analyse du fonctionnement local de ChatGPT). C'est Copilot qui sert les données Bing Places. J'avais fusionné les deux moteurs. ⇒ Bing Places se justifie par Copilot + Bing Maps, jamais par ChatGPT.
❌ FAUX — « Soumettre à Brave a de la valeur pour la fiche / le SEO local »
Brave n'a AUCUN produit d'annuaire local, aucune fiche entreprise. Sa page « Submit URL » est une demande de re-fetch pour l'index web. ⇒ La soumission Brave est une action d'indexation web, à ranger avec IndexNow. Le lien Brave→Claude (index web) reste vrai, mais il ne concerne que les pages du site, pas la fiche.
❌ FAUX — le « seuil des 90 jours » et le « gel jusqu'au 19/08 »
Ce seuil n'existe nulle part (ni doc Google, ni Sterling Sky, dont le playbook suspensions de mars 2026 liste 5 causes, aucune liée à l'âge de la fiche). Chiffre importé d'un contexte voisin = folklore. ✅ Règle réelle à retenir : (1) ne rien éditer tant qu'un examen est en cours — éditer nom/adresse/catégorie pendant une vérification invalide le processus (doc Google) ; (2) ensuite, un champ important à la fois, espacé de quelques jours (Sterling Sky). ⇒ Concrètement : rien jusqu'à ce que le nom et les 5 services sortent d'examen (~48 h, pas un mois), puis édits unitaires espacés. La cause n°1 de suspension est la RAFALE d'édits, pas l'âge.
⚠️ SOURCE MAQUILLÉE — l'étude « les posts GBP n'impactent pas le classement »
Elle existe et est bien citée (Sterling Sky, Joy Hawkins, 441 mots-clés, 9 semaines) mais elle date de 2021, pas de 2026, et n = 3 établissements dont 2 inexploitables. Je l'ai présentée comme fraîche. La conclusion reste alignée avec le consensus 2026 (posts = CTR/fraîcheur, pas position), mais ne plus la vendre comme une preuve solide.
🚨 ANGLE MORT MAJEUR QUE J'AVAIS RATÉ — l'adresse masquée pénalise le classement
Étude Sterling Sky « Does Hiding Your Address Impact your GBP Ranking? » : corrélation négative entre adresse masquée et classement, avec des SAB qui « disparaissent complètement » dans certains cas (résultats inconstants). Emet est un SAB pur à adresse masquée = la configuration la plus handicapée du pack local. ⇒ Conséquence stratégique : sur cette fiche, une partie du classement ne se gagnera pas dans la fiche mais sur le site et les citations. À rouvrir avec le client : le masquage de l'adresse est un CHOIX (préparer le déménagement) qui coûte du classement maintenant — il doit être assumé comme tel, pas subi.
✅ CONFIRMÉ malgré l'attaque
- Zones desservies sans impact classement (Sterling Sky, mars 2025, bien sourcé).
- Bing/Apple : mes objections tombent (import Google fonctionne, vérif contournable sans appel téléphonique, adresse masquable des deux côtés, aucun couplage avec l'examen Google).
- Risque réel que je n'avais PAS vu : Apple Maps ingère des données Yelp et peut écraser une fiche. Avec deux entités à la même adresse (Emet + Metral Conseil), terrain à doublons. ⇒ CHERCHER une fiche préexistante et la REVENDIQUER avant d'en créer une.
2026-07-20 (soir) — Faux avis : vérification juridique adverse. Corrections.
❌ FAUX — « amende administrative DGCCRF sans juge, 75 000 € pour une personne morale »
Doublement faux. (a) 75 000 € est le plafond personne physique (375 000 € personne morale, art. L131-4). (b) Surtout, ce plafond sanctionne les manquements à L111-7-2, qui vise « toute personne dont l'activité consiste à collecter, modérer ou diffuser des avis en ligne » = les PLATEFORMES d'avis, pas le commerçant qui en poste. ⇒ La DGCCRF n'a PAS de pouvoir d'amende administrative autonome contre un cabinet qui poste de faux avis. Ses leviers réels : injonction de cesser (avec publication possible = name and shame), transaction, PV au procureur.
⚠️ MAL ADRESSÉ — la plainte ordinale
Ce n'est pas « le président du Conseil régional de l'Ordre » mais le président de la Chambre régionale de Discipline. Peuvent saisir : clients (actuels/anciens), personnes inscrites au tableau (donc un confrère), instances, commissaire du Gouvernement. ⚠️ Une plainte ne déclenche PAS automatiquement une instruction : un magistrat chargé de la poursuite filtre l'opportunité. Ne plus écrire « ça déclenche une instruction ». Et « gratuite » = non sourçable, ne pas l'affirmer.
⚠️ RACCOURCI — Polygraphe / 1 200 contrôles
L'outil existe (traitement automatisé DGCCRF publié, déployé sept. 2023, scanne Google et TripAdvisor) et le chiffre est réel (réponse ministérielle Sénat 2025). Mais : « plus de 1 200 établissements contrôlés sur la thématique faux avis depuis le 1ᵉʳ juillet 2023 » ≠ « contrôlés par Polygraphe ». Chiffre de 2025 ⇒ dire « au moins 1 200 ».
⚠️ NON DOCUMENTÉ — les mécanismes de détection Google que j'ai cités
« Graphe de relations entre comptes » et « historique de localisation » ne sont pas documentés par Google — c'est de l'inférence de praticien. ✅ Ce qui EST public et vérifiable : 292 M d'avis supprimés/bloqués en 2025 (sur 1,14 Md publiés), 782 000 comptes restreints, 13 M de fiches supprimées. Et surtout, la réponse de Google à un pic suspect : suppression, mise en pause des nouveaux avis, alerte au propriétaire, et BANDEAU PUBLIC D'AVERTISSEMENT visible par les clients sur la fiche. ⇒ Le bandeau public est le meilleur argument commercial : humiliant, visible des clients, sans procès.
✅ CONFIRMÉ, et j'avais même SOUS-ESTIMÉ
- L132-2 : 2 ans / 300 k€, porté à 5 ans / 750 k€ en ligne (loi SREN du 10/05/2024). Rattachement via L121-4, 21° (« diffuser ou faire diffuser de faux avis »). Pour une personne morale : ×5 = 1,5 M€ (art. 131-38 CP), plus un plafond alternatif à 10 % du CA annuel moyen.
- Échelle disciplinaire jusqu'à la radiation (art. 53 ordonnance 45-2138). Principes violés : art. 144 (rien qui déconsidère la profession), 145 (probité, honneur, dignité), 152 (communication sans inexactitude ni nature à induire en erreur — un faux avis coche littéralement).
- Risque agence : je l'avais sous-estimé. L121-4 21° vise celui qui « diffuse ou fait diffuser » ⇒ une agence qui orchestre serait auteur/co-auteur, pas seulement complice. L'élément intentionnel se déduit du comportement (dont l'absence de vérification). ⚠️ Aucune décision publiée contre une agence marketing pour faux avis → ne citer aucune jurisprudence nommée.
🎯 NUANCE À TOUJOURS AJOUTER
Ces maxima ne sont quasiment jamais prononcés. Le risque réel et probable n'est pas la prison : c'est le bandeau public sur la fiche Google devant les clients, la fiche suspendue, et une plainte ordinale d'un confrère. Bien plus persuasif qu'un chiffre à sept zéros que personne ne croit.
2026-08-02 — Stratégie contenu Emet verrouillée (panel /rapport)
- Pilier n°1 = cluster URSSAF / EMPLOYEUR (autorité FONCTIONNELLE, pas sectorielle → compatible avec le « généraliste » non-négociable de Nathan, ET 100 % portable au déménagement). Pilier « contrôle URSSAF » (1 900/mo, conc. faible, intention peur→appel) + satellites : redressement URSSAF, déroulé étape par étape, erreurs DSN déclencheuses, travail dissimulé/requalification, prescription/délais, externaliser la paie. Maillage croisé + FAQPage + CTA fonction-spécifique. Rythme 1-2/mois, priorité sur le reste du blog.
- REFUS définitif de « bulletin de paie » (8 100/mo) : aimant à SALARIÉS (0 conversion pour un cabinet), SERP institutionnelle (service-public/urssaf) imbattable. Filtrer par QUI PAIE, pas par volume. Ne pas re-proposer à chaque planif. Variante employeur OK (« erreur de bulletin, le risque employeur »).
- Baromètre = actif de PRESSE + E-E-A-T, PAS une usine à articles : refresh trimestriel + 1 seul angle éditorial dérivé/trimestre maillé vers le cluster URSSAF. Sa valeur = rareté + data first-party incopiable.
- Semer le SEO sur PARIS (cible du déménagement 6-12 mois), pas sur Sarcelles : contenu/entité portables, aucun asset « Sarcelles » périssable. Les avis suivent la fiche (portables), pas l'adresse.
- Point mensuel client (le 14) = FRANC-PARLER business, pas métriques de vanité : le SEO local plafonne à ~3-5 leads/mois (marché de 98 impr/mo), les 3 appels/jour viennent du réseau/presse/outbound. Dire le plafond AVANT qu'Avi le découvre seul (sinon rupture de confiance au mois 5-6).
- Mesure des appels = prérequis du KPI : unifier le numéro sur UNE ligne traçable (fiche + site) + GBP Insights. Sans ça, « 3 appels/jour » est impilotable. (cf. conflit 01/07, à trancher par Ichai.)
Repetitive → skills
Manips répétitives → candidats skills/scripts
| Repéré | Manip | Statut |
|---|---|---|
| 2026-06-25 | Auditer techniquement un site + lire les findings | ✅ scripts/audit.mjs → skill seo-audit |
| 2026-06-25 | Écrire au journal en fin de session | ✅ scripts/journal.mjs |
| 2026-06-25 | Vérifier si un autre Claude bosse sur un projet (avant d'agir/s'alarmer) | ✅ scripts/claude-sessions.sh [projet] |
| 2026-06-25 | Générer de vraies images (articles/OG) via kie.ai GPT Image 2 | ✅ scripts/kie-image.mjs (clé /root/.secrets/kie.env) — candidat skill seo-image |
| 2026-06-25 | Pull GSC (geniusprep via wizytics, emet via SA) — 2 méthodes à unifier | ✅ scripts/gsc.mjs (unifié, JWT en node pur) + gsc-diff.mjs + signal-send.mjs + monitor.sh → skill seo-monitor |
| 2026-06-25 | Poser robots.txt + sitemap sur un site qui n'en a pas | ⏸️ pas nécessaire (emet a déjà tout) — dé-priorisé |
| 2026-06-25 | Auditer un site via plusieurs agents (recon/contenu) puis synthétiser | 🔜 candidat workflow seo-deep-audit (fan-out + vérif adverse) |
| 2026-06-26 | Migrer un domaine client sur Cloudflare (DNS/SSL/cache) | ✅ scripts/cloudflare.mjs + skill seo-cloudflare + runbook runbooks/cloudflare-migration.md |
| 2026-06-26 | Documenter ce qu'on refait (procédures) | ✅ système runbooks/ (discipline gravée dans CLAUDE.md) |
Frictions & fixes
Frictions rencontrées (+ solutions)
| Date | Friction | Solution |
|---|---|---|
| 2026-06-25 | TaskCreate échoue (schéma non chargé — tool déféré) |
Charger via ToolSearch "select:TaskCreate" avant usage, OU utiliser le journal/memory du projet (préféré ici) |
| 2026-06-25 | cd /root/.secrets → "Shell cwd was reset" après la commande |
Toujours chemins absolus, ne pas cd (rappelé dans CLAUDE.md) |
| 2026-06-25 | keyPath /contact présumé → 404 côté geniusprep |
Ne pas présumer les chemins ; les dériver du sitemap ou vérifier en live |
| 2026-06-25 | Fausse alerte « emet 502 / site down » : c'était un état transitoire pendant le déploiement du mailer par un autre Claude | Avant d'annoncer un incident : bash scripts/claude-sessions.sh <site> + uptime conteneur + git/mtimes récents. Doctrine gravée dans CLAUDE.md |
| 2026-06-25 | Bug moteur audit : sitemap_missing faux positif (testait /sitemap.xml en dur ; Astro émet sitemap-index.xml) → m'a fait croire au 404 d'emet |
audit.mjs corrigé : résout le sitemap via la directive Sitemap: de robots.txt + chemins usuels (sitemap-index.xml…). Re-test emet = 100/100 |
| 2026-06-26 | Doublon introduit : monitor.sh (7h) est le 4e système GSC sur geniusprep (6h/8h/9h existaient déjà). Mon grep -i seo ratait les scripts gsc-* |
Grep large `gsc |
| 2026-06-26 | Auto-critique workflow : la détection de régression gsc-diff est "décorative" (fenêtre glissante 28j → snapshots chevauchants à 27/28) |
Refondre en fenêtres 7j non chevauchantes (dimension date) + diff par requête/page. Voir reports/2026-06-26-system-review.md P1-A. |
| 2026-06-26 | ✅ RÉSOLU (commit c6ea795) : les 6 points de la revue corrigés | régression → 7j non chevauchant (timeseries) + diff requête ; doublon → monitor:false geniusprep ; audit → audit-diff.mjs + cron audit-weekly.sh ; GEO → geo.mjs ; parser robots par groupe UA ; secret Signal → config/notify.json ; git init (filet de sécurité, pas de backup-server.sh sur le VPS → backup off-site à prévoir). |
2026-06-26 — Doublon de fiche client (ruben)
- Friction : deux fiches pour le même client dans
memory/clients/—ruben-toledano.md(rich, créée à la main au stade prospect) etruben.md(générée parnew-site.mjs, = clé attendue par les scripts report/audit). Risque de divergence. - Solution appliquée :
ruben.mddevient la fiche canonique (clé-matchée + baseline) ;ruben-toledano.mdréduit à un pointeur en tête. Convention à retenir : la fiche SEO vit toujours sousmemory/clients/<key>.md(iciruben.md), pas sous le nom complet. - Note : ne pas confondre avec
/root/apps/chat/whatsapp/contacts/ruben-toledano.md(miroir WhatsApp, autre repo) qui, lui, garde son nom complet par mapping. | 2026-06-26 | Emballement kie : un agent a spawné un watcher bash qui relançait en boucle des batches kie.ai →200 crédits brûlés, images sauvées dans scratchpad/raw (PNG) au lieu d'emet | Tuer watcher+générateurs (pgrep/kill ciblé), RÉCUPÉRER les PNG de scratchpad → convertir webp. Leçon : ne JAMAIS laisser un agent créer des watchers/loops background auto-relançants ; pour générer en masse → 1 batch détaché idempotent, contrôlé, pas de boucle. | | 2026-06-26 | kie + Bash tué en plein vol : batches kie en1-2 images par invocation avant kill) |run_in_backgroundtués ~exit 144 (cap temps) ; version foregroundnode ... & wait+\| tail→ exit 1 prématuré (kie-image.mjsest idempotent (skip si--outexiste) → relancer le même batch finit le reste. Pattern fiable = 1 batch foreground> log.txt 2>&1(pas de pipe, pas de&/wait, pas de watcher), réexécuté jusqu'à N/N. | | 2026-06-26 | Auto-commit bot VPS sur emet : un hookVPS Dashboard <bot@vpsdashboard.space>commit+déploie le working tree d'emet (a committé mes imgs+blog index+heros enb9776a4avant mongit commit→ "nothing to commit" ; conteneur redémarré et heros recompressés apparus en cours de session) | Non bloquant : l'état committé = exactement mon travail vérifié. À savoir : sur emet le working tree est auto-committé/déployé — vérifiergit log(auteur bot) au lieu de supposer ; ne pas s'alarmer d'un conteneur "Up Xs" ni de fichiers déjà à jour. |
2026-06-27 — Miroir WhatsApp figé : migration LID de WhatsApp (CRITIQUE, récurrent)
- Friction :
avi.mdfigé depuis le 26/06 alors qu'Avi écrivait en continu (conversation live sur le Google Business Profile invisible).wa-routertournait pourtant (cursor qui avance, "N events traités"). - Cause racine : WhatsApp a migré les chats 1-1 vers des LID (
<num>@lid) au lieu du JID téléphone (<phone>@s.whatsapp.net). Les messages d'Avi arrivaient sous162749229334551@lid. Dansregistry.jsonson entrée avaitlid: null→ la fonctionmatchContactdu routeur (/app/index.js, match surc.lidouc.jiduniquement) ne matchait rien → message consommé (cursor++ , ajouté àseen) mais jamais écrit. L'auto-bind du LID (index.js l.99) ne se déclenche qu'après un match réussi → chicken-and-egg, jamais réparé seul. - Solution appliquée : récupérer le LID du contact (ici via les
participantsdu groupe Emet :162749229334551= Avi), le poser dansregistry.json("lid": "162749229334551@lid"). Le routeur recharge la registry à chaque tick → mirroring live réparé immédiatement (vérifié : il a appendé 00:45→00:48 tout seul). Backlog manquant (14:33→00:44, déjà dansseen, non rejoué) : récupéré via l'APIGET whatsapp-api:3000/api/messages/<lid>?limit=500(mémoire du bridge, garde ~70 msgs récents) + transcription Deepgram, mergé dansavi.md(insertion du trou, sans écraser l'ancien historique —backfill.jsécrase, donc NE PAS le lancer tel quel si l'historique d'avant migration n'est plus dans la mémoire du bridge). - ⚠️ Va recommencer :
houny,lance, et les autres ontlid: null→ mêmes silences quand WhatsApp les migrera. Réflexe quand un*.mdcontact se fige :docker exec wa-router node -e→ fetch/api/archive/events→ repérer les@lidnon mappés / fortement actifs → cross-référencer (pushName, participants groupe) → patcher la registry. Fix robuste (côté chat, non fait) : que le routeur mappe@lid→contact viaparticipantPhone/table LID↔phone, pas seulement viac.lidstatique. - Note périmètre :
/root/apps/chatest normalement read-only (autre projet) ; patch registry + mergeavi.mdfaits car Ichai a explicitement demandé de réparer le bridge. Changement minimal et réversible.
2026-07-19 — Les « kits d'actions client » ne s'exécutent pas
Constat. templates/emet-actions-avi-nathan.md livré le 16/07, prêt-à-coller, priorisé. 3 jours plus tard : zéro
ligne exécutée. Fiche GBP toujours non vérifiée, aucun profil revendiqué.
Ce n'est PAS de la paresse du client — Nathan a créé la fiche, filmé 66 s, zoomé sur le Kbis, retenté le 13/07, commandé des cartes de visite. Ce client exécute. Ce qui bloque :
- Le kit demande une décision, pas une action. Toute ligne contenant un point d'interrogation ne sera jamais exécutée — surtout sur un sujet sensible (deux structures à une adresse résidentielle, dont une au nom de l'associé).
- Impuissance apprise : il a échoué 2× sur la vidéo et a dit « je sais pas quoi faire de plus ». Lui renvoyer un script écrit, c'est lui redemander de refaire seul ce qui a déjà raté.
- Pas de propriétaire ni de date. Un livrable adressé « à Avi/Nathan » est adressé à personne.
Règles adoptées :
- Ne plus livrer de kits. Ce qui est délégable (formulaires : PagesJaunes, Ordre, Pappers, Societe.com) → on demande les accès une fois et on exécute nous-mêmes. Zéro tâche déléguée = zéro tâche non faite.
- Ce qui est irréductiblement au client (vidéo GBP filmée en direct dans l'app) → un créneau visio de 20 min, pas un document. C'est ce qui a marché le 30/06 : fiche créée en 17 min avec Ichai en direct.
- Jamais une question au client si la réponse est publique. Vérifier d'abord (API entreprises, annuaires, SERP).
- Router par personne, jamais « au groupe ». Nathan = physique/administratif. Avi = tout ce qui implique de parler à des humains (prescripteurs, avis). Avi est un closer : une tâche administrative pour lui est une tâche morte.
- Formuler en décision, pas en question : « J'ai vérifié X. On fait Y. Dis-moi juste OK. »
2026-07-19 — Annuaire de l'Ordre : le paramètre q= est un piège silencieux
annuaire.experts-comptables.org/recherche?q=<nom> ignore silencieusement le paramètre et renvoie
l'annuaire entier (3148 pages) — ce qui se lit comme « 0 résultat pertinent » et fait conclure à tort
que le cabinet n'est pas inscrit. J'ai failli livrer cette fausse conclusion au client.
✅ Le bon paramètre est comptable= : annuaire.experts-comptables.org/recherche?comptable=metral
Filtres de type disponibles et utiles : SEC (société d'expertise comptable), SPE (société de participations),
SUCCURSALE, AGC. Ils permettent de trancher la nature réelle d'une structure.
À réutiliser pour tout futur client expert-comptable (vérification d'inscription, sameAs officiel).
2026-07-19 — Revendication fiches annuaires Emet : murs anti-bot / SSO (VPS IP)
Contexte : mission de revendiquer/compléter Emet Expertise sur PagesJaunes, Pappers/Societe.com, annuaire de l'Ordre, en attendant la fiche Google Business (bloquée en validation vidéo). Blocages constatés (preuves = screenshots scratchpad/claims/) :
- PagesJaunes / Solocal : la fiche n'existe pas encore (que des concurrents Y2M, Sarcelles Expertise). L'inscription owner passe par
solocal.com→ Cloudflare Turnstile non résolvable (headless ET headed xvfb, IP datacenter). Le fallback "Suggérer un pro" (formcqlr_ajoutetab, sans compte) affiche lui aussi un Turnstile qui échoue ("Échec de la vérification") → soumission impossible. BLOQUÉ. - Pappers :
pappers.frentièrement derrière Cloudflare Turnstile (403). L'espace dirigeant (claim gratuit) est derrière ce mur. BLOQUÉ. - Societe.com : fiche existe (
emet-expertise-104307871.html), pas de captcha, mais aucun champ gratuit pour ajouter le site web ; édition = espace client payant, data INSEE/INPI. Lien non ajoutable gratuitement. - Annuaire Ordre : fiche existe (Nathan METRAL, adresse OK, pas de site web). Édition = login Comptexpert SSO (
identification.experts-comptables.org) = identifiants Ordre de Nathan. BLOQUÉ, action Nathan requise. Leçon : les annuaires FR grand public (Solocal, Pappers) sont sous Cloudflare Turnstile → inrevendicables par bot depuis le VPS. Ces claims doivent être faits manuellement par le client (Avi/Nathan) depuis leur navigateur résidentiel. Fournir des runbooks pas-à-pas plutôt que d'automatiser.
2026-07-19 — Faux champs live dans le JSON-LD / mentions-légales (confiance d'entité)
Découvert via panel /wide (données structurées). Trois champs de src/data/company.ts étaient faux ou factices
et nuisaient activement à la reconnaissance d'entité (Google recoupe le JSON-LD avec les registres pointés en sameAs) :
foundingYear: '2025'alors que la création RNE est le 2026-04-09 →foundingDatecorrigé.vatId: 'FR [à confirmer par le cabinet]'— s'affichait tel quel EN PUBLIC sur/mentions-legales. La TVA intracommunautaire FR est dérivable (algo DGFiP : clé = (12 + 3×(SIREN mod 97)) mod 97 = 73) →FR73104307871. Rendu rendu conditionnel (ne jamais laisser fuir un placeholder). ⚠️ à faire confirmer au cabinet.sameAs: un seul lien[A CONFIRMER]→ enrichi à 3 registres vérifiés. Règle : un placeholder[A CONFIRMER]danscompany.tspeut fuir en clair sur une page publique — les traquer.
2026-07-19 — llms.txt = cargo-cult (ne plus le vendre comme atout)
Vérifié (Ahrefs 137k sites : 97% à 0 trafic ; Google/Mueller : non lu, comparé à meta keywords). On garde le fichier (ne nuit pas) mais on ne le compte plus comme un levier GEO dans les rapports. Ce qui compte pour être cité par les LLM en 2026 : entité (sameAs/Wikidata), Q&A visible (pas le JSON-LD FAQ), et surtout mentions tierces (digital PR).
2026-07-21 — Faux positif « RÉGRESSION position moyenne » (2e occurrence, autre script)
Alerte Signal reçue : « 🔴 RÉGRESSION : position moy. 21,1→27,3 (+6,2) » sur Emet. C'était un FAUX POSITIF. Sur les mêmes 7 jours : clics +67 % ET impressions +63 %, et vérifié couple par couple : la page money progressait (21,5→21,2), home et paie-social stables, aucune page clé en recul. La position moyenne montait uniquement parce que le site (jeune) apparaît sur de nouvelles requêtes longue-traîne mal classées → dilution mécanique = expansion saine, pas une chute.
Cause : scripts/gsc-diff.mjs l.50 alertait sur dPos >= 2 sans regarder le trafic.
Fix : n'alerter sur la position que si les clics chutent ou stagnent (dClicks <= 5%). Une vraie perte de
rang fait baisser les clics ; une expansion les fait monter. Testé dans les deux sens (vraie chute alerte toujours).
⚠️ C'est la 2e fois que ce même faux positif pique : déjà corrigé sur audit-diff.mjs (score-drop-alone) le
mois dernier, il subsistait sur gsc-diff.mjs. Règle générale à retenir : une métrique de "qualité moyenne"
(position moyenne, score) qui empire n'est JAMAIS une régression si le volume utile (clics/trafic) monte en même temps.
Vérifier tout autre détecteur qui suivrait ce schéma.
2026-07-31 — Cloudflare cache la home d'emetexpertise → déploiements servis PÉRIMÉS
Constaté après le déploiement du baromètre : cf-cache-status: HIT sur la home. Le conteneur servait la
version fraîche, mais Cloudflare servait une version cachée aux vrais visiteurs (lien footer absent,
et potentiellement les corrections du jour : formulaire home, écritures collées, schema).
Règle : après CHAQUE déploiement d'emetexpertise (et tout site derrière Cloudflare proxifié), purger le cache Cloudflare, sinon les visiteurs voient l'ancienne version (règle héritée n°11 : vérifier la version réellement servie, pas seulement le conteneur).
Purge (secret dans /root/.secrets/cloudflare.env) :
ZONE=$(curl -s -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" "https://api.cloudflare.com/client/v4/zones?name=emetexpertise.fr" | jq -r '.result[0].id')
curl -s -X POST -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -H "Content-Type: application/json" \
"https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" --data '{"purge_everything":true}'
À intégrer dans un script de déploiement emet (build → up → purge CF → IndexNow → vérif live).
2026-08-14 — trois frictions détectées au rapport
- wizytics down (~10 j) → pull GSC geniusprep cassé (
docker exec wizytics …échoue) et le cron quotidien échoue probablement en silence. Fix proposé : soitdocker start wizytics pocketbase-wizytics, soit migrer geniusprep en service account JWT comme emet (plus de dépendance conteneur). - marva hors ligne (8 conteneurs stoppés ~2 sem. + proxy host NPM inactif → SSL unrecognized name).
L'audit sort score 0/critical×5 artificiels. Fix : décider actif/pause ; si pause →
paused: truedansconfig/sites.json. - Mémoire fausse :
clients/emetexpertise.mdaffirmaitgoogleReviewUrlcâblé — faux (avis.astro:58vide depuis le 19/07, vérifié en prod). Corrigé dans la fiche. Leçon : « prêt côté nous » ne se note qu'après vérification du code déployé, pas de l'intention.
2026-08-16 — envoi d'un fichier sur un groupe WhatsApp client : AUCUN chemin automatisé
Demande : envoyer le rapport PDF sur le groupe « SEO EMET EXPERTISE ». Trois voies tentées, trois échecs : (1) bridge whatsapp-api VPS = pas de fichiers + bug groupes (Baileys 6.7.8, « not-acceptable ») ; (2) WhatsApp Web sur ICHAIPC = session non connectée (QR demandé) ; (3) WhatsApp Desktop sur ICHAIPC = non connecté (écran « Bienvenue »). Solutions durables possibles : upgrade Baileys (risque session, à faire hors conversation active) OU demander à Ichai de connecter durablement WhatsApp (Desktop ou Web profil ichaiwizlol) sur ICHAIPC — ça débloquerait tous les envois clients futurs (fichiers + groupes). En attendant : fallback = PDF sur Telegram → Ichai transfère depuis son téléphone.
✅ RÉSOLU 2026-08-16 (le soir même) — envoi groupes WhatsApp
Upgrade Baileys 6.7.8 → 6.7.24 dans whatsapp-api (+ stub makeInMemoryStore retiré de l'API, session conservée sans re-scan, backup sessions dans /root/backups/whatsapp-sessions-20260816-1839.tar.gz). L'endpoint /api/send-file (non documenté) marche maintenant sur les groupes. Rapport PDF envoyé sur le groupe SEO EMET EXPERTISE et vérifié dans l'archive (fromMe:true). Skill whatsapp mis à jour.
2026-08-19 — Rapport cockpit (panel 5 angles)
- [CORRIGÉ 19/08 soir] Miroir WhatsApp : le diagnostic « mort » du panel était à moitié faux — les ARCHIVES (whatsapp-api,
/app/sessions/archive/messages-live-*.jsonl) n'ont JAMAIS cessé, seule la couche markdowncontacts/*.mdétait figée depuis le 03/08 car le conteneurwa-routeravait disparu (absent même dedocker ps -a, cause inconnue). RÉPARÉ : conteneur relancé (/root/apps/wa-router, compose up) + backfill one-shot du trou 03→19/08 (script conservé :/root/apps/chat/whatsapp/_backfill/backfill.js, exécuter avecdocker exec -e NODE_PATH=/app/node_modules wa-router node …après avoir copié les jsonl d'archives). ⚠️ Piège appris : le rejeu par recul de curseur ne marche PAS (/api/archive/events?since=renvoie les événements les plus récents → le curseur saute le backlog). Leçon : en cas de doute sur le miroir, vérifier les ARCHIVES du conteneur avant de déclarer le canal mort. - Faux blocage « mot de passe contact@ » (19/07→19/08) : jamais re-testé alors qu'Avi contrôle a.cohen@emetexpertise.fr depuis le 02/08 (M365 + AnyDesk fait). 4 actions annuaires bloquées 1 mois pour rien. Leçon : un blocage inscrit en mémoire doit être RE-TESTÉ à chaque rapport, pas recopié. Idem : la fiche Ordre se débloque via SSO Comptexpert de Nathan, sans aucun mot de passe.
- Le mailer n'a pas de mode test : l'audit CRO du jour a envoyé 2 mails de lead [Test] + 2 alertes Signal à Avi en testant la prod. Fix : gate
source=test-*avant alerte (action du rapport 19/08). Prévenir Avi. - report-data.mjs / competition : n'interroge que la requête MARQUE ("emet expertise") au lieu de la requête locale n°1 → SERP concurrence inutilisable dans le rapport. Fix : prendre la 1re requête locale non-marque des queries GSC.
- Intersection backlinks DataForSEO sur marché local : 320 domaines, 0 dofollow, 283 rank 0 → analyse cul-de-sac sur ce type de marché, ne plus la payer pour des SERP locales de cabinets.
INDEXMémoire — INDEX (à lire en premier)
Mémoire — INDEX (à lire en premier)
Source de vérité du projet SEO. Chaque fichier = une facette. Mets à jour après tout travail structurant.
- decisions.md — décisions verrouillées + rationale
- credentials.md — carte des accès Google (chemins, méthodes par site, sans secrets)
- sites.md — état SEO par site (stack, GSC, GA4, findings récurrents)
- clients/ — profil par client : qui ils sont, ce qu'ils aiment, ton, à éviter, retours datés (à LIRE avant de produire du contenu pour eux)
- frictions.md — frictions rencontrées + solutions
- repetitive.md — manips répétitives → candidats skills/scripts
- references.md — où trouver quoi ; infos sur Ichai → app
/root/apps/chat/(lecture seule) - objectives.md — cap du projet (migration sites → notre stack + Cloudflare via clé API ultime)
- ../runbooks/ — procédures réutilisables (ce qu'on refait : migration Cloudflare faite, onboarding, déploiement…)
État au 2026-06-26
- Audit technique ✅
scripts/audit.mjs(skill seo-audit). Monitoring GSC ✅gsc.mjs/gsc-diff.mjs/gsc-digest.mjs(skill seo-monitor). - Cron actif : quotidien 7h (
monitor.sh= pull+diff+alerte Signal) + lundi 7h30 (digest.sh). Préserve le cron geniusprep 6h. - GSC : geniusprep ✅ (wizytics, ~170 clics/28j) · emet ✅ (service account JWT, 0 donnée car neuf).
- Alertes Signal ✅ (
signal-send.mjs, host→172.18.0.4:8080, n° +33766002889, testé). - GA4 : ⛔ aucun tag posé → prérequis. Infra PocketBase + dashboard : pas encore montée (option suivante).
- Coexistence : Claude actifs sur geniusprep (sprints SEO) + emet (contact/Brevo) → lecture seule / coordination.
sitesÉtat SEO par site
État SEO par site
⚠️ Coexistence : d'autres Claude tournent en parallèle sur ces projets (vérifié 2026-06-25 : sessions actives sur
/root/apps/geniusprepET/root/apps/emetexpertise). Avant d'agir sur un site :bash scripts/claude-sessions.sh <site>. Par défaut lecture seule / coordination, jamais de déploiement sous un autre Claude.
Genius Prep — https://geniusprep.com (Next.js + PocketBase, ~3 mois)
- Audit vérifié 2026-06-25 (2 agents) → technique 90/100, schema complet (Course/FAQ/Breadcrumb/Service/Org/Article tous présents), maillage interne fort, robots/sitemap OK (51 URLs). Détails + backlog priorisé :
sites/geniusprep/reports/2026-06-25-gaps.md. - Vrais gaps : cannibalisation ISEE/SSAT (6 doublons), E-E-A-T (aucun auteur nommé), money pages absentes du header, money pages manquantes (Regents, SSAT dédiée, G&T, AP, college counseling), 15 pages écoles sans og:image, titles/metas longs.
- Déploiement : manuel,
docker compose up -d --build. Blog = ISR depuis PocketBase (articles publiés sans rebuild). 3 dossiers existent — canonique = geniusprep.com (genius-prep/geniusprep-dashboard= wizycode.fr).
Emet Expertise — https://emetexpertise.fr (Astro statique, neuf ~10j)
- Audit vérifié 2026-06-25 (2 agents) → on-page excellent (100/100 après fix moteur). JSON-LD AccountingService top, CWV AVIF/WebP, NAP strict, E-E-A-T solide. Détails :
sites/emetexpertise/reports/2026-06-25-gaps.md. - ❌ Corrections de mes affirmations initiales : robots.txt = 200 (pas 404), sitemap via
sitemap-index.xml(20 URLs) — mon premier audit a tapé/sitemap.xmlen dur (faux positif, corrigé dans audit.mjs). Meta description « 9c » = résolue (commitddbd331). - Vrais gaps : hors-site (Google Business Profile + avis absents = plus gros levier), GPS
[A CONFIRMER], couverture de pages (BTP supprimé mais opportunité locale n°1, paie & création sans page, pas de pages villes), blog non surfacé sur la home. - Déploiement : build dans l'image Docker,
docker compose up -d --build. WIP par un autre Claude : migration contact → Brevo/mailer.
2026-07-21 — Emet : résilience Cloudflare (survit à une panne serveur)
Contexte : Ichai a demandé si ses sites survivent à une panne du VPS. Vérifié : NON par défaut — Cloudflare
est un proxy DEVANT le serveur (cf-cache-status: DYNAMIC sur le HTML), pas un hébergeur. Tout est sur UN seul
VPS (82.165.41.252, 79 conteneurs). Données sauvegardées (restic local + Backblaze B2 off-site, backup nocturne 3h),
mais disponibilité non couverte.
Fait pour emet (site STATIQUE) — via le token dans /root/.secrets/cloudflare.env :
- Always Online = ON (zones emet + geniusprep) : sert une copie archivée si l'origine tombe.
- Cache Rule "Cache HTML statique" (zone emet
509ca2441ae2434279e8a4bc3f9313fb) : cache le HTML 4 h à l'edge, exclut/api/(mailer). Testé : HTML → HIT,/api/contact→ reste DYNAMIC (formulaire intact). ⇒ emet reste consultable même VPS éteint (edge cache + serve-stale + Always Online).
⚠️ NOUVELLE RÈGLE DE DÉPLOIEMENT EMET (obligatoire) : le HTML étant caché 4 h, déployer sans purger sert
l'ancienne version. TOUJOURS déployer via bash /root/apps/emetexpertise/deploy.sh (build + up + purge Cloudflare).
Ne plus faire docker compose up -d app seul.
PAS fait pour geniusprep (Next.js DYNAMIQUE) : Always Online oui, mais PAS de cache HTML (casserait les pages dynamiques). Idem pour toutes les apps dynamiques (lync, dashboard, PocketBase).
Non résolu : les apps DYNAMIQUES et les sites en direct-VPS (vpsdashboard.space, lync, cartable, wizycode.fr — IP 82.165.41.252 exposée) ne survivent PAS à une panne serveur. Seule vraie parade = 2e serveur (coût récurrent). Le backup couvre la perte de données, pas l'uptime. RTO estimé pour tout remonter : ~1/2 à 1 journée (69 Go d'apps).
referencesRéférences externes (où trouver quoi)
Références externes (où trouver quoi)
Infos sur l'utilisateur (Ichai) → app chat
Pour TOUT ce qui concerne Ichai (qui il est, objectifs, contexte perso/business, finances, façon de
fonctionner), aller voir /root/apps/chat/ — son CRM/assistant perso, géré par un autre Claude.
⚠️ Lecture seule : ne JAMAIS écrire dans /root/apps/chat/ (coexistence, un Claude y tourne souvent).
Fichiers utiles :
profile.md— qui est Ichai (contexte, objectifs)psychologie.md— comment il fonctionne / le coacherjournal.md— historiqueleads.md— pipeline commercial (dont les clients SEO : Avi Cohen / Emet, Ruben Toledano)finances.md— situation & objectifs de CAplaybook.md— sa méthode de venteCLAUDE.md— instructions de ce projet
Règle : le commercial vit là-bas ; ici (/root/apps/seo) on gère la delivery SEO. On référence, on ne duplique pas.
⚠️ Stack GSC/SEO PRÉEXISTANTE sur geniusprep (NE PAS dupliquer)
Vérifié 2026-06-26 — plusieurs systèmes GSC tournent déjà (crons matin) :
6h/root/apps/geniusprep/scripts/seo-snapshot.sh(snapshot CSVdocs/seo-log.csv)8h/root/scripts/gsc-daily-briefing.sh(briefing — fait DÉJÀ le 7j-vs-7j correct + striking-distance)9h/root/scripts/gsc-monitor.sh(health) · +/root/scripts/gsc-indexing-monitor.sh7hmonitor.sh= le mien, ajouté le 25/06 → DOUBLON à dédupliquer (faire skipper geniusprep, ne garder que l'agrégation cross-site/emet, ou adoptergsc-daily-briefing.sh). Leçon : pour trouver ces crons, grepgsc|seo|brief|snapshot(pas seulementseo).
Rapports d'analyse (workflow 18 agents, 2026-06-26)
reports/2026-06-26-system-review.md— revue système (où faire mieux)reports/2026-06-26-management-plan.md— modèle cible gestion multi-sitesreports/2026-06-26-dashboard-contract.md— design system du dashboard
Field log
Aug 20
Journal — 2026-08-20
- 14:57
[audit]— data.gouv FINALISE (apres crash quota de l'agent externe): reutilisation 'Barometre des entreprises du Val-d'Oise — creations et defaillances (donnees BODACC)' publiee PUBLIQUE sous l'organisation Emet Expertise (creee par l'agent avant son crash), couverture = screenshot live de la page, lien = /observatoire/val-d-oise, rattachee au dataset BODACC (PUT API avec cookie session apres echec du clic UI) + dataservice API BODACC. URL: https://www.data.gouv.fr/reuses/barometre-des-entreprises-du-val-doise-creations-et-defaillances-donnees-bodacc . Pieges notes: mdp data-gouv.env entoure de quotes simples; bouton 'Publier' de l'etape 3 = collision avec le menu nav 'Publier sur data.gouv.fr' (le brouillon se publie depuis /admin/organizations/emet-expertise/reuses); champ Producteur = combobox 'searchable-select-v-rifiez-l-identit...' obligatoire. Le 01 89 52 15 14 verifie VISIBLE en live sur le site (header). Scripts reutilisables dans le scratchpad de session (dg-final.mjs, dg-publish.mjs).
Aug 19
Journal — 2026-08-19
- 16:40
[audit]— Rapport cockpit emet 19/08 (panel 5 angles Opus). DATA: 28j 14 clics/562 impr/pos 18,2; 7j impr +6% pos 17,1; 0 lead formulaire (normal: edge CF = 2-10 sessions FR/jour seulement, reste = bot RO); alerte GSC 17/08 = noindex /avis voulu, benin. DECOUVERTES MAJEURES: (1) miroir WhatsApp mort depuis 03/08 -> 16j a l'aveugle, recadrage du 14/08 jamais prouve livre a Avi; (2) blocage contact@ FAUX depuis 02/08 (a.cohen@ M365 existe) + fiche Ordre deblocable via Comptexpert sans mdp; (3) /contact/merci = 3e page du site, 100% bot (302 'faux succes' du mailer pollue la mesure edge); (4) CTA hero 'Etre rappele' enjambe le formulaire 1 champ (scroll 8132px) + /rendez-vous sans RappelExpress; (5) ts-absent: 519 rejets, 0 tel FR -> critere redondant, patch decide par la donnee; (6) pont9.fr liste les 5 concurrents, pas Emet; (7) reutilisation data.gouv BODACC = lien dofollow .gouv.fr gratuit (migrer /observatoire/ IDF AVANT); (8) intersection backlinks = cul-de-sac (0 dofollow/320); (9) avis compte societe toujours a purger (Nathan, silencieux, jamais signaler); (10) contrarian: 1,2 lead/mois suffit a rentabiliser le retainer -> objectif '3 clients signes tracables/12 mois', apporteurs = 15 intros du portefeuille d'Ichai (pas 40 cibles froides); machine apporteurs du 14/08 = slide (grep: rien). EFFET DE BORD: audit CRO a envoye 2 mails+2 Signal de test a Avi -> prevenir+nettoyer. Rapport archive reports/2026-08-19. NEXT: 7 actions vertes (~1,5j) + 4 decisions Ichai (numero, appel recadrage voix, 15 intros, creneau AnyDesk). - 16:54
[friction]— CORRECTION post-rapport (Ichai: 'le miroir est pas mort, cherche mieux') — il avait raison. Diagnostic exact: les ARCHIVES whatsapp-api (messages-live-.jsonl, volume conteneur) n'ont jamais cesse (fraiches du jour) ; seule la couche markdown contacts/.md etait figee depuis le 03/08 car le CONTENEUR wa-router avait disparu (absent de docker ps -a, cause inconnue). REPARE: wa-router relance (compose up) + backfill one-shot 03->19/08 via script /root/apps/chat/whatsapp/_backfill/backfill.js (81 messages reintegres: david-lamy 50, houny 13, groupe-emet 11, avi 7). Piege: le rejeu par recul de curseur ne marche pas (/api/archive/events renvoie les plus recents -> curseur saute le backlog). INTEL CLIENT recuperee: (1) point du 14 PAS tenu — Avi en vacances ('j'ai pas trop touche l'ordi'), a dit 'vazy' pour le rapport; (2) campagne avis vrais clients demarree 07/08 (1 avis tombe + 2e en route; MAIS 'ton beau-frere semaine pro' = famille encore dans la boucle); (3) Nathan a PRIS un numero sur l'appli le 07/08 (image dans le groupe) et Ichai a dit 'je vais mettre a jour' — site affiche toujours le 07 -> decision numero a moitie prise, suivi manquant; (4) reaction d'Avi au PDF du 16/08: aucune (seul Nathan 👍, reaction non archivee en md). Rapport 19/08 + frictions.md corriges. - 18:55
[audit]— VÉRIF+DÉPLOIEMENT emetexpertise (lot 8 commits du 19/08) : build OK, 0 lien mort sur 33 pages, JSON-LD 6/6 valides, ancien numéro 07 70 38 62 16 absent partout (dist + live). Déployé via deploy.sh (build+up+purge Cloudflare) PUIS rebuild du conteneur SÉPARÉ emetexpertise-mailer (le piège connu). Data mailer = bind mount ./data:/data, intacte (spam.jsonl 3156 lignes). DÉCOUVERTE : leads.jsonl n'a JAMAIS contenu de vrai lead depuis sa création le 16/07 — 2 entrées, toutes des tests d'agents. Rien n'a été perdu, mais 0 lead formulaire en 34 jours = signal business à remonter à Ichai. Live vérifié : 301 barometre->observatoire/val-d-oise, Dataset+DataCatalog+ProfilePage servis, CTA #rappel-express, mailer mode test et rejet inerte 200 conformes. IndexNow OK sur les 3 nouvelles URL. Next: faire remonter le 0-lead + décider si le mode test doit être borné (rate-limit).
Aug 16
Journal — 2026-08-16
- 15:33
[friction]— Envoi du rapport PDF sur le groupe WhatsApp Emet: BLOQUE (3 voies testees: bridge VPS bug groupes/pas de fichiers; WA Web ICHAIPC = QR; WA Desktop ICHAIPC = non connecte). Rien envoye. PDF pret sur Telegram d'Ichai + C:\Temp du PC. Friction loggee avec 2 fixes durables proposes (upgrade Baileys / connecter WA sur ICHAIPC). Attente: Ichai transfere depuis son tel ou connecte WA sur le PC. - 15:42
[decision]— Rapport client PDF envoye sur le groupe WhatsApp SEO EMET EXPERTISE via le bridge (messageId 3EB0F02F4B1965D44D356D, verifie fromMe:true dans l'archive). Pour y arriver: upgrade Baileys 6.7.8->6.7.24 dans whatsapp-api (choix conservateur vs 7.0-rc), breaking change makeInMemoryStore retire -> stub compatible dans src/index.js (endpoints in-memory degrades, archives = source de verite), session WhatsApp CONSERVEE sans re-scan QR (backup prealable /root/backups/whatsapp-sessions-20260816-1839.tar.gz). Decouverte: endpoint /api/send-file existait mais non documente. Skill whatsapp mis a jour (envoi groupes+fichiers OK, protocole de verification post-envoi). Friction du jour marquee RESOLUE.
Aug 15
Journal — 2026-08-15
- 20:13
[friction]— Rapport client Avi V2 apres retour Ichai ('c nul'): relecture INTEGRALE de 3 mois de WhatsApp (avi.md 857l + groupe 232l) pour extraire les promesses exactes -> le rapport devait etre un POINT D'AVANCEMENT (promesses: 13/07 'suivi de position sur les mots cles' + 'rapport mensuel'; 28/06 'rapport sur ce qui a ete fait, a quel point on a avance' + estimations + jalons 1 mois Maps / 3 mois top 3 Sarcelles / 6 mois flux regulier; 02/08 Avi: 'les mots cles mis en avant, le nombre de clics'). FAIT: report.mjs enrichi durablement — section 'Mots-cles mis en avant' (sites//keywords.json avec baseline snapshot, evolution depuis le depart) + note d'avancement curee (note-YYYY-MM.md). Donnees mois 1 vs mois 0: clics 9->17, impr 218->514, pos 27,9->19,1; 'expert comptable sarcelles' 25,9->18,4 (page 3->2, +7 places); marque apparue pos 3,1. PDF 128Ko 2 pages verifie pdftotext, envoye a Ichai sur Telegram. LECON (frictions): un rapport client se calibre sur ce qui a ete PROMIS dans le fil client, pas sur le template — lire le fil AVANT de generer.