Évaluation, benchmarking et red teaming

Les scores des benchmarks publics ne vous disent presque rien sur la manière dont un système d'IA fonctionnera dans votre déploiement. Nous concevons des harnais d'évaluation, des benchmarks propres à votre domaine et des programmes structurés de red teaming qui mesurent si les systèmes d'IA fonctionnent réellement pour votre cas d'usage — face à vos données, à vos cas limites et à vos contraintes de coût et de sécurité.

Pourquoi les benchmarks publics passent à côté de votre déploiement

Les modèles de pointe se regroupent au-dessus de 88 % sur MMLU. GPT-5.3 Codex obtient 99 %. Le Leaderboard LLM 2025 de Vellum a entièrement abandonné MMLU car il ne différencie plus les modèles de manière significative. MMLU-Pro, conçu pour corriger cela, approche déjà les 90 % pour les modèles de pointe. Les benchmarks les plus cités du secteur sont devenus des indicateurs de vanité.

Le problème plus profond, c'est la pertinence. Un score de benchmark ne prédit la performance en production que sous trois conditions :

• Il teste des tâches similaires aux vôtres.
• Le jeu de test est exempt de contamination des données — certains benchmarks présentent des taux de fuite atteignant 100 %.
• Les écarts de score sont statistiquement significatifs.

Pour la plupart des déploiements en entreprise, aucune de ces conditions n'est remplie. Le classement peut s'inverser complètement dès que vous testez sur vos propres données — le modèle n° 3 des classements publics peut surpasser le n° 1 de 40 % sur une véritable tâche d'extraction. C'est précisément le type d'écart qu'un harnais d'évaluation sur mesure est conçu pour faire apparaître, ce qui explique pourquoi répondre à « quel modèle est le plus performant sur mes données, mes cas limites, sous mes contraintes de coût ? » exige une infrastructure d'évaluation conçue pour votre déploiement.

Les trois couches d'un programme d'évaluation rigoureux

Nous structurons l'évaluation autour de trois couches, chacune répondant à une question différente sur votre système d'IA.

Évaluation de la capacité — Fait-il ce dont nous avons besoin ?

Nous construisons des suites de tests propres à la tâche à partir de vos données de production et de cas limites réalistes, non pas d'échantillons de convenance. Pour un modèle de souscription, cela signifie tester sur de véritables demandes refusées, des cas frontière et les formats de documents spécifiques que rencontre votre pipeline.

Chaque cas de test est documenté avec la méthodologie de collecte et les indicateurs de qualité d'annotation. Nous mesurons avec rigueur statistique — exécutions multiples avec différentes graines, intervalles de confiance par bootstrap et tests de significativité appariés. Une amélioration de 2 % qui tombe à l'intérieur de l'intervalle de confiance n'est pas une amélioration.

Évaluation de la sûreté — Où échoue-t-il, et à quel point gravement ?

