Garde-fous LLM en entreprise : la méthode évaluation-contrôle de Mozilla.ai

En juin 2026, à Montréal, l'équipe de Mozilla.ai a présenté à l'ACM FAccT (Fairness, Accountability, and Transparency) 2026 un tutoriel intitulé : Contextual Evaluation of LLM Guardrails Across Languages and Agentic Systems. Son sujet : comment transformer les résultats d'une évaluation de modèle de langage en garde-fous réellement utilisables, et pourquoi ces garde-fous méritent le même niveau de scrutin que les modèles qu'ils encadrent.

Pour les équipes techniques qui déploient des agents IA en production, ce travail dépasse largement le cadre académique. Il pose une question très concrète : comment savoir si le filtre qui bloque, corrige ou laisse passer les réponses de votre agent fait réellement son travail, et pas seulement dans la langue et le contexte où vous l'avez testé une fois ?

Les garde-fous, ces grands oubliés de l'audit IA

Un garde-fou (guardrail), c'est le mécanisme qui filtre, signale ou contraint les entrées et sorties d'un LLM. C'est lui qui décide si une réponse part au client telle quelle, si elle doit être bloquée, ou si elle doit être reformulée. Historiquement, ces mécanismes étaient des classifieurs propriétaires, opaques, visibles uniquement à travers un refus sans explication. L'arrivée de modèles de garde-fous open source et de garde-fous pilotés par des prompts de politique a changé la donne : ils peuvent désormais être évalués indépendamment, au même titre que les modèles qu'ils protègent.

C'est exactement l'argument central de Mozilla.ai à FAccT : évaluer un garde-fou est aussi important qu'évaluer le LLM sous-jacent, et les résultats d'évaluation spécifiques à un contexte et à une langue doivent nourrir des politiques dynamiques, plutôt qu'une taxonomie figée du type de contenu à bloquer.

Le cas d'usage : 120 scénarios, cinq langues, un public vulnérable

Pour illustrer sa démarche, l'équipe a construit un cas d'usage volontairement exigeant : l'accompagnement de réfugiés et de demandeurs d'asile par des agents conversationnels. Elle a évalué 120 paires de scénarios en anglais, farsi, arabe, kurde sorani et pachto, notées par des traducteurs natifs de l'organisation Respond Crisis Translation, selon six critères fondés sur les droits. Les résultats ont été publiés en données ouvertes (le jeu MHRE) sur la Mozilla Data Collective, aux conditions fixées par les évaluateurs eux-mêmes.

Les défaillances récurrentes identifiées, des orientations dangereuses vers des ressources inadaptées, des avertissements légaux manquants, des suppositions stéréotypées sur la situation de l'utilisateur, ont ensuite été traduites en politiques de garde-fous concrètes, rédigées en anglais et en farsi.

La limite qui a tout changé : un texte ne peut pas vérifier un fait

En testant ces politiques, l'équipe a buté sur un problème structurel. Des critères comme la factualité ou l'actionnabilité d'une réponse ne peuvent pas être jugés à partir du seul texte. Cette association existe-t-elle vraiment ? Cette loi est-elle toujours en vigueur dans cette juridiction ? Un garde-fou purement textuel n'a aucun moyen de le vérifier : il a tamponné des réponses qu'il ne pouvait pas contrôler, halluciné des termes, et noté différemment des politiques strictement identiques selon qu'elles étaient rédigées en anglais ou en farsi.

De ce constat est née une hypothèse simple : les garde-fous pilotés par LLM ont besoin d'outils, recherche, récupération d'information, vérification factuelle, pour juger de manière fiable. C'est ce garde-fou agentique que Mozilla.ai a apporté à Montréal pour le tester en public.

Ce que l'atelier de Montréal a montré

