Feuille de route PQC 2029 de Google Cloud : ce que cela implique pour votre PKI

Le 11 août 2026, Google Cloud a publié « PQC in Plaintext: Google Cloud's post-quantum cryptography roadmap », signé par Jai Haridas (VP/GM, Regulated and Sovereign Cloud) et Michael Bachman (VP/GM, Cloud Foundations). L'annonce fixe un objectif clair : une préparation post-quantique complète sur l'ensemble de Google Cloud d'ici 2029, avec des travaux qui se poursuivront dans les années 2030 pour suivre l'évolution des recommandations telles que CNSA 2.0 et les trajectoires de transition du NIST IR 8547, qui anticipent l'abandon définitif des algorithmes vulnérables au quantique entre 2030 et 2035.

Les feuilles de route des hyperscalers méritent l'attention bien au-delà de leur propre base de clients, parce qu'elles font office d'horloge de facto pour tout le secteur. Lorsque l'une des plus grandes infrastructures mondiales engage des moyens d'ingénierie et des dates sur une transition cryptographique, elle déplace le niveau de référence pour tout le monde : les organismes de normalisation obtiennent des retours d'implémentation à grande échelle, les auditeurs disposent d'un point de comparaison, et chaque organisation consommatrice de services cloud hérite d'un calendrier qu'elle n'a pas fixé. Cette feuille de route mérite une lecture attentive pour une seconde raison. Enfoui dans sa section la plus lourde de conséquences se trouve un rappel : aucun fournisseur de cloud, aussi compétent soit-il, ne peut réaliser votre part de la migration.

Trois domaines, une date de convergence

Google structure sa migration autour du Google Quantum Threat Model, décliné en trois domaines de risque, chacun avec sa propre échéance.

Le premier domaine est la mitigation du Store Now, Decrypt Later (SNDL), visée pour fin 2027. C'est la même menace de collecte-puis-déchiffrement que les récentes recommandations TLS de l'IETF traitent comme le front urgent : un adversaire enregistre aujourd'hui du trafic chiffré et le déchiffre dès qu'un ordinateur quantique cryptographiquement pertinent existe. La réponse de Google couvre les points d'entrée exposés aux clients, les chemins d'accès des administrateurs et des développeurs (Cloud VPN, Interconnect, SDK, bibliothèques clientes) ainsi que les pipelines de données des plateformes d'analytique et de stockage.

Le deuxième domaine est l'intégrité et la non-répudiation, visé pour fin 2028. Il couvre tout ce qu'un attaquant quantique pourrait falsifier plutôt que déchiffrer : les attestations de chaîne d'approvisionnement logicielle, les signatures numériques, les jetons d'identité et, avant tout, les certificats. Google s'engage à faire migrer ses autorités de certification internes et externes vers des certificats ML-DSA, avec SLH-DSA là où cela a du sens, en suivant les travaux de normalisation de l'IETF auxquels l'entreprise contribue activement. Son offre de CA privée doit prendre en charge la PQC en 2027, Cloud IAM en 2028, et un déploiement large de certificats PQC est prévu sur l'ensemble des produits en 2027 et 2028.

Le troisième domaine est celui des fondations et de la gestion des clés, également visé pour fin 2028 : algorithmes approuvés par le NIST dans Cloud KMS et dans les bibliothèques BoringSSL et Tink, racines de confiance matérielles résistantes au quantique dans Confidential Computing et Cloud HSM (FIPS 140-3 niveau 3), et orchestration PQC pour la gestion de clés externes et côté client. Une réserve honnête ressort du document : la transition matérielle suit à la fois le remplacement actif et les cycles naturels de renouvellement des équipements, si bien que certains composants physiques pourront dépasser 2029. Quiconque a géré un parc de HSM reconnaîtra ce réalisme.

Ce qui est déjà en production : les jalons 2026

La crédibilité de la feuille de route repose sur ce qui a déjà été livré, et la liste est substantielle. Les points d'accès des API Google Cloud, dont google.com et *.googleapis.com, proposent désormais un échange de clés hybride quantum-safe fondé sur ML-KEM (FIPS 203), standardisé par le NIST. Les load balancers applicatifs et proxy prennent en charge X25519MLKEM768 pour TLS 1.3 sur activation volontaire, ce qui permet aux clients de valider le comportement avant une activation généralisée. Cloud KMS est disponible en version générale pour ML-KEM, ML-DSA et SLH-DSA, et l'import de clés quantum-safe est en cours de développement.

L'élément le plus prospectif concerne les certificats. Google collabore avec le groupe de travail PLANTS de l'IETF et expérimente, aux côtés de Chrome et de Cloudflare, les Merkle Tree Certificates, une construction inédite conçue pour maîtriser la taille des signatures post-quantiques dans la WebPKI. Les grandes chaînes de certificats PQC constituent l'un des problèmes pratiques les plus ardus de la transition — celui-là même que les recommandations applicatives TLS de l'IETF traitent par la compression et les certificats abrégés — et le fait qu'un hyperscaler, un navigateur et un CDN testent des alternatives structurelles à grande échelle indique que le secteur juge les correctifs incrémentaux insuffisants à eux seuls.

Deux constats découlent de ces jalons. D'abord, l'échange de clés hybride n'est plus expérimental : il est déployé sur certains des points d'accès les plus sollicités d'Internet. Ensuite, le volet confidentialité de la transition est mesurablement en avance sur le volet authentification, précisément le séquencement sur lequel la communauté de normalisation a convergé. L'échange de clés d'abord, parce que le SNDL le rend urgent. Les certificats ensuite, parce que la migration d'une PKI prend des années et que les normes se stabilisent encore.

La phrase qui concerne tous les lecteurs

