L'autonomie se mérite. Voici l'ordre dans lequel on la gagne.

Les blocages que nous avons rencontrés, dans nos propres projets et dans le corpus de recherche que nous tenons à jour, ne venaient pas de la qualité du modèle. Ils venaient de quelque chose construit dans le mauvais ordre, et presque toujours de la même chose : l'autonomie est arrivée avant la machinerie qui la rend viable. Une démo qui marche une fois, c'est un modèle qui fait un tour de passe-passe. Un système qu'on peut laisser tourner, c'est un modèle dans un harnais, dans une boucle, derrière une barrière, sous un budget, sur un environnement d'exécution que quelqu'un d'autre maintient. Ajoutez la primitive en dessous et le contexte que le modèle voit, et ça fait sept décisions, dans l'ordre. Cette note donne cet ordre, ce que chaque étape achète, et la question qui vous dit si vous l'avez franchie ou simplement sautée.

L'ordre de construction des agents en production.

Lisez l'échelle ci-dessous comme un système de permissions plutôt que comme une liste de vérification. Chaque barreau est une chose que vous construisez, et le franchir vous donne le droit de construire le suivant. On peut sauter un barreau, et on le fait souvent. Ça ne fait que déplacer la facture vers la production, où elle se paie en incidents plutôt qu'en semaines.

Dans l'ordre, les sept décisions sont : choisir la primitive la plus simple, bâtir le harnais, faire l'ingénierie du contexte, passer par la barrière d'évaluation, faire tourner la bonne boucle, concevoir le coût et l'arrêt, puis acheter la couche d'orchestration. L'autonomie repose sur les sept.

Avez-vous vraiment besoin d'un agent ?

La première décision est celle qu'on saute le plus souvent, parce que « nous construisons un agent » est ce qui a fait financer le projet. Deux barreaux se trouvent sous ce mot. Le function calling (l'appel de fonction), c'est un modèle qui produit un appel structuré selon un schéma que vous avez défini, et c'est votre code qui décide de la suite. Le tool calling (l'appel d'outils) ajoute une boucle où le modèle choisit parmi des outils et relit les résultats. Un agent, c'est cette boucle, plus un modèle qui décide lui-même de son flux de contrôle : quoi faire ensuite, et quand c'est terminé.

Chaque cran franchi donne de la généralité, et on la paie de trois façons. Par la latence, parce qu'une boucle de contrôle fait plus d'appels au modèle qu'un seul appel structuré. Par la prévisibilité, parce qu'un flux de contrôle que le modèle détient est un flux qu'on ne peut pas énumérer d'avance. Par l'argent, pour la même raison. Nous avons posé le vocabulaire dans la note glossaire, et la règle d'exploitation n'a pas bougé depuis : on monte d'un cran devant une contrainte structurelle, jamais devant une aspiration.

Ce que chaque barreau achète réellement.

Barreau deux, le harnais. Le cadrage de LangChain est la version courte la plus nette que nous ayons vue : un agent, c'est un modèle plus un harnais (le harness), et le harnais, c'est tout ce qui n'est pas le modèle.[1] Les prompts système, les définitions d'outils et leurs descriptions, le système de fichiers et le bac à sable où il s'exécute, la logique d'orchestration, les hooks et intergiciels, la mémoire et la recherche, la planification et l'autovérification. C'est l'article d'un éditeur : prenez la taxonomie et laissez de côté toute affirmation sur les résultats. La taxonomie est la partie utile, parce qu'elle transforme « l'agent s'est mal comporté » en une question qui a un endroit : quel composant du harnais devait empêcher ça, et a-t-il été construit ?

Si ça vient avant l'autonomie, c'est pour une raison banale. L'autonomie, c'est le droit d'agir sans qu'une personne relise d'abord le résultat. On ne peut pas accorder ce droit de façon responsable à un système dont les actions ne sont pas journalisées, dont les outils ne sont pas bornés et dont l'état n'est pas inspectable. Construisez les garde-fous, la mémoire, les outils et les journaux, puis déléguez une étape de plus et voyez ce qui arrive. L'autre voie, c'est d'accorder l'autonomie et de découvrir les exigences du harnais dans le rapport d'incident.

Barreau trois, le contexte. Le travail le plus difficile du harnais, c'est de décider ce que le modèle a le droit de voir. Anthropic le formule ainsi : trouver le plus petit ensemble de jetons à fort signal qui produit le résultat voulu, en notant que le rappel se dégrade à mesure que la fenêtre se remplit, un problème que des fenêtres plus grandes ne règlent pas.[2] Comme la source est de première partie, c'est le fournisseur qui décrit le comportement de son propre système, soit le palier où une affirmation de fournisseur vaut le plus. En pratique, ça se résume à trois habitudes : aller chercher les données à l'exécution plutôt que de tout précharger, garder des jeux d'outils minimaux qui ne se chevauchent pas, et décider délibérément comment on compacte une longue exécution. Leur test pour la conception des outils est celui que nous empruntons le plus souvent : si une personne ne sait pas lequel de deux outils utiliser, le modèle ne le saura pas non plus.

