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

Ce guide vise à appliquer un principe 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 d’IA. Nous développons des logiciels de rétrospective ; c’est donc cette approche que nous maîtrisons le mieux. Le cycle décrit dans ce guide 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 consulter 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 en matière de travail d’équipe

Chaque méthode utilisée par votre équipe pour s’améliorer est une variante d’un même cycle : réaliser le travail, analyser les résultats, apporter un changement, vérifier que ce changement a été bénéfique. Deming l’a enseigné au secteur industriel sous le nom de « Planifier-Faire-Vérifier-Agir » ; 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 intitulé 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 devenir plus efficace, 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 l’appliquent 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 une dynamique positive : chaque cycle améliore le suivant. Celles qui ne le font pas se retrouvent à faire toujours la même chose.

Pendant soixante-dix ans, ce sont les gens qui ont fourni les éléments de preuve. Ce sont eux qui ont remarqué les frottements, qui s’en sont plaints à l’heure du déjeuner et qui ont soulevé la question dans le retro. Les capteurs de la boucle étaient des êtres 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, contrôlent 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 désormais devenue la référence dans le domaine : « Les assistants IA sont comme des développeurs débutants dotés d’une énergie infinie, mais dépourvus de tout 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. Il n’y a là 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, puis passe à autre chose. Il n’est 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 réunion les recense) ne se déclenche pas.

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

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.

Les joueurs s’en sont aperçus — et ont reconstruit la boucle par eux-mêmes

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, « identifier les frictions liées aux agents et en tenir compte » est devenu une pratique communément admise, connue sous au moins une demi-douzaine de noms différents : le Feedback Flywheel de Garg, le Compound Engineering d’Every, le Loop Engineering d’Osmani, le sensor-instrumented harness engineering de Thoughtworks, les boucles de mémoire à l’échelle d’une flotte proposées par les 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 d’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 toutes les boucles du domaine fonctionnent en solo. Un professionnel qui peaufine son propre guide opérationnel, 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 s’opère au niveau de l’équipe — là où se trouve la vue d’ensemble, où les priorités sont réévaluées, où les processus, la documentation et les budgets ont des responsables. C’est précisément cette couche que personne n’a encore repensée. 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 cela 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é ? (Auto-dé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 données issues de nombreuses sessions et provenant de nombreuses personnes sont-elles regroupées ?
Synthèse	Quels sont les schémas qui importent, et à quel niveau chaque correction doit-elle être appliquée ?
Faire le plein	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 distinct dans ce guide :

• Des rapports, pas des impressions. Une entrée utile décrit le moment en question, 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 ; en revanche, huitmissing-documentationentrées peuvent l’être. (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 alourdirez 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 (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 s’apparente presque à un défi : « 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). C’est le fil conducteur de ce guide. Il ne s’agit ni d’une nouvelle cérémonie, ni d’une cérémonie gérée par l’IA — mais bien de la boucle d’amélioration à laquelle votre équipe fait déjà confiance, étendue pour inclure le tout nouveau collaborateur de l’équipe, l’agent y jouant le rôle de 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 pour partir sur des bases claires : si votre équipe se contente d’ajouter un point à l’ordre du jour et d’en discuter (sans compte-rendu ni é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 vous indique ce qu’il faut 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 spécialistes 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 immédiate des événements, l’identification des causes profondes, les règles de non-enregistrement.
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 travail d’équipe, dont le coût est compétitif par rapport à celui de ses concurrents.
6. Organisation de l’activité collaborative « AI » en mode 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.

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.