La « vibecoding fatigue » : épuisés par l’IA, les développeurs informatiques inventent leurs propres parades

La vibecoding fatigue, ou AI brain fry, désigne une fatigue spécifique ressentie par les développeurs informatiques utilisant intensivement l’intelligence artificielle générative pour coder.

Le terme est popularisé en août 2025 par Jorge Raad, un ancien ingénieur de Google, qui décrit une lassitude née de la délégation excessive de tâches cognitives à des outils d’IA.

Cette fatigue se manifeste par un épuisement lié à la validation constante du travail produit par ces outils, qui génèrent du code rapidement mais nécessitent un contrôle humain permanent.

Un ingénieur cité dans l’article compare cette situation à « mettre ta bougie de productivité sur un lance-flammes : tu vas plus vite, mais tu brûles beaucoup plus d’énergie ».

Cette expression illustre l’idée que l’IA accélère le travail, mais au prix d’un effort mental intense et continu.

En 2024, une enquête de l’Upwork Research Institute menée auprès de 2 500 professionnels révèle que 77 % des utilisateurs d’IA estiment que ces outils ont alourdi leur charge de travail.

Un an plus tard, en 2025, une nouvelle étude montre que parmi les salariés les plus productifs grâce à l’IA, 88 % déclarent souffrir de burn-out.

Ces chiffres illustrent un paradoxe : l’IA, censée faciliter le travail, génère une pression accrue.

En mars 2026, une étude publiée dans le Harvard Business Review et menée sur 1 488 personnes confirme ces tendances.

Elle révèle une augmentation de 39 % des erreurs graves, de 33 % de la fatigue de décision, et une hausse de 9 points (de 25 % à 34 %) de l’envie de démissionner chez les utilisateurs intensifs d’IA.

Les chercheurs désignent les développeurs comme des « canaris dans la mine », car leur fatigue annonce celle d’autres métiers du langage.

Les modèles d’IA générative, comme ceux d’OpenAI, Anthropic, Google ou Microsoft, ont accordé une place centrale au code pour deux raisons principales.

D’abord, le code a un impact direct sur le monde réel : une seule ligne de code peut déclencher un calcul ou une action à distance.

Ensuite, le code est vérifiable : une erreur dans un programme se voit immédiatement et peut être corrigée, contrairement à une erreur dans un texte ou une phrase, qui reste souvent subjective.

Les concepteurs d’IA utilisent des tests comme le SWE-bench, qui soumet les modèles à des centaines de bugs réels extraits de logiciels publics.

Chaque modèle est évalué sur sa capacité à corriger ces bugs, ce qui permet de mesurer ses progrès.

Les développeurs, en tant qu’utilisateurs et constructeurs d’outils d’IA, sont équipés plus tôt et plus intensément que les autres métiers.

La vibecoding fatigue s’explique en partie par un phénomène décrit dès 1983 par l’ergonome Lisanne Bainbridge : les « ironies de l’automatisation ».

Lorsque les tâches simples sont confiées à la machine, il ne reste à l’humain que les tâches complexes, ainsi que la surveillance du système.

Les chercheurs Marie-Laure Cahier et Pierre Quesson ont observé ce phénomène dans le conseil.

Une médecin du travail citée dans leur travail explique que les tâches simples, autrefois des moments de repos pour le cerveau, disparaissent avec l’IA.

Il ne reste alors que des efforts continus, sans répit.

Un consultant compare l’IA à un « exosquelette mental » qui décuple les forces, mais dont l’utilisateur doit porter le poids une fois qu’il est retiré.

Les compétences s’usent aussi à force d’être sollicitées en continu, car l’IA prend en charge les gestes techniques, laissant à l’humain uniquement l’arbitrage et la coordination.

Face à cette fatigue, les développeurs inventent des parades pour reprendre le contrôle.

La première consiste à « faire un brouillon » : avant de lancer un outil d’IA, ils rédigent en mots simples ce qu’ils veulent obtenir.

Cela permet de fixer un cadre clair et d’éviter de prendre pour valide ce qui n’est que plausible.

La deuxième stratégie est de « se réapproprier le travail » : une fois le code produit par l’IA, les développeurs vérifient qu’ils pourraient le défendre sans notes, en comprenant chaque ligne.

Cette exigence ralentit le processus, mais elle est nécessaire pour maintenir leurs compétences.

Enfin, la troisième parade est de « refuser certaines tâches » : les développeurs tracent des lignes rouges, comme les choix d’architecture, les zones à risque (paiements, données médicales) ou les tâches qui donnent du sens à leur métier.

Ces refus relèvent du jugement professionnel et sont difficiles à codifier dans des règles strictes.

Les trois stratégies identifiées ont un point commun : elles réinstallent des freins que l’IA a supprimés, comme la réflexion préalable ou la vérification approfondie.

Pour les transmettre, les développeurs chevronnés observent où leurs pairs refusent d’utiliser l’IA.

Leurs refus indiquent ce qu’il faut encore maîtriser soi-même.

Cette approche repose sur l’apprentissage par l’exemple et l’imitation des pratiques des experts.

Elle suggère que la résistance à l’IA passe moins par des règles imposées que par l’acquisition de réflexes professionnels, transmis de manière informelle.

Cette dynamique pourrait s’étendre à d’autres métiers du langage, comme les journalistes ou les juristes, qui suivent les développeurs avec un temps de retard.