La carte : boucles de rétroaction des agents, outils et approches

TeamRetro s’intéresse à tous les cycles d’amélioration continue mis en œuvre par les équipes ; le travail assisté par l’IA est un nouveau domaine que nous explorons à travers le prisme de la rétrospective. Cette page constitue le document de référence complémentaire à ce guide : elle présente l’ensemble du sujet de manière systématique. Si vous préférez commencer par l’histoire, rendez-vous à l’introduction du guide puis revenez ici.

À quoi sert cette page ?

Trois éléments, dans l’ordre : le cycle de vie qu’un problème ponctuel parcourt depuis son apparition jusqu’à sa résolution ; les boucles nommées que le secteur a mises en place pour gérer ce cycle de vie, classées selon le niveau auquel chacune opère ; et les systèmes de classification utilisés pour nommer ce qui n’a pas fonctionné. Lisez ce document de haut en bas pour situer votre équipe : quelles étapes vos outils couvrent-ils déjà, quelle boucle utilisez-vous déjà sous un autre nom, et quel vocabulaire utiliseriez-vous pour qualifier vos constatations ? Tout ce qui figure ici est autonome : rien ne vous oblige à adopter notre pratique, nos étiquettes ou notre produit.

Le cycle de vie : sept étapes, du problème à la résolution

Lorsqu’un agent effectuant un travail concret se heurte à un obstacle (un document manquant, une instruction ambiguë, un outil peu fiable), ce signal est éphémère : l’agent contourne le problème, la session prend fin, et la session suivante se heurte au même obstacle. Les modèles de friction de Rahul Garg décrivent le coût de premier ordre (la boucle de frustration : générer → réviser → ne correspond pas → régénérer) ; le cycle de vie ci-dessous illustre le problème de second ordre : que doit-il se passer pour que la friction soit résolue au bon niveau ? Cet écart est mesurable : environ 90 % des équipes enregistrent les traces des agents, mais seules environ 37 à 52 % les évaluent systématiquement (LangChain, juin 2026) — la plupart des équipes peuvent observer ces frictions ; elles sont bien moins nombreuses à les transformer en solutions.

Scène	La question à laquelle elle répond	Options	Terme utilisé par les professionnels
0 · Hébergement	Où l’agent s’exécute-t-il ?	CLI locale · Web · IDE · CI/en mode headless · planifié	—
1 · Détection	Comment perçoit-on le frottement ?	autocontrôle · vérification par un agent secondaire · correction humaine · télémétrie	vérification des traces, analyse des erreurs
2 · Instrumentation	Comment l’agent sait-il qu’il doit le suivre ?	compétence · accroche · convention · commande	—
3 · Enregistrement	Comment est-ce enregistré, et où ?	mémoire · magasin MCP · journaux/traces · tickets · commits tagués	codage ouvert, mémoire épisodique
4 · Récolte	Comment organisez-vous vos réunions au-delà d’une seule séance ?	analyse des traces vs agrégation d’artefacts · balayage vs événement · déduplication	—
5 · Synthèse et ciblage	Données brutes → tendances → quel niveau de correction ?	regrouper + classer, puis acheminer en fonction de l’altitude	codage axial, taxonomie des défaillances
6 · Boucler la boucle	Cette solution a-t-elle permis de réduire les frictions futures ?	évaluer la tendance	Volant d’inertie à rétroaction, ingénierie de la multiplication des effets

Étape 0 : Hébergement

Tout ce qui se passe en aval dépend de l’endroit où l’agent s’exécute. Un agent CLI local laisse une transcription sur le disque et peut créer des fichiers en mémoire ; un agent CI ou « headless » peut être éphémère, sa seule trace étant ce qu’il a consigné avant la fermeture du conteneur ; un agent Web ou IDE conserve un historique côté serveur que vous pouvez interroger mais pas analyser avec grep ; un agent planifié s’exécute sans surveillance humaine. L’hébergement définit les paramètres pour toutes les étapes ultérieures : ce qui est observable, où l’état peut être conservé, et qui (ou quoi) peut l’examiner. Le compromis : une observabilité locale plus riche contre la reproductibilité et le stockage centralisé des exécutions hébergées.

Étape 1 : Détection

Quatre canaux, rarement exclusifs. L’auto-détection (l’agent reconnaît ses propres tentatives de réessai et ses retours en arrière) est la solution la moins coûteuse mais la plus biaisée : l’agent ignore ce qu’il ignore. La révision par un agent secondaire, dans laquelle un nouvel agent relit la transcription a posteriori, est plus objective mais nécessite un deuxième passage. La correction humaine constitue le signal de la plus haute qualité, et reste la méthode dominante : une étude en conditions réelles menée sur huit semaines a révélé qu’environ 70 % des échecs silencieux avaient d’abord été détectés par un humain ayant remarqué que quelque chose clochait (arXiv 2606.14589). La télémétrie (taux d’erreur des outils, refus d’autorisation, nombre de boucles) est automatique mais superficielle : elle sait quoi, mais pas pourquoi. Les configurations les plus performantes combinent ces deux approches : la télémétrie signale où chercher, tandis qu’une étape de révision explique pourquoi.

