Vibecoding fatigue et « AI brain fry » : comprendre la nouvelle fatigue liée à l’IA

Qu’est-ce que la vibecoding fatigue ?

La vibecoding fatigue est une fatigue cognitive spécifique aux métiers qui utilisent intensivement l’IA générative. Elle se caractérise par une saturation mentale sans sentiment d’accomplissement, une difficulté à se remettre à travailler sans assistance, et une perte du fil de ce que l’on produit.

Le terme circule depuis 2025 dans les communautés de développeurs, souvent accompagné de son cousin plus imagé, l’AI brain fry, littéralement « cerveau grillé par l’IA ». Aucun des deux n’appartient au vocabulaire médical. Ce sont des expressions d’usage, nées de l’expérience avant d’être étudiées.

Ce qui les distingue du burn-out classique tient en une phrase : le burn-out vient d’une charge trop lourde portée trop longtemps, la vibecoding fatigue vient d’une charge qui a changé de nature.

 

Figure 1. Le déplacement de l’effort cognitif. L’assistance ne supprime pas l’effort mental, elle le fait passer de la production à la vérification. Schéma Emeric Lebreton / ORIENTACTION.

 

D’où vient le terme « vibe coding » ?

Le 6 février 2025, Andrej Karpathy, cofondateur d’OpenAI et ancien directeur de l’IA chez Tesla, publie sur X une description d’une nouvelle façon de programmer : parler à un modèle, accepter ses propositions sans les relire, avancer aux sensations. Ses mots : « je m’abandonne complètement aux vibes, j’embrasse les exponentielles, et j’oublie jusqu’à l’existence du code ».

L’expression vibe coding est reprise dans le monde entier en quelques semaines. En novembre 2025, le dictionnaire Collins en fait son mot de l’année. Un point de vocabulaire mérite d’être posé, parce qu’il conditionne tout le reste.

Le développeur Simon Willison a défendu tout au long de 2025 une distinction devenue centrale : si un modèle a écrit chaque ligne de votre code mais que vous l’avez relue, testée et comprise, ce n’est pas du vibe coding, c’est de la programmation assistée. Le vibe coding suppose précisément de ne pas regarder. Confondre les deux revient à donner le même nom à une pratique de loisir et à un métier.

Que dit la recherche sur la fatigue liée à l’IA ?

Cinq travaux publiés entre 2024 et 2025 permettent aujourd’hui de sortir de l’impression subjective.

L’étude du MIT sur la « dette cognitive »

En juin 2025, une équipe du MIT Media Lab menée par Nataliya Kosmyna publie un preprint intitulé Your Brain on ChatGPT. Cinquante-quatre participants sont répartis en trois groupes pour écrire des essais : avec ChatGPT, avec un moteur de recherche, ou sans aide. L’activité cérébrale est mesurée par EEG.

Le groupe assisté par le modèle de langage présente la connectivité neuronale la plus faible des trois. Plus frappant encore, une large majorité de ses participants se révèle incapable de citer une phrase de son propre texte quelques minutes après l’avoir rendu. Les auteurs proposent le concept de dette cognitive : un gain de temps immédiat, remboursé plus tard sous la forme d’un modèle mental qui n’a jamais été construit.

Deux réserves, que les auteurs eux-mêmes ont dû rappeler publiquement tant leur travail a été surinterprété : l’étude porte sur l’écriture d’essais et non sur le code, et il s’agit d’un preprint non validé par les pairs sur un échantillon modeste. Elle ne dit pas que « ChatGPT rend bête ».

L’étude Microsoft et Carnegie Mellon sur la pensée critique

Présentée à la conférence CHI 2025, l’étude de Lee et ses collègues interroge 319 travailleurs du savoir sur 936 situations concrètes d’usage.

Son résultat central : plus la confiance dans l’outil est élevée, moins l’utilisateur engage d’effort de pensée critique. Mais l’effort ne disparaît pas, il se déplace. On passe de la production à la vérification, de la création à la supervision. C’est probablement là que se joue l’essentiel de la fatigue ressentie. Écrire est engageant. Relire ne l’est pas.

L’étude METR sur l’écart entre vitesse perçue et vitesse réelle

En juillet 2025, l’organisation d’évaluation indépendante METR publie un résultat contre-intuitif. Seize développeurs open source expérimentés réalisent 246 tâches réelles sur des dépôts qu’ils connaissent bien, la moitié avec assistance IA, l’autre sans. Ils s’estiment environ 20 % plus rapides avec l’IA. Les mesures montrent qu’ils ont été 19 % plus lents.

L’échantillon est petit et les auteurs se gardent d’en tirer une loi générale. Mais l’écart entre le ressenti et la mesure est en soi le résultat intéressant : la fluidité de l’interaction produit une impression de vitesse que le travail réel ne valide pas. On se sent efficace, et on est fatigué.

