Un examen ne mesure plus grand-chose si le candidat a déjà lu les questions. Cette évidence scolaire est devenue un problème industriel pour l’intelligence artificielle. Les grands modèles sont entraînés sur des masses de données, testés à répétition et parfois ajustés après avoir rencontré des évaluations privées. Un excellent score peut alors refléter une capacité réelle, mais aussi une familiarité avec l’épreuve.
Google DeepMind affirme avoir franchi une étape pour sortir de cette zone grise. Le laboratoire a présenté le 27 août 2026 un pilote d’évaluation en double aveugle : les questions secrètes d’un organisme indépendant sont envoyées dans un environnement de calcul protégé sans être révélées à Google ; les poids et le code d’inférence de Gemini y entrent de l’autre côté sans être remis à l’évaluateur. Seuls les résultats autorisés ressortent.
L’expérience a porté sur Gemini 2.5 Flash Lite, des prompts privés de la suite AILuminate de MLCommons et un second jeu de questions du Singapore AI Safety Institute. Elle ne prouve pas que Gemini est « sûr » et le rapport ne publie pas de nouveau classement spectaculaire. Son intérêt est ailleurs : montrer qu’un laboratoire et un auditeur peuvent tester un modèle propriétaire sans devoir se confier mutuellement leurs secrets les plus sensibles.
Les benchmarks IA ont un problème de fuite
Un benchmark est une épreuve standardisée : un ensemble de questions, de tâches ou de scénarios qui permet de comparer des modèles. Il peut mesurer le raisonnement mathématique, la programmation, la résistance aux demandes dangereuses, les capacités cyber ou encore la propension à produire du contenu violent.
Le principe paraît simple. Il devient fragile dès que les questions circulent. Les données publiques peuvent être aspirées pendant le préentraînement. Des exemples proches peuvent être utilisés pour l’ajustement. Un fournisseur peut aussi tester de nombreuses variantes sur la même épreuve et ne publier que la meilleure. Dans tous ces cas, le score cesse de représenter une rencontre réellement nouvelle entre le modèle et le problème.
Une étude publiée en janvier 2026 a quantifié cet effet sur des évaluations génératives. Ses auteurs ont entraîné des modèles avec différentes quantités de données contaminées par le jeu de test MATH. La performance mesurée augmente avec la contamination et avec la taille du modèle ; même une seule copie du jeu de test peut produire un avantage détectable. La mémorisation n’explique pas tout, mais elle suffit à rendre une comparaison ambiguë.
La manipulation peut également intervenir après l’entraînement. Le travail The Leaderboard Illusion, accepté à NeurIPS 2025, a documenté les biais de Chatbot Arena et observé, dans un cas extrême, 27 variantes privées soumises par un même fournisseur avant la publication du modèle retenu. Tester plusieurs prototypes n’est pas illégitime. Présenter le meilleur résultat comme s’il provenait d’une tentative unique crée toutefois un avantage comparable à celui d’un candidat autorisé à repasser l’examen jusqu’à obtenir sa meilleure note.
Le double aveugle protège les deux camps
Les évaluateurs disposent déjà d’une réponse partielle : garder une partie des questions secrètes. MLCommons utilise ainsi un mélange de prompts publics, utiles pour comprendre la méthode, et de prompts privés réservés aux résultats officiels. Sa documentation précise que cette séparation vise à limiter le jeu stratégique et à préserver l’intégrité empirique du test.
Cette précaution déplace cependant le problème. Pour interroger un modèle fermé, l’évaluateur passe normalement par l’API de son propriétaire. Les prompts arrivent alors, en clair, dans l’infrastructure de l’entreprise. Un contrat de confidentialité et une politique d’absence de journalisation peuvent interdire leur conservation, mais l’auditeur doit croire que la règle est correctement appliquée et qu’aucune donnée ne contaminera un entraînement ultérieur.
L’autre solution consiste à remettre une copie du modèle à l’évaluateur. Elle protège les questions, mais oblige le laboratoire à transférer des poids qui représentent des années de travail, un investissement considérable et parfois des capacités à double usage. Les entreprises acceptent rarement de livrer cet actif hors de leur infrastructure, surtout pour les modèles les plus avancés.
Le double aveugle cherche donc à satisfaire deux exigences simultanées :
- l’évaluateur ne révèle ni ses prompts privés ni sa méthode détaillée au propriétaire du modèle ;
- le propriétaire ne révèle ni les poids du modèle ni son code d’inférence propriétaire à l’évaluateur.
Cette symétrie est la nouveauté centrale. Le dispositif ne demande pas aux acteurs de mieux se faire confiance. Il tente de réduire la partie du processus qui repose uniquement sur leur parole.
Une salle d’examen construite dans le processeur
Le pilote s’appuie sur Confidential Space, l’environnement de calcul multipartite de Google Cloud, ainsi que sur le framework open source PySyft d’OpenMined. Le test a été exécuté sur une machine équipée d’un processeur Intel protégé par TDX et d’un GPU NVIDIA H100 de 80 Go configuré en mode confidentiel.
Le terme « enclave sécurisée » peut sembler abstrait. On peut l’imaginer comme une salle d’examen temporaire dont les murs sont constitués par le matériel. Les données stockées dans la mémoire vive du processeur et du GPU sont chiffrées. Une clé éphémère est créée au démarrage, puis détruite lorsque l’environnement est arrêté. Même l’administrateur du cloud n’est pas censé pouvoir lire directement ce qui se trouve à l’intérieur.
Le chiffrement ne suffit pas. Les deux parties doivent aussi vérifier qu’elles envoient leurs actifs dans la bonne salle et que celle-ci exécutera bien le programme convenu. C’est le rôle de l’attestation distante. Le matériel produit une preuve cryptographique décrivant le logiciel chargé : micrologiciel, noyau, environnement d’exécution et conteneur. Avant de libérer ses données, chaque participant compare cette empreinte à celle qu’il attend.
Le rapport technique du pilote décrit ensuite un déroulement en sept étapes. Le propriétaire publie d’abord une interface factice afin que l’évaluateur prépare son code sans voir le modèle. Les deux parties vérifient l’attestation de l’enclave. Les poids de Gemini et les questions privées y sont transmis par des canaux chiffrés distincts. Le calcul ne commence qu’après l’approbation du code par chacun. Enfin, seules des métriques bornées sont renvoyées, avant la destruction de l’environnement.
Ce qui a réellement été testé
Google DeepMind, AVERI et MLCommons ont utilisé une partie de réserve d’AILuminate qui n’avait encore été traitée par aucun modèle. Les prompts couvrent notamment les risques chimiques, biologiques, radiologiques, nucléaires et explosifs, les cyberattaques, la haine, l’automutilation et le crime violent. AVERI a chiffré les entrées, déchiffré les sorties et évalué les réponses.
Le Singapore AI Safety Institute a mené une seconde évaluation avec des demandes privées centrées sur la production de contenus nuisibles dans le contexte singapourien. Cette composante est importante : un test de sécurité conçu dans un seul pays ou une seule langue peut manquer des références locales, des tensions sociales ou des formes de préjudice propres à un autre environnement.
Le rapport ne donne pourtant ni note globale, ni comparaison avec d’autres modèles, ni détail permettant de conclure que Gemini 2.5 Flash Lite a réussi ou échoué sur ces risques. Le pilote valide surtout le circuit de confidentialité. Il montre que le modèle et le benchmark peuvent être réunis pour un calcul sans que leurs propriétaires obtiennent automatiquement accès au secret de l’autre.
Ce que la cryptographie règle — et ce qu’elle ne règle pas
L’évaluation en double aveugle répond à une faiblesse précise : la fuite volontaire ou accidentelle des questions vers le développeur. Elle peut prolonger la durée de vie d’un benchmark privé et rendre plus crédible l’affirmation selon laquelle un modèle rencontre les tâches pour la première fois.
Elle facilite aussi des évaluations sensibles. Un institut public pourrait vouloir mesurer les capacités cyber d’un modèle avec des scénarios qu’il serait dangereux de diffuser. Une entreprise pourrait tester un assistant sur des dossiers réglementaires confidentiels. Un hôpital pourrait comparer un modèle à des cas cliniques protégés. Dans ces situations, la confidentialité n’est pas seulement un avantage concurrentiel ; elle conditionne la possibilité même du test.
La méthode ne garantit toutefois pas que les questions sont bonnes. Un benchmark peut être trop étroit, mal annoté, culturellement biaisé ou facilement contournable tout en étant parfaitement secret. AILuminate reconnaît lui-même des limites : incertitude des évaluateurs automatiques, interactions principalement en un tour et couverture incomplète des langues et des catégories émergentes. La méthodologie de MLCommons mesure des violations selon un standard défini ; elle ne certifie pas qu’un produit est sûr dans tous ses usages.
Le double aveugle n’empêche pas non plus l’évaluateur de divulguer les questions de son côté, ni le propriétaire de sélectionner l’épreuve qui l’avantage. Il protège le calcul convenu. Il ne remplace ni une gouvernance indépendante, ni la publication transparente des protocoles, ni la répétition des tests par plusieurs organismes.
Google reste encore dans la chaîne de confiance
Le rapport est particulièrement utile lorsqu’il décrit ses propres limites. Toute l’expérience a été hébergée sur Google Cloud pour tester un modèle de Google DeepMind. Les auteurs reconnaissent que toutes les implémentations propriétaires de Gemini n’ont pas pu être supprimées ou inspectées. AVERI a accepté cette contrainte, mais une partie du code n’était donc pas vérifiable par une simple liste de fonctions autorisées.
Autre réserve : les constructions du système d’exploitation invité ne sont pas entièrement reproductibles de manière indépendante, notamment parce qu’elles utilisent des clés de signature privées. Le dispositif s’appuie en outre sur des services de Google pour signer et vérifier certaines attestations. L’enclave réduit fortement l’accès de l’opérateur, mais elle n’élimine pas Google du chemin de confiance.
Cette nuance compte. « Cryptographiquement vérifiable » ne signifie pas « sans confiance ». Les participants doivent encore faire confiance aux racines matérielles d’Intel et de NVIDIA, à l’intégrité de la chaîne logicielle, à la configuration du cloud et aux politiques qui limitent ce que le résultat peut révéler. Une vulnérabilité dans l’une de ces couches pourrait affaiblir les garanties.
Google Cloud travaille déjà à dissocier une partie de cette vérification du fournisseur : son offre Confidential Space permet désormais d’utiliser Intel Trust Authority comme service d’attestation indépendant. Mais le billet de Google Cloud qui décrit cette évolution reste celui du fournisseur de l’infrastructure. Une adoption large exigera des audits tiers, des implémentations concurrentes et des procédures reproductibles.
Le prochain défi sera organisationnel autant que technique
Un premier prototype mené en 2024 par OpenMined, l’institut britannique de sécurité de l’IA et Anthropic avait déjà testé des enclaves pour l’évaluation. Il utilisait toutefois GPT-2 et un échantillon de cinq lignes, sans réunir deux actifs propriétaires réels. Le nouveau pilote franchit cette étape avec un modèle fermé de classe frontière et des questions privées.
Le passage à l’échelle reste difficile. Les plus grands modèles ne tiennent pas sur un seul H100 ; ils nécessitent des grappes de GPU et des connexions chiffrées entre plusieurs machines. Chaque nœud ajoute du matériel, des dépendances et des preuves à vérifier. Le rapport estime que le surcoût brut du calcul confidentiel peut rester inférieur à 5 %, mais identifie un goulot d’étranglement plus prosaïque : les accords juridiques, la revue du code et la coordination humaine.
Ce constat est presque rassurant. L’obstacle n’est plus seulement de construire une boîte cryptographique assez solide. Il faut décider qui définit l’épreuve, qui peut lancer le test, quelles sorties sont autorisées, comment un résultat négatif est communiqué et quelles conséquences suivent pour le modèle.
Des scores moins brillants, mais enfin plus croyables
L’industrie de l’IA s’est habituée aux tableaux où chaque nouvelle version gagne quelques points. Cette précision apparente masque souvent une question plus fondamentale : le modèle a-t-il réellement été surpris par le test ? Tant qu’un laboratoire voit les questions ou qu’un auditeur dépend entièrement de son API, la réponse conserve une part de confiance institutionnelle difficile à vérifier.
L’évaluation en double aveugle ne rendra pas tous les classements honnêtes et ne transformera pas une mauvaise épreuve en bonne science. Elle fournit néanmoins une infrastructure pour séparer trois choses trop souvent confondues : la capacité du modèle, la confidentialité du test et l’intérêt commercial de celui qui publie le score.
La prochaine avancée importante ne sera peut-être pas un Gemini mieux classé, mais un résultat que Google ne pouvait ni préparer ni observer à l’avance, produit par un protocole qu’un tiers peut contrôler. Dans une industrie saturée de records, rendre les conditions de l’examen plus crédibles pourrait valoir davantage qu’un nouveau record.
Références
- Google DeepMind — Piloting the world’s first double-blind AI evaluations
- Google DeepMind, AVERI, Singapore AISI, OpenMined et MLCommons — Double Blind Evals: Resolving the Dual Confidentiality Dilemma in AI Safety Auditing
- MLCommons — AILuminate Safety Methodology
- Rylan Schaeffer et al. — Quantifying the Effect of Test Set Contamination on Generative Evaluations
- Shivalika Singh et al. — The Leaderboard Illusion, NeurIPS 2025
- OpenMined — Secure Enclaves for AI Evaluation
