Compound-1 & Compound-2 : les deux phases où le SDLC piloté par l'IA apprend

Un défaut de pagination dans un export. Un fuseau horaire mal géré au passage à l'heure d'hiver. Une validation de formulaire qui laisse filer une chaîne vide. Vous l'avez corrigé il y a six mois. Et le voilà qui revient, dans un autre module, sur un autre projet, avec un autre ticket et un autre développeur — qui rouvre patiemment l'enquête que quelqu'un d'autre avait déjà close. Vous payez la même dette une deuxième fois. Puis une troisième.

C'est tolérable au rythme humain : la mémoire d'une équipe absorbe une partie de ces répétitions, un senior se souvient, une revue attrape le doublon. Mais branchez des agents sur ce cycle, et l'arithmétique change de signe. Un agent ne se souvient de rien d'un cycle à l'autre : il refait l'enquête depuis zéro, à pleine vitesse. L'accélération, dès lors, ne réduit pas le nombre de bugs récurrents : elle le multiplie. On produit ses erreurs dix fois plus vite, mais on les réapprend aussi dix fois plus souvent.

D'où une formule qui, chez SFEIR, a valeur de règle : « un bug vu deux fois n'est pas un bug. C'est un trou dans le système. » La nuance est décisive. Un bug, on le corrige. Un trou dans le système, on le bouche — une fois pour toutes — en transformant la leçon en une défense qui se déclenchera automatiquement la prochaine fois. La première posture traite des symptômes ; la seconde construit un actif.

C'est tout le sujet de cet article. Pas la capitalisation comme bonne intention vaguement rangée dans un wiki que personne ne lit, mais la capitalisation comme deux phases nommées, datées et non négociables d'un cycle de production logicielle piloté par l'IA. Car un cadre tiers le résume sans détour : sans mécanisme intentionnel de capture des leçons, les agents n'offrent aucun avantage cumulatif — ils repartent de zéro à chaque exécution (Industrie · ADLC, Chris Williams). Le mécanisme n'est pas un supplément d'âme. C'est ce qui sépare un outil qu'on rachète chaque trimestre d'un système qui se valorise.

La conviction qui change tout : le système apprend du projet

Cet article prolonge le SDLC augmenté de SFEIR — le cycle à 11 phases, 3 gates humains et 2 capitalisations. Sa thèse tient en une ligne : le code est le sous-produit ; l'actif réel est la connaissance. Trois convictions la portent — l'IA exécute, l'humain encadre, le projet apprend. C'est cette troisième que nous prenons ici au pied de la lettre.

« Le projet apprend » est une formule facile à répéter et difficile à tenir. Car par défaut, le projet n'apprend pas — il oublie. Patrick Debois, figure historique du mouvement DevOps, pose le diagnostic d'une phrase : « chaque session d'agent est comparable à un nouvel employé qui repart de zéro, sans mémoire institutionnelle » (Industrie · Tessl). L'image est exacte et un peu cruelle : vous avez recruté l'ingénieur le plus rapide du monde, capable d'abattre en une heure ce qui prenait une journée — mais frappé d'amnésie chaque matin. La valeur que vous croyez accumuler s'évapore à la fermeture de la fenêtre de contexte.

La conviction SFEIR retourne ce défaut en programme : « chaque cycle enrichit le suivant — leçons, règles automatiques, standards versionnés. Le 100ᵉ cycle est meilleur que le 1ᵉʳ, par construction. » Le mot qui compte est « par construction ». Il ne s'agit pas d'espérer que l'équipe progresse, ni de parier sur un modèle plus intelligent l'an prochain. Il s'agit d'outiller le cycle pour que la connaissance produite à chaque tour soit capturée, structurée et réinjectée au tour d'après. C'est exactement la bascule que SFEIR nomme Context Engineering : on quitte le prompt engineering — interaction isolée, mémoire éphémère, retour sur investissement linéaire — pour une mémoire persistante d'un projet, qui survit aux sessions et produit un ROI composé. On reviendra sur ce que « composé » veut dire chiffres en main. Retenons d'abord où, dans le cycle, cet apprentissage est censé se produire.

