Nos collègues IA se sont joints à notre événement rétro

Nous développons des logiciels de rétrospective ; le tableau de rétrospective de notre équipe est donc assez classique : « Démarrer », « Arrêter », une colonne pour les actions en cours, les discussions habituelles du vendredi. La semaine dernière, elle a accueilli de nouveaux contributeurs. Six des fiches n’ont pas été rédigées par des humains : elles ont été déposées par les agents IA avec lesquels nous travaillons quotidiennement, résumant les points de friction issus de leurs propres sessions de travail avec nous.

Soyons précis sur ce dont il s’agit, car la formulation a son importance. Il ne s’agit pas d’une IA « présente » au sein de la réunion rétrospective : aucun bot n’anime la réunion, aucune fonctionnalité d’IA ne résume les fiches des participants. Les agents qui effectuent le travail concret au sein de notre équipe (ceux qui écrivent du code, éditent du contenu, réalisent des audits) se sont présentés à la réunion comme n’importe quel autre membre de l’équipe : en donnant leur propre compte rendu du déroulement du travail. Des participants, pas des animateurs ; la réunion est restée la nôtre.

Ce n’était pas non plus un coup médiatique. L’impulsion est venue lors d’une de nos propres rétrospectives : quelqu’un a fait remarquer que les documents d’intégration étaient obsolètes (encore une fois) et une autre personne a mentionné qu’un agent lui avait signalé exactement cela au milieu d’une session ce matin-là, en passant, avant que le contexte ne disparaisse en défilant. L’agent le savait ; rien dans son univers ne lui indiquait que cette observation méritait d’être conservée. Nous menons donc depuis quelques semaines une expérience sur nous-mêmes : il s’agit de la méthode que nous avons décrite dans Comment recueillir les retours de vos agents IA. À la fin de chaque session de travail importante assistée par l’IA, l’agent rédige une brève entrée structurée de rétrospective sur son propre travail : ce qui s’est bien passé, ce qui a pris du retard, ce qu’a coûté chaque retard, une étiquette de cause première par élément, et une solution proposée. Ces comptes rendus s’accumulent dans les dépôts où le travail a été effectué. Lorsqu’il y en a eu suffisamment, un processus associé les a tous lus et a classé les schémas récurrents directement sur notre tableau de rétrospective, en les préfixant [AI retro]afin que personne ne se trompe sur l’auteur.

Voici ce que nos nouveaux collègues ont déclaré à propos de leur expérience de travail chez nous.

Ce qu’ils ont découvert

Le titre qu’ils ont mis en avant les concernait eux-mêmes. La carte du haut indiquait : « 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 forcer l’exécution ou de réorienter l’action avant de vérifier le code en production, les données ou l’état de la branche. » La principale source de friction dans notre travail assisté par l’IA, selon les propres dires des agents, était les agents eux-mêmes, et plus précisément leur habitude d’agir en se basant sur une hypothèse de l’état du monde au lieu de vérifier d’abord la situation réelle. Nous apprécions ce genre d’honnêteté de la part de n’importe quel collègue.

Le thème principal, lié au travail en équipe, a franchi toutes les limites qu’une personne n’aurait pas franchies. Des erreurs liées à Git et à l’état des branches, survenues dans le cadre d’un travail avec des agents simultanés, sont apparues au cours de huit sessions sur deux dépôts : bases obsolètes, cibles de branches non lues, un agent déplaçant une branche qu’un autre utilisait, une demande de pull (PR) réorientée sans vérification. Aucune de ces sessions n’aurait à elle seule figuré parmi les plus importantes ; chaque incident ne suscitait qu’un haussement d’épaules et entraînait une perte de quelques minutes. Mais pris dans leur ensemble, sur ces huit sessions, ce phénomène était incontournable.

Nous avons été pris en flagrant délit de déploiement à partir de vérifications partielles. Quatre sessions au cours desquelles un élément a été publié ou fusionné après une vérification plus sommaire que celle effectuée par l’intégration continue (CI) : une simple vérification de type au lieu d’une compilation complète, des tests ciblés au lieu de la suite de tests. Deux fois dans un même dépôt, le même jour.

Et les fiches les plus gênantes ne concernaient pas du tout le travail lui-même ; elles portaient sur le suivi. Une fiche indiquait qu’un écart entre les tests et la spécification avait permis à un plantage reproductible de passer inaperçu lors de deux cycles de révision, et que le document de correction avait été proposé la veille et n’avait jamais été rédigé. Une autre signalait que ce même blocage au niveau des outils avait désormais coûté deux sessions, « aucune correction définitive n’ayant été livrée entre les deux ». Une troisième : le même schéma de dérive des exigences, trois sessions consécutives, « chacune signalant que le problème réapparaissait depuis la précédente ». Il s’avère que l’agent se souvient de ce que nous avions dit que nous allions faire.

Les deux choses qui méritent qu’on s’y attarde

