10 min de lecture - Google Confidential G4 est disponible : testez d’abord l’attestation

Google Cloud a placé l’informatique confidentielle sur ses instances G4 en disponibilité générale le 21 octobre 2026. Le service associe une machine virtuelle protégée par AMD à un GPU NVIDIA RTX PRO 6000 Blackwell. Le chiffrement et l’attestation visent à protéger les poids du modèle, les prompts et les données pendant le calcul.

Ce nouveau contrôle répond à un besoin précis lorsque le modèle de menace inclut les accès privilégiés à l’infrastructure. Il ne prouve ni la conformité, ni la résidence des données, ni la sécurité de l’application. L’acheteur doit encore définir les preuves attendues, leur vérificateur et les secrets qui resteront indisponibles en cas d’échec.

Le premier pilote doit donc tester l’attestation et la remise des clés, pas simplement vérifier qu’un modèle répond sur une machine virtuelle confidentielle.

Ce qui est désormais disponible

Selon l’annonce de Google Cloud, Confidential G4 est accessible dans 36 zones, sur des machines Compute Engine et des nœuds GKE, avec plusieurs modes de consommation. Google décrit trois mécanismes : des clés matérielles non exportables, l’attestation distante et le chiffrement de la mémoire. Les images Ubuntu, pilotes NVIDIA et bibliothèques CUDA-X habituels peuvent fonctionner sans refonte de l’application.

Google annonce une baisse de débit inférieure à 3,5 % dans ses tests de Llama 3, Llama 3.3, ResNet-50 et SDXL sur un type de machine. Ce chiffre vient d’un test fournisseur, pas d’un plan de capacité. Le même billet précise que les résultats varient selon la charge, la configuration et le matériel. Mesurez la latence, le débit, les démarrages à froid et la reprise avec votre modèle, sa fenêtre de contexte et votre trafic.

Une annonce voisine reste au futur. Google prévoit la disponibilité générale de Confidential Space pour ce dispositif dans les semaines à venir. Ne l’intégrez pas à une décision actuelle avant de confirmer son statut et sa couverture régionale.

Un GPU confidentiel répond à une question de sécurité

Le chiffrement courant protège le stockage et le transport. Un serveur de modèle doit déchiffrer les prompts, documents récupérés et poids pour les traiter. L’informatique confidentielle ajoute un environnement d’exécution protégé par le matériel et des preuves sur cet environnement. Un vérificateur peut alors comparer son état à une politique approuvée avant de remettre les éléments sensibles.

Le Confidential Computing Consortium décrit l’attestation comme une décision de politique appuyée sur des preuves matérielles. Dans son exemple de remise sécurisée, la clé de déchiffrement reste bloquée si le micrologiciel ou un autre composant mesuré ne respecte pas la politique. Le contrôle dépend donc de deux éléments : une preuve récente et une décision qui modifie réellement l’accès de la charge.

Pour les documents privés, les modèles propriétaires ou les données de recherche partagées, un GPU confidentiel peut réduire l’exposition à certaines parties de l’infrastructure hôte. Il ne corrige ni un compte de service trop puissant, ni un index documentaire empoisonné, ni une injection de prompt, ni une API qui renvoie une information sensible au mauvais appelant.

Construisez le vérificateur avant de déplacer les données

Un lancement réussi depuis la console prouve que la plateforme a accepté une configuration. Il ne prouve pas que votre organisation refusera une configuration inattendue le mois suivant.

Commencez par écrire une politique d’attestation lisible par un ingénieur et un responsable sécurité. Nommez le type de machine, les modes CPU et GPU, l’image invitée, l’exigence Secure Boot, les versions de pilote et de micrologiciel, puis le propriétaire de chaque valeur de référence. Décrivez aussi l’entrée des mises à jour dans l’ensemble approuvé. Une politique qui accepte toute version signée identifie le fournisseur, mais ne définit pas votre propre décision d’acceptation.

Rendez ensuite la preuve récente. Le guide d’attestation des Confidential VM utilise un nonce dans le flux de preuve GPU, sépare la collecte de la vérification et distingue l’attestation du pilote de celle du matériel. Il recommande aussi Secure Boot pour mieux vérifier le pilote. Un rapport conservé aide au diagnostic, mais ne devrait pas autoriser une nouvelle remise de secrets sans nouveau défi cryptographique.

Exécutez la vérification hors de la charge évaluée. Le vérificateur compare les mesures et paramètres à la politique, conserve une décision compacte et bloque par défaut une preuve absente, périmée ou inconnue. N’y copiez ni prompts ni secrets. Conservez plutôt la version de politique, l’empreinte de la preuve, l’identité de la charge, l’heure et le motif de la décision.

