Garde-fous et politiques d'action

Pourquoi un agent a besoin d'une politique d'action

Un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire bien outillé sait appeler des fonctions, enchaîner des étapes, corriger sa trajectoire à partir des résultats qu'il observe. Rien dans cette description ne garantit qu'il sache s'arrêter au bon moment, ni qu'il distingue une action anodine d'une action qui engage réellement l'entreprise. Les chapitres précédents ont posé le mécanisme du function callingtool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire et la boucle de décision ; celui-ci pose la question qui conditionne le passage en production : que se passe-t-il quand l'agent se trompe, et qui peut l'arrêter avant que l'erreur ne devienne un incident ?

La réponse ne peut pas reposer sur la qualité du modèle. Un modèle plus performant réduit la fréquence des erreurs de raisonnement, il ne les élimine pas, et une instruction malveillante glissée dans un contenu externe peut détourner sa décision sans qu'aucune amélioration de capacité ne s'y oppose. La politique d'action est la couche qui reste vraie indépendamment du modèle utilisé aujourd'hui ou demain : elle définit, hors du jugement du modèle, ce qui est permis, ce qui exige un humain, et ce qui est interdit sans exception.

Demander au modèle, dans ses instructions système, de « ne jamais supprimer de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sans confirmation » n'est pas une politique d'action, c'est un vœu. Un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système peut être contourné par une injection, oublié après un long contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, ou simplement mal interprété. Une politique d'action réelle est appliquée par du code, en dehors du contrôle du modèle, avant que l'appel ne parte vers le système cible.

Modèle de menace : ce qui peut réellement mal tourner

Avant de choisir des mécanismes, il faut nommer précisément ce contre quoi ils protègent. Trois scénarios couvrent l'essentiel des incidents observés en production :

• L'erreur de raisonnement. Le modèle interprète mal une demande ambiguë et choisit une action plausible mais incorrecte — rembourser la mauvaise commande, annuler le mauvais abonnement. Aucune malveillance, une simple dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire de jugement amplifiée par l'exécution automatique.
• L'injection par contenu externe. Un document, un email ou une page web consultés par l'agent contiennent une instruction cachée qui détourne son comportement vers une action non voulue par l'utilisateur légitime.
• La dérive cumulative. Sur une longue chaîne d'itérations, chaque étape reste plausible, mais l'ensemble s'éloigne progressivement de l'objectif sans qu'aucun signal interne n'alerte le modèle de sa propre dérive.

Aucun de ces scénarios ne se résout par une meilleure formulation du prompt. Les trois se résolvent par des mécanismes externes au modèle : des limites qu'il ne peut pas franchir même s'il le « décide », et des points d'arrêt où un humain reprend la main avant qu'un effet irréversible ne se produise.

Allowlists : autoriser plutôt qu'interdire

Le premier réflexe consiste souvent à lister ce qu'un agent n'a pas le droit de faire — une liste noire. C'est une erreur d'architecture. Une liste noire suppose d'anticiper à l'avance toutes les actions dangereuses possibles, ce qui est structurellement impossible dès que le catalogue d'outils ou les paramètres qu'ils acceptent évoluent. Une allowlist inverse la logique : rien n'est permis par défaut, seul ce qui figure explicitement dans la liste peut s'exécuter. Tout nouvel outil, tout nouveau paramètre à risque, est automatiquement bloqué tant qu'il n'a pas été explicitement ajouté et évalué.

Une allowlist efficace ne se limite pas au nom de l'outil. Elle combine trois dimensions :

• L'outil lui-même — quelles fonctions sont exposées à cet agent, dans ce contexte précis.
• La portée des paramètres — un outil envoyer_email peut être autorisé, mais restreint à un domaine de destinataires interne, ou à un gabarit de message prédéfini plutôt qu'à un corps de texte libre.
• L'identité et le contexte de l'appelant — un agent interne opérant pour un employé authentifié peut avoir un périmètre plus large qu'un agent exposé directement à un utilisateur anonyme sur un site public.

Une allowlist n'a pas besoin d'être statique. Le catalogue d'outils réellement transmis au modèle à chaque appel peut varier selon l'identité de l'appelant, l'étape du parcours ou l'historique récent de l'agent. Un outil non transmis dans la déclaration de tools ne peut tout simplement pas être invoqué, ce qui constitue une barrière plus solide qu'une simple vérification a posteriori.

Niveaux de confirmation humaine

Toutes les actions ne méritent pas le même niveau de supervision. Exiger une confirmation pour chaque appel, y compris une simple recherche, tue l'intérêt de l'agent et pousse à valider machinalement sans lire — ce qui annule la protection. À l'inverse, n'en exiger aucune revient à parier que le modèle ne se trompera jamais sur ce qui compte. La bonne approche consiste à graduer la confirmation selon la gravité réelle de l'action.

