Comment recueillir les retours d'expérience de vos agents IA

Un agent IA vous a livré du code cette semaine. Il a lu votre brief, a passé au crible la base de code, s’est heurté à un obstacle dû à une documentation erronée, a deviné comment le contourner et a poursuivi son travail. Puis la session s’est terminée, et tout ce qu’il avait appris sur les points de difficulté de votre projet a disparu avec elle. Personne n’a demandé au seul participant qui venait de passer une heure dans votre dépôt ce qui le ralentissait.

Les rétrospectives ont justement pour but de combler ce fossé pour vos collaborateurs : l’équipe se réunit, identifie ce qui a été utile et ce qui a constitué un obstacle, puis en tire des enseignements pour évoluer. Les agents IA effectuent désormais un véritable travail au sein de votre équipe, et ils se heurtent aux mêmes difficultés que vos collaborateurs, voire parfois davantage. La question est donc simple. Si un agent effectue le travail de l’équipe, pourquoi n’est-il pas présent lors de la rétrospective ?

Ce guide vous explique comment intégrer cette nouvelle perspective. Il ne s’agit ni d’un nouveau format de rétrospective, ni d’automatiser les contributions de vos collaborateurs : il s’agit d’un nouveau participant. L’IA apporte son point de vue ; c’est toujours votre équipe qui décide de ce que cela signifie. Voici comment recueillir ces informations et comment les intégrer à la rétrospective que vous organisez déjà.

Cet article constitue une introduction rapide. Cette pratique dispose désormais d’un guide complet, Rétrospectives des agents IA, qui couvre l’ensemble du cycle, de la collecte des informations à la cérémonie d’équipe ; commencez par ici, puis rendez-vous là-bas pour avoir une vue d’ensemble.

Pourquoi il est utile de consigner l’expérience de votre agent IA

L’argument en faveur d’un « retro » humain est que la mémoire s’estompe et que les leçons ne sont pas partagées. Avec un agent d’IA, le problème est encore plus aigu : sa mémoire de travail ne s’estompe pas, elle s’évapore. Dès qu’une session se termine, le contexte disparaît. Rien de tout cela n’est reporté à la session suivante, à moins que quelqu’un ne le consigne par écrit : le fichier README manquant qu’il aurait souhaité voir exister, la variable d’environnement qui n’a pas été documentée, le briefing qui aurait pu être interprété de trois façons différentes.

Et les agents accumulent un type de signal spécifique et utile. En une heure de travail, un agent remarque des éléments qu’une personne ne voit pas, car celle-ci a déjà le contexte en tête :

• Le document d’intégration qui décrit une étape de compilation qui n’existe plus.
• La fonction étant utilisée différemment par ces trois points d’appel, l’expression « suivre le modèle » renvoie donc à trois modèles.
• Le brief qui disait « nettoyer la configuration » sans préciser de quelle configuration il s’agissait, ni comment la nettoyer.
• La suite de tests qui nécessite l’exécution d’un service dont rien ne vous indique qu’il faille le démarrer.

Un développeur humain se heurte lui aussi à ces problèmes, hausse les épaules, trouve des solutions de contournement et signale rarement quoi que ce soit, car ces frictions restent en dessous du seuil à partir duquel « cela vaut la peine d’être évoqué en réunion ». Un agent, si on lui pose la question de la bonne manière, signalera chacun d’entre eux, en joignant les preuves. C’est là que réside la valeur : non pas que l’IA comprenne mieux votre processus, mais qu’elle apporte un regard neuf, sans ego et sans tolérance accumulée face à ces petits désagréments. La collaboration entre l’humain et l’IA fonctionne mieux lorsque les deux parties peuvent exprimer ce qui les a ralenties.

Une mise en garde avant d’aller plus loin, car elle conditionne tout ce qui suit. L’IA est un participant, jamais un animateur ni un juge. Elle apporte des éléments à la rétrospective comme le ferait n’importe quel participant. Elle ne dirige pas la réunion, n’évalue pas votre équipe et ne décide pas de ce qu’il faut corriger. Ce sont les humains qui lisent ses retours, en vérifient la pertinence et choisissent ce qui compte. Respectez cette limite et la pratique restera saine ; brouillez-la et vous aurez confié votre processus d’amélioration à un outil qui ne peut être tenu responsable du résultat.

L’entraînement : une rétrospective de fin de session

Ce mécanisme est volontairement simple. À la fin d’une session de travail (une tâche de programmation, un travail de recherche, une refactorisation), l’agent rédige une brève note de rétrospective sincère dans un fichier du dépôt sur lequel il travaillait. Cela prend moins d’une minute à l’agent. Un humain passe à peu près le même temps à vérifier que tout est correct. Voilà tout le cycle.

