À quoi ressemble un bon bilan en matière de friction ?

Pourquoi des archives, et non des souvenirs ?

Un conflit lors d’une seule séance n’est qu’un incident isolé. Le même conflit qui se répète au cours de huit séances constitue un schéma que votre équipe peut corriger — mais uniquement si ces huit séances ont laissé des traces que vous pouvez réellement analyser ensemble : cohérentes (même schéma, ce qui permet de les comparer) et fiables (des observations étayées par des preuves, et non de simples impressions).

Aucune de ces deux situations ne se produit par défaut. Le moment où une friction apparaît est celui où l’on dispose d’un maximum d’informations à son sujet : la ligne précise du guide d’intervention qui n’est plus à jour, le paramètre exact que le brief a laissé en suspens. Ces informations se perdent rapidement. L’agent normalise sa propre solution de contournement en quelques itérations, et à la fin de la session, le signal a disparu à moins qu’il n’ait été consigné par écrit ; tout ce qu’un sous-agent découvre « disparaît dès qu’il le renvoie » (Hindsight, mai 2026). Ce chapitre traite de la consignation par écrit.

Comment on se rend compte de la friction

Avant de pouvoir enregistrer quoi que ce soit, il faut d’abord le remarquer. Il y a quatre canaux, et chacun d’entre eux perçoit des choses différentes :

L’agent se rend compte qu’il rencontre des difficultés. Boucles de réessai, retour en arrière, relecture du même fichier ou nouvelle interrogation de la même vue analytique, une supposition imposée par une lacune dans le cahier des charges. Les plateformes de production se sont essentiellement alignées sur cette liste de signaux comportementaux (Factory Signals, janvier 2026). Le canal le moins coûteux, avec deux limites évidentes : il est aveugle à ce qui est absent (une boucle de réessai est détectée ; un document qui n’a jamais existé ne produit aucun signal), et l’auto-observation devance l’autodiagnostic — les modèles localisent mal leurs propres erreurs d’agent, même sur des traces triées (~11 %, TRAIL). La tâche à accomplir pendant la session consiste donc à observer les symptômes et à citer des preuves, en gardant une approche souple quant au diagnostic.

Un deuxième agent relit la transcription. Un relecteur qui n’a pas participé au traitement initial repère ce que l’agent chargé du traitement a normalisé. Cette approche est plus objective ; elle nécessite toutefois une deuxième lecture et comporte ses propres erreurs de jugement.

Un humain corrige l’agent. Le capteur reste le plus efficace : une étude de production menée sur 8 semaines a révélé qu’environ 70 % des défaillances silencieuses des agents ont d’abord été détectées par une personne ayant remarqué que quelque chose n’allait pas — et non par des tests unitaires, des contrôles d’intégrité ou des audits de gouvernance (arXiv 2606.14589). Chaque correction (un « non, je voulais dire… » d’un relecteur, une partie prenante réexpliquant le cahier des charges en cours d’audit) marque précisément l’endroit où le contexte s’est écarté de l’intention, et l’agent peut le saisir sur-le-champ sans aucun coût supplémentaire en termes de processus.

Télémétrie. Taux d’erreurs des outils, refus d’autorisation, nombre de boucles, durées prolongées. Automatique et impartiale, mais superficielle : elle sait *qu’*un événement s’est produit, mais pas pourquoi.

Les configurations les plus performantes reposent sur une approche triangulaire : la télémétrie indique où chercher, une analyse rétrospective explique pourquoi, et la correction humaine comble les lacunes que les signaux automatiques ne peuvent pas détecter. Quelle que soit la combinaison que vous utilisez, le résultat final devrait toujours être le même : un record.

Qu’est-ce qui pousse l’agent à l’enregistrer ?

Un agent n’enregistrera pas un frottement que personne ne lui a demandé de rechercher. La plupart des frottements ne sont pas enregistrés, non pas parce qu’ils n’ont pas été remarqués, mais parce que rien n’a déclenché leur enregistrement. Il existe quatre mécanismes, qui diffèrent principalement par ce qui garantit leur déclenchement :

• Une compétence : une procédure écrite, dont la version est contrôlée, que l’agent exécute à la fin de la session. Elle contient le schéma et les règles d’honnêteté, ce qui garantit la cohérence de son déclenchement : la même procédure s’applique aussi bien à une refonte qu’à un examen de compte publicitaire. Faiblesse : son invocation est probabiliste ; il peut arriver qu’elle ne se déclenche jamais, sans que cela soit signalé.
• Un « hook » : c’est le harnais lui-même qui déclenche ou rappelle une action (une injection au début de la session, un déclencheur à la fin de la session). Cette méthode est déterministe (c’est la seule option qui ne repose pas sur le fait que quelqu’un s’en souvienne), mais peu nuancée (elle se déclenche également pour les sessions de deux minutes) et dépendante de la plateforme.
• Une règle de convention : une consigne permanente figurant dans le fichier de contexte de la portée, ou dans son équivalent hors code, une étape de la procédure opérationnelle standard (SOP) de l’équipe : « mettre fin à chaque session importante assistée par l’IA en consignant les frictions rencontrées ». Aucune infrastructure n’est nécessaire, mais cette méthode repose entièrement sur le fait que le modèle respecte une ligne parmi tant d’autres, et elle perd de son efficacité à mesure que le fichier s’étoffe ; le mode de défaillance identifié est le fichier de mémoire qui a « cessé d’être lu » (note de terrain sur les anti-modèles).
• Une commande : une instruction saisie par un humain/retroà la fin d’une branche de fonctionnalité ou d’une équipe de triage. Elle est mûrement réfléchie et exécutée à un moment précis ; le maillon faible, c’est la mémoire humaine.

