Si l'IA fait le travail des juniors, par où entre-t-on dans le métier ?

Entre 14 et 15 %, c’est le volume du recul des offres d’emploi junior en développement logiciel par rapport aux offres senior depuis l’arrivée de ChatGPT (Westby, Modestino et Cheng, IZA DP18723 ↗, données vacancy Lightcast). Ce nombre prend en compte non seulement la conjoncture mais aussi un mouvement de fond depuis le déploiement grand public des LLM.

Les tâches par lesquelles un junior devenait senior n’ont pas juste été simplifiées par l’IA : elles ont été retirées du marché.

On embauche moins de juniors

Le récit dominant tient en une phrase : on recrute moins de débutants. Un consultant du secteur, Sean Goedecke, résume ce que beaucoup d’équipes techniques observent depuis un an dans son billet sur les ingénieurs juniors ↗ : les postes d’entrée se raréfient, et rares sont ceux qui semblent pressés d’inverser la tendance.

Le cabinet Brynjolfsson et son équipe du Stanford Digital Economy Lab l’ont chiffré sur données de paie ADP (même mécanisme, versant vitesse plutôt que volume, que celui décrit dans le paradoxe de la productivité), dans une étude au titre en forme d’avertissement, Canaries in the Coal Mine ? ↗ : l’emploi entry-level recule sélectivement dans les métiers les plus exposés à l’automatisation par IA générative, développement logiciel en tête.

Le secteur du conseil documente le même mouvement sous un autre nom. Le modèle traditionnel de la profession, la pyramide (beaucoup de juniors en bas, peu de seniors au sommet), est en train de se rétrécir. Starmind ↗, FourWeekMBA ↗ et Sogeti Labs ↗ décrivent la même transition : de la pyramide à l’obélisque, avec un recul de 50 à 70 % des postes entry-level par rapport au modèle pyramidal classique. Ces sources nomment elles-mêmes le risque : dépendance croissante aux recrutements latéraux, pipeline de talents qui s’assèche. Le clivage entre l’expert que l’IA amplifie et le novice qu’elle fragilise (voir libérateur pour l’expert, risqué pour le novice) rejoue ici à l’échelle du marché… (Comme j’ai déjà couvert, à ma façon, d’autres apports majeurs du mémoire excellent de MBA de l’IAE que j’ai encadré cette année, L’impact de l’intelligence artificielle sur le comportement et la productivité des développeurs de Ahmed Hassen BEN TALEB et Inès HADDAJI, j’ai choisi de m’appuyer sur leurs travaux pour illustrer un des enseignements qu’on peut en tirer.)

Deux sources indépendantes chiffrent l’ampleur du même mouvement, l’une aux États-Unis, l’autre en France. SignalFire ↗, un fonds de la Silicon Valley dont la plateforme suit plus de 650 millions de profils, mesure que les embauches de jeunes diplômés chez les douze plus grandes entreprises tech américaines (Google, Meta, Apple, Amazon et consorts) ont chuté d’environ 65 % par rapport à 2019 ; dans les start-up en amorçage, la baisse atteint 76 %. En France, l’Apec constate un recul de 19 % des embauches de cadres débutants (moins d’un an d’expérience, tous métiers confondus) en 2024, et prévoyait, dans ses prévisions 2025 ↗, un nouveau recul de 16 % l’année suivante - deux points de la même série, le second en prévision plutôt qu’en résultat constaté.

C’est un cycle économique

Voici l’argument le plus solide en faveur d’un simple ajustement conjoncturel : le secteur tech a déjà traversé ça. En 2001, en 2008, les recrutements juniors se sont taris avant de reprendre quand la conjoncture s’est améliorée (mais le gel touchait le flux d’embauche, pas la structure du métier). Pourquoi cette fois serait-elle différente ? En France, les offres d’emploi développeur ont chuté de 80 % entre janvier 2023 et juillet 2025 selon les données Indeed relayées par Developpez.com ↗ (un chiffre à prendre avec la réserve que porte l’article lui-même sur la représentativité d’Indeed, et qui ne distingue pas junior de senior). Ajoutez la prudence budgétaire post-hype, quelques trimestres de vaches maigres, et le phénomène s’explique sans reconfigurer quoi que ce soit.