Une bonne entrée se compose de quatre parties :

1. Ce qui s’est bien passé : les moments qui méritent d’être retenus, en référence à un événement concret survenu au cours de la séance. Pas de compliments, pas de remplissage. Si cela ne peut pas renvoyer à un moment précis, cela ne doit pas figurer dans le compte-rendu.
2. Friction : les situations où le travail s’est avéré plus difficile que nécessaire. Chaque élément de friction est associé à l’une des dix étiquettes de cause première prédéfinies (ci-dessous) et se termine par une mention de la taille d’un ticket « → Solution : », c’est-à-dire la règle qui permet d’y remédier. Pas de constat sans solution.
3. Une solution prioritaire « À faire en premier » : la seule modification qui aurait été la plus utile. Un élément mis en avant, afin qu’un lecteur pressé qui ne lit rien d’autre puisse prendre connaissance de ce qui compte vraiment.
4. Hypothèses formulées : chaque passage où l’agent a comblé une lacune par une supposition. Ce sont des pépites. Une hypothèse correspond à un endroit où votre contexte était ambigu ou incomplet ; l’agent vous montre exactement où il a dû inventer une réponse.

Deux principes garantissent la fiabilité des contributions. Uniquement des exemples étayés : chaque point fait référence à un événement réel, ce qui évite de lire des conseils génériques. Et l’honnêteté va dans les deux sens : l’agent critique à la fois le contenu qui lui a été remis et ses propres erreurs. Une contribution qui se contente de blâmer le code et qui ne dit jamais « J’ai mal lu cela et j’ai perdu vingt minutes » n’est pas honnête ; cette pratique exige les deux.

Les dix étiquettes de causes profondes

Chaque élément source de friction se voit attribuer exactement une étiquette. C’est grâce à un vocabulaire restreint et fixe qu’un ensemble de griefs individuels se transforme en un schéma sur lequel vous pouvez agir : lorsque la même étiquette revient au cours de dix sessions, vous savez sur quoi consacrer votre prochaine heure. Ces dix étiquettes couvrent les différents obstacles qui entravent le travail concret.

Étiquette	Ce que cela signifie	L’endroit où la solution se trouve généralement
ambiguous-instruction	Ce mémoire pouvait être interprété de plusieurs façons.	La personne qui rédige l’exercice
missing-context	Les informations dont l’agent avait besoin n’ont pas été fournies.	Le cahier des charges, ou le contexte commun
incorrect-context	Les informations qui vous ont été fournies étaient erronées ou obsolètes.	Le cahier des charges, ou le contexte commun
missing-documentation	Le dépôt ne mentionne pas un élément qu’il devrait mentionner.	Les documents / CLAUDE.md / AGENTS.md
incorrect-documentation	La documentation existe, mais elle est erronée ou obsolète.	Les documents / CLAUDE.md / AGENTS.md
work-material-friction	La nature du travail à effectuer a rendu cette modification difficile (code, compte ou modèle enchevêtré).	Le carnet de commandes / le carnet de dette technique
missing-access-or-tool	Un identifiant, une autorisation ou un outil n’était pas disponible.	Opérations / plateforme / contrôle d’accès
agent-error	L’agent s’est trompé : mauvaise interprétation, mauvais choix, effort inutile.	Le récit de l’agent lui-même, en toute sincérité
changed-requirements	Le but a été marqué à mi-parcours de la séance.	Planification / gestion du périmètre
environment-friction	L’environnement de développement a riposté : compilation instable, configuration lente, outils défaillants.	Expérience des développeurs

(La version 2 des compétences a codebase-frictionété renommée work-material-friction; les entrées plus anciennes portant l’ancienne dénomination sont toujours considérées comme relevant de la même catégorie.)

Remarquez comment les étiquettes répartissent clairement les responsabilités. Certaines renvoient à vous : ambiguous-instruction, missing-context. D’autres renvoient au projet : missing-documentation, work-material-friction, environment-friction. Et agent-errorrenvoie à l’acteur. C’est justement cette répartition qui fait toute la différence : elle empêche le journal de se transformer en une liste de reproches et en fait une carte indiquant où des améliorations sont nécessaires, de part et d’autre.

Le journal : au format Markdown simple, dans votre dépôt

Il n’y a aucun produit à installer pour l’étape de capture. L’agent écrit dans docs/ai-retros/entries/au format Markdown brut, dont les modifications sont validées en même temps que le code. Il s’agit d’un choix délibéré :

