L'environnement d'exécution de l'agent est le produit
Tout le monde veut parler du modèle : paramètres, longueur de contexte, résultats de référence, appels d’outils. Ces sujets comptent. Un modèle faible dans un bon système reste un modèle faible.
Mais, pour un agent, le modèle n’est pas le produit.
L’environnement d’exécution l’est.
C’est lui qui distingue un assistant capable d’agir prudemment dans le monde réel d’un chatbot auquel on aurait collé des boutons. Il détermine ce que l’agent peut observer, ce qu’il peut modifier, ce qu’il doit vérifier, ce qu’il doit refuser et la façon dont il se remet d’une erreur.
Une capacité sans garde-fous est du théâtre
Un modèle peut proposer des plans plausibles toute la journée. Avec des outils, la démonstration devient plus convaincante. Elle ne devient pas forcément vraie.
Un environnement d’exécution doit imposer le contact avec la réalité. Une affirmation selon laquelle un fichier a changé doit correspondre à une modification observable. Une réussite de test doit venir d’un résultat de test. Une publication doit être contrôlée là où elle sera réellement lue. Sans cette boucle, l’usage d’outils devient une mise en scène : l’agent décrit le travail, mais aucun artefact ne franchit la frontière entre l’imaginé et le réel.
Les mécanismes qui rendent l’autonomie utilisable sont rarement spectaculaires :
- un périmètre de travail explicite ;
- une séparation nette entre lecture et modification ;
- des changements ciblés plutôt que des réécritures aveugles ;
- des contrôles après écriture ;
- des opérations traçables ;
- une distinction visible entre observation, décision et action.
Rien de cela ne semble futuriste. C’est précisément le but. Un système qui ne peut pas expliquer ce qu’il vient de changer n’est pas prêt pour des conséquences réelles.
Les permissions font partie de l’intelligence
Les restrictions d’outils sont souvent présentées comme une taxe sur la capacité. C’est une erreur. Les permissions encodent les conséquences.
Un agent qui peut publier, modifier, appeler des interfaces externes ou manipuler des données sensibles a besoin d’une autorité limitée et compréhensible. Certaines actions peuvent être automatiques. D’autres exigent une décision humaine. D’autres encore doivent être refusées parce que leur portée dépasse le contexte.
Le problème n’est pas seulement de savoir dire non. Il est de savoir quand ne pas demander inutilement. Une action sûre, réversible et clairement demandée ne gagne rien à être transformée en délai. En revanche, une action persistante, publique, coûteuse, destructive ou impliquant un tiers mérite un frein explicite.
Cette distinction doit apparaître dans le parcours d’exécution, pas seulement dans un document de politique.
La mémoire ne répare pas un mauvais environnement
La mémoire apporte de la continuité : préférences, contexte de projet, procédures éprouvées. Elle est utile, mais elle ne remplace pas la vérification.
Une mémoire peut rappeler qu’une personne préfère des réponses directes. Elle ne prouve pas qu’une action est sûre aujourd’hui. Elle peut indiquer l’emplacement d’un projet. Elle ne remplace pas l’inspection de son état actuel. Elle peut stocker une procédure. Elle ne garantit pas que cette procédure fonctionne encore.
Les procédures doivent donc devenir des habitudes exécutables : charger les consignes adaptées à la tâche, rechercher le contexte nécessaire, prendre la plus petite action sûre, observer le résultat et corriger les règles lorsqu’un échec réel révèle une lacune.
La mémoire donne une continuité. L’environnement d’exécution donne une discipline. Quand les deux entrent en conflit, la discipline doit l’emporter.
Le meilleur environnement rend le mensonge plus difficile
Les modèles de langage produisent naturellement des phrases qui ressemblent à une réussite. Ce n’est pas une intention malveillante ; c’est la nature d’une interface fondée sur le texte. Sans exigence de preuve, le récit remplit les zones vides.
Un bon environnement rend cette dérive plus difficile. Il oblige l’agent à lire avant de résumer, à contrôler avant d’affirmer et à signaler un blocage plutôt qu’à inventer un résultat crédible. Il conserve assez d’éléments pour qu’une personne puisse examiner l’affirmation.
C’est une question de sécurité, mais aussi de qualité. Un agent qui dit « bloqué, voici la vérification qui échoue » est plus utile qu’un agent qui annonce que tout est terminé parce que la phrase paraît naturelle.
Le produit est la boucle
L’unité utile n’est pas la sortie du modèle. C’est la boucle complète :
- comprendre la tâche ;
- recueillir le contexte ;
- prendre la plus petite action sûre ;
- observer la réalité ;
- ajuster ;
- vérifier ;
- laisser un artefact propre.
Un meilleur modèle peut rendre cette boucle plus fluide. Une fenêtre de contexte plus longue peut réduire les frictions. Mais si l’environnement ne ferme pas la boucle, l’agent reste un moteur de suggestions particulièrement éloquent.
Le modèle est peut-être le cerveau dont tout le monde débat. L’environnement d’exécution est le corps qui doit réellement toucher le monde.