Google Cloud fixe 2029 pour achever sa migration vers la cryptographie post-quantique
Le 11 août 2026, Google Cloud publie sa feuille de route de migration vers la cryptographie post-quantique, avec un objectif de pleine maturité en 2029 et des jalons datés pour 2027 et 2028. Pour un client, le risque Store Now Decrypt Later a désormais une échéance : l’inventaire cryptographique commence aujourd’hui.
11 août 2026. Google Cloud publie sa feuille de route de migration vers la cryptographie post-quantique (PQC). Mars 2026, le groupe avançait déjà son échéance à 2029. Désormais, les jalons sont datés, service par service, jusqu’en 2028 — et le travail se prolongera « dans les années 2030 ».
Le message pour un RSSI ou un CTO est simple : le risque Store Now Decrypt Later — des données chiffrées aujourd’hui et décryptées plus tard par un ordinateur quantique — a maintenant une échéance constructeur. La question n’est plus « faut-il migrer », mais « votre inventaire cryptographique est-il prêt ».
Pourquoi 2029 : la menace quantique est devenue un calendrier
En mars 2026, Google annonçait avancer son objectif de migration PQC à 2029, citant des progrès « plus rapides que prévu » du matériel quantique et de la correction d’erreurs. La feuille de route publiée le 11 août 2026 transforme cette ambition en plan d’exécution, structuré autour d’un modèle de menace quantique interne et de trois priorités : atténuer le risque SNDL (Store Now Decrypt Later), renforcer les signatures numériques contre la falsification, et construire l’agilité cryptographique nécessaire pour adopter les nouveaux standards à mesure qu’ils émergent.
Plusieurs briques sont déjà en production. Les points de terminaison d’API de Google Cloud — dont google.com et googleapis.com — utilisent désormais l’échange de clés ML-KEM standardisé par le NIST, en mode hybride avec un algorithme classique. Les équilibreurs de charge d’application et de proxy supportent l’échange de clés hybride quantum-safe pour TLS 1.3 en opt-in, ce qui permet à un client de valider le changement dans son propre environnement. Et Cloud KMS est passé en disponibilité générale pour les algorithmes PQC standardisés par le NIST, couvrant à la fois l’échange de clés et les signatures.
Les jalons datés : 2027 pour le chiffrement, 2028 pour les signatures
La feuille de route fixe fin 2027 comme échéance pour atténuer le risque SNDL sur les charges de travail exposées aux clients, sur l’outillage d’administration et de développement — dont Cloud VPN et Interconnect — et sur les services de transfert de données comme le CLI BigQuery et Storage Transfer Service.
L’intégrité des signatures et la protection des identités disposent d’un horizon plus long, ciblé pour fin 2028. Cela couvre les attestations de chaîne d’approvisionnement logicielle quantum-safe, le déploiement de certificats quantum-safe dans l’infrastructure de Google, et le durcissement des mécanismes d’identité comme Cloud IAM.
La gestion des clés suit le même cap fin 2028, mais à des vitesses variables : Cloud KMS doit supporter l’import de clés quantum-safe dès 2026, tandis que les protections adossées au matériel — informatique confidentielle, Cloud HSM, gestion de clés externe et options de souveraineté des clés — sont planifiées pour 2028. Côté silicium, Google ancre la confiance dans des composants open source, dont Caliptra et OpenTitan, ce dernier supportant déjà un démarrage quantum-secure.
Le groupe prévient que l’effort se poursuivra « dans les années 2030 », pour accompagner les standards CNSA 2.0 et les trajectoires de transition de NIST IR 8547, qui prévoient la dépréciation finale des algorithmes vulnérables au quantique entre 2030 et 2035.
La part du client : l’infrastructure ne suffit pas
La feuille de route trace une ligne claire entre ce que Google sécurise et ce qui reste à la charge du client. L’entreprise assume la sécurité de son infrastructure ; le client reste responsable de mettre à jour ses logiciels côté client, de gérer le cycle de vie de ses propres clés et de reconfigurer ses services pour activer les réglages quantum-safe une fois disponibles.
Concrètement, Google recommande trois premières étapes. Inventorier les actifs cryptographiques — clés, certificats, usages — pour savoir où le SNDL vous expose. Mettre à jour l’outillage de développement et d’exploitation pour qu’il supporte les bibliothèques compatibles PQC. Et tester les applications existantes contre les API et les équilibreurs de charge quantum-safe déjà disponibles, avant que la migration ne devienne obligatoire.
Store Now Decrypt Later : ce que l’échéance de 2029 protège vraiment
Le SNDL n’a pas besoin d’un ordinateur quantique opérationnel pour être un risque. Le principe : un adversaire enregistre aujourd’hui vos flux chiffrés — TLS, VPN, sauvegardes — et les stocke ; le jour où un ordinateur quantique saura casser l’algorithme sous-jacent, il les déchiffre rétroactivement. Une donnée capturée en 2026 et qui doit rester secrète jusqu’en 2036 est donc déjà exposée.
C’est pourquoi l’échéance de 2029 compte. Elle ne dit pas quand l’ordinateur quantique arrivera — personne ne le sait précisément. Elle dit quand l’infrastructure de Google Cloud aura remplacé les algorithmes vulnérables par des algorithmes PQC. Entre ces deux dates, votre seule protection contre le SNDL est de migrer vos charges vers des échanges de clés quantum-safe le plus tôt possible, car chaque jour de chiffrement classique est un jour de donnée potentiellement capturable.
Le mode hybride et l’agilité cryptographique : migrer sans tout casser
Le mode hybride choisi par Google Cloud est la clé de voûte de la transition. Un échange de clés hybride combine un algorithme classique (X25519, par exemple) et un algorithme PQC (ML-KEM) : la clé de session est dérivée des deux. Si l’algorithme quantique s’avère fragile, le composant classique continue de protéger la session ; si l’algorithme classique tombe, le composant PQC prend le relais.
C’est le compromis à imiter : ne pas attendre la maturité totale des standards pour commencer, mais ne pas basculer brutalement vers un algorithme encore jeune. L’agilité cryptographique — la capacité à changer d’algorithme sans réécrire l’application — est précisément ce qui rend ce double filet possible, et c’est la leçon la plus transférable de la feuille de route.
La démarche s’inscrit dans un courant réglementaire plus large : la CNSA 2.0 américaine et NIST IR 8547 encadrent la dépréciation des algorithmes classiques, et les agences américaines ont déjà des échéances de migration. Un fournisseur cloud qui publie une feuille de route PQC datée n’est plus une exception ; c’est en train de devenir un critère de sélection.
L’inventaire : l’étape la plus dure
En pratique, l’inventaire est l’étape la plus dure. La plupart des organisations connaissent les certificats de leurs points de terminaison publics, mais pas les clés et certificats des services internes, des connexions de bases de données, des files de messages et des intégrations tierces. Commencez là où le SNDL fait le plus mal — les données dont l’horizon de confidentialité dépasse 2030 — et par les comptes de service qui les protègent. L’inventaire construit pour le PQC sert aussi à la gestion du cycle de vie des certificats : un rare cas où une migration de sécurité se paie deux fois.
Verdict
Si vous manipulez des données qui devront rester confidentielles au-delà de cinq à dix ans — santé, défense, propriété industrielle, secrets de conception — le risque Store Now Decrypt Later est déjà actif : un adversaire peut capturer vos flux chiffrés aujourd’hui et les décrypter demain. Commencez l’inventaire cryptographique immédiatement ; c’est l’étape que tout le monde repousse et qui conditionne toutes les autres.
Si vous êtes client de Google Cloud, testez dès maintenant l’échange de clés hybride quantum-safe sur vos équilibreurs de charge et vos appels d’API — c’est le moyen le plus concret de mesurer l’impact de la migration sur vos applications avant l’échéance de 2027.
Pour les équipes qui attendent « le standard final » : le standard est déjà là — ML-KEM, ML-DSA et SLH-DSA sont standardisés par le NIST. L’agilité cryptographique n’est pas un projet qu’on lance en 2028 ; c’est une capacité qu’on construit maintenant.