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 dédiée aux actions en cours, et les discussions habituelles du vendredi. La semaine dernière, elle a accueilli de nouveaux contributeurs. Six de ces 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 relevés lors 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 collègue : 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’idée 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 cours d’une session ce matin-là, en passant, avant que le contexte ne disparaisse du fil de discussion. L’agent en avait pris connaissance ; rien dans son environnement 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 : la méthode est celle 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 note de rétrospective structurée sur son propre travail : ce qui s’est bien passé, ce qui a pris du temps, ce qu’a coûté chaque retard, une étiquette de cause première par élément, ainsi qu’une proposition de solution. 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 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 l’état réel. Nous apprécions ce genre d’honnêteté de la part de n’importe quel collègue.

Le principal problème 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 lors du 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 nous sommes fait prendre en train d’effectuer des validations partielles. Quatre sessions au cours desquelles un élément a été publié ou fusionné après une validation plus sommaire que celle effectuée par l’intégration continue (CI) : une simple validation de type au lieu d’une compilation complète, des tests ciblés au lieu de la suite de tests complète. 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 soulignait que ce même blocage au niveau de l’outil avait désormais coûté deux sessions, « sans qu’aucune correction définitive n’ait é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 en compte 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 ce concept d’agrégation qui est au cœur du guide auquel cet article fait référence, et c’est la partie que nous souhaitions le plus tester sur nous-mêmes.

Deuxièmement : les agents n’ont accusé personne, pas même 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 relatifs aux frictions décrivent l’écart et son 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 véritablement adéquates, 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 accusation 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 prévu. 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 relative aux 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 la vérification de l’adoption du prochain brief qui nous dira si ces trois corrections ont été retenues ; 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 journée « 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 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 approche (à 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 personnes chargées des corrections étaient déjà présentes. Le Feedback Flywheel de Rahul Garg inclut dans sa liste de cadence « 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 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 de non-enregistrement (pas de secrets, pas de données clients, et en aucun cas d’informations 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.