Deux phases, pas une : Compound-1 et Compound-2

La plupart des discours sur « l'IA qui apprend » s'arrêtent à une intuition : capturez vos leçons. Le cycle SFEIR est plus précis. Il pose deux phases de capitalisation distinctes, à deux moments du cycle, parce qu'elles récoltent deux natures de savoir qu'on ne peut pas obtenir au même instant.

Sur la frise des onze phases (0 Setup · 1 Define · 2 Plan · 3 Build · 4 Verify · 5 Review · 6 Compound-1 · 7 Ship · 8 Ops · 9 Compound-2 · 10 Deprecation), les deux capitalisations occupent les positions 6 et 9 — pas par symétrie esthétique, mais parce qu'elles encadrent la livraison. L'une apprend de ce qu'on voit avant d'envoyer en production ; l'autre, de ce qu'on découvre une fois en production. Ce sont deux fenêtres d'observation différentes sur le même travail, et fusionner les deux reviendrait à renoncer à la moitié des leçons.

Compound-1 : capitaliser ce que la revue a vu (phase 6)

Compound-1 récolte les leçons statiques — ce que la revue révèle, juste avant la livraison. Elle suit immédiatement la phase 5, Review, où le cycle SFEIR fait passer le code par plus de quatre angles parallèles : code, sécurité, tests, performance, dont les verdicts sont consolidés. Sans Compound-1, ce verdict finit en commentaires sur une pull request fermée et oubliée. Avec Compound-1, le finding récurrent — « la revue bute toujours sur la gestion des erreurs réseau ici » — quitte le statut de remarque ponctuelle pour devenir une règle. Le bug fixing change de nature : un défaut récurrent attrapé en Verify ou en Review n'est pas seulement réparé, il est promu en règle automatique qui le préviendra la prochaine fois. Le tech lead n'archive pas une correction : il referme un trou dans le système.

Compound-2 : capitaliser ce que seule la prod révèle (phase 9)

Compound-2 récolte les leçons runtime — ce que seule la production révèle, sous charge réelle. Elle suit la phase 8, Ops, où le cycle observe le service en conditions vraies pendant sept à quatorze jours : télémétrie, comportements sous charge, incidents, et le hotfix traité comme un mini-cycle compressé. Aucune revue statique, si rigoureuse soit-elle, ne peut anticiper ce qu'un pic de trafic réel, une donnée client aberrante ou une dépendance tierce capricieuse vont faire surgir. Ces leçons-là n'existent qu'en aval. Compound-2 les capture : un incident de production cesse d'être un mauvais souvenir d'astreinte pour devenir, lui aussi, une règle, un test de non-régression, une question ajoutée à la spécification des prochains cycles.

La distinction est plus qu'organisationnelle. Compound-1 dit ce que le système de revue aurait dû attraper plus tôt ; Compound-2 dit ce qu'aucune revue ne pouvait attraper et qu'il faut désormais surveiller. Confondre les deux, c'est soit demander à la revue de prédire la production (illusion), soit attendre la production pour découvrir des défauts triviaux (gâchis). Deux phases, parce qu'il y a deux vérités.

La boucle se referme au PLAN suivant

Capturer une leçon ne sert à rien si elle reste enfermée dans la phase qui l'a produite. C'est ici que le cycle SFEIR se distingue d'un simple « post-mortem qu'on range ». La note portée sur la frise est explicite : les deux Compound alimentent la mémoire rechargée au PLAN du cycle suivant.

Souvenez-vous de la phase 2, Plan : trois explorations parallèles — code existant, pratiques, frameworks — dont les conflits sont mis à plat avant l'arbitrage humain au gate. C'est précisément là que la mémoire capitalisée revient dans le jeu. Le plan du cycle n+1 ne démarre pas d'une page blanche : il démarre lesté de tout ce que les cycles 1 à n ont appris. Les règles issues de Compound-1, les surveillances issues de Compound-2, les standards versionnés — tout cela conditionne désormais ce que l'agent propose, et ce que l'humain valide. La boucle se referme : apprendre devient une opération concrète du cycle, pas un vœu pieux de rétrospective.