Le passage le plus important de la feuille de route pour quiconque n'appartient pas à Google est sa section sur la responsabilité partagée. Google délimite son propre périmètre avec précision : la sécurité du cloud, c'est-à-dire le réseau, le chiffrement en transit, les frontaux mondiaux, les protocoles internes, les serveurs et les racines de confiance en silicium telles qu'OpenTitan, Caliptra v2.1 et TPM 2.0 v185. Vient ensuite la ligne de partage : la sécurité dans le cloud reste la responsabilité du client. Dans les termes mêmes de Google, les organisations gèrent leurs propres applications, mettent à jour les logiciels côté client pour négocier des handshakes PQC, gèrent le cycle de vie de leurs clés asymétriques et mettent à jour la configuration de leurs services avec des paramètres et des politiques quantum-safe.

Traduit en termes opérationnels : le fournisseur fait migrer la tuyauterie, et tout ce qui y circule et que vous avez créé reste à votre charge — vos certificats, vos clés, vos ancres de confiance, la cryptographie de vos applications et votre PKI privée. Un load balancer quantum-safe termine un handshake quantum-safe, et cela ne dit rien de la hiérarchie de certificats avec laquelle vos workloads s'authentifient, des clés de signature de code de votre chaîne de livraison, ni des certificats d'équipement valables dix ans dans votre usine.

Les premières étapes recommandées par Google confirment où commence le travail du client : inventorier les ressources cryptographiques, mettre à jour les piles logicielles vers des versions compatibles PQC, valider le comportement des applications face à des points d'accès quantum-safe. L'inventaire vient en premier, et ce n'est pas un hasard. C'est l'étape qu'aucun fournisseur ne peut réaliser à votre place, parce que vous seul savez quelles clés et quels certificats existent dans votre parc, qui en est propriétaire, quelle durée de vie de données ils protègent et lesquels sont seulement en mesure de supporter un changement d'algorithme. Toute méthodologie de migration crédible, du NIST à l'ANSSI en passant par les fournisseurs de cloud eux-mêmes, commence désormais au même endroit : savoir ce que l'on possède.

Lire la feuille de route depuis l'Europe

Pour les organisations européennes, la feuille de route croise trois débats en cours.

Le premier est l'alignement réglementaire. Les échéances 2027 et 2028 des domaines de Google arrivent confortablement en avance sur la feuille de route coordonnée de l'UE sur la cryptographie post-quantique, qui appelle à une protection hybride des flux à haut risque avant 2030 et à des trajectoires de migration complètes d'ici 2035, ainsi que sur les horizons du NIST IR 8547 et de CNSA 2.0. Les entités régulées au titre de DORA et NIS2 constateront que le versant fournisseur de leur dépendance au cloud avance plus vite que ne l'exigent leurs obligations, ce qui déplace l'attention vers le versant client de la ligne de responsabilité partagée. Un auditeur qui interrogera la préparation quantique en 2028 obtiendra une réponse solide sur l'infrastructure, puis il posera la question des certificats et des clés que l'organisation contrôle elle-même.

Le deuxième est la posture algorithmique. La feuille de route de Google inclut des certificats ML-DSA et SLH-DSA purs dans ses services de CA privée. Les recommandations européennes, notamment celles de l'ANSSI et du BSI, ont constamment privilégié les constructions hybrides pendant la période de transition, combinant algorithmes classiques et post-quantiques afin que la sécurité tienne si l'un des deux composants cède. Les deux positions se défendent, et elles ne s'excluent pas mutuellement à l'échelle d'un grand parc. La conséquence pratique : les organisations européennes pourront appliquer des exigences hybrides sur certains périmètres et des options PQC pures sur d'autres, ce qui fait de l'application de politiques par population de certificats une exigence de gouvernance et non un raffinement.

Le troisième est la souveraineté. Il est notable que l'annonce soit cosignée par le dirigeant responsable du Regulated and Sovereign Cloud de Google, et que le déploiement de la PQC sur Google Cloud Dedicated et Google Distributed Cloud soit explicitement mentionné. La préparation quantique s'invite dans la conversation sur la souveraineté, et les organisations européennes qui s'interrogent sur l'endroit où résident leurs racines de confiance, sur qui opère leurs CA et sur qui détient leurs clés intégreront désormais les calendriers post-quantiques à des décisions déjà stratégiques. L'excellente feuille de route d'un fournisseur sécurise la couche d'infrastructure, et elle laisse entière la question de savoir qui gouverne la hiérarchie de confiance au-dessus.

En conclusion

« PQC in Plaintext » est une feuille de route sérieuse, datée et d'une franchise inhabituelle, jusqu'à reconnaître que certains matériels survivront à l'objectif 2029. Elle confirme le séquencement sur lequel tout le secteur a convergé : l'échange de clés hybride maintenant, les certificats et les signatures jusqu'en 2028, l'agilité comme fondation permanente. Elle trace aussi, avec les mots du fournisseur lui-même, la frontière qui définit les trois prochaines années de travail pour tous les autres. La moitié infrastructure de la transition quantique est prise en charge par des équipes aux moyens de classe mondiale et aux échéances publiques. L'autre moitié — les certificats, les clés et les hiérarchies de confiance que les organisations possèdent — a les mêmes échéances et un seul responsable.

La lecture prudente reprend le conseil de Google lui-même, généralisé au-delà d'un cloud particulier : inventoriez ce que vous possédez, où que cela se trouve. Les organisations capables d'énumérer leur parc cryptographique, d'en attribuer la propriété et de répéter un changement d'algorithme à l'échelle de la hiérarchie vivront les feuilles de route des fournisseurs de la fin des années 2020 comme un vent portant. Celles qui en sont incapables découvriront en 2029 que la tuyauterie est devenue quantum-safe des années avant le trafic.