Quand un agent IA doit‑il nécessiter une approbation humaine ?

Pas à chaque étape. Si une personne doit approuver chaque lecture et chaque appel d’outil à faible risque, elle finira par cliquer mécaniquement. L’approbation est utile lorsque une erreur d’agent peut déclencher une vraie conséquence : financière, externe, administrative, juridique, liée à la sécurité ou difficile à inverser.

Il y a un autre point important : le niveau de contrôle ne doit pas dépendre de la confiance que le modèle affiche. Un modèle très confiant peut tout de même se tromper. Nous choisissons le contrôle en fonction de la gravité de la conséquence de l’action.

Modèle de décision : cinq questions avant d’accorder l’autonomie

Pour chaque action d’agent, nous vérifions cinq caractéristiques.

1. L’opération modifie‑t‑elle l’état ?

Une lecture est généralement moins risquée qu’une écriture. Ce n’est pas toujours le cas — une lecture peut exposer des données sensibles — mais séparer lecture et écriture constitue un point de départ utile.

2. La conséquence quitte‑t‑elle le système interne ?

Envoyer un courriel, publier un article, activer une publicité, émettre un document ou répondre à un client sont des actions visibles à l’extérieur. Une erreur devient immédiatement un problème de relation, de coût ou de réputation.

3. L’opération crée‑t‑elle un coût ou un engagement ?

Un agent peut appeler correctement une API et prendre quand même la mauvaise décision commerciale. Le budget, les achats, les paiements, les abonnements ou les réservations de ressources nécessitent une frontière distincte.

4. Le changement est‑il facilement réversible ?

Modifier une étiquette et supprimer un compte ne sont pas de la même catégorie. Il faut considérer le coût de récupération, le temps de récupération, la perte de données et l’impact sur d’autres utilisateurs.

5. L’opération modifie‑t‑elle la sécurité ou les permissions ?

Accorder un accès administrateur, faire pivoter un secret, rendre une ressource publique ou changer la politique MFA mérite un contrôle même si l’action est techniquement réversible.

Matrice pratique d’autonomie

Niveau	Caractéristiques de l’action	Exemples	Décision par défaut
A — autonome	lecture‑seulement, impact faible, portée très restreinte	état du service, rapport de coût, liste de tâches	l’agent peut exécuter
B — autonome avec audit	écriture réversible dans une zone contrainte	ajouter une étiquette, enregistrer un brouillon, créer une tâche	l’agent peut exécuter avec permission explicite et journalisation
C — approbation avant effet	conséquence externe, effet financier ou modification matérielle	envoyer un message, publier, activer une campagne	un humain approuve l’opération spécifique
D — contrôle fort	destructif, sensible à la sécurité, difficile à inverser	supprimer des données, changer l’accès admin, révoquer une clé	portée séparée + approbation + aperçu ; souvent vérification supplémentaire

Il s’agit d’un modèle opérationnel, pas d’une norme juridique. Un système donné doit adapter les niveaux à ses données, à la réglementation, aux conséquences et aux mécanismes de récupération.

L’approbation doit être liée à une conséquence précise

Un dialogue d’approbation médiocre ressemble à ceci :

L’agent veut exécuter une action. Continuer ? Oui / Non.

La personne ne sait pas ce qu’elle autorise.

Un aperçu plus utile ressemble davantage à :

Opération : ACTIVER CAMPAGNE
Compte : Brillnet Ads / [identifiant lisible]
Campagne : Recherche — Pulsar GRC
Budget quotidien moyen : 80 PLN
Cible : Pologne
Changement : PAUSE → ACTIVÉ
État réversible : la campagne peut être à nouveau mise en pause ; les dépenses accumulées ne sont pas annulées
Conséquence : après approbation, la campagne pourra commencer à générer des dépenses
Source de décision : tâche #…

Ce n’est qu’alors qu’un bouton « Approuver » a un sens réel. Dans Google Ads, un budget quotidien moyen n’est pas un plafond strict du même jour : pour la plupart des campagnes, la limite de facturation quotidienne est le double de ce montant. L’aperçu doit expliquer cette conséquence plutôt que de promettre un plafond de 80 PLN.

