Vibecoding fatigue : pourquoi l'IA épuise les développeurs — et les parades que j'applique au quotidien

Un média grand public vient de mettre un nom sur quelque chose que je ressens depuis des mois. Le 28 juillet 2026, The Conversation publiait une analyse de Morgan Blangeois, doctorant en sciences de gestion à l’Université Clermont Auvergne, consacrée à ce que les développeurs appellent entre eux la « vibecoding fatigue » — ou « AI brain fry » : La « vibecoding fatigue » : épuisés par l’IA, les développeurs informatiques inventent leurs propres parades.

Je vais être direct : ça fait du bien. Pas parce que la fatigue serait agréable, mais parce qu’elle était jusqu’ici invisible et un peu honteuse. Difficile d’expliquer qu’on est épuisé par un outil censé faire le travail à votre place. Voir le sujet traité sérieusement, chiffres et cadre théorique à l’appui, change la conversation.

Ce que dit l’article — et pourquoi ce n’est pas un ressenti isolé

Les données citées ne laissent pas beaucoup de place au doute. Une étude de mars 2026, menée sur 1 488 personnes, mesure chez les utilisateurs intensifs d’IA une fatigue de décision en hausse d’un tiers, des erreurs graves en hausse de 39 %, et une intention de démissionner qui passe de 25 % à 34 %. Avant cela, l’Upwork Research Institute relevait déjà en 2024, sur 2 500 professionnels, que 77 % estimaient que l’IA avait alourdi leur charge de travail ; et en 2025, que 88 % des salariés les plus performants grâce à l’IA se déclaraient en situation de burn-out.

L’article rappelle aussi que le terme lui-même a été posé dès août 2025 par Jorge Raad, ancien ingénieur de Google, et il replace le phénomène dans une filiation plus ancienne : les « ironies de l’automatisation » décrites par l’ergonome Lisanne Bainbridge en 1983. Confier les tâches faciles à la machine ne libère pas l’humain ; ça lui laisse les tâches difficiles, plus la surveillance de la machine.

Enfin, Matthew Kropp y qualifie les développeurs de canaris dans la mine. La formule est juste : les métiers du langage — juristes, journalistes, traducteurs — vivront la même chose avec quelques années de décalage.

Pourquoi je m’y reconnais

Je travaille tous les jours avec des agents de code autonomes, et voici ce que ça produit concrètement.

L’IA va très vite. Elle donne la sensation de maîtriser énormément de choses. Elle permet d’abattre en quelques jours ce qui demandait à une équipe pluridisciplinaire des mois de travail commun — un designer, un développeur back, un développeur front, un intégrateur, des réunions, des allers-retours. Tout ça, compressé.

Le problème n’est pas là. Le problème, c’est que la responsabilité, elle, ne se compresse pas. Elle reste entière, au même endroit qu’avant : sur l’humain qui livre.

Dans le développement classique, le code s’écrit au rythme de la pensée : on construit le chemin logique en même temps qu’on tape. Avec un agent, une fonctionnalité arrive presque entièrement formée, un correctif est produit avant même qu’on ait fini de reconstruire mentalement le problème. Le résultat est souvent bon. Mais il exige une relecture dense, une compréhension à marche forcée. Multipliez par trois ou quatre agents en parallèle, chacun réclamant ses micro-décisions — je valide ? je corrige ? je jette ? — et vous obtenez une charge cognitive que le métier n’avait jamais connue sous cette forme.

Ce n’est pas un rejet de l’outil. C’est un décalage de vitesses.

La vraie compétence a changé de place

Voilà, je crois, le cœur du sujet. La vigilance du développeur consiste désormais à trancher là où son œil d’expert s’arrête.

L’agent produit un résultat cohérent, bien présenté, qui compile. L’œil expert, lui, accroche quelque part : un calcul qui ne tombe pas juste, une logique qui tient sur le papier mais pas sur les données réelles, un workflow qui ignore un cas métier que personne n’a écrit dans la spec. C’est exactement à cet endroit — au point d’accroche — que se joue la valeur du développeur. Pas dans la production du code, qui ne coûte presque plus rien, mais dans la décision de remettre en cause ce qui semble correct.

