Organisation de la rétrospective sur la collaboration en matière d'IA

Chez TeamRetro, nous nous intéressons à chaque cycle d’amélioration continue mis en œuvre par une équipe. Le travail assisté par l’IA est un nouveau domaine que nous avons analysé à travers le prisme de nos rétrospectives ; ce guide présente les conclusions auxquelles nous sommes parvenus à ce jour. N’hésitez pas à vous en inspirer, à l’adapter et à le mettre en œuvre avec les outils ou les pratiques que vous utilisez déjà.

1re partie : le guide

Pourquoi cela a sa place dans une cérémonie d’équipe

Ce mois-ci, au sein de votre équipe, un assistant IA a passé quarante minutes à analyser une campagne publicitaire « défaillante » qui avait été délibérément mise en pause, car le brief ne le précisait pas. La personne en charge de la session a corrigé l’erreur, a haussé les épaules, puis est passée à autre chose. Si quatre collègues se heurtent à des versions de cette même lacune, cela représente des heures de perte de temps silencieuse par mois, et personne ne s’en rend compte, car chacun en a fait les frais seul.

C’est le schéma typique des frictions liées aux sessions d’IA : elles sont chroniques et mineures, ce qui fait qu’elles ne donnent jamais lieu à une analyse rétrospective, et elles sont éphémères, ce qui fait qu’elles disparaissent dès la fin de la session. La plupart des équipes sont déjà en mesure de les surveiller (environ 90 % d’entre elles instrumentent les traces de leurs agents), mais elles sont bien moins nombreuses à en tirer des correctifs : seules environ 37 à 52 % évaluent systématiquement ce qu’elles capturent (LangChain, juin 2026).

Les boucles d’amélioration existantes sont efficaces, et cette pratique s’appuie sur chacune d’entre elles :AGENTS.md mises à jour des fichiers de contexte, systèmes de mémoire, pipelines d’auto-amélioration des fournisseurs, analyse des erreurs à partir des traces (Husain & Shankar, FAQ sur les évaluations). Même les fournisseurs ont recours au terme « rétrospective » : les consignes de Codex d’OpenAI indiquent « lorsque Codex commet deux fois la même erreur, demandez-lui une rétrospective et mettez à jour AGENTS.md » (meilleures pratiques). Mais la quasi-totalité de ces boucles se déroulent en solo : une personne et son agent, ou une plateforme et son parc. Ce que le niveau « équipe » apporte, c’est l’agrégation : une friction qui ne représente que cinq minutes négligées par personne ne devient un coût majeur pour l’équipe que lorsqu’on la considère dans son ensemble, et y remédier (réécrire le modèle partagé, modifier le processus d’intégration, acheter l’outil) nécessite un pouvoir de décision que nul individu ne détient à lui seul. Le « Feedback Flywheel » de Rahul Garg en définit le cadre : « un point à l’ordre du jour de la rétrospective de sprint en cours : qu’est-ce qui a bien fonctionné avec l’IA lors de ce sprint ? » (martinfowler.com), et ce guide propose une manière de le mettre en œuvre.

Une concession honnête d’emblée : ce qu’il faut ici, c’est une cérémonie récurrente, impartiale et fondée sur des faits, en présence des responsables des corrections. Pour la plupart des équipes, il s’agit de la rétrospective, mais un créneau dédié à la planification des sprints, une revue mensuelle des opérations ou une revue des comptes de l’équipe médias peuvent tout aussi bien s’y prêter. La rétrospective, ou votre cérémonie existante de nature équivalente.

Bon à savoir pour un animateur : Scrum.org aborde ce même sujet sous l’angle des indicateurs ; leur guide pour mener une rétrospective de sprint lorsque la moitié de votre équipe est composée d’agents IA recadre cet événement comme une analyse, fondée sur les données, des performances des agents (réécritures de prompts, taux de déviation, consommation de jetons). Ce guide adopte une approche complémentaire : il se concentre sur les causes profondes et les solutions à l’échelle de l’ensemble de la collaboration, les agents apportant leur propre compte rendu du travail, transmis via le serveur MCP de TeamRetro si vous utilisez TeamRetro. Les équipes disposant d’un parc important d’agents pourraient souhaiter combiner des éléments des deux approches.

Comment fonctionne cette pratique, de A à Z

1. Compte rendu, par session. À la fin de chaque session importante assistée par l’IA, l’agent rédige une brève note structurée : ce qui s’est bien passé, ce qui a pris du temps (chaque point étant accompagné d’une cause première et d’une solution proposée), ce qu’il a deviné, ainsi que la solution la plus efficace. Un fichier par entrée, dans un journal partagé.
2. Synthèse, après environ 5 entrées. Avant la cérémonie, l’agent résume le journal en une note d’une page : les thèmes récurrents classés par fréquence × coût, une répartition des causes profondes, une vérification de la mise en œuvre des corrections antérieures et les trois principales actions recommandées.
3. Prenez une décision en 15 minutes. Ce point fait partie de l’ordre du jour de votre rétrospective habituelle ; il ne s’agit pas d’une nouvelle réunion. L’équipe procède à un tri : elle décide de conserver ou d’éliminer chaque source de friction, confirme où chaque solution doit être mise en œuvre et désigne des responsables pour les actions prioritaires. Le compte-rendu du cycle suivant indique si la source de friction a effectivement disparu.