Sauf que ce raisonnement suppose que le ralentissement touche tout le monde de la même façon. Et ce n’est pas ce qu’on observe. L’étude IZA ne mesure pas un tassement général du recrutement : elle isole une hausse d’exigence d’expérience sur les mêmes intitulés de poste. Ce n’est pas qu’on recrute moins de développeurs. C’est qu’un poste étiqueté « développeur » exige aujourd’hui plus d’années d’expérience qu’avant, pour un contenu de mission comparable. Un changement de seuil, pas un changement de composition, c’est aussi ce que rapporte, de l’intérieur, l’un des deux co-auteurs du mémoire cité plus haut, lui-même CTO : ce n’est pas une lecture statistique abstraite, c’est ce qu’on demande concrètement aux équipes aujourd’hui.

Une illustration mérite d’être citée, avec les pincettes qu’impose sa source. Mark Russinovich (CTO Azure) et Scott Hanselman (VP Microsoft) nomment, dans un épisode de leur podcast ↗ largement repris (DevOps.com ↗), un phénomène qu’ils appellent l’« AI drag » : les développeurs juniors, encore en phase d’apprentissage des fondamentaux, sont ralentis par les outils IA plutôt qu’accélérés, tandis que leurs collègues seniors, eux, en tirent un « AI boost » net. Deux dirigeants Microsoft qui vendent des outils IA aux développeurs n’ont, a priori, aucun intérêt à en souligner l’effet dégradant sur la formation des juniors - ce qui rend le constat digne d’attention sans en faire une preuve neutre : c’est un C-Level qui parle de son propre secteur, pas une étude indépendante.

Dans ce même métier, le nombre de développeurs plus expérimentés restent stables ou progressent. Si le mécanisme était purement conjoncturel, un cycle économique généralisé, il toucherait tout le monde. Il ne touche qu’un niveau de la « pyramide », le plus bas. Une objection mérite d’être nommée avant qu’on l’oppose : cette stabilité du nombre de seniors pourrait aussi venir d’une pénurie de profils expérimentés, sans lien avec la thèse de cet article - un phénomène démographique (départs à la retraite d’une cohorte de développeurs seniors) qui produirait le même symptôme. Les deux mécanismes ne s’excluent pas. Mais aucun des deux ne rouvre le marché de l’entrée dans le métier, et c’est ce dont il est question ici.

Même la reprise du marché américain confirme ce partage plutôt qu’elle ne le dément. Sur sa chaîne YouTube, Benjamin Code a compilé, dans une vidéo publiée début août 2026 ↗, une étude Indeed Hiring Lab ↗ :

Depuis le lancement de Claude Code fin février 2025, les offres de développeur aux États-Unis ont regagné près de 15 %, pendant que l’ensemble du marché de l’emploi américain reculait de 7 % sur la même période.

Indeed pose lui-même la réserve méthodologique qui s’impose (« corrélation n’est pas causalité ») avant de noter que la coïncidence de calendrier reste difficile à ignorer. Mais 71 % de cette hausse va à des postes senior.

Ce 71 % ne veut rien dire sans une base de comparaison : plus de senior par rapport à quoi ? Le même Indeed y répond dans une étude distincte publiée deux semaines plus tard ↗, avec un chiffre en points de composition, pas en part d’une hausse ponctuelle. Entre 2019 et 2025, dans l’ensemble du secteur tech, la part des offres senior a gagné 9 points, celle des offres mid-level en a perdu 7,7. Celle des offres entry-level, elle, n’a reculé que d’un point. La bascule récente vers le senior mange donc surtout le mid-level, pas l’entry-level (l’entry-level était déjà si réduit avant même 2025 qu’il ne pouvait plus reculer beaucoup en valeur relative). Ce recul marginal en points, précise Indeed, peut peser lourd en proportion pour ceux qui essaient d’entrer dans le métier. Le marché repart, et repart plus vite que la moyenne. Il repart sans les débutants, mais surtout aux dépens de ceux qui, avant, auraient été promus.

