Vibecoding fatigue : on nous avait promis moins de travail, on a eu zéro pause

« Je passe la moitié de mon temps à dire à l'IA ce qu'elle ne doit pas faire. » La phrase vient d'un développeur interrogé par Morgan Blangeois, doctorant en sciences de gestion à l'université Clermont Auvergne, dans un article publié le 28 juillet sur The Conversation. Si tu codes depuis plus de cinq ans, tu viens probablement de hocher la tête devant ton écran.

On nous avait vendu un assistant. On a reçu un stagiaire increvable, très rapide, très sûr de lui, qui ne dort jamais et qu'il faut relire ligne par ligne. Ce n'est pas tout à fait le même contrat.

Le truc a un nom, maintenant

Le terme « vibecoding fatigue » a été popularisé en août 2025 par Jorge Raad, un ancien de Google. Le vibe coding consiste à décrire ce qu'on veut en langage courant, puis à laisser la machine produire le code. La fatigue qui va avec, elle, n'était pas dans la brochure.

En mars 2026, la Harvard Business Review a publié une étude menée auprès de 1 488 salariés américains par des chercheurs du Boston Consulting Group. Ils ont donné au phénomène un nom nettement moins élégant : « AI brain fry ». Le cerveau qui grille. La définition est précise : un épuisement cognitif provoqué par l'usage ou la surveillance de l'IA au-delà de ses propres capacités mentales. Les participants décrivent un brouillard, un bourdonnement ou la sensation d'avoir douze onglets de navigateur ouverts en même temps dans leur tête.

Les chiffres confirment le problème. Les personnes qui signalent ce brain fry ont environ 33 % de risque supplémentaire de souffrir de fatigue décisionnelle. Elles ont aussi 40 % de risque supplémentaire d'avoir activement envie de démissionner. Matthew Kropp, l'un des auteurs, précise que les ingénieurs qui pilotent plusieurs agents en parallèle sont les canaris dans la mine. Autrement dit, ils détectent le danger avant les autres. Être le canari, c'est flatteur pendant quatre secondes, jusqu'au moment où tu te souviens de ce qui lui arrive.

Le seul onglet grisé, c'est celui de ce que tu étais en train de faire avant.

Les chiffres, et ils ne sont pas beaux

L'Upwork Research Institute enfonce le même clou depuis deux ans. En 2024, 77 % des professionnels qui utilisaient l'IA estimaient qu'elle avait alourdi leur charge de travail. En 2025, après avoir interrogé 2 500 travailleurs dans quatre pays, le résultat est encore plus tordu. Parmi ceux qui gagnent le plus en productivité grâce à l'IA, 88 % se déclarent en burn-out. Ils sont aussi deux fois plus nombreux à envisager de partir. Cerise sur le gâteau, 62 % ne comprennent pas le rapport entre leur usage quotidien de l'IA et les objectifs de leur boîte.

Côté technique, le rapport DORA 2025 de Google dit la même chose avec d'autres mesures. Parmi les répondants, 90 % utilisent l'IA et plus de 80 % pensent qu'elle les rend plus productifs. Pourtant, 30 % n'ont aucune confiance, ou presque, dans le code qu'elle produit. Surtout, l'adoption de l'IA va de pair avec un rythme de livraison plus élevé, mais aussi avec davantage d'instabilité : plus d'échecs après un changement, plus de reprises et des incidents plus longs à résoudre.

Résumons. On livre plus vite, on casse plus souvent, on ne fait pas confiance à ce qu'on livre et on est cramés. Excellent trimestre.

L'ironie a quarante-trois ans

Ce mécanisme n'a rien de neuf. C'est bien ça le plus drôle. En 1983, Lisanne Bainbridge écrivait un texte devenu classique sur les « ironies de l'automatisation », à partir des cockpits d'avion et des salles de contrôle industrielles.

Son constat tient en deux temps. D'abord, l'automatisation prend les tâches faciles, celles qu'on peut décrire clairement. Il reste donc à l'humain les cas tordus, précisément ceux qui demandent le plus d'expérience. Ensuite, on lui demande de surveiller en permanence une machine alors qu'il ne pratique plus lui-même ces tâches. On lui retire l'entraînement et on lui laisse l'examen.

Le deal en une image. Tu as gagné le droit de ne faire que les parties difficiles.

Dans notre métier, le mécanisme est simple. Relire du code qu'on n'a pas écrit peut coûter plus cher que l'écrire. Il faut d'abord reconstituer l'intention, puis juger le résultat. Quand tu écris, tu prends une décision et tu la déroules. Quand tu relis, tu dois reprendre la décision à chaque ligne. Et, comme le note DORA, l'outil ne sait pas signaler ses propres doutes. Il débite une bêtise avec exactement le même aplomb qu'une bonne réponse. Impossible de trier rapidement. Tu dois tout ouvrir.