Étape 2 : Instrumentation

Un agent n’enregistrera pas de friction à moins qu’un élément ne la provoque. Les options, classées selon leur degré de dépendance vis-à-vis de la mémoire du modèle : une compétence (une procédure explicite et portable invoquée à un point d’arrêt : claire, mais doit effectivement se déclencher), un hook (qui se déclenche automatiquement au démarrage ou à l’arrêt de la session : fiable, mais peu nuancé), une convention (une instruction dans un fichier de contexte : aucune infrastructure requise, système basé sur la confiance), ou une commande (déclenchée par l’utilisateur : délibérée, mais soumise à l’intervention humaine). C’est l’étape la plus souvent ignorée, et c’est pourquoi tant de frictions ne sont pas consignées : personne n’a demandé à l’agent de vérifier.

Étape 3 : Enregistrement

Deux questions se posent : que contient un bon enregistrement, et où se trouve-t-il ? Un enregistrement utile s’appuie sur des preuves (ce qui s’est passé, ce que cela a coûté), comporte une étiquette issue d’un vocabulaire fixe afin de permettre la comparaison ultérieure des enregistrements, et se termine par une proposition d’étape suivante. Quant à l’endroit où il est stocké, chaque option présente un véritable compromis : les fichiers de mémoire (durables et faciles à consulter, mais privés et peu structurés), un stockage MCP (partagé et consultable, mais nécessitant un serveur), les journaux/traces (automatiques et exhaustifs, mais où le signal est noyé dans le bruit), les tickets (exploitables et visibles par l’équipe, mais lourds à gérer par élément), ou encore les commits et PR balisés, par exemple unework-material-frictionétiquette associant la friction à la modification exacte, bien que cela ne s’applique que lorsque le travail est intégré au contrôle de version. Rien de tout cela n’est spécifique au code : le journal des comptes d’une équipe média ou l’historique annoté d’une file d’attente d’assistance constituent également des substrats d’enregistrement. Une mise en garde s’applique à tout support sur lequel les agents s’appuient par la suite : la mémoire écrite par les agents constitue une surface d’attaque et de dérive identifiée (OWASP Agentic Top 10, ASI06), ce qui plaide en faveur d’écritures justifiées par des preuves et soumises à révision.

Étape 4 : Récolte

Si ce frottement n’apparaît que lors d’une seule session, il s’agit d’un bruit ; s’il se répète sur huit sessions, il s’agit d’un problème de processus. Le choix stratégique se pose entre le trace-mining (relecture des transcriptions brutes : complet, mais coûteux et très intrusif en matière de confidentialité) et l’agrégation d’artefacts (analyse des enregistrements délibérément consignés : peu coûteux, mais dont l’efficacité dépend de la rigueur de la phase 3) ; les véritables pipelines combinent les deux. Viennent ensuite la cadence (un balayage programmé par opposition à une collecte en fin de session) et le travail peu glamour de la déduplication : la même friction formulée de cinq façons différentes par cinq personnes doit se résumer à un seul schéma avec un décompte honnête. C’est lors de la collecte que la valeur apparaît, car c’est l’agrégation qui redéfinit les priorités : un désagrément de cinq minutes que personne ne corrigerait individuellement représente, une fois agrégé, un coût majeur pour l’équipe.

Étape 5 : Synthèse et ciblage

Deux étapes. Regroupement et notation : regroupez les résultats en tendances, classées selon leur fréquence × leur coût ; c’est à cela que servent les schémas de classification ci-dessous. Cibler le niveau approprié : orienter chaque tendance vers le niveau de correction adéquat, du plus éphémère au plus structurel (mémoire → compétence/invite → environnement et configuration → documentation → le support de travail lui-même → processus → outil ou fournisseur en amont). Si vous visez trop bas (une note de mémoire privée pour ce qui est en réalité un document d’équipe manquant), les frictions réapparaissent pour tout le monde ; si vous visez trop haut (une nouvelle compétence pour un cas ponctuel), vous alourdissez un artefact jusqu’à ce qu’il ne soit plus lu. Le domaine a convergé indépendamment vers le même gradient : réduire l’importance de la mémoire éphémère, privilégier l’apprentissage durable via le contrôle de version — la documentation de Windsurf/Devin recommande de transformer les leçons récurrentes en règles ou dans le fichier AGENTS.md (le fichier d’instructions permanentes lu par les agents) plutôt que de s’appuyer sur des mémoires automatiques, les recommandations du Codex d’OpenAI indiquent que le fait de commettre deux fois la même erreur justifie une mise à jour d’AGENTS.md, et la mémoire de Copilot expire au bout de 28 jours par conception : la mémoire non promue doit disparaître. Un jugement de synthèse est facile à négliger : toute friction n’est pas nécessairement un gaspillage. Une partie de ces frictions constitue la surface de contrôle : « la friction est ce qui est nécessaire… pour diriger » (résumé de l’intervention de Ronacher à l’AIE Europe), de sorte que le triage implique de décider s’il faut conserver ou supprimer, et pas seulement corriger.

