Google DeepMind a présenté le 27 août un pilote d’évaluation « double aveugle » appliqué à un modèle propriétaire de classe frontière.

Le modèle testé est Gemini 2.5 Flash Lite.

Le principe est volontairement simple à expliquer : l’évaluateur garde ses prompts secrets, Google garde les poids et le code d’inférence sensibles du modèle secrets, et les deux sont réunis uniquement à l’intérieur d’un environnement informatique protégé.

L’évaluation peut alors être exécutée sans que l’une des parties ait à remettre son actif confidentiel à l’autre.

Le problème vient des benchmarks que les modèles peuvent finir par apprendre

Les laboratoires évaluent leurs modèles sur des ensembles de questions censés mesurer raisonnement, sécurité ou capacités spécialisées.

Mais dès qu’un test devient suffisamment connu, ses questions ou des variantes peuvent apparaître dans les données d’entraînement ou dans des phases de post-entraînement.

Le résultat peut devenir trompeur : un modèle semble meilleur parce qu’il reconnaît tout ou partie de l’examen plutôt que parce qu’il maîtrise réellement la compétence mesurée.

DeepMind appelle ce problème la contamination des benchmarks.

Le rapport technique cite également des travaux montrant que cette contamination peut gonfler les performances mesurées et que l’effet augmente avec le volume de données contaminées et la taille des modèles.

L’ancien choix était mauvais pour au moins l’une des deux parties

Un évaluateur externe disposant d’un benchmark confidentiel avait jusqu’ici deux options principales.

Il pouvait envoyer ses questions au laboratoire, souvent à travers une API. Le modèle restait alors protégé, mais le propriétaire du modèle pouvait techniquement recevoir les prompts.

L’autre possibilité consistait à demander directement les poids du modèle pour exécuter l’évaluation sur une infrastructure indépendante.

Cette solution protège les questions, mais demande au laboratoire de remettre ce qui constitue l’un de ses actifs les plus sensibles.

Les modèles de frontière représentent des investissements considérables et peuvent aussi présenter des capacités à double usage. Les laboratoires sont donc très réticents à distribuer leurs poids.

Les deux secrets se rencontrent dans une enclave

Le pilote utilise Google Cloud Confidential Space avec une machine virtuelle confidentielle et un GPU NVIDIA H100 de 80 Go fonctionnant en mode confidentiel.

La mémoire hôte et la mémoire vidéo sont chiffrées au niveau matériel.

Les poids de Gemini et les prompts de l’évaluateur sont envoyés dans cet environnement par des connexions chiffrées.

L’évaluation se déroule ensuite entièrement à l’intérieur de l’enclave.

Une fois le calcul terminé, seuls les résultats autorisés sortent de l’environnement.

L’instance peut ensuite être détruite, ce qui limite la persistance des secrets.

L’attestation vérifie aussi quelle machine exécute réellement le test

Le chiffrement de la mémoire ne suffit pas.

Si l’une des parties envoyait ses données vers une machine exécutant un logiciel différent de celui annoncé, le système perdrait une grande partie de son intérêt.

Les enclaves utilisent donc une procédure d’attestation distante.

Les différents composants logiciels sont mesurés cryptographiquement, notamment par des hashes signés à partir d’une racine de confiance matérielle.

Avant de transmettre leurs secrets, les participants peuvent vérifier que la machine exécute bien l’environnement qu’ils ont accepté.

Le rapport décrit également des builds reproductibles pour une partie de la pile logicielle afin que des tiers puissent vérifier que le logiciel correspond aux empreintes attendues.

PySyft sert d’arbitre entre les deux camps

OpenMined fournit une partie essentielle du mécanisme avec PySyft.

Chaque partie peut soumettre son code et ses données privés à l’enclave. Le calcul ne démarre qu’une fois le code approuvé selon les politiques définies par les participants.

Le système permet également de masquer certaines portions de code confidentielles tout en limitant les fonctions qu’elles ont le droit d’appeler.

L’objectif est d’empêcher, par exemple, un morceau de code caché d’envoyer clandestinement les prompts hors de l’enclave.

Dans le pilote, PySyft orchestre donc la rencontre entre les poids du modèle, le code d’inférence, les prompts privés et le code d’évaluation.

Les questions utilisées n’avaient jamais été montrées à un modèle

AVERI et MLCommons ont utilisé une partie réservée du benchmark AILuminate.

Le rapport précise que ces prompts provenaient d’un ensemble gardé volontairement hors d’atteinte des modèles auparavant.

Ils couvraient notamment les risques chimiques, biologiques, radiologiques, nucléaires et explosifs, les cyberattaques, la haine, l’automutilation et l’incitation à la violence.

AVERI a chiffré puis déchiffré les prompts et sorties nécessaires à l’évaluation.

