TL;DR Huit modèles de pointe remplacés en six mois, sans une réunion ni un jour d'onboarding : le modèle est désormais une dépendance versionnée qui se déprécie. Ce qui se capitalise habite le dépôt : 59 ADR que les agents lisent avant tout changement structurel, 134 règles contraignantes câblées à une CI bloquante, et le contexte versionné de chaque sous-système. Puis notre propre inventaire a trouvé la doctrine en dérive, précisément là où rien ne la vérifie. La version honnête de la thèse a survécu à l'audit : seule la part exécutée d'une doctrine tient ses promesses.
En six mois, j'ai remplacé huit fois le cerveau de mon équipe. Personne ne s'en est aperçu.
Huit modèles de pointe entre février et juillet — je les ai comptés en notant le semestre. Chaque remplacement a coûté une ligne de configuration et zéro réunion. Pas d'onboarding, pas de transfert de connaissances, pas de pot de départ. Et si personne ne s'en est aperçu, c'est tout le sujet de ce billet : plus rien de ce qui fait fonctionner mon équipe n'habite le modèle. Les briefs, les règles, les garde-fous, le contexte — tout habite le dépôt, versionné, relu, imposé. Le modèle a cessé d'être un miracle. Il est devenu une dépendance.
Le modèle est une dépendance
Prenez cette phrase au pied de la lettre, pas comme une figure de style. Une dépendance, c'est quelque chose qu'on épingle à une version, qu'on met à jour délibérément, et dont on attend la dépréciation. Les éditeurs de modèles ne garantissent parfois que soixante jours de préavis avant retrait ; les durées de vie effectives se comptent en mois. Tout ce que vous construisez à l'intérieur du comportement d'un modèle précis — les astuces de prompt, le contournement de la faiblesse du trimestre dernier — se déprécie au même rythme. S'accorder à un modèle, ce n'est pas investir. C'est louer.
Un modèle se remplace en une ligne de configuration. Une doctrine se reconstruit en années.
La Bitter Lesson, prise au sérieux
Il y a ici une objection sérieuse, et elle mérite d'être énoncée dans toute sa force. La Bitter Lesson de Richard Sutton, appliquée aux agents, dit que tout échafaudage est un pari contre le prochain modèle : l'orchestration sophistiquée que vous écrivez à la main aujourd'hui est exactement ce que la prochaine version absorbe, et les constructeurs de harnais eux-mêmes ont supprimé des pans entiers de leur échafaudage à chaque génération. Cette critique est juste — pour l'échafaudage procédural. Le flux de contrôle écrit à la main, la logique d'orchestration, la chorégraphie de prompts : cette couche se déprécie avec les modèles, et nous avons jeté la nôtre plus d'une fois.
Mais elle ne touche pas l'autre couche. Aucune version de modèle ne saura jamais, en sortant de l'usine, que dans notre produit un champ précis est verrouillé après signature pour des raisons légales — le même champ verrouillé qui piégeait la story générée du billet précédent, et ce n'est pas un hasard. Ce fait n'est pas de l'intelligence ; c'est notre système. La couche déclarative — les décisions, les contraintes, les règles métier, les critères d'acceptation — est un savoir qu'aucun progrès des modèles ne rend obsolète, parce qu'aucun éditeur ne le possède. La thèse de ce billet est volontairement étroite : l'échafaudage procédural se déprécie comme les modèles. Ce qui se capitalise, c'est la doctrine déclarative et vérifiée par la machine.
Ce que les agents lisent avant de toucher au code
Concrètement, sur Solstice*, un agent ne part pas d'un prompt vide. Il existe un ordre de lecture officiel, écrit : le fichier de contexte racine, puis les ADR, puis le fichier de contexte du sous-système qu'il s'apprête à toucher, puis les règles métier, les règles de design, la sécurité. Le corpus derrière cet ordre, à fin juillet : 59 ADR que les agents doivent lire avant tout changement structurel. Plus de 134 règles contraignantes, chacune reliée aux critères d'acceptation de la spec qu'elle sert, chacune imposée par une CI bloquante — aucune règle ne dérive en silence. C'est du moins ce que la méthode affirme d'elle-même ; gardez cette phrase en tête. 23 scripts de contrôle anti-dérive. 47 skills packagés. 42 fichiers de contexte : un à la racine, un par sous-système, chacun documentant le rôle du service, ses ADR applicables, ses conventions locales.
Deux détails de cette liste disent où tout cela va. La porte pré-PR rend un verdict PASS/FAIL dont la sortie JSON est explicitement écrite pour être lue par un agent — la machine écrit pour la machine. Et un garde-fou surveille la couche de contexte elle-même : quand le code d'un dossier change, il rappelle de mettre à jour le fichier de contexte du dossier. La doctrine documente le système ; un contrôle contrôle la doctrine. Des poupées russes, mais des poupées utiles.
Rien de tout cela n'est une idée neuve. Mon secteur réglementé pratique la compliance as code depuis des années : la politique écrite en prose que personne ne lit devient une règle qu'un pipeline impose. Et le retour en grâce des ADR à l'ère des agents tient en une phrase que j'ai vue se vérifier : un agent qui ne voit pas pourquoi le code a cette forme refactore la raison. La logique de retry qui a l'air redondante, le nommage qui a l'air hérité — un agent supprime en quelques secondes ce qu'il a fallu un incident et des semaines pour apprendre. L'ADR, c'est la leçon de l'incident, et elle reste acquise.
J'ai enterré le SDLC. Puis j'ai écrit 134 règles.
Voici le paragraphe que je vous dois. Mon premier billet de cette série déclarait le SDLC mort : le processus a toujours été du gaspillage, la cérémonie est ce qu'on fait quand on ne fait pas confiance à ses outils. Un lecteur hostile écrit le tweet en dix secondes : il a tué le SDLC et l'a reconstruit en YAML.
Oui, j'ai reconstruit un processus. La promesse n'a jamais été « zéro processus ». C'était « zéro processus qui brûle des heures humaines sans rien vérifier ».
Voici le discriminant, et il est falsifiable. Une cérémonie consomme du temps humain à chaque occurrence et ne vérifie rien : la réunion d'estimation, la signature de validation, le point d'avancement — des heures par semaine, pour toujours, et aucune n'a jamais intercepté de régression. Une contrainte compilée consomme zéro temps humain marginal et vérifie à chaque fois : la règle tourne en quelques secondes, bloque de façon déterministe, et ne fatigue pas le vendredi après-midi. L'ancien processus taxait les humains pour produire un sentiment de contrôle. La doctrine taxe les machines pour produire du contrôle réel. Et le jour où une de nos règles exige une réunion pour être interprétée, elle est redevenue une cérémonie — et elle doit mourir.
Je concède même les pièces à conviction : le billet de mars louait déjà l'agent qui « valide contre les contraintes architecturales ». La doctrine, c'est cette phrase, industrialisée. Ce qui est mort, ce n'est pas le processus. C'est le processus pointé sur les gens.
Un flanc reste ouvert, et je préfère le nommer moi-même. Une doctrine qui ne fait qu'accréter est le nouveau gaspillage — 134 règles en quatre mois et demi, extrapolez, je refuse d'écrire le chiffre. L'élagage a commencé là où il était le moins cher : quatre skills ont été supprimés du bundle quand les modèles les ont rendus natifs. Règles supprimées à ce jour : zéro. C'est le flanc ouvert. Ressortez-le-moi.
L'inventaire qui pique
Fin juillet, on a inventorié notre propre méthode — chaque fichier, chaque script, chaque affirmation que la méthode fait sur elle-même. Le verdict mérite sa section.
Les quatre trouvailles, en entier, parce qu'une confession ne compte que détaillée :
- des fichiers agents décrivant encore l'ancien framework, des mois après la migration ;
- un script documenté « bloquant en PR », câblé nulle part ;
- le garde-fou de fraîcheur du contexte : consultatif, il ne bloque jamais ;
- la porte locale, sous-ensemble strict de la CI — un PASS local ne garantit rien.
La lecture honnête, et je ne vais pas l'enjoliver : la couche qui s'exécute a tenu. La couche qui décrit a pourri, en silence, pendant des mois — et c'est un audit manuel, non planifié et tardif, qui l'a trouvée. Un détecteur de fumée testé une fois, après l'odeur. Les fichiers décrivaient encore le framework frontend qu'on a quitté en vol ; une couche d'instructions a été mise à jour, les autres non. Rien n'a cassé, parce que rien n'exécute une description. Un code faux casse un test. Un fichier de contexte faux casse un agent, en silence, trois semaines plus tard, dans une PR plausible.
La doctrine ne se capitalise que là où elle s'exécute.
L'audit a aussi mis un chiffre sur qui paie. 85,4 % des commits de Solstice portent mon nom — un biais que le deck de la méthode déclare lui-même. La doctrine existe en partie pour réduire la dépendance de l'équipe à son tech lead. Elle est aujourd'hui écrite, et entretenue, surtout par le tech lead. Ce n'est pas un paradoxe ; c'est un contrat de maintenance signé avec l'équipe future, et il coûte du vrai temps senior chaque semaine. Mais cela veut dire que la mitigation du facteur bus est à moitié construite : si je partais demain, l'équipe hériterait d'un corpus largement juste sans savoir quelles parties mentent — pire que rien, sans doute, parce que les agents exécutent les parties périmées avec une confiance totale. La suite est connue et sans gloire : le garde-fou de fraîcheur doit devenir bloquant — c'est sur la roadmap — et l'inventaire doit devenir un rituel, pas un accident.
Dernière réserve, contre moi-même. Tout cela a poussé sur une plateforme greenfield, avec un ingénieur très senior qui tient la plume, pour l'essentiel. Sur le code legacy que la plupart d'entre nous maintiennent, mon propre gain mesuré reste à 10 % ou moins, et la doctrine y enregistre surtout l'archéologie — elle capitalise plus lentement, parce que la moitié des décisions ont été prises par des gens partis depuis. Lisez ce billet comme un point de données en conditions quasi idéales, pas comme une méthode transposable telle quelle.
Ce qui reste aux humains
Décider quelles règles existent. La machine impose une décision. Elle n'en prend pas.
Supprimer des règles. L'élagage est un jugement, et c'est la différence entre une doctrine et une bureaucratie. Personne n'automatise le courage de retirer une porte.
Arbitrer quand la doctrine et le jugement se contredisent. Une règle dit non ; la personne qui connaît le domaine dit que ce cas est différent. Quelqu'un signe cette dérogation — le billet sur le jugement parle exactement de qui.
Savoir quel document mettre en doute. Tant que la fraîcheur n'est pas imposée par un contrôle, ce savoir est tribal — et le savoir tribal est précisément ce que tout cet édifice devait remplacer.
Et la clarification habituelle, parce que cette série a une règle à ce sujet : rien de tout cela ne plaide pour moins de gens — l'argument complet est dans le billet sur le jugement. Un actif que personne n'entretient est un passif avec une belle image de marque.
Lundi matin
- Inventoriez votre doctrine avant d'en écrire davantage. Chaque fichier d'instructions, chaque contrôle, chaque affirmation que votre méthode fait sur elle-même. Ce que vous trouverez réordonnera le reste de cette liste.
- Un fichier de contexte racine que les agents lisent vraiment. Stack actuelle, architecture actuelle, une page. Un contexte faux est pire que pas de contexte du tout.
- Cinq règles maximum, chacune câblée à un contrôle qui bloque. Une règle en prose est un vœu avec un numéro de version. Zéro règle non câblée, dès le premier jour.
- Des ADR seulement pour les décisions déjà re-débattues une fois. C'est le signal que la raison doit être écrite avant qu'un agent ne la refactore.
- Rendez la porte de fraîcheur bloquante avant que le corpus ne grossisse. « Fichier de contexte touché quand le code du dossier change » ne coûte rien à cinq fichiers et coûte tout à quarante-deux.
- Le pipeline réunion→règles en dernier. Celui qui transforme l'atelier hebdomadaire en compte rendu, règles et issues — décrit dans le billet sur le jugement. C'est le moteur de capitalisation, mais seulement une fois les cinq points ci-dessus en place.
Lire la suite de la série : Le SDLC est mort — le billet auquel celui-ci répond en partie. Coder n'a jamais été le métier — ce que devient l'ingénieur quand la syntaxe disparaît. L'IA est devenue un réflexe d'équipe — à quoi ressemble une équipe IA-native un mardi. DORA vient de confirmer ce que mon équipe a déjà vécu — l'amplificateur, mesuré. 100 % du code écrit par des agents — les six mois que couvrent les huit modèles. Le backlog n'a jamais été le métier — qui signe quand la doctrine et le jugement ne sont pas d'accord. Les tests passent. Il ne se passe rien. — le défaut sans symptôme, et ce qui l'attrape à la place de la lecture. La compétence était réelle. Le poste, non. — où vivent les règles une fois que le rôle qui les possédait fusionne dans un autre.
Sources
- Anthropic — Effective context engineering for AI agents : le cadrage du contexte comme actif d'ingénierie, par le laboratoire lui-même. Un éditeur qui a intérêt à ce que vous investissiez dans son harnais — à lire comme « le labo le dit aussi », pas comme une preuve.
- AGENTS.md : la convention multi-éditeurs de contexte agent, versée à l'Agentic AI Foundation (Linux Foundation) fin 2025. Les chiffres d'adoption viennent des promoteurs de la spec.
- actual.ai — Agent-optimized ADRs : le mode de défaillance « l'agent refactore la raison ». Littérature de praticiens, pas de la recherche évaluée par les pairs.
- Context rot in AI-assisted development (preprint) : des références périmées mesurées dans les artefacts de configuration et de contexte des dépôts. Un preprint — une direction, pas des décimales.
- Richard Sutton — The Bitter Lesson et son application aux frameworks d'agents : l'objection la plus forte contre ce billet, citée exprès. Elle gagne contre l'échafaudage procédural ; la couche déclarative est la réponse.
- Policy-as-Prompt (arXiv) : le policy-as-code étendu à la gouvernance des agents — la filiation que ce billet revendique.
- Solstice* — le deck de la méthode et l'inventaire de fin juillet : les décomptes (59 ADR, 134+ règles, 23 scripts, 47 skills, 42 fichiers de contexte), les 85,4 % de concentration des commits que le deck déclare lui-même comme biais, et les quatre trouvailles de dérive. Documents internes, pas de lien : le nom de code est fictif et le projet réel, ses produits et son éditeur sont anonymisés.