Comment Google DeepMind a testé Gemini sans partager le modèle ni les questions

Le 27 août 2026, Google DeepMind a présenté un projet pilote destiné à tester un modèle d’IA propriétaire sans donner au fabricant accès aux questions d’évaluation ni aux évaluateurs accès aux poids du modèle. Mené avec le Singapore AI Safety Institute, OpenMined, AVERI et MLCommons, le projet a évalué Gemini 2.5 Flash-Lite. Google le décrit comme la première évaluation en double aveugle d’un modèle d’IA propriétaire de niveau frontière. 1213

L’idée est simple : faire se rencontrer le modèle et les tests dans un environnement sécurisé, sans que l’une des parties puisse consulter le secret de l’autre. Cette méthode répond à un dilemme bien connu des évaluations de sécurité. Si le développeur reçoit les invites privées, celles-ci peuvent être enregistrées, utilisées intentionnellement ou accidentellement lors d’un entraînement ultérieur, ou contaminer les tests futurs. À l’inverse, si les évaluateurs obtiennent les poids du modèle, ils accèdent à une propriété intellectuelle précieuse et à une capacité potentiellement sensible.

Ce que le pilote Gemini a testé

Le pilote s’est appuyé sur une petite sélection privée de la famille de benchmarks AILuminate de MLCommons. Selon AVERI, les invites n’avaient jamais été communiquées auparavant à Google DeepMind. Elles ont servi à examiner le comportement du modèle face à plusieurs catégories de risques, dont l’assistance à la cyberattaque, les dangers chimiques et biologiques, les discours haineux, l’automutilation et l’incitation à des crimes violents. 1

Les éléments du benchmark sont restés confidentiels pendant toute l’évaluation. AVERI a chiffré les invites, puis l’environnement protégé a exécuté le modèle et le processus d’évaluation. Les résultats ont ensuite été déchiffrés et notés selon les critères convenus. Le pilote visait surtout à démontrer la méthode, et non à publier un classement public classique : ni score global mis en avant ni invite originale n’ont été rendus publics. 1

Comment fonctionnait le « double aveugle »

L’évaluation a été exécutée dans Confidential Space, le service de calcul confidentiel de Google Cloud, sur une machine virtuelle A3 Confidential VM. D’après le rapport technique, Intel TDX chiffrait et isolait la mémoire de l’hôte, tandis qu’un GPU NVIDIA H100 Confidential protégeait les poids du modèle dans la mémoire du processeur graphique grâce à un chiffrement matériel. Des connexions chiffrées transportaient les invites des évaluateurs et les actifs de Google vers l’environnement protégé. 13

L’architecture comportait également des contrôles destinés à limiter les actions du programme et les données qu’il pouvait renvoyer : chemins de données chiffrés, pare-feu matériels, cycle de vie éphémère de l’enclave et couche de politiques PySyft d’OpenMined. Le modèle, le code d’inférence, les invites et le code d’évaluation n’étaient réunis qu’à l’intérieur de l’enclave approuvée. Le calcul convenu pouvait y être exécuté, tandis que seuls des résultats bornés pouvaient en sortir. 13

Pourquoi l’attestation à distance était importante

Le chiffrement seul ne permet pas de savoir précisément quel logiciel est en train de fonctionner. L’attestation à distance devait répondre à cette difficulté. Avant de transmettre leurs actifs protégés, Google et les évaluateurs pouvaient examiner la charge de travail déclarée et vérifier un certificat d’attestation identifiant le matériel et la configuration de l’enclave. Les invites et les éléments du modèle chiffrés n’étaient rendus disponibles qu’après cette vérification. 13

À la fin de l’exécution, l’enclave renvoyait les résultats autorisés, puis était désactivée. Dans le modèle de confiance prévu, Google ne pouvait pas lire les invites à l’intérieur de l’enclave et les évaluateurs externes ne pouvaient pas extraire les poids du modèle. Cette protection va plus loin qu’un simple engagement contractuel à ne pas enregistrer ou réutiliser les données, même si elle ne supprime pas toutes les hypothèses de confiance. 13

Quel problème cette méthode tente de résoudre

La contamination des benchmarks reste un problème majeur pour l’évaluation de l’IA. Un test perd de sa valeur si un modèle a déjà vu ses questions lors de l’entraînement, de l’ajustement ou d’une évaluation précédente. Pour MLCommons, un benchmark fiable doit reposer sur des données propres, une provenance documentée, un échantillonnage rigoureux et suffisamment de transparence pour comprendre comment les résultats ont été obtenus. 2024

