Votre modèle a fonctionné en test. Les utilisateurs l’ont déployé en production. Trois jours plus tard, il a commencé à recommander avec assurance des décisions financières qui violaient les règles de conformité. Personne ne l’a remarqué avant qu’un client ne dépose une plainte.
Cela se produit parce que les développeurs traitent la sécurité de l’IA comme une réflexion après coup — quelque chose que le contrôle qualité signale à la fin, pas quelque chose intégré à la conception du système. L’alignement n’est pas une philosophie abstraite. C’est un ensemble de contraintes concrètes et testables qui maintiennent le comportement de votre modèle dans des limites définies.
La Sécurité N’est Pas une Fonctionnalité. C’est une Décision d’Architecture.
Lorsque je construisais des systèmes de trading chez AlgoVesta, « sûr » signifiait : le modèle ne peut pas recommander de transactions dépassant les limites de position, ne peut pas ignorer les seuils de risque, et ne peut pas inventer de données historiques. Ceux-ci n’étaient pas appliqués par espoir — ils étaient appliqués par conception.
La plupart des échecs de sécurité de l’IA se produisent parce que les développeurs confondent deux problèmes différents :
- Alignement : Le modèle se comporte-t-il comme vous le souhaitez ? (Suit-il vos valeurs, vos contraintes et vos règles métier ?)
- Véracité : Invente-t-il des faits ou confabule-t-il ? (Pouvez-vous faire confiance à ses affirmations factuelles ?)
Vous pouvez avoir un modèle parfaitement véridique qui est complètement désaligné avec vos exigences métier. Claude Sonnet 4 n’inventera pas de faux articles de recherche dans la plupart des contextes, mais sans garde-fous, il fera toujours des recommandations en dehors de vos seuils de tolérance.
Trois Couches de Sécurité — et Où Elles Cassent
La sécurité en production nécessite plusieurs vérifications indépendantes. La défaillance d’une couche ne doit pas se propager.
Couche 1 : Contraintes au Niveau du Prompt
C’est là que la plupart des développeurs s’arrêtent. Vous écrivez une contrainte dans votre prompt système et considérez que c’est fait. Voici un exemple réel :
// MAUVAIS : Contrainte enfouie dans du texte
Vous êtes un conseiller financier. Suivez toutes les règles de conformité.
Faites des recommandations uniquement lorsque vous avez une grande confiance.
Ne recommandez jamais d'investissements risqués.
Cela échoue car « risqué » n’est pas défini. Claude l’interprète différemment de votre équipe de conformité. Voici la version de production :
// AMÉLIORÉ : Limite de décision explicite
Vous êtes un conseiller financier. Vous ne pouvez recommander des investissements que si :
- Le ratio de Sharpe est >= 1.2
- La volatilité est <= 15% annualisée
- La concentration sur un seul actif est <= 5% du portefeuille
Si aucune de ces conditions n'est remplie, répondez :
« Je n'ai pas assez d'informations pour recommander une action. »
Ne proposez pas d'alternatives. Ne suggérez pas de solutions de contournement.
Cela fonctionne car la contrainte est mathématique, pas subjective. Mais voici le hic : Claude l'ignorera quand même parfois. Le raisonnement en chaîne peut outrepasser les instructions explicites si le modèle « raisonne » pour s'en sortir.
Couche 2 : Validation de la Sortie (Le Garde-fou)
Ne faites jamais confiance au modèle pour s'auto-réguler. Analysez sa sortie, mesurez-la par rapport à vos contraintes et rejetez-la si elle les viole.
import json
from pydantic import BaseModel, ValidationError
class Recommendation(BaseModel):
action: str #
