Peu de peurs technologiques auront été aussi bruyamment proclamées que celle-ci : l'idée que les grands modèles de langage seraient sur le point de rendre les développeurs superflus. Pourtant, un essai très commenté soutient que ce récit confond une vérité partielle avec une vérité totale. L'IA a bel et bien englouti une partie du métier — mais pas celle qui compte le plus.

Publié sur NormalTech et propulsé en une de Hacker News, le texte a déclenché un de ces débats fleuves où le secteur tout entier vient régler ses comptes avec sa propre angoisse. Son intérêt n'est pas de nier que quelque chose a changé : c'est de remettre ce changement à sa juste échelle, chiffres à l'appui.

Le sandwich décider-exécuter-livrer

L'argument central tient dans une métaphore soignée. Le travail logiciel, affirme l'auteur, est un « sandwich décider-exécuter-livrer » : on décide quoi construire, on écrit le code, puis on livre et on vérifie. Ce que l'IA a comprimé, c'est uniquement la garniture du milieu — l'exécution. Les deux tranches qui l'entourent, le jugement en amont et la responsabilité en aval, se sont révélées étonnamment résistantes à l'automatisation.

La nuance est importante : il ne s'agit pas d'une limite de capacité que la prochaine version d'un modèle viendrait lever. Tant qu'une personne devra répondre de ce qui est mis en production — devant un client, un régulateur ou un conseil d'administration —, l'ingénieur ne disparaîtra pas. Décider quoi construire suppose de comprendre un contexte, des contraintes et des compromis ; livrer suppose d'assumer ce qui casse. Aucune de ces deux opérations ne se réduit à une génération de tokens.

Écrire du code n'a jamais été le goulot d'étranglement

Le point le plus contre-intuitif de l'essai est aussi le mieux étayé : écrire du code n'a jamais été le frein. Les études sur l'emploi du temps des développeurs montrent qu'ils ne passent qu'une fraction de leur journée à coder réellement ; le reste se dissout dans les réunions, le recueil des besoins, la revue de code et les tests.

D'où une observation que l'auteur martèle : quand des agents produisent jusqu'à huit fois plus de code, le nombre de mises en production ne progresse que d'environ trente pour cent. Autrement dit, accélérer la frappe ne dégoupille pas la livraison, parce que le vrai goulot d'étranglement se situe ailleurs — dans la coordination, la validation et la décision. Automatiser la partie la moins coûteuse d'un processus n'en supprime pas le coût dominant.

C'est aussi pour cela que la promesse du « développeur remplacé » se heurte au réel dans les outils eux-mêmes. Une jeune pousse comme Niteshift bâtit justement son discours sur l'idée que l'IA augmente l'ingénieur plutôt qu'elle ne le congédie, en cherchant à éviter le verrouillage propriétaire qui ferait du développeur un simple opérateur captif.

L'« AI washing » des licenciements

Le récit du remplacement de masse s'effondre surtout face aux chiffres. Sur les quelque 1,17 million de suppressions de postes dans la tech en 2025, seuls 5 % environ tenaient à l'automatisation par l'IA ; l'essentiel découlait d'un sureffectif que les entreprises ont corrigé après les embauches frénétiques de la pandémie, tout en se drapant dans un récit plus flatteur.

Le détail le plus parlant est sociologique. Un sondage a révélé que 59 % des recruteurs avouaient mettre l'IA en avant dans les annonces de licenciement parce que cela « passe mieux auprès des actionnaires » : licencier pour cause de mauvaise gestion ternit l'image, licencier au nom de l'innovation la dore. À New York, où une loi impose de déclarer les coupes effectivement liées à l'IA, sur plus de 160 dépôts soumis à cette obligation, une seule entreprise a coché la case. L'écart entre le discours public et la déclaration légale en dit long sur la part de mise en scène.

Plus de logiciels, plus d'ingénieurs

Reste l'argument économique, le plus déroutant pour qui s'attend à une apocalypse de l'emploi. Rendre le logiciel moins cher à produire pourrait, paradoxalement, en faire fabriquer beaucoup plus. La demande de ce que le logiciel pourrait accomplir est loin d'être saturée : si chaque entreprise, chaque administration, chaque produit peut désormais s'offrir des fonctionnalités jusqu'ici trop coûteuses, alors plus de logiciels signifie plus d'ingénieurs pour les concevoir, les arbitrer et les maintenir — et non moins.

L'auteur rappelle au passage que l'emploi de programmeur aux États-Unis est passé de quasiment rien autour de 1950 à plusieurs millions de postes aujourd'hui, à travers des décennies pourtant ponctuées d'outils censés « tuer » le métier — compilateurs, langages de haut niveau, frameworks. Les commentateurs de Hacker News invoquent l'analogie du tracteur : la mécanisation a bel et bien déplacé les ouvriers agricoles. L'incertitude cruciale n'est donc pas de savoir si certains postes vont disparaître, mais si les ingénieurs évincés trouveront ailleurs un secteur d'accueil — ce que l'essai laisse prudemment ouvert.

Un métier qui mute plutôt qu'il ne meurt

La conclusion n'est ni triomphaliste ni rassurante à bon compte : le métier ne disparaîtra peut-être pas, mais il se transforme. Comme le raconte un reportage sur le nouveau flux de travail, Boris Cherny, créateur de Claude Code, fait le pari que l'intitulé même finira par s'effacer au profit de « constructeur » ou de « chef de produit ». Le développeur de demain passerait moins de temps à taper des lignes et davantage à orchestrer des agents, à spécifier, à vérifier et à assumer.

Ce déplacement de la valeur vers le jugement et la responsabilité explique pourquoi la communication des fournisseurs d'IA elle-même reste prudente. Les démonstrations spectaculaires d'outils comme Claude et Fable nourrissent une mythologie grand public du « code qui s'écrit tout seul » ; mais à l'intérieur des équipes, la réalité ressemble moins à un remplacement qu'à un changement de poste de travail.

L'essai ne prétend pas que rien ne bouge. Il soutient quelque chose de plus subtil et de plus solide : la partie automatisable du génie logiciel n'a jamais été la partie chère, et confondre les deux a permis de vendre des plans sociaux comme des sauts technologiques. Tant que quelqu'un devra décider quoi construire et répondre de ce qui est livré, il y aura un ingénieur au bout de la chaîne — quel que soit le nom qu'on lui donne.