Installer un agent de code : ce qui compte vraiment

La requête qui vous amène ici attend un tutoriel. Je vais commencer par décevoir : l'installation prend quelques minutes, la documentation de l'éditeur la décrit mieux que je ne saurais le faire, et elle sera encore juste dans six mois quand mes commandes à moi auront vieilli. Ce qui coûte du temps se joue ailleurs, avant et après, et c'est exactement la partie dont personne ne parle.

Installer un agent de code sur un poste prend quelques minutes, mais le rendre utile dans une équipe prend plutôt deux à trois semaines, et ce travail se fait presque entièrement en dehors de l'outil. Avant, il faut que le dépôt porte par écrit ce qu'une nouvelle recrue mettrait un mois à apprendre ; après, il faut décider ce que l'agent a le droit de faire, par où son travail entre, et qui tient cette mémoire à jour.

Pourquoi je n'écrirai pas la procédure d'installation

Trois raisons, et aucune n'est de la paresse. La première : ces outils bougent vite, et une page qui donne la commande du mois devient fausse sans prévenir, ce qui est pire que de se taire, parce que le lecteur tombe dessus avec confiance. La deuxième : l'éditeur publie cette procédure et la tient à jour. La troisième est la plus importante. Dans les équipes que j'accompagne, le moment où l'outil se met à tourner n'a jamais été le moment difficile, et personne ne s'est jamais arrêté là. Les semaines compliquées arrivent après, quand il faut répondre à des questions que la documentation ne pose pas : ce que cet agent a le droit de modifier, qui relit ce qu'il produit, et à quoi on verra qu'il sert à quelque chose. C'est le déséquilibre que je décris dans la préparation prime sur l'exécution : la partie visible du travail n'est pas celle qui le détermine.

Ce que votre dépôt doit contenir avant que l'agent arrive

Un agent de code n'a aucune antériorité. Il ouvre votre projet comme un prestataire qui débarque un lundi matin, sauf qu'il ne peut pas se tourner vers le voisin de bureau pour demander pourquoi ce module s'appelle comme ça. Tout ce qui n'est pas écrit n'existe pas pour lui. Si la connaissance du projet vit dans la tête de trois personnes, sa première semaine se passe à poser des questions auxquelles personne n'a jamais rédigé la réponse, et chacun la lui redonne de son côté, un peu différemment. L'outil n'est pas en cause : il est aveugle. Voici les quatre choses que je vérifie avant de le laisser travailler.

Une documentation de projet qu'un humain lit sans effort

Pas une documentation d'API générée automatiquement : un texte court qui dit à quoi sert le projet, comment il est découpé, et quelles décisions structurantes ont été prises avec leurs raisons. Si un nouveau venu la lit en vingt minutes et comprend le terrain, l'agent aussi.

Des conventions écrites, y compris celles qui semblent évidentes

Nommage, structure des dossiers, façon de gérer les erreurs, ce qu'on ne fait jamais ici et pourquoi. Les tacites coûtent le plus cher : leur violation ne se voit qu'en relecture, et seulement par ceux qui les connaissent déjà.

Une commande de test qui tourne vraiment, du premier coup

Le point le plus sous-estimé. Un agent qui peut lancer les tests se corrige seul et vous rend du travail déjà vérifié. Sinon, il vous rend des propositions à valider à la main, une par une.

Une définition de « terminé » que l'équipe applique déjà

Tests passés, relu par quelqu'un, documentation à jour : peu importe la liste, elle doit exister et être la même pour tout le monde. Sans elle, personne ne peut dire si le travail rendu est fini.

Ce qui m'a frappé en refaisant cet exercice, c'est que cette liste n'a rien de spécifique à l'IA. Ce sont les quatre choses qu'on reproche à un projet mal tenu depuis vingt ans, et qu'on remet à plus tard parce que l'équipe en place sait faire sans. L'agent ne crée pas ce manque : il le facture immédiatement, en pleine lumière et devant toute l'équipe. C'est pour ça que ce travail n'est jamais perdu, puisque la même documentation sert aux humains et survivra à l'outil qui vous aura poussé à l'écrire. J'ai détaillé cette mécanique dans le monorepo comme mémoire du projet.

Les décisions qu'aucune installation ne prend à votre place

