Lorsqu’un système reposant sur un grand modèle de langage (LLM) commence à traiter des données réelles ou à prendre des décisions à fort impact, l’affirmation « il fonctionne généralement » n’est plus un critère acceptable. Un article du Stack Overflow Blog, consacré au quatrième niveau du modèle de maturité des systèmes LLM, propose d’intégrer la sûreté et la gouvernance directement à l’architecture au moyen de quatre pratiques interdépendantes : plusieurs garde-fous, le contrôle des données personnelles à chaque frontière du système, un journal d’audit infalsifiable et une mémoire limitée à un périmètre clairement défini.
Plusieurs garde-fous plutôt qu’un seul point de protection
L’article critique le fait de se contenter d’un seul filtre pour les sorties du modèle et propose de faire de chaque garde-fou un petit contrat logiciel pouvant être testé et ordonné indépendamment. Les requêtes passent par des couches qui vérifient les entrées et les tentatives d’injection d’instructions, les contraintes d’ancrage et le format des sorties, puis nettoient les résultats pour éliminer les violations de politique ou les données personnelles. Viennent ensuite la vérification des règles métier, le recours à un arbitre secondaire pour les cas qui semblent corrects mais sont erronés, et enfin l’estimation de la confiance afin de déterminer si la décision sera exécutée ou nécessitera une intervention humaine.
La règle fondamentale est le « fail closed » : si un garde-fou tombe en panne ou devient indisponible, la requête ne doit pas être transmise automatiquement. Chaque opération de blocage devrait également être enregistrée comme un signal opérationnel ; une hausse soudaine de cet indicateur peut signifier une attaque, une régression de version ou un problème de déploiement. L’article souligne que les contraintes effectives doivent rendre les sorties interdites impossibles à représenter, plutôt que de se limiter à des instructions textuelles que le modèle peut contourner.
Les données personnelles sont traitées aux frontières
Chaque transfert entre les composants du système constitue une frontière de sécurité : entrée des données, envoi au modèle, écriture dans les journaux ou le registre des décisions, et transmission à un autre service. L’article recommande une classification centralisée de la sensibilité, en considérant par défaut les champs inconnus comme des données personnelles, puis de supprimer, masquer ou hacher les données avant le franchissement de chaque frontière.
Dans le registre des décisions, il ne faudrait pas stocker intégralement la charge utile sensible pour prouver ce sur quoi la décision était fondée. L’alternative consiste en un résumé expurgé accompagné d’un hachage keyed hash utilisant HMAC et une clé propre à chaque locataire. L’article souligne que l’utilisation de SHA-256 ordinaire avec des données à faible entropie, comme une adresse e-mail ou un numéro de carte, permet un devinage inverse. Il faut également adopter une représentation JSON canonique et stable, telle que la spécification JCS, afin que le recalcul du hachage produise le même résultat.
Un journal d’audit qui établit l’historique plutôt que de simplement conserver les journaux
L’article distingue les journaux opérationnels, utiles au débogage et susceptibles d’être soumis à une rotation ou d’être non structurés, d’un registre d’audit en ajout seulement qui enregistre chaque décision et sa justification. Ce registre comprend l’identité de la décision, le locataire, les autorisations, les versions du modèle et du prompt, la décision, le niveau de confiance et le chemin de routage, ainsi qu’un résumé expurgé et des entrées hachées.
Les corrections ne modifient pas l’enregistrement précédent : elles créent une nouvelle entrée qui fait référence à l’entrée qu’elle remplace. Pour détecter toute falsification, les entrées sont liées par une chaîne de hachage, avec vérification de la séquence et de l’exhaustivité des numéros. Toutefois, la chaîne seule n’empêche ni la suppression de la partie finale ni la reconstruction complète du registre ; l’article propose donc de signer les entrées et de publier périodiquement des points de contrôle dans un stockage externe. L’ajout doit également être exécuté sous verrou afin d’empêcher deux opérations d’écriture simultanées de créer deux branches de la chaîne.
Une mémoire classifiée et une séparation entre ce qui est livré et ce qui est acquis
Dans les systèmes multi-locataires, la mémoire devient une question de gouvernance des données, et non une simple fonctionnalité. L’article propose des catégories distinctes, telles que les connaissances partagées du locataire, l’espace de l’agent, le contexte temporaire du flux de travail, le journal d’audit, les connaissances sémantiques et la conversation de l’utilisateur. Chaque catégorie possède une portée d’accès, une politique de sensibilité et une clé de partition imposées au niveau même du magasin de données, avec interdiction de toute lecture ou écriture entre locataires et isolation de la conversation d’un utilisateur par rapport aux agents de prise de décision d’autres utilisateurs.
L’article distingue également les données initiales fournies par l’équipe, comme les prompts, les règles, les jeux de tests et les données d’ancrage, des données d’exécution acquises par le système, comme la mémoire, les signaux de dérive et le contexte des sessions. Les premières doivent être versionnées et impossibles à modifier pendant l’exécution, tandis que les secondes peuvent être nettoyées dans un périmètre défini sans supprimer le journal d’audit. Tout nouveau comportement extrait des données d’exécution devrait faire l’objet d’une revue et de tests avant d’être intégré à une version ultérieure ; selon l’article, l’apprentissage doit davantage ressembler à une demande de modification logicielle qu’à un effet secondaire impossible à retracer.
Pourquoi ces pratiques sont-elles importantes ?
La valeur pratique de la proposition ne réside pas dans un outil isolé, mais dans la répartition de la confiance entre des couches indépendantes. Le nettoyage des sorties ne remplace pas la vérification des règles métier, un journal d’audit ne justifie pas la conservation des données brutes, et la mémoire ne devient pas sûre simplement parce qu’une base de données vectorielle est utilisée. Les questions ouvertes qui nécessitent encore une décision d’ingénierie sont la définition des catégories de données adaptées à chaque système, le réglage des politiques de résidence et d’accès, la détermination des cas nécessitant une revue humaine et la preuve que le nettoyage de la mémoire ne supprime pas des entrées indispensables à la prise de décision.