Guardrails : permissions, review et coûts

Un agent capable d'envoyer un email, de merger une pull request ou de déplacer de l'argent n'est sûr que dans la mesure des barrières que vous placez devant ces actions. Le modèle ne se contente plus de générer du texte. Il agit, et une hallucination énoncée avec assurance devient une conséquence réelle. Cette leçon porte sur la couche de contrôle : décider ce qu'un agent peut toucher, quand un humain doit approuver, ce qui ne doit jamais tourner sans supervision, et comment empêcher une boucle folle de consommer votre budget.

Les trois modes de défaillance contre lesquels vous vous protégez

Chaque guardrailguardrailRè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 → que vous construisez correspond à l'un d'eux :

1. Mauvaise action exécutée. L'agent fait quelque chose qu'il ne devrait pas (supprime un enregistrement, envoie un email au mauvais client).
2. Bonne action, mauvais périmètre. L'agent fait la bonne chose mais avec une portée trop large (rembourse la commande entière au lieu d'une seule ligne).
3. Coût qui s'emballe. Une boucle, une avalanche de retries, ou un output d'outil énorme qui revient dans le contexte et fait exploser votre facture de tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète →.

Les permissions traitent les points 1 et 2. La review humaine intercepte la frange à fort enjeu des deux. Les contrôles de coût gèrent le point 3. Traitez-les comme des systèmes distincts, pas comme une grosse instruction « sois prudent ».

Permissions : cadrez les outils, pas le prompt

La plus grande erreur consiste à mettre la sécurité dans le prompt (« ne supprime jamais rien sans demander »). Les prompts sont des suggestions. Les permissions vivent dans le code et la configuration, là où le modèle ne peut pas les contourner par la parole.

Dans ChatGPT (le produit)

Quand vous construisez avec des Custom GPTs et des GPT Actions, vous définissez précisément quels endpoints d'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 → l'action peut appeler via 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 → OpenAPI. Le GPT ne peut pas appeler un endpoint que vous n'avez pas exposé. Utilisez OAuth dans la configuration d'auth de l'action pour que chaque utilisateur agisse avec ses propres permissions, et non avec une clé partagée. Voir la documentation Actions pour le flux d'authentification.

Les connectors (Google Drive, SharePoint, GitHub et autres) héritent des permissions du compte connecté. Si vous connectez un compte de service en lecture seule, l'agent obtient un accès en lecture seule. Provisionnez le compte sous-jacent avec le moindre privilège avant de le connecter.

L'agent ChatGPT navigue, exécute du code et utilise les connectors dans un environnement sandboxé, et il s'interrompt pour demander confirmation avant les étapes conséquentes comme soumettre un formulaire ou effectuer un achat. Considérez cette confirmation intégrée comme le plancher, pas comme votre stratégie complète.

Dans l'API (où vous contrôlez tout)

Avec la Responses API et l'Agents SDK, les permissions ne sont que du code autour de vos fonctions d'outil. Le modèle propose un appel ; votre code décide de l'honorer ou non.

ALLOWED_REFUND_CEILING = 100_00  # cents

def issue_refund(order_id: str, amount_cents: int) -> dict:
    if amount_cents > ALLOWED_REFUND_CEILING:
        return {
            "status": "needs_review",
            "reason": f"Amount {amount_cents} exceeds auto-approve ceiling",
        }
    result = payments.refund(order_id, amount_cents)
    return {"status": "done", "refund_id": result.id}

Le modèle ne voit jamais les identifiants de paiement et ne peut pas relever le plafond. La règle est appliquée là où ça compte.

La review gate : un exemple concret

