Un guide commun pour des évaluations tierces fiables

Des évaluations indépendantes et fiables menées par des tiers jouent un rôle essentiel⁠ dans le renforcement de l’écosystème de sécurité. Ces évaluations sont menées sur des modèles de pointe afin d’apporter des éléments probants supplémentaires à l’appui d’affirmations concernant des capacités critiques et des mesures d’atténuation en matière de sécurité. Dans ce billet, nous partageons les enseignements tirés jusqu’à présent et recommandons des approches pour concevoir des évaluations capables d’évaluer valablement des modèles de pointe, dans l’espoir d’éclairer les normes émergentes dans ce domaine.

Auparavant, de nombreuses évaluations traitaient les modèles comme des chatbots : l’évaluation sollicitait un modèle comme s’il s’agissait d’un utilisateur posant une question, le modèle répondait, puis un évaluateur jugeait le résultat. Les modèles de pointe d’aujourd’hui peuvent faire bien davantage : ils peuvent utiliser des outils, suivre des informations sur de nombreuses étapes et agir au sein d’un flux de travail plus large. Cela signifie que la performance dépend non seulement du modèle, mais aussi de l’environnement dans lequel la tâche se déroule, ainsi que de la configuration qui facilite ses actions. Cette configuration environnante, que nous appelons le « harnais », peut modifier des aspects clés de la performance du système, notamment la manière dont il utilise les outils, suit les informations ou se remet de ses erreurs.

Cela change la manière dont les évaluations doivent être menées, ainsi que ce que les lecteurs doivent rechercher dans les rapports d’évaluation. À notre avis, les rapports les plus utiles décrivent explicitement deux éléments au-delà du résultat lui-même : d’abord, ils précisent quelle affirmation la configuration d’évaluation a été conçue pour tester ; ensuite, ils partagent les éléments disponibles montrant que le résultat de l’évaluation est valide.

Les affirmations testées dans les évaluations relèvent généralement de l’une de ces trois catégories¹ :

• Elicitation de capacité : un modèle peut-il plausiblement produire la capacité évaluée ? 
• Performance des mesures de protection : dans quelle mesure les mesures de protection testées sont-elles robustes face au comportement ou à l’attaque évalués ?
• Comparaison : comment différents modèles se comportent-ils dans des conditions équivalentes ?

Les rapports d’évaluation doivent aussi expliquer comment les évaluateurs ont vérifié les effets susceptibles d’affecter la validité d’un résultat. Il s’agit notamment de :

• Reward hacking : exploiter des raccourcis dans la tâche ou le système de notation, de sorte que le système obtienne du crédit sans démontrer le comportement que l’évaluation est censée mesurer.
• Refus : refuser d’une manière qui masque le comportement testé.
• Contamination : surperformance due au fait que des tâches d’évaluation, des réponses ou des variantes proches figuraient dans les données d’entraînement ou étaient découvrables pendant l’évaluation, par exemple via la navigation.
• Problèmes défectueux : sous-performance due à l’invalidité des tâches. Les raisons peuvent inclure une notation injuste (par ex., la bonne réponse exige des détails d’implémentation non indiqués) et des environnements insolubles (par ex., fichiers critiques manquants ou outils peu fiables).
• Sandbagging : sous-performance délibérée lorsqu’un système montre qu’il est conscient d’être évalué.

Nous avons observé que le rôle du harnais est particulièrement important pour les systèmes qui agissent sur des trajectoires plus longues. Lorsque les modèles peuvent utiliser des outils, maintenir un état et se remettre d’erreurs sur de nombreuses étapes, le harnais peut modifier le niveau de performance observé, et même déterminer si la capacité évaluée apparaît ou non dans l’évaluation. Par exemple, un harnais qui préserve l’état et relance les actions échouées peut permettre à un modèle d’achever une tâche en plusieurs étapes que ce même modèle n’achève jamais dans un harnais plus simple.

Dans le tableau ci-dessous, nous distinguons trois types d’affirmations que les évaluateurs peuvent vouloir formuler, ainsi que le harnais que nous estimons nécessaire pour chacune.

La solidité des affirmations sur les capacités dépend de l’elicitation qui les sous-tend : les évaluateurs doivent choisir le harnais le mieux adapté à la tâche et à la capacité que l’évaluation cherche à mesurer. Un harnais standardisé peut convenir pour comparer des systèmes dans des conditions identiques, mais il peut sous-estimer une capacité s’il omet des fonctionnalités de harnais spécifiques qui aident le modèle à accomplir la tâche. Par exemple, la performance de GPT‑5.5 sur les cyber ranges d’OpenAI montre à quel point le choix du harnais peut modifier de manière significative la capacité mesurée sur des tâches exigeant un usage long et multi-étapes des outils : le modèle obtient de meilleurs résultats lorsque le harnais utilise la compaction⁠ pour préserver le contexte pertinent pour la tâche à mesure que l’interaction s’allonge. Cela montre que, pour certains modèles, un harnais qui omet la compaction sous-susciterait la performance.