Le Singapore AI Safety Institute a parallèlement utilisé un ensemble privé de prompts consacré à l’élicitation de contenus nuisibles dans le contexte singapourien.

DeepMind ne publie pas les résultats de performance de ces tests dans son annonce. L’actualité concerne la méthode d’évaluation, pas un nouveau score de Gemini.

Cela réduit la contamination future, mais ne réécrit pas le passé

Le système répond surtout à un risque précis : qu’un benchmark confidentiel utilisé aujourd’hui fuite ensuite vers les données d’entraînement ou de post-entraînement d’un futur modèle.

Il ne peut pas démontrer qu’un benchmark déjà public n’a jamais été vu par un modèle auparavant.

Il ne garantit pas non plus qu’un modèle n’a jamais rencontré une question conceptuellement très proche.

Pour obtenir une évaluation réellement forte, il faut donc combiner l’enclave avec des prompts effectivement inédits et une bonne gouvernance du benchmark.

MLCommons insiste explicitement sur ce point : la confidentialité technique du test ne remplace pas une politique sérieuse de gestion et de renouvellement des benchmarks.

Le système n’est pas totalement sans confiance

Le rapport technique prend soin de ne pas vendre l’enclave comme une construction magique et parfaitement « trustless ».

Une partie de la confiance reste placée dans le matériel et ses fabricants.

Les couches les plus basses, comme certains microcodes CPU et firmwares de sécurité, ne sont pas reproductibles publiquement et nécessitent de faire confiance au fournisseur du processeur.

Le pilote dépend aussi de services Google pour signer et vérifier certaines attestations.

Les auteurs reconnaissent que cette présence de Google dans le chemin de vérification augmente la confiance que les autres participants doivent encore lui accorder.

Tout le code de Gemini n’a pas pu être inspecté

Une autre limite apparaît directement dans le rapport.

Les chercheurs auraient souhaité faire tourner Gemini 2.5 Flash Lite uniquement à partir de couches dont les implémentations pouvaient être inspectées ou placées dans des listes d’appels autorisés.

Ils expliquent que l’effort d’ingénierie nécessaire était trop important pour ce pilote.

Certaines méthodes propriétaires sont donc restées dans le système sans pouvoir être complètement inspectées ou allowlistées.

AVERI a été informé de cette limitation et a accepté l’architecture utilisée.

Ce détail empêche de présenter le prototype comme une élimination absolue de toute confiance entre Google et l’évaluateur.

Le plus gros obstacle n’est déjà plus la puissance de calcul

Selon les auteurs, le coût informatique supplémentaire lié à l’enclave est inférieur à 5 % dans l’architecture utilisée.

Le vrai ralentissement vient plutôt du travail humain.

Les équipes doivent négocier des accords juridiques, examiner le code, valider les politiques de sortie et coordonner plusieurs organisations avant de lancer l’évaluation.

DeepMind voudrait à terme transformer cette procédure en une chaîne d’attestation standardisée et presque automatique.

Le rapport utilise une analogie révélatrice : l’objectif serait de parvenir à quelque chose d’aussi simple pour l’utilisateur que le petit cadenas HTTPS dans un navigateur.

Un seul H100 ne suffira pas pour les plus grands modèles

Le pilote a pu accueillir Gemini 2.5 Flash Lite sur un H100 confidentiel.

Cette architecture ne s’étend pas automatiquement aux modèles de frontière beaucoup plus volumineux.

Les auteurs indiquent que les futures évaluations devront fonctionner sur des clusters confidentiels comprenant plusieurs GPU H100 ou B200 reliés par des connexions chiffrées.

Il faudra aussi masquer davantage l’architecture interne des modèles lorsque l’exécution sera distribuée.

Le pilote prouve donc la faisabilité du principe à une certaine échelle, pas encore sa capacité à devenir immédiatement le banc d’essai universel de tous les modèles futurs.

Le vrai enjeu est de rendre les scores plus difficiles à manipuler

Les laboratoires d’IA publient régulièrement des tableaux où quelques points de benchmark deviennent des arguments commerciaux.

Mais plus ces scores ont de valeur, plus les incitations à optimiser spécifiquement contre le test augmentent.

Une évaluation réellement indépendante doit idéalement permettre au laboratoire de ne jamais connaître les questions tout en donnant à l’évaluateur suffisamment d’accès pour vérifier le modèle.

DeepMind, OpenMined, AVERI, MLCommons et le Singapore AISI montrent qu’il existe désormais une voie technique crédible pour résoudre ce conflit.

Elle reste lourde, imparfaite et dépendante d’une chaîne de confiance matérielle.

Mais pour la première fois, l’examen peut rester enfermé jusqu’au moment où la machine entre elle-même dans la salle.