Pourquoi l’IA ne nous remplacera pas (encore)

Je n’écris presque plus de code, et je n’ai jamais eu autant de travail.

Je passe mes journées à concevoir. Je peaufine des spécifications pour que chaque ticket soit implémenté correctement. Je vérifie les résultats, longuement. J’ai décrit cette façon de travailler dans Je ne lis presque plus de code, je n’y reviens pas ici.

Dans Écrire du code n’est pas une vertu, je décrivais quatre attitudes des développeurs face à l’IA. Les craintifs en font partie. Ils regardent les capacités progresser et y voient surtout une menace pour leur métier. Je les avais laissés de côté pour parler des puristes.

Cet article leur est adressé. Leur inquiétude est légitime. Je pense simplement qu’elle mène à la mauvaise conclusion.

Ce que l’IA fait déjà, et ce que ça change pour toi

Je ne vais rien minimiser.

L’IA écrit du code, et souvent du bon code. Elle écrit aussi les tests, relit la merge request, repère les régressions et corrige ce qu’elle a cassé. Sur la plupart de mes tickets, la première version du diff ne sort plus de mes mains.

Si ton quotidien consiste à prendre un ticket et à l’implémenter, tu as raison de regarder ça de près. C’est précisément la tâche que l’IA sait le mieux faire. Craindre de voir des postes disparaître, ou des années d’expérience perdre de leur valeur, n’a rien d’irrationnel.

Je ne vais pas non plus te promettre une transition indolore. Certains postes vont changer brutalement. Des compétences très recherchées il y a trois ans vont beaucoup moins compter. Et tout le monde ne suivra pas sans effort. Je préfère le dire franchement.

Un métier, pourtant, est un ensemble de tâches. Quand l’une d’elles s’automatise, les autres se réorganisent autour, et de nouvelles apparaissent.

C’est déjà arrivé plusieurs fois. Les compilateurs ont retiré aux développeurs l’écriture de l’assembleur. Les frameworks ont absorbé des milliers de lignes de plomberie que chaque équipe réécrivait dans son coin. Le cloud a fait disparaître une grande partie du travail sur les serveurs physiques. À chaque fois, une tâche centrale est partie. À chaque fois, le métier s’est recomposé, et il y a eu davantage de développeurs après qu’avant.

Quand le code coûte moins cher, on en demande plus

En 1865, l’économiste William Stanley Jevons fait une observation qui semble paradoxale. Les machines à vapeur consomment de moins en moins de charbon pour produire le même travail, et pourtant la consommation totale de charbon en Angleterre augmente. En devenant plus efficace, la ressource est devenue rentable pour une foule d’usages nouveaux.

Je pense que le logiciel suit la même pente.

Aucune équipe ne vide son backlog. Chacune renonce en permanence à des fonctionnalités, à des outils internes, parfois à des projets entiers, parce qu’ils coûtent trop cher à construire. Quand le coût d’un logiciel baisse, ces projets redeviennent rentables. Des entreprises qui ne pouvaient pas s’offrir une équipe technique peuvent commencer à en monter une. Les idées rangées dans « un jour, peut-être » passent dans « ce trimestre ».

Jevons décrit une tendance, et une tendance de long terme n’a jamais protégé personne d’un mauvais trimestre. À court terme, l’ajustement peut faire mal. Sur la durée, je parie que la demande en logiciel va exploser, et avec elle le besoin de gens capables de le concevoir.

Les questions qui me restent

Les questions que je me pose au travail ont changé. Il y en a cinq, et aucune ne porte sur la syntaxe.

Quel problème faut-il résoudre ? Un besoin arrive rarement propre. Il prend la forme d’une plainte client, d’une intuition produit, d’une demande qui descend de la direction. Le transformer en problème précis demande de discuter, de reformuler, d’arbitrer avec le produit. L’IA m’aide à explorer les pistes. Décider lequel de ces problèmes mérite d’être résolu reste une affaire humaine.

Quelles contraintes donner ? Une bonne partie de ce qui compte ne se trouve pas dans le repo. On n’y lit pas pourquoi ce module a été découpé ainsi, quelle dette l’équipe a acceptée volontairement et pour quelle raison, ni quelle équipe possède telle API et ce qu’elle est prête à tolérer. Ce contexte vit dans des têtes, des fils de discussion et des réunions. Tant que je ne le formule pas, aucun agent ne peut en tenir compte.

Comment savoir si le résultat est correct ? Vérifier suppose d’avoir défini ce qu’on vérifie. Les critères d’acceptation, les cas limites et ce qui ne doit surtout pas casser se décident avant la première ligne. Un agent peut exécuter mille tests. Il faut quelqu’un pour décider lesquels comptent.