Une fois l'outil en place, trois questions se posent le premier jour, et elles n'ont pas de bonne réponse universelle. Jusqu'où l'agent va-t-il sans demander ? Sur quels fichiers et quels environnements a-t-il le droit d'intervenir ? Et que se passe-t-il quand il veut faire quelque chose qui sort de ce cadre ? Ces réponses dépendent de votre contexte, de la sensibilité des données que manipule le projet, et de la maturité de l'équipe. Les trancher demande une demi-journée de discussion avec les bonnes personnes autour de la table, pas un fichier de configuration. Et les laisser implicites revient à les trancher quand même, en moins bien, puisque chacun appliquera alors son propre curseur.

La question	Ce qui se passe si vous ne tranchez pas
Jusqu'où l'agent va sans demander	Chaque développeur fixe un curseur différent
Ce qu'il peut toucher	Il finit par toucher ce que personne n'avait prévu
Qui relit ce qu'il produit	Le volume augmente, la relecture reste au même coût

Le piège du périmètre trop large

La tentation du premier jour est de tout autoriser, parce que chaque demande de validation ralentit. C'est l'ordre inverse qui fonctionne : commencez étroit, élargissez quand une limite vous gêne pour une raison que vous savez nommer. Resserrer un périmètre après coup coûte toujours plus cher, parce qu'il faut défaire des habitudes déjà prises.

Par où son travail entre dans le dépôt

C'est la décision la plus structurante, et elle se prend avant la première ligne produite. Un agent génère du code vite, en quantité, et ce flux arrive quelque part. S'il arrive directement sur la branche principale, vous avez remplacé un goulot d'étranglement par un autre, en plus silencieux. S'il passe par le chemin du travail de n'importe qui, revue comprise, votre dispositif existant encaisse le volume et vous voyez ce qui entre. Je recommande le second, sans originalité, et j'y ajoute une chose : que l'historique dise clairement ce qu'une machine a produit. Pas pour le stigmatiser, mais parce que dans un an, quand quelqu'un cherchera pourquoi ce choix a été fait, la réponse ne sera pas la même selon l'origine.

Reste la question que j'entends le moins souvent : qui tient la mémoire du projet à jour, maintenant qu'elle est devenue un actif opérationnel. Tant que la documentation ne servait qu'à l'accueil des nouveaux, personne ne voyait qu'elle dérivait. Dès qu'un agent s'en nourrit tous les jours, une convention périmée produit du code périmé, immédiatement et à l'échelle. Cette responsabilité doit avoir un nom, un rendez-vous récurrent, et une place dans la définition de « terminé ». Elle gagne parfois à être partagée au-delà des développeurs : j'ai décrit comment donner à un fondateur non technique un accès direct à cette mémoire.

À quoi vous verrez, au bout de trois semaines, que ça a servi

Pas au nombre de lignes produites, qui ne mesure rien et qui augmentera de toute façon. Trois signaux valent mieux. Le premier : la proportion de ce que l'agent rend qui part en revue sans être réécrit avant. Si elle monte, c'est que la mémoire du projet s'est améliorée, et le mérite revient à ce que vous avez écrit. Le deuxième : le nombre de fois où quelqu'un réexplique à l'agent une chose déjà dite la semaine d'avant. Chaque répétition désigne un trou précis dans ce qui est écrit, et c'est une liste de tâches gratuite. Le troisième : le temps que met un nouvel arrivant à faire sa première contribution utile. Il bouge dans le même sens que les deux autres, parce qu'il mesure la même chose.

Un quatrième signal se lit en négatif, et c'est le plus parlant. Au bout de trois semaines, demandez à l'équipe ce qui a changé. Si la réponse tient à l'outil, le déploiement reste fragile et dépendra du prochain changement de version. Si la réponse parle du projet, de ce qui est enfin écrit, de discussions qui ont eu lieu parce qu'il fallait trancher, alors ce que vous avez installé ne s'enlève plus. C'est le critère que je retiens, et celui qui distingue les équipes où ça prend de celles où ça retombe au bout d'un mois. Le reste du raisonnement est dans le guide de l'IA agentique et dans la façon dont j'accompagne ce déploiement.

Ce que ça dit de l'outillage en général

Je termine par une remarque qui dépasse le sujet. Chaque fois qu'un outil nouveau arrive dans une équipe, la discussion se concentre sur l'outil, parce que c'est la partie qu'on peut regarder, comparer, démontrer. Et presque toujours, ce qui détermine le résultat se trouve dans ce que l'équipe avait déjà, ou pas. Un agent de code rend le phénomène spectaculaire : il consomme directement la qualité de votre documentation et de vos conventions, sans la médiation d'un humain qui comble les trous sans s'en rendre compte. C'est inconfortable, et c'est la meilleure nouvelle du sujet : ce travail est celui que vous auriez dû faire de toute façon.