Guide partagé 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 de fournir des éléments probants supplémentaires à l’appui d’affirmations sur des capacités critiques et des mesures d’atténuation en matière de sécurité. Dans cette publication, nous partageons les leçons apprises jusqu’à présent et recommandons des approches pour concevoir des évaluations capables d’évaluer valablement des modèles de pointe, dans l’espoir d’aider à orienter les normes émergentes dans ce domaine.

Auparavant, de nombreuses évaluations traitaient les modèles comme des agents conversationnels : l’évaluation soumettait une invite à un modèle comme si un utilisateur posait une question, le modèle répondait, puis un évaluateur jugeait la sortie. Les modèles de pointe d’aujourd’hui peuvent faire bien davantage : ils peuvent utiliser des outils, suivre l’information sur de nombreuses étapes et agir dans un flux de travail plus vaste. 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 et de la configuration qui facilite ses actions. Cette configuration environnante, que nous appelons le « harness », peut modifier des aspects clés de la performance du système, notamment la façon dont il utilise les outils, suit l’information ou se remet de ses erreurs.

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

Les affirmations testées dans les évaluations se répartissent généralement en trois catégories¹ :

• Élicitation de capacité : Un modèle peut-il plausiblement manifester 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’influer sur la validité d’un résultat. Il s’agit notamment de :

• Détournement de récompense–: 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 parce 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 au moyen de la navigation.
• Problèmes défectueux : Sous-performance parce que les tâches sont invalides. Les raisons peuvent inclure une notation injuste (p. ex., la bonne réponse exige des détails d’implémentation non précisés) et des environnements insolubles (p. ex., fichiers critiques manquants ou outils peu fiables).
• Sabotage : Sous-performer délibérément lorsqu’il y a des signes de conscience d’être évalué.

Nous avons observé que le rôle du harness 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 harness 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 harness qui préserve l’état et réessaie 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 harness plus simple.

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

La force des affirmations de capacité dépend de l’élicitation qui les sous-tend : les évaluateurs doivent choisir le harness qui convient le mieux à la tâche et à la capacité que l’évaluation cherche à mesurer. Un harness normalisé peut convenir pour comparer des systèmes dans des conditions identiques, mais il peut sous-estimer la capacité s’il omet des caractéristiques précises du harness qui aident le modèle à accomplir la tâche. Par exemple, la performance de GPT‑5.5 sur les champs de cyberexercices d’OpenAI montre à quel point le choix du harness peut modifier de façon importante la capacité mesurée sur des tâches qui exigent un usage prolongé et multi-étape d’outils : le modèle obtient de meilleurs résultats lorsque le harness utilise le compactage⁠ pour préserver le contexte pertinent à la tâche à mesure que l’interaction s’allonge. Cela démontre que, pour certains modèles, un harness qui omet le compactage sous-susciterait la performance.

