Agents IA : quand faut-il l’accord d’une personne ?

01Du texte à l’action

Avec un assistant conversationnel, la machine propose un texte et un humain l’utilise ou non. L’agent, lui, manipule des outils : mise à jour d’un dossier, prise de rendez-vous, transfert d’une demande vers le bon service, envoi d’un courriel, préparation d’un virement. À partir de là, juger la qualité de la réponse ne suffit plus. Il faut savoir qui porte la responsabilité de chaque action, et quand cette personne l’a acceptée.

L’OWASP, qui publie un classement des risques propres aux applications fondées sur de grands modèles de langage, y range l’excessive agency (ouvre un site externe) : un agent qui a reçu plus de fonctions, plus d’autorisations ou plus de latitude que nécessaire. Faire valider par un humain est l’une des réponses. Mal dosée, elle échoue dans les deux sens. Appliquée partout, elle freine les équipes et devient un réflexe de clic. Appliquée nulle part, elle laisse s’exécuter des opérations que personne n’a voulues. Le travail consiste donc à bien choisir ses emplacements.

02Inventorier les outils de l’agent

On ne part pas du modèle, mais de la liste des outils qu’il peut déclencher. Chaque outil passe par quatre questions, toutes centrées sur l’effet produit.

1. 01Peut-on revenir en arrière ? Parfois un clic suffit. Parfois il faut un courrier de correction, un remboursement ou un procès.
2. 02Sur qui retombe l’action ? Sur un document de travail, un collègue, un client, un résident ou un frontalier, un tiers, ou sur des fonds.
3. 03Engage-t-elle l’organisation ? C’est le cas d’une décision visant une personne, d’un paiement, d’un contrat ou d’un courrier signé au nom de l’administration ou de la société.
4. 04Quel volume, quel rythme ? Une opération exécutée des milliers de fois chaque jour appelle un autre dispositif qu’une opération hebdomadaire.

Selon les réponses, l’outil se range dans l’un des quatre niveaux du tableau. L’expérience montre que le risque se concentre presque toujours sur quelques actions seulement. Tant mieux : l’effort de validation peut s’y concentrer aussi.

Cette grille sert à concevoir ; elle ne classe rien au sens du droit. Vérifiez-la au regard des textes applicables. L’article 22 du RGPD, dont la CNPD surveille l’application au Luxembourg, protège les personnes contre les décisions prises uniquement par un traitement automatisé (ouvre un site externe) lorsqu’elles produisent des effets juridiques ou comparables. L’article 14 du règlement sur l’IA demande que les systèmes à haut risque restent sous une surveillance humaine effective (ouvre un site externe). Ces deux exigences visent surtout le niveau 4.

03Cinq situations qui imposent un regard humain

Certains cas doivent remonter d’un niveau, quelle que soit l’action. Ne comptez pas sur l’agent pour les repérer : codez ces tests dans le processus.

• Une entrée inédite pour l’agent : type de document jamais vu, champs absents ou incohérents, ou langue imprévue, comme une demande rédigée en luxembourgeois dans un circuit prévu pour le français et l’allemand.
• Des sources qui ne concordent pas, ou une proposition qui s’appuie sur un élément sans référence.
• Un montant, un périmètre ou un nombre d’enregistrements supérieur au seuil fixé par vos soins.
• Un sujet sensible : santé, enfants, plainte, contentieux, recours pendant.
• Une erreur renvoyée par un système en aval, ou une tentative déjà répétée.

Volontairement, la confiance que le modèle déclare n’y figure pas. Un modèle de langage formule une erreur avec le même aplomb qu’une réponse juste. Le NIST, l’institut américain de normalisation, appelle ce phénomène confabulation (ouvre un site externe) dans son profil consacré à l’IA générative. Un score d’auto-évaluation peut compléter des contrôles indépendants, règles de validation ou rapprochement avec le système de référence. Il ne les remplace pas.

04Concevoir une validation qui ne soit pas un réflexe

À force de demandes de confirmation en série, on finit par confirmer sans lire. Le règlement sur l’IA vise ce travers à l’article 14, paragraphe 4, point b) : les personnes qui surveillent un système à haut risque doivent garder à l’esprit le biais d’automatisation, c’est-à-dire la tentation de se reposer sur le résultat de la machine.

Quatre principes de conception aident à tenir cette exigence.

Afficher les pièces justificatives

