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

Chez TeamRetro, nous nous intéressons à tous les cycles d’amélioration continue mis en œuvre par une équipe. Le travail assisté par l’IA est un nouveau domaine que nous avons examiné à travers le prisme de nos rétrospectives ; ce guide présente les conclusions auxquelles nous sommes parvenus jusqu’à présent. 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 silencieuse par mois — et personne ne s’en rend compte, car chacun a dû y faire face 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, de sorte 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 solutions : seules 37 à 52 % environ évaluent systématiquement les données 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étro » : les consignes de Codex d’OpenAI indiquent « lorsque Codex commet deux fois la même erreur, demandez-lui une rétrospective et mettez à jour le fichier AGENTS.md » (bonnes 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 ignorées par personne ne devient un coût majeur pour l’équipe que lorsqu’on la considère de manière agrégée — 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 existante : qu’est-ce qui a bien fonctionné avec l’IA lors de ce sprint ? » (martinfowler.com), et ce guide constitue une manière de le mettre en œuvre.

Une mise au point honnête d’emblée : ce qu’il faut ici, c’est une réunion régulière, impartiale et fondée sur des faits, à laquelle participent les 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 encore la revue des comptes menée par 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 animer la 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, enregistré via le serveur TeamRetro MCP si vous utilisez TeamRetro. Les équipes disposant d’un grand nombre d’agents peuvent souhaiter combiner des éléments des deux approches.

Comment cela fonctionne, 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 synthétise le journal en un résumé 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 l’application 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 à quel niveau chaque solution doit être mise en œuvre et désigne les responsables des actions prioritaires. Le compte-rendu du cycle suivant indique si la source de friction a effectivement été éliminée.

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 enregistrer 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 par simple courtoisie : les corrections sont intégrées dans les budgets, les documents, les processus et les outils dont chacun est responsable et pour lesquels chacun doit 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 en question constituait le frein : une structure de campagne enchevêtrée, une feuille de calcul héritée, un module que personne ne souhaite toucher — l’élément concret étant toujours nommé), 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 huitmissing-documentationentrées le peuvent. Le flou est un mode d’échec ; « 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, matériel de travail, outillage ou agent ; c’est sur ce point que l’équipe doit concentrer son attention), la vérification de la mise en œuvre des suggestions antérieures, ainsi que trois actions pouvant être attribuées à 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 est conservé 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 validé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 n’a pas cerné le public », et non « le brief de X ». Les éléments de friction portent critique sur les contributions et les systèmes, et non sur 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é.

2e partie — 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’IA 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 première ?	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	Quelles hypothèses l’agent (ou nous-mêmes) avons-nous formulées sans disposer d’informations suffisantes ?	Un conflit latent qui n’a pas encore eu de conséquences ; 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 d’approbation 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 de l’équipe.
Commencez par cela	Parmi toutes les options proposées ici, laquelle est la plus rentable, et à quelle altitude ?	Trois éléments au maximum, chacun avec un responsable et le niveau auquel il se situe : documents, environnement, processus, matériel ou en amont.

Partie 3 — 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 la date ni le 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 certaine friction est nécessaire à la direction (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épétées qui n’ont pas été retenues constituent l’élément le plus révélateur de tout dossier ; 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 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-error Il s’agit là d’une étiquette résiduelle, et non de la valeur par défaut ; la valeur par défaut qu’il convient de rejeter consiste à rejeter la faute sur l’agent alors que le problème provenait en réalité du harnais ou du brief — il faut plutôt corriger le harnais (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 consignes, 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 révision concerné ; une fiche portant sur le modèle partagé ou le processus d’une autre équipe doit être transmise à celle-ci, et non intégrée à votre propre périmètre.
11. « S’agit-il d’une discussion ou d’un compte rendu ? » Les corrections évidentes sont directement consignées dans le suivi ; ne consacrez ces quinze minutes qu’aux décisions contestées : maintien ou annulation, litiges d’altitude, priorités.
12. « Cette décision dépasse-t-elle les compétences de chacun d’entre nous ? » Acheter un outil, modifier le processus de réception, 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.