Ces éléments constituent l’ensemble ; superposez-les. Un déclencheur déterministe (un « hook » ou une étape SOP de fin de poste), une charge utile procédurale (la compétence) et une ligne de convention qui énonce la pratique en tant que norme — choisissez au moins un déclencheur, deux étant préférable. Même les fournisseurs ont suivi cette intuition : les recommandations de Codex d’OpenAI indiquent « lorsque Codex commet deux fois la même erreur, demandez-lui une analyse rétrospective et mettez à jour le fichier AGENTS.md » (bonnes pratiques).

Les éléments constitutifs d’une bonne introduction

Un enregistrement constitue le lien entre la session qui a détecté le frottement et tout ce qui se passe en aval : la qualité de la synthèse dépend de la qualité de l’enregistrement. Quatre éléments essentiels :

1. Un événement étayé par des preuves, avec son coût. Ce qui s’est passé, à quel moment, et la conséquence observable, de manière suffisamment précise pour qu’une personne n’ayant pas assisté à la session puisse en tirer les conséquences. Le coût correspond à un travail refait, à du temps perdu ou à un résultat erroné ; un enregistrement sans indication de coût ne peut pas être classé par la suite. Le coût estimé par l’agent est approximatif : indiquez-le tel quel(est.)plutôt que de feindre la précision.

2. Exactement une étiquette de cause première issue d’un vocabulaire fixe de dix étiquettes. Les vocabulaires fixes permettent un étiquetage fiable (MAST a atteint un coefficient κ = 0,88 pour 14 modes de défaillance ; voir arXiv 2503.13657); les catégories libres varient d’une personne à l’autre et ne permettent plus d’agrégation. Les dix :

• ambiguous-instruction: la question laissait un paramètre essentiel en suspens (public, portée, définition, période) et vous obligeait à faire une supposition
• missing-context: un fait avéré que l’équipe connaît mais qu’elle n’a pas communiqué
• incorrect-context: les informations fournies étaient erronées
• missing-documentation: un document qui devrait exister fait défaut (pas de fichier README, de spécifications, de guide d’exploitation ni de procédure opérationnelle standard)
• incorrect-documentation: un document existe, mais il est obsolète ou erroné, et on s’est fondé sur celui-ci
• work-material-friction: le support sur lequel vous travailliez a ralenti le travail ou l’a rendu sujet aux erreurs : dette technique ou structure confuse dans le code ; un compte, un tableau, une feuille de calcul ou un modèle enchevêtré en dehors de celui-ci (veillez toujours à nommer le support concret)
• missing-access-or-tool: un connecteur, une autorisation ou un outil nécessaire n’était pas disponible
• agent-error: une erreur commise par l’agent lui-même (hypothèse erronée, connaissances obsolètes, bug qu’il a lui-même introduit)
• changed-requirements: les exigences ont changé en cours de session et le travail a dû être refait
• environment-friction: défaillances des outils, délais d’attente, problèmes liés au bac à sable ou à la plateforme

Une étiquette par constat permet de garantir l’exactitude des répartitions : choisissez celle qui correspond le mieux, notez les incohérences dans les éléments de preuve, n’inventez jamais d’étiquette en cours de saisie. Trois règles limites assurent l’essentiel du travail de désambiguïsation. Le test de la connaissance de l’agent : le fait était-il susceptible d’être découvert partout où l’agent pouvait raisonnablement chercher ? Invisible là où il aurait dû se trouver → missing-documentation; fourni seulement plus tard, par une personne → missing-context. L’erreur de l’agent est le résidu : n’utilisez cette étiquette que lorsque les données d’entrée étaient adéquates et que l’agent a tout de même commis une erreur ; si l’erreur provient d’une mauvaise donnée d’entrée, étiquetez cette dernière. Et ambiguïté contre changement : si la clarification a révélé ce qui avait toujours été voulu, c’était ambiguous-instruction; si l’objectif a véritablement changé, c’est changed-requirements.

3. Une solution au format « ticket », précisant son niveau d’application. Le niveau d’application correspond au domaine visé par la solution : la mémoire, les compétences, l’environnement, la documentation, le matériel lui-même, le processus ou l’amont. Un rapport de problème sans solution associée est une simple réclamation.

