La collision de vocabulaire : quand un classificateur de sécurité marque tout votre domaine

Un classificateur de sécurité polyvalent repose sur une hypothèse cachée : parler d'attaquants, d'exploits ou de blanchiment d'argent est rare et suspect. Appliquez-le à un produit de sécurité et de conformité, et cette hypothèse s'inverse. Sur une fenêtre de production de 17 jours se terminant le 10 avril 2026, l'alias mistral-moderation-latest de Mistral (qui pointait alors vers le modèle mistral-moderation-2603) a marqué 15 messages dans notre application comme nuisibles. Chacun de ces messages était un faux positif. La précision était de zéro. Non dégradée, non bruyante : zéro sur quinze.

Il s'agit d'un résultat spécifique et mesuré sur notre propre trafic, qui met en lumière un mode de défaillance invisible jusqu'à ce que l'on examine les alertes une par une. Nous l'appelons la collision de vocabulaire : dans un domaine spécialisé, le vocabulaire de danger du classificateur est le vocabulaire de travail du domaine. Le signal censé être rare devient la norme.

Les alertes

Sur les 15 alertes, 14 tombaient dans la catégorie dangerous_and_criminal_content et 1 dans violence_and_threats. En les relisant, le schéma était immédiat. Il s'agissait de discussions légitimes en matière de GRC (Gouvernance, Risques et Conformité) :

• L'ingénierie inverse des services d'un fournisseur cloud, dans le contexte des obligations de propriété intellectuelle. La norme ISO/IEC 27001:2022, annexe A, contrôle A.5.32, est littéralement intitulée « Droits de propriété intellectuelle » ; un utilisateur travaillant sur ce contrôle doit parler d'ingénierie inverse pour en discuter.
• Une évaluation des risques rédigée en espagnol, où « amenazas » (menaces) est le terme ordinaire pour désigner ce que chaque registre des risques énumère.
• Des travaux de lutte contre le blanchiment d'argent, où « blanqueo » (blanchiment) est le sujet, et non un aveu.
• Des expériences de red teaming et de tests d'intrusion.
• Le DAST (Dynamic Application Security Testing), c'est-à-dire le balayage dynamique d'une application à la recherche de vulnérabilités.

Rien de tout cela n'est un contenu criminel. Il s'agit du vocabulaire quotidien des professionnels de la cybersécurité, des responsables conformité et des auditeurs. Le classificateur n'est pas défectueux. Sur le trafic web général, un message évoquant l'ingénierie inverse des systèmes d'un fournisseur est un signal de danger plausiblement faible, et un classificateur polyvalent est conçu pour le traiter comme tel. Nos utilisateurs, eux, forment la population pour laquelle ce même signal signifie exactement l'inverse. Nous nous attendions à ce type d'échec avec n'importe quel classificateur polyvalent utilisé de la même manière, car il découle du cadre polyvalent plutôt que d'une implémentation spécifique à un fournisseur. L'erreur était la nôtre : nous avons traité une hypothèse générale comme si elle était adaptée au domaine.

Le surblocage n'est pas une solution par défaut sûre

L'instinct est de considérer les faux positifs comme le revers inoffensif du compromis précision-rappel. Manquer une menace réelle crée une faille de sécurité ; sur-flaguer génère, au pire, du bruit. En production, ce bruit avait des conséquences, et il est important d'en être concret, car c'est là que se situait le vrai dommage :

