Garde-fou LLM en entreprise : filtrer les messages

Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 20 octobre 2026.

En bref

Un garde-fou LLM en entreprise examine chaque message avant le modèle pour filtrer les injections, contournements, contenus nuisibles et données personnelles. La réalisation publiée par TW3 Partners, sans date de publication affichée, compare 13 classifieurs sur 500 messages annotés à la main en français et en anglais. Elle associe des règles, le masquage des données personnelles et des classifieurs, sur un seul GPU T4 avec mise à l’échelle à zéro, sans appel à un modèle externe pour le filtrage. L’assistant accueille plusieurs milliers d’utilisateurs internes, dont un public jeune, avec deux profils de sensibilité. Selon l’Insee, le 21 juillet 2026, 43 % des entreprises utilisatrices de l’IA déclarent des inquiétudes concernant la protection des données et de la vie privée dans l’enquête de 2025. Ce chiffre concerne les entreprises en France d’au moins 10 personnes occupées des secteurs principalement marchands, hors agriculture, finance et assurance, dans un champ excluant Mayotte.

1. Qu’est-ce qu’un garde-fou d’entrée pour un assistant IA ?

Un garde-fou d’entrée désigne un filtre placé entre l’utilisateur et le modèle, qui examine chaque message avant sa transmission. La fiche TW3 Partners lui attribue le traitement des injections, des contournements, des contenus nuisibles et des données personnelles.

Dans sa fiche sur l’injection de prompt, édition 2025, l’OWASP définit ce risque comme une modification non souhaitée du comportement ou des réponses du modèle provoquée par les entrées de l’utilisateur.

Pour cadrer un projet, nous recommandons d’examiner les instructions contenues dans les messages et de formaliser la décision attendue à l’entrée : laisser passer la demande, masquer les données concernées ou refuser le message. Le responsable métier et le responsable sécurité devraient pouvoir relire cette règle avant le choix technique. Ce document servirait ensuite de référence aux personnes chargées d’annoter les messages de test.

2. Que doit-il bloquer, et que doit-il laisser passer ?

Le filtre doit bloquer les usages dangereux tout en laissant passer les questions légitimes, avec une latence et un coût soutenables : c’est le problème formulé par TW3 Partners dans sa fiche. Le contexte décrit deux profils de sensibilité pour plusieurs milliers d’utilisateurs internes, dont un public jeune.

Notre recommandation est de traduire chaque profil en critères de décision écrits. Pour les demandes autorisées, préciser ce qui justifie leur acceptation ; pour les demandes à refuser, préciser le motif. Les désaccords entre annotateurs devraient être arbitrés avant de comparer les modèles, afin de disposer d’une règle commune pour les évaluer.

Nous recommandons aussi d’examiner les refus de demandes légitimes comme un sujet métier : quelle tâche est interrompue, et comment l’utilisateur peut-il poursuivre son travail ? Cette revue donne une place explicite aux erreurs d’un filtre trop strict. Elle permet de discuter la sévérité sur des décisions identifiables, avec les responsables des usages concernés.

3. Quelles couches composent le filtre ?

Le filtre associe des règles anti-injection, la détection et le masquage des données personnelles, un classifieur compact entraîné en interne et un classifieur de sécurité ouvert. La description de TW3 Partners présente cette combinaison comme un garde-fou multicouche.

Couche décrite	Objet du contrôle	Technique publiée
Règles anti-injection	Injections dans les messages	Règles de filtrage
Traitement des données personnelles	Informations personnelles repérées	Détection et masquage
Classifieur compact	Classification au sein du garde-fou	Entraînement en interne
Classifieur de sécurité ouvert	Classification de sécurité en complément	Combinaison avec le classifieur interne

Pour une DSI qui prépare une architecture comparable, nous recommandons de décrire la décision produite par chaque couche et son effet sur la transmission du message. En particulier, il faut décider comment traiter un désaccord entre classifieurs et à quel moment appliquer le masquage. Ces choix constituent des éléments du cahier des charges à tester.

L’OWASP, dans la même édition 2025, recommande de définir les catégories sensibles et les règles de traitement, ainsi que d’associer des filtres sémantiques à des contrôles de chaînes de caractères. Cette approche fournit un appui pour formaliser les contrôles attendus de la combinaison.

4. Comment comparer des classifieurs avant d’en choisir un ?

Dans la réalisation décrite par TW3 Partners, les classifieurs sont comparés dans les mêmes conditions, sur des messages annotés à la main. La fiche décrit un banc de 500 messages en français et en anglais, avec 13 classifieurs comparés. Elle ne publie ni leurs scores ni leur classement, ni taux de faux positifs ou latence mesurée.

Pour conduire une comparaison dans une autre organisation, nous recommandons de conserver, pour chaque message, la langue, le profil de sensibilité et la décision attendue. L’annotation devrait aussi comporter un motif assez précis pour qu’un responsable puisse comprendre le résultat sans avoir à interpréter le fonctionnement du modèle.

La revue des essais devrait séparer les messages dangereux acceptés des demandes légitimes refusées. Nous recommandons de regarder les désaccords message par message, puis de les regrouper par type de contrôle. Cette lecture permettrait de rechercher une combinaison adaptée aux priorités de l’organisation, avec une règle d’arbitrage explicite entre protection et continuité des usages.