L’approbation ne doit pas devenir un passe‑partout pour les changements futurs

Supposons qu’une personne approuve :

envoyer ce message à 12 destinataires

Si l’agent modifie le contenu ou la liste des destinataires pour atteindre 1 200 personnes après l’approbation, l’approbation initiale ne doit plus s’appliquer.

Une règle pratique est :

L’approbation est liée à une opération normalisée spécifique. Toute modification matérielle de ses paramètres invalide l’approbation et nécessite une nouvelle approbation.

Une implémentation peut lier l’ID d’approbation à un hachage des paramètres de l’opération, à une version de ressource ou à toute autre représentation stable de ce qui a réellement été approuvé.

Le modèle ne doit pas décider seul si l’approbation peut être ignorée

On peut demander au modèle d’estimer le risque. Cela peut constituer un signal utile, mais il ne doit pas être le seul contrôle.

Si la politique est :

lorsque le modèle considère une opération comme risquée, il demande à un humain

alors le modèle contrôle également le mécanisme destiné à contenir l’impact de ses propres erreurs.

Une conception plus robuste est :

1. Le modèle sélectionne l’outil et les paramètres.
2. Le portail classe l’opération en appliquant une politique explicite.
3. Le moteur de politique détermine si une approbation est requise.
4. Une personne approuve lorsque cela est nécessaire.
5. Ce n’est qu’alors que l’exécution a lieu.

Le modèle peut fournir l’explication. La classification finale provient de la politique du système.

Exemple tiré de notre propre automatisation : préparer une campagne n’est pas identique à lancer les dépenses

Dans notre MCP interne Brillnet Ads, nous séparons la capacité de préparer ou de modifier une campagne de la capacité d’activer les dépenses.

Une campagne nouvellement créée est par défaut en état PAUSED lorsqu’aucun autre statut n’est fourni explicitement. Enregistrer la configuration n’est pas un consentement à démarrer les dépenses. L’activation de l’effet opérationnel nécessite une permission d’opération explicite et une confirmation dans la requête. Un champ de confirmation seul ne prouve pas qu’une personne a examiné l’action. Cette preuve requiert le mécanisme d’approbation indépendant décrit ci‑dessus.

Cette petite séparation produit un résultat utile :

• l’agent peut accomplir la plupart du travail de préparation ;
• une personne n’a pas à saisir manuellement chaque champ ;
• le budget ne démarre pas simplement parce que le modèle a jugé la configuration prête.

Le même schéma s’applique à d’autres flux de travail :

Préparation	Effet nécessitant une décision séparée
rédiger un courriel	l’envoyer
proposer un rôle utilisateur	accorder l’accès
plan de migration	exécuter la migration
lister les fichiers à supprimer	les supprimer
proposition de changement de prix	publier le nouveau prix
paiement préparé	autoriser le paiement

Quand l’approbation peut être superflue

Toutes les automatisations n’ont pas besoin d’être semi‑automatiques.

L’approbation humaine ajoute souvent peu de valeur lorsque toutes les conditions suivantes sont réunies :

• l’opération est en lecture‑seule ou à faible impact ;
• l’agent travaille dans une portée étroite, pré‑approuvée ;
• le résultat n’est pas publié automatiquement ;
• une erreur est facile à détecter et à réparer ;
• il n’y a aucun coût ou engagement externe ;
• les permissions et les réglages de sécurité restent inchangés ;
• l’action laisse suffisamment de traces d’audit pour reconstruire le résultat.

Exemple : un agent récupère chaque jour l’état d’une campagne et prépare un rapport interne. Exiger qu’un humain approuve chaque lecture n’augmente pas la sécurité proportionnellement au coût opérationnel.

Quand nous recommandons l’approbation comme minimum

Dans nos projets, je ne confierais pas d’exécution autonome sans analyse séparée pour les opérations qui :

• envoient des communications aux clients ou au public ;
• démarrent ou augmentent des dépenses ;
• suppriment ou écrasent des données sans voie de récupération simple ;
• accordent, élargissent ou révoquent des permissions ;
• modifient des secrets, la configuration de sécurité ou MFA ;
• acceptent des termes légaux au nom d’une organisation ;
• agissent sur une ressource identifiée de façon ambiguë ;
• déclenchent un autre système capable d’exécuter lui‑même des actions à fort impact.

