Dans le premier article de cette série, j'explorais comment l'IA fait monter la pyramide des rôles dans les deux sens. Le PO entre dans le code, l'architecte monte vers le business, et tout le monde se repositionne d'un niveau d'abstraction vers le haut.
Mais cette mécanique soulève un problème que personne ne sait vraiment résoudre : si l'IA fait ce que faisait le junior, comment forme-t-on les seniors de demain ?
Le junior sous pression
Le rôle traditionnel du dev junior — implémenter des features bien spécifiées, écrire du code répétitif, corriger des petits bugs — c'est exactement ce que l'IA fait bien. Très bien, même.
Ce n'est pas un détail. Parce que le dev junior, c'est aussi le pipeline qui forme les seniors de demain. Si on compresse ce rôle, comment est-ce qu'on forme la prochaine génération ?
Les données sont brutales. Entre 2022 et 2024, les offres d'emploi pour les juniors ont chuté de 60 à 67 %. L'emploi des développeurs de 22-25 ans a baissé de 20 %. Et 54 % des engineering leaders prévoient d'embaucher encore moins de juniors à cause de l'IA.
Charity Majors, CTO de Honeycomb, formule l'avertissement le mieux : "Le logiciel est une industrie d'apprentissage. On ne peut pas apprendre à être ingénieur logiciel en lisant des livres. On n'apprend qu'en faisant. Il faut un bon sept ans pour forger un ingénieur compétent." Et elle ajoute : "En n'embauchant pas et en ne formant pas de juniors, nous cannibalisons notre propre avenir."
Ce qu'on ne peut pas court-circuiter
Il y a quelque chose de fondamental dans la façon dont on acquiert l'expertise technique, et l'IA ne change pas ça.
Le modèle de Dreyfus décrit cinq stades d'acquisition de compétence : Novice → Débutant avancé → Compétent → Performant → Expert. La transition critique, celle qui fait vraiment la différence, c'est le passage de compétent à performant. À ce stade, il faut abandonner les règles explicites et laisser l'intuition prendre le relais. Ce "gut feeling" — savoir que quelque chose cloche avant même de savoir pourquoi — ne s'enseigne pas. Il se construit par l'expérience.
La recherche en sciences cognitives apporte une nuance supplémentaire avec le concept de difficultés désirables (Bjork, UCLA) : les obstacles à court terme renforcent l'apprentissage à long terme. Plus précisément, l'effet de génération montre que tenter de produire une réponse avant qu'on vous la donne améliore l'apprentissage — même si la tentative échoue.
Quand l'IA génère du code à la place du développeur, cet effet de génération disparaît. L'apprenant passe du mode actif au mode passif. Il reconnaît sans comprendre. Et l'étude randomisée d'Anthropic (2026) le confirme empiriquement : les développeurs assistés par l'IA obtiennent 17 points de pourcentage de moins aux tests de compréhension que ceux qui codent à la main.
Le problème spécifique de la review
Si l'IA fait la génération, ce qui compte c'est de savoir faire la review. C'est là que le jugement s'exprime. C'est là que l'expertise se voit.
Mais faire des reviews est déjà un exercice très difficile. Pour moi en tout cas. Et je trouve que cette difficulté est exacerbée avec l'IA, pour deux raisons : la quantité de code généré explose, et l'intention qui se cache derrière le code est encore moins lisible qu'avec du code humain.
Concrètement, je teste trois approches, et aucune ne me satisfait complètement.
La review semi-manuelle avec contexte complet — guidelines du projet, codebase et ticket en input. C'est la meilleure alternative que j'ai expérimentée. Moins d'effet boîte noire, le modèle comprend le contexte dans lequel s'inscrit le diff. Mais ça reste une assistance, pas une validation.
La review semi-manuelle avec diff seul — sans le ticket, sans les guidelines. Pas mal, mais l'effet boîte noire est prononcé. Il faut une confiance aveugle dans ce que l'IA sort, sans pouvoir vraiment vérifier la cohérence avec l'intention initiale.
La review manuelle — longue, laborieuse, mais elle permet d'assurer la qualité tout en progressant. C'est la seule approche qui m'apprend vraiment quelque chose.
La question que ça pose est vertigineuse : comment former quelqu'un efficacement à la review sans qu'il ait produit lui-même la moindre ligne de code ? Comment développer l'intuition de "ce qui cloche" sans avoir jamais souffert des conséquences de ses propres mauvaises décisions ?
Ce que dit la recherche sur l'apprentissage solo
Pas de senior à côté ? La recherche est nuancée, mais quelques pratiques émergent clairement.
Contribuer à l'open source reste le substitut de mentorat le plus efficace. Soumettre des pull requests à des projets populaires, c'est obtenir des revues de code de mainteneurs expérimentés — un mentorat fonctionnel et gratuit. L'objectif minimal : faire accepter au moins une PR dans un projet actif et internaliser le feedback reçu.
Utiliser l'IA différemment. L'étude d'Anthropic révèle quelque chose d'important : le mode d'interaction avec l'IA détermine si elle aide ou nuit à l'apprentissage. Les participants qui ont délégué à l'IA ont obtenu moins de 40 %. Ceux qui ont utilisé l'IA pour des questions conceptuelles tout en codant eux-mêmes ont obtenu plus de 65 %. La frontière est claire : l'IA qui fait à votre place nuit. L'IA qui explique ce que vous faites aide. Poser à l'IA "pourquoi ce pattern plutôt qu'un autre ?" plutôt que "génère-moi ce pattern" change tout.
Documenter les post-mortems. Après chaque bug de production ou décision qui a mal tourné, rédiger une courte analyse : qu'est-ce qui aurait dû alerter ? Qu'aurais-je fait différemment ? C'est douloureux, mais c'est probablement le meilleur enseignant quand on est seul. Et ça crée une mémoire externe qui aide à ne pas reproduire les mêmes erreurs.
Le paradoxe central
Le problème fondamental est une tragédie des communs. Chaque entreprise optimise rationnellement en embauchant des seniors plutôt que de former des juniors. Mais la somme de ces décisions individuelles détruit le pipeline collectif.
Kent Beck formule le risque à long terme avec ce qu'il appelle la programmation déflationniste : l'IA rend le code structurellement moins cher. La valeur migre. Elle se déplace vers la compréhension de quoi construire, vers comment les systèmes s'assemblent, vers la sagesse de savoir ce qu'il ne faut pas construire.
Et ces compétences-là, elles ne s'acquièrent pas en regardant l'IA générer du code.
La voie de sortie : préserver la friction productive
Il y a une chose qu'on risque de perdre et qu'on a du mal à nommer précisément. C'est cette intuition fine que les seniors développent après des années de pratique. Le sentiment que quelque chose ne va pas, avant même de savoir quoi. L'instinct qui dit "cet endroit va poser problème dans six mois".
Ce n'est pas de la magie. C'est de l'expérience accumulée, pattern après pattern, erreur après erreur. Et c'est exactement ce qu'on ne peut pas déléguer à l'IA.
L'analogie avec l'aviation est frappante. Après le crash d'Air France 447 en 2009 — des pilotes incapables de reprendre les commandes manuellement après le désengagement de l'automatisation — la FAA a recommandé plus de vol manuel. Pas moins de technologie. Plus de pratique de ce qu'on risque de perdre à force de le déléguer.
Le parallèle avec le développement est direct. L'IA est un excellent copilote. Mais si le développeur ne prend jamais les commandes lui-même, il perd la capacité de le faire quand ça compte vraiment — en production, à 2h du matin, quand l'IA ne comprend pas le contexte et que personne d'autre n'est là.
Il y a aussi ce que la recherche appelle le knowledge paradox : les seniors utilisent l'IA pour accélérer ce qu'ils savent déjà faire. Les juniors essaient de l'utiliser pour apprendre ce qu'ils ne savent pas encore. Ce n'est pas le même usage. Et confondre les deux est probablement l'erreur la plus répandue dans les équipes aujourd'hui.
La réponse n'est donc pas "IA ou pas IA". C'est une question d'intentionnalité. La friction productive — coder à la main quand on apprend, déboguer sans aide quand on peut se le permettre, produire avant de demander — doit être préservée délibérément. Pas par nostalgie. Parce que c'est là que l'intuition se construit.
L'IA ne supprime pas le besoin d'expertise. Elle rend l'expertise encore plus précieuse — et encore plus difficile à acquérir si on ne fait pas attention.
Dans le prochain article : pourquoi réduire les effectifs est un fantasme sans maîtrise préalable de la codebase — et ce que le vibe coding sans ownership coûte vraiment.
Cet article fait partie d'une série sur l'impact de l'IA dans les équipes tech.