Cette mécanique a une économie, et un cadre tiers l'a formalisée avec une précision utile. L'ADLC décrit une « lesson foundry » — une fonderie de leçons — qui transforme les findings récurrents en défenses permanentes : les problèmes déterministes deviennent des règles de lint accompagnées de tests ; les patterns contextuels alimentent un skill-mining ; les lacunes de spécification déclenchent de nouvelles questions au cadrage. Le principe économique est le plus important à retenir : chaque leçon est payée une seule fois, puis rétrogradée d'une coûteuse détection probabiliste vers une prévention déterministe gratuite (Industrie · ADLC). Traduisons : la première fois, un agent coûteux cherche le bug. Ensuite, un linter de quelques millisecondes l'interdit. Le savoir migre du cher vers le gratuit, et il ne remonte jamais.

D'autres décrivent le même phénomène par sa face « mémoire ». Le framework Lattice parle d'un « living context », un dossier de projet qui « grows smarter across feature cycles » — qui s'enrichit à chaque feature livrée (Industrie · Lattice). C'est exactement le contexte vivant que SFEIR recharge au Plan. La règle de pilotage qui en découle est sobre : on standardise le contexte et la preuve, pas l'outil. L'outil changera ; le contexte, lui, vous appartient et se valorise.

Le ROI composé : pourquoi le 100ᵉ cycle bat le 1ᵉʳ

Tout ceci serait une jolie architecture si elle ne se traduisait pas en résultats. Elle le fait, et le chiffre qui le dit mérite qu'on le pèse exactement.

Mesuré chez SFEIR, après dix cycles : − 30 % d'itérations de correction. C'est la preuve, mesurable, que la capitalisation paie. Insistons sur ce qu'il ne dit pas. Ce n'est pas une promesse de gain universel, ni le fruit d'un modèle plus puissant. C'est le résultat mécanique du fait que les leçons d'un cycle — un bug récurrent, une revue qui bute toujours au même endroit — sont consignées en règles automatiques rechargées au plan suivant. La courbe des corrections ne descend pas par magie : elle descend parce que le système se souvient. Trente pour cent d'allers-retours en moins, ce n'est pas un meilleur agent ; c'est un meilleur système autour de l'agent.

C'est là toute la différence entre un ROI linéaire et un ROI composé. Avec un assistant à mémoire éphémère, vous payez le même prix au cycle 1 et au cycle 100 : chaque tour repart de zéro, le gain est plat. Avec une mémoire de projet qui se compose, chaque cycle abaisse le coût du suivant. Un cadre tiers en fait même un critère de santé brutal : « flat cost is failure » — un coût plat est un échec. Un système qui apprend vraiment voit son coût par changement décroître mesurablement à mesure que les règles s'accumulent et que les couches de garde-fous s'épaississent ; et la bonne unité de compte n'est pas le « nombre de tokens par développeur » mais le coût par changement livré et vérifié (Industrie · ADLC). Si votre courbe de coût est plate, vous n'avez pas un système qui apprend : vous avez un outil que vous louez.

Debois décrit la même trajectoire par l'image du volant d'inertie. La première itération capture les conventions ; à la dixième, un basculement s'opère : ce n'est plus seulement l'agent qui suit mieux les consignes, c'est toute l'équipe qui code différemment — plus vite, plus cohérent, avec moins de corrections (Industrie · Tessl). Et le retour se fait sur quatre fronts à la fois : qualité des agents, expertise approfondie du senior qui codifie son savoir, montée en compétence des juniors qui lisent ce savoir, et alignement de toute l'organisation sur un vocabulaire commun. C'est l'esprit de la stratégie AI for IT — le 10x de SFEIR : viser un facteur dix, pas des gains marginaux, en déplaçant l'effort de la production manuelle de code vers le pilotage du contexte.

