Le même prompt, deux ingénieurs différents
L'an dernier, j'ai vu deux ingénieurs d'une même squad adopter Cursor au cours du même sprint. Les deux étaient productifs dès le premier jour. Les deux ont livré des pull requests qui avaient l'air propres. Mais l'une de ces PR a provoqué un incident trois semaines plus tard, et remonter jusqu'à la cause m'a appris plus sur les assistants IA que n'importe quel benchmark.
Le senior s'était servi de l'outil pour ébaucher une couche de cache, puis avait passé vingt minutes à la malmener. Il a écarté une dépendance qu'il ne sentait pas et ajouté le timeout que le modèle avait discrètement oublié. Le junior a utilisé le même outil, accepté ce qu'il produisait, et fusionné un code qui est passé en revue sans accroc parce qu'il se lisait comme l'œuvre de quelqu'un de compétent. Il se trouve simplement qu'il avait tort sur la façon dont notre session store gérait les écritures concurrentes.
Même assistant, résultats opposés. C'est précisément ce que la démo ne montre jamais.
Les sondages de GitHub situent l'adoption des outils d'IA par les développeurs au-delà de 80%, et la plupart des équipes que je croise tournent dans ces eaux-là. Ce qui frappe, c'est l'écart entre l'usage et la confiance. Les gens s'appuient sur Copilot et Cursor en permanence tout en gardant un sourcil levé, parce que l'expérience leur a montré exactement où ces outils fabriquent de l'assurance. Le gain est réel, mais il est emprunté sur le jugement de celui qui tient le volant.
Pourquoi l'expérience change ce que fait l'outil
Un senior lit du code généré comme un éditeur lit un premier jet : il cherche ce qui manque, ce qui est supposé, ce qui cassera en charge. Un junior le lit pour savoir s'il tourne. Les deux réflexes se défendent, mais un seul attrape le cas limite silencieux.
C'est cette partie qui m'inquiète. L'assistant ne fait pas la différence entre un code correct et un code seulement plausible, et le plausible, c'est sa spécialité. Confiez ça à quelqu'un qui ne sait pas encore distinguer les deux et vous ne lui avez pas offert un gain de productivité. Vous lui avez donné une façon très rapide de produire des erreurs qui ont l'air finies.
L'IA ne remplace pas le jugement. Elle augmente le prix de ne pas en avoir, car les mauvaises réponses arrivent désormais plus vite et mieux habillées que jamais.
C'est le même problème de compréhension que j'évoquais dans le nouveau visage de la dette technique : du code qui part en production avec l'air d'être complet tout en cachant ce que personne n'a réellement vérifié.
Le mentorat qui se jouait dans les interstices
Voici la perte que presque personne ne mesure. Les juniors apprenaient dans la pause, ce moment où ils bloquaient, demandaient de l'aide, et où un senior leur expliquait le pourquoi avant le comment. Cette pause, c'était l'endroit où se construisait la compréhension. L'IA la referme. Le code arrive maintenant déjà formé, et le moment d'enseignement qui vivait dans l'effort s'évapore tout simplement.
Une équipe qui ne le remarque pas continuera de livrer. Elle se remplira juste, lentement, de gens capables de produire un code qu'ils ne savent pas expliquer. Le chemin que je traçais dans d'ingénieur à product owner en devient plus précieux, pas moins : ce que l'IA ne sait toujours pas feindre (cadrer un problème, arbitrer, porter le résultat) est précisément ce que cette pause faisait grandir.
Il y a aussi un effet de second ordre plus vicieux. Les seniors qui relisent aujourd'hui la sortie de l'IA ont forgé leur jugement en s'arrachant les cheveux sur des problèmes que le modèle règle maintenant en quelques secondes. Si la promotion suivante saute cet effort, le vivier de gens capables de relire du code machine de façon critique se réduit au moment exact où son volume explose. Les équipes qui s'en sortiront reconstruiront la pause volontairement : sessions de lecture de code, revues de conception, et un simple « explique-moi pourquoi ça marche » avant toute fusion.
Arrêtez de le déployer de la même façon pour tout le monde
L'erreur la plus fréquente que je vois, c'est de traiter le déploiement comme uniforme. Une licence, un document d'onboarding, les mêmes attentes pour un ingénieur principal et pour quelqu'un sorti d'un bootcamp six mois plus tôt. Ce réglage ne sert bien ni l'un ni l'autre.
Les seniors ont surtout besoin de levier : contexte architectural et revue plus rapide du code humain comme machine. Maintenez-les rigoureux sur la revue de code(lien externe, nouvel onglet), comme s'ils relisaient la branche d'un collègue. Les juniors, eux, ont besoin de l'inverse : des garde-fous et l'obligation de se justifier. Dans mes équipes, la règle est simple. Si vous l'avez généré, vous le défendez avant la fusion, avec vos propres mots, en expliquant notamment pourquoi les cas limites sont couverts.
Rien de tout cela ne vise à ralentir qui que ce soit. La recherche DORA de Google(lien externe, nouvel onglet) retombe toujours sur le même constat : les outils aident quand ils soutiennent le flux et la qualité, et cessent d'aider dès qu'ils ne font que gonfler le volume. Plus de lignes fusionnées n'a jamais été l'objectif. C'est la même discipline qui sépare un vrai produit d'un tas de code généré dans le vibe coding ne sauvera pas votre produit.
Ce qu'il faut faire dès lundi
Traitez le binôme avec l'IA comme un amplificateur, pas un égalisateur. Il multiplie ce que vos ingénieurs apportent déjà, alors investissez dans ce qu'il ne sait pas fournir. Pour vos juniors en particulier, faites de l'explication le prix de la fusion. Vous ne freinez pas leur vélocité. Vous leur rendez la leçon que la pause disparue enseignait.
