Des agents IA ont rejoint votre équipe. Votre cycle d'amélioration ne s'en est pas aperçu.

Ce guide explique comment appliquer un concept que les équipes connaissent déjà, à savoir le cycle d’amélioration continue, à un domaine nouveau : le travail que votre équipe effectue désormais avec des agents IA. Nous développons des logiciels de rétrospective ; c’est donc cette approche que nous maîtrisons le mieux. La boucle décrite ici s’adapte à tous les outils et rituels que vous utilisez déjà.

Vous préférez commencer par la version de 10 minutes ? Commencez par l’article « Démarrage rapide », recueillir les retours des agents IA, puis revenez ici pour avoir une vue d’ensemble.

L’astuce la plus ancienne du travail d’équipe

Chaque méthode utilisée par votre équipe pour s’améliorer est une variante d’une boucle : accomplir le travail, analyser le résultat, apporter un changement, vérifier que ce changement a été bénéfique. Deming l’a enseigné au secteur industriel sous le nom de « Plan-Do-Check-Act » ; Toyota en a fait une culture d’entreprise et l’a baptisée « kaizen » ; le secteur du logiciel en a fait un rituel. L’ouvrage de Norm Kerth, Project Retrospectives (2001), a popularisé la rétrospective auprès des équipes de développement logiciel, et le Manifeste agile en a fait un principe : « À intervalles réguliers, l’équipe réfléchit à la manière de gagner en efficacité, puis affine et adapte son comportement en conséquence » (principe 12). Les analyses rétrospectives sans reproche suivent le même cycle pour les incidents ; le bilan de campagne d’une équipe média et l’examen du triage d’une équipe d’assistance appliquent ce principe sans jamais utiliser le mot « agile ».

Cette boucle fonctionne grâce à un principe fondamental : le travail fournit des éléments d’information sur la manière dont il devrait évoluer. Les équipes qui tirent parti de ces éléments d’information créent un effet cumulatif : chaque cycle améliore le suivant. Celles qui ne le font pas se retrouvent à faire toujours la même chose.

Pendant soixante-dix ans, les informations provenaient des gens. Les gens remarquaient les frottements, s’en plaignaient à l’heure du déjeuner, en faisaient part dans le retro. Les capteurs de la boucle étaient humains.

Un nouveau type de salarié

Au cours des deux dernières années, votre équipe a commencé à confier des tâches concrètes à un nouveau type de collaborateur. Des agents d’IA rédigent et relisent désormais du code, vérifient les comptes publicitaires, rédigent des réponses au service client, établissent des rapports et migrent du contenu. Et ce collaborateur présente un profil singulier : infatigable, rapide, compétent, mais dépourvu de tout contexte. La formulation de Rahul Garg est devenue la référence dans ce domaine : « Les assistants IA sont comme des développeurs débutants dotés d’une énergie infinie, mais d’aucun contexte », ce qui explique pourquoi « le temps gagné grâce au code généré par l’IA est souvent absorbé par l’effort nécessaire pour le corriger » (Patterns for Reducing Friction in AI-Assisted Development).

Ce coût de correction, c’est la friction, et le travail des agents la génère en permanence : le cahier des charges ambigu qui a obligé à deviner, le document qui n’existait pas, la structure du compte qui pose problème à chaque session, l’outil qui a expiré, l’exigence qui a changé en cours de tâche. Tout cela n’a rien de nouveau. Le travail humain génère la même liste. Deux aspects de cette situation sont toutefois nouveaux.

Le nouvel employé ne se plaint pas pendant le déjeuner. Un agent se heurte à un obstacle, trouve une solution pour le contourner et passe à autre chose. Il ne se sent pas suffisamment frustré pour soulever le problème lors de la rétrospective du vendredi. Le signal sur lequel votre cycle d’amélioration s’est toujours appuyé (une personne qui garde à l’esprit les frictions jusqu’à ce qu’une cérémonie les recense) ne se déclenche pas.

Et les indices s’évaporent. Lorsque la séance prend fin, le contexte de la friction disparaît avec elle. La séance suivante (nouvelle personne, même agent) se heurte à nouveau au même obstacle. Vous ne pouvez pas tirer parti d’indices que vous n’avez jamais relevés ; la boucle s’essouffle discrètement tandis que le travail semble se dérouler normalement.

Voici donc la situation, en termes clairs : une part croissante du travail de votre équipe génère désormais des données d’amélioration que votre cycle d’amélioration n’a jamais été conçu pour collecter.

Le terrain s’en est rendu compte et a reconstruit la boucle tout seul

