L'IA rend-elle les développeurs moins bons ?

Un essai randomisé sur des développeurs chevronnés, 211 millions de lignes de code analysées : les études les plus sérieuses pointent dans la même direction. L'IA ralentit vos développeurs, alourdit leur code, émousse leurs réflexes. De quoi inquiéter n'importe quel dirigeant qui finance une équipe technique. Sauf que ces études ne mesurent pas vraiment « l'IA ». Elles mesurent une façon de s'en servir.

Je commence par un aveu, il rend la suite plus honnête. Quand une IA me sort du code qui marche, l'envie d'aller voir à l'intérieur s'évapore. Les tests passent, la fonctionnalité tourne, et la relecture devient une corvée. Je connais ce réflexe, je l'ai. C'est exactement là que les problèmes se logent. La seule question qui compte pour vous, dirigeant, c'est de savoir si votre équipe a de quoi y résister.

Ce que disent les chiffres

En 2025, le laboratoire indépendant METR a fait passer un test rare : un essai contrôlé randomisé, la méthode qu'on utilise pour évaluer un médicament, sur des développeurs open-source chevronnés travaillant sur leurs propres dépôts. Résultat à rebours des promesses : avec l'IA, ils ont mis 19 % de temps en plus. Le détail qui pique : interrogés après coup, ils étaient persuadés d'avoir gagné 20 %. Plus lents, et convaincus du contraire.

Côté qualité, GitClear a passé au crible 211 millions de lignes. La part de code refactorisé, celui qu'on réorganise pour le rendre réutilisable, est tombée de 25 % à moins de 10 %. Le copier-coller a grimpé, et les blocs d'au moins cinq lignes dupliquées ont été multipliés par huit sur la seule année 2024. Du code dupliqué, c'est autant d'endroits où un bug peut se cacher, et autant de corrections à refaire en dix exemplaires.

Côté comportement, une enquête Sonar auprès de plus de mille professionnels donne le ton : 96 % des développeurs ne font pas pleinement confiance au code généré par IA, mais 48 % seulement le vérifient systématiquement avant de le valider. Tout le monde sait qu'il faudrait relire. Un sur deux le fait.

L'image qui résume tout ça, c'est le GPS. Vous arrivez plus vite, sans effort. Et au bout de deux ans à suivre la flèche bleue, vous ne savez plus lire une carte. Le trajet se fait. La compétence s'efface.

Ces études ne mesurent pas « l'IA »

Regardez ce qu'elles testent vraiment : une manière de s'en servir, souvent un réflexe hérité de 2022 où l'on tape une demande, on colle la réponse, on passe à la suite. Le « vibe coding », où l'on confie tout à la machine sans lire ce qu'elle produit, en est la version extrême. Au premier trimestre 2025, les dirigeants de l'accélérateur Y Combinator estimaient qu'un quart de leur dernière promotion avait une base de code générée à 95 % par IA. Le problème n'est pas que la machine écrive. C'est que personne ne relit.

Et l'outil, lui, avance vite. Ce même laboratoire METR mesure que la durée des tâches qu'une IA mène seule, sans supervision, double environ tous les sept mois, avec une nette accélération sur 2024-2025. L'assistant qui calait sur une tâche d'une heure il y a dix-huit mois enchaîne aujourd'hui des chantiers de plusieurs heures. La capacité progresse donc à toute vitesse. Mais elle ne réglera pas le problème de fond, parce que le problème n'est pas un problème de capacité.

Capacité contre méthode

C'est le piège de presque tous les articles sur le sujet. Les uns crient à l'abrutissement, les autres répondent « attendez le prochain modèle ». Les deux confondent la capacité et la méthode.

Un meilleur modèle code plus juste, comprend mieux votre demande, se trompe moins. Mais la dette technique et l'érosion des compétences ne sont pas des défauts du modèle, ce sont des comportements humains. Et un modèle plus impressionnant rend la tentation de tout déléguer plus forte, pas plus faible. Le meilleur modèle du monde ne créera jamais la discipline de relire à votre place.

La preuve tient dans une étude qu'Anthropic a publiée début 2026 sur des développeurs juniors. Compréhension du code mesurée par test : 67 % pour ceux qui codaient sans IA, 50 % pour ceux qui l'utilisaient. Dix-sept points d'écart. Mais cette moyenne cache deux populations opposées. Ceux qui se servaient de l'IA pour comprendre, poser des questions, explorer un concept, dépassaient 65 %. Ceux qui lui déléguaient la génération sans réfléchir tombaient sous 40 %. Même outil, posture inverse, résultat inverse. Anthropic est juge et partie sur le sujet, mais le protocole reste un essai randomisé sérieux.