Les étapes de capture et de synthèse sont implémentées sous forme de compétences d’agents open source dans notre dépôt TeamRetro-skills si vous souhaitez vous lancer rapidement.

L’agent rend compte sans filtrage : un agent qui a besoin d’une autorisation pour signaler les frictions sous-déclare, et les corrections humaines a posteriori constituent un signal additif, et non un point de contrôle sur lequel la boucle attend. La décision revient à l’équipe, et ce n’est pas une simple courtoisie : les corrections sont intégrées dans les budgets, les documents, les processus et les outils dont les membres sont responsables et pour lesquels ils doivent rendre des comptes. L’agent apporte des éléments de preuve et des propositions ; c’est l’assemblée qui décide.

À quoi ressemble un bon article ?

Voici un exemple concret, qui n’est délibérément pas une session de programmation :

# 2026-07-16: Monthly ads account review

**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped

## Went well
- Exec summary shipped in one pass; the account structure doc from last month held up

## Friction
- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

## Guesses made
- Assumed the target CPA unchanged from June, unverified

## Do this first
Campaign-status flags in the brief template. Kills the largest single time sink this month.

Remarquez la rigueur. Chaque élément de friction mentionne un moment et un coût (les estimations approximatives sont signalées par le symbole (est.)), comporte exactement une étiquette de cause première issue d’un petit vocabulaire fixe (des étiquettes telles que ambiguous-instruction, missing-context, missing-documentation, missing-access-or-tool, agent-error, ou work-material-friction, où l’élément lui-même constituait le frein : une structure de campagne enchevêtrée, une feuille de calcul héritée, un module que personne ne veut toucher, toujours en précisant le nom concret de l’élément), et se termine par une solution de la taille d’un ticket qui précise son niveau : cette solution doit-elle figurer dans une note de mémoire privée, une procédure, l’environnement, la documentation, le support de travail lui-même, le processus, ou en amont auprès d’un fournisseur ? Ce sont les étiquettes fixes qui permettent de comparer les entrées d’une personne à l’autre et d’une session à l’autre ; « la documentation prêtait à confusion » ne peut pas être agrégée, mais huit entréesmissing-documentation le peuvent. Le flou est le mode de défaillance ; « rien de notable » est une entrée valide.

Un bon résumé tient sur une page : il présente les thèmes les plus fréquents (« 4 sessions sur 9 ») et des exemples datés, indique clairement quel groupe de causes profondes prédomine (briefing, documentation, supports de travail, outillage ou agent ; c’est sur ce point que l’équipe doit concentrer son attention), le bilan de la mise en œuvre des suggestions passées, ainsi que trois actions attribuables à des responsables. Il alimente la discussion ; il ne la remplace pas.

Périmètre : un journal par périmètre d’examen

Tenez un journal par périmètre de révision : la limite au sein de laquelle les corrections seraient appliquées. Pour le travail de développement, il s’agit généralement du dépôt, car c’est là que se trouvent la documentation, la configuration et les conventions. Pour le travail hors code, il s’agit du compte publicitaire, de la boîte de réception du support ou de la relation client ; le journal se trouve dans le répertoire de documents de cet espace de travail. Une entrée classée en dehors de son périmètre est une entrée que le responsable final de la correction ne trouvera jamais. Le schéma reste identique partout ; c’est le schéma, et non le stockage, qui permet d’agréger les entrées.

Les règles « never-log »

Les entrées sont enregistrées, partagées et survivent à leur contexte ; c’est pourquoi certains éléments n’y ont jamais leur place : les secrets, les identifiants ou les clés sous quelque forme que ce soit ; les données clients ou les informations personnelles ; les chiffres d’activité non publiés ; et, ce qui est le plus important pour la culture rétro, les noms, les fonctions ou tout élément permettant d’identifier une personne. Décrivez la lacune et ce qu’elle a coûté, sans jamais mentionner qui en est responsable : « le brief a laissé le public indéfini », et non « le brief de X ». Les éléments de friction critiquent les contributions et les systèmes, pas les personnes. Si la friction liée à un périmètre ne peut être décrite sans contexte sensible, conservez ces entrées privées et ne partagez que le brief agrégé.

Partie 2 : le modèle « AI Collaboration Retro »

Un format prêt à l’emploi : cinq questions, s’appuyant sur le schéma de référence, pouvant être utilisées dans TeamRetro ou sur n’importe quel tableau blanc :

