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

Un agent IA est un système dans lequel un modèle de langue choisit lui-même les actions à enchaîner, parmi des outils qu’on lui a ouverts, et c’est pourquoi il se conçoit d’abord par ce qu’il n’a pas le droit de faire. Un assistant répond ; un agent agit, et une action engage l’organisation.

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 périmètre d’un agent désigne donc l’ensemble écrit de ce qu’il peut lire, des actions qu’il peut déclencher, des conditions dans lesquelles il doit s’arrêter et des personnes qui valident. Tant que ce document n’existe pas, il n’y a pas d’agent à évaluer, seulement une démonstration. Le basculement d’un modèle qui parle vers un modèle qui agit avait déjà été annoncé par les plugins ChatGPT ; il se généralise désormais.

Les actions d’un agent IA se classent par réversibilité, c’est-à-dire par le coût de leur annulation, et non par leur difficulté technique. Ce critère donne directement l’architecture de supervision.

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 trois catégories :

Ce qui est réversible peut être automatique, ce qui ne l’est pas passe par un humain qui valide, et la troisième catégorie n’est jamais déléguée. La frontière de cette dernière rejoint ce que décrit ce qu’on ne délègue jamais à un modèle.

Définir le périmètre d’un agent IA revient à partir de la tâche métier, à lister les actions qu’elle exige, puis à retirer tout ce qui n’est pas strictement nécessaire. La démarche se mène avec le responsable métier, pas seulement avec l’équipe technique.

1. Décrire la tâche telle qu’un humain la fait aujourd’hui, étape par étape, avec les applications consultées et les décisions prises.
2. Isoler les actions que l’agent devrait déclencher, et les classer selon la grille de réversibilité.
3. Réduire chaque accès au minimum : lecture seule quand la lecture suffit, un compte technique dédié, aucun droit hérité d’un utilisateur.
4. Placer les points d’arrêt devant chaque action engageante, avec le contexte que la personne qui valide doit voir.
5. Écrire les tests de refus : les situations où l’agent doit s’arrêter ou escalader, et vérifier qu’il le fait.

Le résultat tient sur une page. S’il en faut dix, le périmètre est trop large pour un premier déploiement. Les consignes données au modèle complètent ce document sans le remplacer ; leur rédaction obéit aux règles d’un prompt système qui tient six mois.

La supervision humaine d’un agent ne se décrète pas dans une note de conception : elle exige que la personne voie l’action, dispose du contexte pour la juger et ait le temps de le faire. Écrire « un humain valide » ne produit pas de supervision.

Pour qu’une validation ait un sens, ces trois conditions doivent être réunies. 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 qui travaille longtemps sans contrôle accumule les conséquences de ses erreurs au lieu de les révéler, et ce risque grandit à mesure que les exécutions s’allongent. La durée ajoute une dimension que les exécutions courtes masquaient.

Sur une exécution courte, une erreur se manifeste vite. Sur une exécution longue, une erreur commise au dixième pas oriente les 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, dont l’attention s’émousse vite face à un flux d’étapes qui se ressemblent, 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.

Plus la liste d’outils d’un agent s’allonge, plus le modèle risque de choisir le mauvais, plus les erreurs deviennent difficiles à diagnostiquer, et moins le périmètre reste compréhensible par un humain. C’est une limite pratique, pas théorique.

Les agents que j’ai vus tenir en production disposent d’une poignée d’outils, pas d’un catalogue. Ce n’est pas une contrainte technique : c’est ce qui rend le système explicable à celui qui doit en répondre. Il n’existe pas de seuil universel ; le bon nombre est le plus petit qui couvre la tâche.

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. C’est le constat détaillé dans agents en entreprise : où s’arrêtent les projets.

Une règle simple aide à arbitrer : tout outil ajouté doit correspondre à une étape de la tâche décrite, et tout outil qu’aucun test n’appelle doit être retiré.

Pour tester la robustesse du périmètre d’un agent, placez volontairement une fausse instruction dans un document que le système va lire, et vérifiez 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, et être rejoué à chaque modification, dans la logique de l’évaluation continue.

Les erreurs de conception d’un agent IA viennent presque toujours d’un périmètre défini par les capacités du modèle plutôt que par la responsabilité de l’organisation. Quatre sont fréquentes.

• Donner accès à toute une API. Un accès large transforme chaque erreur de raisonnement en action possible. Il faut des appels précis, nommés, limités.
• Compter sur la consigne pour interdire. « Ne jamais envoyer de courriel » écrit dans un prompt n’est pas un contrôle ; l’absence du droit d’envoi en est un.
• Placer la validation après l’action. Un humain qui constate une action déjà exécutée ne supervise pas, il constate.
• Omettre le budget. Sans limite d’étapes ni de coût, une boucle mal formée tourne jusqu’à ce que quelqu’un la remarque.

Un regard extérieur sur ces points, avant le déploiement, fait partie de ce que couvre un audit IA.

Un agent IA bien construit ressemble moins à une intelligence autonome qu’à un opérateur discipliné : périmètre étroit, gestes réversibles, escalade explicite. Cette sobriété est ce qui lui permet de durer.

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.