Dans un bureau de San Francisco, quelque part entre le quatrième et le septième onglet Chrome ouvert simultanément, un ingénieur en IA fixe l’écran depuis sept heures. Il n’a pas écrit beaucoup de code aujourd’hui — l’agent de codage a produit la majorité des lignes. Mais il a relu, corrigé, revalidé, et décidé si chaque sortie du modèle était acceptable, approximative, ou franchement incorrecte, plusieurs centaines de fois depuis le matin. Il y a une sensation diffuse derrière les yeux. Pas tout à fait de la fatigue. Quelque chose de plus précis, comme si un processeur intérieur continuait de tourner sans pouvoir s’arrêter. Les anglophones qui travaillent dans ces environnements l’ont surnommé « brain fry ». Le terme est informel mais il décrit quelque chose de réel.
La surcharge cognitive liée à la supervision d’outils d’intelligence artificielle est un phénomène documenté qui ne ressemble pas tout à fait au burn-out classique. Ce n’est pas l’épuisement d’un volume de travail excessif sur une longue période — c’est la saturation d’un système cognitif sollicité au-delà de ses limites opérationnelles sur une journée de travail ordinaire. La théorie de la charge cognitive, formalisée par le psychologue australien John Sweller dès la fin des années 1980, établit que la mémoire de travail humaine peut traiter simultanément un nombre très limité d’éléments — sept, plus ou moins deux, dans les estimations classiques. Superviser plusieurs agents IA en parallèle, chacun produisant des sorties qui nécessitent une évaluation, dépasse cette capacité de façon continue et répétée.
Le paradoxe qui surprend même ceux qui le vivent est celui du développeur confronté au code généré par IA. L’intuition veut que déléguer la génération de code à un modèle linguistique devrait réduire la charge de travail. Dans la pratique, pour les ingénieurs travaillant dans des environnements critiques, c’est souvent l’inverse. Écrire du code soi-même est un processus actif et contrôlé — l’auteur sait où il va, comprend les décisions qu’il prend, peut anticiper les problèmes.
Réviser du code généré par IA est un processus défensif — l’ingénieur doit maintenir une attention maximale pour détecter des erreurs subtiles dans un contexte qu’il n’a pas construit, sur des blocs de code potentiellement plausibles mais incorrects sur des points non évidents. C’est le type de surveillance qu’on trouve dans d’autres professions exposées à la fatigue de vigilance : les contrôleurs aériens, les opérateurs de centrale nucléaire, les médecins urgentistes lisant des résultats d’examens automatisés. Le parallèle n’est pas rhétorique — le mécanisme psychologique est similaire.
Les symptômes que les travailleurs de l’IA décrivent dans les forums professionnels et les discussions informelles sont cohérents : un brouillard mental qui s’installe en début d’après-midi, une difficulté croissante à prendre des décisions même simples, parfois des sensations physiques légères comme des bourdonnements ou une tension cervicale persistante. La fatigue décisionnelle — l’épuisement progressif de la capacité à trancher entre options — est l’élément qui revient le plus souvent. Un développeur passant sa journée à valider ou invalider des centaines de propositions de code d’un agent vide cette capacité décisionnelle à un rythme que le travail de développement traditionnel ne sollicitait pas de la même façon.
Les stratégies de récupération que les praticiens ont développées empiriquement convergent vers quelques principes assez simples. Les micro-pauses cognitives — cinq à dix minutes par heure de coupure complète de l’écran, sans téléphone, sans outil numérique — permettent à la mémoire de travail de se vider partiellement et de récupérer une capacité de traitement. La réduction de la charge numérique ambiante — fermer les onglets superflus, ramener l’interface à une tâche unique — limite le nombre d’éléments concurrents que le cerveau essaie de maintenir en parallèle. Et la règle que beaucoup considèrent la plus difficile à appliquer : identifier les signaux d’alerte personnels — le moment où le taux d’erreur dans ses propres évaluations commence à monter, où les décisions ralentissent — et s’arrêter complètement à ce moment-là, même si la journée de travail n’est pas terminée.
