Image generated by Google Gemini
Si un agent IA a casse votre application lors d’un refactoring, si vous voulez transformer des systemes legacy en un environnement ou l’IA peut travailler, si vous voulez convertir les budgets de maintenance legacy du Fortune 500 en budgets de transformation – cet article est la feuille de route.
Memoire verrouillee
A l’epoque de la bulle Internet, les entreprises ont commence a accumuler des actifs numeriques. Code, bases de donnees, specifications, documentation, API — la memoire d’entreprise accumulee sur des decennies.
Cette memoire etait verrouillee. Impossible a explorer, impossible a verifier, impossible a atteindre (unreachable). La seule methode : qu’un humain lise, comprenne et corrige directement. C’est pourquoi 60 a 80 % des budgets IT du Fortune 500 servent a maintenir cette memoire verrouillee. On ne peut pas l’ouvrir, alors on se contente de la garder.
Nous traversons actuellement ce qu’on appelle la bulle IA. Le vrai sens de cette periode n’est pas que les modeles deviennent plus intelligents. C’est que les vieilles memoires legacy des entreprises commencent a devenir accessibles (reachable).
Mais pas encore. En 2026, les agents IA ecrivent du code. 68 minutes, des millions de tokens brules, le refactoring est termine. L’application est completement cassee. Une histoire qui revient chaque jour sur X.
Pourquoi cela se repete-t-il ?
Ce n’est pas que l’agent est stupide. C’est que l’environnement n’est pas fait pour qu’un agent y travaille. On ne met pas un robot dans un bureau ou travaillent des humains. On construit une usine ou le robot peut travailler.
Pour ouvrir la memoire verrouillee, il faut d’abord qu’elle prenne une forme qui permette l’ouverture. Ce n’est pas qu’une question de code. Bases de donnees, specifications, documentation, API — l’ensemble des actifs numeriques de l’entreprise est opaque pour l’agent.
Qu’est-ce que Agent-Operable
Pour qu’un agent travaille de facon autonome, trois conditions sont necessaires :
1. Il doit pouvoir lire — sans bruit
Dans un fichier de 2 000 lignes, pour trouver une seule fonction, 1 950 lignes sont du bruit. Dans une base non normalisee, trouver des informations client exige de joindre trois tables. Les regles metier cachees dans des feuilles Excel sont introuvables par un agent.
Lisible ne signifie pas lisible par un humain. Cela signifie parsable structurellement par une machine.
2. Il doit pouvoir verifier — mecaniquement
Si apres une modification par l’agent, on ne sait pas ce qui est casse, on tombe dans un doom loop. Le code a besoin de tests, la base de donnees de contraintes, l’API de validation de schema, les specifications de verification croisee.
Un LLM qui verifie un LLM, c’est demander a un ami ivre “Est-ce que je suis ivre ?”. go test n’hallucine pas. Les contraintes CHECK ne mentent pas. JSON Schema ne derive pas.
3. L’etat doit persister — meme si l’agent meurt
Un agent finit toujours par tomber. Limite de tokens, erreur reseau, session coupee. Si la progression n’est pas sauvegardee, on repart de zero a chaque fois.
Si l’agent A traite jusqu’a la fonction 200 et meurt, l’agent B doit reprendre a partir de la 201. Les agents sont jetables, mais la progression doit s’accumuler.
Etape 0 : taxidermisez les bugs
Les trois conditions sont la destination. Le point de depart est different. Pas de documentation, pas de tests, 300 fichiers de 2 000 lignes — voila le legacy de depart.
Dans cet etat, si on dit a l’agent “refactorise”, que se passe-t-il ? Il “corrige” un bug vieux de 10 ans. Le probleme : ce bug n’est pas un bug.
Hyrum’s Law : tout comportement observable d’une API suffisamment ancienne a quelqu’un qui en depend. Une erreur d’arrondi ignoree pendant 10 ans est liee a la logique de paiement d’un client VIP. Un bug de parsing de date a genere des macros Excel qui soutiennent toute la comptabilite. Les vieux bugs sont des specifications metier implicites.
La premiere mission de l’agent n’est pas de corriger le code. C’est de taxidermiser le comportement actuel.
On interroge l’API. On enregistre la reponse. On la fige en test Hurl. Bug bizarre ou comportement intentionnel, on ne fait pas la distinction. On taxidermise tel quel. C’est le premier cran du ratchet — on verrouille pour empecher l’agent d’“ameliorer” a sa guise.
Le changement ne releve que de celui qui detient la specification. L’agent est un executant. Pas un decideur.
Une fois la taxidermie terminee, la transition vers les trois conditions — lecture, verification, persistance — peut commencer.
Pas seulement le code
“Agent-operable codebase” est un point de depart. Les actifs numeriques d’une entreprise ne se limitent pas au code.
| Actif | Etat actuel | Etat Agent-Operable |
|---|---|---|
| Code | Fichiers de 2 000 lignes, pas de tests | Un fichier = un concept, tests pour chaque fonction |
| Base de donnees | Non normalisee, pas de documentation | Gestion declarative DDL, migration auto-generee |
| Specifications | Wiki, transmission orale, derive | 9 SSOT en verification croisee, chainage par identifiant unique |
| Documentation | Regles cachees dans PDF, Excel | Schema extrait, lisible par machine |
| API | Non documentee, contrat implicite | Capture OpenAPI, validation de schema |
Pris separement, c’est “il faut mieux ranger”. Vu ensemble, c’est un systeme.
Symbolic Feedback Loop
Une structure commune rend cette transition possible.
Le LLM genere -> un outil deterministe juge -> le resultat est renvoye au LLM -> on repete
Dans le code, les tests, les specifications, les donnees — la meme boucle fonctionne :
Structure du code : filefunc validate -> feedback de violation -> correction LLM -> repeter
Tests : go test + coverage -> feedback lignes non couvertes -> renforcement LLM -> repeter
Coherence des specs : yongol check -> feedback de derive -> correction LLM -> repeter
Regles utilisateur : rulecat evaluate -> feedback de violation -> correction LLM -> repeter
Le LLM n’intervient que pour la “generation”. Quoi modifier, si c’est valide, quelle est la prochaine etape, si c’est fini — tout est decide par la machine. On ne donne pas le pouvoir de decision au LLM.
Ce n’est pas une invention. C. elegans investit 60 de ses 302 neurones (20 %) dans la perception. Pas la generation — la verification. C’est la conclusion de 500 millions d’annees d’evolution : ameliorer la qualite du feedback est plus avantageux pour la survie qu’augmenter le nombre de neurones.
L’industrie rend le train (le modele) plus rapide. Des modeles plus gros, des agents plus intelligents, de meilleurs prompts. Mais plus le train accelere, plus les rails comptent.
80/20
A l’etat final, le systeme se divise en deux couches.
SSOT (80~90 %)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── Genere a partir des specs. Derive bloquee a la source. Modification libre par l'agent.
Custom (10~20 %)
├── Regles metier, logique de domaine, calculs juridiques/politiques
└── Structure par filefunc, tests assures par tsma. Verification humaine.
Le code qui necessite vraiment l’attention humaine est compresse a 10-20 %. Le reste, l’agent le genere a partir des specifications, et la machine le verifie.
Les 60 % du Fortune 500
60 a 80 % des budgets IT du Fortune 500 sont consacres a la maintenance du legacy. 42 % du temps des developpeurs est consomme par la dette technique. 70 % des migrations manuelles de legacy echouent.
Ce budget est deja depense. Pas besoin d’en creer un nouveau. Il suffit de changer la direction. Transformer le budget de maintenance en budget de transition.
On injecte le legacy dans sa totalite et on obtient un systeme agent-operable. C’est la promesse de Building Agent-Operable Systems.
Pourquoi les Big Tech ne font-elles pas cela
Anthropic et OpenAI construisent des modeles generalistes. Ameliorer un modele de 10 % s’applique a tous les clients. Mais construire une boucle de feedback Go test ne s’applique qu’aux developpeurs Go. Construire un outil de couverture Python ne s’applique qu’aux projets Python.
La verification symbolique est par nature specifique au domaine. Chaque langage, chaque framework, chaque specification necessite un verificateur different. Pas de caractere generaliste, donc pas de ROI pour les Big Tech.
C’est pourquoi cette place est vacante. Ceux qui construisent le train et ceux qui posent les rails ne sont pas en concurrence — ils se completent.
Questions
Votre agent ecrit du code. Mais qui verifie que ce code est correct ?
Un autre agent ? Ou go test ?
Votre LLM lit-il vraiment les 100 000 lignes ?
Ou fait-il semblant de les lire ?
A l’ere des agents, ce qu’il faut, ce n’est pas un agent plus intelligent. C’est un systeme ou l’agent peut travailler.
Sources
- Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
- Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
- McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
- Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
- Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
- White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
- Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
- METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
- GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
- Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks