Si l’IA fait le travail des juniors, comment former les seniors de demain ?

L'IA peut générer une implémentation, expliquer du code inconnu et suggérer une correction. Pour quelqu'un qui débute une carrière dans le développement logiciel, cela crée des opportunités.

Pour les employeurs, cela soulève également une question inconfortable.

Si un développeur expérimenté avec l'IA peut gérer un travail précédemment assigné à un junior, les entreprises recruteront-elles encore des personnes en début de carrière ? Et quelle valeur ces personnes peuvent-elles apporter pendant qu'elles apprennent ?

Chez HumanInTech, nous pensons qu'il existe de solides arguments pour continuer à recruter des juniors et accompagner leur progression. Mais ces arguments doivent être pratiques. Les entreprises ont besoin de personnes qui contribuent aujourd'hui, tout en développant l'expertise dont elles auront besoin demain.

Des recherches récentes aident à expliquer à la fois l'opportunité et le risque.

Produire plus de logiciels, comprendre ces logiciels et développer un jugement professionnel sont des résultats différents. Nous devons faire de la place pour les trois.

La pression sur l'emploi de niveau débutant mérite attention

Des chercheurs de Stanford ont analysé les données de paie américaines jusqu'en juin 2026. Ils ont rapporté que l'emploi parmi les travailleurs âgés de 22 à 25 ans dans les professions exposées à l'IA se situait 19 % en dessous du niveau qui aurait été atteint si leur emploi avait progressé au même rythme que celui de leurs pairs moins exposés. La divergence s'est opérée principalement par une réduction du recrutement.

Les auteurs décrivent cela comme des résultats observationnels, et non une estimation causale. Ils n'ont également trouvé aucune suppression généralisée d’emplois à l’échelle de l’économie. Ce sont des résultats américains à travers les professions, et non une mesure du recrutement de développeurs juniors belges. Source : Stanford Digital Economy Lab, révisé en août 2026.

Le graphique de l'emploi reconstruit la comparaison rapportée sous forme d'indice : 100 pour le point de référence de comparaison et 81 pour le niveau d'emploi relatif rapporté. Il ne montre pas que 19 % des développeurs juniors ont perdu leur emploi.

Pour les employeurs, cela soulève une question au-delà des licenciements : que se passe-t-il lorsque la première opportunité ne s'ouvre jamais ?

Une entreprise pourrait conserver ses développeurs expérimentés tout en décidant de ne pas pourvoir son prochain poste junior. Ce choix peut être compréhensible dans le cadre d'un budget particulier. Répété dans toutes les organisations, il pourrait rétrécir la voie par laquelle les personnes entrent dans la profession.

Nous ne pouvons pas promettre que le recrutement de juniors restera inchangé. Nous pouvons décider si nos propres organisations offrent un parcours significatif vers le travail.

L'IA peut également rendre les développeurs moins expérimentés plus productifs

Il existe également des preuves d'opportunité.

Trois expériences de terrain randomisées impliquant 4 867 développeurs chez Microsoft, Accenture et une entreprise du Fortune 100 ont trouvé une augmentation estimée de 26,08 % des tâches accomplies avec un assistant de codage IA. Les développeurs moins expérimentés ont montré une adoption plus élevée et des gains de productivité plus importants. L'estimation groupée présentait une incertitude substantielle, illustrée dans le graphique. Source : Cui et collègues, juin 2025.

Le nombre de tâches accomplies mesure la production. Il ne démontre pas des gains équivalents en apprentissage, en fiabilité ou en valeur commerciale.

L'implication pour le recrutement mérite d'être considérée. Les employeurs peuvent utiliser l'IA pour aider un junior à devenir utile plus rapidement, avec une supervision appropriée.

Cela n'établit pas un retour universel sur le recrutement de juniors. Cela remet en question l'hypothèse selon laquelle les avantages de productivité de l'IA appartiennent exclusivement aux développeurs expérimentés.

La question pratique devient : quelles responsabilités utiles un junior peut-il assumer avec ces outils et le bon soutien ?

Quelle valeur un junior peut-il apporter aujourd'hui ?

Une réponse crédible doit aller au-delà de l'enthousiasme, des perspectives nouvelles ou d'un salaire inférieur. Un junior peut contribuer par un travail concret dont la portée correspond à ses compétences en cours d’acquisition.

• Enquêter sur les problèmes : reproduire une défaillance intermittente et documenter les conditions qui la déclenchent, donnant à l'équipe des preuves exploitables.
• Fournir des améliorations délimitées : améliorer la validation, l'accessibilité ou la gestion des erreurs avec révision, résolvant de vrais problèmes utilisateurs.
• Vérifier le comportement : transformer un défaut signalé par un client en test de régression pour aider à prévenir le retour de la même défaillance.
• Clarifier les connaissances : tester les instructions d'intégration et documenter les étapes manquantes, rendant l'équipe moins dépendante des explications informelles.
• Assurer le suivi auprès des utilisateurs : vérifier si une modification livrée répond à la difficulté initiale, en reliant la livraison technique au résultat escompté.
• Développer la compréhension du domaine : apprendre les règles et les exceptions qui sous-tendent un flux de travail métier, en développant la capacité à prendre des décisions de plus en plus éclairées.

Ce sont des exemples de la façon dont nous structurerions le travail, plutôt que des résultats mesurés par les études.

Prenons un client qui signale qu'une commande disparaît parfois d'un écran. Un junior peut enquêter pour savoir quels utilisateurs sont affectés, reproduire la séquence et déterminer si l'information est manquante, retardée ou affichée incorrectement.

Un senior devra peut-être aider à interpréter les preuves ou à choisir la correction. Mais l'enquête elle-même fait avancer le travail. L'apprentissage se fait par une contribution utile.

Une réalisation plus rapide ne garantit pas une compréhension plus approfondie

Une expérience distincte illustre pourquoi la production seule est une mesure incomplète.

Des chercheurs ont recruté 52 ingénieurs principalement juniors pour travailler avec une bibliothèque Python inconnue. Le groupe assisté par IA a obtenu en moyenne 50% à un quiz de compréhension immédiat, contre 67% sans IA : une différence de 17 points de pourcentage. L'avantage en termes de temps n'était pas statistiquement significatif.

Il s'agissait d'une expérience de petite envergure et de courte durée. Elle n'établit pas de perte de compétences à long terme. L'analyse exploratoire a associé la recherche d'explications et les questions conceptuelles à un apprentissage plus solide, mais n'a pas prouvé que ces comportements en étaient la cause. Source : Shen et Tamkin, janvier 2026.

Cette expérience portait sur l’apprentissage d’une nouvelle bibliothèque. Elle ne mesure pas le même résultat que l’expérience de productivité en entreprise : leurs chiffres ne sont pas directement comparables.

Notre interprétation est que les entreprises devraient évaluer la compréhension en plus de la livraison. Un ticket complété ne nous dit pas si son auteur peut expliquer la solution ou enquêter sur son échec.

Les juniors doivent encore apprendre la programmation

L'IA ne supprime pas le besoin de comprendre le flux de contrôle, les données, les permissions, la concurrence, les tests et la gestion des échecs.

Imaginez qu'un assistant génère du code qui réessaie une demande de paiement après un délai d'expiration.

Le code compile. Le test du chemin nominal réussit. Mais le fournisseur de paiement pourrait avoir traité la transaction avant l'échec de la connexion. Réessayer pourrait facturer le client deux fois.

Pour reconnaître ce danger, un développeur doit raisonner sur l'incertitude : ce qui s'est passé à distance, ce que l'application locale sait et quelles actions peuvent être répétées en toute sécurité.

Taper chaque ligne personnellement n'est pas un prérequis pour cette compréhension. Pratiquer le raisonnement sur le code l'est.

Cette pratique devrait parfois inclure le travail sans IA. Le junior peut-il suivre l'exécution, expliquer un échec ou implémenter un petit morceau de logique de manière indépendante ?

Elle devrait également inclure le travail avec l'IA. Peuvent-ils remettre en question sa suggestion, identifier une hypothèse non testée et vérifier le résultat ? Les deux exercices révèlent quelque chose d'utile.

La revue de code partagée peut relier livraison et apprentissage

Réviser le code ensemble avec un senior est un moyen pratique de développer le jugement.

Le senior peut rendre son raisonnement visible :

• Qu'est-ce qui a attiré son attention ?
• Quelle hypothèse pourrait échouer ?
• Quelles seraient les conséquences ?
• Quelles preuves les mettraient à l'aise pour accepter la modification ?

Le junior devrait participer avant de recevoir la réponse.

Pour l'exemple du paiement, le senior pourrait demander : « Si la requête expire, savons-nous si le paiement a eu lieu ? »

Laissez le junior suivre cette question à travers le système. Ensuite, demandez-lui de reproduire la situation dangereuse dans un test et d'enquêter sur une solution.

Le résultat est une modification révisée, une démonstration concrète du risque et un principe qu'ils peuvent appliquer ailleurs.

La revue seule ne suffit pas

Il y a une limite à l'apprentissage par les explications : reconnaître un problème après que quelqu'un l'a identifié est plus facile que de le trouver soi-même.

Les juniors ont besoin d'opportunités pour formuler des hypothèses, prendre des décisions et découvrir où leur raisonnement se heurte à des limites.

Une petite fonctionnalité peut offrir cette expérience du début à la fin. Avec du soutien, un junior peut clarifier l'exigence, proposer une approche, la mettre en œuvre, répondre aux commentaires de revue et suivre son comportement après le déploiement.

La responsabilité doit croître au fur et à mesure que leur compétence se développe.

Nous devons également éviter d'assigner aux juniors un travail de vérification sans fin tout en réservant chaque décision de conception et investigation intéressante aux seniors. Cela peut aider à vider le backlog du jour, mais cela offre un chemin étroit vers l'autonomie.

Le mentorat nécessite un business case et du temps

Les employeurs sont en droit de demander ce que cette approche coûte.

Un junior a besoin de feedback. Les revues prennent du temps. Certaines tâches doivent être reprises. L'IA ne fait pas disparaître ces coûts.

La comparaison utile est la contribution de l'ensemble de l'équipe dans le temps : améliorations livrées, effort de mentorat, défauts, autonomie croissante et connaissances partagées entre les personnes.

Une approche pratique pourrait inclure :

• Un mentor désigné avec du temps protégé.
• Un ensemble initial de tâches utiles avec des conséquences gérables.
• Des revues partagées qui examinent le raisonnement ainsi que la justesse.
• Des opportunités régulières de déboguer et d'expliquer du code de manière autonome.
• Une responsabilité progressivement plus large à mesure que la compréhension s'améliore.

Les progrès doivent devenir visibles. Le junior identifie-t-il les risques plus tôt ? A-t-il besoin de moins d'aide pour un travail familier ? Peut-il expliquer ce qu'il a testé et ce qui reste incertain ? Devient-il fiable dans une partie de l'application ?

Il n'existe pas de calendrier universel. Il devrait y avoir une progression intentionnelle.

Si tout le monde n'engage que des seniors, d'où vient l'expérience ?

Une organisation peut raisonnablement avoir besoin de recruter une personne expérimentée pour un projet exigeant. Elle peut également manquer de capacité de mentorat à un moment particulier.

Mais une stratégie durable consistant à n'engager que des personnes expérimentées dépend du fait que d'autres employeurs continuent à les développer.

La séniorité se développe grâce aux opportunités de prendre des décisions, de rencontrer des conséquences et de recevoir du feedback. Supprimer ces opportunités tout en s'attendant à une offre illimitée d'ingénieurs expérimentés est une hypothèse fragile.

Développer des juniors donne également à une entreprise la possibilité de construire la connaissance du produit et de distribuer la responsabilité au sein de sa propre équipe. La rétention n'est jamais garantie, mais recruter des personnes expérimentées comporte également de l'incertitude.

La décision doit tenir compte à la fois des besoins de livraison immédiats et des capacités que l'organisation souhaite avoir dans plusieurs années.

L'opportunité est d'améliorer la façon dont nous développons les personnes

Chez HumanInTech, nous pensons que les entreprises doivent adopter l'IA tout en accordant une attention explicite à l’apprentissage des développeurs.

Les juniors peuvent apporter de la valeur par la mise en œuvre, l'investigation, la vérification et une compréhension croissante du business. Les collègues expérimentés peuvent aider cette contribution à croître en expliquant leur jugement et en créant des opportunités de le pratiquer.

La recherche nous donne des raisons de prendre au sérieux à la fois la productivité et l'apprentissage. Notre responsabilité est de traduire cela dans la façon dont nous organisons le travail.

Si nous voulons que les seniors de demain exercent un jugement sain, nous devons donner aux juniors d'aujourd'hui des opportunités de le développer.