La mémoire, c'est le même problème sur un horizon plus long, et elle a maintenant sa propre discipline : ce qui s'écrit, ce qui se gère, ce qui se relit. Nous l'avons traitée dans la note sur la mémoire, et la version courte, c'est qu'une fenêtre bornée fait des notes une mémoire de travail plutôt qu'un matériel de référence.

Barreau quatre, la barrière. Les évaluations sont ce qui rend modifiable chaque barreau au-dessus de celui-ci. Sans elles, changer de modèle, retoucher un prompt ou ajouter un outil, c'est un pile ou face qu'on ne peut pas noter, alors les équipes arrêtent de toucher à un système qui fonctionne et il se dégrade sur place. La forme qui résiste à un vrai calendrier est à deux paliers : un détecteur structurel rapide qui roule en intégration continue à chaque changement, puis des suites sémantiques complètes qui roulent moins souvent. La nôtre est volontairement petite, six lignes, décrite dans la note sur la suite d'éval, et c'est justement l'idée. Une suite d'évaluation que personne ne fait rouler, c'est de la documentation.

Deux éléments appartiennent à la suite, et les équipes les laissent couramment de côté. Noter le taux d'action, c'est-à-dire la fréquence à laquelle l'agent a réellement fait quelque chose, et noter l'arrêt, c'est-à-dire s'il s'est arrêté. Le succès de la tâche, à lui seul, masque les deux modes d'échec de la section suivante.

Barreau cinq, la boucle. Selon Ng, la construction assistée par l'IA fonctionne comme des boucles de rétroaction imbriquées à différentes échelles de temps : l'agent qui itère sur son propre travail en quelques minutes, le développeur qui oriente et reformule la spécification sur des dizaines de minutes à quelques heures, et la rétroaction externe des vrais utilisateurs sur des heures, des jours ou des semaines.[3] C'est l'opinion mûrie d'un praticien, pas une étude, et les intervalles relèvent de son expérience. Nous la gardons quand même parce qu'elle sert de diagnostic. L'essentiel de l'effort gaspillé dans un projet d'agent est de l'effort dépensé dans la mauvaise boucle : vérifier à la main un résultat que l'agent pourrait contrôler lui-même, ou peaufiner une boucle interne alors que la cible vers laquelle elle converge est la mauvaise. Sa façon de recadrer le « flair » humain en avantage de contexte est la moitié la plus utile. L'humain reste dans la boucle exactement aussi longtemps qu'il sait quelque chose que le système ne sait pas, ce qui indique aussi à quel moment une étape devient automatisable.

Les deux façons d'échouer une fois en production.

Le barreau six est celui où se retrouvent la plupart de nos notes de terrain sur les modes d'échec, et ce n'est pas un hasard. Le coût et l'arrêt ne sont pas des préoccupations d'exploitation à ajouter après le lancement. Ce sont des primitives de conception, parce que les deux pôles d'échec en production viennent de la même absence : une limite claire de ce qui suffit.

