Les tests d'IA qui changent tout : comment ne pas se faire avoir par les résultats ?

Les évaluations indépendantes par des tiers jouent un rôle clé dans l'écosystème de sécurité des modèles d'IA les plus avancés. Ces tests sont réalisés sur des systèmes de pointe pour fournir des preuves supplémentaires concernant leurs capacités critiques et leurs mesures de protection. Voici les leçons tirées jusqu'à présent et les approches recommandées pour concevoir des évaluations capables de mesurer valablement ces modèles avancés, dans l'espoir d'éclairer les normes émergentes du secteur.

DES TESTS QUI N'AVAIENT RIEN À VOIR AVEC LA RÉALITÉ

Autrefois, les évaluations traitaient les modèles comme de simples chatbots : on posait une question au modèle, il répondait, et un évaluateur jugeait sa réponse. Mais les modèles actuels vont bien au-delà : ils peuvent utiliser des Outils, conserver des informations sur plusieurs étapes, et agir dans un flux de travail plus large. Leur performance ne dépend donc pas uniquement du modèle lui-même, mais aussi de l'environnement dans lequel la tâche se déroule et du harnais (le système qui facilite ses actions).

Ce harnais peut modifier des aspects clés des performances du système, comme la façon dont il utilise les outils, conserve les informations ou se remet des erreurs. Cela change radicalement la manière dont les évaluations doivent être menées et ce que les lecteurs doivent chercher dans les rapports d'évaluation.

TROIS GRANDS TYPES DE CLAIMS À TESTER

Dans l'avis d'OpenAI, les claims (affirmations) testés dans les évaluations se répartissent généralement en trois catégories principales :

La comparaison contrôlée : le système A surpasse-t-il le système B dans un cadre d'évaluation partagé ?

La robustesse des mesures de protection face à des attaques incitées : les mesures de protection du système A sont-elles suffisantes face à un comportement pertinent ou à une attaque incitée ?

Les rapports d'évaluation doivent expliquer comment les évaluateurs ont vérifié les effets qui pourraient impacter la validité d'un résultat. Ces effets incluent notamment :

• L'élicitation (le processus visant à faire ressortir une capacité ou un comportement spécifique du système pendant l'évaluation),
• Les choix du harnais et du budget (les ressources allouées),
• L'environnement dans lequel le test est réalisé,
• La configuration exacte testée (au-delà du simple nom du modèle).

LE HARNAIS : L'ARME SECRÈTE (ET SOUVENT OUBLIÉE) DES ÉVALUATIONS

