Le Compound externalisé : quand la capitalisation devient un bien commun vérifié

À la seconde où vous lisez cette phrase, quelque part, un agent de codage rouvre une enquête. Un export qui pagine mal, un fuseau horaire qui dérape au passage à l'heure d'hiver, une dépendance tierce capricieuse. Il tâtonne, échoue, retente, finit par trouver le correctif — puis la fenêtre de contexte se referme et la solution s'évapore. Au même instant, sur un autre continent, dans une autre entreprise, un autre agent rouvre exactement la même enquête. Et un troisième. Et mille autres. Chacun paie le plein tarif. Chacun jette la facture.

C'est une scène que le SDLC piloté par l'IA connaît déjà à l'échelle d'une équipe : un agent ne se souvient de rien d'un cycle à l'autre, il refait l'enquête depuis zéro, à pleine vitesse. Nous avons nommé et traité ce défaut à l'intérieur du cycle — c'est l'objet de la face interne de la capitalisation. Mais le même défaut existe un cran au-dessus, là où plus personne ne le regarde : entre les organisations, à l'échelle de l'écosystème tout entier.

Un acteur bien placé pour le diagnostiquer vient de lui donner un nom. Stack Overflow — quinze ans de dépôt de référence du savoir des développeurs — appelle cela l'« Ephemeral Intelligence Gap » : des agents qui, partout dans le monde, résolvent indépendamment des problèmes identiques, gaspillent calcul et tokens, puis perdent la solution dès la fin de la session ; les mêmes patterns d'architecture redécouverts en boucle, dans ce qu'il faut bien appeler de coûteuses boucles de réinvention². Nous avons industrialisé la production de code. Nous n'avons pas industrialisé la mémoire de ce que nous apprenons en le produisant. Et à l'échelle planétaire, l'addition devient absurde : le monde entier paie le même bug, en même temps, sans jamais le boucher.

Le paradoxe : générer est devenu bon marché, vérifier ne l'est pas

Pour comprendre pourquoi cette amnésie collective coûte si cher, il faut voir où la valeur s'est déplacée. La formule la plus juste tient en une ligne, et elle mérite d'être citée telle quelle : « générer des réponses plausibles est devenu bon marché ; vérifier lesquelles tiennent réellement en production ne l'est pas »². C'est tout le renversement de l'ère agentique en une phrase.

Tant que produire du code était l'effort principal, l'actif rare était la capacité à en produire. Cette capacité est en train de devenir une commodité : un agent génère une réponse plausible en quelques secondes, pour quelques centimes. Ce qui reste cher — ce qui devient même la nouvelle rareté — c'est de savoir laquelle de ces réponses tient sous charge réelle, avec des données aberrantes, contre une dépendance qui tombe. La rareté a migré de la génération vers la vérification.

Or une réponse plausible mais non vérifiée n'est pas un actif neutre : c'est un passif. Elle peut tromper avec aplomb, passer les tests superficiels, et n'exploser qu'en production. Capitaliser de telles réponses reviendrait à graver ses erreurs dans le marbre. C'est précisément la ligne de partage qu'une phase de capitalisation digne de ce nom doit tenir : on capitalise la preuve, jamais le « claim ». Et ce que Stack Overflow décrit pour son propre mécanisme emploie, sans détour, le mot qui structure tout le cycle SFEIR : le consensus émerge de l'accumulation de signaux — votes, réponses, retours de vérification — qu'il nomme des « compound signals »². La capitalisation, là encore, n'est pas un supplément d'âme : c'est le mécanisme qui transforme une vérification coûteuse, payée une fois, en savoir réutilisable par tous.

Le Compound, hors les murs

Le SDLC SFEIR pose déjà une phase qui transforme le travail en savoir réutilisable, à l'intérieur de l'organisation : les leçons d'un cycle sont capturées, structurées, puis rechargées au cycle suivant — c'est la capitalisation interne, la mémoire d'un projet qui survit à ses sessions. La question neuve, celle que pose l'irruption d'agents autonomes par millions, est ailleurs : que devient cette capitalisation quand elle sort des murs ?

La réponse dessine un objet inédit : un bien commun vérifié. Le savoir cesse de s'évaporer à la fin de chaque session pour se composer — au sens propre, financier et chimique à la fois : les vérifications s'additionnent, les contre-épreuves s'accumulent, un consensus se dépose. On passe de la mémoire d'une équipe à la mémoire collective d'un écosystème.

L'architecture qui rend cela possible n'est pas une UI de plus. C'est une plateforme API-first, pensée d'abord pour être lue par des machines, où la confiance — l'actif historique, justement — est maintenue non par une autorité centrale mais par le consensus de pairs et des boucles de vérification multi-agents². La métaphore est limpide : la connaissance comme un bien commun qui se compose, opposé à l'agent isolé qui repart de zéro. C'est exactement la fonction d'une phase Compound — refermer le cycle sur ce qui apprend — mais déplacée d'un niveau : non plus au bout d'un cycle d'équipe, au bout du cycle de tout le monde.

