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 le récit, commencez par 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 particulier 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 de tout cela n’implique d’adopter nos pratiques, 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 trouve une solution de contournement, la session prend fin, et la session suivante se heurte au même obstacle. Les modèles de friction de Rahul Garg définissent le coût de premier ordre (la boucle de frustration « générer → examiner → 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 instrumentent 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 toutefois 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é	n/a
1 · Détection	Comment perçoit-on le frottement ?	autocontrôle · révision 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	n/a
3 · Enregistrement	Comment est-ce enregistré, et où ?	mémoire · magasin MCP · journaux/traces · tickets · commits marqué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	n/a
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 ?	mesurer la tendance	Volant d’inertie à rétroaction, ingénierie de la multiplication d’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 écrire 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’autocontrôle (l’agent reconnaît ses propres tentatives de réessai et ses retours en arrière) est la méthode 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 le plus répandu : une étude de production 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, 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 passent inaperçues : personne n’a demandé à l’agent de vérifier.

Étape 3 : Enregistrement

Deux questions : que contient un bon enregistrement, et où est-il stocké ? Un enregistrement utile s’appuie sur des preuves (ce qui s’est passé, ce que cela a coûté), porte une étiquette issue d’un vocabulaire fixe afin que les enregistrements soient comparables ultérieurement, et se termine par une proposition d’étape suivante. Quant à son emplacement de stockage, chacun présente un véritable compromis : fichiers en mémoire (durables et faciles à consulter, mais privés et peu structurés), un stockage MCP (partagé et consultable, mais nécessitant un serveur), journaux/traces (automatiques et complets, 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 les commits et PR balisés, par exemple une work-material-frictionétiquette associant la friction au changement précis, 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 d’un compte d’é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’appuieront ultérieurement : 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 (relire les transcriptions brutes : complet, mais coûteux et très intrusif en matière de confidentialité) et l’agrégation d’artefacts (passer au crible les enregistrements délibérément rédigés : peu coûteux, mais dont l’efficacité dépend de la rigueur de l’étape 3) ; les véritables pipelines combinent les deux. Viennent ensuite la cadence (un balayage programmé par opposition à une collecte en fin de séance) 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 : une nuisance de cinq minutes que personne ne corrigerait individuellement représente un coût majeur pour l’équipe une fois cumulée. Pour un exemple concret de collecte entre personnes plutôt qu’entre sessions, découvrez comment cinq d’entre nous avons mis en commun nos souvenirs personnels de Claude Code pour en faire des règles partagées.

Étape 5 : Synthèse et ciblage

Deux étapes. Regroupement et notation : regroupez les résultats en modèles, classés 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 : dévaloriser la mémoire éphémère, privilégier l’apprentissage durable via le contrôle de version. Les documents de Windsurf/Devin recommandent de transformer les leçons récurrentes en règles ou dans AGENTS.md (le fichier d’instructions permanentes que les agents lisent) plutôt que de se fier à la mémoire automatique, 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 un gaspillage. Une partie de celle-ci constitue la surface de contrôle : « la friction est ce qui est nécessaire… pour diriger » (pour résumer l’intervention de Ronacher à l’AIE Europe) ; le triage implique donc 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 ce que Garg appelle la « Feedback Flywheel » (roue d’inertie de rétroaction) et c’est le principe même de l’« ingénierie cumulative » : chaque correction facilite la tâche suivante, à condition que la boucle se referme réellement.

Les boucles nommées, par niveau d’exploitation

La communauté s’est mise d’accord sur ce cycle de vie, qui porte au moins une demi-douzaine de noms différents. Tous sont valables ; rien sur cette page ne vient se substituer à l’un d’entre eux. 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
Loop Engineering / Ingénierie des composés	un praticien	règles personnelles, consignes, guides pratiques
apprentissage-continu-v2 (Everything Claude Code)	un praticien	un agent d’arrière-plan qui transforme les journaux d’appels des outils en règles associées à un score de confiance, chargé au début de la session
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
Dreaming (Anthropic, OpenAI)	la mémoire d’une plateforme	Extraction, pendant les périodes d’inactivité, de l’historique des sessions sous forme de différences de mémoire segmentées, à l’échelle de la flotte
Moteur LangSmith / Thèmes abordés par 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 difficultés rencontrées lors des sessions et création automatique de tickets
Statistiques sur les sessions gh-aw (GitHub)	les sessions d’une plateforme	rapports automatisés d’analyse des sessions pour les exécutions de flux de travail des agents (exemple de 50 sessions)
Volant d’inertie à rétroaction (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 au niveau individuel 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 à la faire fonctionner ; la couche « équipe » exploite ses résultats, elle n’entre pas en concurrence avec elles.

« Everything Claude Code » (ECC), un projet sous licence MIT, est l’exemple le plus parlant de la carte illustrant une boucle locale dans laquelle l’agent rédige ses propres règles. Sa compétence « continuous-learning-v2 » (ECC 2.2.3 à la date de rédaction) enregistre les appels d’outils via un hook Claude Code. Un agent observateur fonctionnant en arrière-plan sur Haiku lit périodiquement ce journal et rédige des « instincts » : de courtes règles « déclencheur-action », chacune dotée d’un score de confiance qui augmente lorsque le motif est à nouveau observé et qui diminue de semaine en semaine lorsqu’il ne l’est pas. Au début d’une session, par défaut, jusqu’à six instincts présentant un niveau de confiance de 0,7 ou plus sont directement intégrés au contexte de l’agent, sans étape de révision. L’observateur est livré désactivé ; son activation constitue donc un choix délibéré. Pour la configuration d’une seule personne, il s’agit d’une boucle complète. Pour un contexte sur lequel repose toute une équipe, nous contrôlerions plutôt les écritures : les données sont librement intégrées, les règles sont validées après examen.

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 de l’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 présente	7 types de signaux	sessions de codage en production par les agents
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 des versions et peut être révisé

Deux remarques concernant la lecture. Premièrement, les axes sont réellement 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 correction (un work-material-frictionconstat renvoie au matériel lui-même : dette technique dans le code, ou un compte, un tableau de bord 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 à code ouvert sous chaque étiquette. Et une mise en garde que l’ensemble du domaine a méritée : les étiquettes de type « agent-error-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.
• Quelque chose 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 corrections prennent une décision commune → 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 à la portée 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 la portée en fonction de l’endroit où les corrections seraient mises en œuvre, et assurez-vous que les cas hors code soient acheminés aussi naturellement que ceux liés au code.

La suite de ce guide aborde ces différents aspects un par un : l’introduction présente l’histoire sous forme narrative ; les chapitres suivants traitent de la manière de saisir les frictions sur le vif, de la capitalisation des acquis d’une session à l’autre, du choix de l’altitude, ainsi que de ce à quoi ressemble concrètement un lieu de rencontre au niveau de l’équipe. Commencez là où se trouve votre ligne vide.

Chapitre suivant : Les caractéristiques d’un bon rapport de friction : la saisie de l’instant présent, l’identification des causes profondes et les règles relatives aux événements à ne jamais consigner.