Un mardi, dans un studio web quelconque : un junior est penché depuis le matin sur une page qui ne s'affiche pas comme prévu. Il finit par tomber sur une propriété CSS héritée d'un composant écrit trois ans plus tôt. Ce n'était pas là. Il recommence. Le soir, il ne le formulerait pas ainsi, mais il sait quelque chose qu'aucun tutoriel ne lui avait donné. Cette journée « perdue » est précisément ce que les agents de code promettent d'éliminer. Et c'est très probablement ce qui fabriquait, jusqu'ici, les gens capables de juger le travail d'une machine.
Pas de licenciements, simplement plus d'embauches
Les données ne ressemblent pas à une catastrophe. Le Stanford Digital Economy Lab a révisé en août 2026 son travail sur l'IA générative et l'emploi, à partir de données de paie ADP couvrant des millions de salariés américains jusqu'en juin 2026. Résultat d'ensemble : pas de destruction massive d'emplois. Mais chez les 22–25 ans, dans les métiers les plus exposés, l'emploi se situe 19 % en dessous de ce qu'il serait en suivant la trajectoire de leurs pairs moins exposés. Chez les seniors, rien de comparable.
Personne n'est mis à la porte : on ne recrute plus. D'où des statistiques globales sages, qui masquent ce qui se passe à l'entrée. Les auteurs eux-mêmes parlent de résultats descriptifs, non d'une preuve de causalité. Soit. Un signal descriptif qui va dans le même sens que ce qu'on entend dans les studios mérite quand même qu'on s'y arrête.
Autre nuance, qui change la lecture : les baisses se concentrent là où l'IA substitue des tâches humaines. Là où elle les complète, l'emploi stagne ou progresse, surtout chez les profils expérimentés. Les juniors en général ne sont donc pas visés. Ceux qui le sont font ce qu'un agent fait déjà assez bien, dans des équipes qui n'ont pas décidé quoi faire du temps libéré.
Une réserve de taille : ces chiffres sont américains. On n'a pas, à notre connaissance, d'équivalent solide pour la France ou l'Europe, et aucun relevé public d'équipes qui auraient supprimé leur poste junior au profit d'un agent. Les conversations de couloir ne font pas une statistique.
Ce que le build cassé enseignait
Relire un diff ligne à ligne, réparer un build, refaire trois fois une page : économiquement, c'est du jetable. Presque rien de facturable en sort. Mais il en sort un modèle mental du système. On comprend rarement un code parce qu'il marche. On le comprend parce qu'on a vu, à un endroit précis, pourquoi il ne marchait pas.
Le développeur qui a passé une nuit sur une dépendance mal versionnée s'en méfiera pendant dix ans. Celui qui a vu une abstraction trop maligne devenir illisible la reconnaît de loin. C'est ce qui sépare celui qui relit de celui qui approuve. Avec l'agent, le junior reçoit une page qui fonctionne, et rien de ce qui la fait tenir.
Le résultat arrive sans la nuit passée à le comprendre.
« Ils apprendront plus vite » : sur quoi, au juste ?
L'objection est sérieuse, et elle a des chiffres. L'étude du NBER (National Bureau of Economic Research) de Brynjolfsson, Li et Raymond, portant sur 5 179 agents de support client, mesure un gain de productivité de 14 % en moyenne et de 34 % pour les novices, contre un effet quasi nul chez les expérimentés. L'outil diffuse les pratiques des meilleurs et aide les nouveaux à gagner du temps sur la courbe d'expérience. Si le code fonctionnait pareil, le junior deviendrait senior plus tôt.
Mais il s'agit de support client, pas de développement : transposer est un pari. Et l'étude compte des tickets résolus par heure. C'est une performance, pas une compétence. Prenons un outil juste 85 % du temps, ordre de grandeur plutôt que mesure : les 15 % restants sont justement ceux qu'un novice ne sait pas repérer. La machine fournit la réponse, pas le raisonnement qui permet de voir quand elle ne vaut plus. Accéder à l'information ne construit pas le jugement.
« Plus vite » mérite aussi qu'on le questionne. Si le parcours se raccourcit sur les tâches bien définies, celles où l'agent excelle et où un test dit vrai ou faux, on accélère la partie facile et on saute la partie formatrice. Les meilleurs agents sont passés de quelques pourcents à plus de 70 % de tickets résolus sur SWE-bench Verified en deux ans. Des problèmes bien posés, validés automatiquement. Le travail réel l'est rarement, et aucun bouton « run tests » ne dit si l'architecture tiendra dans trois ans.
Qui relira le code de la machine ?
Pour relire un diff produit par un agent, il faut déjà savoir à quoi ressemble un bon diff. Et surtout reconnaître l'erreur de conception cachée derrière un code syntaxiquement impeccable. Cela ne s'acquiert pas en validant des propositions. Cela s'acquiert en s'étant trompé, souvent, sur des choses qui comptaient peu.
Le marché risque de se couper en deux : des profils très expérimentés, plus précieux parce qu'ils sont les seuls à arbitrer, et un vide au milieu. Le coût n'apparaît pas ce trimestre. Quand faudra-t-il promouvoir des gens qui n'ont jamais porté seuls un diagnostic ? Cinq à huit ans, avance-t-on parfois. C'est une hypothèse, pas une échéance. Mais une pénurie de ce type ne se règle pas par une campagne de recrutement.
Former coûte à celui qui forme
Pris isolément, le calcul se défend. Une équipe qui remplace un poste junior par un abonnement affiche une productivité en hausse et une masse salariale en baisse. Seulement voilà : l'entreprise qui forme paie, celle qui ne forme pas récupère la personne formée. Chacun attend que l'autre s'y colle. Rien de scandaleux, juste un mécanisme connu.
Les gagnants sont les développeurs confirmés, dont l'outil augmente le levier sans menacer la place. Les perdants : les jeunes qui n'entrent pas, et les petits studios, incapables de financer un poste à perte. Ceux-là recruteront des seniors, ou personne. Le savoir-faire se concentre sans que personne l'ait décidé.
Garder l'erreur, pas la corvée
Personne ne réclame le retour du build cassé à 23 heures. Ce qu'il faut sauver, c'est l'erreur comme signal. Quelques pratiques tiennent même dans une équipe de deux ou trois personnes.
- Réserver chaque semaine un créneau non facturé à une tâche que l'agent ferait mieux, justement parce qu'elle forme.
- Avant de lire la correction, écrire ce qui va casser et pourquoi : l'écart avec le réel est la matière de l'apprentissage.
- Faire le post-mortem d'une erreur de l'agent comme on le ferait pour une erreur humaine. Un cas d'école gratuit, à condition de s'y arrêter.
- À l'entretien comme en revue annuelle, demander d'expliquer un diff ou de refuser une solution qui passe les tests, plutôt que de compter ce qui a été livré.
Rien de cela ne se fait seul. Un agent optimise ce qu'on lui demande, pas la patience qu'il faut pour laisser un junior se tromper. Cette décision reste humaine, et elle coûte tout de suite. C'est bien pourquoi elle ne sera pas prise par défaut.
Et si les modèles plafonnent ?
L'objection la plus solide est là. Si les gains se tassent, la demande de juniors reviendra et l'écart se refermera comme il s'est ouvert. Autre scénario : des outils qui expliquent leur raisonnement, signalent leurs doutes, enseignent au lieu de livrer. Ce n'est pas la direction actuelle. Les produits sont réglés pour finir la tâche, pas pour former celui qui regarde.
Reste une asymétrie. La productivité se mesure en trimestres, la compétence se construit en années. Une équipe peut gagner deux ans de marge et découvrir plus tard qu'elle a fermé la filière qui produisait ses relecteurs. Les statistiques, elles, resteront calmes jusque-là.