Guardrails, permissions et human-in-the-loop

En 2024, le chatbot d'un concessionnaire automobile s'est laissé convaincre de vendre un pick-up pour un dollar. C'était « juridiquement contraignant », a plaisanté le client en faisant une capture d'écran de la réponse. Le bot n'avait pas de freins. **Il pouvait dire n'importe quoi, et (dans une version plus dangereuse) il aurait pu *faire* n'importe quoi.**

Imaginez maintenant ce même agent connecté à votre messagerie, votre agenda et la carte bancaire de l'entreprise. Un agent capable d'agir dans le monde réel a besoin de limites qu'il ne peut pas franchir. Cette leçon porte sur ces limites : ce qu'on autorise, quand demander à un humain, et comment plafonner les dégâts.

Pourquoi les agents ont besoin de freins

Un chatbot se contente de parler. Un agent (une IA capable d'agir via des outils, comme envoyer un email ou appeler une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →) fait réellement des choses. C'est tout l'intérêt, et tout le risque.

Trois modes de défaillance reviennent en permanence :

• Mauvaise action. L'agent rembourse 5 000 $ au lieu de 50 $.
• Bonne action, mauvaise cible. Il envoie le brouillon à toute l'entreprise au lieu d'une seule personne.
• Boucles incontrôlées. Il retente une tâche en échec 400 fois, chaque tentative coûtant de l'argent.

Les guardrailsguardrailsRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → permettent de garder l'utilité en supprimant la catastrophe. Il existe trois outils principaux : les permissions (ce que l'agent *peut* faire), les approbations (quand un humain doit valider au préalable) et les limites (des plafonds stricts qu'il ne peut pas dépasser).

Permissions : l'allow-list d'outils

Le premier guardrail consiste à décider quels outils l'agent peut seulement toucher. C'est l'allow-list d'outils : une liste explicite des actions dont il dispose. Tout ce qui n'y figure pas n'existe tout simplement pas pour l'agent.

Voyez cela comme donner un badge à un nouveau stagiaire. Vous ne lui donnez pas accès à toutes les pièces du bâtiment. Vous lui donnez les trois portes dont il a besoin.

Un agent de support pourrait obtenir :

• search_knowledge_base (lecture seule, sans risque)
• create_draft_reply (produit du texte, n'envoie rien)
• escalate_to_human (transmet)

Remarquez ce qui n'y est *pas* : pas de send_email, pas de issue_refund, pas de delete_account. L'agent peut préparer le travail, mais une personne ou un système plus strict traite tout ce qui est irréversible.

Une habitude utile : classez chaque outil en lecture (sans risque, consultation), écriture (modifie quelque chose, plus risqué) et irréversible (dépense de l'argent, envoie des messages, supprime des données). Les outils de lecture peuvent généralement s'exécuter librement. Les outils d'écriture et irrirrLe taux de rendement interne est le taux d'actualisation qui annule la valeur actuelle nette d'un projet. Il exprime le rendement annualisé attendu d'un investissement.Voir la définition complète →éversibles méritent une vigilance supplémentaire.

Cadrez l'outil, pas seulement son nom

Donner à un agent un outil send_email ne suffit pas comme contrôle. *Cadrez-le*. Par exemple, restreignez l'outil pour qu'il ne puisse écrire qu'à des adresses du domaine de votre entreprise, ou répondre uniquement aux fils que l'utilisateur a lui-même ouverts. C'est l'outil qui applique la règle, l'agent ne peut donc pas l'enfreindre quoi qu'il « décide ».

Human-in-the-loop : l'étape d'approbation

Pour les actions risquées, le frein le plus sûr reste un humain. Human-in-the-loop (souvent abrégé HITL) signifie que l'agent s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →ête avant une action sensible et attend qu'une personne approuve ou rejette.

Le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → est simple :

1. L'agent décide qu'il veut effectuer une action (émettre ce remboursement).
2. Au lieu de l'exécuter, l'agent la *propose* et se met en pause.
3. Un humain voit la proposition et clique sur approuver ou rejeter.
4. L'action ne s'exécute qu'après approbation.

Vous n'avez pas besoin d'approbation sur tout. L'agent serait alors aussi lent que de faire le travail vous-même. N'approuvez que les actions irréversibles ou coûteuses. Laissez passer le reste.

Voici un schéma indépendant de tout fournisseur de ce à quoi ressemble une porte d'approbation dans une boucle d'appel d'outils. La logique est la même que vous utilisiez l'OpenAI Agents SDK, le Claude Agent SDK ou l'ADK de Google :

# Tools that always require a human to approve before running
NEEDS_APPROVAL = {"send_email", "issue_refund", "delete_record"}

def run_tool(name, args):
    if name in NEEDS_APPROVAL:
        # Pause et demande à une personne
        if not human_approves(name, args):
            return {"status": "rejected", "reason": "Human declined."}
    return execute(name, args)

# La boucle de l'agent
while not done:
    action = agent.next_action()          # le modèle propose un appel d'outil
    result = run_tool(action.name, action.args)
    agent.observe(result)                 # réinjecte le résultat

L'idée clé : le modèle *propose*, votre code *décide* de l'exécuter ou non. L'agent n'a jamais directement la main sur le bouton dangereux.

Rendez les approbations faciles à examiner

Une demande d'approbation qui se contente de dire « Approuver l'action ? » ne sert à rien. L'humain ne peut pas juger. Affichez le détail complet :

L'agent veut envoyer un email À : jane@acme.com Objet : Votre remboursement de 50,00 $ Corps : Bonjour Jane, nous avons traité votre remboursement... [Approuver] [Rejeter] [Modifier]

Donnez au relecteur assez de contexte pour repérer une erreur en deux secondes. Une option « Modifier » est un plus : l'humain corrige le montant de 500 $ à 50 $ puis approuve.

Limites : les plafonds que l'agent ne peut pas franchir

Les approbations reposent sur l'attention d'un humain. Les limites fonctionnent même quand personne ne regarde. Ce sont des plafonds stricts appliqués par votre code, pas par le jugement du modèle.

Limites courantes :

• Plafond de dépense. L'agent peut dépenser au maximum 100 $ par jour. La 101e tentative échoue automatiquement.
• Rate limit. Pas plus de 20 emails par heure, pour éviter qu'une boucle incontrôlée ne spamme.
• Budget d'étapes. Arrêt après 15 actions sur une même tâche, pour qu'il ne boucle pas indéfiniment.
• Périmètre de données. Il peut lire la base support mais jamais la base paie.

En pratique, un plafond de dépense n'est qu'un cumul que votre code vérifie avant chaque dépense :

DAILY_CAP = 100.00

def issue_refund(amount):
    if spent_today() + amount > DAILY_CAP:
        return {"status": "blocked", "reason": "Daily cap reached."}
    charge(amount)
    return {"status": "ok"}

Comme cela s'exécute dans votre code, l'agent ne peut pas s'en sortir par l'argumentation. Aucun prompt astucieux ne fait monter le chiffre. C'est ce qui rend les limites plus fortes que les instructions.

Les instructions ne sont pas des guardrails

Écrire « ne jamais dépenser plus de 100 $ » dans le system promptsystem promptLes instructions cachées qui définissent le comportement d'un assistant IA avant toute question : son rôle, son ton, ses limites et ses règles.Voir la définition complète → est une *suggestion*, pas une garantie. Les modèles peuvent être induits en erreur, jailbreakés, ou simplement se tromper. Les vrais guardrails vivent dans le code et les outils environnants, là où le modèle n'a pas voix au chapitre. Servez-vous du prompt pour orienter le comportement, mais appliquez les règles strictes en dehors du modèle.

Pour un panorama solide et gratuit de la place de ces contrôles dans un cadre de sécurité plus large, le NIST AI Risk Management Framework est lisible et indépendant de tout fournisseur.

Mise en pratique : un agent de remboursement

Concevons un agent réaliste et superposons les trois guardrails.

Mission : traiter les demandes de remboursement clients dans une boîte de réception support.

Permissions (allow-list) :

• look_up_order (lecture, sans risque)
• check_refund_policy (lecture, sans risque)
• draft_refund (écriture, prépare mais n'exécute pas)
• issue_refund (irréversible)

Approbations :

• Remboursements inférieurs à 50 $ conformes à la politique : approbation automatique, l'agent les exécute.
• Remboursements de 50 $ et plus, ou tout ce qui sort de la politique : mis en pause pour un humain.

Limites :

• Plafond quotidien de 2 000 $ tous remboursements confondus.
• 30 actions de remboursement maximum par heure.
• Arrêt et escalade après 10 étapes sur un même dossier.

Suivons maintenant une demande. Un client veut récupérer 200 $ pour une commande en retard. L'agent consulte la commande (sans risque), vérifie la politique (sans risque) et prépare le remboursement. Comme 200 $ dépasse le seuil de 50 $, il se met en pause. Un conseiller support voit la proposition complète, confirme que la commande était bien en retard et clique sur approuver. Le remboursement s'exécute et s'impute sur le plafond quotidien de 2 000 $.

Si un bug amenait l'agent à tenter 50 remboursements en une minute, le rate limit l'arrête à 30. Si une prompt injection (une instruction cachée glissée dans un message client pour détourner l'agent) lui demandait de rembourser 10 000 $, le plafond quotidien bloque et l'étape d'approbation intercepte. Les couches se couvrent mutuellement.

Cette superposition est la vraie leçon. Aucun guardrail seul ne suffit. Les permissions réduisent le champ du possible, les approbations rattrapent les erreurs de jugement, et les limites plafonnent le pire scénario. Ensemble, elles laissent un agent fonctionner en grande partie seul tout en rendant le désastre quasi impossible.

Régler les freins dans la durée

Commencez strict, puis desserrez. Lancez avec une approbation sur presque tout. Observez les propositions pendant une semaine. Les actions que les humains approuvent systématiquement sans modification sont candidates à l'approbation automatique. Celles qu'ils modifient ou rejettent souvent restent sous contrôle.

Cela vous donne des données plutôt que des suppositions. Vous apprenez *où* l'agent est fiable et vous le laissez agir librement à cet endroit, tout en gardant un humain sur les décisions réellement risquées.

Pour les façons spécifiques à chaque fournisseur de câbler ces contrôles (hooks d'approbation natifs, réglages de permissions d'outils, fonctions de budget), voyez les blocs d'approfondissement sur l'OpenAI Agents SDK, le Claude Agent SDK et l'ADK de Google. Les concepts présentés ici se transposent directement ; seule la syntaxe change.

Points clés

• Utilisez une allow-list d'outils. L'agent ne peut utiliser que les outils que vous accordez explicitement. Classez chaque outil en lecture, écriture et irréversible, et cadrez étroitement les plus risqués.
• Mettez un humain dans la boucle pour les actions irréversibles ou coûteuses. Le modèle propose, votre code décide de l'exécution. Affichez tout le détail aux relecteurs pour que l'approbation prenne quelques secondes.
• Appliquez les limites strictes dans le code, pas dans le prompt. Plafonds de dépense, rate limits et budgets d'étapes arrêtent les boucles incontrôlées et les jailbreaks même quand personne ne regarde.
• Superposez les guardrails. Permissions, approbations et limites rattrapent chacune ce que les autres laissent passer. Aucun frein seul ne suffit.
• Commencez strict et desserrez avec les données. Verrouillez tout au lancement, puis passez en approbation automatique les actions que les humains valident toujours.