Épuisement lié à l’IA : le coût caché du code rapide

L’IA peut réduire une tâche de programmation à quelques minutes, puis absorber le temps gagné en relecture, en vérification et en coordination. Le travail ne disparaît pas : il se déplace.

Du code plus rapide peut densifier la journée

Dire que l’IA rend chaque développeur dix fois plus rapide ne permet pas de piloter une équipe. Une tâche peut démarrer plus vite, tandis que l’équipe passe davantage de temps à contrôler le résultat, décider de ce qu’elle fusionne, l’expliquer aux autres et retrouver sa concentration après les interruptions. L’agenda subit le système entier, pas seulement le premier jet.

Je sépare donc les mesures, les corrélations, mon expérience et ce que j’en déduis. Les confondre produirait une histoire nette, mais fausse.

Une hausse visible du débit peut absorber la marge qui rendait le travail soutenable. Si seuls les tickets clos ou les demandes de fusion intégrées comptent, la capacité gagnée sera vite remplie. C’est une lecture des incitations, pas le résultat d’une étude isolée.

En 1865, William Jevons a observé une version de ce problème : lorsque les machines à vapeur utilisaient le charbon plus efficacement, la consommation de charbon augmentait, car ces machines devenaient plus utiles et plus répandues. L’analogie n’est pas une loi de management, mais elle alerte utilement. L’efficacité ne crée pas automatiquement du repos ; elle peut étendre la demande.

Mon observation est moins spectaculaire, mais plus utile : mon agenda est pire en 2026 qu’en 2024. Pas parce que taper du code est devenu plus difficile, mais parce que la journée contient désormais davantage de micro-décisions. Le paradoxe de Jevons suggère un mécanisme possible. Il ne prouve pas que mon expérience soit universelle.

Les données pointent vers la reprise et la capacité de relecture

Ces sources n’étudient ni les mêmes équipes, ni les mêmes outils, ni les mêmes résultats. Leurs chiffres ne s’additionnent pas. Ils indiquent toutefois où chercher le travail déplacé par une génération moins coûteuse.

Ce que les études citées ont mesuré sur la qualité

• GitClear a rapporté 5,7 % de taux de réécriture, contre 3,3 %, dans son analyse de 211 millions de lignes de code. Il s’agit de code rapidement réécrit ou supprimé. Cette comparaison décrit une évolution du code, elle ne prouve pas qu’un assistant explique chaque modification.
• CodeRabbit a signalé 1,7 fois plus de problèmes dans les demandes de fusion générées par IA que dans celles écrites par des humains. Ce résultat dépend de son échantillon et de sa méthode ; ce n’est pas un taux de défaut universel.
• Veracode a rapporté que 45 % du code généré par IA dans ses tests échouait à des contrôles de sécurité. La question utile n’est pas de savoir si ce pourcentage se transpose exactement à votre dépôt, mais si les changements générés reçoivent le même examen de sécurité que les autres.
• Dans son étude comparative, LinearB rapporte un taux d’acceptation de 32,7 % pour les demandes de fusion générées par IA, contre 84,4 % pour celles écrites manuellement. Un taux inférieur peut signaler davantage de reprises ; il ne mesure pas la qualité du code de toutes les équipes.

La file d’attente peut se déplacer vers la relecture

• Faros AI a mesuré un temps de revue supérieur de 91 % pour les demandes de fusion de son analyse.
• La même source rapporte des demandes de fusion 154 % plus volumineuses en moyenne. Une modification plus grande n’est pas nécessairement moins bonne, mais sa lecture exige davantage d’attention.
• Dans son étude, LinearB observe que les demandes de fusion générées par IA attendaient 4,6 fois plus longtemps avant le début de la revue.

Prises ensemble, ces corrélations proviennent de sources distinctes ; elles ne forment pas une expérience contrôlée. Elles décrivent néanmoins un mode de défaillance plausible : la génération accélère, tandis que la revue reste rare. Le goulot ne disparaît pas. Il se déplace vers les personnes qui doivent décider si une modification est sûre, cohérente et mérite d’être conservée.

Le travail caché est aussi cognitif

Les métriques de dépôt ne disent pas comment se termine la journée.

Je peux commencer ce qui semblait être un après-midi léger, puis lever les yeux à 19 heures et constater que je n’ai pas arrêté depuis 9 heures. Rien ne ressemble à un travail massif : quelques requêtes, des différences de code, des commentaires, de petites corrections et des réponses. Pourtant, je suis vidé. C’est mon expérience, pas une mesure.

Une étude mesure un effet voisin, dans un cadre plus étroit.

Zhang et al. ont étudié 58 étudiants en design sans formation en programmation pendant deux jours de programmation créative. Le groupe assisté par IA rapporte environ 16 % de charge mentale et 27 % de frustration supplémentaires sur le NASA-TLX. Ces déclarations de débutants ne prouvent pas le même effet chez des développeurs professionnels. Étude et méthode.

