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.

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.

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.

Suite​