Le rapport existe. La pièce, non.

Récemment, un agent d’IA a ajouté six éléments sur notre propre tableau rétro.

Le premier disait : « Commencez par vérifier avant d’agir — les erreurs d’exécution des agents représentent 38 % des frictions (soit deux fois plus que la cause suivante) ; le coût récurrent réside dans le fait d’affirmer une cause, de pousser ou de réorienter avant d’avoir vérifié le code en production, les données ou l’état de la branche. » Derrière cela se cachaient les preuves de ce schéma : des erreurs « git/branch-state » survenues lors du travail d’agents simultanés au cours de huit sessions et sur deux dépôts ; des vérifications partielles avant la publication qui ont interrompu l’intégration continue (CI) lors de quatre sessions, dont deux fois dans un même dépôt le même jour ; une lacune dans la simulation des tests qu’une session avait signalée la veille, avec la remarque que la documentation relative à la correction n’avait jamais été rédigée.

Deux aspects de ce tableau méritent votre attention. Premièrement, aucune session de travail n’aurait à elle seule classé l’un de ces points comme le problème principal : chaque cas n’était qu’un haussement d’épaules, quelques minutes perdues, un désagrément que quelqu’un avait contourné. Le classement n’existe qu’à l’échelle globale, toutes sessions et toutes personnes confondues. Deuxièmement, et c’est plus gênant : les points les plus accablants ne concernaient absolument pas l’agent ni le code. Ils nous concernaient nous : des corrections que nous avions acceptées mais que nous n’avions pas adoptées, le même blocage récurrent avec « aucune correction définitive livrée entre les deux ».

Un rapport automatisé peut vous fournir toutes ces informations. Ce qu’il ne peut pas faire, c’est réunir les personnes responsables du processus, de la documentation, du budget consacré aux outils et de la définition des priorités pour qu’elles se concertent et décident des mesures à prendre. Le rapport existe. La réunion, elle, n’existe pas. Cet article porte justement sur cette réunion.

Tout le monde a participé à la réalisation de la boucle

D’ici mi-2026, « identifier ce qui n’a pas fonctionné dans le travail assisté par l’IA et en tirer des enseignements » sera une pratique communément admise. Elle existe sous au moins six appellations différentes, qui sont toutes pertinentes. Le Feedback Flywheel de Rahul Garg transforme les frictions rencontrées lors des sessions en documents d’orientation et en lignes directrices. Le Compound Engineering d’Every permet à chaque unité de travail d’instruire la suivante. Thoughtworks équipe ses agents de capteurs ; Addy Osmani appelle cette discipline « Loop Engineering ». Les fournisseurs de plateformes bouclent la boucle à l’échelle d’un parc : la « mémoire rêvante » d’OpenAI, la curation contextuelle d’Anthropic, Factory Signals qui crée automatiquement des tickets. Le projet open source de GitHub gh-aw, un framework pour les workflows autonomes écrit en Markdown en langage naturel, est celui qui se rapproche le plus de notre sujet : ses workflows d’analyse des sessions génèrent déjà des rapports automatisés d’analyse des sessions. Un exemple public, l’analyse automatisée de 50 sessions sur une seule journée, signale un taux d’abandon de 24 % et un taux de réussite des exécuteurs de 33 % comme des « signaux d’échec ».

Si vous utilisez l’une de ces méthodes, continuez à les utiliser. Cet article ne propose de remplacer aucune d’entre elles. Triez toutefois les boucles en fonction du niveau auquel elles s’exécutent et observez la tendance suivante :

Un guide pratique pour les professionnels. Une configuration de session. Une mémoire de plateforme. Une pile d’observabilité. Un parc de fournisseurs.

Presque toutes les boucles sur le terrain sont des cycles individuels : une personne et son agent, ou un fournisseur et sa flotte. Le « flywheel » de Garg est la seule conception qui vise à mettre en place des artefacts d’équipe partagés, et sa liste de cadence comprend une ligne que presque personne n’a encore mise en œuvre : « Lors de la rétrospective : un point à l’ordre du jour de la rétrospective de sprint existante : qu’est-ce qui a bien fonctionné avec l’IA au cours de ce sprint ? » Il précise le lieu et passe à autre chose. Le « dogfooding » de GitHub, quant à lui, produit exactement le rapport sur les frictions qu’une cérémonie d’équipe souhaiterait comme contribution, et le présente comme de l’observabilité technique, un point c’est tout.

