Où la solution devrait-elle être mise en œuvre ?

Deux équipes, les mêmes tensions, un quart-temps différent

Deux équipes commencent toutes deux à répertorier les difficultés rencontrées par leurs agents IA : les demandes ambiguës, les documents obsolètes, les outils peu fiables, les exécutions répétées.

La première équipe règle tous les problèmes au niveau le plus accessible. Chaque désagrément récurrent donne lieu à un ajustement rapide ou à une note de rappel ; tout ce qui est plus important devient un paragraphe supplémentaire dans le fichier de contexte. Trois mois plus tard, leurs agents fonctionnent selon des instructions surchargées que personne ne lit dans leur intégralité, et les frictions qui comptaient vraiment (le modèle de brief dont la portée reste indéfinie, le compte publicitaire dont la structure complique chaque session) sont toujours présentes, car aucun ajustement rapide ne peut y remédier.

La deuxième équipe pose une question supplémentaire pour chaque schéma : à quelle catégorie ce correctif appartient-il réellement ? Le groupe « les agents ne cessent de se tromper sur notre public » se traduit par un changement dans la manière dont le travail est défini : un correctif de processus, convenu lors d’une réunion d’équipe. Le groupe « manuel d’intervention obsolète » se traduit par une amélioration de la documentation, avec un responsable désigné. La bizarrerie ponctuelle devient une simple note de rappel, sans plus. Trois mois plus tard, leurs fichiers d’instructions sont plus courts qu’au début, et les catégories de frictions qu’ils ont corrigées affichent une tendance à la baisse.

La différence ne réside pas dans la rigueur de la saisie des données. Les deux équipes ont saisi leurs données. La différence réside dans une question d’itinéraire que la première équipe ne s’est jamais posée.

La manœuvre clé : les points de friction en altitude

Lorsqu’une session assistée par l’IA rencontre un obstacle, la cause profonde renvoie à un niveau où se trouve la solution durable. Nous appelons cela l’altitude de la solution ; les altitudes disponibles vont de l’éphémère au structurel :

mémoire → compétence/instruction → environnement et configuration → documentation → le support de travail lui-même → processus/flux de travail → produit ou fournisseur en amont

Le fait de nommer le problème transforme une plainte en une solution identifiable. « L’agent s’est encore trompé dans la stratégie d’enchères » est une plainte. « La décision relative à la stratégie d’enchères n’a jamais été consignée par écrit à un endroit où l’agent aurait pu la trouver : il s’agit d’une correction à apporter à la documentation, et voici le guide d’intervention dans lequel elle doit figurer » est une tâche dotée d’une solution précise.

Une mauvaise estimation de l’ampleur du problème entraîne deux types de conséquences. Le sous-ciblage, note de mémoire personnelle qui remplace en réalité un document d’équipe manquant, signifie que les frictions se reproduisent pour tous ceux qui ne sont pas vous : un coût de récurrence pour le reste de l’équipe. Les notes déjà perdues de cette manière peuvent être récupérées grâce à une collecte de mémoire au sein de l’équipe. **Surciblage (une nouvelle compétence pour une tâche ponctuelle, un paragraphe de plus dans un fichier de contexte déjà surchargé) représente un coût de maintenance pour l’artefact ; le domaine a précisément nommé ces anti-modèles : prolifération des compétences (16→48 compétences en 15 jours : « Ajouter des compétences, c’est facile. … La gestion, c’est ça le plus dur.») et le gonflement du fichier de contexte (« un fichier de mémoire qui a cessé d’être lu », selon cette note de terrain). Les fournisseurs ont convergé vers le même gradient en partant de l’autre extrémité : dévaloriser la mémoire éphémère, privilégier l’apprentissage durable via le contrôle de version : Windsurf/Devin (« Écrivez-le sous forme de règle ou ajoutez-le à AGENTS.md… plutôt que de vous fier à des souvenirs générés automatiquement », documentation), OpenAI Codex (« lorsque Codex commet deux fois la même erreur, demandez-lui une rétrospective et mettez à jour AGENTS.md », bonnes pratiques), l’expiration délibérée de la mémoire de Copilot au bout de 28 jours.

Le secteur connaît donc ces deux modes de défaillance. Ce qui manquait, c’était un outil de routage.

Un vocabulaire fixe qui achemine

Notre proposition de travail : associer à chaque problème identifié exactement une cause première issue d’un vocabulaire fixe de dix étiquettes réparties en cinq groupes : suffisamment restreint pour être mémorisé, axé sur les causes plutôt que sur les symptômes, et délibérément indépendant des outils et des disciplines :

• Point d’information : ambiguous-instruction, missing-context, incorrect-context, changed-requirements
• Documentation : missing-documentation, incorrect-documentation
• Matériel de travail : work-material-friction
• Outillage : missing-access-or-tool, environment-friction
• Agent : agent-error

