Aller au contenu principal

Sécurité, refus et solutions de repli

Intermédiaire

En production, votre code doit gérer le cas où Claude ne veut (ou ne peut) pas répondre comme prévu. Bien fait, c'est invisible pour les utilisateurs ; mal fait, c'est un plantage ou une réponse déroutante.

What you'll learn
  • Distinguer un refus du modèle d'un blocage classifieur/sécurité — et pourquoi c'est important
  • Traiter un refus comme un résultat normal au lieu de planter ou d'afficher une réponse vide
  • Réduire les refus non désirés, sans tenter de contourner ceux que vous voulez
  • Choisir un repli : question de clarification, alternative sûre ou passage à un humain

Deux choses différentes​

  • Un refus du modèle — Claude décline une requête (par ex. il la juge nuisible). La réponse le signale (généralement via un stop_reason/contenu de refus). Traitez-le comme un résultat normal, et non comme une erreur.
  • Un blocage du classifieur/de sécurité — une couche de sécurité distincte peut bloquer le contenu. Cela peut se présenter différemment d'un refus du modèle.

Savoir lequel des deux vous avez obtenu vous permet de réagir de manière appropriée plutôt que de réessayer à l'aveugle.

Gérez-le avec élégance​

resp = client.messages.create(...)
if getattr(resp, "stop_reason", None) == "refusal":
    # Don't show a raw/empty result. Offer a safe fallback or a clarifying ask.
    show_user("I can't help with that as asked. Here's what I can do instead…")
else:
    render(resp)

Réduire les refus indésirables​

  • Ajoutez un contexte légitime. Une requête peut ressembler par motif à quelque chose de sensible alors que l'intention est bénigne ; énoncer le but réel et légitime aide.
  • Soyez précis. Une formulation vague ou limite invite à la prudence.
  • Ne luttez pas contre. Si une requête est réellement interdite, le refus est correct — concevez un chemin élégant, n'essayez pas de contourner les protections.

Ajouter le contexte légitime dès le départ

I am a security engineer at [company] reviewing our own authentication code
before a release. Below is a function we wrote and own.

Identify weaknesses in it and explain how an attacker would exploit each one,
so we can fix them before we ship.

[code]

Patrons de repli​

  • Une question de clarification plutôt qu'une impasse.
  • Une alternative sûre (« Je peux résumer les informations publiques à la place »).
  • Pour les pipelines, acheminez vers un humain lorsque la confiance/l'éligibilité est faible.
Guided walkthrough1 of 4
  1. Inspectez la réponse à la recherche d'un signal de refus avant de l'afficher. Ne redirigez jamais une réponse non vérifiée directement dans votre UI — c'est ainsi que les utilisateurs voient une boîte vide ou un objet brut.

Vérifiez-vous

0/3
  1. Votre code reçoit un refus de Claude. Quelle est la bonne manière de le traiter ?
  2. Une requête bénigne se fait constamment refuser. Que tenter en premier ?
  3. Pourquoi est-ce important de savoir si vous avez reçu un refus du modèle ou un blocage classifieur/sécurité ?
Key takeaways
  • Un refus est un résultat, pas une erreur — détectez-le avant l'affichage, toujours.
  • Refus du modèle et blocage classifieur sont des choses différentes ; identifiez celui reçu.
  • Les refus non désirés diminuent habituellement quand vous ajoutez un contexte légitime et êtes précis.
  • Si une requête est réellement interdite, le refus est correct — construisez un chemin élégant, ne contournez pas.
  • Replis dans l'ordre : question de clarification, alternative sûre, passage à un humain.

Suite​