Ils codaient dix fois plus vite grâce à l'intelligence artificielle, et se retrouvent « cramés » dès 11 heures du matin. Parmi les développeurs les plus avancés dans l'usage des assistants génératifs, un mal d'un genre nouveau se répand : la « vibecoding fatigue », ou « AI brain fry » — un épuisement mental qui ne vient pas de trop écrire, mais de trop relire, valider et superviser un code qu'on n'a pas produit soi-même. Le phénomène reste, pour l'essentiel, une affaire de témoignages ; mais les premières études sur la charge cognitive lui donnent déjà des contours, et il pourrait déborder l'informatique pour gagner tous les métiers du langage.

Vibe coding, brain fry : de quoi parle-t-on ?

Le « vibe coding » désigne une manière de programmer apparue avec les assistants génératifs : plutôt que d'écrire chaque ligne, le développeur décrit en langage courant ce qu'il veut obtenir, et l'IA produit le code correspondant. Le terme a été popularisé début 2025 par le chercheur Andrej Karpathy, cofondateur d'OpenAI, pour qualifier un flux de travail où l'on « se laisse porter par l'ambiance » (vibes), en acceptant le code proposé sans forcément tout relire ni tout comprendre. Des outils comme GitHub Copilot, Cursor ou Claude Code ont banalisé cette pratique en quelques mois.

Le « brain fry » — littéralement « cerveau grillé » — en est le revers. Il décrit la surcharge cognitive éprouvée quand on n'a plus assez de mémoire de travail et d'attention pour piloter plusieurs agents d'IA à la fois. Contrairement au burn-out classique, qui s'installe sur des mois, ce brouillard mental est aigu et se manifeste par des difficultés de concentration, une prise de décision ralentie, parfois des maux de tête. Nuance importante relevée par les praticiens : le brain fry se dissipe souvent après une bonne nuit de sommeil, là où le burn-out, lui, ne se répare pas ainsi.

Le paradoxe : plus vite, mais plus épuisé

La singularité de cette fatigue, c'est qu'elle ne provient pas d'un excès de production. « C'est comme mettre votre bougie de productivité sur un lance-flammes : vous allez plus vite, mais vous brûlez beaucoup plus d'énergie », résume un ingénieur cité par The Conversation. Le développeur ne rédige plus : il valide en continu du travail produit par la machine. Or relire, comprendre et endosser la responsabilité d'un code qu'on n'a pas pensé soi-même mobilise une attention considérable — et prive du fameux « flow », cet état de concentration immersive que procurait l'écriture manuelle.

Plusieurs figures de la tech ont raconté publiquement leur épuisement. Simon Willison, développeur influent, confie sur le podcast de Lenny Rachitsky qu'il trouve « mentalement épuisant » de superviser quatre agents en parallèle et se sent souvent « lessivé » dès 11 heures du matin. « Il y a une limite à la cognition humaine, même si vous ne relisez pas tout ce que font les agents, sur ce que vous pouvez garder en tête en même temps », explique-t-il. Andrej Karpathy a de son côté évoqué des mois de pression psychologique intense, par peur de décrocher dans la maîtrise de ces outils. Garry Tan, patron de l'accélérateur Y Combinator, a raconté ne dormir que quatre heures par nuit en pilotant une dizaine d'agents ; et Quentin Rousseau, cofondateur de la start-up Rootly, décrit des mois d'insomnie et des pensées intrusives sur l'optimisation de son code : « Mon corps était au lit, mais mon esprit était encore dans le terminal », rapporte le média Built In.

Ce que disent (déjà) les études