Le groupe constitue la clé de routage. Dès qu’un résultat est étiqueté, son routage est à moitié effectué :

Groupe dominant	Le correctif se trouve généralement à l’adresse suivante :	Artéfacts typiques
Exposé	processus (la manière dont le travail est défini) ou une mémoire persistante	modèle de note de synthèse, liste de contrôle pour le lancement, dossier de référence
Documentation	documents	Fichier README, guide d’exploitation/procédure opérationnelle standard, fichier de contexte, spécification
Matériel de travail	le matériau lui-même	code : la refonte vers laquelle le « friction » ne cesse de pointer ; hors code : la restructuration du compte, du tableau ou du modèle
Outillage	environment/config, ou en amont	paramètres, configuration MCP, autorisation d’accès, ticket fournisseur
Agent	invite, compétence ou garde-fou	modification de compétence, hook, eval

Une précision d’emblée : les groupes sont nommés d’après leurs destinations de fixation ; ainsi, l’affirmation selon laquelle « l’étiquette détermine en partie la fixation » est vraie par construction, il s’agit d’un choix de conception plutôt que d’une découverte empirique. L’affirmation empirique sous-jacente est que les étiquettes au moment de la capture sont précises et cohérentes, ce qui est précisément ce que nous n’avons pas encore mesuré (plus d’informations ci-dessous).

Le tableau attribue une première adresse à une correction, et la récurrence peut la déplacer. Lorsque des problèmes réapparaissent après une correction apportée à la documentation ou au fichier de contexte, c’est probablement que le texte ne fonctionne pas. Déplacez la correction vers une barrière de sécurité : un hook ou un contrôle CI, qui la maintient en place, que quelqu’un la lise ou non. C’est le même raisonnement que pour le choix d’un déclencheur de capture : une ligne de convention dépend du fait que quelqu’un s’en souvienne, contrairement à un hook.

Notez bien ce que ce terme recouvrework-material-friction, car c’est là que ce vocabulaire justifie son caractère indépendant de toute discipline. En langage de programmation, il s’agit de la « dette technique » : ce module sur lequel chaque session bute. En dehors du code, ce phénomène est tout aussi réel. Imaginez une équipe marketing dont l’agent audite un compte Google Ads qui s’est développé par accumulation : trois générations de conventions de nommage, des campagnes mises en pause que personne n’ose supprimer, des mots-clés dupliqués dans des groupes d’annonces qui se chevauchent. À chaque session, le chargé de compte passe ses premiers instants à reconstituer à quelle campagne appartient quoi, et chaque recommandation s’accompagne d’une mise en garde. Aucune solution rapide ne permet d’y remédier ; aucune note de rappel ne résout le problème pour la personne suivante. L’étiquette est work-material-friction, toujours associée à l’élément concret désigné (ce compte), et l’altitude correspond à l’élément lui-même : la restructuration vers laquelle les frictions ne cessent de pointer. Le même schéma se retrouve dans des feuilles de calcul enchevêtrées, des modèles CMS en pagaille et des bibliothèques de macros d’assistance ; une boucle conçue pour un agent de codage n’a nulle part où les classer.

Pourquoi « fixe » plutôt que « émergent » ? Parce que, pour une équipe, la taxonomie est un outil de coordination, et non un simple exercice de classification. « Une friction identique sur huit sessions constitue un problème de processus » n’a de sens que si les huit sessions l’ont toutes qualifiée de la même manière ; les analyses de répartition nécessitent un dénominateur stable ; et les tendances (« la friction liée aux briefings a-t-elle diminué depuis que nous avons standardisé le modèle de briefing ? ») ne sont valables que si une étiquette a la même signification en mars et en juillet. Les catégories émergentes, où chacun effectue son propre codage, constituent la bonne solution en solo, mais au sein d’une équipe, elles divergent d’une personne à l’autre, et rien ne peut être agrégé sans une étape de réconciliation dont personne n’assume la responsabilité. Nous maintenons ce mécanisme d’émergence en place à deux niveaux : une note citant des preuves sous chaque étiquette, et une révision périodique du vocabulaire au cours de laquelle les notes accumulées permettent de tester la validité des étiquettes. Le vocabulaire est géré par versions ; il est conçu pour évoluer en fonction des preuves, et non pour être défendu.

Ce qui existe déjà, comparé en toute honnêteté

Ce n’est pas nous qui avons inventé les taxonomies de l’échec, et celles qui existent déjà remplissent bien leur fonction.

MAST (arXiv 2503.13657) est la taxonomie fixe de référence : 14 modes de défaillance répartis en 3 catégories, issus de 150 traces examinées par des experts et validés par rapport à un corpus de plus de 1 600 cas, avec une forte concordance entre les annotateurs (κ = 0,88). Elle classe les défaillances des systèmes multi-agents ; conçue pour la recherche et l’évaluation comparative, elle est la plus proche de la nôtre en termes de discipline, mais diffère par son objet : nous classons les causes des frictions survenues dans la collaboration entre les humains et les agents.