L’écran de validation décrit l’opération en langage courant. Il cite les sources, avec un lien qui mène directement au passage concerné. Il nomme la règle appliquée et montre la modification exacte, système par système. Une vérification qui exige d’ouvrir trois applications ne sera plus faite le jour où l’équipe est sous pression. Quand les pièces existent en français, en allemand et en anglais, signalez la langue de chacune.

Refuser doit être aussi simple qu’accepter

Corriger et refuser font partie du fonctionnement normal. Les trois boutons figurent côte à côte. Un refus s’accompagne d’un motif bref, réutilisé ensuite pour évaluer l’agent. Si retoucher une proposition prend plus de temps que de la rédiger soi-même, les équipes valideront des propositions médiocres.

Désigner un rôle habilité

L’approbateur est un rôle identifié, formé, compétent et autorisé à contredire la machine. Pour les systèmes à haut risque, l’article 26, paragraphe 2 (ouvre un site externe) du règlement en fait une obligation du déployeur. Ajoutez un remplaçant, une voie d’escalade et un suivi des délais. Chez un administrateur de fonds, un dossier d’investisseur signalé par l’agent rejoint la file du service conformité, avec un délai de traitement suivi. Une file sans titulaire devient vite le point de blocage que l’on finit par contourner.

Grouper uniquement le faible risque

Examiner à la suite quarante cas quasi identiques n’améliore pas l’attention. Le niveau 2 se prête à une revue par lots, complétée par des contrôles aléatoires. Aux niveaux 3 et 4, chaque cas garde son examen individuel.

05Un contrôle technique, pas une consigne

Écrire « demande toujours l’accord » dans les instructions de l’agent ne protège rien. Tout contenu qu’il lit, courriel, pièce jointe ou site web, peut y glisser ses propres ordres. L’OWASP décrit ce mécanisme sous le nom de prompt injection (ouvre un site externe). Si l’unique barrière avant une opération irréversible est une phrase du prompt, considérez qu’elle cédera un jour.

• L’agent reçoit une identité technique distincte, limitée aux droits strictement utiles à chaque outil. Lorsque la plateforme le permet, il agit avec les droits de l’utilisateur qui l’a sollicité.
• La validation se vérifie dans la couche d’intégration. Exemple chez un distributeur : le service qui comptabilise une facture fournisseur au-delà d’un certain montant rejette l’appel s’il ne trouve aucun accord enregistré pour cette facture.
• Les outils portent leurs propres limites de montant, de volume et de cadence, indépendantes de l’agent.
• Lecture et écriture passent par des outils distincts. On peut ainsi ouvrir davantage de données à l’agent sans lui donner davantage de pouvoir.

06Tracer pour pouvoir rendre compte

Chaque exécution laisse une trace complète : demande d’origine, sources trouvées, appels d’outils et paramètres, proposition, identité de l’approbateur, décision, corrections, horodatage. Le règlement impose aux déployeurs de systèmes à haut risque de garder les journaux automatiques au moins six mois, sauf autre règle (article 26, paragraphe 6 (ouvre un site externe)). Sans obligation, conservez-les tout de même : ils sont votre meilleur outil d’apprentissage.

Analysez ces journaux à intervalles réguliers. Ce qui est toujours validé tel quel peut descendre d’un niveau. Ce qui est souvent retouché trahit une faiblesse de l’agent, ou doit monter d’un cran. Quand les refus se concentrent sur une source, un formulaire ou une équipe, la cause se trouve en général dans le processus, et aucun modèle ne la corrigera.

07Démarrer prudemment, assouplir sur preuves

Au démarrage, les opérations à fort impact restent aux niveaux 3 et 4. Avant la mise en service, fixez vos critères : ce qui compte comme un bon résultat, les erreurs tolérables et celles qui ne le sont pas. Mesurez ensuite l’agent sur ces critères. Les fonctions de mesure de l’AI Risk Management Framework du NIST (ouvre un site externe) offrent pour cela une liste de contrôle utile.

Une action ne descend de niveau qu’avec des éléments concrets : une période sans correction significative, des tests sur les cas qui avaient échoué, l’accord écrit du propriétaire du processus. Ce changement se documente comme toute évolution du système, et il reste réversible.

Un système d’IA commet des erreurs. Il faut en tirer une méthode, pas une interdiction : décider où l’humain garde la main. La valeur d’un agent tient à sa capacité d’agir, et des points de validation bien placés permettent de lui en confier progressivement davantage.