Les garde-fous des agents IA doivent limiter leurs actions et permettre de comprendre ce qui se passe lorsqu’une situation sort du cadre. Une consigne générale de prudence ne suffit pas à encadrer un système capable de lire des dossiers, d’envoyer un message ou de modifier une information. Avant la production, l’organisation doit traduire ses règles en permissions, en seuils de validation et en scénarios de test.
À retenir
- Un garde-fou utile correspond à une limite précise dont on peut vérifier le fonctionnement.
- Les permissions réelles doivent refléter les actions autorisées dans le mandat.
- Une escalade demande un destinataire, une information suffisante et un comportement sûr en attendant la réponse.
- Le mécanisme d’arrêt doit être testé, avec une procédure de reprise adaptée.
- Les contrôles doivent être revus lorsque les accès, les tâches ou les fournisseurs changent.
Un besoin reconnu, des règles encore incomplètes
Une enquête menée en mars 2026 par Harvard Business Review Analytic Services, avec le soutien d’Appian, a interrogé 385 décideurs d’organisations explorant, testant ou utilisant l’IA. Le communiqué du 29 avril rapporte que 92 % des répondants jugent nécessaires des garde-fous fondés sur des règles pour les agents. Le chiffre de 48 % concernant des règles définies porte sur les organisations utilisant, considérant ou explorant l’IA agentique. Les bases étant formulées différemment, on ne doit pas transformer mécaniquement ces chiffres en un écart mesuré de 44 points pour une même population. Communiqué et méthode de l’enquête.
Pour une organisation, la question pratique est de savoir ce que ses propres règles empêchent ou permettent réellement. Une politique peut affirmer que les décisions sensibles nécessitent une validation, tandis que la configuration technique autorise déjà l’action. Cette incohérence doit être repérée avant le lancement. Le contrôle devient utile lorsqu’il est relié à une action et à une conséquence compréhensibles.
Définir les garde-fous des agents IA par action
Commencez par décomposer le travail de l’agent. Consulter un dossier, proposer une modification, enregistrer cette modification et la communiquer sont des actions distinctes. Pour chacune, indiquez les données nécessaires, les autorisations, les limites et les validations. Cette décomposition évite qu’un accès accordé pour une petite tâche ouvre implicitement un ensemble beaucoup plus large d’opérations.
Les restrictions doivent être appliquées au niveau approprié. Une instruction peut expliquer ce que l’agent doit faire, mais les permissions du système doivent aussi limiter ce qu’il peut exécuter. Lorsqu’une action dépasse le mandat, le dispositif devrait empêcher son exécution ou exiger la validation prévue. La configuration doit être examinée par les personnes compétentes pour les systèmes concernés.
Les limites peuvent porter sur un montant, un type de destinataire, une catégorie de données ou un ensemble de dossiers. Leur choix dépend du contexte. Un seuil arbitraire peut laisser passer une action dommageable ou bloquer inutilement le travail. Il faut donc relier chaque limite aux conséquences possibles et documenter la raison de son adoption.
Tester le cas normal et les exceptions
Un scénario de démonstration montre généralement le parcours attendu. La préparation à la production doit aussi examiner les situations où l’information manque, se contredit ou ne correspond pas au mandat. Les essais utilisent des données fictives ou un environnement approprié, afin de ne pas provoquer d’actions réelles indésirables. Chaque cas doit préciser le comportement attendu et la preuve à conserver.
| Scénario | Comportement attendu à définir |
|---|---|
| Dossier complet et autorisé | Réaliser uniquement les actions prévues |
| Information manquante | Demander une précision ou transmettre le dossier |
| Deux personnes aux noms semblables | Éviter de choisir un dossier sans vérification suffisante |
| Action hors mandat | Refuser ou déclencher une validation appropriée |
| Instruction trouvée dans un document externe | La traiter comme un contenu, sans lui donner autorité sur les règles |
| Service indisponible | Signaler l’échec et éviter les doublons d’action |
| Arrêt demandé | Suspendre les actions selon le mécanisme prévu |
Le cas des instructions externes mérite une attention particulière. Un agent peut lire un document contenant une demande qui ressemble à une consigne. L’organisation doit vérifier que ce contenu ne lui permet pas de modifier son mandat ou d’envoyer des informations à un autre destinataire. Le test doit être conçu et réalisé par des personnes autorisées, dans un cadre adapté.
Rendre l’escalade utilisable
Une règle disant « demander à un humain » laisse plusieurs questions ouvertes. Quelle personne reçoit la demande? Dans quel délai? Que voit-elle? Peut-elle modifier la proposition ou seulement l’accepter? Que fait le système en attendant? Sans ces réponses, l’escalade peut devenir une file d’attente ou pousser les employés à approuver rapidement pour débloquer le travail.
Le dossier transmis devrait expliquer l’action proposée, les données utilisées, la difficulté rencontrée et les conséquences possibles. Le responsable doit disposer d’assez de contexte pour exercer un jugement. Pour un cas sensible, un simple bouton vert ne fournit pas nécessairement cette capacité. La charge de validation des gestionnaires doit être estimée avant d’élargir le volume des demandes.
Il faut aussi prévoir l’absence de la personne habituelle. Un remplacement, un délai maximal et un comportement d’attente peuvent être définis selon l’usage. L’urgence ne devrait pas créer automatiquement de nouveaux pouvoirs pour l’agent. Les exceptions autorisées doivent elles-mêmes avoir un cadre et laisser une trace exploitable.
Prévoir l’arrêt et la reprise
Le mécanisme d’arrêt doit permettre aux personnes autorisées de suspendre les actions lorsque le fonctionnement devient incertain. Il faut connaître sa portée : une tâche en cours s’arrête-t-elle immédiatement, les nouvelles tâches sont-elles bloquées, des actions déjà envoyées peuvent-elles encore aboutir? Ces détails dépendent du système et doivent être vérifiés dans l’environnement réel.
La reprise demande également une décision. Réactiver l’agent sans comprendre l’incident peut reproduire le problème. Le responsable doit examiner les actions effectuées, corriger la cause connue et déterminer quels essais reprendre. Une procédure courte peut préciser qui autorise la remise en service et quelles informations doivent être conservées. Elle doit correspondre aux moyens de l’organisation.
Un exercice fictif peut aider à tester ce dispositif : l’agent prépare plusieurs réponses, puis une erreur de destinataire est détectée avant l’envoi. L’équipe vérifie la suspension, identifie les tâches touchées et détermine ce qui peut reprendre. Le résultat de l’exercice doit décrire les délais et les difficultés observés, sans prétendre couvrir tous les incidents possibles.
Conserver des traces utiles et proportionnées
Les journaux devraient permettre de comprendre les actions, les validations et les erreurs importantes. Il faut toutefois éviter de conserver sans nécessité des renseignements personnels ou des contenus sensibles. Les accès aux traces, leur durée de conservation et leur utilisation doivent être définis selon le contexte. Un volume élevé de données n’aide pas si personne ne peut retrouver le parcours pertinent.
Le registre de gouvernance des agents IA peut renvoyer à ces éléments : responsable, systèmes concernés, contrôles et dernière vérification. Il permet de repérer les dépendances lors d’un changement. Les avis des fournisseurs doivent aussi alimenter la revue lorsqu’une permission, une fonction ou un comportement évolue.
Le NIST propose un cadre volontaire de gestion des risques de l’IA et un profil consacré à l’IA générative. Ils peuvent aider à structurer l’identification, la mesure et le suivi des risques, sans constituer une certification du projet ni remplacer les obligations applicables. Cadre NIST AI RMF et profil sur l’IA générative, juillet 2024.
Questions fréquentes
Une bonne consigne suffit-elle comme garde-fou?
Une consigne contribue à définir le comportement attendu, mais les permissions et les contrôles doivent aussi correspondre au mandat. Les actions importantes doivent être encadrées au niveau du système lorsque c’est nécessaire. Les essais vérifient ensuite que la limite fonctionne dans les situations prévues et les exceptions pertinentes.
Que faut-il tester avant le premier déploiement?
Testez le parcours normal, une information manquante, une demande hors mandat, une erreur possible de dossier et le mécanisme d’arrêt. Ajoutez les scénarios propres aux conséquences de votre usage. Conservez le comportement attendu, le résultat observé et les corrections nécessaires avant la mise en service.
Quand revoir les garde-fous après le lancement?
Une révision est pertinente lors d’un changement de tâche, d’accès, de données ou de fournisseur, après un incident et selon une cadence définie. Un agent autorisé pour un périmètre limité ne doit pas recevoir automatiquement de nouveaux pouvoirs sans examen des contrôles concernés.
