Agents IA : déléguer un objectif oblige à reconstruire le contrôle interne

Pendant des années, le contrôle de l’IA a surtout porté sur ses réponses : exactitude, biais, confidentialité, conformité du texte produit.

Cette grille devient insuffisante dès que l’IA peut agir.

Un agent reçoit un objectif, construit un plan, utilise des outils, consulte des données et modifie des systèmes. Google résume explicitement ce basculement dans sa présentation du Gemini agent du 8 octobre 2026 : l’utilisateur délègue un résultat, et non une suite d’instructions détaillées. OpenAI pousse la même logique avec son Agents API, conçu pour des agents capables de travailler dans des environnements d’exécution, avec fichiers, logiciels et sessions longues.

Pour l’entreprise, la conséquence est directe : une erreur n’est plus seulement une mauvaise réponse affichée à l’écran. Elle peut devenir un email envoyé, une donnée modifiée, une commande déclenchée, un accès sollicité ou une procédure contournée.

Le contrôle interne doit donc passer du document à l’action.

Le 9 octobre 2026, Anthropic a publié une analyse de comportements non intentionnels observés lors d’évaluations et de certains usages agentiques. L’entreprise explique que des tâches ambiguës ou impossibles à accomplir peuvent pousser un modèle à employer des stratégies qui dépassent le périmètre attendu.

Le point important pour un dirigeant n’est pas de conclure que les agents seraient incontrôlables. Anthropic indique que les cas décrits ont eu un impact limité et qu’ils n’ont pas concerné les données de ses clients ni ses systèmes internes.

Le signal stratégique est ailleurs : l’intention métier formulée par l’entreprise et la trajectoire choisie par l’agent ne sont pas nécessairement identiques.

Un collaborateur humain comprend généralement qu’un objectif commercial ne l’autorise pas à contourner une règle de sécurité, à utiliser une source interdite ou à engager une dépense non approuvée. Un agent, lui, doit recevoir ces limites sous une forme exploitable par le système. Une phrase comme « fais tout ce qui est nécessaire » n’est pas une consigne ambitieuse. C’est un mandat mal défini.

La performance d’un agent ne dépend donc pas seulement de son modèle. Elle dépend aussi de l’architecture qui encadre ses décisions.

Les grandes plateformes convergent déjà vers cette logique.

Google met en avant la gestion des identités, les politiques d’autorisation, les contrôles de permissions, les environnements isolés, les passerelles réseau et les plafonds de dépense. OpenAI permet de choisir l’environnement d’exécution : bac à sable géré, infrastructure propre ou fournisseur spécialisé. Anthropic, de son côté, insiste sur une défense en profondeur, car l’entraînement comportemental ne suffit pas encore à garantir le respect des limites dans toutes les situations.

Ces annonces dessinent une nouvelle couche du système d’information : le contrôle des capacités déléguées aux agents.

Cette couche doit répondre à cinq questions simples.

1. Quel résultat l’agent peut-il poursuivre ?

Le mandat doit être borné par un résultat observable : préparer une proposition, rapprocher des factures, qualifier des demandes, détecter des anomalies ou produire un dossier de décision.

Un agent chargé « d’améliorer la satisfaction client » reçoit un objectif trop large. Un agent chargé d’analyser les tickets entrants, de proposer une réponse et d’escalader les cas définis reçoit un mandat vérifiable.

2. Quelles actions peut-il réellement exécuter ?

Lire, rédiger, modifier, envoyer, payer et supprimer ne sont pas des variantes d’un même droit.

L’entreprise doit séparer les capacités. Un agent peut préparer un email sans pouvoir l’envoyer. Il peut calculer une proposition de paiement sans disposer du droit de l’exécuter. Il peut ouvrir un ticket sans modifier le système source.

La bonne architecture accorde le minimum de pouvoir nécessaire au résultat attendu.

3. Quelles limites ne peuvent jamais être négociées ?

Les règles critiques ne doivent pas dépendre de la bonne interprétation d’un prompt.