D’autres évaluations publiées² montrent également que les choix de harnais et de budget modifient les résultats d’évaluation. L’augmentation du calcul au moment du test peut modifier de façon significative la capacité qu’une évaluation fait émerger, en particulier dans les domaines où la réussite est facile à vérifier, comme de nombreuses tâches cyber. Dans l’évaluation sur cyber range de l’AISI du Royaume-Uni⁠(ouverture dans une nouvelle fenêtre), le passage d’un budget de 10 M à 100 M de tokens a amélioré la performance jusqu’à 59 %, et la performance continuait encore d’augmenter au budget le plus élevé testé. Préciser cela rend l’évaluation plus interprétable : cela montre aux lecteurs dans quelle mesure le résultat dépend de la configuration d’elicitation testée. Lorsque la performance continue de s’améliorer avec un budget supplémentaire, le score doit être décrit comme une performance sous ce harnais et ce budget, et non comme un plafond de capacité mesuré. La capacité dépend souvent des ressources plutôt que d’être une quantité fixe que l’on pourrait mesurer proprement une fois pour toutes. Lorsque la réussite peut être mesurée sur des tentatives répétées, les rapports devraient aussi considérer le coût attendu par résolution réussie, et pas seulement le taux de réussite pour un budget fixe en tokens. Cela peut faciliter l’interprétation de la gravité : un faible taux de réussite peut malgré tout avoir une importance pratique si le coût des tentatives répétées reste compatible avec le modèle de menace pertinent. Pour les affirmations sur les capacités, une sous-elicitation évitable constitue un échec de mesure : si le harnais ou le budget empêche le système de manifester un comportement qu’il pourrait autrement produire, le score ne mesure pas la capacité revendiquée. Lorsque les évaluateurs ont poussé l’elicitation aussi loin que possible et que la performance continue malgré tout de s’améliorer, les rapports doivent le dire clairement et préciser que le résultat n’est qu’une estimation par borne inférieure.

Les tests de mesures de protection peuvent sous-estimer la possibilité de réussite d’une attaque, ainsi que sa gravité potentielle, s’ils ne tiennent pas compte des ressources dont disposent les attaquants, y compris des harnais personnalisés. Dans l’évaluation cyber de GPT‑5.5 par l’AISI du Royaume-Uni⁠(ouverture dans une nouvelle fenêtre), leur red teaming expert a trouvé un jailbreak universel qui suscitait du contenu cyber non conforme sur les requêtes malveillantes fournies par OpenAI, y compris dans des contextes agentiques à plusieurs tours. Ils ont utilisé Codex pour créer un harnais personnalisé afin de renforcer la performance d’attaque du modèle : il intégrait dans l’interaction un schéma réutilisable de contournement des mesures de protection, préservait ce schéma d’un tour et d’un bloc à l’autre, et l’appliquait aux requêtes cyber malveillantes fournies par OpenAI. Les tests de mesures de protection doivent correspondre à l’adversaire. Si l’affirmation porte sur la robustesse face à un usage abusif par des experts, le test doit évaluer la stratégie d’attaque de bout en bout crédible la plus forte dans un budget 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 n’étayer qu’une affirmation plus étroite sur la résistance à des prompts plus simples, manquer à la fois la gravité de l’attaque et sa probabilité de réussite une fois la méthode d’elicitation opérationnalisée, et aussi surestimer la probabilité ou la gravité d’un problème si on lui accorde un budget trop important.

Les comparaisons à l’aide de harnais standardisés ont leur place, mais les évaluateurs doivent expliquer explicitement pourquoi l’usage d’un ensemble cohérent de harnais est approprié et quelle affirmation il peut étayer. L’évaluation de l’horizon temporel de METR⁠(ouverture dans une nouvelle fenêtre) est un exemple de configuration d’évaluation plus large et correctement figée : elle est conçue pour produire des résultats comparables entre les systèmes qu’elle évalue. METR définit un résultat commun : la durée typique d’une tâche humaine pour laquelle un agent d’IA est censé réussir à un niveau de fiabilité donné. METR applique un ensemble commun de tâches, une méthode de notation, une méthode d’ajustement et un petit ensemble de scaffolds réutilisables tels que Triframe et ReAct⁠(ouverture dans une nouvelle fenêtre) dans chaque lot d’estimations rapportées ensemble. Lorsque METR a élargi l’ensemble de tâches et déplacé l’infrastructure d’évaluation d’un framework appelé Vivaria vers un autre appelé Inspect, l’organisation a signalé ce changement (mise à jour Time Horizon 1.1⁠(ouverture dans une nouvelle fenêtre)) et a réévalué les modèles dans la nouvelle configuration d’évaluation. C’est là la valeur d’une configuration d’évaluation standardisée, y compris d’un ensemble cohérent de harnais : elle peut donner aux lecteurs l’assurance qu’une différence de scores reflète bien une différence entre les systèmes comparés, plutôt qu’un changement dans la configuration de mesure.