Trois échelles de capitalisation : repo, entreprise, écosystème

Ce déplacement se lit mieux si l'on accepte que la même fonction — capitaliser — se décline désormais à trois échelles emboîtées. Les confondre, c'est passer à côté de ce qui se joue.

Du repo à l'entreprise : la mémoire qui reste interne

La première échelle est celle du repo et de l'équipe. C'est le terrain du Compound Engineering, dont l'axiome est le jumeau exact de la conviction SFEIR : « chaque unité de travail d'ingénierie devrait rendre les suivantes plus faciles, pas plus difficiles » ; les leçons vivent dans le codebase, si bien qu'un nouvel arrivant se retrouve aussi bien armé qu'un vétéran³. La mémoire reste locale, versionnée avec le code.

La deuxième échelle est celle de l'entreprise. Ici se superposent la capitalisation interne du cycle — les leçons rechargées au plan suivant — et une exigence que l'externalisation rend soudain critique : garder la souveraineté de son savoir. C'est le sens du pattern que Stack Overflow nomme Stack Internal : une couche de savoir propriétaire, où les agents servent la connaissance organisationnelle sans transmission vers l'extérieur². L'entreprise capitalise et mutualise — mais en vase clos, sous son propre contrôle.

De l'entreprise à l'écosystème : le bien commun vérifié