Le phénomène relève d'abord du vécu, et il faut le dire clairement : on parle ici de récits d'ingénieurs, pas d'un diagnostic clinique établi. Quelques travaux commencent toutefois à mesurer la charge associée à l'IA au travail. Une étude du Boston Consulting Group, relayée par la Harvard Business Review et portant sur environ 1 500 salariés, observe que les personnes touchées par ce « brain fry » ont un tiers de risque en plus de souffrir de fatigue décisionnelle (+33 %), sont 39 % plus susceptibles de commettre une erreur grave affectant la sécurité ou les résultats, et 34 % d'entre elles cherchent activement à changer d'emploi. La même recherche note un seuil : la productivité progresse jusqu'au troisième agent piloté en parallèle, puis chute nettement au-delà de quatre. Une enquête de l'Upwork Institute évoquée par la même source rapporte que, parmi les employés les plus productifs grâce à l'IA, 88 % déclarent des signes d'épuisement.

À cela s'ajoute un paradoxe de perception mesuré par l'organisation à but non lucratif METR. Dans un essai contrôlé randomisé publié en juillet 2025, seize développeurs open source expérimentés ont réalisé 246 tâches réelles, tantôt avec, tantôt sans assistant d'IA (principalement Cursor Pro avec Claude 3.5 ou 3.7 Sonnet). Résultat : ils ont mis 19 % de temps en plus lorsqu'ils utilisaient l'IA — alors même qu'ils estimaient, après coup, avoir été 20 % plus rapides. Autrement dit, la sensation d'accélération peut être trompeuse, et une part de l'effort se déplace, invisible, vers la supervision. S'y greffe une « fatigue de la revue » : plusieurs équipes signalent une hausse de 40 à 60 % du volume de pull requests à relire, propice à des validations superficielles.

Les parades inventées par les devs

Faute de solution toute faite, les développeurs bricolent leurs propres garde-fous. Le terme « vibecoding fatigue » a d'ailleurs été forgé en août 2025 par Jorge Raad, ancien de Google, dans un billet où il détaille sa méthode de récupération. Trois stratégies reviennent, décrites par The Conversation.

La première consiste à cadrer en amont : rédiger soi-même, en langage clair, une spécification précise avant de lancer l'IA, pour l'empêcher de produire du code seulement « plausible ». La deuxième est la relecture profonde : « Je lis et comprends chaque ligne produite. Pas pour vérifier que ça marche, mais pour comprendre ce qui a changé », témoigne un vétéran de vingt ans de métier. La troisième relève de la fixation de limites : réserver à l'humain les décisions d'architecture, les tâches à haut risque (paiements, données médicales) et le travail réellement stimulant, en déléguant à la machine le reste.

Certains vont plus loin en rationnant carrément le temps de vibe coding. Le vétéran Steve Yegge, coauteur d'un ouvrage sur le sujet, avertit dans la newsletter The Pragmatic Engineer que les dirigeants ne devraient pas espérer plus de trois heures productives par jour d'un ingénieur qui « code à pleine vitesse » — quitte à ce que, pendant ces trois heures, il soit « cent fois plus productif que sans IA ». Il décrit un « effet vampirique » de l'outil, « qui vous excite, vous fait travailler très dur et capter énormément de valeur », mais épuise. Son conseil aux managers : autoriser explicitement ces trois heures maximales, « sinon votre entreprise va casser ». Côté organisation, la recherche du BCG note que le simple fait, pour un manager, de répondre aux questions sur l'IA fait baisser de 15 % le score de fatigue mentale.

Bientôt tous les métiers du langage ?

Ce que vivent les développeurs pourrait n'être qu'un signal avancé. La programmation a été le premier terrain d'usage massif de l'IA générative, mais la mécanique — produire vite un premier jet, puis passer l'essentiel de son énergie à le relire, le corriger et l'endosser — se retrouve partout où le travail consiste à manier le langage. Journalistes relisant des dépêches ébauchées par une IA, juristes vérifiant des contrats ou des mémoires générés, traducteurs révisant une post-édition automatique : tous risquent de basculer du rôle d'auteur à celui de superviseur permanent d'une machine. C'est l'hypothèse avancée par les sources qui documentent le phénomène : la « vibecoding fatigue » ne serait alors qu'un premier nom, technique, donné à une fatigue de la validation appelée à se généraliser à mesure que l'IA s'installe dans les métiers de l'esprit.