Les tâches d’apprentissage ont disparu et non simplifiées

Voici le renversement. L’IA n’a pas rendu les tâches de junior plus faciles. Elle les a retirées du marché.

CRUD, glue code, tests unitaires, tickets de bugs simples : c’était le matériau brut par lequel un junior devenait progressivement confirmé, le processus d’apprentissage comptât plus que le résultat de chaque ticket (voir enseigner le processus, pas le résultat). Ces tâches n’étaient pas forcément formatrices en elles-mêmes, elles offraient un terrain d’erreur à faible enjeu. On se trompait sur un ticket mineur, un senior corrigeait en revue, on comprenait pourquoi. C’était lent, redondant, parfois frustrant à encadrer. C’était aussi le seul mécanisme connu de fabrication de l’expertise.

Un mémoire de Master encadré à l’IAE Paris (Ahmed Hassen BEN TALEB et Ines HADDAJI, juin 2026, 103 pages), consacré à l’impact de l’IA sur le comportement et la productivité des développeurs, nomme ce mécanisme sous une forme que je trouve plus juste que la plupart des analyses publiées sur le sujet : le saut des apprentissages comme moteur de la dette technique, et non comme son dommage collatéral. L’inversion de causalité est le cœur de l’article. On dit d’habitude que la dette technique s’accumule parce que le code produit vite est mal compris. Le mémoire renverse : le code est mal compris parce que la personne qui devait apprendre à le comprendre n’a jamais eu l’occasion de le faire, l’IA ayant déjà produit ce qu’elle aurait dû s’exercer à écrire.

Le code est mal compris parce que la personne qui devait apprendre à le comprendre n’a jamais eu l’occasion de le faire.

Cette inversion rejoint, sans le nommer, un cadre théorique plus ancien. Harry Braverman ↗, en 1974, décrivait le deskilling comme la séparation organisationnelle entre conception et exécution : un ouvrier qui n’exécute plus que des fragments perd la compréhension du tout. Qin et Cheon, dans un article accepté à CHI 2026 (la conférence de référence en interaction homme-machine), Labor, Capital, and Machine ↗, remettent ce cadre au centre de la recherche en interaction homme-machine : ils opposent explicitement les études HCI (Human-Computer Interaction, interaction homme-machine) classiques de la programmation, qui s’en tiennent aux pratiques de travail et à l’usage des outils, à une lecture par la théorie du procès de travail, qui traite la programmation comme travail salarié pris dans des rapports de pouvoir. Ce n’est pas une étude empirique du développement logiciel assisté par IA (le papier ne mentionne ni l’IA générative ni les outils d’assistance au code), mais un cadre théorique qui légitime la question posée ici. C’est ce cadre, plus que le papier lui-même, qui éclaire ce que le mémoire IAE observe sur le terrain : la boucle d’apprentissage par la pratique.

Cette boucle, le mémoire la décrit en quatre maillons qui s’auto-entretiennent. Le junior ne peut pas auditer le code que l’IA a produit, faute des repères qu’il aurait acquis en l’écrivant lui-même. Il accumule donc du code non compris sans le voir comme un problème. Plus tard, un senior éponge (souvent sur un autre budget, un autre trimestre, sans lien visible avec la cause). Le junior n’est jamais confronté à ses propres lacunes, puisque quelqu’un d’autre les a corrigées avant qu’elles ne deviennent visibles. Ce qui distingue cette boucle d’un simple déficit de formation, c’est qu’elle ne se rompt jamais d’elle-même. Aucun indicateur de vélocité ne la capture : le sprint avance, les tickets se ferment, la dette s’accumule ailleurs.

Un travail empirique récent documente la même érosion sans invoquer Braverman. Shen et Tamkin, dans une étude par assignation aléatoire publiée en janvier 2026, mesurent comment l’IA générative façonne la formation des compétences ↗ : les développeurs qui s’appuient sur l’assistance IA pour résoudre une tâche perdent en compréhension conceptuelle de cette tâche, comparés à un groupe qui la résout sans assistance. Le RCT (randomized controlled trial, essai contrôlé randomisé) ne parle pas de séniorité ni de recrutement. Il documente, à l’échelle d’une tâche unique, exactement le mécanisme que le mémoire décrit à l’échelle d’une carrière.

Le raccord théorique le plus original du mémoire, à mon sens, tient en une phrase. Herbert Simon ↗, en 1955, avait posé le concept de satisficing : face à une décision coûteuse à optimiser, un agent rationnel s’arrête au premier résultat « suffisamment bon », pas au meilleur possible. Le mémoire montre comment l’IA générative abaisse mécaniquement le seuil de ce « suffisamment bon » : « ça a l’air correct » remplace « j’ai vérifié que c’est correct ». Ni Simon ni les auteurs qui ont formalisé le concept ne font ce lien avec l’assistance par IA. C’est une construction propre au mémoire, et elle éclaire un mécanisme que j’ai traité en détail ailleurs sous l’angle de la reddition cognitive : ici, le satisficing n’est pas seulement un raccourci de jugement individuel, c’est ce qui prive le junior du seul exercice qui aurait pu construire son jugement.

« Ça a l’air correct » remplace « j’ai vérifié que c’est correct ».

L’ironie de l’automatisation, décrite par Lisanne Bainbridge ↗ dès 1983, referme la boucle. L’expertise nécessaire pour traiter les cas exceptionnels, ceux qu’aucun système automatisé ne sait résoudre seul, s’acquérait justement par la pratique répétée des cas simples. Confisquer les cas simples ne rend pas les cas exceptionnels plus faciles à traiter. Ça retire l’entraînement qui aurait permis de les traiter.

Confisquer les cas simples ne rend pas les cas exceptionnels plus faciles à traiter. Ça retire l’entraînement qui aurait permis de les traiter.

Un signal plus fragile mérite d’être cité avec sa réserve, pas comme un fait établi. En septembre 2025, Lance Eliot documentait dans Forbes ↗ l’émergence d’un rôle informel de « vibe code cleaner », des développeurs le plus souvent seniors chargés de reprendre et consolider du code produit en vibe coding par d’autres. L’article est une source primaire réelle, antérieure au mémoire IAE de plusieurs mois : le terme n’est donc pas une invention de 2026. Mais aucun intitulé de poste dédié n’existe sur le marché du recrutement à ce jour. Les cabinets qui documentent les nouvelles compétences recherchées, comme KORE1 ↗, intègrent la revue de code IA à des rôles génériques plutôt qu’à un métier séparé. Tous les relais qui ont repris le terme après Forbes recyclent le même article sans observation indépendante. Le rôle existe comme pratique et comme signal de tension. Il n’existe pas encore comme donnée de marché.

Comment devenir développeur senior dans ce contexte ?

Aucun de ces éléments n’apparaît dans un tableau de bord de management. La vélocité de sprint progresse, parfois. Le nombre de tickets fermés progresse, souvent. Rien dans ces indicateurs ne dit si l’équipe est en train de fabriquer son prochain senior ou de dépenser le seul mécanisme qui savait le faire.

La vélocité de sprint progresse, parfois. Le nombre de tickets fermés progresse, souvent. Rien dans ces indicateurs ne dit si l’équipe est en train de fabriquer son prochain senior ou de dépenser le seul mécanisme qui savait le faire.

Le mémoire propose une matrice à double entrée pour arbitrer où l’IA générative peut intervenir sans dette : criticité du processus concerné, croisée avec maturité de l’équipe qui l’exécute. Trois zones : autoriser (faible criticité, équipe mature), encadrer (criticité ou maturité intermédiaire), limiter ou interdire (criticité forte, équipe junior). Les auteurs sont explicites sur son statut : c’est une heuristique de départ, pas un résultat testé sur données. Elle vaut comme cahier des charges de discussion pour une équipe, pas comme grille prescriptive validée empiriquement.