Ce qui s’apparente le plus à une exception vient de Scrum.org, dont la série consacrée aux équipes hybrides comprend l’article Comment mener la rétrospective de sprint lorsque la moitié de votre équipe est composée d’agents IA. Cet article mérite d’être lu, car il aborde sérieusement la question du cadre et y apporte une réponse différente de la nôtre : leur rétrospective se transforme en une session de débogage axée sur les données, portant sur les métriques des agents (fréquence de réécriture des invites, taux de déviation, consommation de jetons). C’est un angle d’approche utile, et une équipe pourrait mettre en œuvre les deux approches. Mais elle porte sur les agents ; la boucle dont traite cet article porte quant à elle sur la collaboration : les causes plutôt que les symptômes, les corrections orientées vers le niveau auquel elles appartiennent (le brief, la documentation, le processus, le matériel), les agents apportant leur propre compte rendu du travail plutôt que d’apparaître sous la forme d’un tableau de bord.

Le problème ne réside pas dans la technologie. Tous les éléments (collecte, agrégation, production de rapports) sont déjà disponibles aujourd’hui. Le problème réside dans la pratique : presque personne n’a expliqué ce que fait l’équipe, collectivement, lorsque le rapport est disponible.

Qu’est-ce qui nécessite réellement une pièce ?

La tendance naturelle ici est d’automatiser davantage : un meilleur regroupement, des corrections appliquées automatiquement, un tableau de bord. Pour une grande partie des résultats, c’est tout à fait justifié, et les pipelines décrits ci-dessus y parviennent très bien. Mais énumérez les décisions que le rapport soulève réellement et observez leur nature :

• Conserver ou supprimer. Quelle friction récurrente relève du gaspillage, et laquelle relève d’un contrôle délibéré ? La phase de validation qui ralentit l’agent pourrait bien être la « laisse » que quelqu’un a choisie (récapitulatif de l’intervention d’Armin Ronacher à l’AIE Europe : « la friction est ce qui est nécessaire… pour orienter ») ; Le Radar de Thoughtworks met désormais en garde contre la dette cognitive liée à une suppression excessive. La suppression d’un point de contrôle modifie le risque pour chacun. Il s’agit, par définition, d’une décision d’équipe.
• Où la solution est mise en œuvre. Un problème récurrent se résout à un certain niveau : une note personnelle, une instruction ou une compétence, la configuration de l’environnement, la documentation, le support de travail lui-même, le processus, ou en amont avec un fournisseur. Ces éléments ont des responsables, et ces responsables sont des personnes différentes.
• Priorité dans le cadre de l’agrégation. Cinq minutes « négligées » par personne et par session passent inaperçues pour chacun, mais représentent un coût global important pour l’équipe. Pour y remédier (réécrire le modèle partagé, modifier le processus de prise en charge, faire remonter le problème au prestataire), il faut prendre une décision qui dépasse les compétences décisionnelles de tout individu.
• La vérification de l’adoption. La correction apportée lors du dernier cycle a-t-elle réellement été adoptée, et les problèmes ont-ils cessé ? La remarque la plus pertinente de notre propre comité de pilotage était justement celle-ci : signalé hier, jamais implémenté. Une boucle sans cette vérification est comme un volant d’inertie qui tourne dans le vide.

Aucune de ces étapes n’est un calcul. Il s’agit dans tous les cas de négociations entre des personnes qui maîtrisent différents aspects du fonctionnement de l’équipe. Les professionnels indépendants intègrent légitimement ces décisions au feeling ; les pipelines de type « fleet » génèrent légitimement le sous-ensemble lisible par la machine à la vitesse de celle-ci. Les versions à l’échelle de l’équipe nécessitent la présence de personnes dans une même pièce, partageant un vocabulaire commun et disposant de l’autorité nécessaire pour réorienter l’attention. Ce n’est pas un pipeline. C’est une cérémonie.

Pourquoi un style rétro, ou une cérémonie de même nature ?

Pour être tout à fait transparent avant d’entrer dans le vif du sujet : nous commercialisons des logiciels rétrospectifs. C’est précisément pour cette raison que cette section s’appuie sur les propriétés du produit plutôt que sur la marque : veuillez donc relativiser notre conclusion en conséquence et vérifier vous-même ces propriétés.

Les caractéristiques que doit présenter le cadre décisionnel : un lieu récurrent (les frictions mineures et chroniques ne déclenchent jamais de réunion ponctuelle), où l’on ne cherche pas à attribuer la responsabilité par principe, inter-responsables (les personnes en charge des processus, de la documentation, des outils et des priorités sont présentes), et fondée sur des preuves. Pour la plupart des équipes, la rétrospective de sprint est le lieu où ces quatre propriétés sont déjà réunies : pas de nouvelle réunion à défendre dans une guerre d’agendas, et une convention « sans reproche » qui a plus d’importance qu’il n’y paraît, car le mode d’échec tentant ici est le bilan post-mortem accusant les agents, et l’école d’ingénierie des harnais rejette explicitement ce par défaut : l’ingénieur impute la faute au modèle et classe l’affaire sous « attendre la prochaine version » ; corrigez plutôt le harnais (Osmani, Agent Harness Engineering).