Le pôle inactif porte maintenant un nom, idle-drift (dérive d'inactivité), issu d'un banc d'essai de longue durée (une préimpression, citée et classée par palier dans cette note) où un modèle est resté inactif pendant des semaines de temps simulé alors que ses rapports d'état demeuraient cohérents. Nous l'avons traité dans la note sur l'agent qui cale sans que ça paraisse. Nous avons documenté la version emballée dans un postmortem et la réponse de conception dans un planificateur avec budget de confiance. L'instrumentation qui rend l'un ou l'autre maîtrisable, c'est la dépense par étape, triée par dépense plutôt que par volume d'appels, ce qui est l'objet de traiter le coût comme une métrique prioritaire. L'ordre compte ici aussi : instrumenter d'abord, puis filtrer, tronquer, rétrograder le palier de modèle ou mettre en cache, et faire passer chacun de ces changements par la barrière d'évaluation du barreau quatre. Travailler le coût sans évaluations, c'est comme ça qu'un système devient moins cher et discrètement moins bon.

Construire ou acheter la couche d'orchestration.

Barreau sept, l'environnement d'exécution. Si un produit prêt à l'emploi fait déjà toute la tâche, achetez-le : cette échelle vaut pour le travail qu'aucun produit ne couvre. Une fois que vous construisez, la question de construire ou d'acheter porte rarement sur l'agent. Elle porte sur l'environnement d'exécution qui est en dessous. Optez par défaut pour un cadriciel d'orchestration maintenu, et ne construisez le vôtre que devant un mur infranchissable. Le coût du sur-mesure, ce n'est pas de l'écrire. L'écrire, c'est deux belles semaines. Le coût, c'est la surface de maintenance et le facteur d'autobus : un environnement d'exécution que seule votre équipe comprend, qu'elle devra maintenant porter pour toujours, face à un cadriciel dont les mises à niveau sont payées par quelqu'un d'autre. La note sur les orchestrateurs custom plaide ce point à fond.

Auditer un projet hérité.

Parcourez l'échelle comme un audit. La plupart des projets qui semblent coincés reposent sur un barreau jamais construit, et le symptôme pointe rarement vers lui. Pas besoin d'être l'ingénieur pour faire cette passe : cinq questions, et les réponses disent à un propriétaire ou à un responsable des opérations quel barreau est ouvert.

1. Demandez ce qui arrive si l'agent se trompe à trois heures du matin.

   Si la réponse implique qu'une personne s'en aperçoive, l'autonomie dépasse le harnais. C'est le barreau deux, et aucun barreau au-dessus ne peut compenser. La surface de journalisation, les bornes des outils et l'état inspectable passent avant la prochaine délégation, pas après le prochain incident.

   à faire · repérer le composant de harnais manquant avant d'ajouter de la capacité
2. Demandez quand le prompt a changé la dernière fois, et comment on a su que ça aidait.

   Une équipe qui a cessé de toucher à un agent qui fonctionne est une équipe sans barrière d'évaluation. Barreau quatre. Construisez d'abord le détecteur structurel rapide : il roule à chaque changement, et c'est lui qui rend le système modifiable à nouveau.

   à faire · mettre en place une suite d'évaluation à vitesse d'intégration continue avant la prochaine retouche de prompt
3. Demandez le coût de l'exécution la plus chère du mois dernier.

   Pas la moyenne, pas le total. Si personne ne peut le sortir en une minute, la dépense par étape n'est pas instrumentée, et le barreau six est ouvert. Triez par dépense, pas par volume d'appels : le chemin coûteux est rarement le plus achalandé.

   à faire · instrumenter le coût par étape avant de négocier quelque contrat de modèle que ce soit
4. Demandez ce que fait l'agent quand il ne peut pas réussir.

   « Il continue d'essayer » et « il s'arrête et prévient quelqu'un » sont deux produits différents. Si l'arrêt n'a jamais été conçu, vous portez les deux pôles d'échec sans en avoir mesuré aucun. Ajoutez les deux à la suite d'évaluation la même semaine.

   à faire · écrire la condition d'arrêt, puis la noter
5. Demandez si un appel de fonction aurait suffi.

   Ça vaut la peine de le demander même pour un système déjà en production. Certains agents déployés sont une boucle de contrôle enroulée autour d'une tâche qui ne se ramifie jamais, et redescendre d'un barreau réduit la latence et fait gagner en prévisibilité et en marge d'un seul coup.

   à faire · refaire le test du barreau un à la lumière du comportement dont vous avez maintenant les données

Ce que ceci n'autorise pas.

Ceci est de la doctrine, ce qui est plus faible qu'une preuve et doit se lire comme tel. C'est notre ordre, tiré de nos propres projets et d'un corpus que nous tenons à jour, et nous n'avons pas mené l'expérience qui le mettrait à l'épreuve : deux équipes, le même mandat, l'une qui construit dans cet ordre et l'autre pas. À notre connaissance, personne ne l'a fait. Ce que nous pouvons dire est plus étroit. Chaque mode d'échec coûteux que nos notes de terrain passent en revue correspond à un barreau manquant, et les barreaux sont ordonnés selon le saut qui tend à se manifester en premier. Ces notes sont des exemples travaillés à titre d'illustration : il s'agit donc d'une vérification de cohérence de la doctrine, pas d'un test de celle-ci.

Les sources portent leurs propres limites, et elles ne sont pas interchangeables. La taxonomie du harnais, c'est un éditeur qui décrit un paysage dans lequel il vend : c'est du vocabulaire plutôt qu'une preuve. Les recommandations sur le contexte sont de première partie, ce qui les rend solides pour les modèles de ce fournisseur et une hypothèse pour ceux de tous les autres. Le cadre des boucles, c'est l'expérience d'un seul praticien avec ses propres projets, et les plages de temps en particulier sont illustratives. Nous utilisons les trois parce qu'elles convergent de directions différentes, pas parce qu'une seule d'entre elles établit l'ordre.

Deux bornes sur la doctrine elle-même. C'est un récit de construction et d'exécution, donc il sous-pondère le plan de contrôle d'exécution qui entoure un déploiement : le standard d'interface des outils, la passerelle multifournisseur, les garde-fous en couches et l'observabilité. Ces éléments sont porteurs dans notre propre pile technologique et ne sont pas des barreaux de cette échelle, ce qui est un trou dans l'échelle plutôt qu'un jugement sur leur importance. Et le tout est écrit pour des agents qui travaillent dans des systèmes que vous contrôlez. Un agent qui agit en public au nom d'un client ajoute des obligations que cette note ne couvre pas du tout.

Si vous êtes à mi-hauteur sur cette échelle et que vous voulez un regard extérieur sur le barreau qui est ouvert, le formulaire de contact est la voie la plus rapide. Dites-nous ce que fait l'agent et ce qu'il coûte, et nous vous enverrons une évaluation écrite de l'endroit où l'ordre s'est brisé, gratuitement.