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

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

Deux équipes commencent toutes deux à consigner 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 proche. 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 — le modèle de brief dont la portée reste indéfinie, le compte publicitaire dont la structure entrave chaque session — sont toujours présentes, car aucun ajustement ponctuel ne peut y remédier.

La deuxième équipe pose une question supplémentaire pour chaque cas de figure : à quel domaine cette correction s’applique-t-elle réellement ? Le groupe de problèmes « les agents ne cessent de se tromper sur notre public » se traduit par une modification de la manière dont le travail est défini : une correction de processus, convenue lors d’une réunion d’équipe. Le groupe « manuel d’intervention obsolète » se traduit par une amélioration de la documentation, avec désignation d’un responsable. La particularité 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 se situe à un niveau où réside 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 correction pouvant faire l’objet d’un suivi. « 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 référence précise.

Une mauvaise estimation de l’ampleur du problème a deux conséquences négatives. Le sous-ciblage, note personnelle remplaçant 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. Le sur-ciblage (une nouvelle compétence pour une tâche ponctuelle, un paragraphe supplémentaire dans un fichier de contexte déjà surchargé) représente un surcoût de maintenance pour l’artefact ; la communauté a précisément nommé ces anti-modèles : la prolifération des compétences (16→48 compétences en 15 jours: « Ajouter des compétences, c’est facile. … La gestion, c’est la partie difficile. ») 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 depuis 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 après 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é, il est à moitié routé :

Groupe dominant	Le correctif se trouve généralement à l’emplacement suivant :	Artéfacts typiques
Point d’information	processus (la manière dont les missions sont définies) 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 forum 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 correction ; ainsi, l’affirmation selon laquelle « l’étiquette détermine en partie la correction » est vraie par nature — il s’agit d’un choix de conception, et non 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).

Notez bien ce quework-material-frictionce terme recouvre, car c’est là que ce vocabulaire justifie son caractère indépendant de toute discipline. En programmation, il s’agit de la « dette technique » : ce module sur lequel chaque session trébuche. 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. Le label est work-material-friction, toujours associé à 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 emmêlées, des modèles CMS en pagaille et des bibliothèques de macros d’assistance ; une boucle en forme d’agent de codage n’a nulle part où les classer.

Pourquoi « fixe » plutôt que « émergente » ? 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 courbes de tendance (« 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 attribue ses propres étiquettes, 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 humains et 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 émerger 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 les é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, quoi qu’il en soit, 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) identifie la couche de la pile qui a é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 notreagent-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 — il faut corriger le harnais, pas l’agent : Osmani, Agent Harness Engineering). TraceProbe classe les actions de gestion des erreurs dans les traces. Garg’s Feedback Flywheel 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 « échecs » 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 de ces classifications portent sur des symptômes, des niveaux ou des destinations ; la nôtre classe les causes — c’est ce qui fait de cette étiquette une clé de routage, et c’est là l’argument de nouveauté proprement dit, pour ainsi dire. 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 (des évaluateurs indépendants effectuant un étiquetage en aveugle sur les 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 sont 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 cours : Loop Engineering, Compound Engineering, agent-retro, les rétrospectives AGENTS.md, les systèmes de mémoire des fournisseurs et les rapports de session automatisés. Conservez-les tous ; rien ici ne les remplace.

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 d’agents). Et les chiffres du secteur lui-même indiquent que l’étape coûteuse n’est pas l’analyse : environ 90 % des équipes instrumentent les traces des agents, mais seules 37 à 52 % environ 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 vision d’ensemble commence à prendre toute son importance, pour deux raisons.

L’agrégation redéfinit les priorités. Un désagrément de dix minutes pour une personne n’est qu’un bruit de fond ; personne ne s’en occupe de manière rationnelle. Ce même libellé, récurrent au cours de huit sessions et chez cinq personnes, représente l’un des coûts les plus importants pour l’équipe, et seule la vue agrégée permet de le mettre en évidence. 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 principales 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’appliquent à des éléments 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 point de contrôle sur le pipeline : les agents doivent détecter, enregistrer, regrouper et rédiger librement ; les humains apportent le jugement sur l’orientation à prendre et en assument la responsabilité.

Si votre équipe organise déjà une réunion 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 de priorité. Ce n’est pas un nouveau rituel, mais une rétrospective avec de meilleures données d’entrée. Les ingénieurs en apprentissage automatique appellent cela l’analyse des erreurs de lecture ; 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 dans le cadre de 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 de 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 correspondent à des propositions que nous souhaitons tester au sein 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 de fournisseurs, 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 fait absolument pas référence à une altitude : ai-discussion@teamretro.com.

---

Chapitre suivant : Le rapport existe. La pièce, non. — pourquoi l’acheminement des corrections relève d’une décision d’équipe, et ce que fait l’équipe lorsque le rapport sur les frictions arrive. Extrait du guide des rétrospectives des agents IA.