Étendre l'agent

La Section a démonté la machine, appris au repo à 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 : un répertoire générique (lire, écrire, chercher, exécuter), le même chez vous que chez n’importe qui.

Le guide 01 avait posé les deux leviers 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. Ce guide les actionne. Donner à la boucle le répertoire que votre contexte mérite : outils maison, serveurs branchés, savoir-faire rechargeable. Avec la règle qui gouverne tout le reste : on étend par problème à résoudre, jamais par catalogue.

---

Une capacité se paie avant de servir

Le guide 01 l’a établi : un outil est un contrat (nom, description, schéma) présenté au modèle dans le contexte, comme tout le reste. La conséquence économique est immédiate : chaque capacité ajoutée occupe la fenêtre à chaque appel de la boucle, qu’elle serve ou non. Une extension n’attend pas d’être utile pour coûter. Elle dispute le budget d’attention aux consignes de votre dossier et au code de la tâche, exactement comme une ligne de trop dans le fichier racine.

D’où le test d’admission, le même que pour le dossier de contexte : une extension entre au répertoire pour résoudre une friction observée. Nommée, récurrente, mesurable en sessions perdues. L’agent qui redécouvre votre procédure de test à chaque session, le rituel de vérification en quatre commandes retapé à la main, le système que la boucle ne peut ni lire ni actionner : voilà des frictions. « Ça pourrait servir » n’en est pas une. C’est le réflexe du catalogue, un coût certain payé contre un gain hypothétique.

Et chaque outil ajouté élargit le rayon d’action. Le critère du guide 01 ne change pas d’échelle : l’autonomie se calibre sur la réversibilité de ce que l’outil permet, pas sur la confiance qu’il inspire. Une capacité qui lit est gratuite à autoriser. Une capacité qui agit sur un système externe mérite la question avant l’installation : qu’est-ce qui se défait, et comment ?

D’abord épuiser le shell

L’extension la moins chère n’a besoin d’aucune intégration : c’est un script. Le guide 01 retournait la perspective (la surface CLI de votre projet définit ce que l’agent sait faire) ; la retourner en levier, c’est travailler cette surface comme une interface pour l’agent. Un script bien nommé, avec une aide en une ligne et des échecs explicites, est un outil au sens plein du contrat : découvrable, descriptible dans le dossier de contexte parmi les commandes qui font foi, exécutable par l’outil shell que tout harnais possède déjà.

Le travail se cadre par friction, pas par technologie :

• Le rituel devient une commande. La vérification en quatre étapes que vous dictez à chaque session (build, tests, lint, migration à jour) se fige en une seule commande qui échoue fort et tôt. La boucle du guide 01 ne converge que vers ce que vos outils vérifient. Une commande de vérification unique est le meilleur investissement par ligne de code de toute cette Section.
• La convention devient un générateur. Un nouveau module chez vous a une forme : arborescence, fichier de test, enregistrement quelque part. Un générateur qui l’estampille transforme une page de consignes en une commande. Moins de lignes dans le dossier, moins de déviations à corriger.
• L’invisible devient lisible. L’état que vous seul savez consulter (le seed de la base locale, la version déployée, la santé des services de dev) devient une commande qui l’imprime en texte, le médium natif du modèle.

Le dividende est double : tout ça sert aussi les humains et la CI, se teste, se versionne et se débogue avec vos outils habituels. La règle de préséance en découle : si la capacité peut être un script, c’est un script. Les mécanismes plus lourds se justifient seulement quand le shell ne suffit plus.

Brancher l’extérieur : les serveurs d’outils

Certaines capacités résistent au shell : le navigateur qui rend votre frontend, le gestionnaire de tickets derrière son authentification, la plateforme d’observabilité, la base de production en lecture seule. Pour celles-là, le pattern est le serveur d’outils : un processus qui expose au harnais un catalogue d’outils (noms, descriptions, schémas) via un protocole standard. MCP en est aujourd’hui la lingua franca. La mécanique de la boucle ne change pas d’un iota : le répertoire s’agrandit, le modèle demande, le harnais exécute.

