Idée principale

Le volume de code produit et les propriétés d'ensemble d'un système ne varient pas ensemble. La cohérence d'architecture, la fiabilité en exploitation, la sécurité et la qualité des intégrations ne sont pas des quantités que l'on obtient en écrivant davantage : ce sont des propriétés de l'ensemble, qui se dégradent quand les parties s'ajoutent sans arbitrage.

La question technique qui compte se déplace donc. « Peut-on coder ça ? » redevient une question banale dès que la production est abondante ; les questions qui restent difficiles sont ailleurs : peut-on l'intégrer proprement dans l'existant, peut-on le maintenir, peut-on le sécuriser, peut-on le faire tenir dans le réel.

Ce que l'équipe technique apporte n'est plus principalement la capacité d'écrire, c'est le jugement de ce qu'il est raisonnable, robuste et soutenable de construire dans un contexte donné.

Couche apportée par « PM, développeurs et IA : les rôles se brouillent, les responsabilités restent » (2026-08-01). La formulation la plus utile passe par ce qui devient une commodité et ce qui ne le devient pas. Produire rapidement une première version de code cesse d'être rare ; le logiciel, lui, ne devient pas une commodité, pas plus que l'ingénierie, l'architecture, la sécurité ou la maintenabilité. Confondre les deux conduit à traiter comme banal un métier dont seule la première étape s'est banalisée.

Pourquoi c'est important

Cela empêche de lire une accélération de production comme une avance technique. Un système qui grossit plus vite qu'il n'est arbitré accumule une dette d'architecture au rythme même de sa croissance.

Cela donne aussi le critère par lequel évaluer une proposition technique une fois la faisabilité acquise : l'intégration, la maintenabilité, la sécurité et la tenue en exploitation, qui sont les quatre endroits où le coût réel se révèle.

Nuances et limites

L'affirmation ne dit pas que la production ne compte plus : une équipe incapable de livrer n'arbitre rien. Elle dit que la capacité d'écrire cesse d'être le facteur limitant.

Et une partie de la cohérence peut être outillée — conventions imposées, tests, revues automatisées — ce qui déplace le jugement vers la définition de ces garde-fous sans le supprimer.

Questions ouvertes

• Comment mesurer la dégradation de cohérence d'un système pendant qu'il grossit, avant qu'elle ne se manifeste en incidents ?