Agents IA : où la validation humaine s’impose

01Un agent agit : la question change

Un assistant conversationnel rédige un texte, et une personne décide de ce qu’elle en fait. Un agent va plus loin : il appelle des outils. Il met à jour un dossier, réserve un créneau, oriente une demande, envoie un message ou prépare un paiement. Dès qu’un logiciel agit, la question utile n’est plus seulement « cette réponse est-elle bonne ? », mais « qui répond de cette action, et à quel moment a-t-il donné son accord ? »

Les spécialistes de la sécurité ont un nom pour l’erreur inverse. Le Top 10 de l’OWASP consacré aux applications de grands modèles de langage range l’agentivité excessive (ouvre un site externe) (excessive agency) parmi les risques majeurs : un agent doté de plus de fonctions, de plus de droits ou de plus d’autonomie que sa tâche ne l’exige. La validation humaine est l’une des parades. Appliquée partout, elle ralentit le travail et habitue les équipes à cliquer sur « approuver ». Appliquée nulle part, elle laisse des actions que personne n’a décidées. Tout l’enjeu est de bien la placer.

02Partir des actions, pas du modèle

Dressez l’inventaire de tous les outils que l’agent peut appeler. Pour chacun, posez quatre questions. Elles portent délibérément sur l’action et ses effets, pas sur le modèle.

1. 01Peut-on revenir en arrière ? Et à quel prix : un clic, un courrier rectificatif, un remboursement, une procédure judiciaire ?
2. 02Qui est concerné ? Un brouillon interne, un collègue, un client ou un usager, de l’argent, un tiers ?
3. 03L’action crée-t-elle un engagement ou un effet juridique ? Une décision concernant une personne, un paiement, un contrat, un message envoyé au nom de votre organisation.
4. 04À quelle fréquence et à quelle vitesse ? Une action répétée des milliers de fois par jour n’appelle pas le même contrôle qu’une action qui survient deux fois par semaine.

Les réponses placent chaque action dans l’un des quatre niveaux ci-dessous. La plupart des organisations constatent qu’une poignée d’actions concentre presque tout le risque. C’est une bonne nouvelle : c’est là que l’effort de validation doit porter.

Ces niveaux sont un outil de conception, pas une qualification juridique. Confrontez-les aux règles qui vous sont applicables. Le RGPD accorde aux personnes des droits spécifiques face à une décision fondée exclusivement sur un traitement automatisé (ouvre un site externe) produisant des effets juridiques ou les affectant de manière significative (article 22). Pour les systèmes à haut risque, le règlement européen sur l’IA (AI Act) exige qu’ils puissent faire l’objet d’un contrôle effectif par des personnes physiques (ouvre un site externe) (article 14). C’est généralement au niveau 4 que ces obligations s’appliquent.

03Les signaux qui doivent toujours remonter à une personne

Certaines situations doivent faire monter une action d’un niveau, quelle que soit sa place habituelle. Intégrez-les comme des contrôles explicites dans le workflow, pour qu’ils ne dépendent pas de la vigilance de l’agent.

• L’entrée sort du périmètre sur lequel l’agent a été testé : nouveau type de document, langue inhabituelle, champs manquants ou contradictoires.
• Les sources récupérées par l’agent se contredisent, ou l’action proposée repose sur un élément qu’il ne peut pas citer.
• Le montant, la portée ou le nombre de dossiers concernés dépasse un seuil que vous avez fixé.
• Le dossier touche une catégorie sensible : données de santé, mineurs, réclamation, litige ou recours en cours.
• L’agent a déjà fait plusieurs tentatives, ou un système en aval a renvoyé une erreur.

Un signal manque volontairement à cette liste : la confiance que le modèle affiche lui-même. Un modèle de langage peut énoncer des erreurs avec aisance, ce que le National Institute of Standards and Technology américain (NIST) appelle confabulation (ouvre un site externe) dans son profil de risques de l’IA générative. Un score autodéclaré peut constituer un indice parmi d’autres, mais il doit s’ajouter à des contrôles externes, comme des règles de validation et une comparaison avec le système de référence, jamais les remplacer.

04Concevoir une validation que l’on peut réellement donner

Une avalanche de demandes « approuver ? » apprend surtout à approuver. Le règlement sur l’IA nomme ce risque explicitement : les personnes chargées du contrôle d’un système à haut risque doivent rester conscientes du biais d’automatisation.

Quatre choix de conception rendent cette vigilance possible au quotidien.

Montrer les preuves, pas seulement la réponse

