Agents IA : pourquoi les actions sensibles doivent attendre une validation humaine

Un assistant qui répond à une question se trompe parfois. C'est gênant, mais la personne qui lit la réponse peut la vérifier avant de s'en servir. Un agent va plus loin : il peut envoyer un e-mail, créer une fiche dans un logiciel, supprimer un enregistrement. Là, une erreur ne reste pas sur l'écran. Elle part chez un client, modifie un dossier, engage l'entreprise.

C'est pour cette raison que la question à se poser n'est pas « faut-il faire confiance à l'IA ? », mais « quelles actions l'IA peut-elle faire seule, et lesquelles doivent attendre l'accord de quelqu'un ? ».

Toutes les actions ne se valent pas

La première étape consiste à classer ce qu'un agent peut faire, non par outil, mais par type d'action. Une classification simple suffit à couvrir la plupart des situations :

• Lecture : chercher dans des documents, consulter une fiche. Rien ne change dans vos systèmes.
• Écriture : créer ou modifier une donnée dans un logiciel métier.
• Suppression : effacer un enregistrement ou un fichier.
• Communication externe : envoyer un e-mail ou un message à l'extérieur de l'entreprise.
• Données sensibles : manipuler des données personnelles ou confidentielles.
• Administration : modifier des droits, des réglages, des accès.
• Action irréversible : tout ce qui ne peut pas être annulé.

Ce classement donne immédiatement une règle par défaut raisonnable. La lecture peut être autorisée. L'écriture, la suppression, la communication externe et les données sensibles demandent une validation. L'administration et les actions irréversibles sont interdites à un agent, sauf décision explicite.

Un minimum qui ne se désactive pas

Une règle par défaut ne suffit pas si n'importe qui peut la retirer d'un clic. Pour les actions qui engagent l'entreprise, il est sain de prévoir un plancher : un niveau de contrôle qu'aucun réglage ne peut abaisser.

Concrètement, une organisation doit pouvoir durcir ses règles, par exemple interdire purement et simplement les envois d'e-mails par un agent. Mais elle ne devrait pas pouvoir autoriser un envoi vers l'extérieur sans validation, même par erreur de configuration. Dans MutuaCore AI, ce plancher est vérifié deux fois : par le moteur de règles et par la base de données elle-même.

Ce qu'une bonne validation doit montrer

Une validation n'a de valeur que si la personne sait exactement ce qu'elle approuve. Une demande de validation utile présente :

1. L'action précise : « envoyer cet e-mail à cette adresse », pas « l'agent souhaite communiquer ».
2. Son contenu complet : le texte, les destinataires, les données qui seront transmises.
3. Le contexte : quel agent, à la demande de qui, à partir de quelle question.
4. Le type d'action : pour que la personne mesure le niveau de risque.

Un point est souvent négligé : ce qui a été validé doit être exactement ce qui est exécuté. Si les paramètres d'une action peuvent changer entre le moment où elle est approuvée et le moment où elle s'exécute, la validation ne protège plus rien. Les arguments d'une demande doivent donc être figés dès qu'elle est présentée.

Que faire des demandes sans réponse ?

Une demande de validation qui reste ouverte indéfiniment est un risque discret : elle peut être approuvée des jours plus tard, dans un contexte qui a changé. La bonne pratique est de donner une durée de vie à chaque demande. Passé ce délai, elle expire et rien n'est exécuté. Si l'action est toujours utile, il suffit de la redemander.

Qui valide ?

Valider une action est une responsabilité. Elle doit être confiée à des personnes désignées, pas à tous les utilisateurs. Deux principes aident :

• un droit dédié : la capacité à décider des validations est un droit distinct, attribué par rôle ;
• une décision nominative : chaque validation ou refus est rattaché à la personne qui l'a pris, avec la date et l'heure.

Garder une trace de tout

La validation humaine prend tout son sens lorsqu'elle laisse une trace. Pour chaque action demandée par un agent, il faut pouvoir retrouver ce qui a été demandé, la règle appliquée, la décision prise, par qui, et le résultat.

Cette trace sert à plusieurs moments : comprendre un incident, répondre à un client, préparer un audit. Elle n'a de valeur que si elle ne peut pas être réécrite après coup. Un journal d'audit dans lequel l'application peut seulement ajouter des lignes, jamais les modifier ni les effacer, répond à cette exigence.

Et la réglementation ?

Le règlement européen sur l'intelligence artificielle (AI Act) fait du contrôle humain une exigence explicite pour les systèmes d'IA à haut risque (article 14) : des personnes compétentes doivent pouvoir comprendre, surveiller et, si nécessaire, interrompre ou corriger le système.

Même lorsque vos usages ne relèvent pas de cette catégorie, la logique reste la bonne. Un agent qui agit dans vos outils doit rester sous la supervision de personnes qui comprennent ce qu'il fait.

En résumé

Laisser un agent lire et proposer, garder la décision pour tout ce qui engage l'entreprise.

Pour mettre cela en place :

• classez les actions par type, pas par outil ;
• appliquez des règles par défaut prudentes, et un plancher impossible à abaisser ;
• présentez des demandes de validation complètes, aux paramètres figés ;
• faites expirer les demandes sans réponse ;
• réservez la décision à des personnes désignées ;
• enregistrez chaque demande, décision et résultat dans un journal non modifiable.