Quatre niveaux couvrent la plupart des cas pratiques :

1. Exécution automatique sans notification — actions en lecture seule, sans effet de bord : consulter un statut, chercher une information.
2. Exécution automatique avec notification a posteriori — effet de bord réversible et de faible portée : mettre à jour une préférence, créer une note interne. L'humain peut annuler s'il le remarque.
3. Confirmation humaine préalable — effet significatif ou difficilement réversible : remboursement, modification de tarif, communication externe massive. L'agent prépare l'action et présente les paramètres exacts qu'un humain doit approuver.
4. Interdiction stricte — actions jamais déclenchables par un agent, quelle que soit la confirmation obtenue : permissions d'administration, suppression définitive en production, transfert au-delà d'un plafond réglementaire. Elles restent hors du périmètre par construction, pas par confiance dans la confirmation humaine.

Un bouton « confirmer » affiché sans le détail exact des paramètres de l'action pousse l'utilisateur à approuver un résumé vague plutôt que l'action réelle. La confirmation doit présenter les valeurs concrètes — montant exact, destinataire exact, identifiant exact — jamais une reformulation générique du type « voulez-vous continuer ? ». Une confirmation qu'on approuve sans lire n'est pas un garde-fou, c'est une formalité qui donne une fausse impression de sécurité.

Classer le risque d'une action : une grille pratique

Déterminer le bon niveau de confirmation suppose une grille de lecture stable, appliquée de la même façon à chaque outil du catalogue plutôt que décidée au cas par cas. Trois critères suffisent dans la grande majorité des contextes métier :

• Réversibilité. Une action peut-elle être annulée sans perte si elle s'avère incorrecte ? Une mise à jour de préférence se corrige en un appel ; un email envoyé à un client ne se rappelle pas.
• Portée. L'action affecte-t-elle une seule ressource identifiée, ou un ensemble (tous les comptes d'un segment) ? Une portée large mérite un niveau de confirmation supérieur même si chaque effet isolé semble mineur.
• Exposition financière ou réputationnelle. Un remboursement de 5 € et un remboursement de 5 000 € ne relèvent pas du même contrôle, alors qu'ils passent par le même outil. Le seuil doit être encodé dans la politique, pas laissé à l'appréciation du modèle au moment de l'appel.

Combiner ces trois critères donne une matrice simple : une action irréversible, à large portée et à forte exposition financière relève du niveau 4 (interdiction) ou, au minimum, du niveau 3 avec confirmation détaillée. Une action réversible, ciblée et sans exposition financière relève du niveau 1 ou 2. Les cas intermédiaires se traitent au cas par cas, mais la grille évite au moins d'oublier un critère.

Sandboxing et isolation des effets de bord

Un autre levier, complémentaire des allowlists et des confirmations, consiste à limiter physiquement ce qu'une action peut atteindre, indépendamment de toute décision applicative. C'est le principe du sandboxing : exécuter les actions de l'agent dans un environnement dont le rayon d'action est structurellement borné, de sorte qu'une erreur de raisonnement ne puisse pas se propager au-delà d'un périmètre connu à l'avance.

En pratique, cela prend plusieurs formes :

• Exécution de code — un agent qui génère et exécute du code doit tourner dans un conteneur isolé, sans accès réseau non nécessaire, sans accès au système de fichiers hôte, avec des quotas de CPU et de mémoire stricts.
• Accès aux données — un agent connecté à une base de données doit disposer d'un compte technique aux permissions restreintes (lecture seule quand c'est suffisant), jamais des identifiants d'un compte administrateur partagé.
• Environnement de test avant production — pour un nouvel outil, faire tourner l'agent contre une copie de staging avant de l'exposer à des systèmes réels permet d'observer son comportement sans risque.

Une allowlist protège contre les actions qu'on a explicitement anticipées. Le sandboxing protège aussi contre ce qu'on n'a pas anticipé — un comportement émergent, une combinaison d'appels imprévue — en limitant la portée maximale de n'importe quelle action, même une action légitime au regard de la politique.

Rate limiting, budgets et kill switch

Au-delà de la nature de chaque action prise isolément, la fréquence et le volume des actions constituent un risque à part entière. Un agent qui exécute une action légitime cent fois en boucle, à cause d'une dérive de raisonnement, peut causer un dommage disproportionné même si chaque appel respecte la politique.

Trois mécanismes complémentaires bornent ce risque :

