Il y a une image, dans l'article publié par The Conversation, dont on ne se débarrasse pas facilement. Elle vient d'un ingénieur qui raconte deux mois à sept heures de code par jour, presque sans week-ends :
« C'est comme mettre ta bougie de productivité sur un lance-flammes ; tu vas plus vite, mais tu brûles beaucoup plus d'énergie. »
Le texte donne un nom à ce malaise — vibecoding fatigue, ou AI brain fry — et rassemble ce qui commençait à circuler par morceaux : les fils de discussion de praticiens, les enquêtes de l'Upwork Research Institute, une étude publiée en mars 2026 sur près de 1 500 personnes. Les chiffres qu'il rapporte sont sévères : un tiers de fatigue de décision en plus, davantage d'erreurs graves, une envie de démissionner qui grimpe.
Ce n'est pas un article anti-IA, et cette réaction n'en est pas une non plus. C'est même l'inverse : le sujet mérite d'être pris au sérieux parce que ces outils fonctionnent.
Une fatigue qui vient du bon côté de la barrière
Le détail le plus important est facile à manquer. Les personnes concernées ne sont pas celles qui subissent l'IA ou qui la refusent. Ce sont les plus avancées : celles qui pilotent déjà plusieurs systèmes à la fois. L'article reprend l'expression de Matthew Kropp, « le canari dans la mine » — des sentinelles dont la fatigue annonce celle des autres métiers.
Autrement dit, cette fatigue n'est pas un signal d'échec de l'adoption. C'est un signal de maturité de l'adoption, et il ressemble beaucoup à d'autres qu'on a déjà croisés. Quand Uber a consommé son budget IA annuel en quatre mois, ce n'était pas parce que l'outil décevait — c'était parce qu'il marchait, et qu'il manquait la couche de pilotage autour. Ici, la ressource épuisée n'est pas un budget en dollars. C'est l'attention d'une équipe. Ça se pilote aussi, et c'est autrement plus précieux.
L'ironie de l'automatisation, quarante-trois ans plus tard
L'explication proposée par l'article est la plus solide qu'on ait lue sur le sujet, et elle est ancienne. En 1983, l'ergonome Lisanne Bainbridge décrivait les « ironies de l'automatisation » : quand on confie les tâches faciles à la machine, il ne reste à l'humain que les plus difficiles — plus la surveillance de l'ensemble.
La formulation la plus juste vient d'une médecin du travail citée dans le texte : les tâches simples étaient des moments de repos pour le cerveau. Quand la machine s'en charge, il ne reste que l'effort, sans répit. On a cru supprimer du travail pénible ; on a surtout supprimé les pauses.
Et c'est là que ça nous concerne directement. Le travail qui reste — arbitrer, cadrer, vérifier, coordonner — est exactement celui que nous outillons. Nous n'avons donc pas le droit de le traiter comme un supplément gratuit que l'humain absorberait naturellement. C'est devenu le travail, et il a un coût cognitif qu'il faut regarder en face.
Les trois parades décrivent un poste de pilotage
La dernière partie de l'article recense trois garde-fous que les développeurs les plus en pointe se sont inventés. En les lisant, difficile de ne pas sursauter : ce sont, une par une, les trois briques sur lesquelles nous construisons Survol. Sauf qu'eux les tiennent à la seule force du poignet.
1. Faire un brouillon — c'est-à-dire écrire la spec
Avant de lancer l'outil, ils écrivent en mots simples ce qu'ils veulent obtenir. L'article cite un développeur :
« Tu installes l'IA en face de toi. Tu lui dis : on va travailler cette spécification fonctionnelle. Je donne l'idée, tu poses les questions, et tu rédiges. »
C'est notre principe fondateur, formulé par quelqu'un qui l'a redécouvert par épuisement : la spec validée EST le prompt. La raison invoquée dans l'article est excellente — sans cadre fixé à l'avance, « on prend le plausible pour du juste ».
Mais notez ce que cette parade coûte à celui qui la pratique : il doit y penser, à chaque fois, contre la facilité d'ouvrir directement une session. Quand la spec est le point d'entrée de l'outil et non un effort de volonté, le garde-fou cesse d'être une discipline pour devenir le chemin normal.
2. Se réapproprier le travail — c'est-à-dire structurer la revue
Deuxième parade : ne pas se contenter d'un « ça marche ». Un développeur de vingt ans d'expérience explique qu'il relit et comprend chaque ligne produite, « pas pour vérifier que ça marche, pour comprendre ce qui a changé ».
Sur le fond, il a raison. Mais l'article ajoute, très honnêtement, que ce ralentissement « a un coût » — et c'est le cœur du problème. Relire ligne à ligne tout ce qu'un agent produit est une stratégie qui ne survit pas au volume : c'est précisément la définition du burn-out décrit plus haut. Une étude de Faros AI sur plus de 10 000 développeurs pointe le même goulot : beaucoup plus de demandes de fusion, et un temps de revue qui explose.
Notre parti pris n'est pas de relire moins, c'est de diriger l'attention. Une préview à valider par version plutôt qu'un flux continu de diffs. Des cahiers de tests d'acceptation, déroulés sur un environnement identifié, qui disent ce qui doit être vérifié plutôt que de laisser chacun deviner. Des revues d'experts humains à la demande sur ce qui le mérite. La vigilance reste indispensable ; elle cesse d'être diffuse et permanente.
3. Refuser certaines tâches — c'est-à-dire poser des contraintes
Troisième parade, la plus frappante. Les développeurs tracent des lignes rouges : les choix d'architecture, les zones à risque (paiements, données médicales, fichiers clients), et les tâches qui donnent du sens à leur métier. L'un d'eux le dit crûment :
« Je passe la moitié de mon temps à dire à l'IA ce qu'elle ne doit pas faire. Ne lis pas ce fichier. Ne refactorise pas. Reste à ta place. »
La moitié de son temps. À répéter, session après session, ce qui pourrait être dit une fois.
C'est très exactement ce que sont nos contraintes techniques d'organisation : des règles déclarées une fois au niveau de l'organisation, cascadées jusqu'à la fonctionnalité, injectées au début de chaque session et journalisées. Et sur la troisième catégorie de refus — les tâches qui donnent du sens — nous avons pris une décision de conception qui compte : dans notre modèle, une version écrite à la main, zéro token, a exactement le même statut qu'une version produite par un agent. Même cycle de vie, même revue, même mise en production. Garder une tâche pour soi n'est pas une exception à gérer : c'est un cas normal.
L'objection la plus sérieuse de l'article
Le texte glisse une phrase qui vise directement les outils comme le nôtre, et il faut la citer plutôt que l'éviter : les entreprises qui voudront codifier ces refus « se heurteront à une règle bien connue : plus une contrainte est rigide, plus elle se contourne ».
C'est vrai, et c'est même la raison pour laquelle nos contraintes ont trois niveaux plutôt qu'un interrupteur. Impérative — jamais contournée. Préférence — appliquée par défaut, sans drame si le contexte justifie de s'en écarter. Et entre les deux, le niveau qui répond précisément à cette objection : forte — l'agent peut la contester avec arguments, ce qui ouvre une décision produit qu'un humain tranche.
Une règle avec laquelle on peut discuter est une règle qu'on n'a pas besoin de contourner. Et comme chaque application — comme chaque contestation — est journalisée, une contrainte systématiquement contestée devient visible : c'est le signal qu'elle est mauvaise, pas que l'équipe est indisciplinée.
Ce qu'un outil ne peut pas faire
Il faut être net, parce que le sujet est trop sérieux pour une promesse commerciale.
- Aucun outil ne soigne un burn-out. Si 88 % des salariés les plus productifs grâce à l'IA se déclarent épuisés, comme le rapporte l'article, la réponse est d'abord une décision de charge et d'attentes. Elle appartient au management, pas à un logiciel.
- Un poste de pilotage de plus peut être une charge de plus. C'est un risque réel, et notre garde-fou de conception tient en un mot : dérivé. Le statut d'une fonctionnalité découle de ce qui est réellement déployé, pas d'une case que quelqu'un doit penser à cocher. Un tableau de bord qu'il faut entretenir à la main est une corvée supplémentaire, pas un soulagement.
- Nous ne couvrons que le logiciel. L'article prévient que la vague touchera les traducteurs, les juristes, les journalistes — tous les métiers du langage. Notre terrain, c'est la construction de produits numériques. Pour les autres, le raisonnement se transpose ; l'outillage reste à inventer.
Ce que nous affirmons est plus étroit : une partie de cette fatigue vient du volume, et personne ne peut grand-chose contre ça à court terme. Une autre partie vient du désordre — retrancher deux fois la même décision, tout relire parce que rien ne dit ce qui compte, garder la carte du produit dans sa tête. Cette part-là est un problème d'outillage, et elle est adressable.
Ce qu'on en retient
- La vibecoding fatigue frappe les plus avancés, pas les retardataires. C'est un signal de maturité de l'adoption, pas un argument contre l'IA.
- L'explication de Bainbridge tient depuis 1983 : automatiser les tâches faciles supprime les pauses et laisse l'effort continu — plus la surveillance.
- Les trois parades inventées sur le terrain — écrire la spec avant, structurer la revue, poser des refus explicites — sont justes. Leur faiblesse n'est pas leur contenu, c'est qu'elles reposent sur la volonté d'une personne, et qu'elles ne se transmettent pas.
- Transformer ces réflexes individuels en infrastructure partagée, c'est exactement ce que nous construisons. Ça ne remplace ni le repos ni une charge de travail raisonnable — mais ça retire de la fatigue la part qui vient du désordre.
L'article se termine sur un conseil que nous trouvons remarquable : pour qui débute, un bon repère est d'observer où les professionnels chevronnés refusent d'utiliser l'IA. Leurs refus indiquent, mieux que tout référentiel, ce qu'il faut encore apprendre à faire soi-même. On ajouterait une chose : ces refus mériteraient d'être écrits quelque part. Sinon ils partiront avec ceux qui les ont appris à leurs dépens.
Source : « La "vibecoding fatigue" : épuisés par l'IA, les développeurs informatiques inventent leurs propres parades », The Conversation, 28 juillet 2026. Les chiffres cités (Upwork Research Institute, étude de mars 2026 sur l'AI brain fry) sont ceux rapportés par l'article.