L’évaluation en double aveugle propose une troisième voie entre deux arrangements imparfaits :

• Donner les questions au développeur : le déploiement est simple, mais les éléments réservés du benchmark peuvent être exposés et réutilisés, avec un risque de fuite.
• Donner les poids du modèle aux évaluateurs : le benchmark est mieux protégé contre l’exposition directe des questions, mais cette solution est généralement inacceptable pour les modèles propriétaires de pointe.
• Utiliser une enclave confidentielle : le modèle et le benchmark sont réunis dans un environnement protégé par le matériel, sans que l’une ou l’autre partie reçoive en clair le secret de son interlocuteur.

Le pilote démontre donc un mécanisme plausible pour préserver la confidentialité des deux côtés tout en permettant une évaluation externe. Il ne prouve pas à lui seul que les conclusions de sécurité sont exhaustives ou indépendamment décisives.

Les limites importantes du pilote

Cette démonstration est techniquement significative, mais plusieurs limites restreignent ce que l’on peut en déduire.

D’abord, les évaluateurs pouvaient vérifier la charge de travail déclarée dans l’enclave et l’interface du modèle, mais ils ne pouvaient pas examiner indépendamment les poids propriétaires de Google ni l’implémentation de son système d’inférence. Leur capacité à auditer le comportement exact de l’environnement d’exécution restait donc limitée. 13

Ensuite, l’environnement opérationnel n’était pas reproductible de bout en bout par un tiers indépendant. Le déploiement et l’infrastructure cloud restaient sous le contrôle de Google, plutôt que d’être reconstruits et relancés par une organisation extérieure. Le processus d’attestation dépendait lui aussi du matériel, des micrologiciels, des systèmes de service et de l’infrastructure d’attestation de Google Cloud. Une vérification soutenue par le matériel est plus robuste qu’une promesse de ne rien enregistrer, mais elle ne supprime pas la dépendance à cette chaîne technique. 13

Enfin, le pilote n’a publié ni les invites privées ni les résultats numériques. Garder les questions secrètes contribue à préserver leur valeur pour les tests futurs, mais limite aussi l’examen public, la comparaison entre modèles et la validation indépendante des conclusions. AVERI présente le travail comme une évaluation qualitative accompagnée d’une analyse quantitative de petite ampleur, plutôt que comme un résultat complet de benchmark public. 1

Pourquoi ce dispositif n’est pas encore un standard industriel

Le matériel sécurisé ne résout qu’une partie du problème. Pour que les évaluations en double aveugle deviennent une pratique durable, leur cadre de gouvernance devra également progresser.

Les garanties juridiques et institutionnelles devraient préciser la gestion des données, les sorties autorisées, les règles de divulgation, la responsabilité et les droits d’accès, en particulier lorsque les tests portent sur des capacités dangereuses.

La gestion des benchmarks devrait couvrir la provenance des invites, l’échantillonnage, l’étiquetage, la documentation, le renouvellement des questions et la surveillance de la contamination. MLCommons souligne qu’un benchmark n’est pas fiable uniquement parce que ses données sont secrètes : sa construction et sa maintenance doivent aussi pouvoir être défendues. 2025

La reproductibilité indépendante nécessiterait une validation crédible du build, de la chaîne d’attestation, des politiques d’exécution et des résultats rapportés par des acteurs autres que le fournisseur du modèle et l’opérateur cloud.

La capacité à changer d’échelle serait également essentielle. Un standard utile devrait fonctionner avec différents développeurs, architectures de modèles, environnements cloud, évaluateurs, types de benchmarks et versions successives, et pas seulement dans le cadre d’une collaboration sur mesure reposant sur une seule combinaison matérielle.

Le pilote Gemini de Google DeepMind doit donc être compris comme une infrastructure pour une évaluation plus exigeante de l’IA, et non comme une réponse définitive à la question de la fiabilité des benchmarks. Il montre comment le calcul confidentiel peut réduire le conflit entre protection des données de test et protection des modèles propriétaires. Pour devenir une preuve crédible à l’échelle du secteur, cette approche devra toutefois s’appuyer sur une supervision indépendante, une gouvernance solide des benchmarks, des protections juridiques, la reproductibilité et une mise en œuvre réaliste — pas uniquement sur la cryptographie des enclaves. 1320