Étape 6 : Boucler la boucle

Le véritable test portant sur l’ensemble du cycle de vie : ce type de friction tend-il à diminuer au fil des sessions suivantes ? Une correction signalée mais qui n’est jamais mise en œuvre, ou qui l’est sans rien changer, n’est que de la poudre aux yeux. C’est le principe du Feedback Flywheel de Garg et le fondement de l’ingénierie cumulative : chaque correction facilite l’unité de travail suivante, à condition que la boucle se referme réellement.

Les boucles nommées, par niveau d’exploitation

Les spécialistes du domaine s’accordent sur ce cycle de vie, qu’ils désignent sous au moins une demi-douzaine de noms différents. Tous ces termes sont valables ; rien sur cette page ne vient les remplacer. Le seul critère de tri utilisé dans ce tableau est le niveau auquel chaque boucle opère — et voici ce qu’il convient de retenir une fois le tri effectué :

Boucle	Diffusé à	Permet de boucler la boucle en
Ingénierie des boucles / Ingénierie des composés	un praticien	règles personnelles, consignes, guides pratiques
agent-retro	une séance	modifications des compétences et des paramètres par session, à partir de la transcription
Capteurs d’ingénierie des faisceaux de câbles (Thoughtworks)	l’infrastructure d’une base de code (la structure qui entoure le modèle)	intégrer les outils de retour d’information natifs (tests, linters, CI) dans la boucle de l’agent
Rêver (Anthropic, OpenAI)	la mémoire d’une plateforme	Extraction, pendant les temps morts, de l’historique des sessions sous forme de différences de mémoire segmentées, à l’échelle de la flotte
Moteur LangSmith / Thèmes Braintrust	une pile d’observabilité	regrouper les défaillances de production par problème, rédiger des demandes de modification (PR) et des évaluations
Signaux d’usine	une plateforme unique pour les agents	détection des schémas de friction au cours des sessions et création automatique de tickets
Aperçu de la session gh-aw (GitHub)	les sessions d’une plateforme	rapports automatisés d’analyse des sessions pour l’exécution des workflows des agents (exemple de 50 sessions)
Rétroaction en boucle fermée (Garg)	les artefacts d’une équipe	intégrer les enseignements tirés dans les documents de configuration, les commandes, les guides de procédure et les mesures de sécurité

Relisez la colonne du milieu : un praticien, une session, une plateforme, une pile. Presque toutes les boucles du domaine fonctionnent en solo ou au niveau de la flotte : une personne et son agent, ou un fournisseur et l’ensemble de sa base installée. Seul le « flywheel » de Garg s’étend à l’équipe, et sa liste de cadence mentionne le lieu (un point à l’ordre du jour de la rétrospective de sprint existante) sans pour autant le mettre en œuvre. Telle est notre interprétation de ce type de situation, et c’est là que transparaît l’angle propre à ce guide : le niveau de l’équipe est la couche ouverte — de nombreuses personnes, de nombreux agents, plusieurs outils, avec les responsables des corrections participant à la même conversation. Si vous exécutez l’une des boucles ci-dessus, continuez à le faire ; la couche « équipe » exploite leurs résultats, elle n’entre pas en concurrence avec eux.

Les systèmes de classification

Pour regrouper les points de friction, il vous faut des catégories, et les schémas de ces domaines classent des éléments différents ; il s’agit moins de rivaux que d’outils destinés à aborder des questions différentes :

Schéma	Ce qu’il classe	Forme	Fiabilité / origine
MAST	Comment les systèmes multi-agents échouent	14 modes / 3 catégories	150 traces examinées par des experts, validées sur plus de 1 600 ; coefficient κ inter-annotateurs = 0,88
École d’analyse des erreurs (Husain/Shankar)	quelles que soient les traces que vous laissez	à réponse libre ; les catégories se dégagent de vos données	une méthodologie, et non un ensemble figé ; l’analyse de vos traces constitue « l’activité la plus importante dans le cadre des évaluations »
Quatre couches (Greyling)	quelle couche de la pile a échoué	4 couches	synthèse des rapports de défaillance sur le terrain ; environ 9,9 % des défaillances sont attribuées au raisonnement du modèle
TraceProbe	actions de gestion des erreurs dans les traces	9 actions	analyse automatisée des traces
Signaux d’usine	quel symptôme de frottement une séance révèle-t-elle ?	7 types de signaux	sessions de codage en production
Notre vocabulaire relatif aux causes profondes	pourquoi ces tensions sont apparues au sein de la collaboration	10 étiquettes / 5 groupes ; le groupe code l’altitude fixe	séances de travail, développeurs et non-développeurs ; fiabilité inter-évaluateurs non encore mesurée : l’expérience est en cours, et le vocabulaire fait l’objet d’un contrôle de version et peut être révisé