Voici un compte-rendu complet d’une réunion ne portant pas sur le code, à savoir la revue mensuelle du compte publicitaire :

- **[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

Un moment, un coût accompagné d’un(est.)indicateur, une étiquette, une solution que quelqu’un pourrait mettre en œuvre la semaine prochaine. Comparez cela à la version inutilisable de la même observation, « le cahier des charges prêtait à confusion » : pas de moment précis, pas de coût, pas de suite à donner. Le flou est en soi un mode de défaillance.

4. Le droit de ne rien dire. « Rien de notable » est une réponse valable et utile ; un rapport gonflé de conclusions inventées de toutes pièces occulte les véritables constatations.

Autre point à prendre en compte dans la conception : l’enregistrement doit être sans restriction — un agent qui a besoin d’une autorisation pour enregistrer risque de sous-estimer les frictions. Laissez-le enregistrer librement, et que le retour d’information humain serve de correction a posteriori : il s’agit d’un signal complémentaire provenant de la personne qui a participé à la session, et non d’un point de contrôle sur lequel la boucle d’exécution doit s’arrêter.

Les règles « never-log »

Les enregistrements survivent à leurs sessions : ils sont sauvegardés, partagés et regroupés. Certains éléments ne sont jamais intégrés :

• Les secrets, identifiants, jetons ou clés API, sous quelque forme que ce soit, même partiels.
• Données clients ou informations personnelles.
• Chiffres d’activité non publiés ou données confidentielles — décrivez l’impact, et non les données elles-mêmes.
• Avant tout, les personnes. Jamais un nom, une fonction ou quoi que ce soit permettant d’identifier la personne à l’origine d’une lacune. Décrivez la lacune et ce qu’elle a coûté : « le brief a laissé le public dans l’expectative », et non « le brief de X ». Les contributions critiquent les apports et les systèmes, pas les personnes — c’est la même rigueur que celle qui caractérise une bonne rétrospective, et ce qui permet de lire le compte-rendu en toute sécurité à plusieurs.

Il est normal de porter un regard critique sur les données d’entrée : les briefs peu clairs, le contexte manquant et les exigences communiquées tardivement constituent généralement les éléments sur lesquels il est possible d’agir. L’agent doit se remettre en question avec la même honnêteté. Si les difficultés liées à un périmètre ne peuvent être décrites sans contexte sensible, gardez les entrées relatives à ce périmètre privées et ne partagez que le brief agrégé.

Où se trouve le journal

Un journal par périmètre de révision — c’est-à-dire le cadre dans lequel les corrections sont intégrées. Pour la plupart des travaux de développement, il s’agit du dépôt : sa documentation, sa configuration et ses conventions sont hébergées dans ce dépôt, tout comme son journal des problèmes. En dehors du code, le périmètre correspond au compte publicitaire, à la boîte de réception du support ou à l’engagement client ; conservez le journal 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 ; une entrée écrite dans un répertoire temporaire disparaît à la fin de la session.

Ce qui doit rester identique partout, ce n’est pas le stockage, mais la structure : c’est le schéma, et non le stockage, qui permet ensuite d’agréger les entrées. C’est là tout l’enjeu de ce chapitre en matière de travail d’équipe : ce sont des enregistrements comparables, qu’il s’agisse de personnes, d’agents, de sessions ou d’outils, qui rendent possible l’agrégation au niveau de l’équipe. Adaptez librement le stockage ; préservez le schéma.

Et ensuite ?

Une pile de bonnes notes constitue une matière première, et non une prise de conscience. Les chapitres suivants reprennent le fil : le choix de l’altitude de chaque point de repère (la différence entre une note de mémoire et la refonte vers laquelle la friction ne cesse de pointer) ; la synthèse des entrées en un résumé d’une page que l’équipe peut lire ensemble ; et la cérémonie où les humains et le journal se rencontrent — la rétrospective, où les enregistrements de l’agent servent de contribution aux participants. Cette boucle est un exemple concret du « Feedback Flywheel » : réinjecter les enseignements tirés dans les artefacts qui fournissent le contexte (martinfowler.com). Et la discipline à l’origine de ces entrées est l’analyse des erreurs, « l’activité la plus importante dans les évaluations » (Husain & Shankar, FAQ sur les évaluations), déplacée vers le moment le plus économique possible : tant que la session au cours de laquelle le frottement s’est produit est encore en cours.

Tout ce qui précède fonctionne avec un fichier texte et n’importe quel agent compatible. Si vous préférez ne pas créer le modèle vous-même, la ai-session-retroskill gratuite met en œuvre ce format d’entrée de bout en bout ; le guide de démarrage rapide vous explique comment l’installer en une dizaine de minutes.

Chapitre suivant : Où la correction doit-elle être appliquée ? — le problème d’altitude et la table de routage.