Les cinq règles que j'impose aux équipes qui utilisent l'IA

Ce qui sépare une équipe qui progresse d'une équipe qui s'atrophie, ce n'est pas le modèle qu'elle paie. C'est ce qu'on installe autour. Voici le cadre que je pose, à chaque fois :

1. Aucun code généré par IA n'arrive en production sans revue humaine.
2. Un développeur doit pouvoir expliquer ce qu'il valide. S'il ne sait pas, il ne valide pas.
3. Les décisions d'architecture restent humaines. L'IA propose, elle ne tranche pas.
4. Les tests sont obligatoires, pas négociables.
5. Les juniors se servent de l'IA pour comprendre avant de s'en servir pour générer.

Rien d'exotique là-dedans. Ce sont les fondamentaux que le rapport DORA de Google identifie comme la digue contre l'instabilité : petites livraisons, tests sérieux, revue de code. Ses éditions 2024 et 2025 le disent noir sur blanc : l'IA amplifie ce qui existe déjà. Les équipes solides accélèrent, les équipes fragiles voient leurs problèmes exploser à la vitesse où l'IA produit. J'ai vu des équipes doubler leur vitesse apparente et passer leurs week-ends à éteindre des incendies en production. La vitesse sans cadre, ce n'est pas de la vitesse. C'est de la dette à crédit.

La vraie question pour un dirigeant

« L'IA rend-elle mes développeurs moins bons ? » n'a pas de réponse utile. La bonne question : ai-je, dans mon entreprise, quelqu'un qui cadre la façon dont l'IA est utilisée ?

Ce cadre n'est pas une case à cocher dans un menu. C'est un rôle. Quelqu'un décide des standards, fait respecter la relecture, choisit où l'IA accélère et où elle devient trop risquée. Dans un grand groupe, c'est le travail d'une équipe. Dans une jeune pousse, c'est souvent ce qui manque le plus, et ce qui fait la différence entre une base de code qui tient trois ans et une qu'il faudra jeter.

C'est exactement le genre de diagnostic que je pose pour les équipes que j'accompagne : repérer où l'IA vous fait gagner du temps, où elle vous en coûtera demain, et installer le cadre qui transforme l'outil en levier plutôt qu'en dette.

Ce qu'il faut retenir

• Les études qui inquiètent sont réelles, mais elles mesurent surtout des habitudes d'usage, pas une fatalité de l'outil.
• Attendre un meilleur modèle ne réglera rien : la dette technique et la perte de compétence sont des problèmes de méthode.
• Le même outil fait progresser ceux qui s'en servent pour comprendre et atrophie ceux qui lui délèguent leur cerveau.
• La vraie variable, c'est le cadre. Et le cadre est un rôle, pas un réglage.

Questions fréquentes

L'IA rend-elle les développeurs paresseux ?

Pas par elle-même. Elle rend la paresse facile : quand le code produit fonctionne, l'effort de le comprendre paraît superflu. Les développeurs qui gardent une posture active, qui questionnent et relisent, progressent plus vite. C'est un choix d'usage, pas une fatalité de l'outil.

Faut-il interdire l'IA à mes développeurs juniors ?

L'interdire serait un handicap : c'est l'outil avec lequel ils travailleront toute leur carrière. La leur donner sans cadre, c'est risquer qu'ils n'acquièrent jamais les réflexes de base. Le bon dosage : qu'ils construisent d'abord leurs fondamentaux, puis qu'ils ajoutent l'IA comme amplificateur de ce qu'ils comprennent déjà.

Comment savoir si l'IA améliore vraiment la productivité de mon équipe ?

Méfiez-vous des impressions, y compris de celles de vos développeurs : l'étude METR montre qu'ils se croyaient plus rapides en étant plus lents. Regardez des signaux concrets : la stabilité de vos mises en production, la part de code repris ou corrigé juste après son écriture, le temps réellement passé en relecture. Si la vitesse affichée monte mais que les incidents suivent, vous accumulez de la dette, pas de la performance.

Conclusion

L'IA ne rend pas vos développeurs meilleurs ou moins bons. Elle révèle, en l'accélérant, ce que votre organisation savait déjà faire. Une équipe encadrée en sort décuplée, une équipe livrée à elle-même finit sous sa propre vitesse. La technologie a tranché la question de la capacité. Il vous reste l'autre, la seule qui dépend de vous : celle du cadre.

Si vous vous demandez où en est le vôtre, réservons 30 minutes pour en faire le diagnostic.