• Rate limiting — un plafond sur le nombre d'appels d'un même outil, par unité de temps et par identité d'appelant.
• Budget d'itérations et de tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire — une limite sur le nombre de cycles décision-action qu'un agent peut enchaîner avant d'être forcé à s'arrêter ou à escalader vers un humain.
• Kill switch — un mécanisme d'arrêt immédiat, accessible à un opérateur à tout moment, qui interrompt l'exécution en cours sans attendre la fin du cycle courant. Comme une sauvegarde jamais restaurée, un kill switch jamais déclenché en conditions réelles est un kill switch dont personne ne sait s'il fonctionne : un exercice périodique, où un opérateur déclenche l'arrêt sur un agent en exécution réelle ou en environnement représentatif, doit vérifier que l'interruption est effective et rapide.

Journalisation et audit

Aucun des mécanismes précédents n'a de valeur durable sans une trace exploitable de ce qui s'est réellement passé. Chaque décision de la politique — refus par l'allowlist, exécution automatique, confirmation demandée, accordée ou refusée — doit être journalisée avec l'identité de l'appelant, l'horodatage, les paramètres exacts et l'issue.

Cette journalisation sert deux fonctions. En temps réel, elle permet de détecter une dérive en cours — un volume d'appels anormal, une série de refus qui signale une tentative répétée d'action hors périmètre. A posteriori, elle permet de reconstituer la chaîne de décisions ayant conduit à un incident, sans dépendre du seul historique de conversation visible par l'utilisateur, qui peut être tronqué ou résumé.

Cas concret : agent de support avec accès CRM

Un agent traite les demandes entrantes avec accès à un CRM. Sa politique combine les mécanismes du chapitre : l'allowlist expose consulter_client, consulter_commande et creer_note_interne en exécution automatique (niveau 1-2, actions réversibles, sans exposition financière) ; emettre_remboursement est plafonné à 50 € en exécution automatique avec notification, et exige une confirmation humaine au-delà (niveau 3, la portée financière change le risque) ; supprimer_compte_client n'apparaît pas dans le catalogue exposé (niveau 4, interdiction par absence de l'outil). Un rate limit de dix appels d'écriture par conversation empêche une dérive de produire un volume de remboursements anormal, et chaque décision — y compris les refus — est journalisée avec l'identifiant du ticket.

Ce découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire illustre le principe central du chapitre : la sévérité de la conséquence détermine le mécanisme, pas la confiance qu'on accorde au modèle à un instant donné.

Anti-patterns fréquents

• Tout confirmer. Fait perdre l'intérêt de l'automatisation et pousse à l'approbation machinale, qui annule la protection.
• Confier la politique au prompt système. Une instruction en langage naturel reste contournable par injection ou dérive de longue conversation ; elle doit être doublée d'une vérification côté code.
• Une allowlist statique jamais revue. Un catalogue d'outils évolue ; une allowlist non mise à jour finit soit par bloquer des usages légitimes, soit par exposer un nouvel outil sans classification de risque.
• Confondre journalisation et supervision. Journaliser sans jamais consulter les journaux ni définir de seuils d'alerte revient à collecter une preuve après coup sans jamais prévenir l'incident.
• Kill switch jamais testé. Un mécanisme non exercé en conditions réelles a de bonnes chances de ne pas fonctionner le jour où il devient nécessaire.

Checklist avant déploiement

• L'allowlist couvre l'outil, la portée des paramètres, l'identité de l'appelant et le contexte — pas seulement le nom de la fonction.
• Chaque outil est classé selon réversibilité, portée et exposition financière, avec un niveau de confirmation explicite.
• Les actions de niveau 4 (interdiction) sont absentes du catalogue exposé, pas simplement déconseillées dans le prompt.
• Les écrans de confirmation affichent les paramètres exacts de l'action, jamais un résumé générique.
• Un rate limit et un budget d'itérations sont fixés, avec un comportement défini en cas de dépassement.
• Un kill switch existe et a été testé en conditions représentatives au cours des derniers mois.
• Chaque décision — refus, exécution automatique, confirmation demandée ou accordée — est journalisée avec l'identité de l'appelant.
• La politique est revue à chaque ajout d'outil au catalogue, pas seulement au lancement du projet.

Ce qu'il faut retenir

Une politique d'action ne cherche pas à rendre un agent infaillible — aucun mécanisme ne le peut. Elle garantit que, lorsque l'agent se trompe, l'erreur reste contenue dans un périmètre connu à l'avance : une allowlist qui bloque ce qui n'a pas été explicitement autorisé, une confirmation proportionnée à la gravité de l'action, un sandboxing qui borne les effets même imprévus, un rate limiting et un kill switch qui bornent l'ampleur d'une dérive, une journalisation qui rend chaque décision reconstituable après coup. Aucun de ces mécanismes n'est optionnel dès qu'un agent touche à des systèmes réels — c'est leur combinaison, pas la qualité du modèle, qui détermine si un système d'agents est déployable en production.