Mais la formulation honnête de cette affirmation consiste à évaluer les concurrents plutôt qu’à désigner un vainqueur :

• La réunion de planification du sprint est l’instance la plus influente de la réunion, mais son ordre du jour est tourné vers l’avenir et systématiquement surchargé ; le triage rétrospectif, lorsqu’il est intégré à un créneau de planification, est inévitablement négligé. La planification sert à programmer les actions approuvées, et non à analyser les tendances.
• L’analyse rétrospective irréprochable repose sur des normes tout à fait appropriées, mais son déclencheur est erroné : elle est organisée en cas d’échec majeur ponctuel, jamais pour le schéma « cinq minutes, huit personnes, à chaque sprint », qui est précisément le schéma que seule l’agrégation permet de mettre en évidence.
• Asynchrone (un rapport et un outil de suivi) est la solution la moins coûteuse et, pour la grande majorité des éléments courants, elle suffit. Ce qu’elle ne permet pas, en revanche, c’est de prendre des décisions : la décision de conserver ou de supprimer un élément relève d’une négociation, les désaccords sur l’importance d’un élément dépassent les limites de la responsabilité de chacun, et la redéfinition des priorités nécessite que tous les responsables participent à la même discussion.
• L’alternative « nulle » (se contenter de parler d’IA dans le contexte rétrospectif, sans enregistrements ni étiquettes) est gratuite, adaptée à la situation actuelle et peut réellement suffire à une petite équipe qui utilise peu d’agents. Commencez par là. Ce qu’elle ne permet pas, c’est la comparabilité entre les sessions, l’identification des tendances ou le contrôle de l’adoption : une conversation qui repart de zéro à chaque fois. La pratique décrite ci-dessous est celle que vous mettez en place lorsque cette conversation ne cesse de se répéter.

Voici donc l’affirmation, formulée en toute honnêteté : la cérémonie « rétro », ou votre cérémonie existante de forme équivalente. La revue mensuelle de campagne d’une équipe médias et la revue de triage d’une équipe d’assistance sont une seule et même procédure sous des noms différents, et rien dans cette pratique ne fait appel au code : le journal des problèmes d’un compte publicitaire enchevêtré ou d’une bibliothèque de modèles incohérente se lit exactement comme le journal des problèmes d’un dépôt hérité.

L’intervenant présent dans la salle : un participant, jamais un animateur

Si les éléments de preuve proviennent d’agents, l’agent doit-il se charger de l’affaire ? Non, et ce n’est pas principalement pour la raison que vous imaginez.

La raison pour laquelle cela ne tient pas la route : les modèles actuels ne sont pas fiables précisément pour ce type d’évaluation : les verdicts des LLM varient selon des entrées identiques ~13,6 % du temps, et dans une étude en production de huit semaines ~70 % des défaillances silencieuses des agents ont d’abord été détectées par une personne, et non par des tests ou une surveillance. C’est vrai aujourd’hui ; les modèles s’améliorent.

La raison pour laquelle cela ne change pas : l’animation et la prise de décision répartissent l’attention de l’équipe et modifient les artefacts dont l’équipe est responsable et pour lesquels elle doit rendre des comptes. Cette autorité ne se transfère pas au modèle le plus performant de la salle, pas plus qu’elle ne se transfère à l’ingénieur le plus compétent de la salle. Il s’agit d’une réalité organisationnelle, et non d’un déficit de compétences.

Ainsi, l’agent intervient comme le ferait le contributeur le mieux informé. Il apporte des preuves : ses comptes-rendus de session, étiquetés et accompagnés d’une indication de coût. Il répond aux questions : à la question « Qu’avez-vous réellement essayé avant de recourir à la solution de contournement ? », il apporte une réponse étayée par la transcription. Il rédige, mais ne décide jamais : les solutions proposées sont accompagnées de niveaux d’intervention suggérés ; le groupe les modifie, redéfinit leurs priorités ou les rejette. Et il récupère les actions acceptées (la modification du document, le changement de configuration), pour les exécuter après la séance, dans le cadre d’un examen habituel. La pratique de la recherche a un nom pour cette répartition des rôles : dans le cadre ACE, l’agent est le réflecteur et un conservateur consolide ce qui entre dans le guide de procédures. Nous apportons une adaptation délibérée : dans ACE, le conservateur est un composant déterministe ; ici, les conservateurs constituent l’équipe.