Cela ne signifie pas que l’approbation humaine soit toujours le seul contrôle. Pour les actions critiques, elle doit faire partie de plusieurs couches de protection.

Veiller à la fatigue d’approbation

Si un système demande une approbation 80 fois par jour, les utilisateurs cessent de lire les invites. L’approbation devient alors un CAPTCHA pour les employés.

Cela indique généralement l’un des trois problèmes de conception :

1. la classification du risque est trop large ;
2. le flux de travail ne regroupe pas logiquement les changements liés ;
3. l’agent dispose de trop peu d’autonomie sûre à faible risque, si bien que tout est escaladé.

La solution n’est pas de masquer les avertissements. Il faut concevoir de meilleures limites.

Ce que doit faire un mécanisme d’approbation utile

Montrer le diff, pas l’objet complet

Pour la configuration, afficher avant → après et les champs qui changent. Ne pas obliger le réviseur à comparer deux écrans manuellement.

Indiquer la conséquence

« Enregistrer le changement » est plus faible que « Activer la campagne — elle peut commencer à générer des dépenses avec un budget quotidien moyen de 80 PLN ».

Disposer d’une portée et d’une durée de vie

Une approbation ancienne ne doit pas continuer à autoriser une opération après que le contexte a changé.

Refuser une opération modifiée matériellement

Si les paramètres changent après approbation, l’approbation doit expirer.

Laisser un enregistrement indépendant

Le journal d’audit doit indiquer qui a approuvé quoi, quand et sous quel identifiant d’opération. Il ne doit pas se reposer uniquement sur un message du modèle disant « l’utilisateur a accepté ».

Lire : pistes d’audit des agents IA

Checklist pour une action d’agent unique

Avant d’accorder l’autonomie, répondre :

• L’action est‑elle en lecture‑seule ?
• Modifie‑t‑elle l’état métier ?
• Crée‑t‑elle un coût ou un engagement ?
• Le résultat est‑il visible à l’extérieur ?
• Implique‑t‑elle des données personnelles ou confidentielles ?
• Change‑t‑elle des rôles, des permissions ou la configuration de sécurité ?
• Est‑elle facile à inverser ?
• La ressource cible est‑elle non ambiguë ?
• Une tentative peut‑elle exécuter l’action deux fois ?
• Le système peut‑il afficher un aperçu concret avant exécution ?
• L’approbation sera‑t‑elle liée aux paramètres exacts ?
• L’état résultant peut‑il être vérifié après exécution ?

Si une action combine plusieurs caractéristiques à haut risque, un simple « OK » peut être un contrôle trop faible.

Exemple détaillé : une société de services envoie un rapport client

Considérons un flux de travail proposé plutôt qu’un déploiement déjà réalisé. Un agent récupère les dossiers approuvés, compare les échéances et prépare un rapport. Le propriétaire du compte reste responsable du contenu. Le propriétaire du processus définit les données autorisées et qui peut autoriser la livraison.

La préparation du brouillon peut s’exécuter dans la frontière pré‑approuvée. Avant l’envoi, afficher le client, l’adresse exacte du destinataire, l’objet, le message et les pièces jointes, ainsi que la version des données sources. Le réviseur doit pouvoir inspecter le document directement. Se fier uniquement au résumé du modèle affaiblit la révision.

L’approbation couvre ce paquet précis. Ajouter un destinataire, remplacer une pièce jointe ou modifier une recommandation matérielle invalide l’approbation. Une règle pré‑définie peut autoriser une correction orthographique, mais cela ne doit pas devenir une permission de changer le sens. Le propriétaire du processus définit les changements matériels ; le composant d’exécution applique la frontière.

Ce que doit contenir le registre d’approbation

Associer l’approbation à la personne, au rôle, au locataire, à l’outil, à la ressource cible, à la version des données, aux paramètres, à la date d’expiration et à l’identifiant de tâche. Distinguer les états proposé, en attente, approuvé, en cours d’exécution et incertain. L’opérateur doit savoir si un clic prépare une action ou la déclenche réellement.

