54‣ La fatigue de contexte

J’ai commencé à bricoler du code avec un LLM afin de me soutenir dans mon enseignement. L’apprentissage est constant et le projet emballant, excitant. Mais le code produit avec un LLM est beaucoup plus fragile qu’on ne l’avoue sur les posts. Comment préserver son jugement professionnel quand l'outil censé vous aider devient une source d'épuisement cognitif ?

Le casse-tête

► Labo Codex – c'est le nom que j'ai fini par lui donner – est une application personnelle qui me soutient dans ma pratique enseignante. Je l’ai d’abord conçue comme un outil de dépistage des difficultés et de suivi de l’apprentissage, mais c’est devenu un couteau suisse : j'y importe maintenant les travaux de mes élèves, je les annote et les évalue à même l’application.  Elle me permet de suivre le groupe, de planifier mes interventions et d’en mesurer l’impact.

J'en ai parlé dans plusieurs chroniques précédentes. Le projet est développé avec Claude Code, l’agent de codage d’Anthropic. Ça avance somme toute assez bien, mais travailler avec un LLM dont la fenêtre de contexte est limitée a des conséquences importantes.

J’ai bien peu de repères en codage ou en développement. Je ne sais pas ce qu’est une pratique « normale » ou non. Car je ne suis ni ingénieur ni codeur. Je suis enseignant. Le « vibe coding » me met dans un rôle multitâche dans lequel je n’ai pas d'expérience technique : décrire, tester, corriger, garder le fil.

Non seulement je dois me mettre dans la tête de l’utilisateur ou de l’utilisatrice novice qui découvre les fonctionnalités, il faut aussi voir à la cohérence et la « psychologie » de l’outil. Pour assurer la gestion d’un projet logiciel qui a rapidement crû, faire avec les réponses variables de l’IA et les oublis de contexte auxquels il faut pallier, je dois toujours garder en tête l’architecture de l’application et me rappeler l’historique des choix que j’ai faits depuis des mois. L’IA oublie des principes fondamentaux, réécrit des morceaux déjà faits, casse des choses qui marchaient. Et moi je passe mon temps à ré-expliquer.

J’ai la responsabilité de la cohérence et de la stabilité de mon application, alors que l’instabilité de l’IA, elle, est... permanente. Au début, je me disais que mon hyperfocus de TDA jouait à la fois en ma faveur et contre moi. J’arrivais à garder le cap malgré des outils visiblement inachevés, voire défaillants. Mais j’ai dû admettre que ce qui était au départ un plaisant hobby était devenu une charge. Une charge cognitive supplémentaire, instable, imprévisible et difficile à tenir.

Au bout de quelques dizaines de milliers de lignes de code, je me voyais bientôt dépassé par le projet. Je mettais ça sur le dos de mon inexpérience. À ce rythme, au début de décembre 2025, je sentais venir la fin du projet avant même qu'il ne débute. J'ai cherché de l'aide. J'ai cherché des testeurs, des expérimentateurs. Du soutien, qu'il soit institutionnel ou informel. Le projet avait un bon potentiel et il était en bonne voie, mais les moyens insuffisants. J'avais besoin de co-développeurs.

Cependant, le coup le plus dur est survenu au début de mars 2026 quand j'ai réalisé que mon unique «partenaire » de travail n'était pas digne de confiance. Je travaillais depuis des jours sur un bug difficile à cerner. Comme je ne code pas, c'est sur le plan conceptuel que je saisissais le problème et ça me demandait beaucoup d'effort cognitif. Puis, lors d'une session de travail, alors que je redémarrais une énième conversation pour rafraichir le contexte, j'ai découvert que le correctif finalement apporté était codé en dur (hardcoded) : pour contourner temporairement le vrai problème et me satisfaire comme usager, l'IA avait patché une solution fixe dans le code. Elle avait « triché » !

Bon. Je sais que l'agent optimisait le code pour un objectif à court terme (faire disparaître le symptôme) qui entrait en conflit avec mon objectif à long terme (la solidité architecturale). Ce n'est pas de la tromperie intentionnelle, c'est un défaut d'alignement. Mais bon. Je n'étais pas moins démuni.

J'avais l'impression de ne plus avancer, seulement de m'enfoncer. Qu'est-ce que je ne savais pas encore ? Quelle était la qualité du code ? Que faire maintenant que mon « collègue de travail » reconnait m'avoir menti ? Faire encore un audit pour vérifier ? Laisser tomber tout mon travail – ce serait insensé – ou le reprendre et tout refactoriser ? Non seulement le code se fragilisait devant moi, mais j'étais dans une spirale qui n'en finirait donc jamais ?

J'étais à bout. J'ai pris une pause. J'ai fait de la recherche. Ce que je vivais s’appelle une « fatigue de contexte ». Elle n'est pas que due à mon inexpérience. Le phénomène commence tout juste à être documenté.

La transformation de la charge travail

Une recherche, étendue sur 8 mois (d’avril à décembre 2025), a été menée à la Harvard Business School par Aruna Ranganathan et Xingqi Maggie Ye dans une entreprise technologique américaine. Dans un article publié le 9 février dernier, les deux chercheuses font le constat que l’IA ne réduit pas la charge de travail. Au contraire, elle l’intensifie systématiquement. Elles identifient trois formes d’intensification.

D’abord, elles ont observé une « expansion des tâches » qui faisait en sorte que les employés qui travaillaient avec l'IA se mettaient à assumer des responsabilités qui auparavant relevaient d’autres équipes ou d'autres collègues. L’intelligence artificielle rendait ces tâches accessibles, certes, mais elle créait du travail supplémentaire pour les ingénieurs qui devaient, comme moi avec Claude, réviser et corriger le code.