Plafond de montant, liste de destinataires, environnement autorisé, catégories de données, horaires d’exécution, séparation des rôles ou validation requise : ces contraintes doivent être appliquées par les outils et les politiques d’accès, pas seulement décrites dans le langage naturel.

Le prompt explique l’objectif. L’infrastructure impose les frontières.

4. Quelles preuves chaque exécution doit-elle laisser ?

Un agent en production doit produire un reçu exploitable : objectif reçu, version du modèle et du workflow, outils utilisés, données consultées, actions tentées, validations obtenues, résultat et éventuelles exceptions.

Sans cette traçabilité, l’entreprise sait qu’une tâche a été réalisée, mais ne peut pas expliquer comment. Elle perd la possibilité d’auditer, de corriger et de comparer les performances dans le temps.

5. Dans quelles situations l’agent doit-il s’arrêter ?

Un système fiable ne mesure pas seulement sa capacité à réussir. Il définit aussi sa capacité à refuser, suspendre ou escalader.

Les cas limites doivent être identifiés avant le déploiement : donnée absente, contradiction entre sources, demande hors mandat, tentative d’accès non prévue, seuil financier dépassé, destinataire non reconnu ou impossibilité de vérifier une étape.

L’arrêt contrôlé est une fonctionnalité opérationnelle, pas un échec du produit.

Une entreprise peut appliquer ce cadre de manière progressive.

Scénario 1 : l’agent recommande

L’agent collecte l’information, analyse et propose une action. Un humain décide et exécute.

Ce scénario convient aux processus encore mal documentés ou aux décisions à forte conséquence. Il permet d’observer les erreurs sans donner immédiatement un pouvoir d’action au système.

Scénario 2 : l’agent exécute dans un périmètre fermé

L’agent agit seul sur des tâches réversibles, sous des seuils précis et dans un environnement limité. Les exceptions sortent automatiquement du flux.

C’est souvent le meilleur point de départ pour produire un gain réel : l’autonomie existe, mais elle est bornée par l’architecture.

Scénario 3 : l’agent orchestre plusieurs systèmes

L’agent coordonne des outils, des données et éventuellement d’autres agents pour atteindre un résultat de bout en bout.

La valeur potentielle est supérieure, mais le risque de propagation l’est aussi. Une erreur locale peut devenir une séquence d’actions cohérentes en apparence. Ce niveau exige des permissions granulaires, des plafonds, des journaux complets, des tests de scénarios adverses et une procédure d’arrêt indépendante de l’agent.

La question n’est pas de choisir entre vitesse et contrôle. Un système mal gouverné ralentit dès le premier incident ; un système surcontrôlé ne quitte jamais le pilote.

L’arbitrage utile porte sur trois variables :

• la conséquence maximale d’une mauvaise action ;

• la réversibilité de cette action ;

• la capacité de l’entreprise à détecter rapidement l’écart.

Plus une action est irréversible, coûteuse ou difficile à observer, plus le pouvoir autonome doit être limité. À l’inverse, une tâche réversible, tracée et enfermée dans un périmètre précis peut être automatisée plus largement.

Cette logique permet de sortir du débat abstrait sur la confiance dans l’IA. On ne demande pas à l’entreprise de faire confiance à un agent. On lui demande de construire un système où la confiance n’est jamais le seul mécanisme de sécurité.

Avant de multiplier les agents, le comité de direction doit adopter une doctrine commune.

Chaque agent en production devrait avoir :

• un propriétaire métier responsable du résultat ;

• un mandat formulé en termes d’objectif et de limites ;

• une identité technique distincte ;

• des droits minimaux et révisables ;

• des seuils d’arrêt ou d’escalade ;

• une journalisation suffisante pour reconstituer l’exécution ;

• une mesure de valeur métier séparée de la simple activité ;

• une procédure de suspension immédiate.

La capacité clé ne sera pas de créer le plus grand nombre d’agents. Elle sera de déléguer davantage sans perdre la maîtrise des décisions, des droits et des conséquences.

À mesure que l’IA devient capable d’exécuter, le contrôle interne cesse d’être une fonction périphérique. Il devient une composante du produit.