Présentez l’action proposée en termes simples, les sources sur lesquelles elle s’appuie (avec des liens qui s’ouvrent au bon passage), la règle ou la politique appliquée, et ce qui changera exactement, dans quel système. Une personne qui doit ouvrir trois applications pour vérifier une proposition finira, sous la pression du temps, par ne plus vérifier.

Rendre le « non » aussi simple que le « oui »

Rejeter et corriger sont des issues normales, pas des exceptions. Placez ces options à côté du bouton de validation, demandez un bref motif en cas de rejet et exploitez ces motifs dans l’évaluation. Si corriger une proposition est plus laborieux que de la rédiger soi-même, les équipes valideront des propositions imparfaites.

Confier la validation à un rôle qui a autorité

La validation revient à un rôle désigné, doté des compétences, de la formation et de l’autorité nécessaires pour passer outre au système ; pour les systèmes d’IA à haut risque, le règlement sur l’IA demande exactement cela aux déployeurs (article 26, paragraphe 2 (ouvre un site externe)). Prévoyez un suppléant et une voie d’escalade, et mesurez le temps d’attente des demandes. Une file que personne ne pilote devient le goulot d’étranglement qui pousse les équipes à contourner la validation.

Ne regrouper que ce qui est vraiment à faible risque

Examiner une à une quarante demandes quasi identiques ne rend personne plus attentif. Pour les actions de niveau 2, autorisez un examen groupé avec échantillonnage aléatoire. Gardez un examen individuel pour les niveaux 3 et 4.

05Imposer la validation dans le système, pas dans le prompt

Une consigne dans un prompt n’est pas un contrôle d’accès. Les contenus que lit l’agent, qu’il s’agisse d’un e-mail, d’un document ou d’une page web, peuvent contenir leurs propres instructions : c’est ce que l’OWASP décrit sous le nom d’injection de prompt (ouvre un site externe) (prompt injection). Si la seule barrière entre un agent et une action irréversible est une phrase dans ses instructions, partez du principe que cette phrase sera un jour contournée.

• Donnez à l’agent sa propre identité, avec le minimum de droits nécessaires pour chaque outil, et faites-le agir dans les limites des droits de l’utilisateur demandeur lorsque la plateforme le permet.
• Imposez les validations dans la couche d’intégration : le service qui envoie le courrier refuse l’appel s’il n’existe pas d’enregistrement de validation valide pour cette action précise.
• Appliquez aux outils des plafonds de montant, de volume et de fréquence, indépendamment de l’agent.
• Séparez les outils de lecture et d’écriture : vous pourrez élargir ce que l’agent peut voir sans élargir ce qu’il peut faire.

06Journaliser ce qu’il faudra pouvoir expliquer

Pour chaque exécution de l’agent, conservez la demande, les sources récupérées, chaque appel d’outil avec ses paramètres, l’action proposée, la personne qui a validé, la décision, les éventuelles corrections et les horodatages. Pour les systèmes d’IA à haut risque, les déployeurs doivent conserver les journaux générés automatiquement pendant au moins six mois, sauf disposition contraire d’un autre texte (article 26, paragraphe 6 (ouvre un site externe)). Même lorsqu’aucune règle ne l’impose, conservez-les : le journal est votre principal outil d’apprentissage.

Analysez les journaux à intervalles réguliers. Les actions toujours validées sans modification peuvent descendre d’un niveau. Celles qui sont souvent corrigées révèlent une faiblesse de l’agent, ou relèvent du niveau supérieur. Des rejets qui se concentrent sur une source, un formulaire ou une équipe trahissent généralement un problème de processus qu’aucun modèle ne résoudra.

07Commencer serré, puis alléger action par action

Au lancement, placez la plupart des actions qui comptent aux niveaux 3 et 4. Convenez au préalable de ce qu’est un bon résultat : quelles issues sont correctes, quelles erreurs sont acceptables et lesquelles ne le sont pas. Mesurez ensuite au regard de ces critères, par exemple en utilisant comme liste de contrôle la fonction de mesure du cadre de gestion des risques de l’IA du NIST (ouvre un site externe) (AI RMF).

Ne faites passer une action à un niveau plus léger que sur la base de preuves : une période pendant laquelle les validations n’ont appelé aucune correction substantielle, des tests sur les cas qui ont posé problème et l’accord du responsable du processus. Documentez cette décision comme toute autre modification du système, et gardez la possibilité de revenir en arrière.

Les résultats d’une IA peuvent être faux. Ce n’est pas une raison pour tenir les agents à l’écart du travail réel ; c’est la raison de concevoir précisément les endroits où l’humain garde la main. Un agent est utile parce qu’il peut agir. Placer les points de validation de façon réfléchie, c’est ce qui permet de lui confier davantage avec le temps.