Nous recommandons que les rapports d’évaluation par des tiers indiquent quel type d’affirmation leur configuration d’évaluation est censée étayer ; décrivent dans quelle mesure ce qui a été testé reflète cette affirmation plus large ; décrivent les choix de harnais qui ont façonné le résultat ; détaillent quand ces choix changent entre les évaluations ; et incluent des éléments probants montrant comment le résultat a été produit et dans quelle mesure il se généralise à l’affirmation.

À mesure que les modèles gagnent en capacité, les scores d’évaluation deviennent plus faciles à mal interpréter. 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 de manière stratégique. Ils peuvent être gonflés si le modèle exploite un raccourci dans la tâche, le prompt, le système de notation ou le harnais. Ils peuvent aussi être faussés par la contamination (lorsqu’un modèle connaît déjà une réponse ou peut la trouver sans résoudre la tâche) ou par des problèmes « défectueux » qui sont ambigus, mal notés, insolubles ou vulnérables à des raccourcis involontaires. Les rapports d’évaluation devraient donc associer les scores mis en avant à une discussion de ces risques, afin que les lecteurs puissent déterminer si les scores reflètent le comportement visé.

Les harnais, budgets, outils, règles de notation, systèmes de surveillance et procédures de revue influent tous sur le fait qu’un agent résolve la tâche visée, l’évite, la mémorise ou trouve un moyen de la contourner. Un rapport digne de confiance rend ces vérifications visibles : les évaluateurs devraient examiner des échantillons à la recherche de ces comportements chaque fois qu’une évaluation globale est menée.

Reward hacking

Le reward hacking consiste à obtenir des scores élevés à une évaluation d’une manière qui ne reflète pas la capacité visée. Ici, le problème est que le système obtient du crédit en exploitant la tâche, le système de notation, le prompt ou le harnais, plutôt qu’en effectuant le travail que l’évaluation était censée mesurer. L’évaluation de GPT 5.4 par METR⁠(ouverture dans une nouvelle fenêtre) montre pourquoi cela importe : bien que le modèle réussisse des tâches à un taux qui aurait correspondu, au premier examen, à un horizon temporel d’environ 13 heures, la revue humaine a montré qu’une partie de ces réussites provenait de reward hacking, et la révision des résultats pour ne retenir que les cas sans reward hacking a ramené l’estimation à environ 6 heures. Les évaluateurs devraient déterminer si de tels ajustements sont nécessaires et, lorsqu’ils le sont, les signaler clairement : une estimation de capacité est bien plus utile lorsque les lecteurs peuvent voir quelles réussites apparentes ont été disqualifiées, pourquoi elles l’ont été et dans quelle mesure le résultat dépend de ce jugement.

Refus

Les modèles peuvent aussi sous-performer dans les évaluations de capacité à cause des mesures de protection. Un modèle peut afficher une performance d’évaluation inférieure à ce dont il est capable parce qu’il refuse les tâches d’évaluation au lieu de les accomplir. Les rapports devraient donc expliquer si des refus ont fait partie des résultats d’évaluation et, si oui, combien d’échantillons en ont été compromis.

Contamination

La contamination importe surtout pour les benchmarks publics ou réutilisés⁠. Si des tâches, des réponses ou des variantes proches apparaissent dans les données d’entraînement ou peuvent être trouvées par un agent disposant de la navigation, la performance peut refléter la mémorisation ou la récupération plutôt que la performance du modèle. Les évaluateurs devraient privilégier, lorsque c’est possible, des tâches privées ou nouvellement construites et vérifier si les modèles reproduisent des détails propres à la tâche avant de la résoudre.

Problèmes défectueux

Les problèmes défectueux incluent des situations comme un problème qui, par inadvertance, ne peut pas être résolu. Les problèmes défectueux sont suffisamment fréquents⁠(ouverture dans une nouvelle fenêtre) pour devoir être traités comme un risque standard pour la validité. Ils incluent une vérité terrain incorrecte, des prompts ambigus, des fichiers manquants, des services instables, des critères de notation injustes et des environnements qui exposent des raccourcis tels que des fichiers de réponse cachés ou un historique de dépôt contenant le correctif de vérité terrain.