Le cadrage reste celui du problème, jamais du produit. Donner à l’agent des yeux sur ce qu’il ne pouvait pas lire (la page rendue, les erreurs en production, la documentation interne), ou des mains sur ce qu’il ne pouvait pas actionner. Si le besoin ne se formule pas en ces termes, le serveur n’a rien à faire dans votre configuration.

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, c’est dix contrats payés sur chaque itération de chaque session, pour la poignée qui servira. Branchez par besoin de session, pas par défaut. Le serveur de navigateur quand la tâche touche au frontend, le serveur de tickets quand la session instruit un bug. L’agent suréquipé n’est pas un agent capable : c’est une fenêtre diluée.

Le tips Craftomancer

Tout outil qui lit du contenu extérieur (pages web, tickets, docs, sorties d’API) ouvre votre fenêtre à du texte que vous n’avez pas écrit. Or les Fondamentaux l’ont posé : pour le modèle, tout est du texte au même rang. Une instruction enfouie dans une page lue peut infléchir la boucle avec le même aplomb 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 et action vers l’extérieur, réunis dans la même session, forment une exfiltration qui n’attend que son texte. N’accordez jamais les trois sans point d’arrêt humain sur l’action.

Encapsuler le savoir-faire : les procédures rechargeables

Reste 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. Du savoir-faire trop volumineux pour le fichier racine, qu’il violerait le test d’admission en taxant chaque session pour servir une fois sur vingt. Et trop récurrent pour être respécifié à chaque fois.

Le pattern : la procédure rechargeable. Commande personnalisée, skill, le nom varie selon le harnais. Un document versionné, consigne en markdown éventuellement accompagnée de ses scripts, que l’agent charge quand la tâche l’exige. C’est 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. Une procédure sans critère de fin laissera cent sessions décider chacune quand c’est terminé. Et le chemin de promotion de la Section s’achève ici. Le guide 04 donnait trois étages à une correction : la session, la spécification, le dossier. Le quatrième se dessine. Quand ce qui revient de session en session n’est pas une convention (vraie en tout temps : sa place est au dossier) mais une manière de faire (vraie quand on fait cette chose-là), sa place est dans une procédure rechargeable.

L’extension est un artefact, pas un réglage

Le guide 04 a posé la règle d’hygiène : la session est jetable, les artefacts sont durables. Vos extensions sont des artefacts au sens plein. Elles vivent dans le repo, versionnées, partagées en revue comme le reste du dossier de contexte. Trois réflexes en découlent, tous déjà connus :

• Une description d’outil est un prompt. Le guide 01 le promettait pour le jour où vous étendriez l’agent ; ce jour est arrivé. Un outil vaguement décrit est un outil ignoré ou mal employé. Écrivez la description comme une consigne du dossier : courte, normative, vraie.
• Chaque déviation est un rapport de bug contre l’artefact. L’agent qui emploie votre outil de travers ou déroule votre procédure à côté signale une description vague ou un trou dans la consigne. Corrigez le document, pas la session. Et testez comme on teste le dossier : une session vierge, une tâche représentative, au prix d’un café.
• L’inventaire se taille. Un outil que les sessions n’appellent plus, une procédure que plus personne ne recharge, c’est du poids mort payé à chaque appel. Le répertoire s’élague comme le dossier : chaque capacité doit encore défendre sa place, sinon elle sort.

Le dividende dépasse votre poste. Un répertoire versionné dans le repo, c’est la même pratique outillée pour chaque collègue : l’agent de votre projet devient reproductible, au lieu d’être la configuration artisanale d’une seule machine.

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.

Ici se referme la Section. La machine est démontée, le repo sait se présenter, la demande se spécifie, la session se conduit, et le répertoire est désormais le vôtre : un agent outillé pour votre contexte, productif, borné par vos filets. C’est précisément ce qui rend la suite urgente. Produire plus n’a jamais garanti produire bien, et un agent bien équipé produit beaucoup. Prochaine étape du Parcours : la Section « Aiguiser le craft ». Tests, revue, dette, sécurité : maintenir l’exigence artisanale quand la machine écrit le code.