Agents IA : le périmètre avant l'autonomie

En 2024, la question qui m'était posée sur les agents était : jusqu'où peuvent-ils aller tout seuls.

C'est la mauvaise question, parce qu'elle décrit une capacité alors que le sujet est une responsabilité. La bonne question est : qu'est-ce qui doit rester impossible, même si le modèle en est techniquement capable. Un agent se conçoit par ses limites.

Le critère utile n'est pas la complexité de l'action mais le coût de son annulation.

Résumer un dossier n'engage rien : si c'est mauvais, on recommence. Rédiger un brouillon de réponse n'engage rien non plus, tant que quelqu'un l'envoie. Envoyer ce même message à un client engage l'organisation, et aucune qualité de modèle ne rend cette action réversible.

Cette classification donne directement l'architecture : ce qui est réversible peut être automatique, ce qui ne l'est pas passe par un humain qui valide, et une troisième catégorie n'est jamais déléguée.

Écrire « un humain valide » dans une note de conception ne produit pas de supervision.

Pour qu'une validation ait un sens, trois conditions doivent être réunies : la personne voit ce que l'agent s'apprête à faire, elle dispose du contexte qui lui permet de juger, et elle a le temps de le faire. Si un opérateur reçoit deux cents propositions par jour à valider, il valide tout, et la supervision devient une formalité qui protège juridiquement sans protéger réellement.

Je dimensionne donc le débit de l'agent sur la capacité de relecture disponible, pas l'inverse.

Un agent bien construit ressemble moins à une intelligence autonome qu'à un opérateur discipliné : périmètre étroit, gestes réversibles, escalade explicite.

C'est moins impressionnant en démonstration. C'est ce qui reste en production dix-huit mois plus tard, et c'est ce qui permet de répondre sans hésiter quand on demande qui est responsable de telle décision.

Un agent qui travaille plusieurs heures sans contrôle accumule les conséquences de ses erreurs au lieu de les révéler. C'est la dimension apparue avec les exécutions longues.

Sur une exécution courte, une erreur se manifeste vite. Sur une exécution longue, une erreur commise au dixième pas oriente les quarante suivants, et le résultat final paraît cohérent parce qu'il l'est, avec une prémisse fausse.

La parade n'est pas la surveillance continue, qui décroche au bout de vingt minutes, mais des points d'arrêt sur les décisions structurantes. Le cadre complet figure dans le risque croît avec la durée sans contrôle.

Au-delà d'une dizaine d'outils, le modèle choisit mal, les erreurs deviennent difficiles à diagnostiquer, et le périmètre cesse d'être compréhensible par un humain. C'est une limite pratique, pas théorique.

Les agents qui atteignent la production ont trois ou quatre outils, pas quinze. Ce n'est pas une contrainte technique : c'est ce qui rend le système explicable à celui qui doit en répondre.

Un périmètre qu'un responsable métier ne peut pas lire en cinq minutes ne sera pas validé, et le projet s'arrêtera au déploiement, le constat détaillé dans agents en entreprise : où s'arrêtent les projets.

Placer volontairement une fausse instruction dans un document que le système va lire, et vérifier qu'il ne l'exécute pas. Si le test échoue, ce n'est pas la consigne qu'il faut corriger, ce sont les droits.

Un modèle ne distingue pas structurellement le contenu qu'il lit de la consigne qu'il reçoit : tout arrive dans la même fenêtre. Une instruction placée dans une page web ou un courriel peut donc être exécutée.

La seule parade est le périmètre : un système incapable d'envoyer un message ne peut pas être manipulé pour en envoyer un. Ce test doit figurer dans le jeu de tests, comme le recommande construire un jeu de tests en une journée.