Le rapport existe. La pièce, elle, n'existe pas.

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

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 recibler 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 liées à l’état des branches Git lors du travail avec des agents simultanés sur huit sessions et 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 prise isolément n’aurait classé l’un de ces points comme le problème principal : chaque cas ne suscitait 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, en regroupant les sessions et les personnes. Deuxièmement, et c’est plus gênant : les points les plus accablants ne concernaient absolument pas l’agent ni le code. Ils concernaient nous — des corrections que nous avions acceptées mais que nous n’avions pas mises en œuvre, le même blocage récurrent avec « aucune correction permanente déployé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 afin qu’elles se concertent et décident des mesures à prendre. Le rapport existe. La salle de réunion, elle, n’existe pas. Cet article porte justement sur cette salle de réunion.

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

D’ici mi-2026, « identifier les dysfonctionnements survenus 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 exploite les frictions rencontrées lors des sessions pour élaborer des documents d’orientation et des garde-fous. Le Compound Engineering d’Every permet à chaque unité de travail d’instruire la suivante. Thoughtworks équipe ses agents de capteurs ; Addy Osmani qualifie cette discipline de « Loop Engineering ». Les fournisseurs de plateformes bouclent la boucle à l’échelle d’une flotte : la « mémoire rêvante » d’OpenAI, la « curation contextuelle » d’Anthropic, ainsi que Factory Signals qui classe automatiquement les tickets. Le projet open source de GitHub gh-aw, un framework pour les workflows agentiques é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 d’analyse automatisés. 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 n’en remplacer aucune. Mais triez 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 indique 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 positionne comme relevant de l’observabilité technique, un point c’est tout.

Ce qui s’en rapproche le plus 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 abordée dans 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, reporting) sont déjà disponibles aujourd’hui. Le problème est d’ordre 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é ? Le point de contrôle qui ralentit l’agent pourrait bien être la « laisse » que quelqu’un a choisie (résumé 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 tout le monde. 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 consigne ou une compétence, la configuration de l’environnement, la documentation, le support de travail lui-même, le processus, ou en amont auprès d’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 fournisseur), il faut prendre une décision qui dépasse les compétences 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 de manière intuitive ; les pipelines agiles 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 que des personnes se réunissent dans une même pièce, dotées d’un vocabulaire commun et de l’autorité nécessaire pour réorienter l’attention. Ce n’est pas un pipeline. C’est une cérémonie.

Pourquoi un mariage « rétro » — ou une cérémonie de même nature ?

Avant d’entrer dans le vif du sujet, je tiens à préciser : 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êmes ces propriétés.

Les caractéristiques requises pour le cadre décisionnel : un lieu récurrent (les frictions mineures chroniques ne donnent jamais lieu à une réunion ponctuelle), où la responsabilité n’est pas mise en cause 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 données factuelles. Pour la plupart des équipes, la rétrospective de sprint est déjà le lieu où ces quatre caractéristiques sont 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 axé sur la responsabilité des agents, et l’école d’ingénierie du harnais rejette explicitement ce par défaut : l’ingénieur impute la faute au modèle et classe le problème 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 de sprint est l’instance la plus influente de la salle, mais son ordre du jour est tourné vers l’avenir et systématiquement surchargé ; le triage rétrospectif, intégré dans un créneau de planification, est inévitablement négligé. La planification est le moment où les actions approuvées sont programmées, et non celui où l’on analyse 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 pour faire le point sur les échecs majeurs ponctuels, jamais pour le schéma récurrent de « cinq minutes pour huit personnes à chaque sprint », qui est précisément le schéma que seule une analyse globale 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 d’abandonner un élément relève d’une négociation, les désaccords sur les priorités dépassent les limites des responsabilités individuelles, et la redéfinition des priorités nécessite que les responsables participent tous à la même discussion.
• L’alternative « par défaut » — se contenter de parler d’IA en mode rétrospectif, sans enregistrement ni étiquette — est gratuite, adaptée à la situation actuelle et peut, pour une petite équipe utilisant peu les agents, s’avérer tout à fait suffisante. Commencez par là. Ce qu’elle ne permet pas, c’est la comparabilité entre les sessions, l’identification des tendances ou la vérification 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é : le « rétro » — ou votre cérémonie existante de nature équivalente. La revue mensuelle des campagnes menée par une équipe média et la revue de triage effectuée par une équipe d’assistance sont en réalité la même procédure sous des noms différents, et rien dans cette pratique ne fait référence 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 pourriez imaginer.

La raison pour laquelle cela s’effrite : 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 compétent présent dans la salle, pas plus qu’elle ne se transfère à l’ingénieur le plus compétent présent dans la salle. Il s’agit d’une réalité organisationnelle, et non d’un déficit de compétences.

Ainsi, l’agent intervient à l’instar du contributeur le mieux informé. Il apporte des preuves : ses comptes-rendus de session, étiquetés et accompagnés d’une estimation des coûts. Il répond aux questions : à la question « Qu’avez-vous réellement essayé avant 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 reprend les actions acceptées (la modification du document, le changement de configuration), en les exécutant après la réunion, 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 d’intervention. 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 — un agent qui a besoin d’une autorisation pour signaler des frictions ne rend pas compte de l’ensemble des problèmes. 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 concrètement à une équipe d’essayer, au cours de ce sprint, à chaque itération qu’elle exécute déjà sans modification :

1. À chaque session, l’agent rédige un bref compte-rendu rétrospectif de son 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 ainsi que 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 séance sont synthétisées dans un document d’une page : thèmes récurrents et leur fréquence, groupe de causes profondes dominant, adoption ou non des solutions proposées précédemment, et les trois principales actions recommandées. Ce document alimente la discussion ; il ne la remplace pas.
3. Au cours de la réunion de bilan (un point à l’ordre du jour, et non une nouvelle réunion) : quinze minutes consacrées à la question suivante : « 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, le contrôle d’adoption du cahier des charges indique si les frictions ont effectivement diminué. C’est ce contrôle qui transforme le rapport en 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 vous permettre de 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 un résidu ; la plupart des échecs sont imputables au harnais et aux entrées, et non au 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 œuvre, mais personne ne vérifie la tendance). Nous avons rédigé un guide pratique complet 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 travail avec un prestataire : 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. Il ne s’agit pas non plus d’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 professionnel 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 « avec briefing 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 les quinze minutes : le modèle, le format de saisie et les fiches de questions. Extrait du guide des rétrospectives sur les agents IA.