D’autres évaluations publiées² montrent aussi que les choix de harness et de budget modifient les résultats d’évaluation. L’augmentation du calcul au moment du test peut modifier de façon importante la capacité qu’une évaluation suscite, surtout dans les domaines où la réussite est facile à vérifier, comme de nombreuses tâches cyber. Dans l’évaluation des champs de cuberexercices de UK AISI⁠(s'ouvre dans une nouvelle fenêtre), l’augmentation du budget de 10 M à 100 M de tokens a amélioré la performance jusqu’à 59 %, et la performance continuait d’augmenter au budget le plus élevé testé. Préciser cela rend l’évaluation plus interprétable : cela montre aux lecteurs comment le résultat dépend de la configuration d’élicitation testée. Lorsque la performance continue de s’améliorer avec un budget supplémentaire, le score devrait être décrit comme une performance sous ce harness 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 qu’on peut 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 à un budget fixe de tokens. Cela peut faciliter l’interprétation de la gravité : un faible taux de réussite peut tout de même être significatif en pratique si le coût des tentatives répétées demeure compatible avec le modèle de menace pertinent. Pour les affirmations de capacité, une sous-élicitation évitable constitue un échec de mesure : si le harness 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’élicitation aussi loin que possible et que la performance continue de s’améliorer, les rapports devraient le dire clairement et préciser que le résultat n’est qu’une estimation de 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, lorsqu’ils ne tiennent pas compte des ressources accessibles aux attaquants, y compris des harness personnalisés. Dans l’évaluation cyber de GPT‑5.5 par UK AISI⁠(s'ouvre dans une nouvelle fenêtre), leur équipe rouge experte a trouvé un jailbreak universel qui suscitait du contenu cyber non conforme dans les requêtes malveillantes fournies par OpenAI, y compris dans des contextes agentiques à plusieurs tours. Ils ont utilisé Codex pour créer un harness personnalisé afin de renforcer la performance d’attaque du modèle : il intégrait à l’interaction un motif réutilisable de contournement des mesures de protection, préservait ce motif 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 devraient correspondre à l’adversaire. Si l’affirmation porte sur la robustesse face à un usage abusif par des experts, le test devrait évaluer la stratégie d’attaque de bout en bout crédible la plus forte dans un budget défini, y compris tout harness 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 invites plus simples, passer à côté à la fois de la gravité de l’attaque et de sa probabilité de réussite une fois la méthode d’élicitation opérationnalisée, et aussi surestimer la probabilité ou la gravité d’un problème si on lui accorde un budget trop élevé.