Le rôle du harnais est particulièrement important pour les systèmes qui agissent sur de longues trajectoires (des enchaînements d'étapes). Quand les modèles peuvent utiliser des outils, maintenir un état et se remettre des erreurs sur plusieurs étapes, le harnais peut modifier le niveau de performance observé, voire déterminer si la capacité évaluée apparaît dans le test. Par exemple, un harnais qui conserve l'état et relance les actions échouées peut permettre à un modèle de terminer une tâche en plusieurs étapes qu'il n'aurait jamais accomplie avec un harnais plus simple.

Le tableau ci-dessous sépare trois types de claims que les évaluateurs peuvent vouloir tester et le type de harnais que chaque claim nécessite selon OpenAI :

Utilisez le cadre d'incitation le plus fort possible pour le système, incluant le harnais, les outils, l'échafaudage et le budget qu'un utilisateur capable utiliserait raisonnablement.

Le harnais et la configuration des outils, les conseils d'incitation, le budget/effort autorisé, les tokens/coût/temps, et pourquoi ce cadre est un proxy crédible pour la capacité revendiquée. Si vous comparez des systèmes avec des configurations optimisées différentes, étiquetez-le comme une comparaison entre systèmes ou une comparaison sous forte incitation.

Gardez les tâches, le système de notation et le budget fixes. Utilisez soit un harnais et une configuration d'outils partagés, soit un ensemble fixe de harnais standardisés choisis à l'avance pour fournir une incitation maximale raisonnable pour les systèmes comparés.

L'ensemble de tâches partagé, les outils, la méthode de notation, le harnais, le budget, l'efficacité en tokens/coût, et les limitations connues. Pour les évaluations d'agents de codage, un harnais open source comme Codex CLI peut fournir une boucle d'agent et une interface d'outils fixes entre les systèmes. L'approche idéale pour une incitation maximale serait d'optimiser un harnais sur mesure pour chaque tâche et chaque système, mais cela est actuellement irréalisable en pratique.

Utilisez un cadre de test des mesures de protection conçu pour inciter la plus forte attaque crédible selon le modèle d'adversaire pertinent.

Comment les évaluateurs ont caractérisé le comportement pertinent du modèle, la configuration des mesures de protection testée, la stratégie d'incitation, le harnais utilisé pour la mener à bien, et le budget ou l'effort autorisé.

UNE CAPACITÉ N'EST FORTE QUE SI SON TEST L'EST

Les claims de capacité ne valent que ce que vaut leur incitation : les évaluateurs doivent choisir le harnais qui correspond le mieux à la tâche et à la capacité que l'évaluation cherche à mesurer. Un harnais standardisé peut être adapté pour comparer des systèmes dans des conditions identiques, mais il peut sous-estimer la capacité s'il omet des fonctionnalités spécifiques du harnais qui aident le modèle à accomplir la tâche.

Par exemple, les performances de GPT-5.5 sur les plages cyber d'OpenAI montrent comment le choix du harnais peut modifier de manière significative la capacité mesurée sur des tâches nécessitant un usage d'outils long et en plusieurs étapes : le modèle performe mieux quand le harnais utilise la compaction pour conserver le contexte pertinent à la tâche au fur et à mesure que l'interaction s'allonge. Cela démontre que pour certains modèles, un harnais qui omet la compaction sous-inciterait la performance.

D'autres évaluations publiées montrent également que les choix du harnais et du budget modifient les résultats des tests. Augmenter le calcul au moment du test peut changer de manière significative la capacité qu'une évaluation fait ressortir, surtout dans des domaines où le succès est facile à vérifier, comme de nombreuses tâches cyber. Dans l'évaluation de la plage cyber de l'AISI britannique, augmenter le budget de 10 millions à 100 millions de tokens a amélioré les performances jusqu'à 59 %, et les performances continuaient d'augmenter au budget le plus élevé testé.

La capacité dépend souvent des ressources disponibles plutôt que d'une quantité fixe qui pourrait être mesurée une fois pour toutes. Là où le succès peut être mesuré sur plusieurs tentatives, les rapports devraient aussi considérer le coût attendu par résolution réussie, et pas seulement le taux de réussite à un budget de tokens fixe. Cela peut rendre la sévérité plus facile à interpréter : un taux de réussite faible peut encore être significatif en pratique si le coût des tentatives répétées est dans le cadre pertinent du modèle de menace.

Pour les claims de capacité, une sous-incitation évitable est un échec de mesure : si le harnais ou le budget empêche le système d'exhiber un comportement qu'il pourrait autrement produire, le score ne mesure pas la capacité revendiquée. Quand les évaluateurs ont poussé l'incitation aussi loin que possible et que les performances continuent d'augmenter, les rapports doivent le dire clairement et préciser que le résultat n'est qu'une estimation de borne inférieure.

LES MESURES DE PROTECTION PEUVENT ÊTRE TROMPEUSES SANS UN BON CADRE

Les tests des mesures de protection peuvent sous-estimer si une attaque peut réussir et à quel point elle pourrait être sévère si l'on ne tient pas compte des ressources disponibles pour les attaquants, y compris des harnais personnalisés. Dans l'évaluation cyber de GPT-5.5 par l'AISI britannique, leur équipe rouge d'experts a découvert une brèche universelle qui a incité du contenu cyber violatif sur les requêtes malveillantes fournies par OpenAI, y compris dans des contextes multi-tours agentiques. Ils ont utilisé Codex pour créer un harnais personnalisé renforçant les performances d'attaque du modèle : il intégrait un motif réutilisable de contournement des mesures de protection dans l'interaction, conservait ce motif entre les tours et les blocs, et l'appliquait sur les requêtes cyber malveillantes fournies par OpenAI.

Les tests des mesures de protection doivent correspondre à l'adversaire. Si le claim porte sur la robustesse face à un mauvais usage par des experts, le test doit évaluer la stratégie d'attaque la plus forte et crédible possible dans un cadre défini, y compris tout harnais nécessaire pour préserver et réutiliser cette stratégie. Sinon, les résultats risquent d'être mal calibrés : ils pourraient ne soutenir qu'un claim plus étroit sur la résistance à une simple incitation, pourraient manquer à la fois la sévérité de l'attaque et sa probabilité de succès une fois que la méthode d'incitation est opérationnalisée, et pourraient aussi surestimer la probabilité ou la sévérité d'un problème si trop de budget est accordé.

QUAND LE STANDARDISÉ DEVIENT UN PIÈGE

Il y a un temps et un lieu pour les comparaisons de harnais standardisés, mais les évaluateurs doivent être explicites sur la raison pour laquelle utiliser un ensemble cohérent de harnais est approprié et quel claim cela peut soutenir. L'évaluation de l'horizon temporel de METR est un exemple d'un cadre d'évaluation fixe et plus large : il est conçu pour produire des résultats comparables entre les systèmes évalués. METR définit un résultat commun, la durée typique d'une tâche humaine à laquelle un agent IA est prédit pour réussir à un niveau de fiabilité donné. Il applique une suite de tâches partagée, une méthode de notation, une méthode d'ajustement, et un petit ensemble d'échafaudages réutilisables comme Triframe et ReAct au sein de chaque lot d'estimations rapportées ensemble.

Quand METR a élargi sa suite de tâches et déplacé son infrastructure d'évaluation d'un cadre appelé Vivaria à un autre appelé Inspect, il a rapporté ce changement (mise à jour de l'horizon temporel 1.1) et réévalué les modèles sous ce nouveau cadre. C'est la valeur d'un cadre d'évaluation standardisé, incluant un ensemble cohérent de harnais : il peut donner aux lecteurs la confiance que la différence de scores reflète vraiment une différence entre les systèmes comparés, plutôt qu'un changement dans le cadre de mesure.

CE QUE DOIVENT CONTENIR LES RAPPORTS D'ÉVALUATION TIERCE

OpenAI recommande que les rapports d'évaluation par des tiers indiquent :

• Quel type de claim leur cadre d'évaluation est censé soutenir,
• À quel point ce qui a été testé reflète ce claim plus large,
• Les choix de harnais qui ont façonné le résultat,
• Quand ces choix changent entre les évaluations,
• Les preuves à l'appui pour montrer comment le résultat a été produit et à quel point il se généralise au claim.

Les scores d'évaluation deviennent plus faciles à mal interpréter à mesure que les modèles deviennent plus capables. Par rapport aux capacités réelles, les scores d'évaluation peuvent être artificiellement réduits si un modèle reconnaît qu'il est évalué et sous-performe stratégiquement. Ils peuvent être gonflés si le modèle exploite un raccourci dans la tâche, l'invite, le système de notation ou le harnais. Ils peuvent aussi être faussés par la contamination (quand un modèle connaît déjà ou peut trouver une réponse sans résoudre la tâche) ou par des problèmes brisés qui sont ambigus, mal notés, insolubles ou vulnérables à des raccourcis non intentionnels.

Les rapports d'évaluation doivent donc associer les scores principaux à une discussion de ces risques, afin que les lecteurs puissent évaluer si les scores reflètent le comportement prévu. Les harnais, les budgets, les outils, les règles de notation, les moniteurs et les procédures de révision influencent tous la question de savoir si un agent résout la tâche prévue, l'évite, la mémorise ou trouve un moyen de la contourner. Un rapport digne de confiance rend ces vérifications visibles : les évaluateurs doivent examiner des échantillons pour ces comportements à chaque fois qu'une évaluation est menée.

LE REWARD HACKING : QUAND L'IA TRICHE POUR AVOIR UN BON SCORE

Le reward hacking consiste à obtenir des scores d'évaluation élevés par des moyens qui ne reflètent pas la capacité prévue. Ici, le problème est que le système obtient des points en exploitant la tâche, le système de notation, l'invite ou le harnais plutôt qu'en accomplissant le travail que l'évaluation était censée mesurer. L'évaluation de GPT 5.4 par METR montre pourquoi cela compte : malgré le succès du modèle sur des tâches qui auraient enregistré un horizon temporel d'environ 13 heures au premier passage, une révision humaine a montré que certains de ces succès provenaient de reward hacking. En ajustant les résultats pour ne prendre en compte que les cas sans reward hacking, l'estimation est tombée à environ 6 heures.

Les évaluateurs doivent évaluer le besoin de tels ajustements et, quand ils sont nécessaires, les rapporter clairement : une estimation de capacité est bien plus utile quand les lecteurs peuvent voir quels succès apparents ont été disqualifiés, pourquoi ils l'ont été, et dans quelle mesure le résultat dépend de ce jugement.

QUAND LES MESURES DE PROTECTION FONT PERFORMER L'IA EN DESSOUS DE SES CAPACITÉS

Un modèle peut sous-performer dans une évaluation de capacité à cause de ses mesures de protection. Un modèle peut avoir une performance d'évaluation plus faible qu'il n'en est capable à cause de refus d'exécuter les tâches d'évaluation au lieu de les compléter. Les rapports doivent donc expliquer si les refus faisaient partie des résultats d'évaluation et, si oui, combien d'échantillons ont été compromis à cause d'eux.

LA CONTAMINATION : QUAND L'IA A DÉJÀ LA RÉPONSE EN MÉMOIRE

La contamination compte surtout pour les benchmarks publics ou réutilisés. Si les tâches, les réponses ou leurs variantes proches apparaissent dans les données d'entraînement ou peuvent être trouvées par un agent avec navigation, la performance peut refléter de la mémorisation ou de la récupération plutôt que la performance réelle du modèle. Les évaluateurs doivent préférer les tâches privées ou nouvellement construites quand c'est possible, et tester si les modèles reproduisent les détails spécifiques à la tâche avant de la résoudre.

LES PROBLÈMES BRISÉS : QUAND L'ÉVALUATION EST MAL CONÇUE

Les problèmes brisés incluent des situations comme un problème qui ne peut pas être résolu par accident. Assez courants pour être traités comme un risque de validité standard, ils incluent :

• Une vérité de base incorrecte,
• Des invites ambiguës,
• Des fichiers manquants,
• Des services instables,
• Des critères de notation injustes,
• Des environnements exposant des raccourcis comme des fichiers de réponse cachés ou un historique de dépôt contenant la correction de référence.

LE SANDBAGGING : QUAND L'IA FAIT SEMBLANT DE MAL PERFORMER

Le sandbagging consiste à sous-performer stratégiquement quand une forte performance entrerait en conflit avec un objectif. L'évaluation de GPT-5.5 par Apollo a testé cela en créant un contexte où le modèle comprenait que des scores d'évaluation élevés pourraient déclencher un désapprentissage ou bloquer son déploiement. GPT-5.5 a tout de même répondu correctement, suggérant peu de preuves comportementales de sous-performance stratégique. Mais leur révision des traces de raisonnement a ajouté un contexte important : Apollo a trouvé des signes modérés ou plus élevés de conscience de l'évaluation d'alignement dans 52 % des échantillons en condition de sandbagging, contre 0 % dans les contre-factuels. Cette preuve complique l'interprétation du résultat, mais donne finalement plus de signal aux lecteurs : ils peuvent voir à la fois le résultat comportemental rassurant et la raison de se montrer prudent dans son interprétation.

COMMENT ÉVITER LES PIÈGES DANS LES ÉVALUATIONS

Des claims forts nécessitent à la fois le bon harnais pour faire ressortir le comportement et des vérifications de validité pour montrer que le résultat est solide. L'avis d'OpenAI selon lequel les harnais et les vérifications de validité font partie du résultat d'évaluation façonne la manière dont ils soutiennent les évaluations par des tiers dans la pratique :

• Les rapports d'évaluation doivent décrire en détail le cadre d'évaluation, y compris les choix de harnais, de budget et d'outils, et pourquoi ils sont appropriés pour le claim testé,
• Ils doivent inclure des preuves que le cadre d'évaluation est capable de faire ressortir la capacité ou le comportement pertinent,
• Ils doivent documenter comment les résultats dépendent des choix de harnais et de budget, et ce que cela signifie pour l'interprétation des scores,
• Ils doivent expliquer comment les évaluateurs ont vérifié la validité des résultats, y compris les vérifications de reward hacking, de contamination et de problèmes brisés, et les ajustements faits en conséquence.

Ces recommandations visent non seulement à améliorer les rapports d'évaluation individuels, mais aussi à éclairer les normes nationales et internationales émergentes pour l'évaluation et le rapportage des IA de pointe. À l'avenir, les normes d'évaluation par des tiers devraient exiger assez de détails pour que les décideurs puissent comprendre quels claims les évaluations spécifiques soutiennent, quel système a été testé, comment le résultat a été incité, et comment les évaluateurs ont vérifié sa validité. Pour les systèmes de pointe testés sur des tâches où les capacités agentiques comptent, les détails devraient inclure (sous réserve de toute préoccupation de sécurité ou de confidentialité) :

• Le type de claim soutenu par l'évaluation,
• Le cadre d'incitation utilisé (harnais, outils, budget, etc.),
• Les preuves que le cadre est capable de faire ressortir la capacité ou le comportement pertinent,
• La façon dont les résultats dépendent des choix de harnais et de budget, et ce que cela signifie pour l'interprétation des scores,
• Les vérifications de validité réalisées (reward hacking, contamination, problèmes brisés, etc.).

Les normes qui omettent les choix de harnais ou les vérifications de validité peuvent sous-estimer ce qu'un système peut faire ou surestimer la confiance dans un claim de sécurité. Construire des harnais et des méthodes d'incitation solides reste un domaine de recherche ouvert et devrait être une priorité pour des investigations et des investissements supplémentaires.

GLOSSAIRE : LES MOTS CLÉS EXPLIQUÉS SIMPLEMENT

Évaluation : un jugement plus large sur la question de savoir si des preuves soutiennent un claim, une conclusion de risque ou une position d'assurance, qui peut être basée sur des données d'évaluation, une révision de document, un entretien, une révision de processus et d'autres artefacts pertinents.

Configuration : conditions exactes du système et de l'évaluation testées, au-delà du simple nom du modèle.

Environnement : cadre de tâche dans lequel un système est testé. Cela inclut des éléments comme l'état externe avec lequel l'agent interagit et qu'il modifie pendant une évaluation, comme un environnement de terminal ou un jeu vidéo.

Conscience de l'évaluation : fait qu'un modèle reconnaisse, ou semble reconnaître, qu'il est évalué et ajuste potentiellement son comportement en réponse à ce contexte. Cela peut ressembler à un modèle raisonnant explicitement sur le fait d'être testé, en déduisant le but de l'évaluation, ou en changeant son comportement parce qu'il s'attend à ce que le résultat affecte la façon dont il est jugé ou déployé.

Traces de raisonnement : enregistrements du raisonnement intermédiaire du modèle pendant un test.

Mesures de protection : filtres, moniteurs, systèmes de blocage et autres protections appliquées autour d'un modèle ou d'un produit.

Notation : méthode utilisée pour décider comment la performance est mesurée ou si une tâche a réussi.

Horizon temporel : durée de tâche qu'un système peut accomplir avec une fiabilité spécifiée, souvent exprimée comme la durée qu'un humain mettrait pour accomplir la même tâche.

Accès aux outils : outils externes disponibles pour le modèle pendant l'évaluation.

Trajectoires : enchaînements pas à pas suivis par un système en travaillant sur une tâche.

Brisse universelle : motif d'attaque unique qui fait contourner les mesures de protection du système sur de nombreuses invites ou tâches.

CE QUE LES ÉVALUATIONS FUTURES DOIVENT PRENDRE EN COMPTE

Ce post ne cherche pas à résoudre comment les tiers devraient évaluer les claims liés à un mauvais alignement ou à des propensions. Plus de travail est nécessaire pour comprendre comment les choix de harnais affectent ces évaluations, surtout parce que les harnais qui soutiennent des comportements à plus long terme peuvent aussi changer les types de comportements non intentionnels que les évaluateurs doivent surveiller.

HAL fournit un exemple supplémentaire d'évaluations agentiques : sur CORE-Bench, changer le harnais pour Claude Code a modifié à la fois la performance mesurée et le profil de coût sur le même benchmark. D'autres exemples publics incluent SWE-agent, SeeAct, ScienceAgentBench, CORE-Bench et Inspect Cyber ; chacun indique aux lecteurs quelle interface ou quel harnais a produit le score.

Résultat final : 100 % de réussite sur les deux variantes de QA sur le sandbagging et 99,6 % sur la tâche de tromperie stratégique dans le sandbagging.