Nous proposons enfin de mesurer le délai ajouté au traitement sur l’infrastructure envisagée, en conservant les mêmes conditions pour les candidats. Le dossier de décision réunirait alors les erreurs observées et les contraintes d’exploitation. Le choix de la combinaison pourrait être justifié par les résultats du banc propre à l’organisation.

5. Comment le filtre tient-il sur un seul GPU ?

La réalisation combine un classifieur compact et un classifieur de sécurité, avec un modèle quantifié, sur un GPU T4. La fiche TW3 Partners situe l’hébergement sur Azure Container Apps, en Europe de l’Ouest, et décrit une mise à l’échelle à zéro. Elle précise qu’aucun modèle externe n’est appelé pour le filtrage : cette étape n’envoie donc pas les messages à un service de modèle externe.

La documentation Microsoft sur la mise à l’échelle, mise à jour le 20 mai 2026, distingue les limites du nombre d’instances et les règles qui déclenchent leur ajout ou leur retrait. Le minimum peut être fixé à zéro. Lorsque les règles le permettent, le nombre d’instances actives peut donc être ramené à zéro.

Nous recommandons de prévoir une recette après une période sans activité, puis sous des demandes simultanées. Il faudrait y vérifier le temps d’attente et le comportement de l’assistant lorsque le filtre est indisponible. Le cahier des charges devrait préciser le traitement de ce cas, ainsi que la responsabilité de remise en service, avant d’ouvrir l’accès aux utilisateurs.

6. Que fait-on des données personnelles repérées dans un message ?

La réalisation prévoit leur détection et leur masquage dans le garde-fou placé avant le modèle, selon la fiche TW3 Partners. Ce contrôle mérite une définition précise du périmètre à protéger.

Dans sa définition « Donnée personnelle », sans date de publication affichée, la CNIL explique qu’il s’agit d’informations relatives à une personne physique identifiée ou identifiable. L’identification peut être directe ou indirecte, et résulter du croisement de plusieurs données. À l’inverse, les coordonnées génériques d’une entreprise, telles que celles de son standard ou son adresse de contact générale, ne constituent en principe pas des données personnelles.

Nous recommandons de faire valider le périmètre de masquage par le responsable de la protection des données, puis de contrôler le message effectivement transmis au modèle. La recette devrait vérifier que les informations visées sont masquées et que la demande reste compréhensible. Cette recommandation concerne la conception du contrôle ; les catégories à couvrir doivent être définies pour le projet.

7. Comment faire évoluer le filtre sans perdre ce qui fonctionne ?

La réalisation prévoit le réentraînement et un outil interne de comparaison des versions côte à côte, selon TW3 Partners. Le banc fournit ainsi un support pour examiner les changements de comportement entre versions.

Notre recommandation est de conserver un jeu de référence et de rejouer les mêmes messages avec la version en service et la version candidate. Pour chaque décision modifiée, la revue devrait indiquer si le changement est attendu et qui l’a validé. Les messages nouvellement ajoutés au banc devraient être identifiés pour distinguer l’évolution du filtre de celle du test.

Nous recommandons de décider la mise en service après cette revue et de conserver la configuration précédente pour permettre un retour en arrière. Le responsable sécurité disposerait ainsi d’un dossier comprenant les changements acceptés, leur justification et le périmètre des essais. Le responsable métier pourrait y vérifier le traitement des demandes légitimes qui motivent l’usage de l’assistant.

FAQ

Le filtrage envoie-t-il les messages à un service externe ?
La fiche TW3 Partners indique qu’aucun modèle externe n’est appelé pour le filtrage. Cette indication porte sur le filtre, hébergé sur Azure Container Apps en Europe de l’Ouest.

Pourquoi combiner des règles et des classifieurs ?
La réalisation associe le contrôle des injections, le masquage des données personnelles et la classification de sécurité. La combinaison a été choisie après une comparaison sur banc, selon la même fiche.

Le filtre fonctionne-t-il en français ?
Le banc décrit par TW3 Partners comprend des messages annotés en français et en anglais. Pour un autre déploiement, nous recommandons de vérifier séparément les décisions dans chaque langue attendue.

Quelle infrastructure faut-il prévoir ?
La réalisation utilise un GPU T4 sur Azure Container Apps avec mise à l’échelle à zéro, selon TW3 Partners. Pour reprendre cette architecture, nous recommandons une recette avec les conditions de charge prévues.

Peut-on adapter la sévérité selon les utilisateurs ?
Le contexte de la réalisation TW3 Partners prévoit deux profils de sensibilité. Nous recommandons de formaliser les décisions attendues pour chaque profil avant les essais.

Un garde-fou d’entrée suffit-il à sécuriser un assistant ?
Son périmètre est le traitement des messages avant le modèle. Pour les autres contrôles, l’article TW3 Partners du 28 mai 2026 sur les risques d’un déploiement agentique distingue notamment les sorties et l’exécution des actions.

Pour aller plus loin

Garde-fou d’entrée pour un assistant IA grand public interne : la fiche de réalisation.
Envoyer chaque requête au modèle le plus sobre qui sait y répondre : passerelle multi-modèles et juge de complexité.
Mesurer l’adoption réelle d’un assistant IA interne et repérer les contenus qui manquent.
Déployer une IA agentique en entreprise : risques et conformité.

Filtrer les messages envoyés à un assistant IA interne : conception d’un garde-fou d’entrée qui tient sur un seul GPU