Le piège du codage par l'IA, par Chris Loy
Le piège du codage par l'IA, par Chris Loy
Si vous observez un jour quelqu’un en train de « coder », vous remarquerez peut-être qu’il passe bien plus de temps à regarder dans le vide qu’à taper sur son clavier. Non, il n'est (probablement) pas en train de se la couler douce. Le développement logiciel est avant tout une pratique de résolution de problèmes et, à l’instar d’un mot croisé complexe, l’essentiel du travail se fait dans la tête.
Dans le cycle de vie du développement logiciel, le codage correspond aux lettres inscrites dans les mots croisés : il ne représente qu’un effort minime par rapport à toutes les réflexions et aux notes griffonnées. Le véritable travail se déroule généralement en parallèle du codage, tandis que le développeur se familiarise avec le domaine, affine les exigences, définit les abstractions pertinentes, prend en compte les effets secondaires, teste les fonctionnalités de manière incrémentale et, enfin, corrige les bugs qui ont survécu à ce processus rigoureux. Cela ressemble à peu près à ceci :
Mais avec le codage piloté par l’IA, les choses se déroulent très différemment.
« Le code d’abord, les questions ensuite »
Les agents de codage basés sur l’IA, tels que Claude Code, permettent d’écrire du code de manière étonnamment rapide, en isolé. Mais la plupart des logiciels s’inscrivent dans des systèmes complexes, et comme les grands modèles de langage (LLM) ne peuvent pas encore garder en mémoire l’intégralité du contexte d’une application en une seule fois, les besoins en matière de révision, de tests et d’intégration par l’humain resteront d’actualité. Et cela s’avère bien plus difficile lorsque le code a été écrit sans intervention humaine. Par conséquent, pour les logiciels complexes, une grande partie du temps sera consacrée à la compréhension a posteriori du code rédigé par l’IA.
C’est là que réside la différence fondamentale entre les arguments marketing vantant la vitesse révolutionnaire de l’écriture de code avec l’IA (souvent présentée comme « 10 fois plus rapide ») et les gains de productivité marginaux observés dans la pratique lors de la livraison de logiciels fonctionnels (généralement plus proches de 10 %).
Une conséquence encore plus décourageante de cette situation est que, en tant que développeurs, nous consacrons une part toujours plus importante de notre temps à simplement corriger les résultats de ces merveilleuses machines bavardes. Alors que les LLM s’occupent de toutes les tâches amusantes et faciles à la vitesse de l’éclair, il ne nous reste plus que les tâches ingrates : tester pour s’assurer que les fonctionnalités existantes ne sont pas altérées, supprimer le code en double, rédiger la documentation, gérer le déploiement et l’infrastructure, etc. Très peu de temps est en réalité consacré à ce que les développeurs aiment vraiment faire : coder.
Heureusement, de l’aide est à portée de main. Si les LLM bouleversent la manière dont le développement logiciel est mené, ce problème en soi n’est en réalité pas nouveau. En fait, il s’agit simplement d’un exemple frappant d’un problème séculaire, que j’appelle :
Le dilemme du responsable technique
Au fur et à mesure que les ingénieurs progressent dans leur carrière, ils finissent par endosser le rôle de responsable technique. Ils peuvent être amenés à diriger une équipe, ou occuper le poste d’ingénieur principal, pilotant la livraison technique sans gérer de personnel. Dans les deux cas, ils sont responsables de la livraison technique de l’équipe. Ils sont également généralement le développeur le plus expérimenté de l’équipe : soit en termes d’ancienneté professionnelle, soit dans le domaine de spécialité de l’équipe, soit les deux.
La livraison de logiciels est un travail d’équipe, mais dans lequel l’expérience peut avoir un effet très déséquilibrant sur la vitesse de contribution de chacun. Ainsi, lorsque la mission principale du responsable technique est de maximiser la livraison, il est souvent confronté à un conflit interne entre deux façons de livrer des logiciels :
- Une délégation équitable au sein de l’équipe, maximisant les opportunités d’apprentissage et d’appropriation pour les membres juniors, mais risquant de voir la livraison ralentie par la vitesse des membres les moins productifs.
- Ménager l’équipe, en ne déléguant aux juniors que les tâches faciles ou non critiques, et en conservant pour soi les tâches les plus difficiles, en tant que personne de l’équipe la plus à même de livrer rapidement.
Malheureusement, même si nous verrons que cette attitude de « ménagement » est extrêmement néfaste pour la santé à long terme de l’équipe, elle constitue aussi souvent un moyen très efficace d’accélérer la livraison. La plus grande capacité de travail du responsable technique est souvent exploitée de manière plus efficace en se chargeant de toutes les tâches les plus difficiles :
J’ai ainsi vu ce schéma se répéter à maintes reprises au cours de ma carrière. Et, bien sûr, cela a un coût. Le cloisonnement de l’expertise au sein du responsable technique fragilise l’équipe, rend le soutien plus difficile et exerce une pression toujours plus forte sur le responsable technique, qui devient alors un point de défaillance unique. La suite est prévisible : épuisement professionnel, départ, puis crise, alors que l’équipe peine à survivre sans la seule personne qui sait vraiment comment tout fonctionne.
Comme c’est souvent le cas, la solution réside dans une troisième voie qui évite ces deux extrêmes et concilie la livraison avec la croissance de l’équipe. On pourrait la formuler ainsi :
Lorsque j’étais directeur technique chez Datasine, nous avons inscrit cette attitude dans une devise simple pour l’équipe technique :Mettre en place des pratiques d’équipe qui permettent aux ingénieurs de livrer du code fonctionnel dans un cadre qui minimise les retouches, maximise la collaboration efficace et favorise l’épanouissement personnel et l’apprentissage.
Les bons responsables techniques poussent leurs ingénieurs à travailler à la limite de leurs capacités, en utilisant des processus et des pratiques qui minimisent les risques liés à la livraison tout en permettant à chaque membre de l'équipe de développer ses compétences, ses connaissances et son expertise dans le domaine. C'est, en effet, l'essence même d'un bon leadership technique.Apprendre. Livrer. S'amuser.
Il existe de nombreuses façons d’y parvenir, depuis les cadres rigoureusement codifiés tels que les règles de l’Extreme Programming jusqu’à des ensembles de principes plus souples que l’on pourrait globalement qualifier de « bonnes pratiques » :
- Révisions de code
- Livraisons incrémentielles
- Conception modulaire
- Développement piloté par les tests
- Programmation en binôme
- Documentation de qualité
- Intégration continue
Ainsi, pour les ingénieurs expérimentés d’aujourd’hui, une question urgente se pose : comment transposer ces pratiques dans un monde où le codage est piloté par l’IA ?
Les LLM sont des ingénieurs juniors ultra-rapides
En 2025, de nombreux ingénieurs se retrouvent pour la première fois dans une situation familière à tout responsable technique : superviser un ingénieur junior brillant mais imprévisible. Exploiter et maîtriser ce type de talent, de manière à favoriser une collaboration efficace au sein de l’équipe, est l’un des principaux défis du leadership en ingénierie. Mais les agents de codage basés sur l’IA nécessitent une gestion différente de celle des ingénieurs juniors, car la nature de leur productivité et de leur évolution est fondamentalement différente.
À mesure que les ingénieurs logiciels acquièrent de l’expérience, nous avons tendance à améliorer notre productivité de multiples façons simultanément : en écrivant un code plus robuste, en utilisant de meilleures abstractions, en consacrant moins de temps à l’écriture et à la correction des bugs, en comprenant des architectures plus complexes, en couvrant plus efficacement les cas limites, en repérant plus tôt les schémas récurrents, etc. L’ingénierie est une discipline riche et complexe offrant de nombreuses voies de spécialisation, mais par souci de simplicité, nous pouvons regrouper ces dimensions en deux grands thèmes :
- Qualité : capacité à produire un code plus complexe, plus performant et plus facile à maintenir
- Vitesse : capacité à développer un code fonctionnel et sans bogues dans un délai plus court
Au fil du temps, les bons ingénieurs s’améliorent sur ces deux axes.
Les premiers LLM écrivaient du code rapidement, mais le temps passé à corriger les bogues et à éliminer les « hallucinations » les rendait lents à produire un code exempt de bogues. Au fil du temps, des LLM plus intelligents et une meilleure utilisation de l’ingénierie contextuelle et des outils ont permis aux agents de codage IA modernes d’être bien plus performants dans l’écriture de code « en une seule fois ». La génération actuelle d’agents disponibles dans le commerce peut se montrer incroyablement rapide pour produire du code fonctionnel face à des problèmes qui poseraient des difficultés à certains ingénieurs de niveau intermédiaire, même si elle ne peut pas encore égaler l’expertise des ingénieurs seniors :
On peut donc considérer la génération actuelle d’agents de codage IA comme des ingénieurs juniors, avec toutefois deux différences fondamentales :
1. Les LLM produisent du code beaucoup, beaucoup plus rapidement que les ingénieurs juniors, car ils ne sont limités ni par le temps de réflexion ni par le temps d’écriture ;
2. les LLM n’ont pas de véritable capacité d’apprentissage et ne s’améliorent qu’à travers une ingénierie contextuelle plus efficace ou l’arrivée de nouveaux modèles de base.
Comme pour les jeunes ingénieurs, il existe globalement deux façons de les déployer, selon que votre objectif est à long terme ou à court terme :
- L’ingénierie pilotée par l’IA : appliquer les meilleures pratiques, privilégier la compréhension humaine du code, avancer lentement pour assurer la pérennité du développement.
- Le « vibe coding » : faire fi de toute prudence et implémenter à toute vitesse, sacrifiant la compréhension au profit de la rapidité de livraison, pour finir par se heurter à un mur de code chaotique et irrécupérable.
Comme on pouvait s’y attendre, les trajectoires à long terme liées au choix entre ces deux approches suivent à peu près le même schéma que celui du choix entre la délégation parallèle et la surprotection d’une équipe junior :
C’est pourquoi l’approche du « vibe coding » est idéale pour les tout petits projets ou les prototypes jetables : des applications suffisamment simples peuvent être livrées sans nécessiter la moindre réflexion humaine. En limitant la complexité de nos projets et en nous appuyant sur les capacités des outils, nous pouvons livrer un logiciel fonctionnel de bout en bout en un rien de temps.
Mais vous finirez par vous heurter à un mur de complexité que l’IA est incapable de surmonter seule.
La création de prototypes est aujourd’hui plus facile que jamais. Cependant, si nous voulons utiliser efficacement les grands modèles de langage (LLM) pour accélérer la livraison de logiciels réels, complexes, sécurisés et fonctionnels, et pour obtenir des gains d’efficacité qui ne soient pas seulement marginaux, nous devons rédiger un nouveau guide de pratiques d’ingénierie conçu pour optimiser la collaboration entre les équipes d’ingénieurs composées à la fois d’humains et de grands modèles de langage.
Comment éviter le piège du codage par IA
Les agents de codage basés sur l’IA sont d’une productivité époustouflante, mais ils ne disposent pas d’une connaissance approfondie de votre activité, de votre base de code ou de votre feuille de route. Si on ne les contrôle pas, ils produiront allègrement des milliers de lignes de code sans se soucier de la conception, de la cohérence ou de la maintenabilité. Le rôle de l’ingénieur consiste donc à jouer le rôle de responsable technique auprès de ces « as » : leur fournir la structure, les normes et les processus qui transforment la vitesse brute en livraison durable.
Nous avons besoin d’un nouveau guide pour livrer efficacement des logiciels fonctionnels, et nous pouvons nous tourner vers le passé pour apprendre comment y parvenir. En considérant les LLM comme des ingénieurs juniors ultra-rapides, nous pouvons nous appuyer sur les meilleures pratiques du cycle de vie du développement logiciel pour construire des systèmes évolutifs.
Tout comme les responsables techniques ne se contentent pas d’écrire du code mais définissent des pratiques pour l’équipe, les ingénieurs doivent désormais définir des pratiques pour les agents IA. Cela implique d’intégrer l’IA à chaque étape du cycle de vie :
Spécification : explorer, analyser et affiner les spécifications des fonctionnalités afin de couvrir les cas limites et de préciser l’objectif.
Documentation : générer et réviser la documentation en amont afin de fournir des garde-fous réutilisables et des preuves durables.
Conception modulaire : mettre en place des architectures modulaires pour contrôler la portée du contexte et optimiser la compréhension.
Développement piloté par les tests : générer des cas de test exhaustifs avant la mise en œuvre afin de guider celle-ci et de prévenir les régressions.
Normes de codage : appliquer les conventions internes et les meilleures pratiques lors de la génération de code, grâce à l’ingénierie contextuelle.
Surveillance et introspection : analyser les journaux et en extraire des informations plus rapidement que n’importe quel être humain ne pourrait le faire.
En comprenant que la livraison d’un logiciel va bien au-delà de la simple écriture de code, nous pouvons éviter le piège du codage par l’IA et, au contraire, amplifier considérablement notre capacité à livrer des logiciels fonctionnels et évolutifs.
Source : The AI coding trap
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :
Répondre avec citation
Partager