La charge a peut-être changé de forme : formuler, lire, tester, repérer une erreur subtile, puis basculer entre création et revue. Chaque geste paraît trop petit pour justifier une pause. Leur somme, elle, ne l’est pas.

L’attention fragmentée transforme la vitesse en coût

Cette estimation précède les assistants actuels, et je n’affirme pas que l’IA a créé les interruptions. Le scénario est familier : une suggestion de refactorisation vous détourne d’une implémentation, une grande demande de fusion attend sa revue, un collègue sollicite votre aide pour valider une sortie, tandis que les notifications continuent d’arriver. Rien n’est grave isolément. Ensemble, ces sollicitations morcellent le temps nécessaire au travail difficile.

Uplevel a rapporté une association entre 90 minutes de réunions fragmentées et plus de quatre heures de travail profond perdues. Ce résultat porte sur les réunions, pas sur l’IA. L’inférence est que les interruptions liées à la revue et à la vérification par IA doivent, elles aussi, compter dans la capacité d’une équipe.

Dans l’enquête Stack Overflow 2025, 66 % des répondants ont qualifié les solutions de l’IA de « presque justes » et 45 % ont déclaré que déboguer une sortie d’IA prenait plus de temps que d’écrire eux-mêmes le code. Ce sont des déclarations, pas des mesures causales. Elles expliquent néanmoins pourquoi la vérification doit avoir une place réelle dans un plan de livraison.

Les équipes peuvent perdre plus vite leur boucle de retour

Derrière les chiffres de débit existe un risque plus discret. Un ingénieur expérimenté qui accompagne une nouvelle recrue dans une architecture ne résout pas seulement le ticket du jour. Il explique pourquoi une frontière existe, quel compromis a déjà échoué et où se trouve le danger. Des premiers jets plus rapides peuvent réduire ces conversations si l’équipe les laisse disparaître.

Cela crée un risque pratique, pas un effet universel démontré : un junior peut terminer une tâche sans comprendre pourquoi le système est construit ainsi. L’équipe peut le limiter en maintenant les revues de conception, en demandant des explications pendant la revue et en exigeant que l’auteur sache toujours défendre un changement assisté par l’IA.

L’étude Harvard/BCG « Jagged Frontier » formule un point voisin avec plus de précision. Les participants étaient 25,1 % plus rapides et produisaient un travail de 40 % meilleure qualité pour les tâches à l’intérieur du domaine de compétence de l’IA. Pour les tâches hors de ce domaine, ils avaient 19 points de pourcentage de moins de chances de trouver la bonne réponse que les personnes sans IA. Ce n’est pas un argument contre l’assistance, mais pour apprendre à reconnaître quand il faut s’en méfier.

Ce que les études citées ont réellement mesuré

Mesurez le travail qui s’est déplacé

Ce n’est pas un plaidoyer contre l’IA. Je l’utilise tous les jours. Il faut cesser de considérer le temps gagné lors de la génération comme la preuve que tout le système dispose de plus de capacité. Une équipe doit voir la boucle entière : demande, génération, revue, vérification, reprise et récupération.

Si vous dirigez une équipe d’ingénierie, ne réduisez pas la productivité au nombre de demandes de fusion. Suivez le délai de revue, la taille des changements, le taux de réécriture, les défauts passés en production et la concentration du travail de relecture. Préservez délibérément une marge. Si le débit augmente sans capacité de revue supplémentaire, vous empruntez cette capacité aux personnes qui vérifient.

Si vous êtes développeur, comptez la formulation des demandes, le contrôle et les changements de contexte comme du travail. Préservez vos pauses et demandez des changements plus petits, donc révisables. Une sortie « presque juste » peut consommer plus d’attention qu’un fichier vide, surtout lorsqu’elle a l’air terminée.

À l’échelle d’une organisation, planifiez la capacité de revue, fixez un effort de vérification acceptable et traitez l’attention comme une contrainte de livraison. Une génération plus rapide ne dispense d’aucune de ces décisions.

Références

1. GitClear. (2025, fév). AI Copilot Code Quality: Evaluating 2024's Increased Defect Rate via Code Quality Metrics.
2. Coderabbit. (2025, 17 déc). State of AI vs Human Code Generation Report.
3. Veracode. (2025, 30 jul). 2025 GenAI Code Security Report.
4. Faros AI. (2025, 23 jul). The AI Productivity Paradox Research Report.
5. LinearB. (2026). 2026 Software Engineering Benchmarks Report.
6. Zhang, H., et al. (2025, 25 mai). The Neurophysiological Paradox of AI-Induced Frustration. PMC.
7. Shah, M. (2025, 30 sept). AI vs Time Tools: 5 Ways to Cut Developer Context Switching. AugmentCode.
8. Uplevel. (2025, 28 avr). How to Reduce Developer Interruptions (+ Increase Deep Work).
9. Stack Overflow. (2025). 2025 Developer Survey: AI tools, accuracy and developer frustrations.
10. Dell'Acqua, F., et al. (2023). Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. Harvard Business School et BCG.