Deux pièges méthodologiques qui gonflent les scores des détecteurs d'injection de prompt

De quoi s’agit-il ?

Le 1ᵉʳ juin 2026, Ryle Goehausen et Marcus Sousa (Constellation Network) ont publié sur arXiv Gate AI: LLM Security Benchmark Evaluation Methodology & Results (article daté du 27 mai 2026). Ce n’est pas un article d’attaque. C’est un article de méthodologie sur la manière dont les détecteurs d’injection de prompt et de jailbreak — ces classifieurs de garde-fou que vous placez devant un LLM pour intercepter les entrées hostiles — sont évalués, et sur les raisons pour lesquelles leurs chiffres publiés ne sont souvent pas comparables.

Les auteurs nomment deux faiblesses systématiques récurrentes dans le domaine : le réglage de seuil par jeu de données et les points de fonctionnement non divulgués. Toutes deux font paraître un détecteur meilleur sur le papier qu’il ne le sera en production. L’article décrit ensuite un harnais d’évaluation qui élimine les deux, exécuté sur 16 benchmarks publics totalisant 12 111 échantillons.

Comment ça marche

Un détecteur binaire produit un score ; vous choisissez un seuil au-delà duquel une entrée est signalée. Déplacez le seuil et vous arbitrez entre faux négatifs (attaques manquées) et faux positifs (trafic légitime bloqué). Le couple de taux d’erreur auquel vous opérez réellement constitue le point de fonctionnement.

Le premier piège, le réglage de seuil par jeu de données, consiste à choisir un seuil différent pour chaque benchmark afin que la métrique principale culmine sur chacun. Le classement publié reflète alors un détecteur réajusté par jeu de test — un réglage qu’il ne pourra pas effectuer face à un trafic réel et mélangé. Gate AI sélectionne au contraire un point de fonctionnement global unique sur des plis exclus (F1 maximal sous contrainte d’un taux de faux positifs ≤ 1 %) et applique ce seuil unique uniformément à tous les jeux de données.

Le second piège, les points de fonctionnement non divulgués, consiste à publier un chiffre de précision sans y associer le taux de faux positifs. Une affirmation de « 92 % de détection » n’a aucun sens si l’on ignore combien de prompts légitimes ont été bloqués pour y parvenir. La solution de l’article pour la comparaison directe est le FPR apparié : réglez votre propre détecteur sur le taux de faux positifs publié par le concurrent avant de comparer, afin que les deux se situent au même point de fonctionnement. Lorsqu’un concurrent ne publie que la métrique principale sans taux de faux positifs — ce qui arrive sur certains benchmarks publics, notent les auteurs —, aucune comparaison honnête n’est possible.

Le harnais s’appuie sur une discipline standard mais rarement reportée : validation croisée à 5 plis avec une partition parallèle sensible aux quasi-doublons (MinHash + LSH, Jaccard ≳ 0,8) pour détecter les fuites entre prompts frères, plus une batterie de diagnostics de généralisation — leave-one-dataset-out, un contrôle à étiquettes aléatoires qui doit s’effondrer vers le F1 du hasard (confirmant l’absence de fuite par identité de ligne), une validation adversariale visant une AUC ≈ 0,5, une corrélation de biais de longueur et une sonde d’invariance par paraphrase. Un résultat notable : un benchmark fortement axé jeu de rôle (ilion-bench) se situe bien en dessous de la moyenne macro en leave-one-dataset-out, rappel concret qu’un détecteur entraîné sur une distribution de prompts se dégrade sur une autre.

Pourquoi c’est important

Les benchmarks de détecteurs sont des guides d’achat. L’exemple le plus connu du genre est le benchmark PINT de Lakera, dont le jeu de données et le harnais publics maintiennent délibérément les entrées de test hors de tout entraînement d’éditeur. PINT existe précisément parce que les chiffres inter-éditeurs n’étaient pas comparables — et l’argument de Gate AI est que même un benchmark soigné perd son sens dès lors que les seuils sont réglés par jeu de données ou que les points de fonctionnement ne sont pas reportés.

Pour un défenseur, le risque pratique est simple : vous choisissez un garde-fou sur la foi d’une précision affichée, vous le déployez à seuil fixe face à un trafic mélangé, et vous découvrez que son taux de faux négatifs réel est plus élevé — ou que son taux de faux positifs (utilisateurs légitimes bloqués) est bien plus élevé — que ne le laissait croire le classement. Le chiffre était exact ; il décrivait simplement un autre point de fonctionnement que celui auquel vous opérez.

Défenses

Considérez tout benchmark de détecteur comme non fiable tant qu’il ne répond pas à la question du point de fonctionnement. Vérifications concrètes :

1. Exigez le FPR avec chaque chiffre de détection. Un chiffre de détection ou de F1 sans taux de faux positifs déclaré est ininterprétable. Si un éditeur ne peut pas vous indiquer le point de fonctionnement, vous ne pouvez pas mesurer le coût utilisateur de son garde-fou.

2. Imposez un seuil unique pour tous les jeux de données. Demandez si les résultats par jeu de données reposent sur un seuil global unique ou sur un réglage par benchmark. Si c’est par jeu de données, dépréciez le classement : il ne se reproduira pas sur votre trafic.

3. Comparez à FPR apparié. Pour départager deux détecteurs, fixez le même taux de faux positifs pour les deux et comparez la détection à ce point. Des points de fonctionnement différents rendent les chiffres bruts inexploitables.

4. Effectuez vous-même un contrôle de fuite et de hasard. Excluez un jeu de données que le détecteur n’a jamais vu (leave-one-dataset-out) et exécutez un contrôle à étiquettes aléatoires. Si le F1 à étiquettes mélangées ne s’effondre pas vers le hasard, l’évaluation fuit par identité de ligne et le chiffre principal est gonflé.

5. Testez sur votre propre distribution. La chute sur ilion-bench montre que les détecteurs entraînés sur un style de prompt se dégradent sur un autre. Avant de faire confiance à un garde-fou, évaluez-le sur un échantillon de votre trafic réel — y compris les cas limites légitimes —, pas sur le jeu de données soigné de l’éditeur.

6. Gardez le garde-fou comme une couche, pas comme toute la défense. Même bien mesuré, un détecteur reste un filtre probabiliste. Associez-le à des contrôles architecturaux — moindre privilège sur les outils, filtrage des sorties, les vérifications de la trifecta létale — afin qu’une détection manquée ne se traduise pas par une compromission totale.

État des lieux

Élément	Référence	Date	Notes
Préprint méthodologique Gate AI	arXiv:2606.02959v1 [cs.LG]	2026-06-01	Goehausen & Sousa, Constellation Network ; CC BY 4.0
Corpus	Gate AI	2026-06-01	16 benchmarks publics, 12 111 échantillons, validation croisée 5 plis
Point de fonctionnement global	Gate AI	2026-06-01	F1 max sous FPR ≤ 1 %, appliqué uniformément
Benchmark PINT	Lakera	en cours	4 314 entrées, publiques + propriétaires ; concurrent nommé dans l’article

La leçon n’est pas « les détecteurs ne fonctionnent pas » — c’est que la précision publiée d’un détecteur est une affirmation portant sur un point de fonctionnement, sur un ensemble de jeux de données. Faites énoncer le point de fonctionnement par les éditeurs, comparez à taux de faux positifs apparié, et validez sur votre propre trafic avant de vous fier au chiffre.