L’école de l’analyse des erreurs, la méthodologie d’évaluation de Husain & Shankar (FAQ sur les évaluations, janvier 2026), défend une position opposée à celle d’une liste fixe : les catégories « devraient découler des schémas d’échec observés… et non de classifications prédéterminées des requêtes », et la lecture ouverte de vos propres traces constitue « l’activité la plus importante dans le cadre des évaluations ». Nous pensons qu’ils ont raison à l’échelle individuelle et que la situation s’inverse à l’échelle de l’équipe, pour les raisons d’agrégation évoquées ci-dessus. Leur discipline d’analyse est, dans tous les cas, un pilier de notre proposition ; c’est ce que constituent les notes de justification.

Autour de ces axes : la taxonomie à quatre niveaux (Greyling, mai 2026) classe les niveaux de la pile qui ont échoué, n’attribuant qu’environ 9,9 % des échecs au raisonnement du modèle : la plupart des défaillances sont des problèmes liés au harnais (le harnais est l’échafaudage qui entoure le modèle), ce qui explique pourquoi notre agent-errorétiquette est une valeur résiduelle, utilisée uniquement lorsque les entrées étaient adéquates (l’école d’ingénierie du harnais rejette explicitement la tendance à rejeter la faute sur l’agent, préférant corriger le harnais plutôt que l’agent : Osmani, Agent Harness Engineering). TraceProbe classe les actions de gestion des erreurs dans les traces. Le « Feedback Flywheel » de Garg rassemble quatre types de signaux dans des artefacts d’équipe, le cadre dans lequel s’inscrit le nôtre : son contexte ≈ nos groupes de briefing et de documentation ; son volet « échec » correspond à ce que notre taxonomie décompose. « Factory Signals » classe les symptômes de session en tickets classés automatiquement ; « Braintrust Topics » est le produit issu de cette école émergente, qui regroupe quotidiennement vos traces en nouveaux clusters.

Deux interprétations honnêtes de cette comparaison. Premièrement, la plupart d’entre elles classent des symptômes, des niveaux ou des destinations ; la nôtre classe les causes, ce qui fait de cette étiquette une clé de routage, et c’est là l’argument de nouveauté proprement dit, tel qu’il est. Deuxièmement, et c’est plus important : MAST a mesuré la fiabilité de l’étiquetage, ce que nous n’avons pas fait. La fiabilité inter-évaluateurs de nos dix étiquettes n’a pas été mesurée, et nous considérons cela comme une condition préalable, et non comme une simple note de bas de page : l’expérience (dans laquelle des évaluateurs indépendants attribuent en aveugle des étiquettes aux mêmes entrées réelles, avec un rapport de concordance quel qu’il soit) est en cours sur des entrées issues de notre propre essai en conditions réelles, avec le coefficient κ de MAST = 0,88 comme référence. Tant que les résultats ne seront pas publiés, cette taxonomie reste une proposition de travail comportant des étiquettes versionnées, et non un outil validé. Nous préférons vous le signaler plutôt que de vous laisser le découvrir par vous-même.

Nous soutenons également toutes les boucles déjà en place : Loop Engineering, Compound Engineering, agent-retro, les rétrospectives AGENTS.md, les systèmes de mémoire des fournisseurs, les rapports de session automatisés. Conservez-les toutes ; rien ici ne vient les remplacer.

Pourquoi l’altitude est une question qui concerne toute l’équipe

Voici le point commun entre ces boucles existantes : presque toutes sont « en solo » (un développeur et son agent, ou un fournisseur et son parc). Et les chiffres du secteur lui-même indiquent que l’étape coûteuse ne réside pas dans la surveillance : environ 90 % des équipes instrumentent les traces d’agents, mais seules environ 37 à 52 % les évaluent systématiquement (LangChain State of Agent Engineering, juin 2026). La couche qui fait défaut est la synthèse au niveau de l’équipe, et c’est précisément là que la perspective globale commence à prendre toute son importance, pour deux raisons.

L’agrégation redéfinit les priorités. Ce qui représente une gêne de dix minutes pour une personne n’est qu’un bruit de fond ; personne ne s’en occupe de manière rationnelle. Si le même libellé revient au cours de huit sessions et chez cinq personnes, cela représente l’un des coûts les plus importants pour l’équipe, et seule la vue agrégée permet de le constater. L’agrégation est également ce que permet d’obtenir l’utilisation d’un vocabulaire standardisé : les chiffres ne s’additionnent correctement que si tout le monde utilise les mêmes libellés.