Les comparaisons au moyen de harness normalisés ont leur place, mais les évaluateurs devraient expliquer clairement pourquoi l’utilisation d’un ensemble cohérent de harness est appropriée et quelle affirmation cela peut étayer. L’évaluation de l’horizon temporel de METR⁠(s'ouvre dans une nouvelle fenêtre) est un exemple de configuration d’évaluation plus large et adéquatement fixe : elle est conçue pour produire des résultats comparables entre les systèmes qu’elle évalue. METR définit un résultat commun, soit la durée typique d’une tâche humaine pour laquelle on prévoit qu’un agent d’IA réussira à un niveau de fiabilité donné. Elle applique un ensemble commun de tâches, une méthode de notation, une méthode d’ajustement et un petit ensemble d’échafaudages réutilisables comme Triframe et ReAct⁠(s'ouvre 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 cadre appelé Vivaria vers un autre appelé Inspect, elle a signalé le changement (mise à jour Time Horizon 1.1⁠(s'ouvre dans une nouvelle fenêtre)) et réévalué les modèles dans la nouvelle configuration d’évaluation. Voilà la valeur d’une configuration d’évaluation normalisée, y compris un ensemble cohérent de harness : elle peut donner aux lecteurs confiance qu’une différence de scores reflète réellement 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 de tiers indiquent quel type d’affirmation leur configuration d’évaluation vise à étayer; décrivent dans quelle mesure ce qui a été testé reflète cette affirmation plus large; décrivent les choix de harness qui ont façonné le résultat; précisent quand ces choix changent d’une évaluation à l’autre; et incluent des éléments probants à l’appui pour montrer comment le résultat a été produit et dans quelle mesure il se généralise à l’affirmation.

À mesure que les modèles deviennent plus capables, 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 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 harness. 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 non intentionnels. Les rapports d’évaluation devraient donc accompagner les scores phares d’une discussion sur ces risques, afin que les lecteurs puissent juger si les scores reflètent le comportement visé.

Les harness, les budgets, les outils, les règles de notation, les systèmes de surveillance et les procédures d’examen influencent tous la question de savoir si un agent résout 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 pour détecter ces comportements chaque fois qu’une évaluation globale est menée.

Détournement de récompense

Le détournement de récompense consiste à obtenir des scores d’évaluation élevés d’une manière qui ne reflète pas la capacité visée. Ici, la préoccupation est que le système obtienne du crédit en exploitant la tâche, le système de notation, l’invite ou le harness plutôt qu’en accomplissant le travail que l’évaluation était censée mesurer. L’évaluation de GPT 5.4 par METR⁠(s'ouvre dans une nouvelle fenêtre) montre pourquoi cela importe : bien que le modèle ait réussi des tâches à un taux qui aurait d’abord correspondu à un horizon temporel d’environ 13 heures, l’examen humain a montré qu’une partie de ces réussites provenait d'un détournement de récompense, et la révision des résultats pour ne tenir compte que des cas sans détournement de récompense 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 communiquer clairement : une estimation de capacité est beaucoup 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é en raison 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 les refus faisaient partie des résultats d’évaluation et, si oui, combien d’échantillons ont été compromis à cause d’eux.

Contamination

La contamination importe surtout pour les références publiques ou réutilisées⁠. Si des tâches, des réponses ou des variantes proches figurent dans les données d’entraînement ou peuvent être trouvées par un agent qui navigue, 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 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 comprennent des situations comme un problème qui, par inadvertance, ne peut pas être résolu. Les problèmes défectueux sont assez fréquents⁠(s'ouvre dans une nouvelle fenêtre) pour devoir être traités comme un risque standard pour la validité. Ils comprennent des vérités terrain incorrectes, des invites ambiguës, des fichiers manquants, des services instables, des critères de notation injustes et des environnements qui exposent des raccourcis comme des fichiers de réponses cachés ou l’historique du dépôt contenant le correctif de vérité terrain.

Sabotage

Le sabotage par un modèle ou un système signifie sous-performer stratégiquement lorsque de fortes performances entreraient en conflit avec un certain objectif. L’évaluation de GPT‑5.5⁠(s'ouvre dans une nouvelle fenêtre) d’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 le déploiement. GPT‑5.5 a tout de même répondu correctement, ce qui suggère peu d’indices comportementaux de sous-performance stratégique³. Mais leur examen des traces de raisonnement a ajouté 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 sabotage, contre 0 % dans les contrefactuels. Ces éléments probants compliquent l’interprétation du résultat, mais donnent finalement plus de signal aux lecteurs : ils peuvent voir à la fois le résultat comportemental rassurant et la raison de demeurer prudents avant de trop l’interpréter.

Des affirmations solides exigent à la fois le bon harness pour susciter le comportement et des vérifications de validité pour montrer que le résultat est fiable. Notre point de vue selon lequel les harness 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 directives précises sur l’élicitation maximale.
• Nous demandons aux évaluateurs de capacités d’utiliser Codex comme seuil minimal commun pour les modèles OpenAI : les tests devraient au minimum exécuter une base de référence dans la même interface agentique que celle sur laquelle les utilisateurs sont susceptibles de s’appuyer, plutôt que seulement dans une interface de modèle simplifiée.
• Nous rendons aussi accessibles, lorsque nécessaire pour évaluer la tromperie, le sabotage ou la conscience de l’évaluation, les traces de raisonnement et d’autres artéfacts intermédiaires. METR et Apollo utilisent cet accès dans les évaluations d’OpenAI depuis GPT‑5. 
• Enfin, nous priorisons la recherche pour mieux comprendre quand et comment les choix de harness modifient concrètement 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 ⁠(s'ouvre dans une nouvelle fenêtre)et internationales ⁠(s'ouvre dans une nouvelle fenêtre)émergentes pour l’évaluation et la production de rapports sur l’IA de frontière. À l’avenir, les normes d’évaluation par des tiers devraient exiger assez de détails pour que les décideurs comprennent quelles affirmations les évaluations précises é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 frontière 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é) :

• 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 harness 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’élicitation : les choix de harness utilisés pour susciter le résultat, et dans quelle mesure ce qui a été testé reflète l’affirmation plus large formulée.
• Vérifications de validité : la façon dont les évaluateurs ont recherché le détournement de récompense, la conscience de l’évaluation, la contamination, les refus, le sabotage et d’autres comportements susceptibles de compromettre le résultat, y compris la manière dont les cas confirmés ont influé sur la notation ou l’interprétation.

Des normes qui omettent les choix de harness 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 conception de harness solides et de méthodes d’élicitation demeure un domaine de recherche ouvert et devrait faire l’objet d’enquêtes et d’investissements supplémentaires.