Étendre l’agent

Vous avez démonté la machine, donné au repo de quoi se présenter, transformé l’intention en demande, tenu la barre pendant l’exécution. Tout ça avec l’agent tel qu’il sort de la boîte : lire, écrire, chercher, exécuter. Le même répertoire chez vous que chez n’importe qui.

L’anatomie avait posé deux principes en passant : la surface CLI de votre projet définit ce que l’agent sait faire, et la description d’un outil est un prompt. On va les actionner, et donner à la boucle un répertoire taillé pour votre projet — scripts maison, serveurs branchés, savoir-faire rechargeable.

Une seule règle, mais elle est non négociable : étendez par problème à résoudre, jamais par catalogue. J’ai commencé par faire exactement l’inverse, en branchant six serveurs MCP le premier week-end. Spoiler : c’était pire qu’avant.

---

Pourquoi une capacité coûte avant même de servir ?

Parce qu’un outil est un contrat — un nom, une description, un schéma de paramètres — et que ce contrat est présenté au modèle dans le contexte, comme tout le reste. Chaque capacité ajoutée occupe la fenêtre à chaque appel de la boucle, qu’elle serve ou non. Elle dispute le budget d’attention à vos consignes et au code de la tâche, exactement comme une ligne de trop dans votre fichier racine.

Alors appliquez le même test d’admission que pour le dossier de contexte : n’ajoutez une extension que pour résoudre une friction observée. Vous devez pouvoir la nommer, elle doit revenir, et vous devez pouvoir la compter en sessions perdues.

L’agent qui redécouvre vitest --run à chaque session : friction. Le rituel en quatre commandes que vous retapez à la main : friction. Le système que la boucle ne peut ni lire ni actionner : friction. « Ça pourrait servir » : pas une friction. C’est un coût certain acheté contre un gain hypothétique.

Et chaque outil ajouté élargit aussi le rayon d’action. Le critère ne change pas d’échelle : calibrez l’autonomie sur la réversibilité de ce que l’outil permet, jamais sur la confiance qu’il inspire. Une capacité qui lit est gratuite à autoriser. Une capacité qui agit sur un système externe — écrire dans Jira, poster sur Slack, toucher à votre cloud — mérite la question avant même l’installation : qu’est-ce qui se défait, et comment ?

Pourquoi commencer par un simple script ?

Parce que l’extension la moins chère n’a besoin d’aucune intégration. Si la surface CLI de votre projet définit ce que l’agent sait faire, alors traitez cette surface comme une interface pour l’agent.

Un scripts/verify.sh bien nommé, avec une aide en une ligne et des échecs explicites, est un outil au sens plein du contrat. L’agent le découvre, vous le déclarez dans le fichier d’instructions parmi les commandes qui font foi, et l’outil shell de n’importe quel harnais l’exécute. Zéro configuration.

Cadrez le travail par friction, pas par technologie :

• Figez le rituel en une commande. Vous dictez build, tests, lint et migrations à chaque session ? Écrivez pnpm verify, qui échoue fort et tôt. La boucle ne converge que vers ce que vos outils vérifient.

  pnpm verify # lint + types + tests + migrations, dans cet ordre

• Transformez la convention en générateur. Un nouveau module chez vous a une forme : un dossier, un fichier de test, une ligne dans un index. Écrivez pnpm gen:module. Vous venez de remplacer une page de consignes par une commande — moins de lignes dans le dossier, moins de déviations à corriger.

• Rendez lisible ce que vous seul voyez. Le seed de la base locale, la version déployée, la santé de vos services de dev : donnez-en une commande qui les imprime en texte, le médium natif du modèle.

Le bénéfice est double, et c’est ce qui rend ces scripts si rentables : ils servent aussi les humains et votre CI, et vous les testez, versionnez et déboguez avec vos outils habituels. D’où la règle de préséance que j’applique sans exception — si la capacité peut être un script, faites-en un script. Les mécanismes plus lourds attendent que le shell ne suffise plus.

Quand brancher un serveur d’outils ?

Quand la capacité résiste au shell, et pas avant. Le navigateur qui rend votre frontend, Jira derrière son authentification, Sentry, la base de production en lecture seule : là, oui.

Un serveur d’outils, c’est un processus qui expose au harnais un catalogue d’outils (noms, descriptions, schémas) via un protocole commun — MCP s’est imposé comme le standard de fait. La mécanique de la boucle ne change pas d’un poil : le répertoire s’agrandit, le modèle demande, le harnais exécute.

Là encore, partez du problème, jamais du produit. Vous branchez un serveur pour que l’agent voie la page rendue, lise les erreurs de production, ouvre la documentation interne. Ou pour qu’il agisse sur ce qu’il ne pouvait pas actionner. Si vous n’arrivez pas à formuler le besoin en ces termes-là, n’installez pas le serveur.

Parce que le coût, lui, est permanent. Un serveur branché injecte son catalogue entier dans la fenêtre à chaque appel. Dix outils décrits, ce sont dix contrats payés sur chaque itération de chaque session, pour la poignée qui servira vraiment.

J’aime bien l’image de la caisse à outils qu’on emmène sur un chantier : vous prenez ce dont la journée a besoin, pas tout l’atelier. Le serveur de navigateur quand la tâche touche au frontend, celui de Jira quand la session instruit un bug, et on débranche après. Un agent suréquipé n’est pas un agent capable, c’est une fenêtre diluée.

LE CRAFTOMANCER

