La dette de compréhension du code généré

Les volets précédents ont décrit un déplacement : l'IA accélère la production de code, et le métier glisse vers spécifier, vérifier, décider. Mais cette vitesse dissimule un piège qu'aucune démo ne montre — on peut livrer du code qui fonctionne sans le comprendre. Le décalage entre ce que fait le code et ce que vous en saisissez est une dette. Invisible le jour de la livraison, elle arrive à échéance au premier bug, au premier incident, au premier audit. Ce volet lui donne un nom : la dette de compréhension. Et une règle : ne livrez que du code que vous pouvez expliquer et défendre.

Produire du code n'est pas le comprendre

Commençons par dissiper une confusion tenace. Quand un outil produit en quelques secondes un module qui compile, passe les tests et s'exécute, il naît un sentiment de maîtrise — et ce sentiment n'est pas la maîtrise. Produire est devenu instantané ; comprendre reste un travail. Or les deux se sont, pour beaucoup, mis à se confondre : le code marche, donc on croit le tenir.

Une étude de chercheurs de Stanford, Do Users Write More Insecure Code with AI Assistants? (Perry, Srivastava, Kumar et Boneh, présentée à l'ACM CCS 2023), mesure précisément cet écart. Les participants disposant d'un assistant de code ont produit un code sensiblement moins sûr — et, dans le même mouvement, ils étaient « plus enclins à croire qu'ils avaient écrit du code sûr que ceux qui n'avaient pas accès à l'assistant ». La faille et la confiance progressent ensemble. C'est la signature de la dette de compréhension : elle s'installe d'autant plus facilement qu'on ne la voit pas se former.

Une dette qui se paie au premier bug

Le mot « dette » n'est pas ici une figure de style. Il renvoie à la métaphore d'origine, celle que Ward Cunningham a forgée en 1992 en décrivant son système de gestion de portefeuille. Revenant sur cette image des années plus tard, il en a précisé le sens exact, et ce sens est frappant : « Je ne suis jamais favorable au fait d'écrire du code médiocre, mais je suis favorable au fait d'écrire du code qui reflète votre compréhension actuelle d'un problème, même si cette compréhension est partielle. » Autrement dit, la dette n'est pas le code « sale » : c'est le décalage entre votre compréhension et ce que le programme incarne réellement (Fig. 1).

Livrer du code généré qu'on ne comprend pas, c'est creuser ce décalage d'un coup — donc emprunter. Au moment de la livraison, l'emprunt paraît gratuit : tout fonctionne, on est allé vite. Mais la dette porte des intérêts, et ils tombent au pire moment. Le premier bug en production exige de déboguer un code dont personne ne tient le modèle mental. La première évolution demandée oblige à modifier une logique qu'on n'a jamais vraiment lue. Le premier audit réclame de justifier des choix qu'on n'a pas faits. Ce qui avait été économisé à l'écriture se repaie, majoré, à la maintenance.

L'IA ne comble pas le trou de compréhension

On pourrait croire l'affaire réglée : puisque l'IA a écrit le code, elle saura l'expliquer et le maintenir. C'est là que le raisonnement se fissure. Les modèles de langage comprennent mal le code : ils s'appuient sur des indices de surface plutôt que sur le sens. L'étude Assessing the Impact of Code Changes on the Fault Localizability of Large Language Models (arXiv 2504.04372) le montre nettement : en modifiant la syntaxe d'un programme sans changer sa logique, les auteurs font échouer les modèles sur des fautes qu'ils localisaient auparavant dans 78 % des cas. Leur raisonnement, concluent-ils, est « souvent lié à des caractéristiques sans rapport avec la sémantique ». Le modèle lit des motifs, pas une intention (Fig. 2).

Le contexte long ne sauve pas la mise. On imagine parfois qu'il suffit de donner toute la base de code au modèle pour qu'il la « comprenne ». Or les travaux Lost in the Middle: How Language Models Use Long Contexts (Liu et coll., publiés dans la revue TACL) établissent que la performance « se dégrade significativement lorsque les modèles doivent exploiter une information située au milieu de contextes longs, même pour les modèles explicitement conçus pour les longs contextes ». Un modèle ne relit pas une base de code comme un mainteneur qui en tient la carte : il en néglige des pans entiers. Les recommandations de sécurité OWASP nomment le risque symétrique côté humain — la sur-confiance, cette tendance à « accorder une confiance excessive au contenu généré, sans en vérifier l'exactitude ». Le trou de compréhension ne se comble donc pas tout seul : ni la machine ni la confiance qu'on lui prête ne le ferment.

Ce que cela change pour l'équipe

La règle qui solde la dette est simple à énoncer : ne livrez que du code que vous pouvez expliquer et défendre — en revue, en incident, en audit. Elle ne ralentit pas l'usage de l'IA ; elle en fixe le prix juste. Générer vite reste un gain réel, à condition de combler soi-même le fossé de compréhension avant que le code n'entre dans le produit. Sinon, la vitesse d'aujourd'hui devient l'intérêt de demain.

Ce cadrage prolonge le fil de la série, depuis « écrivons-nous encore du code ? » : l'IA déplace le travail vers le haut — spécifier, vérifier, décider — et cette montée en ingénierie de l'IA a une contrepartie. Plus on délègue la production, plus la compréhension devient la vraie valeur ajoutée, et le vrai garde-fou. Comprendre passe avant produire, non par principe, mais parce que c'est l'humain qui reste garant du sens — et qui, comme le rappelait le volet précédent, répond de ce qu'il livre.