Une idée de fonctionnalité, un prompt, cinq minutes d’attente. Le code arrive, il passe les tests, il part en production. Dans toute cette séquence, personne n’a pris la décision d’architecture qui allait avec.
C’est ce point aveugle qu’explorent Simon Willison et Claire Giordano dans un épisode du podcast Talking Postgres consacré à l’effet de l’IA sur le développement logiciel. Willison y tient une position inconfortable : l’accélération est réelle, elle se chiffre, et c’est précisément pour cela qu’elle abîme une propriété que personne ne mesure.
Cinq minutes pour une fonctionnalité, quarante ans pour une maison
La notion qu’il mobilise vient de The Mythical Man-Month de Fred Brooks : l’intégrité conceptuelle. Un logiciel qui en possède ne réserve pas de surprises, couvre exactement le domaine qu’il doit couvrir, et ses pièces s’emboîtent sans qu’il faille retenir d’exceptions. C’est une propriété d’ensemble : invisible dans un diff, invisible dans une pull request.
Avec des agents, décrit Willison, le logiciel se met à pousser de petites excroissances dans des directions bizarres. Claire Giordano lui répond par une image : la Winchester Mystery House, cette maison de San Jose que sa propriétaire a fait agrandir presque sans interruption pendant près de quarante ans. Willison note lui-même que la légende du médium à l’origine du chantier est contestée. Peu importe l’anecdote : ce qui compte, c’est qu’ajouter une pièce y a toujours coûté moins cher que de se demander à quoi ressemblait l’ensemble.
Le filtre, avant, c’était le temps. Une fonctionnalité qui demandait une semaine se refusait toute seule : personne ne pouvait la justifier. La même idée à une heure de travail passe sans discussion. Le tri se faisait au prix, jamais au jugement d’architecture ; ce prix a fondu, et le tri avec lui.
Mille lignes par jour, une seule tête pour les tenir
Sur la productivité, Willison défend une idée mal vue : compter les lignes de code n’est pas absurde, parce qu’il existait une borne physique. Un ingénieur produisait 50 à 60 lignes prêtes pour la production dans une journée ordinaire ; 200 lignes fonctionnelles et déboguées, c’était une très bonne journée.
Avec des agents, ce palier monte à un millier de lignes déboguées, à une condition expresse : que la qualité tienne au même niveau, maintenabilité et tests compris. Et cette condition, précise-t-il, demande énormément de compétence, de connaissances et d’expérience. Autrement dit, le palier tient au profil senior qui pilote bien plus qu’à l’outil qui produit.
L’échange livre ensuite l’observation qui devrait guider le dimensionnement des équipes : on peut écrire cent fois plus vite, on ne peut pas suivre cent fois plus de code. Le facteur limitant a glissé de la vitesse d’écriture vers l’attention disponible. D’où la conclusion de Willison : les équipes restent nécessaires pour répartir cette charge cognitive, une équipe d’une seule personne étant de toute façon une équipe mal conçue.
Le débit, lui, ne dit rien de la cohérence. On peut parfaitement livrer mille lignes par jour dans une maison qui a perdu son plan.
Pourquoi la même erreur revient la semaine suivante
Un papier déposé sur arXiv le 19 août prolonge ce diagnostic par un mécanisme précis, et surtout par une prise concrète. George Andrikopoulos, ingénieur systèmes, part d’une observation banale : quand un expert corrige l’erreur d’un assistant LLM (grand modèle de langage), la correction meurt avec la session, et la classe d’erreur revient.
Son diagnostic ne met pas en cause les outils. Les mécanismes qui font persister une correction existent déjà, livrés dans les produits. Ce qui manque, c’est la discipline pour les gouverner : versionnage avec provenance, surveillance de la récurrence, contre-métriques, retrait des règles devenues obsolètes. Un sujet d’exploitation, au sens industriel du terme, qui relève de la maintenance quotidienne plus que du développement.
Son cadre traite la pile LLM comme les machines que sa profession exploite depuis trente ans : silicium figé, firmware, modules chargeables, configuration persistante, mémoire volatile. Le plus instructif, ce sont les endroits où la comparaison casse. La génération est stochastique. Une consigne ne s’applique qu’avec une probabilité, jamais à coup sûr. Et il n’existe, par défaut, aucune étape de retrait ni de vérification. Un fichier d’instructions permanentes n’a rien d’un fichier de configuration : il influence, il ne contraint pas.
Il en tire sept principes articulés autour d’une boucle d’erreur, illustrés par trois cas pris dans sa pratique. Le plus parlant : un garde-fou qui a fini par produire, sans que personne le remarque, le dommage même qu’il devait empêcher. C’est l’argument le plus solide en faveur des contre-métriques et de la péremption des règles. Une consigne ajoutée pour éteindre un incident continue d’agir longtemps après que le contexte a changé.
Les fichiers d’instructions vont finir versionnés et datés
Ces fichiers sont déjà partout : CLAUDE.md côté Claude Code, AGENTS.md côté Codex, Cursor ou Gemini CLI, un format désormais hébergé par l’Agentic AI Foundation. Ni l’un ni l’autre n’impose le moindre champ : pas de date, pas de version, pas de responsable.
Les équipes qui tiendront la cadence dans deux ans seront celles qui auront cessé de bricoler leurs instructions permanentes dans un coin du dépôt, pour les traiter comme de la configuration de production : datées, versionnées, rattachées à l’incident qui les a fait naître, revues, périmables. Les feature flags, ces interrupteurs qui activent ou coupent une fonctionnalité en production, ont suivi exactement ce chemin, du bricolage local au registre gouverné, en quelques années.
Ce basculement ira aussi vite que trois choses se mettront en place :
- que la survie des corrections devienne mesurable, au même titre que la couverture de tests ;
- que quelqu’un porte nominativement la revue de ces règles, sinon elles s’empilent sans jamais être retirées ;
- que la décision d’architecture redevienne un acte distinct de la revue de code, parce que les agents produisent désormais le second sans jamais déclencher le premier.
Une réserve honnête : ce papier est une position d’ingénieur appuyée sur trois cas, et son auteur réclame lui-même l’étude en laboratoire qui validerait son cadre de mesure. À lire comme une discipline proposée, en attente de validation. La question qu’il pose, elle, reste entière, et personne ne l’instrumente aujourd’hui.
Comptez les corrections encore vivantes un mois plus tard
Un chiffre à produire cette semaine, si vous pilotez une équipe outillée par des agents : sur vos vingt dernières corrections d’expert, combien sont encore appliquées un mois plus tard sans que personne ait eu à les redonner ? Combien de classes d’erreurs sont revenues à l’identique ? Et combien de règles avez-vous retirées ce trimestre ?
La troisième réponse est la plus révélatrice. Une base de règles dont on ne retire jamais rien finit par reproduire la Winchester Mystery House, un étage plus haut.