La convergence : tout le monde redécouvre la phase qui apprend

Une doctrine maison ne vaut que si elle survit au contact d'autres esprits. Or le plus frappant, en 2026, est que des équipes qui ne se parlent pas dessinent la même phase finale d'apprentissage — chacune avec son vocabulaire, toutes avec la même fonction.

Chez Every, le Compound Engineering organise le développement en une boucle Plan → Work → Assess → Compound, et ses auteurs ne s'embarrassent pas de litote : l'étape Compound est « the money step », l'étape critique. Après chaque revue, les leçons sont résumées et stockées dans le codebase ; comme elles y vivent, un nouvel arrivant se retrouve aussi bien armé qu'un vétéran. Leur axiome — « chaque unité de travail d'ingénierie devrait rendre les suivantes plus faciles, pas plus difficiles » — est le jumeau exact de la conviction SFEIR (Industrie · Every). Debois, lui, formalise un Context Development Lifecycle en quatre phases (Générer, Évaluer, Distribuer, Observer) qui traite le contexte comme un artefact d'ingénierie versionné et testé, pas un markdown oublié — et martèle que le moat n'est ni les outils ni les modèles, qui se commoditisent, mais la connaissance produit accumulée. L'ADLC, enfin, place en bout de cycle une phase Distill dédiée à faire baisser le coût à chaque exécution.

Quatre cadres, quatre noms — Compound, CDLC, Distill, living context — une seule fonction : refermer le cycle sur une phase qui transforme le travail en savoir réutilisable. Quand des équipes indépendantes convergent à ce point, ce n'est plus une mode, c'est une propriété du problème. Pour un décideur, cela change la nature du pari : adopter une phase de capitalisation explicite n'est pas miser sur une doctrine d'éditeur, c'est s'aligner sur un invariant que le marché redécouvre de tous les côtés. Le mécanisme générique de ce compounding, nous l'avons traité ailleurs — voir notre article sur le cycle cumulatif du Compound Engineering. L'apport propre du SDLC SFEIR est de l'ancrer dans un cycle à onze phases et de le dédoubler en deux moments — statique et runtime — là où la plupart des cadres n'en posent qu'un.

Les pièges : la capitalisation qui pourrit

Un discours honnête nomme ses propres failles. Capitaliser n'est pas une assurance tous risques ; mal fait, le mécanisme se retourne. Trois pièges méritent d'être nommés.

Le premier est le skill rot — la pourriture de la connaissance. Un artefact capitalisé qui devient obsolète ne se contente pas d'être inutile : il « délivre une désinformation avec autorité » (Industrie · ADLC). Une règle qui pointe vers une commande disparue, un standard qui décrit une architecture révolue : l'agent les applique avec le même aplomb que les bonnes. La parade est une hygiène, pas un dogme — des vérifications régulières qui extraient les éléments vérifiables (commandes, chemins, versions) et marquent leur fraîcheur. Une mémoire qui ment est pire qu'une absence de mémoire.

Le deuxième est l'absence d'ownership. Debois est catégorique : sans propriétaire désigné — équipe plateforme, context engineers, ou simplement un rôle clairement assigné — le contexte pourrit, exactement comme avant lui la documentation, l'infrastructure et la sécurité (Industrie · Tessl). La capitalisation est un livrable ; un livrable sans responsable n'est livré par personne. Dans le cycle SFEIR, ce rôle revient au tech lead en Compound-1, aux Ops et au lead en Compound-2 : le savoir devient un livrable d'équipe, pas un fichier orphelin.