L’enquête Stack Overflow sur le coût du « presque juste »

L’édition 2025 de l’enquête annuelle Stack Overflow auprès des développeurs montre une adoption massive de l’IA, une confiance en recul d’une année sur l’autre, et une frustration numéro un très précise : des solutions presque justes, mais pas tout à fait.

Le point est technique et ses conséquences sont psychologiques. Une réponse franchement fausse se repère et se jette. Une réponse à 95 % juste se lit, se teste, se débogue, et coûte souvent plus cher qu’une page blanche. Elle mobilise une attention soutenue sans jamais offrir la satisfaction de la résolution.

Les données sur la qualité du code et le « workslop »

Les analyses de GitClear, portant sur plusieurs dizaines de millions de lignes, montrent une progression du code dupliqué et un recul des opérations de refactorisation, celles-là mêmes qui maintiennent une base de code habitable dans la durée.

Les rapports DORA de Google Cloud observent de leur côté que l’adoption de l’IA s’accompagne de gains de vitesse individuels mais exerce une pression sur la stabilité de livraison quand les pratiques d’ingénierie ne suivent pas.

Le phénomène dépasse largement le code. En septembre 2025, la Harvard Business Review publie une enquête du Stanford Social Media Lab et de BetterUp Labs qui popularise le terme workslop : un contenu généré par IA qui a toutes les apparences de la qualité sans en avoir la substance.

Environ 40 % des salariés interrogés déclarent en avoir reçu, et le temps moyen passé à rattraper chaque occurrence approche les deux heures. Le mécanisme est identique à celui du code : le coût de production s’effondre, le coût de vérification reste entier, et il se déplace vers celui qui reçoit.

Récapitulatif des travaux disponibles

Travail	Date	Méthode	Résultat principal
MIT Media Lab, Your Brain on ChatGPT	Juin 2025	EEG, 54 participants, essais écrits	Connectivité neuronale la plus faible dans le groupe LLM ; incapacité à citer son propre texte ; notion de dette cognitive
Microsoft Research et CMU (CHI 2025)	2025	319 travailleurs, 936 situations	La confiance dans l’outil réduit l’effort critique ; l’effort se déplace vers la vérification
METR	Juillet 2025	16 développeurs	246 tâches réelles 19 % plus lents avec l’IA, alors qu’ils se croyaient 20 % plus rapides
Stack Overflow Developer Survey	2025	Enquête à grande échelle	Adoption massive, confiance en baisse, frustration n°1 : les réponses « presque justes »
GitClear et DORA	2024-2025	Analyse de dépôts et enquêtes	Hausse de la duplication, recul du refactoring, pression sur la stabilité de livraison
Stanford Social Media Lab et BetterUp (HBR)	Septembre 2025	Enquête salariés	40 % ont reçu du « workslop » ; près de 2 h perdues par occurrence

 

Pourquoi cette fatigue est-elle différente d’un burn-out classique ?

Quatre mécanismes se combinent. Aucun n’est propre à l’IA, et c’est justement leur accumulation dans une même journée qui est nouvelle.

Le passage de producteur à relecteur. Écrire mobilise une boucle simple : intention, action, résultat. Relire mobilise un contrôle exécutif coûteux, sans récompense équivalente. Une équipe qui génère cinq fois plus de code produit cinq fois plus de charge de revue, et la revue est la partie du métier que personne n’a jamais trouvée reposante.

La vigilance passive. Les facteurs humains connaissent ce problème depuis quarante ans dans l’aviation. Les travaux de Raja Parasuraman et Victor Riley sur l’usage et le mésusage de l’automatisation (1997), ceux de Mica Endsley sur le out-of-the-loop performance problem, décrivent exactement cette configuration : un opérateur retiré de la boucle d’action mais tenu responsable du résultat perd sa conscience de la situation, développe une complaisance envers le système, et se fatigue davantage qu’en pilotant lui-même. Superviser un agent qui écrit du code place le développeur dans cette position.

La rupture du flow. L’état de concentration profonde décrit par Mihály Csíkszentmihályi suppose une boucle serrée entre l’action et son retour. Attendre vingt secondes qu’un agent termine, lire, corriger, relancer : ce rythme ne permet plus l’immersion. On travaille beaucoup, on ne rentre jamais.

La dette cognitive au sens propre. Si le modèle mental du système n’a pas été construit, chaque retour dans le code recommence à zéro. La fatigue n’est plus seulement celle de la journée, elle devient celle de tous les jours précédents dont rien n’a été capitalisé.

Quels sont les signes rapportés ?

Ces signes proviennent de descriptions publiques récurrentes dans le secteur, pas d’une échelle validée. Ils n’ont aucune valeur diagnostique. Une fatigue mentale en fin de journée sans souvenir précis de ce qui a été produit.

