Le meilleur garde-fou est celui que vos clients ne remarquent jamais. Ils posent leur question, avec leurs mots et dans leur dialecte, et reçoivent une réponse utile. En coulisses, le rare message qui tente de manipuler l’assistant est traité avec fermeté. Voilà l’objectif, et il a deux moitiés. La plupart des textes sur la sécurité de l’IA ne parlent que de la première : repérer les attaques. Cet article parle de la seconde : laisser passer les gens.
La raison est très concrète. Un garde-fou qui refuse des questions ordinaires ne protège personne de plus. Les utilisateurs reformulent, agacés, abandonnent, ou appellent le service client que l’assistant devait soulager. L’équipe responsable reçoit les plaintes et, tôt ou tard, assouplit le filtre ou le coupe. Un garde-fou désactivé ne protège rien. Le blocage excessif n’est pas un excès de sécurité : c’est un échec de sécurité.
Les chercheurs lui ont donné un nom
L’article XSTest parle de sécurité exagérée : des modèles qui refusent même des demandes clairement sans danger, parce qu’elles emploient un vocabulaire proche de demandes dangereuses ou abordent des sujets sensibles. Ses auteurs ont construit un test de 250 demandes sûres auxquelles un modèle bien réglé devrait répondre, à côté de 200 contre-exemples dangereux qu’il devrait refuser, précisément pour mesurer ce défaut au lieu de le deviner [1].
L’équipe de CyberSecEval 2, chez Meta, arrive à la même conclusion du côté de la sécurité : entraîner un modèle à rejeter les demandes dangereuses peut le conduire à rejeter à tort des demandes légitimes, ce qui réduit son utilité. Elle propose de suivre un taux de refus injustifiés à côté des chiffres d’attaques [2]. La leçon pour un acheteur est directe : la qualité d’un garde-fou tient en deux chiffres, pas un. Combien de manipulations il remarque, et combien peu de messages normaux il arrête à tort.
Là où les filtres naïfs se trompent en arabe
Le blocage excessif est pire dans les langues pour lesquelles un filtre n’a pas été conçu. Beaucoup de filtres apprennent surtout de l’anglais, et l’arabe tel qu’on l’écrit réellement dans le Golfe leur paraît inhabituel. Les exemples ci-dessous sont les nôtres, écrits pour illustrer le phénomène. Chacun est un message ordinaire qu’un filtre maladroit pourrait mal juger.
Le texte entièrement vocalisé
L’arabe s’écrit le plus souvent sans les signes de voyelles brèves, mais ceux-ci sont utilisés dans les textes qui exigent une prononciation exacte : le Coran, les hadiths, la poésie, les livres pour enfants et le matériel scolaire [3]. Un élève qui colle «العِلْمُ نُورٌ» (« le savoir est lumière ») dans un assistant scolaire fait quelque chose de parfaitement normal. Or des attaquants ajoutent aussi des diacritiques pour déguiser des mots interdits : un filtre qui apprend que « beaucoup de diacritiques, c’est suspect » finit par traiter les textes religieux et scolaires comme des menaces. Les diacritiques ne doivent jamais devenir un signe d’attaque. La bonne approche les retire avant le contrôle, puis juge le sens.
L’arabizi
L’arabizi est de l’arabe écrit avec des lettres latines et des chiffres : 3 remplace ع, 7 remplace ح et 2 la hamza. On l’utilise surtout dans les messageries et les SMS [4]. Un client qui écrit « ana 3ayez a3raf leh el card bta3ti et2afalet » (en égyptien : « je veux savoir pourquoi ma carte a été bloquée ») pose une question bancaire banale. Pour un filtre qui ne connaît que l’anglais, cela ressemble à du bruit ou à de l’obfuscation. Pour un filtre qui ne connaît que l’alphabet arabe, c’est invisible. Dans les deux cas, le client est mal servi.
Le dialecte du Golfe et les messages mélangés
« أبي أكسر حد التحويل اليومي، شلون؟ » signifie en dialecte du Golfe « je veux augmenter mon plafond de virement quotidien, comment faire ? », même si, mot à mot, il s’agit de « casser » le plafond. Un filtre à mots-clés voit « casser » et un virement, et s’inquiète. Ajoutez de l’anglais dans la même phrase, comme le font naturellement beaucoup de gens dans le Golfe (« please check my balance، ابي اعرف الرصيد »), et un filtre qui attend une seule langue par message peut prendre le changement de langue lui-même pour une ruse. Ce sont des clients, pas des attaquants.
Cinq issues, pas deux
L’idée la plus utile d’un garde-fou respectueux des utilisateurs est que « autoriser » et « bloquer » ne sont pas les seuls choix. Un score de risque peut correspondre à plusieurs actions, et la plupart permettent à la conversation de continuer.
- Autoriser : le message passe tel quel. Ce doit être l’issue de la grande majorité des messages.
- Masquer : l’utilisateur colle un numéro d’identité ou un IBAN, le garde-fou le remplace par un marqueur avant que le modèle ne le voie, puis remet la vraie valeur dans la réponse. L’utilisateur reçoit une réponse utile ; la valeur n’atteint jamais le fournisseur du modèle.
- Avertir : le message passe, avec une courte note pour l’utilisateur et une entrée dans votre journal. Utile dans les zones grises où le contexte compte.
- Demander de reformuler : au lieu d’un refus sec, l’utilisateur est invité à formuler sa demande autrement. Une redirection polie garde un client hésitant dans la conversation.
- Bloquer : réservé aux tentatives de manipulation claires ou aux demandes que votre politique n’autorise pas, consignées pour votre équipe sécurité.
Le masquage mérite une mention particulière, car il transforme un refus en oui. L’OWASP cite le nettoyage ou le masquage des contenus sensibles parmi ses mesures contre la divulgation d’informations sensibles [5]. Un garde-fou qui bloque tout message contenant un numéro d’identité émirien rend l’assistant inutile pour les formulaires de visa, les courriers bancaires ou les questions RH. Un garde-fou qui le masque permet à l’assistant d’aider, en toute sécurité.
Comment Guardrino est conçu pour satisfaire les utilisateurs légitimes
Guardrino, le pare-feu IA que HisnLabs construit pour les entreprises, part de ce principe. Tout ce qui suit relève de la conception prévue, pas d’un produit disponible, et nous ne publierons aucun résultat mesuré tant qu’une version n’aura pas été testée sur des jeux de tests publics et sur un jeu réservé.
- Le nettoyage d’abord : diacritiques, lettres étirées, formes de l’alif et du ya sont normalisés, et l’arabizi est lu comme de l’arabe, avant tout contrôle. Un poème vocalisé et sa version simple sont jugés sur le même sens.
- Les cinq issues ci-dessus, choisies par votre propre politique, par application et par équipe. Un assistant scolaire et un assistant de paiement n’ont pas besoin des mêmes limites.
- Un démarrage en simple observation : pendant les premières semaines, Guardrino enregistre seulement ce qu’il aurait fait. Vous examinez les résultats avant que quoi que ce soit ne soit bloqué.
- Un jeu de messages qui doivent toujours passer : une collection fixe de messages courants en arabe et en anglais, revérifiée avant chaque changement.
- Des retours qui le font progresser : quand un utilisateur ou un administrateur revient sur une décision, le cas est examiné et sert à améliorer les contrôles.
Ce que nous visons, c’est un assistant que vos clients aiment utiliser dans la langue qu’ils parlent vraiment, et une équipe sécurité qui voit dans le journal exactement ce qui a été arrêté et pourquoi. Pour comprendre les couches derrière ces décisions, lisez notre guide des garde-fous IA. Pour vérifier vous-même les blocages injustifiés d’un garde-fou, suivez notre tutoriel de test.
Une courte liste de vérification pour votre assistant
- Notez vingt vraies questions de vos utilisateurs, dans chaque langue et chaque dialecte qu’ils emploient, y compris l’arabizi et les messages mélangés. Passez-les dans votre garde-fou. Toutes doivent passer.
- Relisez vos messages de refus. L’un d’eux pourrait-il devenir une invitation à reformuler ?
- Repérez chaque règle qui bloque des données personnelles, et demandez-vous si un masquage permettrait plutôt à l’assistant d’aider.
- Vérifiez que votre journal indique pourquoi un message a été arrêté, pour que les mauvaises décisions puissent être retrouvées et corrigées.
- Mesurez le taux de blocages injustifiés avant et après chaque changement, pas seulement le nombre d’attaques repérées.
Si vous faites tourner des applications IA en arabe et en anglais et voulez un garde-fou pensé pour vos utilisateurs dès le premier jour, le programme pilote Guardrino est ouvert à un petit nombre d’entreprises. Le contexte du projet est expliqué dans pourquoi nous construisons Guardrino pour le Moyen-Orient.
Le rôle de Guardrino et de HisnLabs
Guardrino est conçu pour que les personnes servies par votre IA soient d’abord comprises, et refusées en dernier recours. La simulation ci-dessous montre l’idée en trois messages : des données personnelles masquées, une attaque arrêtée avec une demande de reformulation plutôt qu’un simple refus, et une question ordinaire en arabe qui passe directement. Guardrino est en développement et pas encore disponible.