Comment concevoir le système ? Chaque décision d’architecture est un compromis : vitesse de livraison ou souplesse, simplicité ou performance, cohérence ou autonomie des équipes. L’IA liste les options avec une aisance impressionnante. Choisir, puis assumer ce choix six mois plus tard quand il commence à coûter, reste mon travail.

Comment prouver que ça fonctionne ? Il faut décider du niveau de preuve suffisant, puis signer la mise en production. Cette signature engage quelqu’un. Quand quelque chose casse, la question « qui a validé ? » attend toujours un nom.

Ces cinq questions, c’est le « encore » du titre. Je ne sais pas quand l’IA saura y répondre seule, ni même si elle y arrivera un jour. Personne ne le sait, et je me méfie de ceux qui annoncent une date. Tant que ces questions demandent quelqu’un pour y répondre, le métier de développeur existe.

Former les juniors aux fondamentaux

La question des juniors est celle qui inquiète le plus, et à raison. Si l’IA écrit le code, qui va faire confiance à un débutant le temps qu’il apprenne ?

Je pense que la réponse passe par la formation. Pendant des années, on a appris aux juniors à écrire du code et à maîtriser un framework. On sortait d’école opérationnel sur React ou sur Spring. Cette partie du travail, l’IA la fait désormais très bien. Je recentrerais la formation sur les fondamentaux de la programmation :

les structures de données, les algorithmes et leur complexité ;
les design patterns, le découpage des responsabilités, le couplage et la cohésion ;
la modélisation des données, le SQL, les transactions ;
le fonctionnement du réseau et de HTTP, la concurrence ;
les tests : quoi tester, et pourquoi ;
le débogage et la lecture d’un code qu’on n’a pas écrit ;
l’architecture : les frontières entre modules, le sens des dépendances ;
les bases de la sécurité ;
l’écriture d’une spécification et de critères d’acceptation.

Ces compétences vieillissent très lentement. Un framework change tous les trois ans. La complexité d’un algorithme ou le coût d’une transaction mal placée n’ont pas bougé depuis des décennies.

Surtout, ce sont exactement les compétences qui permettent de répondre aux cinq questions. Un junior qui les maîtrise sait juger ce qu’un agent produit. C’est ce qui le rend utile dès ses premiers mois.

Ce que je ferais à ta place

Si tu es développeur, en poste, et que tout ça t’inquiète, voici par où je commencerais.

Utilise un agent sur un vrai ticket. Un ticket de ton backlog, avec ses contraintes réelles. Tu verras vite ce qu’il fait très bien, et tout ce qu’il ne sait pas faire sans toi.
Entraîne-toi à écrire des spécifications. Avant d’implémenter, écris ce que le ticket doit faire, ce qu’il ne doit pas casser et comment tu sauras qu’il est terminé. Donne-le à un agent. Ce qui revient te montrera exactement où ta spécification était floue.
Reprends les fondamentaux. Choisis un sujet dans la liste précédente et creuse-le pendant quelques semaines, avec un livre ou un petit projet. C’est l’investissement qui se déprécie le moins.

Aucune de ces étapes ne demande de permission. Tu peux commencer demain matin.

Une époque formidable

Si ton métier se résumait à écrire du code, tu aurais raison d’avoir peur. Il n’a jamais été que ça.

Et maintenant que l’écriture du code ne remplit plus nos journées, je pense sincèrement qu’on vit une époque formidable.

Notre génération aura connu l’avant et l’après. On a écrit nos boucles à la main, cherché nos réponses sur Stack Overflow, perdu des soirées sur un fichier de configuration. Aujourd’hui, on regarde des agents écrire, tester et corriger du code en quelques minutes. Peu de générations de développeurs assistent à un tel basculement de leur métier. Nous sommes en plein dedans.

Et tout reste à construire.

Personne n’a encore écrit les bonnes méthodes pour travailler avec des agents. Les pratiques de vérification et de preuve s’inventent en ce moment, équipe par équipe, par des gens qui essaient, se trompent et partagent ce qu’ils trouvent. La façon de former la prochaine génération est à repenser. Les outils eux-mêmes en sont à leurs débuts. Et il y a tous ces logiciels qu’on ne construisait pas parce qu’ils coûtaient trop cher : ils attendent quelqu’un pour les concevoir.

Ce quelqu’un, c’est nous. Nous sommes les pionniers de ce changement. Ceux qui ont peur aujourd’hui ont exactement ce qu’il faut pour en faire partie : ils connaissent le logiciel, ses pièges et ses compromis. Il leur manque seulement la décision de s’y mettre.

Je n’échangerais ma place avec aucune autre génération de développeurs. Tout est à construire, et c’est à nous de le faire.

Pourquoi l'IA ne nous remplacera pas (encore)