• Tout se passe là où le travail a été effectué. C’est dans ce dépôt que les désaccords ont eu lieu ; c’est également là que se trouve la trace de ceux-ci. Toute personne consultant l’historique Git peut voir les commentaires à côté de la modification qui les a suscités.
• Ces données peuvent être comparées et analysées à l’aide de grep. Vous souhaitez obtenir tous les élémentsmissing-documentation du mois dernier ? C’est tout simplegrep. Vous voulez observer la baisse de la friction après avoir corrigé la version ? Tout est dans le système de contrôle de version.
• Ce système est indépendant de tout outil. Le Markdown dans un dossier fonctionne avec n’importe quel agent, n’importe quel éditeur, n’importe quel processus. Il n’y a rien de propriétaire, rien à migrer par la suite.

Voici un exemple d’entrée à titre d’illustration. Il s’agit d’une session fictive destinée à montrer la structure du fichier, et non de données réelles de pilotage :

# Session retro — add rate limiting to the public API
Agent: Claude Code · 2026-07-13 · ~50 min

## Do this first
→ Fix: Document the Redis connection setup in CLAUDE.md — three of us
  will hit this same wall. (missing-documentation)

## What went well
- The `middleware/` folder has a clear pattern; the existing auth
  middleware was a clean model to copy for the rate limiter.
- Tests ran fast once the service was up.

## Friction
- Nothing documented that the test suite needs Redis running locally.
  Spent ~15 min chasing a connection error before finding it by reading
  docker-compose.yml. (missing-documentation)
  → Fix: Add a "Running tests locally" section to CLAUDE.md naming the
    Redis dependency and the `docker compose up redis` command.
- The brief said "add sensible rate limits" without numbers. I chose
  100 req/min per key. (ambiguous-instruction)
  → Fix: Decide the real limits with the team and put them in the ticket.
- `config/limits.ts` and `config/throttle.ts` both looked like the right
  home for the setting; I couldn't tell which was canonical. (work-material-friction)
  → Fix: Merge or clearly comment which config owns rate limiting.

## Guesses I made
- Assumed 100 req/min because the payment endpoints use that. May be
  wrong for read-heavy public endpoints — please check.
- Assumed rate-limit responses should be 429 with a Retry-After header.

Considérez cela comme une note de participant, car c’est bien de cela qu’il s’agit. Elle est précise, elle présente ses propres hypothèses, et chaque problème s’accompagne d’une étape suivante.

Intégrer cela à la rétrospective de votre équipe

Les entrées individuelles constituent la matière première. Avant votre réunion rétrospective, une étape de synthèse complémentaire passe en revue les entrées enregistrées depuis la dernière fois et produit une synthèse d’une page pour la réunion : les frictions qui se sont répétées, les principales solutions regroupées par étiquette, les hypothèses qui reviennent sans cesse au même endroit. Ce résumé est soumis aux mêmes critères que les entrées (pas d’éloges ni de remplissage, pas de constat sans solution), et son honnêteté va dans les deux sens : il critique les entrées qui lui ont été fournies (preuves insuffisantes, solution trop vague pour être mise en œuvre) avec la même facilité qu’il les résume.

Puis la partie humaine, qui ne change pas :

1. Lisez le document d’information avant la rétrospective : considérez-le comme la lecture préparatoire d’un participant parmi d’autres, et non comme l’ordre du jour.
2. Placez le ou les deux premiers éléments sur le tableau, à côté de ce que vos collaborateurs ont apporté. Désormais, la notemissing-documentation de l’IA figure aux côtés de celle d’un collègue indiquant « l’intégration m’a pris une semaine », et vous pouvez constater qu’il s’agit du même problème.
3. Discutez-en et prenez une décision en équipe. L’agent a soulevé la question ; ce sont les personnes présentes dans la salle qui décident de la suite. Vous donnerez suite à certaines questions, vous en mettrez d’autres de côté, et vous ne serez pas d’accord avec d’autres encore. Tout cela est tout à fait normal : il s’agit ici de la contribution d’un participant, et non d’un système qui impose sa volonté.

Il existe deux façons de mener à bien cette dernière étape, et la première ne coûte rien :