La promesse, c'était moins de travail. Le contrat réel, c'est zéro tâche répétitive et 100 % de décisions. C'est comme retirer les lignes droites d'un rallye, puis expliquer au pilote qu'on vient de lui faire gagner du temps.

Trois jours pour la démo, vingt-sept pour le reste

Le meilleur contrepoids chiffré que j'ai lu récemment vient de Luc Bonnin, qui a poussé l'expérience jusqu'au bout. Il a construit ClearSpot.me, une application web de géolocalisation qui repère les éoliennes. Il l'a créée entièrement avec l'IA, en 30 jours, sans écrire une seule ligne de code à la main.

La première version est sortie en 3 jours. Elle a demandé 105 prompts, c'est-à-dire 105 instructions données à l'IA, pour produire 80 782 lignes. Bluffant, vraiment. Puis il a fallu 27 jours supplémentaires pour obtenir une application réellement utilisable en production. Total : 1 117 prompts, 2,5 milliards de tokens (les morceaux de texte que le modèle lit, écrit et facture), et 206 347 lignes à l'arrivée. Surtout, 90 % des tokens ont été consommés après le POC, le prototype qui sert à vérifier que l'idée tient debout.

Trois façons de mesurer le même chantier. Les trois disent la même chose et aucune ne dit ce qu'on avait envie d'entendre.

Sa conclusion est nette : « Pareto s'applique parfaitement pour atteindre un POC ultra rapide, mais c'est un miroir aux alouettes si l'on veut vraiment atteindre une application prod-ready. » La base de données est passée de 40 Mo à 40 Go, et il a fallu écrire 40 algorithmes d'ingestion, c'est-à-dire des mécanismes chargés d'importer et de traiter les données. Puis le premier essai avec dix utilisateurs a révélé des problèmes de performance totalement invisibles pendant une démonstration en solo. Chez lui, dix personnes ont suffi pour faire un test de charge.

Le détail que tout le monde oublie, c'est que le résultat était de bonne qualité, avec des tests, de la documentation et une architecture claire, uniquement parce qu'un expert supervisait le processus en permanence. Zéro ligne écrite à la main ne veut pas dire zéro compétence requise. La compétence a simplement déménagé du clavier vers la relecture. Et personne n'a pensé à demander si c'était moins fatigant.

Ce que les vieux singes font déjà

La partie la plus utile de l'enquête de Blangeois, c'est qu'il ne distribue pas de conseils. Il décrit les solutions que les développeurs les plus expérimentés ont déjà trouvées tout seuls, sans attendre qu'on le leur demande. Il en ressort trois parades.

La première, c'est le brouillon. Avant d'ouvrir l'outil, on écrit avec des mots simples ce qu'on veut vraiment. « Tu installes l'IA en face de toi. Tu lui dis : on va travailler cette spécification. » Sans ce cadre, la machine produit quelque chose de plausible. Et le plausible est l'ennemi numéro un, parce qu'il ressemble beaucoup au juste.

La deuxième, c'est la réappropriation. Un développeur le formule très bien : « Je relis et je comprends chaque ligne produite. Pas pour vérifier que ça marche, pour comprendre. » Le test qu'ils s'imposent est simple : est-ce que je pourrais défendre cette ligne devant un collègue, sans notes ?

La troisième, c'est le refus. On trace des lignes rouges et on garde certaines tâches pour soi. C'est le cas des choix d'architecture qui engagent le système pendant des années. Même chose pour les zones à risque : les paiements, les données médicales ou les fichiers clients. Enfin, on garde les tâches qui donnent du sens au métier. Sinon, il ne reste plus grand-chose d'intéressant dans la journée.

Le scotch rouge sur le bureau n'est pas dans la documentation officielle de l'outil.

La phrase de Blangeois que je retiens est simple : regarder où les professionnels expérimentés refusent d'utiliser l'IA indique ce qu'il faut encore apprendre à maîtriser soi-même. C'est le meilleur conseil de carrière que j'ai lu cette année, et il tient en une ligne.

Le plus ironique, c'est que ces trois parades consistent à remettre à la main les freins que l'outil venait justement de retirer.

Le métier n'est pas mort, sa partie facile, si

Bonnin termine son expérience en citant Jevons, un économiste de 1865 : quand une ressource coûte moins cher à utiliser, on l'utilise davantage, pas moins. Si on produit plus de code, on crée plus de systèmes, plus de dépendances et plus de dette technique. Il faut donc plus de personnes pour maintenir l'ensemble debout. Vu comme ça, on ne va pas manquer de travail. C'est plutôt le contraire qui m'inquiète.

La vraie question ne me semble donc pas être « est-ce que je vais être remplacé ». Elle est plutôt : est-ce qu'on peut tenir trente ans avec des journées composées uniquement de décisions, d'arbitrages et de relecture ? Bainbridge n'y a pas répondu en 1983. Quarante-trois ans plus tard, on en est encore à découvrir le problème.