Soyons clairs sur le constat, avant d'en tirer quoi que ce soit.

Le coût marginal d'écriture d'une ligne de code tend vers zéro. Ce n'est pas une opinion, c'est une observation que fait aujourd'hui n'importe qui travaille avec un assistant sérieux. Du boilerplate qui prenait une demi-journée en prend dix minutes. Un refactoring mécanique sur quarante fichiers devient une tâche de fin de journée. L'exploration d'une API qu'on ne connaît pas ne passe plus par deux heures de documentation.

Je ne vais pas faire semblant d'être nuancé là-dessus. C'est réel, c'est massif, et je ne reviendrai pas en arrière.

Mais un coût qui s'effondre ne disparaît pas du système. Il se déplace.

Ce qui n'a pas changé

Écrire du code n'a jamais été la partie chère du métier.

La partie chère, c'est de comprendre. Comprendre ce que le système fait déjà avant d'y toucher. Comprendre pourquoi telle décision a été prise il y a trois ans. Comprendre les conséquences d'une modification sur des parties qu'on n'a pas ouvertes. Comprendre suffisamment pour être capable de dire non.

Cette part-là n'a pas bougé d'un iota. Le temps qu'il me faut pour me construire un modèle mental d'un module est exactement le même qu'il y a dix ans. Aucun outil ne me l'a réduit.

Et surtout : ce coût de compréhension n'est pas proportionnel au nombre de lignes. Il est proportionnel au nombre de choses différentes qu'il faut tenir en tête simultanément pour raisonner correctement. C'est-à-dire au nombre de frontières mal posées, de dépendances implicites, de concepts dupliqués, de règles éparpillées.

Dix mille lignes bien découpées se comprennent module par module. Deux mille lignes entremêlées ne se comprennent pas du tout.

Le découplage dont personne ne parle

Voici le point que je trouve le plus important, et le moins discuté.

Avant, écrire du code produisait de la compréhension comme effet de bord. On ne pouvait pas implémenter une fonctionnalité sans avoir lu le code autour, sans avoir compris le modèle existant, sans s'être heurté à ses contradictions. La compréhension n'était pas une étape séparée : elle était le prix d'entrée pour écrire quoi que ce soit.

Ce couplage vient de casser.

Aujourd'hui, du code peut apparaître dans une base sans que personne n'ait construit le modèle mental qui va avec. Ni la machine, qui n'en a pas au sens où nous l'entendons. Ni le développeur, qui a validé un résultat plutôt que construit une solution. Ni le relecteur, qui a vérifié une PR isolée sans reconstituer l'ensemble.

Le code est là, il fonctionne, et la compréhension qui l'accompagnait autrefois n'a pas été produite.

C'est exactement ce qui s'était passé dans ma pull request. Personne n'avait mal travaillé. Simplement, le mécanisme qui aurait fait dire à quelqu'un « attends, on a déjà ça ailleurs » ne s'était pas déclenché, parce qu'il reposait sur un travail de lecture que plus personne n'avait eu besoin de faire.

L'arithmétique désagréable

Mettons les deux constats bout à bout.

D'un côté, le volume de code produit par unité de temps augmente fortement. De l'autre, la capacité d'une équipe à comprendre du code reste constante — c'est une contrainte humaine, pas technologique.

Le ratio s'inverse. On produit désormais plus de code à comprendre qu'on n'a de budget de compréhension pour l'absorber.

Et un système qu'on ne comprend plus n'est pas un système lent à faire évoluer. C'est un système qu'on cesse de faire évoluer. On le contourne, on ajoute à côté, on empile une couche. Chacun a déjà vu ça, et personne n'a eu besoin de l'IA pour y arriver — mais on vient d'installer un accélérateur sur ce mécanisme précis.

Où l'architecture intervient

C'est ici que je veux en venir, et c'est la raison d'être de ce blog.

L'architecture, dépouillée de tout son vocabulaire, ne fait qu'une chose : elle décide où sont les frontières. Ce qui est séparé de quoi. Ce qui peut connaître quoi. Ce qui doit passer par un contrat explicite. Le reste — les patterns, les couches, les diagrammes — n'est que l'outillage de cette décision.

Or une frontière bien posée fait exactement deux choses qui nous intéressent aujourd'hui :

Elle borne le coût de compréhension. On peut raisonner sur un module sans tenir le reste en tête. C'est ce qui rend un système lisible par morceaux plutôt que d'un bloc — la seule façon de rester sous le plafond humain.

Dit autrement, un système fortement architecturé induit plusieurs niveau de compréhension, du stratégique au tactique, chacun étant limité dans sa portée.

Elle borne le rayon d'explosion d'une erreur. Une incohérence introduite à l'intérieur d'un contexte isolé y reste. La même incohérence dans un système sans frontières se propage.

Ces deux propriétés avaient déjà de la valeur avant. Elles en ont mécaniquement plus maintenant, parce que le volume qu'elles doivent contenir a augmenté.

Autrement dit : l'IA ne dévalue pas l'architecture. Elle en fait le dernier goulot d'étranglement qui compte vraiment. C'est le seul endroit du processus où l'on décide encore de quelque chose que la machine ne décidera pas à notre place.

Ce que ça change en pratique

Quatre conséquences que j'applique, et sur lesquelles je reviendrai en détail dans les articles à venir.

Les frontières se posent avant de générer, pas après. Générer d'abord et découper ensuite ne marche pas : on se retrouve à réorganiser du code que personne n'a lu. L'ordre compte plus qu'avant, pas moins. Ce que certains appelle le "harnais" de développement est obligatoire. Une architecture consciemment adoptée devient obligatoire.

La revue devient une fonction distincte, pas une politesse. Relire du code qu'on n'a pas écrit était déjà l'exercice le plus difficile du métier. C'est devenu l'activité centrale. Elle mérite du temps dédié, des critères explicites, et — j'y reviendrai — d'être séparée structurellement de la production.

Les décisions se versionnent. Si la compréhension n'est plus produite comme effet de bord de l'écriture, il faut la produire délibérément. Écrire pourquoi on a tranché, et le garder à côté du code. Ce n'est plus de la documentation de confort, c'est la cadre d'execution d'une production de code automatique.

Le langage du domaine redevient un outil de travail. Pendant vingt ans, l'ubiquitous language du DDD a été présenté comme un moyen de se parler entre humains. C'est maintenant, en plus, le contexte qu'on donne à la machine. Un modèle de domaine explicite n'est plus seulement élégant : il est opérationnel.