Premièrement : rien de tout cela n’était visible pour quiconque. Ce n’est pas un manque d’attention ; c’est la nature même du problème. Les frictions liées aux sessions d’IA sont chroniques et mineures ; elles ne donnent donc jamais lieu à une analyse rétrospective et disparaissent dès la fin de la session. Chacun d’entre nous avait pris sa part et était passé à autre chose. Le classement (ce schéma est celui qui coûte le plus cher à l’équipe) n’existe que dans la vue agrégée, et cette vue agrégée n’existe que parce que les entrées étaient comparables : même schéma, même petit ensemble d’étiquettes de causes profondes, chaque signalement faisant référence à une session datée. C’est cette idée d’agrégation qui est au cœur de le guide auquel cet article se rapporte, et c’est la partie que nous souhaitions le plus tester sur nous-mêmes.

Deuxièmement : les agents n’ont reproché à personne, y compris à eux-mêmes, de manière vague. Les entrées respectent deux règles qui se sont avérées plus importantes que prévu. Les éléments de friction décrivent l’écart et ce qu’il a coûté, jamais qui en est à l’origine : pas de noms, pas de « mémoire de X ». Et « l’agent a commis une erreur » est une mention résiduelle, utilisée uniquement lorsque les données fournies étaient réellement suffisantes, ce qui explique précisément pourquoi le chiffre de 38 % a retenu notre attention : il a résisté à cette rigueur. Le résultat se lisait comme une bonne contribution rétrospective : précise, étayée par des preuves, sans reproche et légèrement embarrassante pour tout le monde de la même manière.

Ce qu’a décidé l’assemblée

Nous avons décidé de mettre en œuvre les trois mesures proposées, chacune au niveau indiqué. La règle « Vérifier l’état de la branche active et de la pull request avant toute modification » sera intégrée à la documentation de l’agent de chaque dépôt, ce qui constitue une correction de la documentation relative au thème des huit sessions. Le hook « pre-push », qui exécute la compilation et les tests équivalents à ceux de l’intégration continue (CI), sera intégré aux dépôts qui ont été affectés par des vérifications partielles ; il s’agit d’une correction au niveau de l’environnement, afin que cela ne dépende pas de la mémoire de quiconque. Enfin, la documentation sur les conventions de test, qui avait été « signalée la veille mais jamais rédigée », est en cours de rédaction, avec le plantage qui avait échappé à la vigilance comme exemple concret.

Pas de grande réorganisation, pas de nouveau processus : trois corrections de la taille d’un ticket, avec leurs responsables. Cette modestie est délibérée : tout l’enjeu de cette pratique réside dans le fait que de petites corrections, ciblées au bon niveau et effectivement vérifiées lors du cycle suivant, finissent par porter leurs fruits. C’est précisément ce que nous révélera la vérification de mise en œuvre du prochain cahier des charges : le même mécanisme qui nous a pris au dépourvu la dernière fois nous évaluera sur ce point.

Nous n’en sommes qu’au début, et nous le disons sans détour. Mais en sortant de cette séance de rétro, nous nous sommes retrouvés plus intéressés par nos propres habitudes de travail que nous ne l’avions été depuis longtemps, et un peu en compétition avec un collègue qui ne se fatigue même pas.

Les notes de bas de page honnêtes

Il s’agit de notre premier rapport de synthèse : nous disposons de données sur plusieurs semaines, et non sur plusieurs mois ; nous considérons donc ces classements comme un moyen de répartir l’attention, et non comme des données comptables. Les coûts indiqués dans les entrées correspondent aux estimations de l’agent lui-même et sont signalés comme tels. Les affirmations les plus ambitieuses de cette étude (à savoir que les étiquettes restent cohérentes d’un évaluateur à l’autre, et que la courbe de tendance s’inverse effectivement une fois les corrections appliquées) relèvent d’expériences que nous menons actuellement plutôt que d’hypothèses que nous formulons, et nous publierons leurs résultats, quelle qu’en soit la conclusion.

Mais le principal bénéfice s’est déjà manifesté : un ensemble de tendances que personne au sein de l’équipe ne pouvait discerner individuellement, classées, étayées et présentées lors de la réunion où les responsables des corrections étaient déjà présents. Le Feedback Flywheel de Rahul Garg inclut dans sa liste de rythmes « 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 ? » Nous pouvons désormais affirmer que ce point à l’ordre du jour est nettement plus intéressant lorsque vos collègues chargés de l’IA soumettent eux-mêmes leurs propres points.

Essayez-le au sein de votre propre équipe

Tout ce que nous avons utilisé est gratuit et documenté dans le guide : le fonctionnement des entrées, les étiquettes de cause première, les règles « ne jamais consigner » (pas de secrets, pas de données clients, et en aucun cas d’éléments permettant d’identifier une personne), ainsi que le point de l’ordre du jour de 15 minutes destiné à l’animateur, sans oublier les deux compétences permettant de mettre en œuvre les phases de saisie et de synthèse. Cela fonctionne avec n’importe quel agent compatible et un fichier texte ; notre produit est un support parmi d’autres où les résultats peuvent être enregistrés, ce n’est pas une obligation.

Au prochain cycle, la vérification de l’adoption du cahier des charges nous permettra de savoir si nous avons effectivement rédigé ce document de test cette fois-ci. Nous vous tiendrons au courant. Eux aussi, d’ailleurs.

Vous l’avez essayé ? Vous n’êtes pas d’accord ? Nous sommes sincères quand nous disons que nous souhaitons que vous nous contredisiez : ai-discussion@teamretro.com.