Un hachage de paramètres aide à détecter les substitutions. Il ne prouve pas qu’une personne a lu l’aperçu. Une interface claire et un réviseur autorisé restent indispensables. Une personne qui n’a pas le droit d’accorder un accès administrateur ne doit pas l’obtenir via une boîte de dialogue d’approbation d’agent.

Pour les lots, afficher le nombre d’objets, les exceptions matérielles et l’effet total. Une approbation peut couvrir un lot précisément défini. Elle ne peut pas couvrir des objets additionnels choisis après l’approbation. Cela réduit les dialogues répétés sans perdre le contrôle de la portée.

Gérer l’exécution incertaine avant de réessayer

Un fournisseur peut exécuter une requête même si sa réponse n’atteint jamais l’agent. L’absence de confirmation n’est pas une preuve d’échec. Réessayer peut envoyer un second courriel, créer un document dupliqué ou engendrer un coût supplémentaire. Vérifier d’abord l’identifiant de la requête et l’état du fournisseur.

Lorsque des clés d’idempotence sont prises en charge, les lier à l’opération et les réutiliser pour la même requête. Sinon, mettre en place une détection de doublons ou demander à l’opérateur de décider après vérification de l’état. Enregistrer honnêtement un résultat incertain. Cliquer deux fois ne résout pas un résultat inconnu.

Le silence n’est pas une approbation

Attribuer un suppléant et un canal de notification à chaque processus. Une expiration sans réponse bloque l’opération conditionnée. L’agent peut continuer à préparer d’autres travaux autorisés à faible risque ; il ne doit pas déduire le consentement du silence ou d’une échéance métier.

Définir séparément l’arrêt d’urgence. La permission d’arrêter un flux de travail incorrect peut être plus restreinte que celle de le démarrer. Conserver l’état d’exécution et la liste des actions accomplies. Restaurer la configuration ne peut pas rappeler un message client déjà lu.

Vérifier si la révision modifie les décisions

Suivre les corrections, les refus, le temps d’attente et les tentatives d’exécuter des paramètres modifiés matériellement. Comparer séparément les types d’opération. Un délai d’approbation long pour les communications client ne doit pas empêcher la préparation autonome de tâches internes.

Si chaque proposition est approuvée immédiatement pendant plusieurs semaines, examiner un échantillon avec le propriétaire du processus. La politique est peut‑être trop large, ou les aperçus omettent des informations utiles. Un nombre élevé d’approbations n’est pas une preuve de sécurité.

Demain, choisir une action externe. Construire son aperçu, identifier un réviseur autorisé, définir une date d’expiration et vérifier que changer le destinataire invalide l’approbation. Confirmer que le refus n’entraîne aucun effet externe.

Recommandations et limites de source

OWASP couvre les contrôles d’actions à fort impact et l’intégrité des approbations. Les guides d’autorisation de transaction traitent de la vérification côté serveur des données de transaction importantes. Le NIST AI RMF fournit des recommandations volontaires de gestion des risques. Notre matrice A–D constitue une recommandation d’ingénierie, pas une obligation légale d’approuver chaque action d’IA. La documentation interne du MCP Ads datée du 28 juillet 2026 décrit le design de contrôle cité ; elle ne prouve pas de façon indépendante une mise en production chez un client.

Limite

Ce modèle de classification reflète notre pratique d’ingénierie, pas un avis juridique ni une norme formelle d’évaluation des risques. Les processus réglementés, médicaux, financiers ou critiques pour la sécurité peuvent exiger des contrôles plus stricts.

Voir également MCP et agents IA : concevoir des outils plus sûrs et Moindre privilège pour les agents IA.

Sources

• OWASP AI Agent Security Cheat Sheet. Consulté : 2026-10-02.
• OWASP Transaction Authorization Cheat Sheet. Consulté : 2026-10-02.
• NIST AI Risk Management Framework. Consulté : 2026-10-02.
• Google Ads Help — About spending limits. Consulté : 2026-10-02.