C’est aussi ce qui fatigue. Décider est bien plus coûteux que produire, et une journée d’agents, c’est une journée de décisions à la chaîne, sans les moments de respiration que donnait l’écriture du code.

Les parades décrites dans l’article

Morgan Blangeois en identifie trois, observées chez les développeurs eux-mêmes.

La première : rédiger d’abord en langage simple ce qu’on veut obtenir, avant de lancer l’outil — pour ne pas confondre ce qui sonne juste avec ce qui est juste. La deuxième : se réapproprier le résultat, c’est-à-dire relire chaque ligne pour comprendre ce qui a changé, et pas seulement pour vérifier que ça fonctionne. La troisième : refuser certaines tâches, en traçant des lignes rouges autour de l’architecture système, des zones à risque (paiements, données de santé) et de ce qui donne du sens au métier.

Les deux premières, je les pratique. La troisième, je la formule autrement — j’y reviens plus bas.

Ce que ça donne dans mon workflow

Mon organisation avec Claude Code s’est structurée autour de trois artefacts. En partie par conviction, en partie après m’être fait avoir.

Le brief avant l’agent. Chaque mission commence par un fichier BRIEF-*.md rédigé en amont : objectif, contraintes, points d’arbitrage explicitement marqués et tranchés avant que l’agent n’écrive une ligne. L’agent exécute ensuite en autonomie. Ce n’est pas de la lourdeur administrative, c’est le seul moyen de relire vite : quand la spec existe, la revue consiste à mesurer un écart entre l’attendu et le produit. Sans spec, la revue consiste à reconstruire l’intention en lisant du code qu’on n’a pas écrit. C’est cette seconde activité qui grille les cerveaux.

La revue humaine comme frontière non négociable. J’ai monté un mini PC dédié aux agents autonomes, accessible à distance. Aux premiers essais, un agent a poussé quatre commits directement sur main d’un projet en production — dont un durcissement d’authentification jamais testé. Résultat : login cassé en prod. La cause n’était pas l’IA, c’était moi : pas de règles Git écrites, pas de permissions restreintes, pas de garde-fou. Depuis, la règle est absolue : les agents proposent via des branches et des pull requests, l’humain relit et merge. L’agent ne touche jamais main.

Cette frontière fait plus que protéger la production. Elle transforme une fatigue diffuse — « tout surveiller, en permanence » — en un moment de vigilance délimité : la revue de PR. C’est ma version de la troisième parade. Plutôt que de refuser des tâches à l’IA, je refuse à l’IA le droit de conclure.

Accepter de jeter. Puisque le code ne coûte presque plus rien à produire, il ne coûte presque plus rien à abandonner. Avant, admettre qu’une approche était mauvaise signifiait sacrifier des heures d’effort chargées d’affect. Aujourd’hui, jeter une branche entière et repartir de la spec est souvent plus rapide — et surtout moins fatigant — que de rafistoler une génération partie de travers.

J’ajouterais une quatrième habitude, moins spectaculaire : garder des plages sans IA, sur des tâches que je sais faire. Pas par nostalgie. Parce que le risque n’est pas que l’IA code mal — c’est qu’on désapprenne à juger si elle code bien. Et le jour où l’œil d’expert ne s’arrête plus nulle part, il ne reste plus personne pour trancher.

Le canari chante pour tout le monde

Ce que vivent les développeurs aujourd’hui, les autres métiers du langage le vivront demain. Un juriste qui commande un projet de contrat, un journaliste qui demande une synthèse, un traducteur qui post-édite : même piège du plausible qui sonne juste, même relecture dense d’un texte qu’on n’a pas produit, même responsabilité finale qui ne se délègue pas.

Les parades se transposent telles quelles : écrire ce qu’on attend avant de demander, ne valider que ce qu’on saurait défendre sans notes, garder des moments où l’on fait soi-même.

L’IA générative ne remplace pas le jugement — elle en déplace le coût. Toute la question, pour les mois qui viennent, est d’organiser son travail pour que ce coût reste payable. Chez moi, ça tient en trois artefacts : un brief, une branche, une revue.