1. La fatigue des alertes a neutralisé le filet. Chaque événement confirmé générait un email dans notre boîte de sécurité. Quinze fausses alertes consécutives ont appris à l'équipe à ignorer les notifications de modération. Un filet de sécurité que tout le monde a appris à ignorer n'est pas un filet de sécurité.
2. Un problème de droit à l'oubli. Les fils de discussion signalés étaient verrouillés contre la suppression afin que les preuves ne puissent pas être détruites. C'est raisonnable pour un abus réel. Appliqué à un faux positif, cela signifiait qu'un utilisateur ne pouvait pas supprimer sa propre conversation de conformité, ce qui créait un risque au regard de l'article 17 du RGPD (droit à l'oubli). Ce droit, sous réserve de ses propres conditions et exceptions, couvre la suppression sélective, et pas seulement la fermeture d'un compte.
3. Une étiquette que nous ne pouvions pas justifier. Des messages utiles se retrouvaient dans un stockage dont la sémantique était « contenu dangereux et criminel ». Il s'agissait d'une affirmation sur une personne que nous ne pouvions pas défendre.

La précision, et non le rappel, était le paramètre en souffrance, et son échec n'était pas cosmétique.

Pourquoi les solutions évidentes ne fonctionnent pas

Deux solutions s'imposent, et aucune n'est valable.

Ajuster le classificateur. Impossible. Le point de terminaison de modération est un classificateur fixe. Son API accepte un identifiant de modèle et une chaîne d'entrée, et renvoie des scores de catégories. Il n'y a ni prompt système, ni champ d'instruction, ni moyen de lui dire « ceci est un produit de conformité ». Un classificateur fixe vous donne un bouton sans graduation.

Supprimer les catégories bruyantes. Désactiver dangerous_and_criminal_content et violence_and_threats éliminerait tous les faux positifs que nous avions observés. Cela éliminerait également les seules catégories sous lesquelles une menace réelle dans notre domaine pourrait jamais émerger. Ce n'est pas un calibrage, c'est éteindre le filet et qualifier le silence de succès.

La solution en deux étapes

Conservez le classificateur rapide en première étape ; il continue de s'exécuter sur chaque message. Lorsqu'il signale quelque chose, transmettez le message à un deuxième juge : un petit modèle de conversation (Mistral Small) doté d'un prompt système qui décrit les sujets légitimes de cybersécurité et de conformité que nos utilisateurs abordent réellement. Le juge renvoie l'un des deux verdicts : CONFIRMÉ ou FAUX_POSITIF.

Seuls les événements CONFIRMÉ suivent le chemin d'alerte et de verrouillage. Les événements FAUX_POSITIF sont dirigés vers un stockage supprimé séparé, conservé pour l'audit et la détection de dérive, mais sans conséquence visible pour l'utilisateur : pas d'email, pas de verrouillage de suppression, pas d'étiquette criminelle. Le juge s'exécute sur environ un message signalé par jour, donc le coût supplémentaire est négligeable. Et il échoue en mode sécurisé : si le juge commet une erreur, dépasse le délai ou renvoie un verdict qui n'est pas clair, le message est traité comme CONFIRMÉ. Le pire des cas est l'ancien bruit de base, jamais une menace silencieusement ignorée.

Déployée le 10 avril 2026, cette solution a ramené notre taux de faux positifs sur ces alertes de 15 sur 15 à zéro, sans désactiver une seule catégorie.

Le piège : nous avons déplacé le risque, nous ne l'avons pas éliminé

Voici ce qu'il faut retenir, car cela se généralise au-delà de la modération. Ajouter une deuxième étape indulgente ne supprime pas le risque. Il le déplace, d'une défaillance visible à une défaillance invisible.

Avant, le mode de défaillance dominant était le surblocage, et il était bruyant : chaque faux positif faisait sonner l'alerte. Après, le mode de défaillance dominant est le juge étant trop indulgent et laissant passer silencieusement quelque chose qu'il aurait dû confirmer. Cette défaillance est silencieuse par construction. Elle écrit dans un stockage dont personne n'est notifié par email.

Nous avons eu une démonstration en direct de la façon dont le régime silencieux peut être déroutant. Le 14 avril 2026, quatre jours après le déploiement de la solution, les emails d'alerte de modération ont cessé complètement. De l'extérieur, un passage soudain à zéro est indistinguishable d'un pipeline défectueux : un classificateur qui échoue en mode ouvert, une panne, un déclencheur abandonné. Il a fallu lire les données sous-jacentes pour distinguer « sain et silencieux » de « sombre et silencieux ». Une fois que nous avons eu accès au stockage supprimé, nous avons audité chaque verdict de Mistral Small accumulé depuis le déploiement du 10 avril 2026 : 40 lignes supprimées, et selon notre lecture, aucune ne correspondait à une menace réelle indûment ignorée. Le chemin confirmé s'est aligné exactement sur la même période, avec 23 événements confirmés pour 23 emails d'alerte. Le filet était intact. Mais la seule façon de le savoir était d'auditer ce qui était devenu silencieux.

Ainsi, la deuxième étape nécessite sa propre évaluation, selon son propre calendrier. Le stockage supprimé est désormais vérifié mensuellement pour détecter une indulgence excessive du juge, et un simple comptage quotidien sur la table des événements confirmés permet de surveiller un pipeline qui deviendrait silencieux. La leçon n'est pas « ajoutez un juge LLM ». Elle est : lorsque vous corrigez une défaillance visible avec un composant plus silencieux, prévoyez un budget pour auditer le silence, sinon vous aurez échangé un problème mesurable contre un problème que vous ne pouvez pas mesurer.

Une liste de contrôle portable

Si vous utilisez un classificateur polyvalent sur un corpus spécialisé — médical, juridique, sécurité, finance ou conformité — avant de faire confiance à ses résultats :

• Vérifiez l'existence d'une collision de vocabulaire. Listez le vocabulaire de travail normal de votre domaine. Si ces mots chevauchent les catégories de danger du classificateur, sa précision sur votre trafic est une question ouverte, pas une hypothèse. Mesurez-la.
• Lisez les alertes, ne vous contentez pas de les compter. Un chiffre de précision cache le schéma ; les faux positifs individuels le révèlent. Quinze alertes ne nous ont rien appris jusqu'à ce que nous les lisions une par une.
• Évaluez honnêtement le coût du surblocage. Retracez ce qu'un faux positif déclenche en aval. Fatigue des alertes, un verrouillage de suppression qui entre en conflit avec un droit à l'oubli légal, une étiquette que vous ne pouvez pas justifier. Le surblocage est rarement gratuit.
• Si le classificateur est fixe, enveloppez-le, ne le combattez pas. Lorsque vous ne pouvez pas instruire le modèle, ajoutez une étape adaptée au domaine autour de lui plutôt que de désactiver des catégories en bloc.
• Échelonnez l'enveloppe en mode sécurisé. Une erreur du juge doit entraîner une escalade, jamais une suppression, afin qu'une panne de l'enveloppe ne puisse pas ouvrir silencieusement le filet.
• Donnez à l'étape silencieuse son propre audit. Tout composant qui supprime silencieusement nécessite un examen programmé de ce qu'il a supprimé, ainsi qu'une vérification de disponibilité permettant de distinguer « sain et silencieux » de « sombre ».

Limites

Il s'agit d'un seul produit, d'un seul domaine et d'un petit échantillon : 15 alertes sur une fenêtre unique de 17 jours se terminant le 10 avril 2026, plus 40 lignes supprimées dans les semaines qui ont suivi. Il s'agit d'un résultat ponctuel sur l'alias mistral-moderation-latest tel qu'il était résolu pendant cette fenêtre, formulé comme notre propre mesure sur notre propre trafic. Ce n'est pas une affirmation générale sur la qualité de ce classificateur en dehors de notre domaine. Le taux d'erreur propre au juge est limité par le mode sécurisé par défaut, mais il n'est pas nul, ce qui explique précisément pourquoi il est audité plutôt que fait confiance. Ce en quoi nous avons confiance, c'est le mécanisme : lorsque le vocabulaire du danger et le vocabulaire du domaine sont les mêmes mots, la précision d'un classificateur polyvalent est une mesure que vous devez prendre, et non une propriété que vous pouvez supposer.