• La sensation de superviser en permanence sans jamais construire.
• Une difficulté croissante à démarrer une tâche sans assistance.
• L’ennui et l’épuisement combinés, ce qui est rare et déroutant.
• Le sentiment que le code livré fonctionne mais qu’on ne saurait pas l’expliquer.

 

Si ces signes s’accompagnent de troubles du sommeil, d’un désinvestissement durable ou d’une souffrance qui déborde le cadre professionnel, la question n’est plus celle de l’outil et un professionnel de santé, ou la médecine du travail, reste le bon interlocuteur.

Ce que disent les praticiens

Une précision d’honnêteté s’impose ici. Les éléments ci-dessous sont des prises de position publiques, vérifiables. Ce ne sont pas des témoignages anonymes recueillis sur les forums, et ils ne doivent pas être présentés comme tels.

Andrej Karpathy, qui a inventé le terme, a nuancé sa position au fil de 2025. Dans plusieurs interventions publiques de l’automne, il décrit son propre usage des agents de codage comme décevant sur du travail sérieux, et explique préférer, pour ses projets exigeants, une assistance plus proche de l’autocomplétion, où il garde la main sur chaque décision. Le vibe coding, dans sa bouche, a toujours désigné des projets de week-end jetables.

Simon Willison maintient la ligne de partage rappelée plus haut : relire et comprendre, ce n’est plus du vibe coding.

L’enquête Stack Overflow 2025 fournit le témoignage collectif le plus solide disponible à ce jour : la principale plainte des développeurs n’est pas que l’IA se trompe, c’est qu’elle a presque raison.

Trois configurations reviennent par ailleurs avec insistance dans les discussions publiques du secteur. Elles sont présentées ici comme des synthèses, pas comme des citations.

• La première est celle du développeur expérimenté qui a cessé d’écrire du code et passe ses journées à en évaluer. Il livre davantage, il s’ennuie plus, et il ne saurait pas expliquer pourquoi il rentre chez lui vidé.
• La deuxième est celle du prototype réussi devenu ingérable. L’application a été montée en un week-end, elle fonctionne, elle a des utilisateurs, et personne, y compris son auteur, ne comprend plus comment elle marche. La dette n’est pas technique, elle est cognitive.
• La troisième est celle du décrochage silencieux de la compétence, après plusieurs mois d’usage intensif. Rien ne prouve à ce stade qu’il s’agisse d’une perte réelle plutôt que d’une perte d’habitude, et c’est précisément ce que les études longitudinales devront trancher.

 

Comment réduire la vibecoding fatigue ?

Aucune de ces pistes n’a fait l’objet d’un essai contrôlé. Elles découlent de ce que la recherche établit sur les mécanismes, pas d’une efficacité démontrée sur la fatigue elle-même.

1. Séparer explicitement deux régimes de travail.

D’un côté les zones où le vibe coding est légitime : prototype jetable, script personnel, exploration d’une bibliothèque inconnue. De l’autre celles où il ne l’est pas : données, sécurité, authentification, et plus largement tout code destiné à vivre plusieurs années. La règle tient en une ligne : ce que je devrai maintenir, je dois le comprendre.

 

Figure 2. Où le vibe coding est légitime, et où il ne l’est pas. Deux questions suffisent à trancher : ce code va-t-il vivre, et que se passe-t-il s’il est faux ? Schéma Emeric Lebreton / ORIENTACTION.

 

2. Restaurer la boucle courte.

De petits incréments testés au fur et à mesure, plutôt que des générations massives suivies d’une session de débogage. La boucle courte protège le flow et rend la revue supportable.

3. Traiter la revue comme du travail.

Elle doit apparaître dans les estimations, dans les rituels d’équipe, dans la charge de chacun. Une équipe qui multiplie sa production sans budgéter la vérification fabrique du workslop à l’échelle industrielle.

4. Entretenir la compétence délibérément.

Un exercice court par jour écrit à la main, sans assistance. C’est le principe du calcul mental à l’époque de la calculatrice : l’outil reste, mais on garde la capacité de juger si son résultat est plausible.

5. Ménager des plages sans génération.

Pas seulement des pauses, des plages de travail réellement non assisté. Le cerveau ne se repose pas d’une supervision continue en changeant d’écran.

6. Écrire l’intention avant de lancer la génération.

Deux lignes qui décrivent ce que le code doit faire suffisent à reconstruire le modèle mental que l’assistance a tendance à court-circuiter.

7. Pour les responsables d’équipe : mesurer la valeur livrée, jamais le volume produit.

Un indicateur fondé sur le nombre de lignes ou de tickets fermés ne mesure plus rien à l’ère des agents. Il encourage exactement le comportement qui produit la fatigue et la dette.