Le troisième est le plus insidieux : capitaliser le « claim » plutôt que la preuve. Un agent peut affirmer « les tests passent » sans qu'ils passent, approuver par réflexe la demande de son interlocuteur, ou « optimiser » une métrique au lieu de résoudre le problème. Capitaliser ses déclarations, c'est graver ses erreurs dans le marbre. D'où la discipline de preuve du cycle : on capture la sortie réelle de chaque étape, jamais la parole de l'agent. Un mot de rigueur, ici, car il est facile de s'y tromper : « 100 % des sorties capturées » n'est pas un indicateur de performance. C'est l'énoncé d'un principe de fonctionnement — l'évidence prime sur la déclaration. Le présenter comme une métrique serait un contresens, et la rigueur sur ce point fait partie de la méthode.

Par où commencer : faire de la leçon un livrable

Si une seule idée doit rester, c'est celle-ci : la capitalisation ne s'achète pas, elle s'institue. Voici par où démarrer, sans grand programme préalable.

D'abord, rendre la capture non négociable en fin de cycle. Pas un wiki facultatif — une phase, avec un responsable et un format. Dans le cycle SFEIR, Compound-1 et Compound-2 ne sont pas des options : ce sont des étapes au même titre que Build ou Ship. La règle de pilotage est constante : on standardise le contexte et la preuve, pas l'outil. C'est le contexte qui vous appartient et se valorise ; l'outil, lui, sera remplacé.

Ensuite, versionner la leçon comme du code. Une règle de lint, un test de non-régression, une question ajoutée à la spec : ces formats-là sont déterministes, gratuits à l'exécution, et impossibles à oublier. C'est la traduction concrète de « payer une leçon une fois ». À l'inverse, une note en prose dans un document partagé est déjà à moitié pourrie. Une heuristique utile, empruntée aux praticiens d'Every, tient en trois questions à poser avant de construire : où cela va-t-il dans le système ? faut-il l'ajouter à l'existant ou créer du neuf ? a-t-on déjà résolu un problème similaire ? La troisième est, à elle seule, le réflexe de la capitalisation.

Enfin, recharger au plan suivant — sinon rien de tout cela ne compose. Une mémoire qu'on alimente mais qu'on ne relit jamais au démarrage du cycle d'après n'est qu'un cimetière de bonnes intentions.

Sur ce terrain, SFEIR a un parti pris : se l'appliquer d'abord à elle-même, avec l'objectif de 850 consultants 100 % augmentés par l'IA fin 2026, avant de déployer le modèle chez ses clients. Car la promesse n'est pas un meilleur assistant. C'est un cycle qui transforme chaque unité livrée en capital pour la suivante — un système qui, au lieu de réapprendre ses erreurs dix fois plus vite, les bouche une fois pour toutes. Le bug que vous avez payé deux fois, vous ne le paierez pas une troisième : il n'est plus un bug, il est devenu une ligne dans le système. Reste la seule question qui vaille pour la suite : à votre prochain cycle, votre projet redémarrera-t-il plus savant — ou amnésique ?

Cet article fait partie d'une série sur le SDLC augmenté de SFEIR : l'amont (Define & Plan), l'aval (Ship, Ops, Deprecation), les limites du certifiable et la convergence des cadres (ADLC). Sur le mécanisme général d'apprentissage cumulatif, voir aussi le cycle cumulatif du Compound Engineering.

Sources

1. SFEIR — SDLC augmenté : « un bug vu deux fois n'est pas un bug, c'est un trou dans le système » ; − 30 % d'itérations de correction après 10 cycles, matière first-party, 2026.
2. Chris Williams, The Lifecycle That Gets Cheaper Every Run (ADLC, partie 6) — voodootikigod.com, 12 juin 2026.
3. Patrick Debois, The Context Flywheel: Why the Best AI Coding Teams Will Win on Context — tessl.io, 26 février 2026.
4. Patrick Debois, The Context Development Lifecycle: Optimizing Context for AI Coding Agents — tessl.io, 19 février 2026.
5. Kieran Klaassen, Compound Engineering: The Definitive Guide — every.to, 9 février 2026.
6. techygarg, Lattice — Composable AI skills (« living context over static config ») — github.com, 5 mai 2026.