Les personnes les plus impliquées dans le domaine des agents l’ont compris très tôt, et dès le milieu de l’année 2026, « détecter les frictions des agents et en tenir compte » est devenu une pratique communément admise, connue sous au moins une demi-douzaine de noms : le Feedback Flywheel de Garg, le Compound Engineering d’Every, le Loop Engineering d’Osmani, « sensor-instrumented harness engineering » de Thoughtworks, les boucles de mémoire à l’échelle d’une flotte des fournisseurs de plateformes (« dreaming » d’OpenAI, « Factory Signals »), et gh-aw de GitHub, dont les workflows d’analyse des sessions génèrent déjà des rapports d’analyse automatisés. Même les fournisseurs ont recours à ce terme rétro : les recommandations de Codex d’OpenAI indiquent « lorsque Codex commet deux fois la même erreur, demandez-lui de réaliser une rétrospective et mettez à jour le fichier AGENTS.md » (meilleures pratiques).

Ces boucles sont efficaces. Si votre équipe en utilise une, conservez-la ; tout ce qui est présenté dans ce guide s’appuie sur elles plutôt que de les remplacer. Mais notez deux lacunes.

Tout d’abord, le fossé entre la théorie et la pratique : observer ne suffit pas pour s’améliorer. Environ 90 % des équipes mettent en place des outils de suivi des traces de leurs agents ; seules 37 à 52 % d’entre elles évaluent systématiquement les données ainsi collectées (LangChain, juin 2026). La plupart des équipes disposent d’un tableau de bord. Elles sont toutefois bien moins nombreuses à mettre en place une boucle de rétroaction.

Deuxièmement, le fossé des structures : presque tous les cycles du secteur se déroulent en solo. Un professionnel qui peaufine sa stratégie personnelle, une plateforme qui gère la mémoire de son parc, une pile d’observabilité qui regroupe ses propres traces. Soixante-dix ans d’amélioration continue montrent que la synergie se produit au niveau de l’équipe : là où se trouve la vue d’ensemble, là où les priorités sont réévaluées, là où les processus, la documentation et les budgets ont des responsables. Cette couche est précisément l’élément que personne n’a encore reconstruit. Les rapports existent ; la salle n’a pas encore été réservée.

L’anatomie de la boucle

Lorsque votre équipe décide de mettre ce système en place, le processus comporte davantage d’étapes que ce qu’il n’y paraît à première vue. Voici le parcours qu’un simple obstacle doit franchir :

Scène	La question
Hébergement	Où l’agent s’exécute-t-il, et qu’est-ce que cela permet d’observer ?
Détection	Comment le frottement est-il détecté ? (Autodétection, agent de contrôle, télémétrie et correction humaine, qui reste le capteur principal : environ 70 % des défaillances silencieuses sont d’abord détectées par une personne)
Instrumentation	Qu’est-ce qui pousse l’agent à le noter ? (Personne ne consigne les frictions qu’on ne lui a pas demandé de rechercher)
Enregistrement	Que contient un enregistrement utile, et où se trouve-t-il ?
La récolte	Comment les enregistrements issus de nombreuses sessions et réalisés par de nombreuses personnes sont-ils rassemblés ?
Synthèse	Quels sont les schémas importants, et à quel niveau chaque correction doit-elle être appliquée ?
Fermons la boucle	Cette solution a-t-elle réellement permis de réduire les frictions, ou s’agissait-il d’une mise en scène ?

Trois disciplines font la différence entre une boucle et un journal intime, et chacune fait l’objet d’un chapitre à part entière dans ce guide :

• Des rapports, pas des impressions. Une entrée utile décrit le moment concerné, identifie une cause première parmi un petit vocabulaire prédéfini et propose une solution concise. Ce sont ces étiquettes prédéfinies qui permettent de regrouper les entrées : « la documentation prêtait à confusion » ne peut pas être comptabilisée ; huit entréesmissing-documentation, en revanche, le peuvent. (Chapitre : À quoi ressemble un bon rapport de friction)
• La question du niveau d’intervention. Chaque problème récurrent est résolu à un certain niveau : une note de rappel, une invite, un fichier de configuration, la documentation, le support de travail lui-même, le processus ou en amont auprès d’un fournisseur. Si vous appliquez la correction à un niveau trop bas, le problème réapparaîtra pour tous les autres ; si vous la placez trop haut, vous alourdissez un artefact que personne ne lit. (Chapitre : Où la correction doit-elle être appliquée ?)
• Le jugement au sein d’une équipe. Certaines frictions sont délibérées : le point de contrôle choisi par quelqu’un (un résumé de l’intervention de Ronacher à l’AIE Europe : « la friction est nécessaire… pour orienter » ; Thoughtworks met désormais en garde contre la dette cognitive liée à un travail des agents trop fluide). Les décisions de conservation ou de suppression, les priorités et les corrections impliquant plusieurs responsables sont des négociations, pas des calculs. Elles nécessitent que les responsables des corrections soient réunis au sein d’une même conversation. (Chapitre : Le rapport existe. La salle, non.)

Où l’histoire nous mène