Reliez enfin le résultat à une conséquence. Remettez la clé du modèle ou l’identifiant de données après la validation, jamais avant. Sinon, le rapport observe un état sans le contrôler. La documentation NVIDIA sur les machines virtuelles confidentielles sépare de la même façon la préparation par le fournisseur cloud et la responsabilité du client qui atteste le GPU avant d’exécuter l’application.

Cette preuve peut rejoindre le dossier d’exécution présenté dans notre guide sur l’ascendance des modèles et les preuves d’exécution. Gardez les affirmations distinctes : l’attestation décrit un environnement mesuré, tandis que la provenance explique l’origine d’un artefact.

Testez les cas opérationnels difficiles

Confidential G4 ajoute des contraintes à inscrire dans le pilote. Le guide de création documente un type de machine G4 pour ce chemin, AMD SEV comme paramètre confidentiel, les besoins de quota GPU et des frais de licence NVIDIA Confidential Computing. La comparaison des coûts doit inclure ces frais, l’accès à la capacité, le temps d’inactivité et le travail autour de la vérification. Le chiffre de débit publié dans l’annonce ne couvre aucun de ces éléments.

La page des configurations prises en charge indique qu’une machine existante ne peut pas être convertie sur place. Elle liste aussi des limites de stockage et de réseau, puis exclut les clusters de charges multinœuds avec GPU NVIDIA confidentiels. Une équipe qui entraîne un modèle sur plusieurs nœuds, dépend d’un type de disque précis ou attend une migration à chaud doit mener une revue d’architecture séparée.

L’attestation connaît aussi des échecs. La documentation Google signale actuellement une possible divergence de mesure GPU et conseille un arrêt complet suivi d’un redémarrage. Reproduisez ce cas pendant le pilote : confirmez le blocage des secrets, l’alerte au responsable, le remplacement de l’instance et la reprise sans désactiver la vérification pour rétablir le trafic.

Le pilote doit répondre à quatre questions concrètes :

1. Une instance neuve prouve-t-elle son état CPU, GPU, démarrage et pilote avant de recevoir les secrets ?
2. Une mesure modifiée ou inconnue bloque-t-elle la clé avec un motif exploitable ?
3. Que deviennent les requêtes pendant le remplacement d’une instance refusée ?
4. L’équipe peut-elle approuver un nouveau pilote ou une image sans accepter toutes les futures versions ?

Un test limité à une inférence réussie ignore la raison d’acheter ce contrôle.

Choisissez selon la menace, pas selon l’étiquette

Une PME ou une équipe produit n’a pas toujours les ressources pour maintenir un service d’attestation sur mesure, mais ne peut pas dépendre d’un contrôle compris par un seul spécialiste. Préférez une politique courte, un vérificateur documenté et une charge avec un propriétaire de données identifié. Demandez à un second ingénieur de reproduire l’échec et la reprise avant d’élargir le dispositif.

Les achats devraient demander des preuves exportables et des limites précises, plutôt qu’un simple label. Quels composants sont mesurés ? Qui fournit les références ? Où tourne le vérificateur ? Quel événement révoque une mesure admise ? Quels chemins de stockage, réseau, administration et application restent hors de la frontière protégée ?

La disponibilité générale simplifie l’achat d’un GPU confidentiel. La décision d’ingénierie reste précise : identifiez l’accès privilégié à exclure, prouvez que l’environnement approuvé tourne et refusez les clés dans le cas contraire. L’approche de services d’Exceev peut relier ce modèle de menace à une architecture cloud testée et à un transfert opérationnel.

Sources et limites

Nous avons ouvert et relu chaque source ci-dessous le 21 octobre 2026.

• L’annonce de disponibilité générale de Google Cloud établit la date, la couverture annoncée, les mécanismes, la compatibilité logicielle et les tests menés par le fournisseur.
• Le guide Google Cloud de création d’une VM confidentielle avec GPU documente le type de machine, AMD SEV, les modes de provisionnement, le quota et les frais de licence.
• La page Google Cloud des configurations prises en charge fournit les limites de conversion, de stockage, de réseau et de calcul multinœud.
• Le guide Google Cloud sur l’attestation documente les preuves CPU et GPU, Secure Boot, les nonces, la vérification et le problème de mesure actuel.
• La documentation NVIDIA sur les VM confidentielles explique l’extension de la protection CPU vers la mémoire GPU et la répartition des responsabilités.
• La note du Confidential Computing Consortium apporte une explication indépendante de l’attestation distante et de la remise conditionnelle des clés.

Nous n’avons pas déployé d’instance G4, vérifié la capacité régionale, examiné les tarifs, reproduit les tests Google ni testé le problème d’attestation documenté. La prise en charge, les limites, les performances et les frais peuvent évoluer après cette revue. Les modèles proposés sont des recommandations, pas une garantie de sécurité, une certification, un avis juridique ou un constat de conformité, de résidence ou de respect de la vie privée.