La feuille de route qui l’accompagne obéit à une logique simple : on n’encadre que ce qu’on a d’abord mesuré, on ne pérennise un mode de fonctionnement qu’une fois les processus d’encadrement en place. Mesurer avant d’encadrer, encadrer avant de pérenniser. L’ordre compte : sauter l’étape de mesure, c’est encadrer à l’aveugle. Cette logique de révision régulière plutôt que de plan figé rejoint la distinction entre périmètre planifiable et périmètre incertain appliquée aux compétences.

Une illustration de réponse organisationnelle existe, à traiter comme telle plutôt que comme modèle validé. Le duo Russinovich/Hanselman propose ce qu’ils appellent un preceptorship : un dispositif de mentorat structuré où le senior reste explicitement responsable de la montée en compétence du junior, contrainte inscrite dans l’organisation du travail et pas laissée à la bonne volonté individuelle. Rien n’indique que ce dispositif ait été mesuré ou déployé au-delà du discours : c’est une proposition, pas un résultat. Elle vaut comme illustration de ce à quoi ressemblerait une réponse délibérée : la thèse de cet article tient sans elle, le mécanisme spontané de remplissage a disparu, et seule une réponse organisationnelle consciente peut le remplacer.

Un contre-modèle utile pour cadrer cette conception vient d’un tout autre terrain. Le chercheur Matt Beane ↗ a étudié le shadow learning : la façon dont les novices contournent les systèmes qui réduisent leur espace de participation pour continuer, malgré tout, à apprendre. Il en tire trois conditions, les 3C (Challenge, Complexity, Connection) : un novice progresse quand il est confronté à des tâches suffisamment exigeantes, suffisamment complexes, et reliées à un accompagnement réel. Beane décrit ce que les novices contournent individuellement pour continuer d’apprendre malgré un système qui ne le prévoit plus. Cet article décrit le mécanisme inverse, côté organisation : le système qui ne fournit plus spontanément ces tâches. Les deux angles se rejoignent sur un point : si l’organisation ne recrée pas sciemment le Challenge, la Complexity et la Connection que le marché fournissait avant, personne d’autre ne le fera à sa place.

Ce que ça change selon votre poste

Un manager IT qui arbitre la composition de son équipe affronte une question concrète : quel ratio senior/junior reste soutenable quand la vélocité ne dit plus rien du tarissement en cours ? La matrice criticité × maturité donne un point de départ pour cette conversation, pas une réponse toute faite.

Un professionnel confronté à la transformation sans piloter la stack, DRH, membre de CSE, manager de proximité, gagne à distinguer ce que l’IA change dans le travail lui-même de ce qu’elle change dans l’emploi. Ce sont deux questions différentes, et la seconde masque souvent la première dans le débat public.

Un lead dev ou un CTO vit l’arbitrage au quotidien, dans un endroit précis : qui hérite du code généré par IA. La revue de code, pratiquée comme dispositif de transmission plutôt que comme simple filtre qualité, est le levier le plus immédiatement actionnable de cet article.

Un étudiant qui se demande par où entrer dans le métier touche directement à la question du titre. La réponse n’est pas rassurante par défaut : le socle d’entrée qui existait s’est déplacé, pas disparu. Mais il faut désormais le chercher, pas le trouver spontanément dans une pile de tickets simples.

Ce que j’en retiens

S’appuyant sur une analyse de la littérature très riche et une démarche ambitieuse, je retiens l’enthousiasme des auteurs dans la réalisation de ces travaux. La guidance de mémoire et l’enseignement appellent une forme d’humilité parce qu’il existe toujours un écart entre ce que souhaite avoir transmis et ce qui a été retenu ou appliqué. Il s’agit d’un travail réjouissant, fouillé et intelligent qui permet au lecteur d’avancer dans la réflexion au gré du déroulé du mémoire.

Sur le sujet lui-même, la développement des compétences, dans une organisation, est aussi un geste collectif, organisé ou pas, jamais un accident individuel qu’on pourrait attribuer au seul mérite ou au seul défaut d’un junior isolé.

Post-scriptum : le mémoire d’Ahmed Hassen BEN TALEB et Ines HADDAJI n’est pas publié. Les lecteurs intéressés par le détail de leur travail peuvent le leur demander directement via LinkedIn.