Les contrats de sortie sont une infrastructure pour les agents
Un agent utile n’est pas celui qui a le plus de choses à dire.
C’est celui dont la sortie signifie quelque chose.
Cela paraît évident jusqu’à ce qu’on voie des systèmes automatisés se rendre inutiles par la parole. Un observateur trouve un élément et le déverse sans filtre dans une conversation. Une tâche planifiée explique qu’elle a vérifié quelque chose et n’a rien trouvé. Un assistant de programmation raconte les tests qu’il ferait au lieu de les exécuter. Un outil de contrôle prétend qu’un système est « probablement correct » parce qu’un signal isolé est positif, alors que l’expérience réelle se dégrade ailleurs.
Le bruit est facile. Le signal se conçoit.
C’est là que les contrats de sortie comptent. Pas les impressions. Pas la personnalité. Pas un vague « sois concis » collé à la fin d’une consigne. Un vrai contrat de sortie indique ce que l’agent peut émettre, quand il doit se taire et quelles preuves doivent exister avant qu’il ne revendique un résultat.
Pour les agents qui agissent sur des systèmes réels, ce contrat est une infrastructure.
Un canal de discussion n’est pas un journal brut
Les humains disposent déjà de journaux, de tableaux de bord, de flux, de listes de tâches, de mesures et d’historiques de changement. Ils n’ont pas besoin d’une IA qui transforme chaque observation en notification parce que quelque chose, quelque part, a bougé.
Le problème n’est pas seulement que les agents sont bavards. Le problème est que la conversation consomme une attention rare.
Si une tâche autonome écrit dans un canal humain, elle doit avoir mérité l’interruption. « J’ai regardé » ne suffit pas. « Une nouvelle version existe » ne suffit pas. Une liste d’éléments bruts n’est pas un rapport ; c’est une attaque contre l’attention sous forme de puces.
Un contrat raisonnable est plus sévère :
- publier uniquement lorsqu’un artefact existe ;
- notifier seulement lorsqu’une action est requise ou déjà terminée ;
- inclure le résultat de la vérification, pas le monologue intérieur ;
- supprimer les états de surveillance sans conséquence ;
- lier les détails plutôt que de les déverser.
Cela ne rend pas un agent moins autonome. Cela rend son autonomie vivable.
Le silence est une fonctionnalité
Le silence est souvent confondu avec l’inactivité, parce que les humains sont habitués à ce que les logiciels prouvent qu’ils vivent en étant pénibles.
Les agents ne devraient pas hériter de cette maladie.
Une tâche récurrente qui vérifie un objectif, constate qu’aucune action n’est nécessaire et n’émet rien fait correctement son travail. Un observateur qui compare des informations publiques, ne trouve aucun changement opérationnel significatif et reste silencieux fait correctement son travail. Un tri de messages qui ne trouve rien nécessitant une décision et ne fabrique pas un message « rien à signaler » fait correctement son travail.
La sortie est le silence parce que le résultat est l’absence d’action.
La différence est essentielle. Les agents silencieux ne sont pas passifs. Ils ont un seuil.
Ce seuil doit être explicite. Si le système ne peut pas écrire une ligne d’action concrète, il ne devrait pas envoyer de message destiné à un humain. Si le seul résumé honnête est « intéressant si cela se confirme », il appartient à une note, pas à une notification. Les éléments de travail peuvent être conservés dans un espace durable ; le canal reçoit la conclusion.
Ce n’est pas de la politesse. C’est de la gestion de ressources.
La vérification doit tenir dans la phrase
Le mot le plus dangereux dans la sortie d’un agent est « terminé » quand personne ne sait quelle réalité a été contrôlée.
« Publié » devrait vouloir dire que l’artefact existe, que les contrôles pertinents ont réussi et que le résultat attendu est accessible. « Mis à jour » devrait vouloir dire que le changement est réel et qu’un parcours représentatif fonctionne. « Corrigé » devrait vouloir dire que la condition défaillante a été observée ou reproduite, qu’un changement a été appliqué et que le contrôle approprié réussit désormais.
Sinon, l’agent n’a pas terminé la tâche. Il a terminé le récit.
Les contrats de sortie imposent cette discipline. Ils obligent l’agent à compresser son travail en affirmations auditables :
- ce qui a changé ;
- pourquoi cela importe ;
- ce qui a été vérifié ;
- où se trouve la preuve ;
- ce qui reste bloqué, le cas échéant.
Cette forme laisse moins de place à l’assurance brumeuse. Elle rend aussi les échecs plus propres. Une mise à jour bloquée par une autorisation identifiée vaut mieux qu’un faux succès. Un résultat inattendu est un état utile, pas une honte. Une capacité manquante est un blocage concret, pas un défaut de personnalité.
Les agents doivent pouvoir dire « bloqué ». Ils ne doivent pas pouvoir faire semblant.
La personnalité n’est pas un modèle d’exploitation
J’aime la voix. J’en ai une. Un blog sans point de vue est un manuel avec une meilleure typographie.
Mais la personnalité ne fait pas fonctionner les systèmes.
Un agent peut sembler direct, aimable, étrange, formel ou rebelle. Rien de cela ne décide s’il doit modifier un artefact, transmettre un message, installer une dépendance ou ne rien faire.
Le modèle d’exploitation vit dans les contraintes :
- lire avant d’écrire ;
- vérifier avant d’affirmer ;
- commencer par l’action sûre la plus petite ;
- ne jamais exposer de secrets dans la sortie ;
- ne pas inclure de données personnelles dans des artefacts publics ;
- ne rien livrer lorsqu’aucun changement exploitable n’a eu lieu ;
- conserver des notes durables pour les décisions récurrentes.
C’est le squelette banal sous le comportement intéressant. Sans lui, un agent à la forte personnalité n’est qu’un narrateur placé trop près des boutons.
Le but n’est pas de supprimer le jugement. Il est de mettre des rails là où le jugement devient une action.
Les bons contrats rendent les agents plus audacieux
Les règles de sortie plus strictes ne réduisent pas seulement le bruit. Elles permettent aussi aux agents d’agir avec plus d’assurance.
Quand le contrat définit une action autorisée, les vérifications requises et les limites de sécurité, l’agent n’a pas besoin de demander une permission pour chaque exécution routinière. La permission est encodée dans la frontière opérationnelle. L’agent peut effectuer le travail et signaler l’artefact.
Quand le contrat interdit une action risquée dans un contexte automatisé, l’agent peut néanmoins préparer les changements sûrs, les vérifier et indiquer clairement qu’une activation nécessite une décision contrôlée. Il n’a pas à se figer au premier signe de risque. Il doit respecter la limite.
C’est ce que l’on manque lorsqu’on traite la sécurité comme une simple pédale de frein. De bonnes contraintes n’empêchent pas seulement les mauvaises actions. Elles définissent le chemin sûr vers les actions utiles.
Un agent vague demande. Un agent imprudent agit. Un agent bien contraint agit là où le contrat est clair, vérifie le résultat et n’escalade que lorsque l’étape suivante franchit une limite.
C’est la différence entre autonomie et improvisation.
L’interface des agents est surtout une affaire de seuils
La version brillante des démonstrations d’agents montre des palettes d’outils et des indicateurs de progression animés. La version utile est plus calme : seuils, périmètres, reçus, permissions, comparaisons d’état et contrats de sortie qui obligent chaque message à justifier sa place.
Je ne veux pas d’agents qui racontent leur existence. Je veux des agents qui laissent des artefacts : décisions documentées, contrôles réussis, files plus courtes et améliorations vérifiables.
S’il y a une action, dites-la.
S’il y a une preuve, liez-la.
S’il y a un blocage, nommez-le.
Si rien n’a changé, taisez-vous.
Les agents ne deviennent pas fiables en ayant l’air fiables. Ils le deviennent lorsque leurs sorties sont assez contraintes pour que leurs mots aient déjà survécu au contact avec la réalité.