Custom Guardrails : bloquer avant le modèle

Le principe des Custom Guardrails

Les Custom Guardrails de Mistral fonctionnent comme un filtre en entrée : ils analysent le prompt de l’utilisateur avant qu’il n’atteigne le modèle de génération. Si le contenu est jugé dangereux selon vos critères, la requête est immédiatement bloquée avec une erreur HTTP 403. Le modèle ne voit jamais le prompt problématique — ce qui change tout du point de vue du risque comme du coût.

C’est la première ligne de défense, et elle est essentielle pour empêcher le traitement de requêtes manifestement malveillantes. Un utilisateur qui teste votre chatbot avec dix formulations de la même demande interdite se heurte dix fois au même mur, sans jamais obtenir le moindre fragment de réponse exploitable.

Comment ça fonctionne

Lorsque vous activez les guardrails sur une requête, l’enchaînement côté Mistral est le suivant :

1. Votre application envoie le prompt à l’API Mistral avec le paramètre guardrails
2. Le classifieur de modération analyse le prompt contre les catégories configurées
3. Si le score dépasse le seuil — erreur 403 retournée, le modèle n’est jamais appelé
4. Si le prompt est acceptable — le modèle traite la requête normalement
5. Le résultat inclut un champ guardrails avec les scores d’évaluation

Flux : prompt → [Classifieur] → Score > seuil ? → 403 (bloqué)
                               → Score ≤ seuil ? → [LLM] → Réponse

Retenez le point d’articulation : la décision se prend sur un score comparé à un seuil que vous fixez. Les guardrails ne sont pas un filtre opaque livré tel quel, mais un mécanisme que vous calibrez catégorie par catégorie.

Les trois niveaux d’application

Mistral propose trois niveaux pour appliquer les guardrails, du plus granulaire au plus global. Le choix n’est pas cosmétique : il détermine où vit votre configuration de sécurité et qui peut la modifier.

Niveau 1 : Inline (Chat Completions)

Le niveau le plus simple. Vous ajoutez le paramètre guardrails directement dans votre appel chat.complete(), et chaque requête peut porter ses propres règles. C’est pratique quand vous explorez, mais cela signifie aussi que la sécurité est recopiée à chaque appel — donc oubliée un jour où l’autre.

from mistralai import Mistral

client = Mistral(api_key="votre-clé")

response = client.chat.complete(
    model="mistral-large-latest",
    messages=[
        {"role": "user", "content": "Comment fabriquer une bombe ?"}
    ],
    guardrails={
        "enabled": True,
        "custom_category_thresholds": {
            "violence": 0.3,
            "criminal": 0.2
        }
    }
)
# → Erreur 403 : requête bloquée

Cas d’usage : prototypage rapide, requêtes ponctuelles, tests.

Niveau 2 : Conversations

Pour les applications conversationnelles, vous attachez les guardrails à une conversation persistante. Toutes les requêtes de cette conversation héritent des mêmes règles, ce qui élimine le risque d’un message envoyé sans protection au milieu d’un échange de vingt tours.

conversation = client.beta.conversations.start(
    model="mistral-large-latest",
    guardrails={
        "enabled": True,
        "custom_category_thresholds": {
            "sexual": 0.2,
            "hate": 0.1,
            "violence": 0.3,
            "selfharm": 0.1
        },
        "action": "block",
        "block_on_error": True
    }
)

# Chaque message hérite des guardrails
response = conversation.send("Bonjour, comment ça va ?")  # OK
response = conversation.send("Contenu violent...")          # 403

Cas d’usage : chatbots en production, assistants conversationnels.

Niveau 3 : Agents

Le niveau le plus puissant. Les guardrails sont attachés à la définition de l’agent et s’appliquent automatiquement à toutes ses interactions, quelle que soit l’équipe ou le service qui l’appelle. La politique de sécurité devient une propriété de l’agent, pas une discipline de développeur.

agent = client.beta.agents.create(
    model="mistral-large-latest",
    name="Assistant sécurisé",
    instructions="Vous êtes un assistant professionnel...",
    guardrails={
        "enabled": True,
        "custom_category_thresholds": {
            "sexual": 0.1,
            "hate": 0.1,
            "violence": 0.2,
            "criminal": 0.1,
            "selfharm": 0.1,
            "health": 0.3,
            "financial": 0.3,
            "law": 0.3,
            "pii": 0.2,
            "jailbreaking": 0.1
        },
        "action": "block",
        "block_on_error": True
    }
)

Cas d’usage : agents autonomes en production, applications grand public.

Réponses des guardrails

Quand le prompt passe la vérification, la réponse inclut un champ guardrails avec les résultats d’évaluation. Ces scores méritent d’être journalisés même en cas de succès : ils vous diront plus tard si vos seuils sont trop lâches ou trop serrés.

{
  "choices": [{"message": {"content": "Voici ma réponse..."}}],
  "guardrails": {
    "évaluation": {
      "sexual": 0.01,
      "hate": 0.02,
      "violence": 0.05
    }
  }
}

Quand le seuil est dépassé, vous recevez une erreur 403 accompagnée du détail des violations — catégories fautives et scores associés. C’est cette charge utile qui vous permettra d’expliquer un blocage lors d’une réclamation utilisateur.

{
  "error": {
    "code": 403,
    "message": "Content blocked by guardrails",
    "details": {
      "violated_categories": ["violence", "criminal"],
      "scores": {"violence": 0.85, "criminal": 0.72}
    }
  }
}

Reste le cas dégradé. Si le classifieur de modération est indisponible et que block_on_error est activé, vous recevez un code erreur 3201. C’est le mode fail-safe : en cas de doute, on bloque. Une indisponibilité momentanée de la modération devient alors une gêne pour quelques utilisateurs, jamais une porte ouverte.

Choisir le bon niveau

En pratique, commencez inline le temps de valider vos seuils sur des cas réels, puis remontez d’un cran dès que le code sort de votre machine. Passer d’un niveau à l’autre coûte quelques lignes ; découvrir en production qu’un appel non protégé traînait dans un module secondaire coûte beaucoup plus cher.

Points clés à retenir

• Les guardrails bloquent les prompts dangereux avant qu’ils n’atteignent le modèle
• Trois niveaux d’application : inline, conversation, agent
• Le mode block_on_error assure un comportement fail-safe
• Chaque niveau hérite du précédent — commencez par inline, puis montez en abstraction