- L’usage des outils de codage IA revient à accroître la « dette de code »
- Entre deux entreprises ayant le même produit et le même chiffre d’affaires, celle qui fonctionne avec 100 000 lignes de code est beaucoup plus rapide à comprendre et à modifier que celle qui en a 1 million
- Autrement dit, plus il y a de code, plus la dette s’accumule ; la génération de code par IA augmente la productivité, mais peut aussi être interprétée comme une pratique qui augmente la dette
- La dette a une double dimension, positive et négative
- Positive : elle permet une croissance rapide à court terme
- Négative : à long terme, si elle est mal gérée, elle peut entraîner un risque d’effondrement du projet
- En d’autres termes, la dette peut être bonne ou mauvaise, porter ou non des intérêts, permettre une croissance rapide, mais aussi faire s’effondrer un projet
- L’important n’est pas d’utiliser ou non l’outil, mais de l’administrer de manière responsable
- Il faut garantir un accès facile aux outils tout en tenant compte de la qualité du code généré et de son coût à long terme
5 commentaires
Même si le code est très long, ce n’est pas une dette si l’on peut facilement expliquer « ce qu’il fait ».
On dit que l’usage indiscriminé de l’IA crée de la dette, parce qu’il rend cela difficile.
https://github.com/kelseyhightower/nocode
Ce n’est pas clairement indiqué dans le texte, mais cela pourrait-il vouloir dire que, lorsqu’on écrit du code avec l’IA, il devient une dette parce qu’il est moins familier pour les humains que du code écrit directement par eux-mêmes ?
Avis Hacker News
À première vue, mesurer tout uniquement au nombre de lignes de code (LOC) paraît réducteur. Si l’entreprise A a 1 million de lignes de code nettement plus propres, mieux organisées et mieux documentées, on peut dire qu’elle est dans une meilleure situation que l’entreprise B avec 100 000 lignes mal écrites. Le vrai problème, ce n’est pas le code, c’est la complexité, et le nombre de lignes n’est qu’un indicateur approximatif de cette complexité. Le code est un actif. C’est la production et l’actif d’une entreprise logicielle. Bien sûr, plus on a d’actifs, plus la complexité augmente, mais c’est une évidence. C’est comme le réseau autoroutier américain : on ne peut pas le juger entièrement de manière négative au seul motif qu’il est complexe et difficile à entretenir. Même en laissant de côté la question de l’IA, l’argument de l’auteur revient au fond à une conclusion basique que tout le monde connaît : « moins il y a de complexité, mieux c’est ». Donc le point le plus important de cet article peut se résumer à : « vérifiez bien que les outils de codage IA n’ajoutent pas de complexité inutile au code final »
À l’inverse, je ne pense pas que la complexité soit ici le vrai point central. Si l’on suppose qu’il existe déjà un logiciel métier viable et qu’on raisonne à rebours, tous les coûts (achat, salaires, etc.) doivent en principe être réduits autant que possible. On dit que la complexité est pire que la simplicité, mais c’est surtout parce que, lorsqu’elle est réelle, elle coûte plus cher. Au final, ce qui compte vraiment, que ce soit à court ou à long terme, en capital ou en exploitation, c’est le coût lui-même. La vraie question est donc de savoir si le code généré par les LLM réduit les coûts ou les augmente. La taille du code, la complexité, ainsi que d’innombrables autres variables que ni l’OP ni toi n’avez mentionnées, ont toutes leur importance
Pour ma part, j’évalue la complexité de mes fonctions avec la complexité cyclomatique. Je mesure cela avec SwiftLint et je fais remonter un signal quand un seuil est dépassé. Il m’arrive parfois de découper un peu grossièrement, mais j’essaie en général de trouver un moyen de simplifier réellement. Mes fichiers sont assez longs, mais j’essaie de maintenir un ratio commentaires/code d’environ 50:50. Si on donne à un LLM un prompt pour réduire la complexité et augmenter les commentaires, il devrait s’en sortir correctement
Le code est à la fois un actif et un passif, comme un produit chimique volatil. Bien utilisé, rapidement et correctement, il peut rapporter de l’argent ; mais s’il est laissé à l’abandon ou se répand partout, il devient un passif. Le code source ne se détériore pas de lui-même, mais son « adéquation à l’usage » évolue en permanence à mesure que les objectifs et les processus de l’organisation changent
Je trouve intéressant le thème « Pourquoi n’arrivons-nous pas à créer des logiciels simples ? ». J’ai trouvé marquante cette idée sur la complexité : « la complexité apparaît lorsque les systèmes interagissent. Les systèmes complexes peuvent dériver vers l’irrationnel et produire aussi une créativité inattendue »
Je pense que c’est le logiciel lui-même qui est l’actif, pas le code. De la même manière que, pour une autoroute, l’actif n’est pas le béton mais l’infrastructure achevée. La qualité du béton influe sur la dépréciation de l’actif et sur les coûts de maintenance, ce qui affecte ensuite la valeur de l’actif. Il faut aussi impérativement intégrer ici une perspective de gestion des risques
Au début de ma carrière, je pensais qu’écrire beaucoup de code était important. Vingt ans plus tard, je suis plus fier d’en supprimer davantage. Du point de vue d’un ingénieur sécurité, le code n’est pas seulement un passif, c’est aussi un risque. Les dépendances à des bibliothèques externes constituent notamment un risque majeur. Récemment, avec un collègue, nous avons écrit un petit init system Linux en moins de 600 lignes, uniquement avec la bibliothèque standard de Rust, et il est utilisé en production dans plusieurs organisations. Sans dépendances, avec un démarrage en moins d’une seconde. Cela m’a fait réaliser qu’on peut très bien construire un serveur Linux de type appliance sans systemd ni des millions de lignes de code C. En le faisant soi-même, on a beaucoup moins de code et on peut comprendre complètement l’ensemble du système
Je pense que le pire scénario du code produit par l’IA se voit plus clairement dans des projets personnels que du point de vue d’une entreprise. Je peux écrire moi-même 10 000 lignes d’excellent code que je connais bien, ou bien produire à la va-vite, plusieurs fois plus vite, 20 000 lignes de code problématique. Personnellement, j’essaie de trouver un équilibre entre les deux. Si l’on cherche à continuer à faire évoluer le développement, je pense que le temps « perdu » dans le premier cas finit quand même par coûter cher
Je pense qu’il existe toujours un juste milieu. Dans mon cas, je n’ai confié à l’IA la génération réelle de code que pour des scripts autonomes comme du Bash ou du Python. Comme ces scripts n’interagissent qu’avec la ligne de commande, leurs frontières sont nettes et ils sont faciles à gérer. Une fois écrits, je ne les ai jamais revus. En revanche, générer avec l’IA du code métier central n’a pas vraiment de sens, donc je ne le fais pas. Il faut de toute façon faire une code review, et ce dont j’ai réellement besoin, c’est de pouvoir vérifier la maintenabilité du code. Si ce n’est pas du code qu’on peut jeter tel quel ou simplement relire rapidement, il n’y a pas de raison d’utiliser un outil de génération de code. Si l’IA pouvait jouer le rôle de product owner, comprendre les pertes métier réelles et les améliorer, ce serait différent ; mais à ce moment-là, il faudrait plutôt s’inquiéter du risque de disparition des utilisateurs eux-mêmes
Moi aussi, chaque fois que j’ai trop fait confiance à l’IA pour produire beaucoup de code, j’ai fini par payer très cher le prix de la productivité perdue. Si une application est entièrement faite en vibe coding, la compétence la plus importante sera probablement de savoir se demander : « Avait-on vraiment besoin de cette fonctionnalité ? » Déboguer du spaghetti code sans comprendre du tout, ligne par ligne, à quoi sert quoi, ça doit être une vraie souffrance
Tu dis avoir perdu du temps dans le premier cas, mais le second cas (un code pire, produit plus vite) reste lui aussi une perte de temps au final. Le fond du sujet, à mon avis, c’est de trouver le bon point d’équilibre
Un code bref, avec des noms de variables mal choisis ou trop « malin », est souvent bien pire qu’un code plus verbeux, bien documenté et avec des noms riches en sens. Le passif est au fond proportionnel au temps nécessaire pour comprendre, modifier et étendre le code. Le nombre de lignes n’est pas non plus un indicateur capable de mesurer parfaitement cette dette. Toutes choses égales par ailleurs, réduire la quantité de code peut sacrifier la lisibilité et donc augmenter la dette. C’est pourquoi l’idée selon laquelle « l’absence de théorie est la dette » me semble plus juste. À l’inverse, le code court peut lui-même constituer une dette du point de vue des LLM. L’usage des LLM tend à minimiser la construction de théorie, et cela me paraît particulièrement vrai dans la situation actuelle où l’IA ne peut ni construire seule une théorie globale du projet ni la transmettre correctement à l’ingénieur
J’aime voir la programmation comme un processus de construction de théorie. Surtout pour les logiciels métier, cette théorie doit être centrée sur l’activité. Par exemple, il faut absolument intégrer des questions comme : « Peut-on recruter facilement des développeurs pour cette base de code ? », « À quel point le modèle économique est-il stable ? », « Quelle est l’importance métier de chaque fonctionnalité ? »
Une idée me vient soudain. Je me demande s’il serait possible de demander à une IA d’expliquer les noms de variables ou les fonctions dans le code. Jusqu’à présent, je n’ai utilisé l’IA que pour générer du code
Parmi les entreprises où je suis resté longtemps, certaines n’avaient pas de véritable actif logiciel en interne mais dépendaient, pour leur activité principale, de services d’entreprise tiers. La question que je me pose ici est : dans ce cas, comment mesurer la quantité réelle de code concernée ? Par exemple, si l’on dépend d’un fournisseur SaaS legacy, faut-il considérer aussi son nombre de lignes de code comme faisant partie de notre dette ?
À mon avis, le principal risque lorsqu’on dépend d’un service tiers, c’est qu’il fasse faillite ou que ses conditions changent à la suite d’une fusion-acquisition. Souvent, on se retrouve à devoir utiliser des services de startups très bien financées mais qui n’ont pas vraiment trouvé leur autonomie économique
Je suis totalement d’accord là-dessus. Dans une ancienne entreprise, on utilisait un SaaS d’email marketing ; même si le code d’intégration que nous avions écrit ne faisait que 500 lignes, nous avons énormément souffert à cause des problèmes du service. Au final, nous avons réimplémenté en interne uniquement les fonctionnalités dont nous avions besoin, ce qui nous a fait économiser énormément d’argent et d’efforts, et le nombre de lignes de code a augmenté d’environ 3 000
Je ne comprends pas bien.
Le code est clairement un actif, mais comme le matériel, il se déprécie pour diverses raisons (défauts, évolution de l’industrie logicielle/matérielle, etc.). Plus la quantité de code logiciel augmente, plus le coût de la dépréciation annuelle augmente. Si la maintenance n’est pas suffisante (par exemple, trop de code par rapport au nombre de développeurs), le coût de correction des problèmes finit par croître de manière exponentielle. C’est comme si l’on ajoutait des « intérêts » à la notion de dépréciation. Je comprends donc l’usage du mot « dette », mais ce n’est pas un concept parfaitement équivalent
Bien sûr, le dépôt le plus parfait, c’est évidemment celui-ci
Autrefois, j’aimais dire qu’en un mois j’avais supprimé 20 000 lignes de code nettes. Il y a quelques années, j’ai essayé de refaire la même chose avec une équipe remote de 20 développeurs, mais je n’arrivais plus à suivre le flot de pull requests. Maintenant, je fais du pair programming avec Claude Code et GPT, et cela ressemble clairement davantage au second cas. Je pense qu’il y a là des opportunités de refactoring intelligentes. Mais il faudrait probablement plus de contexte. J’ai essayé ce genre de choses sur du code legacy avec Cursor et Claude opus 4.1, mais même un million de tokens ne suffisait pas. Je me demande si une approche consistant à traduire entre un LLM personnel et un LLM partagé pourrait marcher ; je serais curieux de savoir si quelqu’un a déjà essayé
Personne ne semble vraiment poser cette question pourtant très importante : « Quelle est la quantité minimale absolue de code nécessaire pour implémenter complètement la fonctionnalité X ? » Bien sûr, il est impossible d’y répondre exactement, mais le simple fait de raisonner ainsi favorise un état d’esprit plus efficace. En revanche, les gens s’intéressent beaucoup à des choses peu importantes en pratique, comme la vérification formelle. Sans réflexion sur la quantité minimale de code réalisable, la vérification formelle peut devenir au contraire du gaspillage et perdre son sens. Et, en général, on part du principe que le code écrit par les ingénieurs est bon, alors qu’en réalité il ajoute souvent des abstractions et de la complexité inutiles, ce qui crée encore plus de travail. Une part considérable du software engineering produit en fait une valeur négative. Bien sûr, il y a un mélange de positif et de négatif, ce qui rend le jugement d’autant plus difficile