Guardrails, permissions et human-in-the-loop

# 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 aucun frein. 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 de crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édit 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 : quoi autoriser, quand demander à un humain, et comment plafonner les dégâts.

Pourquoi les agents ont besoin de freins

Un chatbot ne fait que 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 guardrails permettent de conserver l'utilité tout en supprimant la catastrophe. Il y a trois outils principaux : les permissions (ce que l'agent *peut* faire), les approbations (quand un humain doit d'abord dire oui) et les limites (des plafonds durs qu'il ne peut pas dépasser).

Permissions : la tool allow-list

Le premier guardrail consiste à décider quels outils l'agent peut ne serait-ce que toucher. C'est la tool allow-list : une liste explicite des actions à sa disposition. Tout ce qui n'y figure pas n'existe simplement pas pour l'agent.

Voyez cela comme remettre 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 (transfère)

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 prend en charge tout ce qui est 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 →éversible.

Une habitude utile : classer chaque outil en lecture (sans risque, consulter des informations), é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 n'est pas un contrôle suffisant. *Cadrez-le*. Par exemple, restreignez l'outil pour qu'il ne puisse écrire qu'à des adresses du domaine de votre entreprise, ou ne répondre qu'aux fils que l'utilisateur a initiés. C'est l'outil lui-même qui applique la règle, donc l'agent ne peut 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 (envoyer ce remboursement).

2. Au lieu de le faire, 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 si vous faisiez le travail vous-même. N'approuvez que les actions irréversibles ou coûteuses. Laissez passer ce qui est sans risque.

Voici un croquis vendor-neutral de ce à quoi ressemble une porte d'approbation dans une boucle d'appels d'outils. La logique est la même que vous utilisiez l'OpenAI Agents SDK, le Claude Agent SDK ou l'ADK de Google :

# Outils qui exigent toujours l'approbation d'un humain avant exécution
NEEDS_APPROVAL = {"send_email", "issue_refund", "delete_record"}

def run_tool(name, args):
    if name in NEEDS_APPROVAL:
        # Mettre en pause et demander à 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)                 # renvoyer le résultat dans la boucle

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

Rendez les approbations faciles à examiner

Une demande d'approbation qui dit seulement « Approuver l'action ? » est inutile. L'humain ne peut pas juger. Montrez tout le détail :

> 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 : des 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 durs 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. 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 →êt après 15 actions sur une même tâche, pour qu'il ne boucle pas indéfiniment.
• Frontière de données. Il peut lire la base de données support mais jamais celle de la paie.

En pratique, un plafond de dépense est simplement 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 le contourner par l'argumentation. Aucun prompt astucieux ne fait monter le chiffre. C'est ce qui rend les limites plus solides que les instructions.

Les instructions ne sont pas des guardrails

Écrire « ne jamais dépenser plus de 100 $ » dans le system prompt est une *suggestion*, pas une garantie. Les modèles peuvent être perturbés, jailbreakés, ou simplement se tromper. Les vrais guardrails vivent dans le code et les outils qui entourent le modèle, là où il n'a pas voix au chapitre. Servez-vous du prompt pour orienter le comportement, mais faites appliquer les règles dures en dehors du modèle.

Pour un tour d'horizon solide et gratuit de la façon dont ces contrôles s'inscrivent dans un cadre de sécurité plus large, le NIST AI Risk Management Framework est lisible et vendor-neutral.

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 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 (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 →éversible)

Approbations :

• Remboursements inférieurs à 50 $ conformes à la politique : auto-approuvés, 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.
• 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 →ê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 agent de 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'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 à 30. Si une prompt injection (une instruction cachée placée dans un message client pour détourner l'agent) lui demandait de rembourser 10 000 $, le plafond quotidien la bloque et l'étape d'approbation l'attrape. Les couches se soutiennent 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 permettent à un agent de tourner en grande partie seul tout en rendant le désastre quasi impossible.

Régler les freins dans le temps

Commencez strict, puis relâchez. 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'auto-approbation. Celles que les humains modifient ou rejettent souvent restent sous contrôle.

Vous obtenez ainsi 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 manières spécifiques à chaque fournisseur de câbler ces contrôles (hooks d'approbation natifs, paramètres de permissions d'outils, fonctionnalités 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 tool allow-list. L'agent ne peut utiliser que les outils que vous accordez explicitement. Classez chaque outil en lecture, é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 →é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écuter. Montrez aux relecteurs tout le détail pour que l'approbation prenne quelques secondes.
• Appliquez les limites dures dans le code, pas dans le prompt. Plafonds de dépense, rate limits et budgets d'étapes 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 →ê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 relâchez avec des données. Contrôlez tout au lancement, puis auto-approuvez les actions que les humains valident toujours.