Nous testons les frontières comportementales à l'aide de sondes structurées : tests de fonctionnalité minimale, tests d'invariance (la sortie change-t-elle alors qu'elle ne le devrait pas ?) et tests d'attente directionnelle. L'évaluation désagrégée rend compte de la performance sur chaque tranche de données pertinente d'un point de vue opérationnel, car un modèle qui fonctionne en moyenne mais échoue sur une sous-population critique n'est pas sûr à déployer, comme le détaille notre recherche sur les raisons pour lesquelles les taux de défaillance rares mais catastrophiques ne peuvent être écartés.

Évaluation adversariale — Peut-on le faire mal se comporter ?

Cette couche demande si quelqu'un peut faire faire au système quelque chose qu'il ne devrait pas faire. C'est là que réside le red teaming.

Le red teaming comme appréciation structurée des capacités

Le red teaming n'est pas un test d'intrusion sous un autre nom. L'appréciation de sécurité demande « un attaquant peut-il compromettre ce système ? » Le red teaming, dans le contexte de l'évaluation, demande « quelles sont les frontières du comportement de ce système, et où ces frontières cèdent-elles ? » Les méthodologies se recoupent, mais les questions, les rapports et le public sont différents.

Nous opérons selon une méthodologie structurée bâtie sur la taxonomie NIST AI 100-2 E2025 , qui s'est considérablement élargie en mars 2025 pour couvrir les vulnérabilités des agents d'IA autonomes et les catégories d'attaques propres à l'IA générative. Nos programmes de red team suivent une séquence définie :

1. Définition du modèle de menace circonscrite au contexte de votre déploiement.
2. Énumération de la taxonomie d'attaques couvrant les catégories de l'OWASP LLM Top 10 v2 — injection de prompt, jailbreaking, empoisonnement des données, injection indirecte via du contenu récupéré, attaques multimodales et évasion par encodage.
3. Exécution systématique des attaques selon des procédures documentées.
4. Constats notés par niveau de gravité avec étapes de reproduction.

Red teaming humain et automatisé

Nous complétons le red teaming humain par des pipelines adversariaux automatisés. Cascade de Haize Labs atteint des taux de réussite d'attaque de 44 % sur les modèles de pointe, 4 fois supérieurs aux références à un seul tour. Promptfoo exécute plus de 50 types de vulnérabilités en CI/CD sur plus de 300 000 installations de développeurs. Les outils automatisés détectent les schémas connus à grande échelle ; les red teamers humains trouvent des vulnérabilités inédites que les systèmes automatisés n'ont jamais vues — ce qui compte le plus là où les conséquences d'un mode de défaillance manqué sont graves.

Ce que livre chaque mission

Chaque mission de red team est cadrée pour produire trois livrables :

• Un rapport de constats avec niveaux de gravité et procédures de reproduction.
• Des recommandations de remédiation rattachées à votre architecture.
• Une suite de tests de régression automatisés dérivée des vulnérabilités découvertes, qui s'intègre à votre pipeline de déploiement, afin que les faiblesses découvertes restent corrigées.

Quand l'évaluation automatisée fonctionne — et quand elle ne fonctionne pas

L'évaluation par LLM-juge — utiliser un modèle de pointe pour noter les sorties d'un autre modèle — est devenue la solution par défaut pour les équipes qui ne peuvent pas se permettre l'évaluation humaine à grande échelle. Elle est utile. Elle est aussi peu fiable de manières spécifiques et documentées. La recherche a identifié plus de 12 types de biais distincts chez les LLM juges :

• Biais d'auto-préférence — GPT-4 note plus haut les sorties à plus faible perplexité, qu'il les ait générées ou non.
• Biais de verbosité — les juges préfèrent systématiquement les réponses verbeuses et formelles aux réponses concises et correctes.
• Biais de position — les juges favorisent la réponse qui apparaît en premier, quelle qu'elle soit.

Ces biais sont gérables pour une comparaison de qualité générale grâce à des techniques de débiaisement telles que la position randomisée et les panels multi-juges. Ils sont rédhibitoires lorsque l'exactitude propre au domaine importe. Un LLM juge ne peut pas évaluer de façon fiable si un système clinique identifie correctement les interactions médicamenteuses, ou si une recherche juridique cite avec exactitude la jurisprudence. Nous recourons à la notation automatisée là où le biais est gérable et à l'examen par des experts humains là où l'exactitude exige une connaissance du domaine.

Évaluer les systèmes d'IA agentique

Le benchmarking statique de modèles ne fonctionne pas pour les agents qui planifient, utilisent des outils et exécutent des flux de travail à étapes multiples. Un seul chiffre de précision ne peut pas rendre compte de savoir si l'agent a sélectionné le bon outil, l'a appelé avec les bons paramètres, s'est rétabli sans encombre lorsqu'une étape a échoué, ou a produit un résultat cohérent sur 15 opérations enchaînées. Un agent peut exécuter correctement chaque étape individuelle et néanmoins produire un résultat erroné parce que le raisonnement reliant ces étapes était défaillant.

Nous évaluons les systèmes agentiques selon cinq dimensions issues du cadre CLEAR :

• Coût efficience de l'usage des outils et des tokens.
• Latence sur l'ensemble de l'accomplissement de la tâche.
• Efficacité de la réussite de la tâche de bout en bout.
• Assurance que les contraintes de sécurité ont tenu tout au long de l'exécution.
• Fiabilité sur des exécutions répétées.

Pour les agents utilisant des outils, nous testons aussi l'exactitude de la sélection d'outils, la justesse des paramètres (les agents fabriquent des noms de paramètres à des taux notables), le respect du périmètre et la reprise sur erreur. Pour les systèmes multi-agents, nous testons la fidélité de la communication inter-agents, la propagation des défaillances en cascade, et si les contrôles du superviseur interviennent effectivement lorsque des agents subordonnés divergent.

Les benchmarks rattrapent leur retard — SWE-bench teste de véritables tâches d'ingénierie logicielle, Terminal-Bench évalue les flux de travail d'agents en ligne de commande, et UpBench utilise de véritables offres d'emploi Upwork rafraîchies en continu. Mais les benchmarks agentiques sur étagère correspondent rarement à votre architecture d'agent, votre ensemble d'outils et votre domaine spécifiques, c'est pourquoi nous construisons des harnais d'évaluation agentique sur mesure — parce que les modes de défaillance de votre agent sont propres à sa conception.

Évaluation pour l'EU AI Act et la conformité réglementaire

Les dispositions à haut risque de l' EU AI Act entrent pleinement en vigueur le 2 août 2026. L'article 9 exige un système de gestion des risques doté d'une méthodologie d'évaluation documentée, des tests dans des conditions d'usage prévu et de mésusage raisonnablement prévisible, et une surveillance continue après commercialisation. L'évaluation de la conformité doit être achevée avant de mettre un système à haut risque sur le marché de l'UE. La non-conformité entraîne des amendes pouvant atteindre 7 % du chiffre d'affaires annuel mondial ou 35 millions EUR.

Le NIST AI 100-2 E2025 fournit la taxonomie faisant autorité pour l'évaluation adversariale, couvrant désormais les vulnérabilités des agents autonomes absentes de l'édition 2023. Ces cadres apparaissent dans les exigences d'approvisionnement et les revues de risques au niveau des conseils d'administration.

Le défi pratique : aucune norme harmonisée ne définit encore ce qu'est une « évaluation adéquate » pour la conformité à l'EU AI Act. Le CEN/CENELEC JTC 21 a manqué son échéance d'août 2025 et vise le quatrième trimestre 2026. Nous concevons des programmes d'évaluation qui produisent des preuves défendables dès maintenant tout en restant adaptables à des normes encore en cours de finalisation — une approche que nous exposons dans notre livre blanc sur l'intégrité architecturale et la responsabilité réglementaire dans l'IA générative d'entreprise.

L'évaluation continue en production

Une évaluation avant déploiement vous dit que le système fonctionnait à une date précise face à un jeu de test précis. Elle ne vous dit rien sur le mois prochain. Les modèles en production dérivent, les distributions d'entrée changent, le contenu récupéré évolue et les API des outils se mettent à jour. Un rapport LLMOps 2025 a constaté que les modèles laissés inchangés pendant six mois ont vu leurs taux d'erreur augmenter de 35 % sur de nouvelles données. Gartner estime que seulement 18 % des équipes d'ingénierie logicielle avaient adopté des plateformes d'évaluation et d'observabilité de l'IA en 2025, tout en projetant une adoption de 60 % d'ici 2028.

Nous construisons des pipelines d'évaluation qui s'exécutent en continu :

• La surveillance en production note le trafic en direct à l'aide des mêmes évaluateurs que ceux du développement.
• Les évaluations échouées deviennent des tests de régression CI/CD.
• La détection de dérive alerte lorsque les distributions d'entrée s'écartent des références.
• Des suites adversariales s'exécutent chaque nuit contre les points d'accès de production.

Il s'agit d'une infrastructure opérationnelle qui maintient l'évaluation à jour à mesure que votre système évolue.

Le paysage de l'outillage d'évaluation

Le marché est fragmenté, et chaque outil a ses angles morts. Nous utilisons chacun là où il convient et construisons des harnais sur mesure là où aucun d'eux n'atteint.