Ce que la recherche ne sait pas encore

Le sujet se prête à l’emballement dans les deux sens, il faut donc dire clairement où s’arrêtent les données.

Aucune étude longitudinale n’existe sur les effets d’un usage intensif prolongé. Le travail du MIT porte sur quatre sessions, pas sur quatre ans. On ignore si la dette cognitive se rembourse spontanément dès qu’on repasse en mode manuel, ou si elle laisse des traces. On ne sait pas non plus démêler ce qui relève d’un effet propre à l’IA de ce qui relève d’une transition professionnelle brutale, avec son incertitude sur l’avenir du métier. Or l’incertitude fatigue autant que la charge.

Il faut ajouter que ce vécu n’est pas universel. Une partie des praticiens, et non des moindres, décrit au contraire un regain de plaisir : des idées testables en une heure, des barrières techniques levées, un retour à la conception plutôt qu’à la plomberie. Les deux expériences coexistent, et la différence tient sans doute moins à l’outil qu’à la manière dont chacun a redessiné son rôle autour de lui.

Ce qui est établi tient en peu de mots. L’IA générative n’a pas supprimé l’effort mental, elle l’a déplacé vers la vérification. La vérification est plus coûteuse et moins gratifiante que la production. Et l’impression de vitesse qu’elle procure n’est pas un indicateur fiable de l’efficacité réelle.

La vibecoding fatigue n’est pas une maladie. C’est le nom provisoire d’un ajustement en cours entre un métier et un outil qui l’a transformé plus vite que ses pratiques.

Questions fréquentes

La vibecoding fatigue est-elle reconnue médicalement ?

Non. Ni « vibecoding fatigue » ni « AI brain fry » ne figurent dans une classification médicale. Ce sont des expressions d’usage qui décrivent un vécu partagé, pas des diagnostics. La recherche documente les mécanismes sous-jacents, pas un syndrome constitué.

L’intelligence artificielle fait-elle vraiment perdre des compétences ?

Les données disponibles montrent une baisse de l’engagement cognitif pendant l’usage, pas une perte de compétence démontrée dans la durée. L’étude du MIT observe une rétention plus faible de ce qui a été produit avec assistance. Aucune étude longitudinale ne permet aujourd’hui de dire si l’effet persiste ou s’il se dissipe dès le retour à un travail non assisté.

Quelle est la différence entre le vibe coding et la programmation assistée par IA ?

Le vibe coding consiste à accepter le code généré sans le relire ni chercher à le comprendre. La programmation assistée suppose au contraire une relecture, des tests et une compréhension du résultat. Les deux pratiques utilisent les mêmes outils mais n’ont ni le même usage légitime ni les mêmes risques.

Le vibe coding est-il dangereux en production ?

Il l’est dès que le code doit être maintenu, sécurisé ou audité. Les données de GitClear montrent une hausse de la duplication et un recul du refactoring, deux indicateurs de dette technique. La pratique reste pertinente pour les prototypes jetables et les scripts personnels.

Pourquoi suis-je fatigué alors que je produis plus qu’avant ?

Parce que l’effort a changé de nature. Vous êtes passé de la production à la vérification, une activité plus coûteuse en attention et moins gratifiante. L’étude METR montre par ailleurs que l’impression d’être plus rapide avec l’IA ne correspond pas toujours à la réalité mesurée.

Que peut faire un manager pour limiter le phénomène dans son équipe ?

Deux choses en priorité : compter la revue de code comme du travail réel dans les estimations, et cesser de piloter la performance au volume produit. Un indicateur fondé sur le nombre de lignes ou de tickets fermés récompense exactement le comportement qui fabrique de la fatigue et de la dette.

Sources

• Karpathy, A. (6 février 2025). Publication sur X introduisant le terme vibe coding.
• Collins Dictionary (novembre 2025). Word of the Year 2025 : « vibe coding ».
• Kosmyna, N. et al. (juin 2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. Preprint arXiv, MIT Media Lab.
• Lee, H.-P. et al. (2025). The Impact of Generative AI on Critical Thinking. Microsoft Research et Carnegie Mellon University, actes de la conférence CHI 2025.
• METR (juillet 2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.
• Stack Overflow (2025). Developer Survey 2025, section IA.
• GitClear. AI Copilot Code Quality, rapports 2024 et 2025.
• Google Cloud / DORA. State of DevOps Report, éditions 2024 et 2025.
• Stanford Social Media Lab et BetterUp Labs (septembre 2025). Enquête sur le workslop, Harvard Business Review.
• Willison, S. (mars 2025). Not all AI-assisted programming is vibe coding, simonwillison.net.
• Parasuraman, R. et Riley, V. (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2).
• Endsley, M. R. Travaux sur la conscience de la situation et le out-of-the-loop performance problem.