I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

À retenir

1. Date / source. 12 août 2026, LinkedIn Pulse, newsletter Growth Marketing Fit, ~2 500 mots. Système bâti dans Claude pour une équipe marketing de ~60 personnes.
2. Cadrage clé. « Je croyais construire une machine à contenu. Je construisais une machine à confiance, et je ne le savais pas, donc j'ai dépensé mon effort initial exactement au mauvais endroit. » ### Interdire le « pass » nu Un vérificateur est un système en monde clos : il ne peut se prononcer que sur ce qu'on lui a fourni. Confronté à une affirmation qu'aucune de ses sources ne couvre, il ne trouve aucune contradiction et rend un verdict favorable indiscernable d'une vraie vérification. Le correctif est une contrainte de format : | Le rapport doit énoncer | Pourquoi | |---|---| | Combien d'affirmations ont été contrôlées | dénominateur : sans lui, un « OK » ne veut rien dire | | Combien ont été effectivement appariées à une source | c'est le vrai taux de couverture, toujours inférieur | | Lesquelles ne relevaient pas de sa juridiction | sinon le juge déborde et le silence des autres passe pour un accord | | Lesquelles ne sont possédées par aucune source du système | c'est le registre de risque réel de l'organisation | « Je ne peux pas vérifier ceci » doit être un résultat de première classe, au même rang que « conforme » et « non conforme ». L'anti-pattern symétrique est plus dangereux que l'absence de contrôle : « une bonne revue sans valeur est bien pire que pas de revue, parce qu'elle blanchit la sortie » — quelqu'un en aval voit reviewed: pass et arrête de regarder. À croiser avec [[willison-fable-judgement-delegation-subagents-2026-07-03]]. ### Le contrôle que la vérification par actif ne peut pas produire Deux actifs d'une même campagne peuvent être chacun individuellement correct, chacun traçable vers une vraie source, chacun validé — et se contredire. Vérifier contre la couche de vérité et vérifier les actifs les uns contre les autres sont deux contrôles différents ; le premier ne peut pas produire le second. Diagnostic de l'auteur : « si vous faites des campagnes multi-actifs et que vous ne vérifiez qu'un actif à la fois, vous avez ce bug en ce moment. » Transposition hors marketing : une PR qui touche trois fichiers, un jeu de specs généré en lot, une doc et son code produits ensemble. La cohérence croisée est un contrôle de niveau bundle, jamais une somme de contrôles unitaires. ### La couche de vérité Panne racontée : les faits produit vivaient dans la skill qui écrivait les articles, puis le même fait a dû exister dans la skill e-mail, la battlecard, la page web. « En quelques semaines j'avais quatre versions légèrement différentes de notre date de lancement dans quatre fichiers différents, et la dérive était invisible parce que chaque fichier était individuellement plausible. » Règle : « un document qui énonce des faits et un document qui produit du contenu sont deux documents différents, avec deux propriétaires différents », chacun versionné et daté. Rien de ce qui produit du contenu n'a le droit de contenir un fait — il doit le demander. Bénéfice : un fait change, on le change une fois, les 35 skills sont correctes le lendemain ; une affirmation est contestée, un seul endroit à regarder. Raison pour laquelle personne ne la construit : « On ne peut pas faire la démo d'une couche de vérité. On ne peut faire la démo que de ce qu'elle empêche, c'est-à-dire rien de visible. » Exercice proposé : ouvrir les cinq derniers actifs produits, surligner chaque affirmation factuelle, nommer pour chacune l'unique document qui la possède — « celles auxquelles vous ne pouvez pas assigner de propriétaire sont votre véritable registre de risques. » Prolonge [[vasilopoulos-codified-context-infrastructure-ai-agents-2026-02-24]]. ### Deux leçons sur les skills 1. Le contrat de sortie doit être paranoïaque sur l'ambiguïté. Pendant des semaines, la skill « article de blog » écrivait des descriptions d'articles — des titres de section suivis d'une phrase expliquant ce que la section couvrirait, « à chaque fois » — et ça passait toutes les revues, la structure étant impeccable. Cause : une ligne ambiguë du gabarit (« the post, under the flavour's own section headers »), raisonnablement lue comme une demande de plan. Détail organisationnel plus important que le bug : personne ne l'a signalé, « les gens supposent que l'outil a raison et qu'eux l'utilisent mal. » 2. Le travail le plus important d'une skill est de décrire ce à quoi elle ne sert pas. Passé la trentaine de skills, le problème cesse d'être la qualité et devient le routage : deux skills qui traitent toutes deux plausiblement « écris-moi quelque chose pour les commerciaux » se disputent chaque requête, et le gagnant arbitraire produit le mauvais format. La moitié de chaque description est devenue une frontière explicite. À confronter à [[shihipar-claude-code-lessons-building-skills-2026-06-03]]. ### Du prompt à la plomberie Les règles de voix interdisaient les tirets cadratins, chaque prompt le disait, les testeurs en trouvaient quand même pendant des semaines : « Je répétais la règle plus fort, ce qui est un correctif probabiliste à un problème dont la solution déterministe était juste là. » Correctif : une fonction unique en sortie qui les supprime. Heuristique généralisable : « si vous vous surprenez à répéter une instruction, c'est le signal de la sortir du prompt et de la mettre dans la plomberie », avec son corollaire — « demander gentiment n'est pas un contrôle. » ### La panne silencieuse Une constante censée contenir un caractère marqueur invisible avait été vidée en chaîne vide. Aucun diff visible, aucune erreur. En aval, une étape de nettoyage s'est mise à matcher chaque chiffre de chaque prompt et à le supprimer : « 7.1% across 6,000+ orgs, 2500 words » arrivait au modèle sous la forme « .% across ,+ orgs, words ». Chaque statistique, date, compte de mots et numéro de section retirés silencieusement, pendant un nombre indéterminé de releases. C'était la raison réelle pour laquelle les chiffres cités revenaient faux — « et j'avais passé des semaines à blâmer la tendance du modèle à inventer des chiffres. Il les inventait parce que je les avais supprimés. » Principe : « Le logiciel traditionnel plante quand il casse. Ces systèmes continuent, avec assurance, à qualité réduite, et produisent quelque chose qui a l'air correct. » Deux correctifs : tester le pipeline et pas seulement la sortie — un test dont l'unique fonction est d'affirmer que les chiffres survivent à un aller-retour dans l'assemblage du prompt ; et se rappeler que la validation a les mêmes trous que le système — un champ limité à 500 caractères est resté à 688 pendant deux releases parce que le script contrôlait toutes les autres limites sauf celle-là. Règle de diagnostic : avant d'accuser un modèle d'inventer un chiffre, vérifier que le chiffre lui est bien parvenu. ### La couche 4, distribution interne « C'est là que la plupart des projets IA internes meurent en silence. Pas d'un échec technique. D'être techniquement excellents et utilisés par quatre personnes. » L'auteur avait construit pour lui d'abord — un plugin exigeant l'aisance en ligne de commande, ce qui décrivait six personnes sur soixante. Correctif : le même système bâti deux fois, même connaissance et mêmes contrôles, deux portes d'entrée — plugin pour les constructeurs, application navigateur pour les autres (catalogue, trois champs, un brouillon avec ses contrôles à côté sous forme de boutons). Point le plus fin de la section : l'adoption suit la confiance, pas la capacité. L'outil a été davantage utilisé une fois que la sortie s'est mise à admettre ce dont elle n'était pas sûre — « Un brouillon qui signale "cet exemple client est illustratif, trouvez-en un vrai avant publication" est utilisé. Un brouillon qui présente avec assurance un exemple client inventé est utilisé une fois, met quelqu'un dans l'embarras, et l'outil est mort par le bouche-à-oreille. » ### Apprendre au système à refuser La dernière brique adapte un actif à un autre segment de marché et connaît le segment que l'entreprise a décidé de ne pas poursuivre : sollicitée pour ce segment, elle décline et explique pourquoi. « Même principe que la déclaration de couverture. Un système qui ne peut que dire oui vous tendra avec assurance la mauvaise chose pour toujours, et vous ne serez pas capable de faire la différence entre "c'est juste" et "c'était la seule réponse disponible". » Le refus et l'aveu d'ignorance sont la même primitive : la capacité du système à borner son domaine de compétence. ### Les trois incertitudes laissées ouvertes 1. Couche de vérité embarquée ou récupérée en direct ? « Les copies embarquées se périment sans que personne le remarque. Les fetch live sont lents et cassent quand quelqu'un renomme un dossier. » L'auteur fait un mélange et le dit non raisonné. 2. Le coût de vérification reste-t-il justifiable ? Un actif entièrement contrôlé coûte « plusieurs fois » un brouillon brut : rentable pour du public, probablement pas pour une synthèse interne, « et la frontière entre les deux est plus floue que mon système ne le prétend ». Variable de gouvernance à instrumenter en premier : un niveau de vérification par criticité d'actif. 3. Combien survit aux deux prochaines générations de modèles ? Son pari, présenté comme tel : la couche de vérité et la discipline de couverture survivent, parce qu'elles « résolvent un problème organisationnel de provenance et de propriété qui existerait même avec un modèle parfait. » ### Le plan « si vous démarrez lundi » 1. Écrire les dix faits que l'équipe répète le plus, avec un propriétaire et une date pour chacun — couche de vérité version zéro, « ça prend un après-midi ». 2. Prendre le meilleur prompt et en extraire chaque fait vers ce document ; faire en sorte que le prompt les demande. 3. Construire une étape de vérification qui tourne en session fraîche, ne voit que le brouillon et les sources, et doit dire ce qu'elle n'a pas pu contrôler. 4. Trouver ce qui est répété sans cesse dans les prompts et le déplacer dans le code. 5. Le montrer à quelqu'un de non technique et le regarder l'utiliser sans l'aider. Test de référence à faire avant tout le reste : passer un actif déjà expédié au contrôle dans une session complètement fraîche, sans autre contexte que le brouillon et les sources. « Ce qui revient est votre véritable ligne de base qualité. C'est généralement humiliant. La mienne l'était. »