Écrire du code n’est pas une vertu
La keynote d’ouverture de DHH à Rails World 2026 m’a poussé à mettre des mots sur quelque chose que j’observais déjà.
Le créateur de Rails y décrit la politique « pencils down » de 37signals : l’implémentation est déléguée aux agents, et lorsqu’un humain doit intervenir, l’équipe améliore le dispositif plutôt que de reprendre le clavier. Il compare aussi l’IA à l’appareil photo, qui a fait chuter le coût de production des images et ouvert de nouveaux usages.
En 2026, l’IA a dépassé le stade du nouvel outil de développement. Elle commence à modifier en profondeur la manière dont le logiciel est produit. Et les développeurs ne réagissent pas tous de la même façon.
Je vois quatre profils. Vous en reconnaîtrez au moins un dans votre équipe.
- Les optimistes. Ils expérimentent, délèguent de plus en plus et cherchent jusqu’où ils peuvent pousser ces nouveaux outils.
- Les craintifs. Ils voient les capacités progresser et y voient surtout une menace pour leur métier.
- Les retardataires. Ils ne sont pas nécessairement opposés à l’IA. Ils continuent globalement à travailler comme avant.
- Les puristes. Ils revendiquent le fait d’écrire eux-mêmes leur code et considèrent cette pratique comme intrinsèquement supérieure.
Ce sont les puristes qui m’intéressent ici. Leur réaction révèle quelque chose qui dépasse largement le débat sur la qualité des LLM.
Quand écrire du code devient une valeur morale
Au fil des années, nous avons associé notre identité professionnelle à l’acte d’écrire du code. D’où cette phrase :
« J’écris encore mon code moi-même. »
Pourquoi le préciser ?
Si écrire du code n’est qu’un moyen de produire un logiciel, peu importe qui, ou quoi, produit les caractères qui finissent dans le repository.
Mais pour une partie de la profession, l’écriture elle-même semble posséder une valeur morale.
Il faut distinguer deux phrases qui se ressemblent beaucoup :
« Je préfère écrire ce code moi-même parce que, dans cette situation, c’est plus efficace. »
« Je préfère écrire mon code moi-même parce que c’est ainsi qu’un vrai développeur devrait travailler. »
La première est un choix technique. Il garde sa place dans certains secteurs, mais à mon avis les situations où il se justifie deviennent de plus en plus rares. La seconde est un jugement de valeur.
Nous avons toujours cherché à ne plus écrire le code
C’est tout le paradoxe. L’histoire du développement logiciel est une succession d’abstractions destinées à nous éloigner du travail de bas niveau.
Assembleur. Langages de haut niveau. Bibliothèques. Frameworks. ORM. IDE. Autocomplétion. Générateurs. IA.
À chaque étape, une machine ou une abstraction prend en charge quelque chose que le développeur faisait auparavant.
Personne ne demande à un développeur Rails pourquoi il n’a pas écrit son propre serveur HTTP ou son ORM.
Nous sommes une profession qui automatise tout ce qu’elle peut depuis des décennies, mais qui commence à trouver l’automatisation moralement suspecte lorsqu’elle automatise l’écriture de notre propre code.
Le travail ne fait pas la valeur
Nous associons spontanément effort et valeur. C’est une intuition très ancrée. Elle ne résiste pas à un exemple simple.
L’exemple du trou
Quelqu’un creuse un trou en une heure.
Quelqu’un d’autre le creuse, le rebouche, le recreuse et recommence pendant huit heures, avant de laisser exactement le même trou.
Le second a fourni beaucoup plus de travail. Il n’a pas créé davantage de valeur.
Transposé au développement
Développeur A. Deux jours de travail. 2 000 lignes écrites personnellement.
Développeur B. Deux heures. Des agents IA, une spécification, de la supervision, de la validation.
Si le résultat est équivalent, le nombre d’heures passées et le nombre de touches frappées ne rendent pas le premier logiciel plus précieux.
Et si B produit un meilleur résultat, la comparaison devient encore plus intéressante.
Le résultat est ce qui compte
Par résultat, j’entends bien plus que « ça compile ». Pour un logiciel, le résultat comprend notamment :
- la fonctionnalité ;
- la fiabilité ;
- les tests ;
- la maintenabilité ;
- la sécurité ;
- les performances ;
- l’adéquation au besoin.
Le métier ne disparaît donc pas. Le lieu où s’exerce la compétence se déplace.
Je me demande de moins en moins comment je vais écrire telle fonction. Je me demande surtout quel problème je dois résoudre. Quelles contraintes je dois donner. Comment savoir si le résultat est correct. Comment le système doit être conçu. Comment prouver qu’il fonctionne.
Dans mon propre travail, mon rôle s’est progressivement déplacé de la production du code vers la conception du système qui produit et vérifie le code. J’ai détaillé ce fonctionnement dans Je ne lis presque plus de code.
« AI slop »
Tout ce qui est généré par IA devient parfois suspect par défaut.
Oui, l’IA peut produire du code catastrophique. Mais c’est très souvent le reflet de la personne qui lui a donné de mauvaises spécifications. Et les humains aussi produisent du code catastrophique.
Le problème commence lorsqu’on utilise l’origine du code comme proxy de sa qualité.
Une expérience de pensée
Deux pull requests arrivent devant vous. Même niveau de tests. Même lisibilité. Même maintenabilité. Même qualité.
Vous ne savez pas comment elles ont été produites.
L’une a été écrite entièrement à la main. L’autre presque entièrement par un agent.
Laquelle est du « slop » ?
Impossible de répondre sans connaître leur origine.
Si apprendre que la seconde vient d’une IA suffit soudainement à la rendre mauvaise, vous n’évaluez plus le code. Vous évaluez son auteur.
Souvent, l’IA écrit mieux que nous
Le débat est souvent formulé ainsi :
« L’IA produit-elle du bon code ? »
La véritable comparaison devrait être :
« Produit-elle un meilleur résultat que celui que j’aurais produit dans les mêmes conditions ? »
Cette question devient vite inconfortable. Parce que la réponse est souvent oui.
Un développeur peut regarder du code généré par une IA et chercher immédiatement ce qui ne va pas, alors que ce code est mieux structuré, mieux testé, ou simplement meilleur que celui qu’il aurait écrit.
L’idée essentielle tient en une phrase :
Le fait qu’un code soit généré ne nous apprend rien, à lui seul, sur sa qualité.
Ce phénomène dépasse largement les développeurs
L’article : « Tu ne l’as pas vraiment écrit. »
Le design : « Tu ne l’as pas vraiment créé. »
L’image : « Tu ne l’as pas vraiment dessinée. »
Le logiciel : « Tu ne l’as pas vraiment codé. »
La même structure se cache derrière ces réactions : si la machine a effectué une partie importante du travail, quelle part du mérite reste à l’humain ?
Et une question plus générale : pourquoi avons-nous autant besoin que quelque chose ait été difficile à produire pour lui reconnaître de la valeur ?
Ce qui reste au développeur
Si écrire du code devient moins important, cela libère du temps pour ce qui compte réellement :
- comprendre les problèmes ;
- imaginer des solutions ;
- faire des choix ;
- concevoir des systèmes ;
- expérimenter ;
- définir les contraintes ;
- vérifier les résultats ;
- construire davantage de choses.
La compétence ne disparaît pas.
Elle monte d’un niveau d’abstraction.
Quelqu’un qui comprend profondément le logiciel dispose d’un levier beaucoup plus important lorsqu’il peut déléguer son implémentation.
Écrire du code n’est pas une vertu
Retour aux quatre développeurs du début.
La fracture entre ceux qui utilisent l’IA et ceux qui ne l’utilisent pas est bien réelle. Mais elle en recouvre une autre, plus profonde, entre deux conceptions du métier.
Ceux qui considèrent que leur métier consiste à écrire du code.
Et ceux qui considèrent que leur métier consiste à produire du logiciel.
Le craintif et le puriste appartiennent au premier groupe. Ils partagent la même définition du métier et en tirent deux réactions différentes : l’un craint de perdre ce qu’il fait, l’autre l’érige en vertu. Si le métier se résume à écrire du code, une machine qui écrit du code devient forcément une menace ou une imposture.
L’optimiste appartient au second. Pour lui, l’IA est un levier de plus pour produire du logiciel.
Le retardataire n’a pas encore choisi. Tôt ou tard, il devra le faire.
Je n’ai aucune attache particulière au fait d’écrire mon code moi-même. Je veux construire de bons logiciels. Si demain je peux en construire davantage, plus rapidement et mieux, en écrivant moins de code moi-même, je n’y vois aucune perte de valeur. Au contraire.
Le code est un moyen. Le logiciel est le résultat. Confondre les deux risque de nous faire défendre notre manière de travailler d’hier au moment précis où les outils nous permettent d’inventer celle de demain.