Document de travail interne — matiere brute pour le portfolio. Mis a jour le 27/08/2026.

Portfolio — matière brute exhaustive (suite du questionnaire)

Règle : rien d'inventé. Chaque chiffre vient d'un dépôt, d'un rapport de session daté, d'une mesure API ou d'une vérification en production. Quand un chiffre a été corrigé en cours de route, la correction est indiquée — c'est souvent le détail qui rend le reste crédible. Portefeuille concerné : solutio.work/theo (jumeau anglais /en/theo déjà en ligne). theolebreton.com = domaine parqué, inactif, aucune mesure. Période couverte : janvier 2025 → août 2026 pour Solutio ; 2018-2023 pour le salariat.

PARTIE 0 — Avertissement d'architecture (à lire avant d'appliquer le plan du chat)

Le plan proposé (Hero → business outcomes → full business loop → Selected Work → systems → CS deep dive → recommendations → how I work → what I'm looking for → tools/certifications/contact) entre en collision avec trois décisions déjà prises et appliquées sur /theo. À arbitrer consciemment plutôt qu'à écraser :

1. « Ce n'est pas un portfolio que tu as fait, c'est une copie du CV » — retour explicite, 21/08/2026. La page a été rebâtie sur des preuves ouvrables : 6 ressources cliquables (démo de la plateforme sans mot de passe, TrouveMonSaaS, Carto, Solutio Suite, un site client, le portefeuille Credly), 8 vidéos produit, 8 études de cas, 6 principes adossés à un fait, une section « comment je travaille ».
2. Sont bannis de la page (décision du même jour) : parcours, formation, certifications, liste d'outils, le cas « 0 → 350 k€ », et la photo. Tout ça vit dans le CV, envoyé au cas par cas. Le plan du chat réintroduit certifications + tools + recommendations : c'est un revirement, pas un ajout.
3. Les clients sont anonymisés sur la page (« négoce de matériaux multi-agences », « un indépendant », « un cabinet de conseil », « un restaurant-traiteur »). La règle a été inversée deux fois en une journée : d'abord tout en clair (PIX, FFB, Gendarmerie, Bouygues E&S…), puis re-anonymisée. Réserve jamais tranchée : aucune vérification qu'une clause du contrat Tinycoaching n'interdit de nommer les clients.

Ce que le plan apporte de neuf et qui manque vraiment : le niveau « raisonner sur le système » (la 4ᵉ lecture). C'est exactement ce que la matière ci-dessous permet de construire — sans transformer la page en CV, en le mettant derrière des replis/modales comme le chat le propose.

Note de forme, déjà tranchée sur ce périmètre : registre nominal, minimum de « je », zéro jargon technique dans la copie lue par un dirigeant (« prod », « multi-tenant » bannis ; les tags de stack restent comme preuve). Et la copie passe un contrôle anti-tics d'écriture avant publication.

PARTIE 1 — Compléments aux réponses déjà données

1.1 Prospecting / scraping / data — la machine, en détail

Le pipeline, tel qu'il tourne (dépôt prospection, Python, base Postgres) : source → scraping → nettoyage → enrichissement → qualification → séquence → CRM

Les 1 101, segment par segment (la réponse précise à la question du chat) :

• 330 cabinets M&A / transmission — sources Fusacq + CNCFA + Infocession. 110 avec URL LinkedIn, 178 avec site web.
• 545 cabinets RH / Stratégie / Généralistes — Syntec (250) + annuaire du conseil (440) + réseaux de franchise, dédupliqués.
• 226 repreneurs d'entreprise — délégués CRA, Réseau Entreprendre, Initiative France, search funds, signataires d'un manifeste de repreneurs.
• Sortie : 5 fichiers CSV au schéma d'import LinkedHelper 2 (ProfileLink, CompanyLink, Company, FirstName, LastName, Position, Email, Website, Industry, City, Country, Tags), le champ Tags encodant segment|priorité|source pour piloter les smart-lists.

Ce qu'est un « critère de qualification » ici : un fichier spec.yaml par campagne, qui déclare code NAF + intitulés de poste LinkedIn + règles de scoring + pipeline de traitement + exclusions dures. Deux exclusions racontent la méthode mieux qu'un discours :

• le client en cours est exclu du ciblage (c'est un client, pas un prospect) ;
• zéro crédit Pappers sur ces deux campagnes — les crédits payants sont réservés à l'aval de la conversion, l'amont tourne sur INSEE / recherche-entreprises / PagesJaunes / LinkedHelper / Tavily / recherche d'e-mail en offre gratuite.

Sources réellement utilisées, au-delà de celles déjà citées : Google Maps (via Outscraper), Tavily (recherche et extraction), LinkedIn + Sales Navigator + LinkedHelper, INSEE / recherche-entreprises.gouv.fr, Pappers (rationné), PagesJaunes, Fusacq, CNCFA, Infocession, Syntec, l'annuaire de l'Ordre des experts-comptables, CRA, Réseau Entreprendre, Initiative France, BODACC/SIREN (côté produit, pour l'enrichissement automatique d'une fiche entreprise).

Deux listes nominatives construites à la main-machine, jamais achetées : 41 artisans de la métropole rouennaise (dont ~33 sans site web, sources citées ligne à ligne) et 31 cabinets comptables Rouen / Le Havre (petits et indépendants, réseaux nationaux exclus).

Règle dure du système : ne jamais écrire à une adresse déjà présente dans la table des séquences d'un autre outil. Le déduplicateur est inter-produits, pas intra-campagne.

1.2 Cold email — la partie infra, chiffrée

• Domaines, SPF/DKIM/DMARC, warm-up, cross-emailing, inscriptions en annuaires : fait à la main, sur des domaines déjà détenus.
• Un seul modèle d'envoi approuvé (cold_single.py), décision écrite et datée : plusieurs runners = double envoi garanti un jour ou l'autre.
• Transactionnel séparé du prospectif : Resend pour les alertes et accusés de réception, domaine vérifié par DNS (TXT DKIM + MX chez l'hébergeur). Sur le plan gratuit, l'expéditeur doit être le domaine vérifié — contrainte assumée.
• Landing personnalisée par prospect, générée automatiquement (agent d'outreach dédié). C'est le cas le plus fort à montrer.
• Accusé de réception ajouté des deux côtés d'un tunnel de leads (acheteur + éditeur), avec le texte qui reprend la promesse de la page et rien de plus (« réponse écrite sous 48 h ouvrées, devis avant tout engagement »).
• Garde-fou anti-flood posé côté base : 20 alertes maximum par tranche de 10 minutes.

Un blocage assumé, jamais contourné : la liste d'attente d'un produit ne peut pas être écrite tant que le double opt-in n'est pas branché — sans preuve de possession de l'adresse, un tiers peut inscrire quelqu'un. C'est écrit comme bloquant dans le dépôt et ça n'a pas été forcé.

1.3 LinkedIn — deux corrections de chiffres

• Page entreprise : 0 → 2 000+ abonnés (le « 3 000 » qui traînait dans mes notes était faux, corrigé le 21/08/2026).
• Réseau personnel : 500 → 5 000+.
• Stack de prospection réellement déclarée sur le profil : LinkedIn, LinkedHelper, Hunter.io et Make — Make manquait dans les notes et manque dans la réponse actuelle du chat.

1.4 Ce que le salariat porte comme chiffres (source : profil LinkedIn, qui fait foi)

Tinycoaction = DEUX postes qui se chevauchent, pas un. LinkedIn les groupe sous « 4 ans » ; les écraser en une ligne détruit exactement la progression growth → founding sales qui fait l'intérêt du profil. (Et c'est quatre ans, pas cinq — une note interne disait cinq, corrigée à la source.)

Chiffres consignés, tels qu'énoncés par Théo : CA de la société 0 → 350-450 k€ stable (pas un book personnel — le fondateur co-closait certains dossiers), 20+ contrats dont des récurrents, ACV entreprise 10-50 k€, cycles 6-10 mois, 6+ interlocuteurs par dossier. Comptes : OPCO, PIX (débloque un partenariat national), Fédération Française du Bâtiment (exclusivité via appel d'offres national), Gendarmerie nationale (pilote puis référent), Bouygues Energies & Services, Cotral, EM Caen, Digifab, CEREF. Méthode de vente employée : méthode de l'Échiquier (française, inconnue à l'international — à expliquer si le lecteur est étranger).

Deux stages réels retirés du portfolio le 21/08/2026 (décision assumée : ils diluent en 2026) : Saint-Gobain / Placoplatre mars→août 2018 — analyse de données sur bases clients avec Marketo, segmentation, ciblage, reporting — et un stage à Bangkok sept. 2016→janv. 2017. Marketo survit dans la section stack ; c'est la seule provenance de cette compétence.

Autres éléments factuels du dossier : TOEIC 955, EDHEC, 13 badges Credly (mesuré au navigateur le 21/08 — pas 8 : Google Career Certificates et IBM SkillsBuild s'y ajoutent), 2 certifications Anthropic hébergées ailleurs (verify.skilljar.com), HubSpot Academy encore ailleurs. Basé à Rouen, 100 % remote, siège La Bouille (76530), code APE 70.22Z conseil de gestion.

PARTIE 2 — SEO / SEO programmatique / GEO (bloc 8, en entier)

2.1 TrouveMonSaaS — la chaîne complète

Le catalogue. 721 fiches SaaS dans src/data/catalog.ts (8 971 lignes), 35+ catégories, marché français. Ce fichier n'est pas écrit à la main : il est généré par un pipeline Python séparé (affiliate-agent/sync_catalogs.py) qui alimente aussi le second site. Une source, deux consommateurs — et une règle : on n'édite jamais un fichier généré.

Trois décomptes à ne jamais confondre (leçon prise sur mon propre site) :

• 2 154 pages construites au build
• 1 540 URLs déclarées au sitemap
• 963 pages uniques réellement vues en Search Console sur 28 jours

Un audit qui mélange les trois raconte n'importe quoi. Le mien le faisait (« ~1 169 pages ») jusqu'à remesure.

Les gabarits (c'est ça, le programmatique — une dizaine de templates, pas 2 000 pages écrites) : /saas/[slug] · /comparer/[a]-vs-[b] (507 pages) · /alternatives/[slug] (713) · /alternative-francaise/[slug] (13) · /categorie/[slug] (21) · /comparatif/… (21) · /meilleur/… (68, passées en noindex, follow) · /ressources/… (40 guides) · /editeurs · /catalogue · /recommandation (le quiz) · locale /en.

Recherche de mots-clés → ce que la donnée a réellement dit.

Les impressions ont fait ×400 sans un clic de plus. Et j'avais ouvert le dossier sur la prémisse inverse (« nos impressions ne décollent pas ») : elles décollaient depuis quatre mois. Diagnostiquer le symptôme annoncé aurait produit un plan pour un problème inexistant.

Par surface, 180 jours :

Et la conclusion contre-intuitive : j'avais attribué la dérive de position aux « pages fines programmatiques ». Faux. En retirant chaque gabarit du calcul pondéré : retirer /saas dégrade la moyenne de 9,74 points, retirer /comparer la dégrade de 0,38 — ces deux-là tirent vers le haut. Le seul poids mort est /categorie. Un gabarit se retire pour un budget de crawl, pas pour une position.

La niche qui gagne, mesurée sur 4 654 couples requête×page :

La niche résiste à ses deux objections : sans les sondes automatisées, médiane 10,3 ; sans les sondes et sans la catégorie tête-de-pont, médiane 10,0 et 53 % en top 10 sur 219 lignes, contre 4 % pour le générique. Facteur 13, même domaine, même autorité, même semaine.

Le motif qui marche, et qui est outillé : CATEGORY_RESOURCE fait passer la main de la page catalogue au guide qui répond réellement à l'intention. Effet mesuré sur « quelle API de signature électronique… » : la page catégorie passe de 120 impressions en position 72,3 à 12 en position 80,9, pendant que le guide tient la position 1,7. Étendu le 27/08 sur cette preuve à erp (42,7 → 20,0), hr (75,8 → 9,2, le plus grand écart du site) et ecommerce (42,3 → 11,5). Écartées sciemment : billing (ni l'une ni l'autre ne sort) et recrutement (7 impressions). Le fait d'écarter deux cas sur cinq est ce qui rend le geste sérieux.

La cannibalisation, chiffrée : 405 requêtes servies par 2+ pages du site (11 171 impressions), et 42 % de ces impressions vont à une page moins bien classée qu'une autre du même site. Cas type : le guide en position 1,4 reçoit 83 impressions, la page catégorie en position 72,3 en reçoit 120 — Google montre la mauvaise page plus souvent. → faire posséder chaque intention par une seule page AVANT d'écrire de nouveaux guides.

Le zéro-clic en position 1-5, disséqué : 1 992 impressions en position 1-5, 0 clic. Deux familles, et aucune ne se répare par un meilleur titre : 1 272 impressions viennent d'une requête anglaise (« human resources software ») servie par une page française ; le reste sont des questions conversationnelles en position 1,5-5,4 — signature d'une réponse déjà affichée dans la SERP. Décision associée : ne pas indexer la version anglaise pour capter ce volume — ce serait du trafic hors cible sur une métrique qui ne convertit pas.

Les responsables nommés (28 j) : bamboohr 3 385 impressions position 7,5, 0 clic ; wave accounting 1 022 à 7,9, 0 clic. Qui tape « bamboohr » veut bamboohr.com. Une fiche d'annuaire classée 7ᵉ ne peut pas convertir. Ce n'est pas un défaut de CTR à corriger, et le dire évite un chantier inutile.

Structure d'URL et redirections : passage de l'underscore au trait d'union, 651 URLs migrées, 706 redirections 308 dans la configuration de déploiement, 683 vérifiées en production (échantillon 120/120 testé une par une). Piège coûteux trouvé au passage : le fichier public/_redirects est totalement inerte sur cet hébergement — ses 28 règles rendaient 404 en production. Seul vercel.json redirige. Et un contrôle de redirection ne se fait jamais avec curl -L, qui suit la redirection et affiche 200 quoi qu'il arrive.

Titres / metas : 185 titres au-dessus de 60 caractères ramenés sous le plafond via une fonction dédiée + un champ seoTitle distinct du titre affiché.

Données structurées : JSON-LD vérifié sans défaut sur les 1 540 URLs. Sur le site client local, l'audit a trouvé un @type: "Caterer" qui n'existe pas dans le vocabulaire schema.org — le bloc était donc invalide sur 37 pages sur 37 depuis un seul composant. D'où un script qui valide le JSON-LD rendu (dist/) contre le vocabulaire officiel, volontairement hors du build pour qu'une régression SEO ne bloque pas une mise en production client.

Search Console : propriété administrée sans passer par l'interface — compte de service + Site Verification API + enregistrement TXT posé par l'API DNS de l'hébergeur, puis sites.add. Le compte de service est siteOwner sur trois propriétés. 🔴 Détail qui a coûté trois propositions inutiles : la voie « Paramètres → Utilisateurs » est morte — Google refuse un compte de service depuis un bug reconnu du 20/04/2026, sur GSC et GA4. La vérification DNS n'est plus une commodité, c'est la seule voie. Corollaire client : sans accès au DNS, aucun accès GSC par API.

Premier relevé TMS (90 j, 17/07/2026) : 38 clics · 5 769 impressions · position moyenne 20,1 ; 622 requêtes distinctes, 188 pages en SERP, 150 requêtes en position 8-20. Le site rankait déjà — en bas de page 2.

Autorité (Ahrefs Webmaster Tools, 19/08/2026) :

3 700 liens pour 15 domaines qui transmettent quelque chose. Le plafond n'est pas le nombre de liens, c'est le DR.

Citations IA, enfin mesurées (c'était le « point aveugle irréductible », aucune API Google ne l'expose) :

40 réponses IA, 37 pages citées. GA4 n'en voyait que 12 sessions, parce qu'il ne compte que les citations cliquées. Et les assistants citent les pages d'entité, pas les pages de question — ce qui contredit l'intuition de départ.

Pages crawlées : 5 373, dont 19,6 % en 404. Audit du dist/ : sur 108 388 liens internes, 8 seulement pointaient vers un 404 — le reste est de l'historique gardé par le crawler. Les 8 corrigés, dont le pire : 4 guides envoyaient vers /quiz, qui n'a jamais existé (le quiz est à /recommandation). Verrouillé par un test, deux mutants tués.

Génération IA — et ce qu'elle a cassé (le meilleur matériau « échec » du dossier) :

• Le prompt donnait {"prix": "XX euros/mois"} en exemple. Le modèle recopiait l'exemple quand il ne savait pas : 90 % des fiches recopiaient ["Tous secteurs"], 17 % ["Slack","Google Workspace"], 11 % le XX. Les champs de prose libre : 0 % de fuite — le modèle recopie le structuré et rédige la prose. C'est un résultat exploitable en soi.
• 268 fiches affichaient un plan « Gratuit » semé par le pipeline (jusqu'à 61 % du catalogue).
• 423 descriptions et 230 avis coupés en plein mot ; la signature du défaut n'est pas le style, c'est la longueur fixe (200 et 300 caractères). Nuance trouvée ensuite : sur /saas l'ellipse est honnête (la source est coupée) — 594 fiches ; c'est sur /alternatives que le gabarit s'amputait lui-même (deux budgets divergents, 165 contre 155), 74 pages, corrigé, 0 en production.
• 14 fiches publiaient la consigne du prompt en clair.
• 19 fausses nationalités en base (des éditeurs indiens, australiens, britanniques vendus comme « français »).

→ Correctif structurel : un validateur branché sur le chemin d'écriture (il a attrapé 764 fiches contaminées), pas un contrôle a posteriori.

Le bug le plus instructif du site (à raconter tel quel en entretien) : le champ alternatives contenait des noms d'affichage, pas des slugs. Sur 1 767 références déclarées, exactement 1 était un slug valide. Donc les 713 pages /alternatives tournaient à 100 % sur le repli par catégorie, dans l'ordre alphabétique — depuis toujours, sans un test rouge. Effet visible : « alternatives à Workday » proposait un logiciel de gestion d'adhérents associatifs. Un helper qui échoue vers undefined masque une fonctionnalité morte : .map(...).filter(Boolean) ne lève jamais. Le test qui l'attrape n'est pas « la page affiche des alternatives » (elle en affichait) mais « chaque alternative rendue figure dans la liste déclarée de l'outil source ». Et ce défaut est revenu deux fois le même jour, dans deux autres fichiers indexés sur l'autre forme du même identifiant : 7 pages ont perdu leur bloc d'équivalents prouvés, puis 151 fiches sur 165 ont perdu tout leur « Notre avis » — build vert, 879 tests verts, rien signalé. Ce qui l'attrape : une assertion sur le HTML construit, avec les entrées non affectées comme témoin (8 % contre 56 % sous le défaut ; 93 % contre 95 % après correction).

Affiliation : ~188 programmes signables identifiés, 721 programmes suivis, 27 liens vivants, 316 programmes non signés, 349 sans piste. 21 outils réellement monétisés (un lien retiré : son DNS ne résolvait pas). 4 liens signés ne sont pas sur le site — obtenus après la mise en pause du script de synchronisation : du revenu acquis, pas câblé. Source de vérité = la table cart_affiliate_tracking, jamais le fichier catalogue généré. L'API PartnerStack est accessible via un serveur MCP écrit pour l'occasion ; ⚠️ Cloudflare rejette les clients Python standards (erreur 1010), il faut un User-Agent de navigateur.

2.2 Le démontage des concurrents (audit de 3 annuaires, sitemaps réels + 11 pages capturées au navigateur)

Ce qu'on en apprend :

• SaaSHub n'a AUCUN JSON-LD. 626 000 pages, zéro balisage sur les 4 gabarits testés. Ils rankent par volume + maillage (355-417 liens/page) + fraîcheur affichée → le sur-balisage schema n'est pas le levier qu'on croyait.
• Leur meilleure idée = 234 470 pages « statut » (Is Slack down? NO) : intention à gros volume, concurrence nulle, récurrente, et qui boucle vers les alternatives. ⚠️ Non copiable sans monitoring réel — sinon c'est de la donnée inventée.
• Le titre pose une question, la meta donne la réponse — formulation liftable telle quelle par une AI Overview.
• softwarefinder = auteur humain nommé + photo + LinkedIn + « Last Updated », et un disclaimer de provenance honnête à voler tel quel.

Le « trou du marché » que j'avais identifié — et qui a été démenti par ma propre mesure. Personne ne couvre « prix {logiciel} » à l'échelle chez les annuaires américains (11 pages / 50 pages). J'en ai conclu un trou. Faux en France : « lemlist prix », « organilog tarif » renvoient chacun 5-7 pages tarifaires dédiées (LeBonLogiciel, Logiciels.Pro, Capterra). Le thème prix pèse 4 % de nos impressions. L'absence chez les annuaires anglophones ne vaut pas absence de concurrence en français : vérifier la SERP de la LANGUE cible avant de bâtir un programme éditorial dessus.

🔴 Règle posée par le client (moi, dans ce cas) et que j'avais violée : j'avais mis AlternativeTo et SaaSHub dans la liste des annuaires où soumettre le site. Ce sont les concurrents directs sur la SERP. Liste noire depuis : Appvizer, Capterra, GetApp, Software Advice, G2, SaaSHub, AlternativeTo, SaaSworthy, softwarefinder. Et une distinction que la liste ne faisait pas : un annuaire (on soumet un formulaire) n'est pas une cible de pitch (Maddyness, Journal du Net, Blog du Modérateur — on envoie l'étude). Les mélanger produit une todo inexécutable.

2.3 Le site principal — de 2 pages indexées à un site sain

Le fait qui commandait tout, mesuré via l'API URL Inspection (autoritaire, contrairement au champ indexed du rapport sitemap, déprécié et faux) : 2 pages indexées sur 48. 90 jours : 56 impressions, 0 clic. Pages techniquement saines (HTML statique, H1 unique, canonical, 1 150-2 240 mots). Cause = autorité, pas technique ni contenu. Corollaire dur, écrit noir sur blanc : tant que l'indexation n'est pas réglée, écrire du contenu ajoute des pages « détectées, non indexées ». Ne jamais partir sur un silo de contenu avant les liens.

Puis, un mois plus tard : 21/54 indexées (39 %). Le travail payait.

Un cloaking trouvé et tué. Un middleware de mars 2026 servait aux robots un HTML codé en dur périmé sur 10 routes — avec les prix de mars sur une page produit. Réécrit de 624 à 98 lignes : zéro logique d'user-agent, vrais 404 via une liste blanche générée au build. Parité robot/humain vérifiée en production après déploiement. C'est le genre de chose qu'on ne trouve qu'en regardant ce que le serveur répond à Googlebot, pas ce que la page affiche.

Les hypothèses testées et mortes (celles-là valent de l'or dans un portfolio, personne ne les publie) :

• « MCP pour votre levée de fonds » → volume nul, zéro page française ne lie les deux notions. L'offre peut être bonne : le SEO n'est pas le canal.
• « MCP » générique → SERP française saturée (IBM, Cloudflare, Red Hat, Databricks, Google Cloud, Wikipédia, l'État) et agences françaises déjà installées. Bonne surprise : « MCP » n'est pas polysémique en français (9/10 = le protocole). Le problème est la concurrence, pas l'ambiguïté. Piège : « créer un serveur » ramène des serveurs Minecraft.
• Tutos/prix/avis Claude Code, Cursor, Lovable, vibe coding → saturés en français.
• Le message « c'est puissant mais ça prend du temps, formez-vous ou je le fais » → c'est le playbook standard du marché français depuis ~18 mois, même CTA, six concurrents nommés.
• « Mon app Lovable est-elle RGPD » → pas un trou (erreur annoncée puis corrigée en séance) : un concurrent possède le créneau avec 233 URLs et un scanner gratuit.
• Levée de fonds / deck / BPI / subvention → forteresse et mauvaise intention. Double disqualification.

La leçon de méthode, transposable : chaque niche annoncée « vide » par un agent s'est révélée occupée à la vérification. Quand un angle paraît évident, il l'a été pour dix autres 18 mois plus tôt. Deux agents se sont même contredits ; la vérification a tranché.

Le pivot qui en sort : la « forteresse » institutionnelle (BPI, France Num, CCI, incubateurs) qu'on ne peut pas battre en SEO est le canal de distribution. Ne pas la combattre, s'y faire lister. Un lien .gouv.fr règle la cause racine et amène des clients déjà financés. ⚠️ Et le contre-fait qui tue une thèse trop simple : la fiche Activateur France Num existait déjà, avec un lien dofollow — et le site restait à 2 pages indexées sur 48. Donc « un lien institutionnel débloquera l'indexation » est FAUX. Il faut du volume de liens ET du contenu. (Au passage : j'ai perdu cinq agents à recommander une inscription déjà faite, faute d'avoir lu le contexte avant de chercher.)

Échelle, pour situer : axopen.com 2 614 URLs · yieldstudio 448 · galadrim 362 · swoft 258 · flowlab 233 · le site 48 (2 indexées). La guerre du volume est perdue d'avance ; la différenciation est la posture (une agence au jour-homme ne peut pas écrire « dans 3 cas sur 10, ne me payez pas, faites-le avec Claude Code »), la cible et la preuve chiffrée propriétaire.

Vocabulaire — l'observation la plus réutilisable : le vocabulaire d'achat n'est pas le vocabulaire du besoin. Un fondateur pré-seed ne tape ni « MCP » ni « levée de fonds » : il tape « combien coûte un MVP ». Anomalie de marché : 9 résultats sur 10 sont de petites agences, zéro institution, zéro média, zéro marketplace. Le mot « MVP » fait basculer la SERP de finance/conseil vers build/agence. Et l'argument dominant du marché français n'est pas « gagner du temps » mais le patrimonial (« le SaaS est un loyer, le sur-mesure est un actif au bilan ») plus l'anti-Excel.

Conversion, mesurée sur 61 pages (90 j) : 1 clic / 319 impressions. 34 pages indexées, 15 « découvertes non indexées », 8 inconnues de Google. Trois causes trouvées et corrigées :

1. /contact = page la plus vue du site (64 impressions, position 6,8) et sans aucun formulaire (un QR code et un mailto).
2. Les guides avaient 2 liens internes entrants chacun → jamais crawlés. Registre de liens produit→guide et guide→guide : passés à 4-13 entrants.
3. Premier CTA de conversion après 60 % de la page → bloc injecté à ~20 %.

Découverte annexe : le pied de page était en position:fixed; height:100vh et peignait par-dessus le dernier écran de chaque page. La barre « Un projet, une question ? » de ~50 pages n'a jamais été lisible par personne.

Performance — le gain le plus net, prouvé en ligne : les pages générées chargeaient deux feuilles de style bloquantes (~86 Ko). Extraction du CSS critique above-the-fold, inliné, le reste déféré → une page produit passe de 90 à 100, FCP 2,1 → 0,9 s, LCP 2,9 → 0,9 s, articles à 100/100. Trois pièges de FOUC corrigés au passage, dont un vicieux : **Chrome drop les var() en raccourci lors de la sérialisation CSSOM (background:var(--bg) devient vide → page blanche) — il faut mettre la couleur en dur dans le critique. Et l'aveu qui va avec : mon constat précédent « plancher inhérent, ne pas chasser » était faux** — l'écart de FCP était le levier.

Un jank de scroll, résolu par ablation mesurée et non par intuition. Symptôme : toutes les pages saccadaient sauf la home. Trois fausses pistes écartées par la mesure (la bibliothèque de scroll, un double fond fixe, les flous décoratifs). Cause réelle : backdrop-filter: blur(2px) sur les cartes — une page produit en affiche 15 à 25, soit 26 surfaces de flou ré-échantillonnées à chaque frame. La home n'a aucune carte : d'où l'exception. Mesuré : 33,3 ms → 16,7 ms de frame médiane (30 → 60 fps), p90 50 → 33 ms. Méthode réutilisable : charger la page, injecter *{backdrop-filter:none!important} puis chaque suspect isolément, re-mesurer sur un scroll à pas fixe. En headless les valeurs absolues ne valent rien, les comparaisons entre variantes de la même page sont fiables. Et une leçon de portée plus large, payée deux fois : quand seul un sous-ensemble de pages dysfonctionne, diffuser dans le code ce que ces pages chargent en plus — ne jamais régler ça en touchant une configuration partagée. Un réglage global « corrigé » a cassé les deux pages que le client jugeait parfaites.

2.4 SEO local (site client traiteur) — la part réellement tenue

• Technique : Astro, DNS apex en ALIAS vers l'hébergeur du site avec conservation des NS chez le registrar pour ne pas casser l'e-mail, certificat auto, CSP + 5 en-têtes de sécurité, sitemap, llms.txt, robots ouverts aux 15 crawlers IA.
• État au 27/08/2026 : 35/35 URLs en 200, 0 titre > 60 caractères, 0 description > 160, 0 image sans alt (38 alt ajoutés, 270 images couvertes), JSON-LD valide, canoniques complets, zéro lien interne cassé, zéro page orpheline. Audit Ahrefs : Health 100, 0 erreur.
• Search Console (90 j) : 162 clics / 7 685 impressions. La marque fait ~54 % des clics. /le-smoker porte 3 705 impressions en position 22,3 — le problème est le rang, pas le titre. Et le gisement rentable : « barbecue normandie » (185 impressions), « barbecue eure » (156), « barbecue en normandie » (113) — position 6-8, CTR nul. 10 articles publiés pour cibler ces requêtes mesurées.
• Le maillage suivait la date, pas le sujet : le bloc « à lire aussi » servait les trois articles les plus récents → 15 des 19 articles ne recevaient aucun lien, pendant que les trois derniers en captaient 18 chacun. Nouvelle règle : deux par tags partagés + un par rotation alphabétique qui garantit qu'aucun ne reste à zéro (le tri par tags seul laissait 5 orphelins, une grappe se refermant sur elle-même). Résultat mesuré sur le HTML rendu : 15 orphelins → 0, min/max 0/18 → 2/11.
• 14 titres dépassaient 60 caractères, dont 10 par le seul suffixe de marque ajouté sans condition par le gabarit. Il ne s'ajoute plus quand il ferait déborder.
• Contrôle qualité devenu bloquant sur trois règles neuves (titre, description, article sans lien entrant), chacune avec son témoin vérifié. ⚠️ Et la limite du témoin est documentée : « délier un article » ne prouve rien tant que ses autres entrants existent — il faut neutraliser les 121 liens /blog/ du build.
• www servait un 200 au lieu de rediriger : pages dupliquées dans GSC. Corrigé par une redirection 308 host-based. Le même défaut est revenu sur la racine (la règle ne matchait pas le chemin vide) et expliquait à elle seule les « 19 redirections d'image + 18 3XX + 2 HTTP→HTTPS » de l'audit.
• Local : fiche Google, 14 avis réels 5/5 intégrés en carousel + AggregateRating, areaServed, et un ancrage géographique du retrait uniquement (le traiteur reste « Normandie », c'est le point de retrait qui porte « à 20 min de Rouen, 76 ») — anti keyword-stuffing assumé.
• Hors-ligne au service du local : flyer A5 + carte de visite (HTML/CSS → PDF Chromium, QR vectoriel vers la fiche Google) pour alimenter le flux d'avis. Zéro Canva.
• Identité légale reconstituée depuis Pappers (SIREN, forme, adresse) → mentions conformes LCEN.
• Ce que je n'ai pas fait : inventer. priceRange manquait dans le schema → demandé au client plutôt que rempli. Les « horaires manquants » n'en sont pas : le modèle est une pré-commande hebdomadaire fermant le mardi soir, pas une boutique — les omettre est correct. Et quand l'app mobile a été abandonnée (décision client du 13/08/2026), le mode de règlement n'était plus décrit nulle part : le trou est signalé comme trou, pas comblé au jugé.

2.5 Mesurer la performance — l'instrument est aussi en test

• PageSpeed sert une analyse en cache. Trois appels rendaient le même horodatage d'analyse. Le tableau de bord affichait « médiane de 3 runs » : c'était une mesure recopiée trois fois avec l'apparence d'une méthode. Corrigé en agrégeant sur les analyses distinctes et en publiant leur nombre (relevé réel : 1 sur 3 en mobile, 2 sur 3 en bureau).
• PSI est bimodal sur ces sites. Cinq appels, trois analyses distinctes : 100 / 74 / 74 / 98, LCP de 1,7 s à 6,8 s. Aucun chiffre unique n'est vrai, et une médiane sur ces valeurs non plus.
• L'instrument fiable est le navigateur : Chromium, viewport 412×823, DPR 2,6, conditions Lighthouse mobile exactes (1,6 Mbit/s ↓, 750 kbit/s ↑, 150 ms de latence, CPU ×4) et un PerformanceObserver sur largest-contentful-paint — qui nomme l'élément, ce que PSI refuse. Relevé : 748-780 ms (H1 texte) / 1 492-2 060 ms (sous-titre du hero) / 772-860 ms (poster vidéo). Les trois sites sont sous le seuil de 2,5 s et aucun LCP ne dépend d'un tiers.
• ⚠️ Et le piège vérifié dans mon propre outil : un * 10 de trop dans le débit rendait 476-608 ms au lieu de 748-780. Le bridage se relit avant de conclure.

PARTIE 3 — Cycle client : activation, adoption, satisfaction (blocs 13 à 19)

3.1 Ce que « activé » veut dire quand on l'instrumente soi-même

Sur mes propres produits, l'activation n'est pas déclarative. Elle est mesurée, et surtout elle refuse de mentir :

• Chaîne de mesure maison sur 6 sites : 7 collecteurs (santé HTTP, Search Console, GA4, performance, dépôt git, DNS, Ahrefs) + un huitième pour les déploiements, 5 tables, 84 tests, un tableau de bord, 6 agents et 6 tâches planifiées.
• Règle de conception du tableau de bord : il refuse d'afficher un chiffre dont il n'est pas sûr. Aucun chiffre pour une source cassée depuis moins de 48 h ; « indisponible » et son motif plutôt qu'un tiret qui se lirait comme un zéro ; « réponse illisible » plutôt qu'une liste vide quand l'API change de forme. Une page de suivi qui ment en silence est pire qu'une page en panne.
• Sur l'outil de climat social : seuil d'anonymat (pas de restitution sous n=5), tendance N-1, key-driver par corrélation de Pearson entre chaque item et l'eNPS, analyse des verbatims, export PPTX.
• Et le raffinement qui compte : masquer une ligne ne suffit pas, la soustraction la rend. Publier « Production n=10 » à côté d'un total de 11 livre la 11ᵉ personne. Règle retenue : fusionner les petits groupes dans « Autres », et si « Autres » reste sous le seuil, ne pas publier le découpage du tout.
• Corollaire sécurité appris le même jour : masquer un bouton ne ferme pas une URL. Le formulaire restait atteignable par son paramètre ; la garde appartient aux fonctions serveur, pas à l'affichage.

3.2 Le cas « problème produit vs problème de déploiement », vécu

Le site principal remontait 0 session GA4. Premier diagnostic : le bandeau cookies. Faux — et plausible. Le « 0 requête avant consentement, 1 après clic sur Accepter » mesurait en réalité une interaction, pas un consentement : le script était chargé au premier scroll|click|keydown|touchstart, avec un repli à 7 s. Consent Mode v2 était déjà en place et n'a jamais rien bloqué.

Ce qui a tranché : un triplet de mesures au navigateur, en production —

Un seul de ces chiffres ne prouve rien. Le triplet distingue « la mesure est absente » de « la mesure est différée » — deux causes qui donnent le même 0 au premier relevé et appellent deux correctifs opposés. Le commentaire du code affirmait d'ailleurs « no pageviews lost », à côté du code qui le contredisait.

Et la correction a été faite à moitié la première fois : j'ai corrigé index.html, mesuré un build local à 3 requêtes, déployé — et la production est restée à 0. Le script de build fait cp dist/home.html dist/index.html : le gabarit servi est un autre fichier. Deuxième passe, deuxième commit, vérifié sur la vraie chaîne.

3.3 Satisfaction — l'outil, pas seulement la pratique

L'outil de mesure du climat (Pouls) contient ce qu'un praticien voudrait : questionnaire type sur 0-10, eNPS (part de promoteurs moins part de détracteurs), heatmap par service, tendance N-1, key-drivers, analyse IA des verbatims, exports. Il sert aussi de produit vendu — c'est le même objet.

Extension livrée en juillet 2026 : un audit d'acculturation IA des équipes, livré comme un jeu de questions à l'intérieur de l'outil existant plutôt qu'en application dérivée. Raison assumée : forker aurait dupliqué ~6 300 lignes de rapport et d'export, alors que le barème restait 0-10 par construction (auto-évaluation notée telle quelle, mise en situation = % de bonnes réponses × 10). Trois invariants ont été verrouillés par des tests pour que l'ajout ne contamine pas les campagnes clientes en cours — dont un cas d'école : les 18 nouveaux items sont inactifs en permanence, parce que tous les lecteurs historiques filtrent sur « actif » sans filtrer sur le jeu de questions, y compris un bundle déjà en cache dans un onglet ouvert.

Et une leçon d'ordre opératoire qui vaut pour toute mise en production : semer les données avant de déployer le code = fuite en direct. J'ai créé une vraie exposition sur 6 campagnes clientes ouvertes en insérant les items avant que la garde ne soit déployée. Ordre correct : code d'abord, données ensuite.

3.4 Voice of Customer → produit, ce qui est traçable

Fonctionnalités réellement nées d'un besoin exprimé ou d'un usage observé, et livrées : notation de risque financier (Altman Z'' + capacité de remboursement, note 0-100 / A-E), benchmark sectoriel percentile (avec le bug de correspondance casse/accent corrigé au passage), garde-fous de seuil n=5, kanban à 3 états, persistance de l'extraction PDF (jusque-là le moteur, le benchmark, la notation et les exports ne tournaient pas sur le flux réel), veille en fan-out (5-6 requêtes dédupliquées et datées + matrice concurrents/SWOT/Porter — validé en direct : 24 sources, 8 concurrents), tendance N-1 + key-driver, 360° multi-évaluateur avec angles morts et seuil d'anonymat, business-case ROI (gains bornés + hypothèses affichées), coût/ROI €/an et matrice impact/effort, import FEC (mapping plan comptable → agrégats), vrai DISC (banque de 28 items en français, scoring réel).

Trois alertes d'intégrité corrigées dans le même mouvement — c'est le point le plus honnête du dossier :

1. Un axe « inné vs adapté » du profil était pseudo-aléatoire (un décalage dérivé d'un hash), et vendu comme une mesure → supprimé, contenu dérivé relabellisé.
2. Le DISC était vendu et cassé (un placeholder) → d'abord désactivé, puis reconstruit pour de vrai.
3. La cartographie annonçait un export qui n'existait pas (hook orphelin) → export réel construit.

Livrer plutôt que couper la promesse a été le choix — mais après avoir nommé l'écart.

3.5 Avant-vente et livrables — ce qui remplace un deck

• Démo publique en lecture seule, ouverte à un inconnu via une porte e-mail : la fonction serveur enregistre le lead puis ouvre une session sur un compte de démonstration partagé, côté serveur. Le mot de passe n'atteint jamais le navigateur (sinon le secret part dans le bundle public et la collecte d'e-mails se contourne). Vérifié : la chaîne n'apparaît nulle part dans le build.
• Politique tranchée : griser, pas masquer. Toute action mutative reste visible, grisée, désactivée, avec une infobulle — le visiteur voit la fonctionnalité sans la déclencher. Exports et navigation restent actifs. Vérifié par un parcours automatisé de 19 pages : 0 bouton mutatif actif.
• Nuance commerciale ajoutée ensuite : l'export PPTX est réservé aux comptes payants, avec un message parlant d'offre commerciale et non de mode démo — sinon le visiteur croit à une limitation technique au lieu d'un argument d'achat.
• Porte qualifiée : prénom / nom / société en plus de l'e-mail, colonnes ajoutées côté base, alerte e-mail portant société et contact en tête, page d'administration des leads.
• Honnêteté du chiffre : les 12 leads de démonstration sont 100 % des tests (curl, Playwright, moi). Zéro prospect réel à cette date.
• Décks commerciaux : un hub + 3 decks stratégie + 6 decks par outil, sur un domaine dédié, design partagé, prix affichés « sur devis » (décision : pricing masqué).
• Book de vente produit à partir de l'état fonctionnel réel du code : ce qui n'est pas câblé est écrit « en préparation » ou absent, l'IA est décrite par son niveau sans jamais nommer un modèle. Et ce book a une date de péremption : il a été marqué périmé trois semaines plus tard, quand les outils sont montés en gamme.

PARTIE 4 — Automatisation, IA, outils internes (bloc 20, en entier)

4.1 Le socle

Tout passe par le CLI sur un VPS, avec les process décentralisés, versionnés et documentés. Conséquence voulue : changer d'outil demain sans rien casser — la valeur est dans les procédures et les garde-fous, pas dans le fournisseur.

Ce qui tourne, nommément :

Règle structurante de l'orchestrateur : il n'écrit jamais de code lui-même, il délègue. Un orchestrateur qui exécute devient un point de panne. Autres règles opérantes : 3 lignes maximum par message, zéro emoji, classification d'intention avant toute réponse.

MCP réellement utilisés : Supabase, Vercel, Google Drive, Gmail, Tavily, Hostinger DNS, Ahrefs, Figma, Notion, ClickUp, PartnerStack (serveur écrit pour l'occasion).

APIs pilotées directement, sans interface : Google Search Console + Site Verification, GA4 Data + Admin, Tag Manager, PageSpeed Insights, Indexing (limité), IndexNow, Bing Webmaster, YouTube Data (upload résumable + miniature + playlist), Hostinger DNS, Vercel, Supabase Management, Resend, ElevenLabs, Framer Server API, Malt, Common Crawl.

Postgres est partout : leads et séquences, suivi d'affiliation, données produit multi-tenant, base de mesure des sites, et une base auto-hébergée sur le VPS (Postgres embarqué + PostgREST, sans Docker) pour un outil client qui ne pouvait pas être sur du managed.

4.2 Les automatisations les plus intéressantes, avec leur mécanique

a) Génération et synchronisation de catalogue — trigger : cron 4 h. Sources : découverte de programmes + enrichissement web (Tavily) + LLM. Transformations : normalisation, validation sur le chemin d'écriture, dédup. Destination : deux fichiers TypeScript générés dans deux dépôts distincts + une table de suivi. Résultat : 721 fiches, 2 154 pages. Défaut qui a coûté le plus cher : voir 2.1 (prix inventés).

b) Alerte lead partant de la base, jamais du navigateur — trigger AFTER INSERT → fonction interne → pg_net → fonction edge → e-mail. Sur 4 tables. C'est le point à ne pas « simplifier » plus tard : une alerte côté client raterait exactement les soumissions qui échouent. Avant ça, le formulaire faisait une insertion directe depuis le navigateur dans un try {} catch {} silencieux — aucun e-mail, aucun webhook, aucun trigger — pendant que le mur d'e-mail promettait « vos recommandations personnalisées ». Rien n'a jamais été envoyé.

c) Chaîne de mesure quotidienne — 6 sites, 8 collecteurs, chacun portant son témoin. Le témoin du lot (casser exprès une propriété Search Console) a échoué au premier essai, et c'est ce qui a payé : l'exception remontait jusqu'à l'appelant au lieu de rendre « cassé », donc un 403 sur le premier site aurait tué le cycle entier sans que personne le voie.

d) Publication vidéo de bout en bout — script → voix de synthèse horodatée mot à mot (chaque coupe tombe sur un mot) → rendu headless image par image → mixage avec ducking sidechain piloté par la voix, cible −14 LUFS → upload YouTube par API → réécriture de l'identifiant de la vidéo dans le générateur du site → rebuild → vérification. Le script est réentrant (état sur disque, il saute ce qui est déjà passé) ; commit, push et suppression des anciennes vidéos restent manuels à dessein.

e) Personnalisation d'une landing par prospect dans une campagne d'outreach — le cas le plus vendeur, et le plus simple à démontrer.

4.3 Ce qui a mal tourné (et ce que ça a appris)

• 25 tâches planifiées sur 30 en pause depuis le 20/04/2026 — dont la sauvegarde git quotidienne, dont le dernier passage rapportait déjà « 3 OK, 1 failed ». Quatre mois. Personne ne surveillait, parce qu'une tâche en pause ne fait pas de bruit. Le piège suivant, évité de justesse : réactiver la chaîne d'outreach telle quelle aurait envoyé quatre mois de file d'un coup. Une reprise n'est pas un redémarrage.
• Les agents planifiés n'ont jamais exécuté un seul agent pendant trois jours : claude -p "Lance l'agent X" ne dispatche rien. Il faut --agent X. Faute de le trouver, la session improvisait : elle s'est fabriqué sa propre liste de sites, en a audité trois hors périmètre, en a ignoré deux du registre, et a signé d'un nom d'agent inventé. Deux constats « sitemap absent » ont été ouverts sur des sites sains, et une correction a été appliquée sur la foi d'un constat faux. Un agent non chargé ne rend pas d'erreur : il rend un rapport bien formé, sur les mauvais objets.
• La pipeline jetait ce qu'elle scrapait : un script d'enrichissement réel (sans LLM) remplissait 69 fiches que aucun des trois générateurs ne lisait, pendant que 528 fiches étaient inventées à côté.
• Deux modèles morts appelés en production (404 vérifié) dans deux scripts.
• Un correctif appliqué à une seule variante : trois prompts fuyaient, un seul a été corrigé.
• Ce que j'ai renoncé à automatiser : l'envoi au-delà d'un seuil, la validation éditoriale, la soumission d'annuaires (comptes et KYC), et la demande d'indexation d'une page (l'API Google ne couvre officiellement que les offres d'emploi et les événements — ne pas re-proposer d'automatiser ça).

PARTIE 5 — Produit / build (bloc 21)

5.1 Ce qui a été mis en marché

1. Solutio Suite — 7 modules pour PME et cabinets : diagnostic d'organisation, cartographie des processus, sondage climat / eNPS, profil collaborateur (Big Five, DISC, 360°), analyse financière, veille marché, plan d'action. Plus la génération de propositions de mission. FR/EN.
2. Version marque blanche de la Suite, vendue à des cabinets : multi-tenant, thème et domaine par client, démo publique séparée en lecture seule, livrables structurellement neutres (les exports ne lisent jamais la marque de la plateforme — un nom de plateforme dans un livrable client est impossible par construction).
3. TrouveMonSaaS — comparateur de SaaS français, 721 fiches, monétisé à l'affiliation.
4. Parcours de formation IA (gratuit, acquisition) — 38 modules, Astro + MDX + fonction edge ; adossé à un audit payant qui le finance. Objectif de conception affiché : 40 % de complétion contre 12 % de moyenne du marché ; critère de décision n°1 = UX anti-abandon.
5. Outil d'aide à la décision tarifaire (client négoce multi-agences) — moteur de prix, en service.
6. Otto — agent de devis sur WhatsApp pour artisans (Cloud API + PDF).
7. Machine de prospection, agent d'affiliation, assistant Telegram, chaîne de mesure — internes, mais ce sont des produits au sens plein (crons, tests, base, tableau de bord).

Volumes de tests, pour l'échelle : 1 051 (comparateur), 928 (Suite), 319 (outil tarifaire), 103 (formation), 84 (chaîne de mesure).

5.2 L'outil tarifaire — le cas « métier » le plus dense

Un principe de conception qui vaut d'être raconté : le moteur mécanique est gelé, le contexte client est adaptable.

• Gelé, jamais éditable : prix de marché médian, écarts-types haut et bas, formules de tarif agressif et de plancher avec écrêtage, structure de l'arbre de décision, trois niveaux statistiques.
• Adaptable, avec explication + défaut intelligent + édition : taxonomies (types de clients, nomenclature, colonnes tarifaires), classifications, seuils et coefficients, certaines règles.
• Honnêteté du produit, non négociable : les chemins non calculables affichent « non calculé » — aucun prix inventé. Sur une première importation réelle, le moteur était 100 % inerte (0 calculé) parce qu'un drapeau d'article était figé ; le correctif n'a pas été de forcer un chiffre mais d'ouvrir le classement des articles à l'utilisateur, avec suggestion automatique. Après « suggérer pour tous » : 5/10 calculés, grilles, prix par profil, backtest 400/800 lignes repricées, marge 30 → 30,6 %.
• Un humain dans la boucle par construction : workflow de qualification (en attente / validé / à revoir + prix ajusté), rien n'est appliqué automatiquement.
• Un socle pédagogique dans le produit parce que l'utilisateur final n'a jamais vu la formation d'origine : glossaire de 8 termes, guide de méthode en 8 sections, infobulles sur les en-têtes clés, et un « Pourquoi ce tarif ? » par article. Plus une visite guidée interactive en 5 étapes qui navigue de station en station, et un bandeau « prochaine action recommandée » dérivé de l'état réel des données.
• Et une décision produit dictée par le terrain : les marges se jugent en relatif, jamais en absolu. Dans le négoce, une marge par produit est structurellement minuscule — un seuil absolu peint tout en rouge et ne veut rien dire, et un commercial ne peut pas fixer ce seuil. Chaque objet est comparé à sa propre cohorte métier (un plaquiste qui achète beaucoup de plaque est normal pour un plaquiste), coloration par percentile intra-cohorte. Les paramètres absolus qui venaient d'être ajoutés ont été retirés pour ça.

5.3 Sécurité et multi-tenant — ce qui a été trouvé, pas ce qui a été promis

• 63+ policies RLS AS RESTRICTIVE sur 21 tables tenant et 12 tables filles. Raison technique à connaître : les policies permissives s'additionnent en OR — une policy de blocage permissive serait décorative, seul RESTRICTIVE retire un droit.
• Piège d'interprétation : un USING restrictif filtre les lignes au lieu de lever → une modification bloquée renvoie 200 sans rien écrire et sans erreur. C'est ce qui produisait un toast « clôturé avec succès » mensonger. ⇒ l'état lecture seule doit être affiché a priori, jamais déduit d'une erreur qui ne viendra pas.
• Les fonctions serveur tournent en service_role et contournent la RLS : les policies n'arrêtent aucune génération. Il faut une garde explicite dans chacune des 11 fonctions de génération.
• Le fichier de configuration ne fait pas autorité sur l'authentification. Une fonction absente du fichier n'hérite pas de la vérification de jeton ; la vérité est l'état déployé de la plateforme. Coût réel : une fonction sans aucune authentification interne a laissé exécuter un modèle payant, anonymement, en boucle, pendant deux mois sur le compte du propriétaire. Fermée, vérifiée (anonyme → 401).
• Deux failles cross-tenant trouvées par une revue de sécurité : une fonction de gestion d'utilisateurs exécutait suspendre/archiver/supprimer sur un identifiant brut sans vérifier l'appartenance à l'organisation (n'importe quel propriétaire pouvait supprimer n'importe quel utilisateur de n'importe quel client) ; une fonction de réinitialisation résolvait l'utilisateur globalement par e-mail et renvoyait un mot de passe temporaire (prise de compte en saisissant l'e-mail d'une victime). Corrigées, rejet cross-organisation vérifié en direct.
• Un pont silencieux propriétaire → administrateur plateforme a été supprimé : chaque propriétaire de cabinet contournait la séparation multi-tenant sans le savoir.
• Fuite de marque client dans les livrables : le nom d'un ancien client était codé en dur dans 5 fonctions de génération — donc régénérer un PDF le réintroduisait, même après nettoyage de la base. Corrigé à la source + données nettoyées + 5 fonctions redéployées + vérification sur le HTML exact que le téléchargement utilise.
• RLS prouvée, pas supposée : sondes anonymes en production — sans en-tête = 0 ligne, capacité valide = 1 ligne, tentative d'exploitation = 0 ligne.
• Un détail de conception qui protège les clients payants : l'organisation de démonstration doit rester au plan le plus bas, parce que la résolution d'organisation se fait par rang de plan — sinon la démo éclipserait l'organisation réelle d'un client et le verrouillerait en lecture seule sur son propre travail.
• Le jeu de démonstration est 100 % synthétique, vérifié compte par compte (22 comptes, zéro humain réel). Avant durcissement, une loterie piochait dans toute la base sans filtre — ce qui aurait publié la fiche du premier vrai client (SIRET, CA, notes, répondants nommés) sans une ligne de code modifiée. Et deux contrôles qui semblaient suffisants validaient des rapports de 43 caractères : compter des lignes ne prouve rien.

5.4 Ce que je fais / ce que produit l'IA

La ligne honnête : je décide, je spécifie, je pose les garde-fous, je vérifie ; le code est majoritairement produit par l'IA sous contrôle. Ce que ça implique, et qui est la vraie compétence :

• des revues indépendantes systématiques avant mise en production (revue de code, simplification, revue sécurité). Sur un audit, 9 réserves sur 14 ont été trouvées par un processus séparé — dont une sur un axe que j'avais moi-même déclaré propre. Une relecture dans le même fil hérite des angles morts du premier passage.
• des contrôles qui peuvent échouer : un garde-fou qu'on n'a jamais vu tomber ne prouve rien. J'ai cassé exprès une propriété Search Console pour vérifier qu'un 403 ne tuait pas le cycle — il le tuait.
• la conscience que les butées ne sont opérantes que là où elles s'exécutent : la butée « lint vert » rend l'agent correcteur inerte sur un dépôt qui porte 38 erreurs de lint (comportement voulu, et documenté comme tel) ; aucun des trois dépôts ne déclarait la commande de typecheck que la butée nommait ; et un dépôt avait son manifeste dans un sous-dossier, ce qui fait qu'un contrôle lancé à la racine ne trouve rien et ressemble à un dépôt sain.
• et une discipline de production apprise dans la douleur : après un travail d'agents, commiter immédiatement avant tout changement de branche. Un git checkout a écrasé 7 fichiers non commités produits par des agents — ~500 k tokens de travail perdus. Correctif adopté : travailler directement sur la branche principale, les fichiers non commités ne déployant pas.

Je ne me présente pas comme développeur. Je me présente comme quelqu'un qui met en production et qui sait ce qu'il faut vérifier avant.

PARTIE 6 — Analytics et décision (bloc 22)

Outils réellement opérés : GA4 (+ Consent Mode v2), Google Tag Manager, Search Console (propriété par compte de service + DNS), Bing Webmaster, Ahrefs Webmaster Tools + Web Analytics, PageSpeed Insights, CrUX (indisponible ici, voir plus bas), Common Crawl, Vercel Analytics, et des tableaux de bord maison branchés sur Postgres.

Cinq cas où la donnée a changé une décision :

1. Deux sites comptés sous un seul nom. 610 sessions attribuées au mauvais site : le collecteur ne filtrait pas le nom d'hôte. Vrai partage : 603 / 7. Décisions : une propriété par site, et une liste de noms d'hôtes explicite, jamais un motif générique (un suffixe ramasserait les sous-domaines le jour où ils seront tagués). Chaque relevé déclare désormais les hôtes qu'il écarte.
2. Le mirage des impressions (voir 2.1) : arrêt du pilotage par volume d'impressions, bascule sur le gabarit guide-adossé-à-la-catégorie.
3. 73 % de robots dans le trafic analytics (Singapour/US), et « Direct » = 296 sessions pour 296 utilisateurs sur 28 jours, un utilisateur par session → pas humain. Le vrai organique était de 18. Décision : ne plus lire le trafic brut, et considérer les données antérieures à une date comme inexistantes plutôt que de les interpréter.
4. Une CSP rendait GA4 aveugle : connect-src n'autorisait que le domaine global alors que GA4 poste sur l'endpoint régional pour le trafic européen → chaque page vue refusée par le navigateur. C'est l'explication la plus probable d'un compteur mort. Corrigé, vérifié en direct (204 sur la collecte, zéro violation).
5. Un tracker mort ne fait pas d'erreur, il fait des zéros. Le suivi first-party était mort depuis quatre mois : le traceur vivait dans un hook de l'ancienne application, supprimé lors d'une migration, jamais réimplémenté. Avant de conclure quoi que ce soit d'un taux de conversion, vérifier la date du dernier enregistrement du dénominateur.

Trois limites que je documente au lieu de les masquer :

• CrUX répond 403 sur toute la ligne (API non activée sur le projet) → aucun field data Core Web Vitals, tout est du laboratoire.
• L'Admin API GA4 répond 403 → impossible de créer un flux par script, la création reste manuelle.
• Aucune API n'expose les liens entrants : l'API Search Console n'a aucun endpoint liens (11 méthodes, vérifié), et l'API Bing répond 200 avec une liste vide sur les 6 sites du compte — y compris un site dont un lien est prouvé par crawl direct. C'est une propriété de l'endpoint, pas une mesure du web.

Le cas « 0 backlink », en entier, parce qu'il est exemplaire. Un audit concluait « 0 backlink = plafond ». Ça n'avait jamais été mesuré : c'est une absence supposée présentée comme un constat. Démenti direct : une fiche institutionnelle .gouv.fr porte un lien dofollow. Puis mesure Ahrefs : 220 domaines référents, 15 dofollow, DR 2. Puis mesure Common Crawl (gratuite, sans clé) : github.com sort au rang #24, lemonde.fr au #1 258, les trois domaines n'ont aucune entrée — ce n'est pas « 0 backlink », c'est « pas assez d'arêtes entrantes pour être classé dans ce crawl ». 🔴 Et la limite de l'outil est documentée : sa liste de domaines référents est inerte (elle rend vide y compris pour github.com), donc elle ne prouve aucune absence et ne doit jamais être citée. Le contrôle positif a payé : exiger de retrouver d'abord le lien institutionnel connu a rattrapé un faux négatif — le premier crawl renvoyait 200 avec 0 occurrence à cause d'une réponse compressée non décodée. Sans ce garde-fou, un lien existant était rapporté absent. Formulation défendable tant que la mesure manque : « aucun domaine référent tiers mesuré à ce jour, faute de source ».

PARTIE 7 — Les échecs et apprentissages (bloc 23) — le bloc le plus fort du dossier

Format demandé : ce que je pensais → ce que j'ai tenté → ce qui s'est passé → pourquoi → ce que je ferais maintenant. Il y en a douze ; le chat en demandait cinq, à choisir selon l'axe voulu.

1 — Acquisition · « 0 backlink », une absence supposée devenue argument

Je pensais : le plafond était l'absence de liens. J'ai tenté : dimensionner un chantier de netlinking dessus. Ce qui s'est passé : le chiffre n'avait jamais été mesuré ; la mesure réelle donne 220 domaines référents et 15 dofollow. Pourquoi : un constat négatif rapporté par un tiers ne porte aucune preuve, et je l'avais appliqué sans le revérifier. Maintenant : « X n'existe pas » est une affirmation à prouver ; et je vérifie une absence avant de l'appliquer, pas seulement avant de l'écrire.

2 — Contenu · une publication réussie qui ne prouvait que son accueil

Je pensais : l'aperçu de 38 modules était en ligne et vérifié. J'ai tenté : un garde-fou automatique (vérifie le noindex, le compte de pages, la signature). Ce qui s'est passé : en ligne plusieurs jours avec tous les liens internes en 404 ; les trois contrôles passaient au vert, aucun ne cliquait. Pourquoi : je vérifiais la forme de la publication, pas son usage. Maintenant : le contrôle inclut un parcours réel (200 sur chaque cible et un témoin qui doit rendre 404, sinon c'est la mesure qui est cassée).

3 — Produit · des prix inventés qui passaient tous les contrôles

Je pensais : la pipeline enrichissait à partir de sources. J'ai tenté : des contrôles de format. Ce qui s'est passé : 268 fiches avec un plan « Gratuit » semé, 11 % recopiant le XX euros/mois de l'exemple du prompt, 19 fausses nationalités, et une pipeline qui jetait ce qu'elle scrapait. Pourquoi : « 99 €/mois » passe tous les contrôles de forme. La confiance se juge sur la provenance. Maintenant : validation sur le chemin d'écriture, ancrage obligatoire sur une source, et un test qui vérifie « ça vient bien d'où on prétend » plutôt que « ça affiche quelque chose ».

4 — Opérations · 25 tâches planifiées en pause pendant quatre mois

Je pensais : la machine tournait. Ce qui s'est passé : 25 crons sur 30 en pause depuis le 20/04, dont la sauvegarde git quotidienne, dont le dernier passage rapportait déjà un échec. Pourquoi : une tâche en pause ne fait pas de bruit. Maintenant : ce qui compte n'est pas le stock (« 30 crons installés »), c'est la date du dernier élément réellement produit. Et une reprise n'est pas un redémarrage : rallumer la chaîne d'outreach telle quelle aurait envoyé quatre mois de file d'un coup.

5 — Mesure · « médiane de 3 runs », une méthode qui n'existait pas

Je pensais : le tableau de bord agrégeait 3 mesures. Ce qui s'est passé : l'API servait la même analyse en cache aux trois appels ; trois valeurs identiques avec l'apparence d'une méthode. Et la comparaison avant/après un correctif est devenue non concluante, la ligne de base étant elle-même du cache. Pourquoi : je testais mon code, pas mon instrument. Maintenant : agrégation sur les analyses distinctes, publication de leur nombre, et médiane basse — jamais la moyenne de deux valeurs (90 et 100 donnaient un « 95 » qu'aucune mesure n'avait produit).

6 — Diagnostic · une cause plausible et fausse (le bandeau cookies)

Voir 3.2. Ce qu'il faut en retenir : quand une mesure rend 0, ne pas s'arrêter à la première hypothèse plausible ; construire un jeu de conditions dont chacune élimine une cause. Un correctif de consentement sur un problème de chargement n'aurait rien changé — et aurait été déclaré fait.

7 — Le même défaut, trois fois dans la même journée · les identifiants à deux formes

Un fichier de données indexé sur une forme d'identifiant, interrogé avec l'autre : 1 résolution sur 1 767 ; puis 7 pages perdent leur bloc d'équivalents prouvés ; puis 151 fiches sur 165 perdent leur seul contenu éditorial. Build vert à chaque fois. Pourquoi : un helper qui échoue vers vide masque une panne. Maintenant : la règle est écrite dans le dépôt (« interroger la pipeline avec la clé d'origine, jamais avec le slug d'URL »), et les contrôles portent sur le HTML construit, avec les entrées non affectées comme témoin — un seuil absolu ne distingue pas une panne d'un taux d'échec normal.

8 — Une correction juste faite à moitié · cinq fois en une matinée

Sur neuf corrections, cinq n'étaient faites qu'à moitié — et aucune n'a été trouvée par relecture. Les quatre endroits qui échappent systématiquement : le critère de réussite de l'exercice, la récapitulation finale, le registre de provenance, le fichier de test. Même famille : j'ai corrigé le mauvais fichier (index.html alors que le build sert home.html), déployé, et la production est restée à zéro. Maintenant : après chaque correction, relancer la recherche sur tout le dépôt, et relire autour (un compte annoncé, une numérotation, une phrase coupée).

9 — Un grep ne voit pas la cohérence

Cinq réserves déclarées fermées « contrôlées mécaniquement » : la chaîne fautive avait disparu. Le passage suivant en a requalifié une et trouvé trois défauts de plus, dont deux créés par ces corrections mêmes — « trois issues » suivi de quatre puces, une renumérotation qui périme un commentaire deux lignes plus bas, une insertion qui coupe une phrase en deux. Une correction est locale ; ses effets ne le sont pas. Corollaire : un décompte n'est pas une donnée, c'est le résultat d'une convention de comptage — un registre portait 8, 9, 10 et 11 pour le même objet, personne n'avait fauté, on comptait des choses différentes.

10 — Quand tout le parc s'écarte d'une règle, interroger la règle

Recette indépendante de 38 modules, un correcteur par module, contexte vierge : 559 écarts, 0/38 publiable. Le résultat portait en réalité sur le corpus de règles, pas sur les contenus : 54 écarts sont tombés en alignant deux paragraphes de documentation contradictoires, et la règle « 3 puces » était enfreinte par 28 modules dont celui qui fait référence — le parc était conforme à l'exemplaire, pas à la règle. Les 38 correcteurs ont relevé de 38 à 113 règles dans les mêmes sept fichiers : les gravités n'étaient pas comparables entre modules.

11 — Un resserrage est une décision éditoriale

Un document de candidature passé de 17 à 12 pages sur le critère « ne garder que les faits relevés » : tout le raisonnement a disparu (les canaux, le pivot produit, la boucle, les garde-fous). Rétabli sur un autre critère — une page = une affirmation + sa preuve + la décision qu'elle débloque. Maintenant : écrire le critère avant de couper, et produire un rapport de ce qui a été coupé.

12 — Le HTML servi n'est pas la page

Trois constats effondrés en une session, même racine : j'ai mesuré ce que curl recevait et conclu sur ce qu'un visiteur voit. « Les articles ne portent aucun lien produit » → faux, les liens sont injectés en JavaScript. « Pas de routage depuis les vidéos » → faux, les liens sont enveloppés dans une redirection et invisibles à un grep naïf. Et une charge utile n'est pas un affichage : une page de liens contenait 26 offres d'affiliation dans son JSON, aucune affichée — j'ai failli écrire dans un document client qu'il en faisait la promotion. Maintenant : dès qu'un constat porte sur ce qu'un visiteur voit ou peut cliquer, mesurer dans un navigateur ; et un témoin qui retourne 0 dit que la mesure est cassée, pas que la cible est absente.

Le fil rouge, si tu ne devais garder qu'une phrase de cette partie :

La plupart de mes erreurs n'ont pas la forme d'une erreur. Elles ont la forme d'un chiffre correct, d'un test vert, d'un rapport bien rédigé. C'est pour ça que je construis maintenant des contrôles qui peuvent échouer, et des témoins qui prouvent que la mesure fonctionne avant de croire ce qu'elle dit.

PARTIE 8 — Niveaux de compétence (bloc 24)

Barème : Deep experience / Used successfully / Tested / Familiar. Je place ce qui est prouvable sur le périmètre Solutio et clients. Les lignes ⚑ dépendent de ton expérience salariée : à toi de trancher, je n'ai pas la donnée interne.

La phrase de cette section (elle est vraie, et elle est rare) :

J'ai testé assez de la chaîne GTM et du cycle client pour savoir ce que j'exécute moi-même, ce qui casse en général, ce que je testerais en premier — et à quel moment un spécialiste est la meilleure réponse.

PARTIE 9 — Formules prêtes à l'emploi (issues du matériau, pas inventées)

• J'adapte la stack au problème, pas le problème à la stack.
• En outbound, je vends la conversation avant la solution. Le premier objectif est d'obtenir assez de temps pour comprendre le besoin.
• Un chiffre ne vaut que par sa provenance. « Gratuit » et « 99 €/mois » passent tous les contrôles de forme.
• Un contrôle qui ne peut pas échouer ne prouve rien.
• Un stock ne dit rien du flux : ce qui compte n'est pas « 30 tâches installées », c'est la date du dernier élément produit.
• Une publication réussie ne prouve que son accueil.
• Le vocabulaire d'achat n'est pas le vocabulaire du besoin.
• Quand tout le parc s'écarte d'une règle, c'est la règle qu'il faut interroger.
• Le HTML servi n'est pas la page.
• Une absence est une affirmation, pas un constat par défaut.
• Le moteur est gelé, le contexte est adaptable (principe de conception produit).
• Griser plutôt que masquer (principe de démonstration commerciale).

PARTIE 10 — Inventaire des preuves ouvrables (ce qu'un recruteur peut cliquer)

⚠️ Deux points à ne pas afficher sans vérifier d'abord : theolebreton.com est parqué (aucun contenu servi), et un sous-domaine d'assistant porte un certificat TLS expiré. Un recruteur qui clique tombe sur une erreur.

PARTIE 11 — Ce que je NE peux pas répondre à ta place

Tout l'interne Tinycoaching. Sans tes chiffres, ces cases resteront vides ou fausses :

1. MQL / SQL : la définition exacte appliquée, et les signaux du scoring (pages vues ? demande de démo ? taille ? secteur ? score composite ?).
2. Forecasting : méthode (pondération par étape ? engagement commercial ? les deux ?) et horizon.
3. Le plus gros problème de données CRM réellement résolu — doublons, attribution, migration, champs libres ? Ta réponse actuelle (« j'ai tout installé moi-même ») répond à une autre question, et le chat le relèvera.
4. Newsletter : fréquence, taille d'audience, segmentation, et la confirmation du « 25 %+ d'ouverture ».
5. Le freemium ~1 000 utilisateurs : taux de conversion vers un RDV ou une vente, et ce que « turnover important » veut dire chiffré.
6. Négociation : jusqu'à quel montant ou quelle remise tu décidais seul, et ce que tu pouvais concéder (délais, périmètre, engagement, paiement).
7. Fédération nationale : ce que tu as fait précisément pour obtenir l'exclusivité, et ce que l'appel d'offres exigeait.
8. Renewal : le dénominateur du « 1 compte sur 2 » (sur combien ?), et les motifs de non-renouvellement.
9. Expansion : l'origine du cross-sell « managers' track », et comment les engagements pluriannuels ont été obtenus.
10. Voice of Customer : où les retours étaient stockés, comment ils étaient priorisés avec le fondateur, et 1-2 fonctionnalités réellement nées de tes conversations.
11. VivaTech : nombre de contacts capturés, taux de relance, pipeline sorti.
12. POC : un exemple où les résultats du pilote ont directement débloqué la signature (tu as donné l'échec — l'inverse manque, et c'est celui qui vend).
13. Le moteur de génération de parcours : ton rôle exact (spécification ? règles pédagogiques ? arbitrage ? tests ?).

Une ligne par point suffit : je sais déjà où chacune s'insère dans l'architecture.