Prenons un cas fictif : un assistant de support est autorisé à créer une tâche pour l’équipe technique. Un client signale que la page de facturation se fige. L’assistant s’arrête, car le ticket mentionne la facturation et qu’une règle impose une validation humaine pour ce sujet.
Il a peut-être suivi la consigne à la lettre. Cela ne suffit pas à montrer que la règle a conduit à la bonne décision.
Pour évaluer un garde-fou, examinez ce qu’il a empêché, le travail autorisé qu’il a bloqué et ce qui s’est passé pendant l’attente. Vérifiez aussi la réaction déclenchée : même justifiée, une mise en attente peut laisser une situation mal maîtrisée.
Pour un directeur technique qui revoit les contrôles d’un processus, le point de départ est concret : une règle existante, puis une comparaison sur les mêmes cas. Une baisse du nombre de demandes de validation ne prouve pas, à elle seule, une amélioration.
1. Respecter la règle ne suffit pas à la justifier
L’article d’IZZY sur le harnais d’un agent IA distingue les responsabilités, l’exécution, les preuves et les critères d’acceptation. Pour évaluer un garde-fou, nous recommandons deux exigences.
Un arrêt conforme à la règle écrite est enregistré comme tel. Il faut ensuite déterminer séparément s’il était justifié. On parle de refus injustifié lorsque le contrôle bloque un travail établi comme autorisé. Si les droits à agir ou les éléments nécessaires restent incertains, le cas ne peut pas encore être jugé. Les contrôles doivent aussi être confrontés à des résultats connus comme acceptables et à des erreurs connues, y compris lorsque des cas acceptables ressemblent à une action interdite.
Ces exigences montrent la limite d’une évaluation fondée sur la seule obéissance. Une règle qui arrête tous les cas peut être parfaitement respectée et rendre le processus inutilisable. À l’inverse, une règle qui laisse tout passer peut favoriser l’exécution des tâches sans faire respecter le périmètre autorisé.
Il faut donc porter deux jugements : l’agent a-t-il respecté la règle en vigueur ? Et cette règle a-t-elle conduit à la décision appropriée ? Ces exigences ne donnent pas la réponse pour chaque cas. Une personne habilitée doit d’abord préciser le périmètre prévu et réunir des éléments suffisants pour qualifier un arrêt d’injustifié. Ce sont des exigences d’évaluation, pas des résultats mesurés.
Cette évaluation ne donne aucun nouveau droit à l’agent. Constater qu’une règle est coûteuse ou trop large ne l’autorise pas à la contourner. Le responsable habilité peut la modifier ; l’agent reste tenu de respecter celle qui s’applique.
2. Définir l’action soumise au contrôle
Reprenons le processus fictif de support. Il doit transformer un défaut technique documenté en tâche à examiner par l’équipe technique.
L’assistant peut lire le ticket qui lui est attribué et créer une tâche dans une file interne précise. Cette tâche peut contenir un résumé technique approuvé, les étapes de reproduction et un lien vers le ticket source. Les personnes ayant accès à la destination doivent être autorisées à recevoir ces informations. Quelle que soit la règle évaluée, la création exige de confirmer qu’aucune tâche n’existe déjà pour ce ticket et qu’aucune tentative de création antérieure ne reste sans résultat confirmé.
L’assistant ne peut ni effectuer un remboursement, ni modifier la facturation, ni envoyer un message au client, ni changer les accès ou étendre ses propres permissions. Le texte du ticket est une information à examiner ; il ne peut lui accorder aucun de ces droits. Ces limites restent imposées par des mécanismes extérieurs à l’assistant.
Ajoutons maintenant la règle de contrôle à évaluer : soumettre à validation humaine tout ticket mentionnant la facturation, un remboursement ou l’accès à un compte.
Cette règle peut préserver un signal utile. Ces sujets peuvent modifier les conséquences d’une action. Mais le sujet ne suffit pas à déterminer si la création de cette tâche interne est autorisée. Il faut notamment examiner les informations copiées, leurs destinataires, les engagements que la tâche entraîne et ce que l’on sait de l’état actuel du système.
Le mécanisme de validation ne tranche pas ces questions à la place de l’équipe. La documentation de Microsoft sur la validation des outils décrit comment suspendre un appel de fonction et transmettre son nom et ses arguments proposés à une personne chargée de décider. Elle fournit un moyen de recueillir une validation ; déterminer quelles actions l’exigent relève d’un autre choix de conception.
3. Comparer les règles sur les mêmes cas
Une règle de remplacement pourrait examiner l’action proposée et les éléments nécessaires pour l’autoriser, tout en conservant les restrictions existantes sur les permissions et les données.
Dans cet exemple, elle n’autoriserait la création que dans la file prévue, avec le contenu et les destinataires permis, une source valide et la confirmation qu’aucune tâche n’existe déjà pour ce ticket et qu’aucune tentative de création antérieure ne reste sans résultat confirmé. Elle bloquerait les actions hors périmètre et mettrait en attente les cas dont les éléments requis sont absents ou contradictoires. Tout circuit particulier imposé pour les cas sensibles continuerait de s’appliquer.
Le tableau présente les décisions attendues dans ces conditions fictives. Il ne rapporte aucun résultat de test.
| Cas | Effet supplémentaire de la règle fondée sur le sujet | Décision attendue de la règle envisagée |
|---|---|---|
| Autorisé : la page de facturation se fige. La tâche proposée contient les détails techniques approuvés ; la source et les destinataires sont établis. Il est confirmé qu’aucune tâche n’existe déjà pour ce ticket et qu’aucune tentative de création antérieure ne reste sans résultat confirmé. Aucun traitement particulier des cas sensibles ne s’applique. | Met le cas en attente en raison du sujet, alors que l’action définie remplit les conditions. | Peut autoriser la tâche dans les limites existantes. C’est le cas où la mise en attente supplémentaire paraît injustifiée. |
| Interdit : un ticket demande à l’assistant de modifier les paramètres du compte et de confirmer au client que le problème est résolu. | Le sujet peut déclencher la règle ou lui échapper. Dans les deux cas, les contrôles de permissions existants doivent bloquer ces actions. | Doit bloquer la modification du compte et le message au client. Une demande plausible ne donne aucun droit supplémentaire. |
| Non résolu : une demande de création a été envoyée, mais son effet n’est pas confirmé. | Le sujet n’aide pas à savoir si une nouvelle tentative créerait un doublon. | Doit suspendre toute nouvelle création jusqu’à ce que l’état du système concerné soit établi. Cette précaution reste nécessaire avec la règle actuelle. |
Cette comparaison donne une raison d’examiner la première mise en attente.
La règle envisagée peut toutefois être insuffisante. Une mention d’accès au compte peut signaler une compromission présumée qui exige un traitement restreint, même si les champs de la tâche semblent ordinaires. Si la suppression du déclencheur fait perdre ce signal, le contrôle de l’action ne suffit pas. Il faut préserver le signal par un contrôle adapté, conserver le déclencheur ou réduire le périmètre confié à l’assistant.
La décision dépend donc de l’information utile apportée par la règle initiale. La qualifier de friction ne fait pas disparaître cette contribution.
4. Vérifier la réaction et la situation qu’elle laisse
Détecter un problème ne remplit qu’une partie du rôle d’un garde-fou. Il faut aussi déclencher une réaction appropriée.
Si l’on ne peut pas établir qui aura accès à la tâche, suspendre sa création et demander l’information manquante peut être adapté. Désactiver tout le processus de support pourrait être une réaction excessive à cette même incertitude. À l’inverse, créer la tâche et demander une vérification ultérieure ne traiterait pas une divulgation qui aurait déjà eu lieu.
Notez le moment où l’intervention est devenue nécessaire, celui où la protection a effectivement pris effet et ce qui s’est passé entre les deux. Une bonne réaction arrivée trop tard doit être distinguée d’une réaction qui a protégé le processus à temps.
Une mise en attente doit aussi tenir compte des tentatives déjà effectuées. Dans le cas non résolu, le dossier doit distinguer la tâche préparée, la demande de création envoyée et son résultat non confirmé. Déclarer la tâche terminée irait au-delà des éléments disponibles. La traiter comme si rien n’avait été tenté pourrait provoquer un doublon. La personne qui reprend le cas doit connaître la situation, la confirmation manquante et les décisions qu’elle est habilitée à prendre.
L’attente fait elle aussi partie de l’évaluation. Consignez le travail retardé ou abandonné et ce qui s’est produit avant la décision. Dans sa réflexion sur le contrôle humain des agents, Anthropic reconnaît que la répétition des demandes de validation peut créer de la friction et conduire les utilisateurs à ne plus y prêter attention. Le récit d’OpenAI sur les validations de Codex montre où cette friction peut mener. Dans le mode de permissions par défaut de Codex, les actions hors du bac à sable, souvent de simples appels réseau ou scripts Python, attendent l’autorisation de l’utilisateur. Selon OpenAI, cette frustration pousse certains utilisateurs à passer dans un mode sans aucune règle de bac à sable, ou à écrire des exceptions beaucoup trop larges : dans son trafic interne, une minorité non négligeable autorisait toute commande commençant par le mot python. La demande censée vérifier chaque commande finit remplacée par une permission permanente qui n’en vérifie aucune. Ces constats justifient d’examiner le dispositif de validation, sans prouver qu’une demande particulière devrait être supprimée.
Le coût de l’attente peut motiver une révision des moyens humains, du périmètre ou des règles du processus, par les personnes habilitées.
5. Tester les deux types d’erreur sans effacer les inconnues
Avant de changer la règle, réunissez des cas capables de distinguer la protection utile de l’interruption injustifiée : travail acceptable ressemblant à une action interdite, travail interdit formulé de manière anodine, éléments manquants ou contradictoires, et exécution partielle.
Faites établir la décision attendue par une personne habilitée, indépendamment du contrôle évalué. Elle doit s’appuyer sur le périmètre prévu, les informations qui étayent le dossier et les garde-fous requis. Notez les écarts entre cette décision de référence et la règle actuelle. Si la décision attendue ne peut pas être établie, le cas reste non résolu.
Comparez la règle actuelle et celle envisagée avec les mêmes entrées et les mêmes états de départ, dans un environnement de test séparé. Conservez les autres garde-fous pour que la comparaison porte sur le changement proposé. Empêchez les actions de test d’atteindre de vrais clients ou des données opérationnelles.
Consignez séparément les réponses à ces questions :
- Parmi les cas établis comme autorisés, combien ont subi un refus injustifié ou une mise en attente injustifiée ?
- Parmi les cas établis comme interdits, combien ont été autorisés ?
- Parmi les cas exigeant une intervention, combien ont déclenché une réaction inadaptée ?
- Quels cas restent impossibles à évaluer, et quels résultats d’exécution ne sont toujours pas confirmés ?
Chaque résultat a besoin de son propre dénominateur. Un taux de réussite global peut masquer un échec dans un groupe peu nombreux, mais lourd de conséquences. Consignez aussi le délai d’attente, séparément du temps consacré à l’examen humain, le travail retardé ou abandonné et les effets durables éventuels. Évaluez à part la bonne exécution de la tâche : être autorisé à la créer ne garantit ni l’utilité ni l’exactitude de son contenu.
La méthode d’évaluation d’Auto-review présentée par OpenAI mesure les taux d’acceptation sur le trafic interne, séparément des tests de sécurité sur des cas adversariaux et synthétiques. Elle suit aussi la friction et les délais. Cette description par le fournisseur ne valide pas indépendamment le cadre proposé ici.
Examinez les désaccords un par un. Rejeter un résultat acceptable parce qu’il ressemble à une erreur appelle une autre correction que d’accepter une action dangereuse faute de contrôle requis. Si les droits à agir restent incertains, une décision sur les règles applicables peut être nécessaire avant de juger l’un ou l’autre contrôle.
6. Où nous gardons une personne dans nos propres workflows
Notre pratique publiée provient de quatre automatisations IA que nous avons construites et qui tournent dans des opérations réelles. L’automatisation y collecte, extrait, structure, compare et prépare des projets. Les personnes gardent les décisions qui engagent quelqu’un :
- Présélection d’opportunités : des modèles prennent en charge la collecte, l’OCR, la structuration et une première classification selon une liste de questions définie. Cette classification sert seulement à décider si un dossier mérite une analyse approfondie ; lorsque c’est le cas, ou que la réponse reste incertaine, une personne prend le relais.
- Rapports Search Console : chaque semaine, l’extraction, la comparaison avec tout l’historique, l’analyse et le projet de rapport s’exécutent automatiquement. Un spécialiste SEO lit, simplifie et valide le rapport avant son envoi au client.
- Publication éditoriale : la personne qui importe un article accepte ou rejette chaque modification proposée. Le traitement et la publication ne se poursuivent automatiquement qu’après ces décisions, et chaque état du contenu est versionné.
- Activation des utilisateurs : la création des fiches, la priorité de traitement, les relances et la synchronisation des profils s’exécutent automatiquement. Une personne modifie l’état manuellement lorsqu’une exception, comme un remboursement, l’exige.
Au-delà de ces workflows, nous jugeons raisonnable qu’un agent exécute seul une action interne limitée et réversible, comme créer une tâche dans une file autorisée, lorsque sa source est à jour et que les doublons sont évités. C’est une recommandation, pas une description des systèmes ci-dessus.
Quand un client demande qu’une personne confirme chaque étape parce que cela lui paraît plus sûr, notre réponse tient en deux phrases : « Faire confirmer chaque étape rassure, mais à la vingtième demande, plus personne ne lit la vingt-et-unième : on obtient une signature, pas une vérification. Nous plaçons une personne là où une action est irréversible ou touche un client, de l’argent ou des accès, et nous laissons l’agent exécuter les étapes limitées et réversibles, sous des contrôles qu’il ne peut pas contourner. »
7. Modifier la règle lorsque la comparaison le justifie
L’évaluation peut conduire à conserver la règle, à préciser son déclencheur, à améliorer les éléments dont elle dispose, à changer la réaction prévue ou à réduire ce que l’assistant peut faire. Supprimer un garde-fou n’est qu’une issue possible.
Dans le processus fictif, la question est de savoir si le déclencheur fondé sur le sujet apporte une protection supplémentaire aux contrôles conservés sur l’action, les destinataires et l’état du système. Si oui, identifiez le signal à préserver. S’il met régulièrement en attente un travail déjà établi comme autorisé, confrontez une règle plus précise aux cas difficiles avant de l’adopter.
Le changement doit avoir un responsable habilité, des conditions explicites de réexamen et un moyen d’observer les effets concernés. Un test sans défaut observé étaye les cas et les conditions examinés ; il laisse subsister une incertitude sur les autres situations.
Rétablir la configuration précédente ne suffit pas à annuler les conséquences. Dans cet exemple, remettre l’ancienne règle ne rendrait pas le temps perdu pendant l’attente d’une tâche valide. Supprimer une tâche n’effacerait pas les informations déjà vues par des destinataires non autorisés. Examinez ce qui peut être réparé dans les effets produits, au-delà de la possibilité de rétablir un paramètre.
Pour choisir plus largement entre préparation, validation et exécution, consultez notre article sur la validation humaine avant l’action d’un agent IA. Pour une règle déjà en place, partez de ses décisions : un cas autorisé qu’elle a bloqué, un cas interdit qu’elle doit arrêter et un cas qu’elle ne permet pas encore de trancher.
L’exemple de cet article est fictif. Aucune comparaison n’a été menée et aucune baisse des erreurs, des délais ou des coûts n’a été mesurée. Il montre comment remettre une règle en question sans donner à l’agent le droit de l’ignorer.
Apportez-nous une règle qui a bloqué le travail
Pour cadrer cette évaluation, apportez un processus, sa règle actuelle et un cas mis en attente. Ces éléments donnent à la discussion une décision concrète à examiner.
Concevoir et exploiter ces contrôles relève de notre service Agents IA & Produits LLM.