La liste de cadence de Garg pour le « flywheel » comprend une ligne qui tient presque du défi : « 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). C’est ce fil conducteur que suit ce guide. Il ne s’agit ni d’une nouvelle cérémonie, ni d’une cérémonie pilotée par l’IA : c’est la boucle d’amélioration à laquelle votre équipe fait déjà confiance, étendue pour inclure le tout nouveau collaborateur de l’équipe, l’agent agissant en tant que participant : il apporte les preuves, rédige les corrections, répond aux questions ; l’équipe conserve le pouvoir de décision, car les corrections s’inscrivent dans des processus, des documents et des budgets dont les personnes sont responsables et pour lesquels elles doivent rendre des comptes.

Et partons d’un principe simple : si votre équipe se contente d’ajouter un point à l’ordre du jour et d’en discuter (sans compte-rendu, sans étiquettes), c’est déjà mieux que le silence, et cela peut suffire en cas d’utilisation modérée de l’outil. La suite de ce guide présente les éléments à ajouter lorsque cette conversation se répète sans cesse.

Les chapitres

1. Cette page : pourquoi le travail assisté par l’IA doit s’inscrire dans le cycle de travail que votre équipe a déjà mis en place.
2. La carte : boucles de rétroaction des agents, outils et approches : le cadre de référence couvrant le cycle de vie des frictions, les boucles identifiées par la communauté des chercheurs dans ce domaine et les schémas de classification utilisés. Commencez par là si vous adoptez une approche descendante.
3. À quoi ressemble un bon rapport sur les frictions : la saisie en temps réel, les étiquettes indiquant les causes profondes, les règles de « ne jamais consigner ».
4. Où la correction doit-elle être appliquée ? Le problème d’altitude et la table de routage.
5. Le rapport existe. La salle, elle, n’existe pas. Pourquoi la synthèse est un processus collectif, dont le coût est concurrentiel par rapport à celui de ses concurrents.
6. Organisation d’une séance de collaboration sur l’IA en format rétrospective : le guide de l’animateur, comprenant le point à l’ordre du jour d’une durée de 15 minutes, le modèle et les fiches de questions.
7. Commencez en dix minutes : ai-session-retro et ai-retro-brief, les extrémités « capture » et « synthèse » de la boucle, prêtes à être installées.

Vous préférez la version courte ? Voici deux articles complémentaires sur le blog : le guide de démarrage rapide, recueillir les retours d’agents IA, et le récit de la première fois où nous l’avons mis en pratique nous-mêmes, nos collègues IA ont participé à notre rétrospective.

Foire aux questions

Les agents d’IA ont-ils besoin de leur propre rétrospective distincte ?

Non. L’approche présentée dans ce guide vient compléter le cycle d’amélioration que votre équipe met déjà en œuvre, souvent sous la forme d’un simple point à l’ordre du jour de la rétrospective existante, plutôt que d’introduire une nouvelle cérémonie. L’agent participe en apportant des éléments factuels et en proposant des solutions ; c’est l’équipe qui se charge de la prise de décision.

Pourquoi les frictions liées aux agents IA n’apparaissent-elles pas lors des rétrospectives habituelles ?

Il y a deux raisons à cela. D’une part, les agents ne se plaignent pas : lorsqu’ils se heurtent à un obstacle, ils trouvent une solution de contournement et passent à autre chose, de sorte que personne ne ramène le problème à la rétrospective. D’autre part, les indices disparaissent : lorsque la session prend fin, le contexte du conflit s’éteint avec elle, si bien que la session suivante se heurte à nouveau au même obstacle sans aucune trace du précédent.

Nous enregistrons déjà les traces de nos agents. N’est-ce pas suffisant ?

La simple observation ne suffit pas à améliorer les choses. Environ 90 % des équipes mettent en place des outils de suivi des traces de leurs agents, mais seules 37 à 52 % d’entre elles évaluent systématiquement les données ainsi collectées. Ces traces constituent une matière première ; ce processus nécessite une approche rigoureuse de la collecte, une synthèse, ainsi qu’un espace de concertation au niveau de l’équipe où les responsables des corrections prennent leurs décisions ensemble.

L’IA devrait-elle se charger elle-même de la rétrospective ?

Non. L’agent est un acteur à part entière : il apporte les éléments de preuve, élabore les solutions et répond aux questions. C’est l’équipe qui conserve le pouvoir de décision, car les solutions s’inscrivent dans des processus, des documents et des budgets dont les personnes sont responsables et pour lesquels elles doivent rendre des comptes.

Quelle est la version minimale viable de cette pratique ?

Ajoutez un point à l’ordre du jour de votre rétrospective habituelle (« Qu’est-ce qui a bien fonctionné avec l’IA au cours de ce cycle ? ») et discutez-en. Pas de compte-rendu, pas d’étiquettes. C’est déjà mieux que le silence, et pour une utilisation modérée des agents, cela peut suffire. Le reste de ce guide vous indique ce qu’il faut ajouter lorsque cette conversation revient sans cesse sur le tapis.

Nous préférons qu’on nous contredise plutôt qu’on nous donne poliment raison. Chaque chapitre se termine par ce qui pourrait nous faire changer d’avis.