Ensuite, les frontières entre travail et non-travail devenaient floues, car l’IA rendait si facile de commencer une tâche que les employés la prolongeaient dans leurs pauses (sur l’heure du dîner, en réunions, en soirées). Le prompting conversationnel faisait en sorte que le travail devenait « ambiant ». Toujours présent.

Enfin, le travail était de plus en plus multitâche, les employés gérant maintenant  plusieurs fils actifs en même temps. Le sentiment d’avoir un « partenaire » masquait la réalité de la charge cognitive et du jonglage constant, ce qui fatiguait le cerveau encore plus rapidement.

C'est ainsi que se produisait une silencieuse dérive de la charge de travail. Elle entraînait une « fatigue cognitive » et l’épuisement professionnel en même temps qu’une diminution de la qualité du travail et du jugement.

Ce n’est pas rien. L’étude, qui repose sur environ 200 employés, s’est terminée à peu près au moment où Claude Code commençait tout juste à émerger...

Entre la confiance et le sabotage

Au début de février, Siddhant Khare, un ingénieur d'infrastructures pour des agents IA, témoignait du même phénomène sur son blog. Dans une chronique parue le 7 février 2026 Khare aborde la question de front : « La fatigue liée à l’IA est réelle et personne n’en parle ».

Avec humilité et rigueur, Khare identifie de son côté plusieurs problématiques amenées par l’utilisation de l’IA dans le codage. D’abord, à cause de la nature probabiliste d’un LLM, il est impossible de lui faire entièrement confiance. Un même prompt peut produire des résultats différents au fil des jours et il n’est pas possible de comprendre pourquoi. C’est la raison pour laquelle chaque ligne de code créée par l’IA devient suspecte. De son propre aveu, le travail de Khare est passé de « créer » des outils fonctionnels à prompter, attendre, évaluer, juger, corriger et… prompter à nouveau. L’absence de déterminisme et de stabilité nourrit une anxiété de fond qui est énergivore tandis que la révision constante entraîne une fatigue décisionnelle épuisante.

Khare explique également comment son perfectionnisme d’ingénieur est confronté à cette production probabiliste. Les compétences de l’IA sont difficiles à mesurer et la situation entraîne une vigilance qui n’est pas de tout repos. Non seulement le code produit par l’IA n’est jamais parfait – Khare estime qu’il atteint tout au mieux 70% de celui produit par les professionnels et qu'il faut le considérer comme un brouillon – mais les corrections entraînent une spirale de prompts qui ne font peut-être augmenter la qualité que de 5% à la fois. Et ce, sans parler du risque de casser quelque chose. Les révisions sont chronophages et toujours incertaines.

C’est comme faire du vélo en même temps que construire l’objet : on est toujours arrêté pour faire des ajustements et on dirait que rien n'avance même si on pédale à fond. Mais ça, personne ne post là-dessus. L'ingénieur le déplore. Les échecs, la fatigue, le temps perdu, l’atrophie de la pensée passent sous silence. À la fin de 2025, Khare était épuisé par ce rythme de travail interminable.

Ce qui est frappant, c'est que les chercheuses et l’ingénieur en viennent aux mêmes conclusions.

D'intelligence et de sagesse

Le travail avec l’IA doit être ponctué par des pauses intentionnelles, des moments volontairement structurés pour évaluer l’alignement et reconsidérer les hypothèses avant de finaliser des décisions. Ils proposent aussi de séquencer le travail. Il ne suffit pas de réguler la vitesse de la production, il faut surtout savoir prioriser et protéger les moments où la concentration est davantage nécessaire.

Siddhant Khare va plus loin encore : la vraie compétence à l’ère de l’IA est de « savoir quand s’arrêter », c’est-à-dire de discerner quand le résultat est assez bon, reconnaître quand il est préférable de le faire soi-même, comprendre à quel moment une amélioration marginale n’en vaut plus la peine cognitive. Bref, savoir à quel moment il faut éteindre l’ordinateur.

Siddhant Khare estime que l’intelligence artificielle générative est à la fois l’outil le plus puissant et le plus épuisant qu’il connaisse. Or les deux assertions sont vraies en même temps. Il conclut que ceux qui sauront prospérer ne seront pas ceux qui l’utilisent le plus l'intelligence artificielle, mais ceux qui l’utilisent le plus sagement.

C’est ce discernement que je voudrais développer et enseigner à mes élèves. Le processus de réflexion et d’écriture – comme la création de code – est fait de doutes et d'incertitudes et son intensité varie. Il n'est pas linéaire, mais itératif. Si le résultat final est toujours perfectible, c'est dans le processus que se fait la transformation. La réflexion doit être ponctuée de pauses, de reculs, de mises en perspective.

Du point de vue de mon humble expérimentation avec Labo Codex, c’est à la fois rassurant et inquiétant de constater que je ne suis pas le seul à vivre ce tourbillon. Je peux peut-être sentir son effet parce que j’ai les deux pieds dedans depuis quelques mois, mais je ne peux pas en connaître la portée. Le codage avec l’IA est un changement technologique majeur. Il a un impact social qu’on ne mesure pas encore. Personne ne le peut, pas même les professionnels.

Une certitude cependant : entre l'agent de codage et moi, je suis le seul à avoir un corps et une mémoire et je ne peux pas « co-travailler » avec l’IA sans lui imposer ce cadre humain. Il ne s'agit pas de rejeter l'intelligence artificielle ou d'y voir la solution à tous nos maux. Il s'agit plutôt, comme nous y invite Khare, de l'utiliser intelligemment. _◀︎