Anatomie d'un agent

Les Fondamentaux ont posé la mécanique du modèle : une machine à continuer du texte, sans mémoire, dont le contexte est la seule réalité. Un agent, c’est cette mécanique mise en boucle et équipée d’outils.

Ce guide démonte la machine pièce par pièce. Pas par culture générale : chaque pièce explique un comportement que vous observerez en session, et le vocabulaire posé ici sert à toute la Section.

---

De l’autocomplete à l’agent

L’autocomplete propose une continuation ; vous acceptez ou rejetez. Le chat ajoute le tour de parole : le modèle répond, vous copiez-collez, vous exécutez à sa place. L’agent franchit le pas restant : il agit sur l’environnement et lit le résultat de ses actions.

La différence n’est pas l’intelligence du modèle (c’est souvent le même), c’est l’architecture autour. Un agent se décompose en trois pièces :

• le modèle, qui ne fait toujours qu’une chose : continuer du texte ;
• le harnais (l’application : CLI, extension d’IDE), qui exécute réellement les actions et reconstruit le contexte à chaque appel ;
• les outils, le répertoire d’actions que le harnais accepte d’exécuter pour le compte du modèle.

« L’agent », c’est l’ensemble. Gardez la décomposition en tête : elle évite une erreur d’attribution constante. La plupart des différences entre deux agents (ce qu’ils voient de votre repo, ce qu’ils ont le droit de faire, ce qu’ils retiennent entre les sessions) sont des propriétés du harnais, pas du modèle.

La boucle agentique : lire, agir, observer

Le cœur du fonctionnement tient en une boucle. À chaque itération :

1. le harnais assemble le contexte (instructions, historique, résultats d’outils précédents) et l’envoie au modèle ;
2. le modèle continue ce texte, soit par une réponse, soit par une demande d’appel d’outil : du texte structuré qui dit « exécute ceci » ;
3. le harnais exécute l’outil, capture le résultat, et l’injecte dans le contexte de l’itération suivante.

La boucle tourne jusqu’à ce que le modèle produise une réponse sans appel d’outil. Le modèle n’exécute jamais rien lui-même : il demande, le harnais fait, le résultat revient en texte.

C’est cette boucle qui change la nature du travail. Les Fondamentaux ont établi que la sortie d’un modèle n’a pas à être digne de confiance, mais vérifiable à bas coût. La boucle rend cette vérification automatique. Un agent qui peut lancer vos tests, lire l’échec et corriger converge vers du code qui passe, sans que vous arbitriez chaque étape. La qualité de votre outillage de vérification devient littéralement la qualité de l’agent.

La boucle a aussi son coût. Chaque résultat d’outil (chaque fichier lu, chaque sortie de commande) s’ajoute à la fenêtre de contexte. Une session agentique est une fenêtre qui se remplit vite, avec tout ce que les Fondamentaux ont dit de la dilution de l’attention. La dérive en fin de longue session n’est pas un mystère. C’est de l’arithmétique.

Les outils : le répertoire d’actions

Un outil est un contrat : un nom, une description, un schéma de paramètres. Le harnais présente ce catalogue au modèle (dans le contexte, comme tout le reste), et le modèle « choisit » un outil comme il fait tout : en continuant le texte le plus plausible vu la tâche.

Le répertoire type d’un agent : lire et modifier des fichiers, chercher dans le code, exécuter des commandes shell, consulter le web. S’y ajoutent les outils que vous branchez vous-même (serveurs MCP, scripts maison), qui étendent le répertoire sans changer la mécanique.

Deux conséquences pratiques :

• Un agent ne « connaît » pas votre repo, il l’explore. Chaque information qu’il a sur votre code a été acquise par un appel d’outil, visible dans la session. Quand il se trompe sur l’état du projet, la question de débogage reste celle du contexte : qu’a-t-il réellement lu ?
• La description d’un outil est un prompt. Le modèle décide d’utiliser un outil sur la foi de sa description. Un outil mal décrit est un outil ignoré ou mal employé. Retenez cette règle pour le jour où vous étendrez l’agent.

Les permissions : le rayon d’action

Tout ce que le modèle demande, le harnais peut le refuser. C’est le rôle du système de permissions : approbation action par action, listes blanches de commandes, modes plus ou moins autonomes, sandbox. Ce n’est pas une formalité d’interface. C’est votre contrôle du rayon de dégâts, et le seul.

Le dimensionner est un arbitrage, pas un réglage par défaut. Tout approuver à la main rend la boucle inutilisable. Tout autoriser confie votre machine à un processus qui optimise la plausibilité, pas la prudence. Mon critère : l’autonomie accordée se calibre sur la réversibilité des actions, pas sur la confiance accumulée. Lire est gratuit, écrire se défait avec git, exécuter dépend de la commande. C’est l’irréversible (pousser, déployer, migrer, supprimer hors du repo) qui mérite le point d’arrêt.

Le tips Craftomancer

L’autonomie d’un agent ne se mérite pas, elle se borne. Un agent qui a eu raison cent fois produira la cent-unième commande avec le même aplomb statistique, justifié ou non. N’élargissez jamais les permissions parce que « ça se passe bien » : élargissez-les parce que le filet mécanique en dessous (git, sandbox, environnement jetable) rend l’erreur réparable.

Pourquoi le terminal

Les agents ont convergé vers le terminal, et ce n’est pas une mode rétro. Le terminal est l’interface universelle des outils de développement : tout y entre et tout en sort en texte, le médium natif du modèle. Un seul outil shell donne accès à git, aux tests, aux linters, aux générateurs, à tout ce que votre projet expose en ligne de commande, sans intégration spécifique.

La conséquence renverse la perspective : la surface CLI de votre projet définit ce que l’agent sait faire. Une commande de test qui échoue avec un message précis, c’est une boucle de correction qui converge. Un build qui ne se lance que depuis l’IDE, c’est une capacité que l’agent n’a pas. Rendre un projet « agent-ready », c’est d’abord le rendre pilotable et vérifiable depuis un shell. Exactement ce qu’exigeait déjà une bonne CI.

En pratique

• Distinguez modèle et harnais : la plupart des comportements à déboguer (contexte, permissions, mémoire de session) appartiennent au harnais.
• La boucle ne converge que vers ce que vos outils vérifient : investissez dans des commandes de test et de build rapides, aux échecs explicites.
• Chaque appel d’outil remplit la fenêtre. Les longues sessions diluent l’attention (conclusion connue des Fondamentaux) : redémarrez plutôt que d’insister.
• Calibrez les permissions sur la réversibilité des actions, et n’élargissez l’autonomie qu’adossée à un filet mécanique (git, sandbox).
• Auditez la surface CLI de votre projet : ce qui ne se pilote pas depuis un shell est invisible pour l’agent.

La machine est démontée ; reste à la nourrir. Prochaine étape : le dossier de contexte du projet, ce que l’agent doit lire avant la première ligne.