• Avec n’importe quel outil de rétrospective. Le document de référence n’est qu’un simple document. Lisez-le avant la réunion, ajoutez le ou les deux points principaux au tableau que vous utilisez, y compris les post-it. Toute la méthode fonctionne ainsi, de bout en bout, sans TeamRetro ni aucun autre produit spécifique.
• Avec TeamRetro, l’agent publie lui-même ses messages. Si votre équipe organise ses rétrospectives dans TeamRetro, l’agent peut préparer ses recommandations à partir du journal et, après votre confirmation pour chaque élément, les publier via le serveur MCP de TeamRetro : éléments en attente pour votre prochaine rétrospective, actions à mener lorsqu’une correction a déjà un responsable, ou idées proposées directement sur un tableau de travail. Chaque élément publié est précédé du préfixe [AI retro], afin que l’ensemble des participants puisse identifier qui l’a soulevé. C’est là toute la différence en une ligne : au lieu que ce soit vous qui transmettiez les retours de l’IA lors de la réunion, c’est le participant qui les soumet lui-même.

Commencez en 10 minutes environ

L’ensemble est open source sous licence MIT. Le dépôt TeamRetro-skills couvre les deux voies : ai-session-retro(rédaction de l’entrée de fin de session) et ai-retro-brief(synthèse des entrées dans le compte-rendu pré-rétrospective) ne nécessitent aucun produit, tandis que teamretro-post-recommendationsajoute le parcours de publication pour les équipes TeamRetro. Un ensemble de questions indépendantes de l’outil vient compléter le tout.

Pour commencer :

1. Clonez le dépôt et ajoutez les compétences à votre configuration Claude Code, ou récupérez le pack de prompts si vous utilisez un autre outil.
2. Vous n’utilisez pas Claude Code ? Ce pack de prompts est conçu pour fonctionner avec Cursor, GitHub Copilot ou tout autre agent auquel vous pouvez transmettre un prompt système : même format en quatre parties, mêmes dix étiquettes, même principe « pas de résultat sans solution ».
3. Effectuez une session avec cet outil activé. À la fin, lisez l’entrée qu’il a générée. C’est généralement lors de cette première lecture que le déclic se produit : l’agent aura mis le doigt sur un aspect de votre projet que vous connaissiez vaguement mais que vous n’aviez jamais consigné par écrit.

Indiquez aux entrées un dossierdocs/ai-retros/entries/ situé dans le dépôt de votre choix où travaillent vos agents, validez-les, et vous êtes prêt à commencer.

Des limites honnêtes

Il s’agit d’un cabinet récent qui gagne la confiance de ses clients en faisant preuve de franchise sur ce qu’il ne peut pas faire.

• Une IA ne peut pas détecter toutes ses propres erreurs. Certaines agent-errorfrictions sont invisibles pour l’agent qui les a provoquées. Elle ignore ce qu’elle ignore. La vérification humaine n’est pas une simple option facultative ; c’est grâce à elle que les angles morts sont repérés. C’est pourquoi l’IA reste un participant et n’est jamais le juge.
• Une seule entrée ne constitue qu’une anecdote. Il vous faut environ cinq entrées avant que les tendances ne prennent tout leur sens. Les difficultés rencontrées lors d’une seule session peuvent simplement être dues à un coup de malchance ; en revanche, si la même étiquette revient cinq fois, c’est un signe. Attendez quelques semaines avant de tirer des conclusions.
• L’agent rend compte de son expérience, et non de la réalité objective. Lorsqu’il indique que la documentation est erronée, vérifiez : il arrive parfois que la documentation soit correcte et que l’agent l’ait mal interprétée. Cela reste utile (car cela signifie que la documentation prête à confusion), mais la solution à apporter est différente.
• Des briefs médiocres donnent lieu à des entrées médiocres. Cette pratique met en évidence les points de friction ; elle n’invente pas de perspicacité là où il n’y en avait pas. Une session avec un brief clair et un dépôt bien structuré produit une entrée courte et ennuyeuse, ce qui est tout à fait normal.

Rien de tout cela ne remet en cause votre argumentation. Vos agents IA font déjà le travail et se heurtent déjà à des limites. La seule question est de savoir si vous vous en rendez compte. Accordez-leur une minute à la fin de la session pour qu’ils s’expriment, lisez leurs commentaires à la lumière de votre jugement humain, puis intégrez les remarques sincères dans la rétrospective que vous organisez déjà. C’est là que la contribution d’un participant a toute sa place : aux côtés de vos collaborateurs.

Nous avons effectué tout le circuit avec notre équipe, agents compris. Découvrez ce qui s’est passé lorsque nos coéquipiers IA se sont joints à notre rétro.

---

Vous créez des fichiers de contexte pour vos agents ? Découvrez pourquoi l’ingénierie de contexte nécessite une boucle de rétroaction. Et si vous débutez dans l’organisation de rétrospectives, commencez par lire comment organiser une rétrospective agile.