Validation humaine d'un agent IA : quelles actions faire valider
Faire valider chaque action d'un agent revient à ne rien valider : au bout de la cinquantième demande, on confirme sans lire. Ne rien faire valider revient à laisser un modèle probabiliste écrire dans vos outils. Entre les deux, il faut choisir quelles actions arrêter, et soigner la façon dont on les présente.
Publié le 22 septembre 2026
Ce que la validation humaine protège, et ce qu'elle ne protège pas
Le guide IA générative ou règles pose le principe : le modèle propose, une règle contrôle, une personne valide ce qui engage. Ce guide va plus loin sur la dernière étape, celle qu'on appelle human in the loop : quelles actions arrêter, et comment.
Un agent peut se tromper de trois façons : il comprend mal la demande, il s'appuie sur une information fausse, ou il est manipulé par un contenu qu'il lit, par exemple un courriel qui contient une consigne cachée. Dans les trois cas, l'erreur n'a de conséquence que si elle se transforme en action. La validation humaine est le dernier point où cette transformation peut être arrêtée.
Elle ne protège pas de tout. Elle ne corrige pas une réponse fausse que l'utilisateur lit et reprend à son compte, elle ne remplace pas des droits bien réglés, et elle ne vaut que si la personne qui valide comprend ce qu'elle voit. C'est un contrôle parmi d'autres, décrit avec les autres exigences dans le guide plateforme agentique en entreprise.
Classer les actions, pas les agents
L'erreur courante consiste à régler la validation par agent : « cet agent est sûr, celui-là doit tout faire valider ». Or un même agent enchaîne des lectures sans risque et des écritures qui engagent. La bonne unité est l'action, c'est-à-dire l'appel d'un outil précis.
| Nature de l'action | Exemples | Validation humaine |
|---|---|---|
| Lecture | Chercher un document, lire un courriel, consulter une fiche | Non, les droits d'accès suffisent |
| Préparation | Rédiger un brouillon, proposer une réponse, calculer une estimation | Non, rien ne sort tant que personne ne l'utilise |
| Écriture interne réversible | Ajouter une note à un ticket, créer une tâche | À décider selon le contexte |
| Écriture qui engage | Modifier une commande, mettre à jour un contrat, changer un statut client | Oui |
| Envoi vers l'extérieur | Envoyer un courriel, publier un message, partager un fichier | Oui |
| Suppression ou exécution | Supprimer un enregistrement, lancer un traitement, déclencher un paiement | Oui |
Cette classification doit être attachée à l'outil, au moment où il est déclaré, et non évaluée par le modèle au moment de l'appel. Si c'est le modèle qui décide qu'une action « ne nécessite pas de confirmation », la validation dépend de la même source d'erreur qu'elle est censée contrôler.
Les critères qui font basculer une action
La ligne « écriture interne réversible » du tableau est la plus délicate. Pour trancher, six critères aident, et un seul suffit souvent à imposer une validation :
- L'irréversibilité : une fois faite, l'action se rattrape-t-elle sans dommage ? Un courriel envoyé ne se rappelle pas.
- Le destinataire externe : l'effet sort-il de l'organisation, vers un client, un fournisseur, le public ?
- Le volume : l'action touche-t-elle un enregistrement ou mille ? Une mise à jour en masse mérite toujours un arrêt.
- Les données sensibles : l'action manipule-t-elle des données personnelles, de santé, financières, couvertes par un secret ?
- L'engagement financier ou juridique : l'action crée-t-elle une obligation, un paiement, un engagement contractuel ?
- L'effet sur une personne : l'action contribue-t-elle à une décision qui affecte quelqu'un, comme un refus, une sanction, une priorité de traitement ?
Le dernier critère a une portée juridique. L'article 22 du RGPD donne à la personne concernée le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou l'affectant de manière significative, et prévoit, dans les cas où une telle décision est admise sur la base d'un contrat ou du consentement, le droit d'obtenir une intervention humaine. Une validation de pure forme ne répond pas à cette exigence.
Concevoir une validation qui reste lue
Le principal ennemi de la validation humaine n'est pas la malveillance, c'est l'habitude. Une personne qui voit cinquante demandes par jour, toutes justes, finit par confirmer sans regarder. L'AI Act nomme ce phénomène « biais d'automatisation » et demande que les personnes chargées du contrôle y soient sensibilisées. La conception de la validation doit le combattre.
- Déclencher de façon déterministeL'arrêt dépend de la nature de l'outil appelé, jamais de l'appréciation du modèle.
- Montrer l'action exacteLe destinataire, le contenu intégral, les champs modifiés avec leur valeur avant et après. Pas un résumé rédigé par le modèle.
- Donner le contexte utilePourquoi l'agent propose cette action : la demande d'origine et les sources qu'il a utilisées.
- Permettre de refuser simplementRefuser doit être aussi facile que confirmer, et l'agent doit s'arrêter proprement après un refus.
- Tracer la décisionQui a confirmé ou refusé, quand, et ce qui était affiché à ce moment.
Si la personne qui valide ne voit qu'une phrase comme « L'agent va répondre au client », elle ne valide rien. Elle doit voir le message exact, au destinataire exact, tel qu'il partira.
Deux réglages complètent ce dispositif. Le regroupement : quand un agent prépare vingt actions de même nature, les présenter ensemble, lisibles une par une, vaut mieux que vingt interruptions. L'expiration : une demande de validation restée sans réponse ne doit pas s'exécuter par défaut. Le silence vaut refus.
Qui valide, et ce qu'en dit l'AI Act
Dans la plupart des usages, la personne qui valide est celle qui a lancé l'agent : elle connaît le contexte et assume l'action. Pour les actions à fort enjeu, un second regard peut s'imposer, sur le modèle des « quatre yeux » déjà pratiqué pour les paiements.
Dans tous les cas, la personne doit avoir la compétence pour juger et l'autorité pour refuser. C'est aussi ce que demande l'AI Act pour les systèmes à haut risque. L'article 14 exige que ces systèmes puissent être contrôlés effectivement par des personnes physiques, qui doivent notamment pouvoir comprendre les capacités et les limites du système, décider de ne pas en suivre la sortie, et l'interrompre. L'article 26 impose aux déployeurs de confier ce contrôle à des personnes disposant de la compétence, de la formation et de l'autorité nécessaires.
Toutes les utilisations d'agents ne sont pas à haut risque au sens du règlement, et le calendrier d'application de ces obligations a été révisé par l'omnibus numérique : la page de la Commission européenne indique une application à partir du 2 décembre 2027 pour les domaines à haut risque listés à l'annexe III. Concevoir dès maintenant une validation conforme à ces principes évite de reprendre l'architecture le jour où un usage bascule dans cette catégorie.
Les erreurs les plus fréquentes
Tout faire valider
La validation systématique paraît prudente et produit l'inverse : des confirmations machinales. Les lectures et les brouillons n'ont pas à être arrêtés.
Laisser le modèle décider de ce qui est sensible
Une consigne du type « demande confirmation avant les actions importantes » dépend du jugement du modèle. Un contenu malveillant peut précisément le convaincre qu'une action n'est pas importante.
Valider un résumé
Une validation qui montre une reformulation de l'action, et non l'action elle-même, laisse passer exactement les erreurs qu'elle devait arrêter.
Oublier la trace du refus
Un refus est une information : il signale une erreur de l'agent, une consigne ambiguë, parfois une tentative de détournement. Il doit être tracé et relu, au même titre qu'une confirmation.
Questions fréquentes
La validation humaine ralentit-elle trop les agents ?
Elle ralentit les actions qu'elle arrête, et seulement celles-là. Si la classification est bonne, l'agent travaille seul sur les lectures et les préparations, qui représentent l'essentiel du travail, et ne s'arrête qu'avant les effets difficiles à rattraper.
Peut-on assouplir la validation une fois l'agent éprouvé ?
Pour des écritures internes réversibles, oui, après une période où les décisions humaines ont été tracées et analysées. Pour les envois externes, les suppressions et les engagements financiers, la fiabilité passée d'un agent ne protège pas contre un contenu malveillant qu'il lira demain.
La validation humaine suffit-elle pour respecter l'AI Act ?
Non. Le contrôle humain est une des exigences applicables aux systèmes à haut risque, à côté de la gestion des risques, de la journalisation, de la transparence et de la qualité des données. Il en est une pièce, pas la totalité.
Où se situe SmartAGT
Dans SmartAGT, toute action d'écriture est mise en pause avant exécution, par défaut : la nature de l'action décide, pas le modèle. L'opérateur voit exactement ce qui va se passer, confirme ou refuse.
La décision est tracée avec l'acteur humain dans une chaîne d'audit hash-chaînée SHA-256, vérifiable de bout en bout. Le détail est sur la page Sécurité.