Voici le pattern annoncé : un agent rédige une action, mais un humain l'approuve avant exécution. C'est un outil en deux phases. La phase une retourne une proposition. Un humain (ou une étape d'approbation distincte) confirme. La phase deux valide.

Imaginez un agent de support qui traite les demandes de remboursement. Vous voulez qu'il fasse le travail fastidieux (retrouver la commande, lire la politique, préparer le remboursement) mais qu'il ne déplace jamais d'argent tout seul au-delà d'un seuil.

from openai import OpenAI
client = OpenAI()

PENDING = {}  # en production, utilisez un vrai datastore

def propose_refund(order_id: str, amount_cents: int, reason: str) -> dict:
    token = f"refund_{order_id}"
    PENDING[token] = {"order_id": order_id, "amount_cents": amount_cents}
    return {
        "status": "awaiting_approval",
        "approval_token": token,
        "summary": f"Refund ${amount_cents/100:.2f} on {order_id}: {reason}",
    }

def commit_refund(approval_token: str) -> dict:
    job = PENDING.pop(approval_token, None)
    if not job:
        return {"status": "error", "reason": "unknown or already-used token"}
    receipt = payments.refund(job["order_id"], job["amount_cents"])
    return {"status": "done", "refund_id": receipt.id}

L'agent peut appeler propose_refund librement. Il ne peut physiquement pas appeler commit_refund sans un token valide, et ce token n'apparaît dans votre système qu'après qu'un humain a cliqué sur approuver. Le travail du modèle 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 à « voici ce que je veux faire ». Une personne est propriétaire du « oui ».

C'est le modèle mental de toute automatisation à fort enjeu : proposé par l'IA, validé par l'humain, l'étape de validation étant verrouillée derrière un token que le modèle ne peut pas falsifier.

Où placer l'humain

Toutes les actions ne méritent pas la même barrière. Classez vos outils en trois catégories :

• Auto : lecture seule ou trivialement réversible (retrouver une commande, rédiger un texte, chercher dans des documents). Aucune barrière.
• Review : conséquent mais routinier (envoyer un email client, 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 →éererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète → un ticket, rembourser sous un plafond). Un humain approuve, idéalement par lot.
• Jamais sans supervision : 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 ou à large rayon d'impact (supprimer des données de production, virer de l'argent au-delà d'une limite, publier pour tous les utilisateurs, modifier des permissions). Toujours une personne, toujours journalisé.

Rendez ces catégories explicites dans votre document de conception. « Dans quelle catégorie est cet outil ? » est la première question à poser pour toute nouvelle capacité que vous ajoutez.

Ce qu'il ne faut jamais automatiser sans supervision

Quelques catégories relèvent de la troisième, aussi bon que soit votre agent :

• Suppressions irréversibles de données client ou de production.
• Transactions financières sortantes au-delà d'une limite faible et fixe.
• Changements d'identité et d'accès (attribution de rôles, rotation des identifiants d'un tiers, modification des paramètres de partage).
• Communication publique ou de masse (publier publiquement, écrire à une liste entière, tout ce qui ne peut pas être annulé).
• Engagements juridiques ou de conformité (signer, accepter des conditions, dépôts réglementaires).

Le test : *si l'agent se trompe une seule fois là-dessus, puis-je revenir en arrière avant que quiconque en subisse le préjudice ?* Si la réponse est non, un humain valide. Les tâches planifiées rendent cela plus aigu, car une scheduled task dans ChatGPT s'exécute pendant que vous ne regardez pas. Tout ce qui est planifié doit produire un brouillon ou une notification, pas déclencher une action irréversible dans le vide.

Garder les coûts sous contrôle

Les agents bouclent. C'est leur force et leur risque financier. Un seul run qui dérape peut appeler un outil cinquante fois, réinjecter chaque résultat surdimensionné dans le contexte et gonfler discrètement une facture bien plus lourde qu'une conversation normale. Le contrôle des coûts est un guardrail, pas une réflexion d'après-coup.

Plafonnez la boucle

La limite la plus importante est le nombre maximal d'étapes qu'un agent peut effectuer. Dans l'Agents SDK, vous fixez une limite de tours pour qu'un agent bloqué s'arrête au lieu de tourner indéfiniment.

from agents import Agent, Runner

agent = Agent(name="support", instructions=SYSTEM_PROMPT, tools=[propose_refund])

result = Runner.run_sync(agent, "Refund order 8842, item was defective", max_turns=8)

Si l'agent ne peut pas terminer en huit tours, il s'arrête. Ce seul paramètre fait la différence entre une tâche bornée et une boucle qui s'emballe.

Contrôlez ce qui revient dans le contexte

Le coût en tokens s'accumule parce que chaque résultat d'outil est ajouté au contexte et renvoyé à l'appel suivant. Un dump d'API de 20 000 tokens dont le modèle n'avait besoin que d'un seul champ vous coûtera à chaque tour suivant. Tronquez et résumez les outputs d'outils avant de les retourner.

def search_logs(query: str) -> dict:
    rows = db.search(query, limit=2000)
    return {"matched": len(rows), "top": rows[:5]}  # pas les 2000

Retournez le décompte et un échantillon, pas la botte de foin entière. Le modèle a rarement besoin du dump brut, et votre portefeuille certainement pas.

Dimensionnez le modèle et utilisez les leviers peu coûteux

Vous n'avez pas besoin de votre modèle le plus performant à chaque étape. Router la classification et l'extraction vers un modèle plus petit et moins cher, et réserver le modèle frontier au raisonnement véritable est l'un des leviers de coût les plus puissants à votre disposition. Consultez la gamme actuelle et les tarifs au token sur la page pricing d'OpenAI, car les modèles exacts et les chiffres évoluent.

Deux autres leviers :

• Le prompt caching réduit le coût de la partie répétée et statique de votre prompt (instructions système, définitions d'outils) lorsque le même préfixe revient. Gardez votre contenu stable en tête pour qu'il soit mis en cache.
• Les structured outputs gardent les réponses compactes et parsables, ce qui évite les cycles de re-prompt et de retry qui doublent discrètement votre dépense. Définissez le schéma et le modèle retourne exactement cette forme.

Surveillez la dépense, ne la découvrez pas

Fixez une usage limit mensuelle stricte dans les paramètres de facturation de votre compte OpenAI pour qu'un bug ne puisse pas vider le budget. Ajoutez des clés d'API par environnement (une pour le dev, une pour la prod) afin d'attribuer la dépense et de révoquer celle qui fait du bruit. Puis surveillez le dashboard d'usage. Un pic de coût sur un graphique est une alerte précoce ; une facture surprise est un post-mortem.

Assembler les couches

Un agent bien encadré a les trois systèmes qui fonctionnent simultanément :

1. Les permissions décident quels outils existent et quel périmètre chacun a, appliqué dans le code.
2. Les review gates se placent devant les outils conséquents, avec une séparation proposer-puis-valider pour qu'un humain soit propriétaire de chaque « oui » irréversible.
3. Les contrôles de coût plafonnent la boucle, réduisent ce qui revient dans le contexte, routent vers le bon modèle et alertent sur la dépense.

Aucun de ces éléments ne vit dans le prompt. Le prompt façonne le comportement ; les guardrails imposent les limites. Quand vous ajoutez une nouvelle capacité, posez les trois questions dans l'ordre : *Qu'est-ce que ça peut toucher ? Qui l'approuve ? Combien ça coûte si ça boucle ?*

À retenir

• Appliquez les permissions dans le code, pas dans le prompt. Utilisez les schémas de GPT Actions, des comptes de connectors au moindre privilège, et des contrôles au niveau des outils que le modèle ne peut pas contourner.
• Utilisez une barrière proposer-puis-valider pour les actions à fort enjeu. L'agent retourne une proposition et un token ; c'est l'approbation d'un humain qui libère l'étape de validation.
• Tenez une liste explicite « jamais sans supervision » : suppressions irréversibles, argent au-delà d'une limite fixe, changements d'accès, communication de masse et engagements juridiques.
• Plafonnez le nombre d'étapes de chaque agent avec max_turns (ou son équivalent), et tronquez les outputs d'outils pour que des résultats surdimensionnés ne reviennent pas dans le contexte à chaque boucle.
• Fixez une limite de facturation stricte, utilisez des clés distinctes par environnement et routez les étapes peu exigeantes vers des modèles moins chers. Surveillez le dashboard d'usage pour qu'un pic soit une alerte, pas une facture.