Rejoindre une équipe, puis augmenter sa façon de travailler avec des agents

La plupart de mes missions commencent de la même façon : une équipe existe déjà, avec son code, ses habitudes, ses rituels et ses angles morts. Je n’arrive pas sur un terrain vierge, et c’est tant mieux. Une équipe qui livre a toujours de bonnes raisons de faire ce qu’elle fait, même quand elle ne les a jamais écrites.

Mon rôle n’est pas de remplacer cette façon de travailler par la mienne. Il est d’y ajouter, à la mesure de l’équipe, ce que j’appelle des primitives de travail agentique : des pièces simples, que les humains comme les agents savent utiliser, et qui restent quand je pars. Voici comment je m’y prends, avec des exemples tirés de projets réels et de mon propre atelier.

D’abord, écouter le dépôt

Les premières semaines, je lis plus que je n’écris. L’historique Git, les tickets, les conventions implicites, la façon dont une revue se passe, ce qui fait peur à l’équipe quand elle déploie. Je pose beaucoup de questions, souvent naïves, parce que ce sont celles qu’un agent poserait s’il le pouvait.

Ce que je comprends, je l’écris. Pas dans un rapport que personne ne lira, mais dans un fichier court à la racine du dépôt, que l’équipe relit comme du code : à quoi sert ce projet, comment il est organisé, ce qu’il ne faut surtout pas casser, où trouver le reste. C’est la première primitive, et la plus rentable. Un nouvel arrivant y gagne une semaine. Un agent y gagne la différence entre une modification plausible et une modification juste.

Écrire ce que l’équipe sait déjà

La deuxième primitive est la décision consignée. Sur le projet d’automatisation SAV auquel je contribue pour Santécie, le dépôt porte aujourd’hui des décisions d’architecture écrites une par une, un audit des flux et un glossaire métier partagé avec les utilisateurs. Sur le banc d’essai de lecture de cartes de complémentaire santé, onze décisions d’architecture expliquent pourquoi chaque option a été retenue ou écartée.

Ces documents ne sont pas de la bureaucratie. Ce sont eux qui permettent de répondre, six mois plus tard, à « pourquoi le système fait-il cela ? ». Et ce sont eux qu’un agent lit avant de proposer un changement, au lieu de deviner.

Dans mon propre espace de travail, je pousse la logique plus loin : chaque dossier a un fichier d’instructions pour les agents, chaque projet sa fiche, le contexte durable vit dans docs/ et l’état temporaire dans un dossier à part. Un agent sait où il est, ce qui s’applique ici, et où écrire ce qu’il découvre. Je ne l’impose pas tel quel à une équipe ; j’en installe la version qui lui sert.

Transformer les procédures en skills

Toute équipe a des procédures qui reviennent : préparer une mise en production, relire une migration, rédiger un compte rendu. Quand une procédure revient assez souvent et qu’elle a des règles de vérification claires, elle devient une skill : un savoir-faire écrit que l’agent charge au bon moment, avec ses étapes et ses contrôles.

Chez moi, la préparation de mon compte rendu d’activité mensuel en est une. L’agent reconstitue l’activité à partir de l’historique Git et de mes sessions de travail, sépare les projets, vérifie la couverture de chaque jour, puis prépare la facture et l’email. Il ne les envoie jamais : il me les présente.

La bonne skill n’est pas la plus ambitieuse. C’est celle qui retire à l’équipe une tâche qu’elle fait sans plaisir, tout en gardant les points où son jugement compte.

Passer des conversations aux workflows

Une conversation avec un agent suffit pour une tâche courte. Pour une tâche longue, elle devient fragile : le contexte s’épuise, une étape est oubliée, personne ne sait où l’on en est. Je décris alors le travail comme un graphe d’étapes, avec un état explicite, des reprises possibles et des validations humaines aux endroits qui engagent.

C’est l’objet de deux outils que je publie, pi-graph et Zedflow. Dans Zedflow, une validation humaine est une étape du graphe, vérifiée sur des données typées : le montant, le destinataire, la période. Pas sur un « ça a l’air bon ».

La preuve avant la confiance

Un agent qui annonce « c’est fait » n’a rien prouvé. Je fais donc entrer la vérification dans le flux de travail : un build et une vérification de types après chaque passe, des tests qui échouent avant d’être corrigés, une relecture humaine avant publication. Un agent qui ne peut pas montrer ce qu’il a vérifié n’a pas terminé.

Cela vaut aussi quand un agent bloque. Pendant la construction de ce site, un agent chargé de générer des images s’est heurté à une limite de son bac à sable. Il s’est arrêté, a décrit l’erreur et proposé deux façons de débloquer, au lieu de désactiver la protection de lui-même. C’est exactement le comportement que je veux installer : échouer clairement plutôt que réussir en apparence.

Ce que cela donne sur un vrai projet : ce site

Ce site a été construit par plusieurs agents, chacun avec un périmètre de fichiers attribué : l’un pour la structure des pages, l’autre pour l’expérience de lecture, un troisième pour le contenu. Ils se transmettaient des contrats écrits, ce que chacun avait livré, ce qu’il n’avait pas touché, ce qui restait ouvert. Chaque passe se terminait par un build et une vérification de types.

Tout n’a pas été lisse. Un agent de contenu a été arrêté en cours de route ; le suivant a dû relire ses modifications partielles une à une au lieu de leur faire confiance. C’est précisément pour ce genre d’incident que les primitives existent : l’état était écrit, les règles aussi, et la reprise a été une relecture, pas une enquête.

Ce que je n’installe pas

Je n’arrive pas avec une pile d’outils à adopter en bloc. Je n’introduis pas d’agent sur des données de production sans frontière écrite. Je ne promets pas de gain de productivité avant de l’avoir mesuré. Et je ne demande pas à une équipe de renoncer à ce qui fait la fierté de son métier : les agents prennent les gestes mécaniques, les développeurs gardent le jugement.

Par où commencer

Si vous voulez essayer dans votre équipe, trois gestes suffisent pour démarrer :

1. Écrire le fichier de contexte de votre dépôt principal, en une page, et le relire en équipe.
2. Choisir une procédure qui revient chaque semaine, l’écrire comme une skill avec ses vérifications, et la confier à un agent sous supervision.
3. Fixer une règle de preuve : aucune modification d’agent n’est acceptée sans le build, les tests et une relecture humaine.

Le reste vient avec l’usage. Et si vous voulez qu’on le fasse ensemble, c’est précisément le travail que je propose.