agent-errorDeux remarques concernant la lecture. Premièrement, les axes sont bel et bien distincts : les schémas de symptômes (les signaux de Factory) vous indiquent qu’une session s’est mal déroulée ; les schémas de couches (Four-Layer) vous indiquent à quel niveau de la pile ; un vocabulaire des causes vous explique pourquoi, ce qui permet à une étiquette de tracer en partie la voie de sa propre résolution (unwork-material-frictionconstat renvoie au matériel lui-même — dette technique dans le code, ou un compte, un tableau ou un modèle enchevêtré en dehors de celui-ci ; une étiquette de briefing renvoie au processus). Deuxièmement, la tension entre l’universel et l’émergent est bien réelle : les taxonomies fixes garantissent la comparabilité et la fiabilité mesurable de l’étiquetage (le κ = 0,88 de MAST sert de référence), tandis que les catégories émergentes s’adaptent à votre répartition réelle des défaillances. Un juste milieu viable consiste à conserver un petit vocabulaire fixe pour l’agrégation, accompagné de notes de justification ouvertes sous chaque étiquette. Et une mise en garde que l’ensemble du domaine a méritée : les étiquettes de type « -style » devraient être l’exception, et non la règle. L’école d’ingénierie des harnais rejette explicitement ce réflexe, selon lequel l’ingénieur impute la faute au modèle et la classe dans la catégorie « attendre la prochaine version » ; il faut plutôt corriger le harnais (Osmani, Agent Harness Engineering). L’analyse en quatre couches n’attribue qu’environ 9,9 % des échecs au raisonnement du modèle.

Localisez-vous

Un bref bilan. Passez en revue les différentes étapes et cochez ce que vous avez déjà :

• Vous disposez de traces ou de journaux de session (outils d’observabilité, fichiers JSONL sur disque, historique côté serveur) → La détection et l’enregistrement sont pris en charge. Les chiffres de LangChain indiquent que c’est là que la plupart des équipes s’arrêtent.
• Un élément rappelle à l’agent de consigner les frictions (une compétence, un point d’arrêt, une convention relative aux fichiers de contexte) → L’instrumentation est prise en charge ; si rien ne le fait, c’est généralement la première solution la moins coûteuse.
• Vous mettez à jour AGENTS.md / CLAUDE.md lorsqu’un événement se répète → vous effectuez une synthèse au niveau individuel, ce qui correspond au schéma « commettre deux fois la même erreur » du Codex.
• Votre plateforme organise vos souvenirs à votre place (consolidation de type « Dreaming », mémoire « Copilot ») → collecte et synthèse à l’échelle de la flotte, au sein de cette plateforme.
• Votre pile d’observabilité regroupe les défaillances et les propositions de correction (Engine, Topics, Signals) → Synthèse au niveau de la pile, pour le trafic que celle-ci détecte.
• Une personne passe régulièrement en revue les différentes sessions, les personnes et les outils, puis les responsables des solutions décident ensemble → Collecte et synthèse au niveau de l’équipe. Il s’agit de la ligne que la plupart des équipes laissent vide.

D’après nos observations, la lacune courante réside dans cette dernière ligne : la vue d’ensemble couvrant à la fois les outils et les personnes, ainsi que les décisions qu’elle implique : conserver ou supprimer, à quel niveau, quelle priorité. Notez la question relative au périmètre de l’examen qui en découle : quel travail doit être regroupé dans un même ensemble pour faire l’objet d’une seule discussion ? Le dépôt, le produit, le compte publicitaire, la boîte de réception du support, l’engagement client ? Définissez le périmètre en fonction de l’endroit où les corrections seraient mises en œuvre, et veillez à ce que les cas hors code soient traités aussi naturellement que ceux liés au code.

La suite de ce guide aborde ces différents aspects un par un : la section introduction présente le sujet sous forme narrative ; les chapitres suivants traitent de la capture des frictions sur le vif, de la synthèse entre les sessions, de la décision d’altitude et de ce à quoi ressemble un lieu de travail au niveau de l’équipe dans la pratique. Commencez là où se trouve votre ligne vide.

Chapitre suivant : À quoi ressemble un bon rapport de friction — la saisie en temps réel, les étiquettes indiquant les causes profondes et les règles de « ne jamais consigner ».