La troisième échelle est celle de l'écosystème. C'est le bien commun mondial, et son intérêt pour qui pense le SDLC tient dans son workflow, qui calque trait pour trait une phase de capitalisation rigoureuse : chercher d'abord (interroger le savoir validé avant d'agir), contribuer en cas de lacune (l'agent rédige, mais un orchestrateur humain approuve avant publication), vérifier (résultats, modifications nécessaires, conditions de contexte), puis composer les signaux jusqu'à faire émerger un consensus².

Les formats eux-mêmes sont des formats de capitalisation, et la correspondance est frappante. Les Questions consignent les problèmes non résolus — ce qui a été tenté, ce qui a échoué, ce qui bloque encore. Les TIL (Today I Learned) sont des traces de debug — système cassé, tentatives, fix réussi, cause racine : ce sont des leçons de debug capitalisées. Les Blueprints, soumis à l'exigence de qualité la plus haute, sont des patterns de design réutilisables multi-systèmes : autrement dit, des règles capitalisées. Là où le cycle interne transforme un bug récurrent en règle de lint, l'écosystème transforme un pattern éprouvé en Blueprint partagé. La fonction est identique ; seul change le rayon de diffusion.

La vérification comme nouvelle rareté : le consensus contre l'hallucination

Reste la question qui décide de tout : comment faire confiance à un savoir produit, pour l'essentiel, par des agents ? Un bien commun qu'on ne vérifie pas n'est pas un actif, c'est un vecteur de contamination. La réponse n'est pas une réponse unique et autoritaire — c'est un consensus qui émerge de l'accumulation de signaux.

Deux mécanismes le rendent robuste. Le premier est l'ancrage réputationnel : les développeurs revendiquent la propriété de leur agent via une authentification unique, ce qui rattache la performance de cet agent à une réputation humaine établie — une « community anchor » qui empêche les fixes hallucinés de polluer la base². L'agent n'est plus anonyme ; il engage quelqu'un. Le second est explicite sur la place de l'humain : « les agents travaillent à la vitesse de la machine, les humains restant dans la boucle pour les orchestrer et approuver ce qui est publié »².

Cette intuition n'est pas isolée. Martin Monperrus la pousse à sa conclusion la plus radicale pour le SDLC : la revue de code humaine ne serait plus un composant nécessaire d'un pipeline qualité, à condition de lui substituer un pipeline de vérification adversariale multi-agents — un agent générateur, des agents reviewers indépendants, des tests et méthodes formelles, et un consensus par vote⁴. La confiance ne vient plus de la croyance en une bonne réponse, mais de la difficulté à la réfuter. L'humain, lui, se recentre là où il pèse le plus : la spécification, les arbitrages d'architecture, l'approbation des domaines critiques. On reconnaît là le principe qui irrigue tout le SDLC augmenté de SFEIR — la revue à plus de quatre angles, la discipline de preuve où l'évidence prime sur la déclaration. La vérification adversariale n'est pas une exotique nouveauté : c'est la modération du bien commun.

Les pièges : un bien commun peut s'empoisonner

Un discours honnête nomme ses propres failles, et l'externalisation en ajoute de spécifiques à celles de la capitalisation interne. Quatre méritent d'être posées sans complaisance.

Le premier est la pollution. Un correctif halluciné capitalisé ne se contente pas d'être faux : il contamine tous ceux qui le consomment, à la vitesse de l'API. C'est la raison d'être de l'ancrage réputationnel et de la vérification — mais c'est aussi le rappel que la qualité d'un bien commun ne tient qu'à la rigueur de sa porte d'entrée.

Le deuxième est le skill rot à l'échelle. Un artefact périmé, prévient l'analyse de l'ADLC, « délivre une désinformation avec autorité »⁵. Le défaut est déjà sérieux dans un repo ; partagé entre mille organisations, il devient systémique. Une règle qui pointe vers une commande disparue, un Blueprint qui décrit une architecture révolue : l'agent les applique avec le même aplomb que les bons. L'hygiène de fraîcheur — extraire et dater les éléments vérifiables — cesse d'être une option.

Le troisième est le plus stratégique : dépendance et souveraineté. Externaliser sa mémoire vers une plateforme tierce, c'est accepter un risque de lock-in et, pis, d'exfiltration de son savoir le plus différenciant. C'est précisément pourquoi la couche interne vérifiée n'est pas un luxe mais une parade : servir aux agents la connaissance de l'entreprise sans la laisser fuir. La règle de pilotage reste la même qu'au-dedans : on standardise le contexte et la preuve, pas l'outil — car l'outil, lui, sera remplacé.

Le quatrième est la tension que Stack Overflow lui-même n'esquive pas : son pivot transforme un savoir longtemps gratuit — le « training data » de toute une industrie — en service vérifié, facturé, accessible par API. La vérification devient une rareté ; les raretés se monétisent. Ce n'est pas une critique, c'est une donnée : le bien commun vérifié a un coût, et quelqu'un le facturera.

Par où commencer : chercher avant de générer, vérifier avant de capitaliser

Si une seule discipline doit être retenue, c'est un renversement de réflexe : chercher avant de générer. Interroger le savoir vérifié — interne d'abord, commun ensuite — avant de relancer un agent à froid sur un problème déjà résolu mille fois. C'est l'antidote direct aux boucles de réinvention, et le geste le moins coûteux du lot.

Quatre leviers le complètent, et aucun ne suppose de grand programme. Imposer une revue humaine avant publication : rien n'entre dans la mémoire partagée sans qu'un humain l'oriente et l'approuve. Ancrer la réputation : un agent rattaché à une responsabilité humaine pollue moins. Vérifier de façon adversariale : commencer sur des composants à faible risque, mesurer l'agent contre l'humain, et — détail qui fait toute la différence — expliciter les décisions de rejet, car un rejet motivé est lui-même une leçon capitalisable⁴. Construire une couche de savoir interne vérifiée enfin, pour les organisations qui ont un patrimoine à protéger : capitaliser à l'échelle de l'entreprise sans exposer ce qui la distingue.

Sur ce terrain, SFEIR a un parti pris cohérent avec sa doctrine. La version interne de cette capitalisation, nous la nommons déjà — Compound-1 et Compound-2, le passage du Context Engineering qui fait basculer d'un ROI linéaire à un ROI composé. L'externalisation n'est pas un autre sujet : c'est la même fonction, à l'échelle de l'écosystème. Et nous nous l'appliquons d'abord à nous-mêmes, avec l'objectif de 850 consultants 100 % augmentés par l'IA d'ici fin 2026, avant de la déployer chez nos clients.

Reste la question qui vaut pour la suite, et qui n'est plus celle d'une équipe mais d'une industrie. L'écosystème va-t-il continuer à re-payer indéfiniment le même bug, chacun dans son coin, à pleine vitesse — ou va-t-il enfin composer une mémoire commune vérifiée ? Le bien commun n'adviendra pas tout seul. Il n'existera que pour ceux qui prennent le double pli : chercher avant de générer, et vérifier avant de capitaliser.

Cet article fait partie d'une série sur le SDLC augmenté de SFEIR. Il prolonge, vers l'extérieur, la face interne de la capitalisation — Compound-1 & Compound-2 — et croise le cycle cumulatif du Compound Engineering.

Sources

1. SFEIR — SDLC augmenté : le code est le sous-produit, l'actif réel est la connaissance ; Compound-1 & Compound-2 ; Context Engineering ; 850 consultants 100 % augmentés par l'IA fin 2026, matière first-party, 2026.
2. David Gibson, Janice Manningham, Announcing Stack Overflow for Agents — stackoverflow.blog, 10 juin 2026.
3. Kieran Klaassen, Compound Engineering: The Definitive Guide — every.to, 9 février 2026.
4. Martin Monperrus, The End of Code Review: How AI Agents Supersede Human Code Review — arxiv.org, 11 juin 2026.
5. Chris Williams, The Lifecycle That Gets Cheaper Every Run (ADLC, partie 6) — voodootikigod.com, 12 juin 2026.