Écrire du code à la main à l’heure de l’IA : un geste devenu inutile ou plus précieux que jamais ?

À l’heure où des agents d’intelligence artificielle peuvent générer, tester et déployer du code sur simple instruction, une question presque provocatrice se pose dans le monde du développement logiciel : à quoi bon encore écrire du code soi-même ? C’est le sujet d’une tribune récemment publiée par un développeur, qui défend une thèse à contre-courant de l’enthousiasme ambiant pour l’automatisation totale.

Le développeur devenu architecte d’une chaîne de production

Le constat de départ ne fait guère débat : le rôle de l’ingénieur logiciel a changé de nature. Il ne s’agit plus seulement de produire du code, mais de construire ce que l’auteur appelle une véritable « usine logicielle » — une infrastructure qui permet à n’importe qui de demander une modification et de la voir déployée presque instantanément. Cette infrastructure repose sur deux piliers : des outils proactifs qui guident les agents IA (bases de connaissances, fichiers de configuration, compétences prédéfinies) et des garde-fous réactifs qui protègent le code a posteriori, comme les tests automatisés, les vérificateurs de type ou d’autres systèmes d’évaluation.

Dans ce contexte, même un modèle d’IA modeste, correctement encadré par ces contraintes, parvient à produire des modifications globalement satisfaisantes. Il devient alors tentant de se demander si l’examen manuel du code, voire son écriture directe, n’est pas devenu superflu — une pratique presque risible aux yeux de certains.

Écrire du code pour mieux le comprendre, pas pour mieux performer

L’auteur de la tribune rejette pourtant cette conclusion. Selon lui, l’intérêt d’écrire soi-même du code ne tient pas à une quelconque supériorité humaine sur les agents IA en matière de performance pure. Il s’agit plutôt d’une question d’attention et de compréhension profonde du système. Rester un simple observateur passif des modifications produites par des agents, en se contentant de lire des diffs et des correctifs, ne suffit pas à véritablement saisir l’architecture d’un logiciel. Il faut, selon ses mots, en faire l’expérience directe, ressentir sa fragilité de l’intérieur.

Cette fragilité n’est pas une question esthétique. Si un développeur humain peine à faire évoluer un code sans provoquer de régressions, un agent IA rencontrera les mêmes difficultés. Nettoyer le code, documenter des principes architecturaux cohérents, et repérer les failles dans une stratégie de tests permet, selon l’auteur, d’éliminer des classes entières de bugs — un travail qu’il reconnaît possible sans écrire de code soi-même, mais qu’il juge plus efficace en pratique quand on s’implique directement.

Le risque du « centaure inversé »

L’auteur emploie une image frappante pour décrire le piège qui guette les développeurs devenus simples relecteurs de code généré par IA : celle du « centaure inversé », où l’humain peine à maintenir son attention et perd le sentiment d’appropriation du résultat. Dans cette configuration, du code de mauvaise qualité — un « slop » selon le terme employé — peut passer inaperçu, devient plus difficile à ajuster finement, et fragilise à terme le travail des agents eux-mêmes, précisément parce que personne ne prête suffisamment attention aux détails.

À l’inverse, lorsque l’humain participe activement à l’élaboration d’une approche avant de laisser l’agent en reproduire le schéma, il conserve une forme de propriété et d’implication sur le résultat final.

Le langage naturel, un outil imprécis pour penser l’algorithmique

Un autre argument avancé dans la tribune touche aux limites intrinsèques du langage naturel. L’anglais — ou toute langue humaine — reste un moyen imprécis d’exprimer un raisonnement computationnel. Pour un travail véritablement algorithmique, l’auteur préfère esquisser sa pensée directement en étapes exécutables, avec un niveau de précision calibré selon les besoins : parfois un langage bas niveau offrant un vaste espace de conception, parfois un langage plus haut niveau et plus contraint.

Il met en garde contre une dérive consistant à traiter les agents de codage comme de simples compilateurs, ce qui inciterait à tolérer un code mal écrit. Or les agents ne sont pas des compilateurs : ce sont, selon la comparaison choisie, davantage comme des stagiaires fraîchement arrivés, qui lisent un code parfois imparfait, reçoivent une description approximative du changement demandé, et doivent produire une modification à partir de cette base incertaine.

Un exemple concret : la dette technique amplifiée par les agents

L’auteur illustre son propos par une anecdote personnelle : une décision hâtive et peu réfléchie d’utiliser le stockage local du navigateur pour gérer un état, alors que le reste de l’application reposait sur une base de données côté serveur. En reprenant ce code, il a constaté que la quantité de code nécessaire pour préserver cette décision initialement maladroite avait probablement triplé au fil des interventions successives des agents — ces derniers ayant tendance à privilégier la modification la plus prudente possible plutôt qu’une remise en question architecturale. Ce n’est qu’en explorant et en supprimant activement du code que l’auteur affirme être parvenu à une architecture plus saine, un résultat qu’il juge difficilement atteignable en se contentant de formuler des instructions en langage naturel.

L’auteur reconnaît volontiers les bénéfices considérables apportés par les agents IA, notamment la généralisation des pratiques d’intégration continue dès les premières étapes d’un projet, même personnel. Mais il insiste sur le fait que toute chaîne de production, aussi automatisée soit-elle, comporte des points faibles qu’il faut parfois démonter entièrement pour comprendre en profondeur — un travail qui, selon lui, ne peut se faire qu’en gardant une vision d’ensemble du système tout en se plongeant dans ses détails les plus fins. Tracer des frontières arbitraires sur ce qu’un développeur devrait ou non toucher directement dans le code irait, selon cette tribune, à l’encontre de cet objectif.

Photo d’illustration : Pixabay (cc)

[cc] Article rédigé par la rédaction de breizh-info.com et relu et corrigé (orthographe, syntaxe) par une intelligence artificielle.

Breizh-info.com, 2026, dépêches libres de copie et de diffusion sous réserve de mention obligatoire et de lien do follow vers la source d’origine.