Dès qu’un outil lit du contenu extérieur (pages web, tickets, docs, réponses d’API), vous ouvrez votre fenêtre à du texte que vous n’avez pas écrit. Or « Le contexte est la seule réalité du modèle » l’a posé : pour le modèle, tout est du texte au même rang. Une instruction glissée dans une page lue peut infléchir la boucle au même titre qu’une consigne de votre main. Le danger ne vient pas d’une capacité, mais de leur croisement. Lecture de contenu non maîtrisé, accès à des données sensibles, action vers l’extérieur : réunissez les trois dans une session, et vous avez monté une exfiltration qui n’attend plus que son texte. N’accordez jamais les trois sans point d’arrêt humain sur l’action.

C’est quoi une procédure rechargeable ?

Un document versionné que l’agent charge à la demande, quand la tâche l’exige — et c’est la réponse à la friction la plus fine : les procédures qui reviennent.

La release, la montée de version d’une dépendance, l’audit d’accessibilité, votre façon d’écrire un ADR. Ce savoir-faire est trop volumineux pour le fichier racine : il y taxerait chaque session pour servir une fois sur vingt, et il échouerait à votre propre test d’admission. Mais vous ne pouvez pas non plus le respécifier à chaque fois, ça revient bien trop souvent.

Commande personnalisée, skill : le nom varie selon le harnais, le principe non. Vous versionnez un document markdown, éventuellement accompagné de ses scripts, et l’agent le charge quand il en a besoin. Vous retrouvez exactement l’arbre du dossier de contexte, appliqué au savoir-faire : une racine courte qui pointe vers la profondeur, le détail payé seulement dans les sessions qui en ont besoin.

Écrire une procédure, c’est écrire une spécification qui servira cent fois : objectif observable, périmètre fermé en négatif, conditions de fin vérifiables. Oubliez le critère de fin, et vous laissez cent sessions décider chacune quand c’est terminé.

Vous tenez d’ailleurs ici la quatrième destination d’une correction. L’Étape précédente en donnait trois — la session, la spécification, le dossier. Voici la dernière : quand ce qui revient de session en session n’est pas une convention (vraie en tout temps : au dossier) mais une manière de faire (vraie quand on fait cette chose-là), écrivez-en une procédure rechargeable.

Comment entretenir son répertoire d’outils ?

Comme le reste du dossier de contexte, parce que c’en est. Rappelez-vous la règle d’hygiène : la session est jetable, les artefacts sont durables. Vos extensions sont des artefacts au sens plein — versionnez-les dans le repo, passez-les en revue.

Trois réflexes, tous déjà connus :

• Écrivez la description comme une consigne. Une description d’outil est un prompt. Décrivez vaguement, et l’agent ignorera l’outil ou l’emploiera de travers. Visez ce que vous visez dans le dossier : court, normatif, vrai.
• Traitez chaque déviation comme un rapport de bug. L’agent emploie votre outil de travers ou déroule votre procédure à côté ? Il signale une description vague ou un trou dans la consigne. Corrigez le document, pas la session. Et testez comme vous testez le dossier : session vierge, tâche représentative.
• Taillez l’inventaire. Un outil que les sessions n’appellent plus, une procédure que plus personne ne recharge, c’est du poids mort payé à chaque appel. Élaguez le répertoire comme le dossier : chaque capacité doit encore défendre sa place, sinon elle sort.

Dernier bénéfice, et pas le moindre : en versionnant ce répertoire dans le repo, vous outillez chaque collègue de la même façon. Votre agent devient reproductible, au lieu de rester la configuration artisanale d’une seule machine — la vôtre.

En pratique

• N’étendez que sur friction observée : nommée, récurrente, mesurable en sessions perdues. Le réflexe du catalogue paie un coût certain contre un gain hypothétique.
• Épuisez le shell d’abord : si la capacité peut être un script aux échecs explicites, c’est un script, déclaré parmi les commandes qui font foi.
• Branchez les serveurs d’outils par besoin de session, jamais par défaut : chaque catalogue connecté se paie à chaque appel de la boucle.
• Ne réunissez jamais lecture de contenu non maîtrisé, données sensibles et action vers l’extérieur sans point d’arrêt humain.
• Encapsulez les manières de faire récurrentes en procédures rechargeables, écrites comme des spécifications, avec leur condition de fin.
• Traitez chaque extension en artefact du repo : description normative, testée sur session vierge, corrigée quand l’agent dévie, élaguée quand elle ne sert plus.

Vérifiez votre modèle

Quatre questions pour voir si le répertoire est bien tenu. Cliquez une réponse : le verdict s’affiche.

RUN · V 0 / 4

jack in — choisissez votre réponse

Qu’est-ce qui justifie d’ajouter une capacité au répertoire ?

▶ une friction observée : nommée, récurrente, mesurable ▶ l’existence d’un serveur officiel bien fait ▶ le fait qu’elle ne coûte rien tant qu’on ne s’en sert pas

La capacité dont vous avez besoin tient dans un script. Alors ?

▶ c’est un script ▶ mieux vaut un serveur d’outils, c’est plus propre ▶ ça dépend du harnais utilisé

Vous aviez branché le serveur de navigateur pour une tâche frontend. La session suivante instruit un bug d’API. Le bon réflexe ?

▶ débrancher le serveur devenu inutile pour cette session ▶ le laisser branché, ça resservira ▶ ajouter le serveur d’API à côté, sans toucher au reste

Le point d’arrêt humain devient obligatoire dès qu’une session réunit…

▶ lecture de contenu non maîtrisé, données sensibles, action vers l’extérieur ▶ lecture de contenu non maîtrisé et données sensibles ▶ un seul outil au périmètre très large

Vous refermez ici le répertoire d’outils. Machine démontée, repo qui se présente, demande spécifiée, session conduite, et un agent outillé pour votre projet. Sauf qu’un agent bien équipé produit beaucoup — et produire beaucoup n’a jamais garanti de bien produire. Prochaine Étape : les agents autonomes, quand la boucle tourne pendant que vous faites autre chose.