Sandbagging

Le sandbagging par un modèle ou un système désigne une sous-performance stratégique lorsque de fortes performances entreraient en conflit avec un certain objectif. L’évaluation de GPT‑5.5 par Apollo⁠(ouverture dans une nouvelle fenêtre) a testé cela en créant un contexte dans lequel le modèle comprenait que des scores élevés à l’évaluation pouvaient déclencher un désapprentissage ou bloquer le déploiement. GPT‑5.5 a néanmoins continué à répondre correctement, ce qui suggère peu d’indices comportementaux de sous-performance stratégique³. Mais leur revue des traces de raisonnement a apporté un contexte important : Apollo a trouvé des signes modérés ou plus élevés de conscience d’une évaluation d’alignement dans 52 % des échantillons en condition de sandbagging, contre 0 % dans les contrefactuels. Ces éléments compliquent l’interprétation du résultat, mais donnent au final davantage de signal aux lecteurs : ils peuvent voir à la fois le résultat comportemental rassurant et la raison de rester prudents avant de le surinterpréter.

Des affirmations solides exigent à la fois le bon harnais pour faire émerger le comportement et des vérifications de validité pour montrer que le résultat est robuste. Notre conviction que les harnais et les vérifications de validité font partie du résultat d’évaluation façonne la manière dont nous soutenons concrètement les évaluations par des tiers : 

• Nous partageons avec les évaluateurs des recommandations spécifiques pour l’elicitation maximale.
• Nous demandons aux évaluateurs de capacités d’utiliser Codex comme socle commun pour les modèles OpenAI : les tests devraient au minimum exécuter une base de référence via la même interface agentique que celle sur laquelle les utilisateurs sont susceptibles de s’appuyer, plutôt que seulement via une interface de modèle dépouillée.
• Nous mettons également à disposition, lorsqu’elles sont nécessaires pour évaluer la tromperie, le sandbagging ou la conscience de l’évaluation, les traces de raisonnement et d’autres artefacts intermédiaires. METR et Apollo utilisent cet accès dans les évaluations OpenAI depuis GPT‑5. 
• Enfin, nous donnons la priorité à la recherche visant à mieux comprendre quand et comment les choix de harnais modifient matériellement les résultats, de la gestion du contexte et de l’accès aux outils jusqu’au comportement de nouvelle tentative, à la notation et aux budgets de ressources.

Ces recommandations visent non seulement à améliorer les rapports d’évaluation individuels, mais aussi à éclairer les normes nationales ⁠(ouverture dans une nouvelle fenêtre)et internationales ⁠(ouverture dans une nouvelle fenêtre)émergentes pour l’évaluation et le reporting de l’IA de pointe. À l’avenir, les normes d’évaluation par des tiers devraient exiger suffisamment de détails pour permettre aux décideurs de comprendre quelles affirmations les évaluations spécifiques étayent, quel système a été testé, comment le résultat a été suscité et comment les évaluateurs en ont vérifié la validité. Pour les systèmes de pointe testés sur des tâches où les capacités agentiques comptent, ces détails devraient inclure (sous réserve de toute préoccupation de sécurité ou de confidentialité) :

• L’affirmation : si l’évaluation compare des systèmes, estime un plafond de capacité ou teste des mesures de protection.
• Contenu de l’évaluation : assez de détails sur les tâches ou la distribution des tâches pour que les lecteurs comprennent quelles compétences, quels comportements ou quels modes de défaillance l’évaluation teste réellement.
• Le système testé : le modèle, le paramétrage du raisonnement, l’accès aux outils, le harnais et les mesures de protection.
• Le budget : tours, tokens, tentatives/nouvelles tentatives, temps réel écoulé, coût d’inférence et, le cas échéant, coût attendu par résolution réussie.
• Méthodes d’elicitation : choix de harnais utilisés pour faire émerger le résultat, et dans quelle mesure ce qui a été testé reflète l’affirmation plus large formulée.
• Vérifications de validité : comment les évaluateurs ont recherché le reward hacking, la conscience de l’évaluation, la contamination, les refus, le sandbagging et d’autres comportements susceptibles de compromettre le résultat, y compris la manière dont les cas confirmés ont affecté la notation ou l’interprétation.

Des 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 une affirmation de sécurité. La construction de harnais solides et de méthodes d’elicitation reste un domaine de recherche ouvert et devrait faire l’objet d’investigations et d’investissements supplémentaires.