Les niveaux les plus élevés relèvent de la responsabilité de l’équipe. Un individu peut définir ses propres paramètres de mémoire, ses invites et sa configuration. Mais les changements de processus, les décisions à prendre concernant plusieurs outils, le budget alloué aux outils, les escalades en amont — c’est-à-dire les niveaux où se situent généralement les plus grandes frictions récurrentes — sont des décisions qu’aucun individu ne peut prendre seul. C’est également la raison pour laquelle nous pensons que la place de l’humain dans la synthèse reste indispensable, quelle que soit la qualité des modèles : les corrections s’inscrivent dans des artefacts dont les humains sont responsables et pour lesquels ils doivent rendre des comptes : briefs, processus, budgets, accords d’équipe. Il s’agit là d’une question d’autorité organisationnelle, et non de capacité des modèles. Et il s’agit d’une place au cœur du processus, et non d’un barrage sur le pipeline : les agents doivent détecter, enregistrer, regrouper et rédiger librement ; les humains apportent le jugement sur l’acheminement et en assument la responsabilité.

En parcourant les contributions des utilisateurs et les dépôts, on découvre également des leçons qui se contredisent. Privilégiez la substitution plutôt que le remplacement : la nouvelle leçon est ajoutée sous forme d’entrée datée faisant référence à l’ancienne, et cette dernière reste consultable, afin que personne ne reprenne discrètement la croyance erronée par la suite. Pour trancher entre les deux, vérifiez d’abord la provenance (un témoignage de première main l’emporte sur une leçon qui n’a été que répétée), puis la date, en consultant les horodatages réels. Si aucun de ces critères ne permet de trancher, marquez les deux comme non résolues plutôt que d’imposer une solution. Vérifiez également le champ d’application. L’un de nos dépôts contenait une consigne indiquant de ne jamais créer de lien symbolique vers le répertoire de travail node_modules; un autre stipulait qu’il fallait absolument en créer un, sous peine d’échec de la compilation. Chacune était vraie dans son propre dépôt. Une solution partagée ultérieurement, consistant en une copie liée en dur, a fonctionné dans les deux cas, de sorte que la consigne relative au lien symbolique a été remplacée.

Si votre équipe organise déjà une séance d’amélioration continue, cette démarche s’y intègre parfaitement : le tableau récapitulatif des frictions est présenté, l’équipe se demande « où se situe chaque correction ? », et chaque schéma est attribué à un responsable et à un niveau d’importance. Il ne s’agit pas d’un nouveau rituel, mais simplement d’une rétrospective s’appuyant sur de meilleures données. Les ingénieurs en apprentissage automatique appellent cela une « analyse des erreurs » ; les équipes appellent cette séance une « rétrospective ».

Qu’est-ce qui pourrait nous faire changer d’avis ?

Il s’agit d’un document de réflexion ; voici donc les points sur lesquels nous avons réellement des doutes :

• Fiabilité. Si l’expérience inter-évaluateurs fait état d’une faible concordance, cela signifie que les règles de délimitation (ou les étiquettes elles-mêmes) sont erronées, et nous les réviserons en indiquant la version correspondante plutôt que de les défendre.
• Taille. Le nombre de dix étiquettes est un paramètre hérité, et non dérivé. MAST en utilise 14 ; Four-Layer en utilise 4. La répartition de nos étiquettes après un quart des entrées réelles constitue la preuve qui permet de la conserver ou de la modifier.
• Modes manquants. Les frictions entre agents (perte lors du transfert entre sous-agents, défaillances d’orchestration) sont actuellement classées sous environment-friction; les cas concrets pourraient nécessiter une catégorie distincte.
• Périmètre des revues hors code. Nous définissons le périmètre des revues en fonction de l’emplacement où les corrections seraient intégrées : le dépôt pour la plupart des travaux de développement ; les rubriques « compte », « espace de travail » ou « mission » en dehors de celui-ci. Ces limites hors code constituent des propositions que nous souhaitons tester auprès d’équipes réelles.
• Faisabilité au moment de la saisie. Les équipes très occupées peuvent-elles attribuer des causes sur le vif, ou cette attribution doit-elle avoir lieu lors de la révision ? Les équipes qui s’y essaient permettraient de trancher cette question plus rapidement que nos théories.

Si vous utilisez n’importe quelle version de cette boucle (catégories émergentes, pipeline fournisseur, simple feuille de calcul), nous aimerions savoir à quel moment la table de routage présente des dysfonctionnements. En particulier si vous pouvez nous montrer un schéma de friction qui ne pointe absolument pas vers une altitude : ai-discussion@teamretro.com.

---

Chapitre suivant : Le rapport existe. La salle, elle, n’existe pas : pourquoi l’orientation des corrections relève d’une décision d’équipe, et comment l’équipe réagit lorsque le rapport sur les frictions est transmis. Extrait du guide sur les rétrospectives des agents IA.