Fatigue liée à l’IA : organiser le travail avec des agents
Réduisez la fatigue liée à l’IA en organisant tâches, contexte et décisions dans une file de travail claire, traçable et maîtrisée par l’humain.
Fatigue liée à l'IA : reprendre le contrôle d'un travail fragmenté
Vous lancez une tâche dans un agent de code. Pendant qu'il répond, vous en démarrez une autre. Puis la première demande une précision, ce qui déclenche une vérification... et une petite tâche en plus. À la fin, chaque sujet finit dans un onglet différent ou une conversation séparée. Au bout de quelques minutes, vous jonglez entre des contextes que votre cerveau doit garder en parallèle.
Le problème n'est pas seulement le nombre de tâches. C'est ce que ça vous coûte quand il faut sans cesse changer de contexte : vous rappeler pourquoi un agent a fait tel choix, ce que vous devez valider, et où reprendre après une interruption. Et à mesure que les outils deviennent plus rapides, ils peuvent aussi produire plus de travail à superviser.
Une approche pragmatique consiste à traiter le travail avec l'IA comme une file de tâches, pas comme une suite de conversations. Chaque tâche a un état, un contexte conservé et un point de décision clairement identifié. Voici comment structurer ça, ce que vous pouvez automatiser, et ce qu'il faut garder sous contrôle.
Pourquoi les agents IA créent-ils de la fatigue mentale ?
Un agent de programmation ne se contente pas de répondre à une question. Il peut explorer un dépôt, modifier plusieurs fichiers, lancer des tests, puis vous soumettre une proposition à examiner. C'est utile - mais ça déplace une partie du travail : vous devez orchestrer plusieurs tâches, vérifier ce qui a changé, et décider quoi faire quand quelque chose reste ambigu.
Le vrai souci, c'est quand chaque tâche est menée dans une conversation séparée, sans registre commun. Une réponse arrive pendant que vous lisez l'autre. Une décision reste implicite dans un fil. Une demande de précision coupe votre travail en cours. Vous ne perdez pas seulement du temps à changer d'onglet : à chaque reprise, vous devez reconstituer le contexte.
Le vrai coût : recharger le contexte
Reprendre une tâche, c'est souvent rassembler plusieurs éléments : le problème initial, les fichiers touchés, les décisions déjà prises, les vérifications effectuées, et les questions encore ouvertes. Quand tout est dispersé entre un terminal, des messages et votre mémoire, le redémarrage devient cher.
La charge augmente avec le nombre de sujets ouverts, mais aussi avec leur degré d'incertitude. Une tâche bien cadrée, avec des tests qui passent, se reprend facilement. Une tâche bloquée par un arbitrage ou une règle métier demande plus d'attention - surtout si la raison du blocage n'a pas été écrite quelque part.
Pourquoi « faire une pause » ne règle pas tout
Faire des pauses, réduire le périmètre des demandes et réfléchir avant de lancer une tâche, ça reste une bonne hygiène de travail. Mais ça ne corrige pas un système où l'état du travail dépend d'une conversation ou d'une mémoire humaine. Après la pause, il faut toujours retrouver ce qui s'est passé.
La distinction utile est donc entre fatigue liée à l'effort et fatigue liée à la fragmentation. La première vient du travail en lui-même. La seconde vient des changements de contexte et des informations qui restent ouvertes. Une bonne organisation ne supprime pas l'effort de revue, mais elle enlève des tâches mentales parasites : se souvenir, chercher, reconstituer et relancer.
Dans une équipe, cette distinction a aussi un effet concret. Si les validations sont invisibles, un responsable peut devenir un goulot sans même voir combien de tâches l'attendent. La file rend l'attente observable, donc traitable comme un élément du processus - pas comme un "oubli" individuel.
Comment garder les décisions humaines au bon endroit ?
Un agent peut exécuter des actions dans un périmètre défini. Il ne devrait pas décider à votre place d'un compromis produit, d'une exception métier ou d'un changement à risque. La vraie question devient donc : où commence et où s'arrête l'autorisation donnée à l'agent.
Une façon simple de cadrer ça : distinguer les tâches "sûres à construire" et laisser les autres attendre. Une correction isolée, couverte par des tests et réversible, peut parfois aller dans le premier groupe. En revanche, une modification de facturation, de permissions, ou de données sensibles demande presque toujours une validation explicite. Le seuil dépend du produit, des conséquences d'une erreur, et du coût de correction.
Regrouper les arbitrages dans une boîte de réception
Les questions qui exigent un jugement humain peuvent être rassemblées dans une boîte de réception dédiée. Un script ou une vue de synthèse lit la file et affiche une liste priorisée : changement à examiner, question à trancher, compromis à choisir, tâche bloquée.
Cette vue évite les interruptions dispersées. Au lieu de tomber sur une demande au milieu d'un terminal ou d'un long fil, vous avez un endroit unique pour traiter ce qui demande votre attention. Et pour chaque demande, l'agent doit fournir assez d'éléments pour décider : ce qui a été fait, pourquoi, quelles options existent, et quelles conséquences sont envisagées.
Une interface de lecture peut rendre cette revue plus confortable (tableau global, fiche détaillée par ticket, résumé des différences et des contrôles). Mais l'interface n'a pas besoin d'être la source de vérité. Si elle se reconstruit depuis le dépôt à chaque cycle, les décisions peuvent être consignées directement dans le ticket versionné. L'interface sert à lire et agir ; le registre durable garde l'historique.
Fermer une tâche avant d'en ouvrir une autre
Le geste central est simple : prendre un élément, charger son contexte, décider (ou demander une action), puis clore la boucle en mettant à jour la tâche. La décision ne doit pas rester "quelque part dans votre tête". Elle doit devenir un état explicite dans la file : approuvée, rejetée, à modifier, ou bloquée avec une raison.
Clôturer ne veut pas dire que tout est fini. Ça veut dire que vous avez défini la prochaine action et transféré l'état hors de votre mémoire. Vous pouvez ensuite passer au sujet suivant sans garder l'ancien en suspens mental.
Pour une petite équipe française ou européenne, cette traçabilité aide aussi à revoir les responsabilités : qui a validé quoi, et sur quelles informations. Ce n'est pas une garantie de conformité, ni un substitut à une analyse RGPD. Mais c'est un point de départ bien meilleur qu'une succession de conversations dont l'état est difficile à reconstituer.
Comment déployer cette méthode sans créer une usine à gaz ?
Ce système ne vaut la peine que s'il vous coûte moins cher que la désorganisation qu'il corrige. On est vite tenté de construire un tableau de bord sophistiqué, des scripts de priorisation, et plusieurs agents spécialisés. En pratique, commencez par ce qui compte vraiment : la qualité de la file et la clarté des droits d'action.
Commencer avec un seul flux de travail
Choisissez un type de tâche limité : par exemple des corrections d'interface non sensibles ou l'ajout de tests. Définissez un modèle de ticket simple et une règle claire sur les actions autorisées. Gardez les changements à risque en revue manuelle, et interdisez à l'agent de déployer en production.
Un démarrage raisonnable peut suivre ces étapes :
- Créer un modèle de ticket (objectif, contexte, critères de validation, prochaine action).
- Définir les états de la file, avec une signification distincte pour chacun.
- Établir les permissions : lecture, modification, exécution de tests, création de branche, déploiement.
- Exiger une trace de travail : fichiers modifiés, contrôles lancés, résultats, points d'incertitude.
- Organiser une revue humaine des décisions, des changements et des tâches bloquées.
- Améliorer le processus à partir des échecs observés, plutôt que d'ajouter des outils "par anticipation".
Mesurer le coût réel, pas le nombre de tâches
Un agent qui traite beaucoup de tickets n'est pas forcément plus productif. Regardez plutôt : le temps de revue humaine, la fréquence des reprises, les erreurs qui passent malgré les contrôles, et la durée pendant laquelle les tâches restent bloquées en attente de décision.
Si les tickets prennent vingt minutes à comprendre, le format doit changer (vue de synthèse, structure des fiches, ajout de critères). Si les tâches tournent en boucle parce qu'il manque un arbitrage, le ticket doit mieux signaler le blocage et la file doit faire remonter ce type de demande. Si la revue montre souvent des changements hors périmètre, les règles d'autorisation sont trop larges ou les tickets sont trop ambigus.
Assumer les limites et les garde-fous
Une file bien construite ne rend pas les agents fiables "par magie". Elle peut même industrialiser une erreur si les critères d'acceptation sont faux. Les tests automatisés ne couvrent pas tout, et une vérification dans un navigateur ne remplace pas une revue sécurité ou une validation produit.
Les tâches peuvent aussi boucler : l'agent attend une décision, propose une solution, puis retombe sur le même blocage. Dans ce cas, il faut rendre les blocages explicites, limiter les tentatives automatiques et exiger une escalade quand la tâche dépend d'un arbitrage humain.
Enfin, le système doit respecter les contraintes de confidentialité et de sécurité de votre organisation : données envoyées à un fournisseur d'IA, accès au dépôt, secrets techniques. Tout ça doit suivre vos règles internes et les obligations applicables, notamment en matière de RGPD. En bref : la bonne automatisation est celle qui rend permissions, traces et limites compréhensibles par l'équipe.
Conclusion : moins de conversations, davantage de continuité
La fatigue liée aux agents IA vient souvent d'un décalage : les outils accélèrent l'exécution, mais laissent à l'humain la charge de suivre les contextes et les décisions. Une file de travail durable, une boîte de réception pour les arbitrages, et une clôture explicite de chaque tâche rendent cette charge plus visible et plus facile à gérer.
Le bon principe, ce n'est pas d'automatiser chaque étape. C'est de confier à l'agent ce qui est cadré et réversible, tout en gardant les décisions importantes et les déploiements sous contrôle humain. Commencez avec un seul flux, observez où le contexte se perd, puis ajustez le système à partir de ces frictions. En général, c'est plus utile que d'ajouter un nouvel outil dans une organisation déjà fragmentée.
Comment organiser les tâches dans une file de travail ?
Une file de travail sépare la description d'une tâche de l'outil qui l'exécute. Au lieu de laisser l'état du projet dans les conversations d'un agent, vous stockez chaque tâche dans un support durable, consultable, et versionné. Dans l'approche décrite ici, ce support est le dépôt Git : chaque ticket est un fichier Markdown, placé près du code concerné quand ça a du sens.
Choisir Git n'est pas une obligation. L'important, c'est d'avoir un principe simple : une source de vérité unique, pas forcément un format précis. Git marche bien pour du développement, parce que les tickets peuvent évoluer avec le code, être historisés, et reprendre leur état même si une session se termine.
Les informations minimales d'un ticket
Un ticket doit permettre à quelqu'un - humain ou agent - de reprendre le travail sans relire toute l'historique d'un chat. Idéalement, il contient :
Avec cette structure, vous évitez les tickets qui ressemblent à des notes vagues. "Améliorer le formulaire" ne dit pas comment vérifier. "Afficher une erreur compréhensible quand l'adresse e-mail est invalide, sans effacer les autres champs" est beaucoup plus exploitable.
Faire avancer la file par cycles
L'agent peut avancer en cycles : examiner les nouvelles tâches, qualifier celles qui manquent de contexte, créer explicitement les tâches autorisées, lancer les contrôles prévus, puis mettre à jour l'état. Les changements sensibles peuvent rester sur une branche et attendre une revue humaine.
La file doit aussi rester cohérente dans le temps. Si l'agent met à jour une tâche, le résultat doit être enregistré dans la source de référence - pas juste affiché dans une interface temporaire. Une session qui s'arrête ne doit pas "effacer" la décision ni le travail déjà fait.
Au final, vous remplacez une conversation au fil de l'eau par un processus visible. Vous voyez ce qui attend, ce qui avance, et ce qui est bloqué. Mais il faut accepter une discipline minimale d'écriture : si les tickets sont incomplets ou obsolètes, l'agent travaillera sur de mauvaises hypothèses. La file ne remplace pas le cadrage : elle rend simplement son absence difficile à ignorer.