Chronique	Invite	Blague en une ligne
Tout s’est bien passé	Quels aspects du travail ont été accélérés ou améliorés grâce à l’intelligence artificielle au cours de ce cycle ?	Uniquement les réussites étayées par des preuves : ce qu’il faut préserver et reproduire, sans en faire une exagération.
Les tensions, et leurs causes	Où le ralentissement s’est-il produit, et quelle en était la cause profonde ?	Chaque carte indique le moment, le coût approximatif et un terme issu du vocabulaire fixe de l’équipe.
Hypothèses que nous avons retenues	Qu’est-ce que l’agent (ou nous) avons supposé sans disposer d’informations suffisantes ?	Un conflit latent qui n’a pas encore eu de conséquences négatives ; signalez tout ce qui n’a pas encore été vérifié.
Conserver ou éliminer	Laquelle de ces frictions avons-nous choisie délibérément ?	Les étapes de révision et de validation peuvent constituer des points de contrôle délibérés (résumé de l’intervention de Ronacher à l’AIE Europe); la suppression de l’une d’entre elles relève d’une décision collective.
Commencez par cela	Parmi tout ce qui est présenté ici, quelle est la solution la plus rentable, et à quelle altitude ?	Trois éléments au maximum, chacun avec un responsable et le niveau auquel il se situe : documentation, environnement, processus, matériel ou en amont.

3e partie : fiches d’animation pour l’animateur

Questions à poser lorsqu’une équipe présente un brief « AI-retro » lors de la cérémonie. Une par fiche ; utilisez celles qui s’avèrent nécessaires à la discussion.

1. « De quelle séance s’agit-il, et quel en était le coût ? » Les demandes relatives aux schémas nécessitent des justificatifs datés ; une fiche ne mentionnant ni date ni coût ne peut pas être traitée.
2. « Cette friction correspond-elle à un point de contrôle que nous avons choisi ? » Commençons par le principe « conserver ou supprimer » : une partie de la friction réside dans la pilotage (résumé de l’intervention de Ronacher à l’AIE Europe), et l’absence totale de friction a un coût ; Thoughtworks met en garde contre la dette cognitive qu’elle engendre (annonce).
3. « Nous avions proposé cette solution la dernière fois. Qu’est-ce qui a empêché sa mise en œuvre ? » Les suggestions récurrentes qui n’ont pas été retenues constituent l’élément le plus révélateur de tout rapport ; sans cette question, le « flywheel » n’est que de la poudre aux yeux.
4. « Cela vous a pris dix minutes à chacun, combien cela coûte-t-il à l’équipe par mois ? » L’agrégation est l’atout majeur de l’équipe ; posez cette question chaque fois qu’une carte est ignorée.
5. « Cette correction doit-elle figurer dans la documentation, dans l’environnement ou dans la manière dont nous définissons le périmètre du travail ? » La question de l’équilibre. Si vous visez trop bas, les frictions réapparaissent ; si vous visez trop haut, vous alourdissez le mauvais élément.
6. « À qui appartient l’objet dans lequel cette réparation est effectuée ? » Une action sans propriétaire correspond à un objet figurant sur une liste de souhaits. Si le propriétaire n’est pas présent dans la pièce, cela constitue également une découverte.
7. « Avant de conclure qu’il s’agit d’une erreur de l’agent, les données d’entrée étaient-elles adéquates ? » agent-errorC’est là l’hypothèse résiduelle, et non la valeur par défaut ; la valeur par défaut qu’il convient de rejeter consiste à imputer la faute à l’agent alors que le problème réside en réalité dans le dispositif de pilotage ou le cahier des charges ; il faut donc corriger le dispositif de pilotage à la place (Osmani, Agent Harness Engineering).
8. « Quel groupe de causes profondes domine la répartition, et est-ce bien sur celui-ci que se concentre notre attention ? » Les chiffres présentés dans le rapport vous indiquent si le problème réside dans les briefings, la documentation, le matériel de travail, les outils ou la configuration des agents. C’est sur les données qu’il convient de concentrer votre attention.
9. « Est-ce une personne qui a détecté cela, ou bien l’agent ? » La correction humaine reste le capteur principal : une étude de production a révélé qu’environ 70 % des défaillances silencieuses avaient d’abord été détectées par une personne ayant remarqué quelque chose d’anormal (arXiv 2606.14589). Considérez ces détections comme des preuves de premier ordre, et non comme des interruptions.
10. « S’agit-il d’un problème relevant de notre périmètre ou de celui d’une autre équipe ? » Les corrections relèvent du périmètre de leur revue ; une fiche concernant le modèle partagé ou le processus d’une autre équipe doit être transmise, et non traitée en interne.
11. « S’agit-il d’une discussion ou d’un compte rendu ? » Les corrections évidentes sont directement consignées dans le système de suivi ; ne consacrez ces quinze minutes qu’aux décisions contestées : maintien ou annulation, litiges concernant l’altitude, priorités.
12. « Cette décision dépasse-t-elle les compétences de chacun d’entre nous ? » Acheter un outil, changer de source d’approvisionnement, faire remonter le problème à un fournisseur : la liste des priorités réévaluée dépasse souvent le cadre des décisions individuelles. C’est précisément pour cette raison que ce sujet est abordé ici.

---

Chapitre suivant : Commencez en dix minutes. Installez les compétences et lancez votre première capture, ou adaptez le modèle ci-dessus au tableau que votre équipe utilise déjà. Extrait du guide des rétrospectives des agents IA.