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 cahier des charges, a épluché 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 avait ralenti le processus.

Les rétrospectives ont justement pour but de combler ce fossé pour vos collaborateurs : l’équipe se réunit, identifie ce qui a aidé 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, parfois même 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 porte sur l’intégration de cette « voix ». Il ne s’agit ni d’un nouveau format de rétrospective, ni d’automatiser les contributions de vos collaborateurs, mais bien d’un nouvel intervenant. 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à.

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 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. Le fichier README manquant qu’il aurait souhaité voir exister, la variable d’environnement qui n’était pas documentée, le brief qui aurait pu être interprété de trois façons différentes : rien de tout cela n’est reporté à la session suivante, à moins que quelqu’un ne le note.

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, « 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 dans quelle mesure il fallait 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 — 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 au mieux lorsque les deux parties peuvent exprimer ce qui les a ralenties.

Une mise au point avant d’aller plus loin, car cela 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 séance

Ce mécanisme est volontairement simple. À la fin d’une session de travail — qu’il s’agisse d’une tâche de programmation, d’un travail de recherche ou d’une refactorisation —, l’agent rédige une brève note de rétrospective 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 d’éloges, 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 qu’il n’aurait dû l’être. Chaque élément de friction est associé à l’une des dix étiquettes de cause première prédéfinies (ci-dessous) et — c’est là la règle qui rend cette méthode utile — se termine par une mention « → Solution : » de la taille d’un ticket. 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 point 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é doit être réciproque : l’agent critique à la fois le code qui lui a été confié et ses propres erreurs. Une contribution qui se contente de blâmer le code sans jamais admettre « J’ai mal lu ce passage 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 apparaît au cours de dix sessions, vous savez où 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é communiquées é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
codebase-friction	C’est le code lui-même qui a rendu cette modification difficile : une structure enchevêtrée, sans cohésion.	Le code source / le carnet de commandes de la 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 honnêteté
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é : des compilations instables, une configuration lente, des outils défaillants.	Expérience des développeurs

Remarquez comment les étiquettes répartissent clairement les responsabilités. Certaines renvoient à vous — ambiguous-instruction, missing-context. D’autres renvoient au projet — missing-documentation, codebase-friction, environment-friction. Etagent-error renvoie à 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 dansdocs/ai-retros/entries/ au format Markdown brut, qui est validé 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 discussions ont eu lieu ; c’est également là que se trouve la trace de celles-ci. Quiconque consulte l’historique Git peut voir les commentaires à côté de la modification qui les a suscités.
• Ces données sont comparables et consultables via grep. Vous souhaitez obtenir tousmissing-documentationles éléments du mois dernier ? C’est tout grepsimple. Vous souhaitez 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 le principe, 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. (codebase-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 est accompagné 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 réunion et produit un résumé d’une page destiné à 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) aussi volontiers qu’il les résume.

Et 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 note demissing-documentation 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 allez donner suite à certaines questions, en mettre 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 des participants, et non d’un système qui impose ses décisions.

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 sur le 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.
• [AI retro]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 : des éléments mis en attente pour votre prochaine rétrospective, des actions à mener lorsqu’une correction a déjà un responsable, ou des idées proposées directement sur un tableau de travail. Chaque élément publié est précédé d’un préfixe, afin que l’ensemble des participants puisse voir qui l’a soulevé. Voilà 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) etai-retro-brief (synthèse des entrées dans le compte-rendu pré-rétrospective) ne nécessitent aucun produit, tandis queteamretro-post-recommendations ajoute le parcours de publication pour les équipes TeamRetro. Un ensemble de messages-clés indépendant de tout 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. Faites une séance en l’utilisant. À la fin, lisez ce qu’il a noté. 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 mis par écrit.

Indiquez aux entrées undocs/ai-retros/entries/dossier situé dans le dépôt de votre choix où vos agents opèrent, 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. Certainesagent-error frictions sont invisibles pour l’agent qui les a générées — celui-ci ignore ce qu’il 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 pour que les tendances aient un sens. Un problème rencontré lors d’une seule session peut simplement être dû à un coup de malchance ; en revanche, si la même étiquette apparaît cinq fois, c’est un signal. 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 peut facilement prêter à 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 ne crée pas de perspicacité là où il n’y en avait pas. Une session avec un brief clair et un dépôt bien organisé 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 vous en fassent part, examinez leurs retours à la lumière de votre jugement humain, puis intégrez les éléments sincères dans la rétrospective que vous organisez déjà — aux côtés de vos collaborateurs, là où les retours des participants ont toute leur place.

---

Vous souhaitez découvrir ce qui s’est passé lorsque nous avons mis cela en pratique au sein de notre propre équipe ? Lisez Notre IA a participé à notre rétrospective — voici ce qu’elle nous a dit. 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 complètement dans l’organisation de rétrospectives, commencez par Comment organiser une rétrospective agile.