Former une équipe aux agents IA : l'outil, c'est la partie facile

Apprendre à se servir d’un agent IA, c’est l’affaire de quelques jours. N’importe quel développeur sait installer l’outil, écrire une demande et accepter une modification. C’est pour ça que tant de formations s’arrêtent là, et c’est pour ça qu’elles changent si peu de choses.

Le vrai sujet, c’est l’équipe. Des gens qui n’en sont pas au même point, qui n’ont pas les mêmes envies, qui travaillent sur des projets avec leur histoire et leurs contraintes. Les faire progresser ensemble, ça ne se fait pas avec un programme sur étagère. Il faut les écouter, leur laisser du temps, savoir ce qui doit être enseigné et ce qui doit être vécu, et accepter que le plan prévu au départ ne soit pas celui qu’on suivra.

C’est comme ça que je travaille, et le parcours que je viens d’animer pour l’équipe de développement d’une agence web en est un bon exemple.

Partir de l’équipe, pas du programme

La demande de départ était raisonnable : deux jours, une formation puis un hackathon. Mais l’équipe que j’avais en face n’était pas homogène. Certains pilotaient déjà un agent tous les jours, d’autres ouvraient le chat de leur IDE de temps en temps, et l’un d’eux n’avait aucune envie d’arrêter d’écrire son code. Un même contenu, déroulé en deux jours, aurait ennuyé les uns et perdu les autres.

J’ai donc commencé par un cadrage, et je voulais que ce soit une vraie discussion plutôt qu’un recueil de besoins. Pour ça, j’ai développé une petite application : mes slides d’un côté, mes notes de l’autre, le tout projeté. L’équipe voit ce que je retiens, corrige, ajoute. Le programme de la première session a bougé pendant la réunion, avec par exemple un panorama de l’IA locale qui n’était pas prévu.

L'application de cadrage : la slide du programme de la session fondamentaux à gauche, les ajustements demandés par l'équipe saisis en direct à droite

Le parcours qui en est sorti s’étale sur plusieurs mois, en sept étapes. Ce n’est pas un modèle que je ressors pour chaque client : c’est celui qui convenait à cette équipe, à ses projets et à son rythme.

Le parcours en sept étapes : cadrage, conception et préparation, fondamentaux, expérimentation, retour d'expérience, hackathon et consolidation, skills d'équipe

Enseigner ce qui dure

Personne ne sait quel agent sera le plus utilisé dans un an. Si j’apprends à une équipe à se servir d’un outil précis, mon travail sera périmé avant la fin de l’année. Je préfère enseigner ce qui reste vrai d’un outil à l’autre : ce qu’est un modèle et pourquoi il n’a pas de mémoire, ce qu’est une fenêtre de contexte, ce qu’est un agent et le harnais qui l’entoure.

L’équipe n’avait d’ailleurs pas encore choisi son outil. Les démonstrations ont tourné sur plusieurs agents, sur un projet préparé dans leur stack, avec des résultats très proches de l’un à l’autre. J’en ai fait un article, Vous n’avez pas le bon débat. C’est le meilleur argument que je connaisse pour convaincre une équipe que la question n’est pas l’outil, mais la façon de s’en servir.

Laisser le temps faire son travail

La partie la plus importante du parcours, c’est celle où je ne suis pas là. Après les fondamentaux, chacun a expérimenté seul, sur ses vrais projets, avec un canal ouvert pour me poser des questions. C’était prévu sur deux semaines, ça a duré six, et c’était très bien comme ça.

Quand on s’est retrouvés pour le retour d’expérience, chacun arrivait avec ses réussites, ses échecs, ses agacements. Mon rôle a été de transformer ces expériences en règles communes. Un modèle bon marché qui s’enlise sur une demande simple, une montée de version complexe qui passe sans accroc parce qu’elle a été planifiée : ces histoires valent bien plus que n’importe quelle slide, parce que ce sont les leurs. C’est aussi là que sont apparues les premières idées de skills d’équipe.

Créer des moments qui marquent

La journée en présentiel, je l’ai conçue comme un moment à part. J’avais déjà raconté un premier hackathon, et cette fois j’ai développé une vraie plateforme pour l’animer : chacun rejoint depuis son téléphone, dépose anonymement une contrainte dans un « chapeau », suit le chrono, puis vote pour les autres. L’écran projeté révèle les contraintes une à une, puis le palmarès. (Captures refaites en local, prénoms fictifs et contraintes en partie inventées.)

L'écran projeté au moment de la révélation des contraintes, en partie inventées pour l'exemple : TDD, vidéo générée par IA, base de données imposée, Konami code, README soigné

Le jeu n’est pas là pour faire joli. Il oblige à sortir de ses habitudes, et il permet de récompenser ce que je veux voir progresser : pas seulement le résultat, mais la façon dont chacun a piloté son agent.

Deux vues téléphone de la plateforme, avec des prénoms fictifs : le chrono du hackathon avec les contraintes, puis l'écran de vote par catégorie

Le moment qui a le plus marqué l’équipe est venu d’une des contraintes : produire une vidéo de présentation générée par IA. Les teasers ont été générés par Opus 5.5, entièrement en HTML, CSS et JavaScript, et ils ont bluffé la salle. Pour moi, c’est le genre de déclic qui ne s’enseigne pas : comprendre qu’un agent produit du code, et que tout ce qui peut s’écrire en code est à sa portée. Je n’aurais pas pu le provoquer avec une démo. Il fallait que ça vienne d’eux.

Le palmarès projeté en fin de matinée : le plus beau rendu, le meilleur pilote d'agent, les contraintes les mieux domptées et le coup de cœur (prénoms fictifs)

Savoir lâcher son déroulé

L’après-midi, j’avais prévu que chacun écrive sa propre skill. L’équipe a préféré en construire une seule, ensemble, pour un besoin qu’elle avait tout de suite : démarrer un nouveau projet Symfony à ses standards, toujours de la même façon. J’ai rangé mon exercice.

C’était la bonne décision. En une séance, l’équipe a tranché des questions laissées ouvertes jusque-là, parce que l’agent les posait une par une et qu’il fallait bien répondre. On a ensuite comparé le résultat avec et sans la skill sur plusieurs cas de test : la différence était nette, et l’équipe repartait avec une liste précise de ce qu’il restait à améliorer. Elle sera diffusée par le marketplace de skills de l’équipe, versionnée et relue comme le reste du code.

Je crois que c’est là qu’une formation aux agents IA rapporte le plus : quand les choix de l’équipe sortent de la tête de quelques personnes pour être écrits, partagés et améliorés.

Ce que je laisse derrière moi

Au début du parcours, l’équipe se demandait quel outil choisir et s’il fallait vraiment s’y mettre. Au retour d’expérience, plus personne ne se demandait s’il fallait utiliser un agent, mais quand. Et en fin de parcours, les questions étaient devenues : quelle analyse statique imposer au code écrit par un agent, comment faire travailler plusieurs agents sans qu’ils se gênent, qu’est-ce qu’on relit en entier, qu’est-ce qui mérite une skill.

Ce sont ces questions-là que je cherche à faire émerger. Quand une équipe se les pose seule, elle n’a plus besoin de moi pour avancer. C’est ce travail-là que j’aime faire. Si votre équipe se pose ces questions-là, ou pas encore, on peut en parler.