Trente-cinq participants ont testé la démo en choisissant leurs propres scénarios et politiques, en comparant un juge agentique (doté d'outils) et un juge non agentique sur les mêmes réponses. Premier enseignement : les outils changent surtout les preuves justificatives, pas le verdict final. Sur l'ensemble des comparaisons, les verdicts concordaient dans 90% des cas entre les deux modes.

Deuxième enseignement, plus surprenant : le comportement agentique dépend presque entièrement du LLM utilisé comme juge, pas du cadre lui-même. Claude Sonnet 4.6 a déclenché une recherche web à quasiment chaque exécution (4,1 appels d'outils en moyenne), tandis que GPT-5 Nano y a eu recours de façon marginale (0,2 appel d'outil en moyenne). Quand les outils étaient effectivement mobilisés, ils faisaient bouger le verdict dans les deux sens : vérifier les affirmations factuelles d'une réponse liée à une demande d'asile a pu faire remonter son score, tandis que détecter une erreur factuelle qu'un juge sans outil avait laissée passer a fait basculer un verdict de validé à surveiller.

any-guardrail et Otari : l'outillage disponible dès maintenant

Ce type d'expérimentation devient vite ingérable si chaque comparaison exige de réécrire l'intégration technique. Mozilla.ai propose pour cela deux briques open source. any-guardrail offre une interface unifiée pour choisir et permuter des garde-fous avec des politiques personnalisées, rendant la couche de contrôle aussi configurable que le modèle lui-même. Otari, la passerelle LLM open source de Mozilla, permet de changer le modèle qui sert de juge sans réécrire l'intégration à chaque fois.

La suite de ces travaux porte sur la fiabilité de l'accès aux outils pour les garde-fous, sur des cas d'usage humanitaires, financiers et de lutte contre l'ingénierie sociale, avec des scénarios anglais-farsi et anglais-espagnol supplémentaires.

Ce que ça change pour votre entreprise

Si vous déployez un agent IA en production, qu'il s'agisse d'un support client, d'un assistant interne ou d'un outil métier, trois enseignements sont directement transposables :

• Un garde-fou générique et statique ne suffit pas dès que votre agent touche plusieurs langues ou plusieurs contextes métier. Une politique qui fonctionne en français sur un cas simple peut se comporter différemment sur un cas ambigu ou dans une autre langue.
• Évaluez votre garde-fou comme vous évaluez votre modèle. Les mêmes questions s'appliquent : sur quels cas échoue-t-il, dans quelle langue, avec quel taux de faux positifs et de faux négatifs.
• Un filtre purement textuel ne peut pas juger un fait. Si votre agent doit vérifier une affirmation (un prix, une loi, l'existence d'une entité), donner au garde-fou l'accès à un outil de recherche ou de vérification change sa fiabilité, mais l'efficacité de cet accès dépend fortement du modèle choisi comme juge, pas seulement du fait de lui donner des outils.

Notre lecture chez CZSyn

Chez CZSyn, nous accompagnons des PME et des équipes techniques qui intègrent des agents IA dans leurs workflows métier, souvent sans disposer en interne du temps ou de l'expertise pour construire une couche d'évaluation dédiée. Le travail présenté par Mozilla.ai à FAccT confirme une intuition que nous partageons sur le terrain : la robustesse d'un agent IA ne se joue pas uniquement sur le choix du modèle, mais sur ce qui l'entoure, le garde-fou, la politique, l'outillage de vérification.

Le chiffre le plus utile de cette étude n'est peut-être pas les 90% de verdicts concordants, mais l'écart entre 4,1 et 0,2 appels d'outils selon le modèle juge choisi. Concrètement, cela veut dire que deux entreprises qui déploient exactement le même garde-fou agentique avec deux modèles différents en tirent des garanties très différentes, sans que rien dans l'interface ne le signale. Avant de faire confiance à un garde-fou parce qu'il est présenté comme intelligent ou agentique, mieux vaut savoir ce qu'il fait réellement, et avec quel modèle.

Sources primaires

• Mozilla.ai, From Evaluation to Guardrails: What We Brought to ACM FAccT 2026, juin 2026.
• Mozilla.ai, site officiel mozilla.ai.
• Mozilla AI sur GitHub, dépôts open source (any-guardrail, Otari).