L’une de ces asymétries concerne la charge de travail. Tout ce que l’agent apporte dans la pièce doit être libre d’accès, car un agent qui a besoin d’une autorisation pour signaler des frictions sous-estime l’ampleur du problème. Tout ce qui quitte la pièce pour être utilisé ultérieurement par les agents (mémoire, fichiers de contexte, configuration) fait l’objet d’une vérification classique, car ce chemin d’écriture constitue une surface d’attaque reconnue, susceptible d’être corrompue ou de subir des dérives (OWASP Agentic Top 10, ASI06). La procédure se situe précisément à cette frontière : les données entrantes ne sont pas soumises à de contrôles, tandis que les écritures sortantes le sont.

Les quinze minutes

Ce que nous proposons en réalité à une équipe d’essayer, au cours de ce sprint, à chaque itération, sans rien modifier :

1. À chaque session, l’agent rédige une brève note rétrospective sur son propre travail : ce qui s’est bien passé, chaque point de friction accompagné d’une indication de la cause première et de son coût, une proposition de correction sous forme de ticket et le niveau visé. Validé en même temps que le travail, sans délai d’attente.
2. Avant la rétrospective, les contributions enregistrées depuis la dernière session sont synthétisées dans un document d’une page : thèmes récurrents et leur fréquence, quel groupe de causes profondes domine, si les solutions proposées précédemment ont été adoptées, les trois principales actions recommandées. Ce document alimente la discussion ; il ne la remplace pas.
3. Dans la rétrospective (un point à l’ordre du jour, pas une nouvelle réunion) : quinze minutes consacrées à la question « Qu’est-ce qui a bien fonctionné avec l’IA au cours de ce cycle, et qu’est-ce qui a continué à poser problème ? ». Les humains procèdent à un tri : conserver ou abandonner, confirmer ou réorienter les pistes, désigner des responsables pour les trois principales.
4. Au cycle suivant, la vérification de l’adoption du cahier des charges permet de déterminer si la friction a effectivement diminué. C’est cette vérification qui transforme le rapport en une boucle. C’est également là que notre propre conseil d’administration nous a pris en défaut.

Modes de défaillance, ainsi nommés pour que vous puissiez vous en prémunir : théâtre rétro (la cérémonie que vous organisez pour le public : lecture succincte, hochements de tête, aucune décision prise ; la règle des « trois principaux avec leurs responsables » existe justement pour cela) ; responsabilisation de l’agent (considérer « l’agent a commis une erreur » comme l’explication plutôt que comme le résidu ; la plupart des échecs trouvent leur origine dans le harnais et les entrées, et non dans le raisonnement du modèle); prolifération de la liste de souhaits (vingt actions, aucun responsable) ; et la boucle qui ne se referme jamais (l’absence de suivi: les corrections sont mises en place, mais personne ne vérifie la tendance). Nous avons rédigé tout un guide pratique sur les causes d’échec des cérémonies; tous les modes qui y sont décrits s’appliquent également ici.

Ce que nous ne prétendons pas

Cela ne remplace aucune boucle de fournisseur : leurs résultats constituent les données d’entrée de cette cérémonie. Il ne s’agit pas d’une nouvelle réunion. Ce n’est pas non plus une cérémonie pilotée par l’IA ; pour une entreprise dont le produit est la rétrospective, cette limite est délibérée. Ce n’est pas nécessaire pour un praticien indépendant, dont les boucles se bouclent parfaitement à l’instinct. Et l’objectif n’est pas l’absence totale de friction : une certaine friction sert de surface de contrôle, et ce point à l’ordre du jour existe pour choisir, et non pour éliminer d’emblée.

Qu’est-ce qui pourrait nous faire changer d’avis ?

Il s’agit d’un document de réflexion ; voici donc la partie falsifiable. Si les boucles des fournisseurs donnent lieu à un véritable jugement inter-outils et inter-personnes, et non pas simplement à des écritures en mémoire à l’échelle de la flotte, le champ d’action se réduit à une simple fonction d’audit. Si les équipes qui utilisent la version asynchrone « brief uniquement » affichent la même tendance à la réduction des frictions que celles qui traitent le point à l’ordre du jour, ces quinze minutes ne seront qu’une mise en scène et nous le dirons clairement. Quant à notre affirmation concernant le vocabulaire étiqueté, elle repose sur une expérience de fiabilité inter-évaluateurs que nous menons actuellement sur des entrées réelles, plutôt que sur une affirmation a priori. Nous préférons publier les chiffres plutôt que le niveau de confiance.

Si votre équipe met en œuvre l’une des versions de cette initiative (le point à l’ordre du jour, le briefing asynchrone ou une cérémonie à laquelle nous n’avons pas pensé), nous aimerions savoir comment cela s’est passé : ai-discussion@teamretro.com.

---

Chapitre suivant : Organiser une rétrospective collaborative sur l’IA. Le guide de l’animateur pour ces quinze minutes : le modèle, le format de saisie et les fiches de questions. Extrait du guide des rétrospectives sur les agents IA.