Akamai a franchi une étape que peu d’observateurs attendaient si tôt : la généralisation du chiffrement post-quantique de bout en bout sur son réseau TLS mondial. L’annonce, confirmée mi-août 2026, couvre à la fois les connexions entre les internautes et le réseau Akamai et celles entre Akamai et les serveurs d’origine de ses clients. Dans la foulée, Google Cloud a précisé sa propre feuille de route pour ses répartiteurs de charge, tandis que l’IETF débat encore de la meilleure façon de standardiser l’algorithme au cœur de ce basculement, ML-KEM. Trois mouvements distincts, une seule direction : la cryptographie post-quantique quitte les laboratoires pour s’installer dans l’infrastructure qui fait tourner une bonne partie du web.
Pour la France et l’Europe, où l’ANSSI a déjà fixé un calendrier de migration strict, ce basculement industriel change la donne. Les entreprises qui pensaient avoir jusqu’à 2027 ou 2030 pour agir découvrent que leurs propres fournisseurs cloud et CDN ont déjà commencé à changer les règles du jeu, souvent sans que leurs équipes techniques en soient pleinement informées.
Akamai généralise le chiffrement post-quantique sur son réseau TLS
Le mouvement n’est pas parti de rien. Akamai avait déjà activé la cryptographie post-quantique sur ses connexions Ghost-to-Origin (G2O) le 30 juin 2025, un premier jalon technique confirmé sur son blog officiel. Trois mois plus tard, en septembre 2025, l’entreprise ouvrait le même mécanisme côté périphérie (edge), permettant aux clients d’activer le groupe de clés hybride TLS 1.3 X25519MLKEM768 pour les connexions entre les navigateurs et son réseau.
Mi-août 2026, ce dispositif atteint son stade final : disponibilité générale sur l’ensemble du réseau Enhanced TLS, pour les deux segments de la connexion à la fois. Concrètement, un client qui charge une page servie par Akamai bénéficie désormais d’une protection quantique-résistante depuis son navigateur jusqu’au serveur d’origine, sans point faible intermédiaire au niveau du CDN. Sur son blog, Akamai résume l’objectif ainsi : traiter la menace du « harvest now, decrypt later » dans le contexte des CDN était une priorité évidente, l’entreprise se disant satisfaite d’avoir livré la cryptographie post-quantique dans ses négociations TLS 1.3, aussi bien côté client que côté origine.
Cette bascule ne concerne pas un service marginal. Akamai gère une part significative du trafic HTTPS mondial via son réseau de diffusion de contenu, ce qui fait de cette généralisation l’un des déploiements de production à plus grande échelle de TLS 1.3 post-quantique jamais réalisés.
Comment fonctionne l’échange de clés hybride X25519MLKEM768
Le nom technique X25519MLKEM768 combine deux mécanismes bien différents. D’un côté, X25519, un échange de clés Diffie-Hellman sur courbe elliptique Curve25519, éprouvé depuis plus d’une décennie. De l’autre, ML-KEM-768, un mécanisme d’encapsulation de clés fondé sur les réseaux euclidiens (lattices), standardisé par le NIST sous la référence FIPS 203 en août 2024. Le résultat est un schéma hybride : pour casser la clé de session, un attaquant devrait vaincre à la fois la cryptographie classique et la cryptographie post-quantique. Tant que l’une des deux tient, la session reste protégée.
Akamai explique sur son blog que déployer une PQC qui interopère, côté client ou côté serveur, nécessite une bibliothèque ou un framework TLS qui prend en charge le dernier échange de clés hybride TLS 1.3 reposant sur un schéma hybride post-quantique/traditionnel. Cette approche prudente explique pourquoi l’industrie a choisi l’hybridation plutôt qu’un passage direct à des algorithmes purement post-quantiques : ML-KEM est un standard récent, encore jeune comparé à des décennies d’analyse cryptographique sur les courbes elliptiques.
L’entreprise précise également que cette capacité permet aux clients d’opter pour la prise en charge du groupe de clés hybride TLS 1.3 X25519MLKEM768, fondé sur le standard ML-KEM (FIPS 203) du NIST. Autrement dit, rien ne change dans le chiffrement du contenu lui-même (AES-256-GCM reste en place, tout comme SHA-2 ou SHA-3 pour l’intégrité) : seule la phase d’établissement de la clé de session évolue.
Google Cloud emboîte le pas avec ses répartiteurs de charge
Le 11 août 2026, Google Cloud a publié sa propre feuille de route pour la cryptographie post-quantique, précisant que ses répartiteurs de charge d’application et de réseau prendraient en charge le même échange hybride X25519MLKEM768. Sur son forum communautaire, l’équipe Google Cloud a écrit : « Nous introduisons la prise en charge de l’échange de clés post-quantique dans nos répartiteurs de charge sous la forme de l’échange de clés hybride X25519MLKEM768 ».
La convergence entre Akamai et Google Cloud sur le même groupe cryptographique n’est pas un hasard. X25519MLKEM768 est devenu le standard de facto pour l’écosystème TLS 1.3 hybride, porté à la fois par les grands navigateurs (Chrome, Firefox, Edge) et par les principaux opérateurs d’infrastructure. Cette uniformisation limite les risques d’interopérabilité qui avaient freiné les précédentes tentatives de déploiement post-quantique, notamment autour de l’algorithme Kyber avant sa standardisation officielle sous le nom ML-KEM.
Pour les clients de Google Cloud qui utilisent des répartiteurs de charge d’application (Application Load Balancer) ou de proxy réseau (Network Proxy Load Balancer), l’activation reste pour l’instant une option à demander explicitement, à l’image du modèle choisi par Akamai. Aucun des deux fournisseurs n’a encore annoncé de bascule automatique et obligatoire pour l’ensemble de leur base de clients.
La controverse à l’IETF : ML-KEM « solo » contre hybride obligatoire
Le calendrier de ces annonces industrielles n’est pas anodin. Début août 2026, un projet de texte à l’IETF visant à enregistrer ML-KEM comme mécanisme de clé autonome pour TLS 1.3, c’est-à-dire sans l’associer systématiquement à un algorithme classique comme X25519, a atteint la phase de Last Call de l’IESG. La période de commentaires s’est achevée le 13 août 2026, deux jours après l’annonce de Google Cloud et la veille de la généralisation d’Akamai.
Le débat oppose deux écoles. La première considère que ML-KEM, validé par le NIST et audité pendant plusieurs années, peut être utilisé seul dans certains contextes, ce qui simplifierait les implémentations. La seconde, plus conservatrice, défend le maintien de l’hybridation comme exigence minimale pour TLS 1.3, au motif qu’aucun algorithme post-quantique n’a encore accumulé la même confiance que les courbes elliptiques classiques. Cette discussion a aussi suscité des critiques sur la transparence du processus de consensus au sein du groupe de travail TLS de l’IETF.
Le fait qu’Akamai et Google Cloud aient choisi, l’un comme l’autre, de déployer exclusivement la version hybride plutôt que d’attendre l’issue de ce débat en dit long sur la doctrine actuelle de l’industrie : mieux vaut la prudence d’une double protection qu’une adoption plus rapide mais plus risquée d’un algorithme post-quantique encore jeune.
Pourquoi maintenant ? La menace du « harvest now, decrypt later »
Aucun ordinateur quantique capable de casser RSA-2048 ou une courbe elliptique standard n’existe aujourd’hui. La justification de cette migration tient dans un scénario différent, connu sous le nom de « harvest now, decrypt later » : un adversaire capture et stocke aujourd’hui du trafic chiffré, dans l’attente de disposer un jour d’un ordinateur quantique suffisamment puissant pour le déchiffrer rétroactivement. Pour des données à durée de vie longue (dossiers médicaux, secrets industriels, communications diplomatiques, archives financières), le risque existe dès maintenant, même si la machine capable de l’exploiter n’apparaîtra que dans dix, vingt ou trente ans.
C’est précisément l’angle que retient Akamai dans sa communication : protéger la confidentialité des échanges d’aujourd’hui contre des capacités de calcul qui n’existent pas encore. Cette logique explique pourquoi les CDN et les clouds bougent avant même l’apparition d’une menace concrète : la fenêtre de protection utile se compte en années de collecte de trafic, pas en mois.
Entre le 10 et le 24 août 2026, plusieurs bulletins de sécurité ont rappelé que les failles critiques du moment restent d’une tout autre nature. La CISA a ajouté à son catalogue de vulnérabilités activement exploitées plusieurs CVE majeures, dont CVE-2026-33824 sur le protocole IKE de Microsoft et CVE-2026-59310 sur VMware vCenter, avec des délais de remédiation fixés début septembre 2026. Ces failles relèvent de problèmes de gestion mémoire ou d’authentification, pas d’une faiblesse des primitives cryptographiques. AES-256, SHA-2 et un TLS 1.3 bien configuré restent robustes face à ces incidents, ce qui illustre la nature de la menace post-quantique : stratégique et à long terme, pas une urgence immédiate.
Contexte historique : de la standardisation NIST à l’adoption industrielle
Ce mois d’août 2026 marque l’aboutissement d’un processus entamé bien plus tôt. Le NIST a lancé son concours post-quantique en 2016, sélectionné Kyber (devenu ML-KEM) en 2022, puis finalisé FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA) en août 2024. Cette finalisation a servi de signal de départ pour l’industrie, en permettant aux acheteurs de remplacer des tests exploratoires par des programmes de migration alignés sur un standard stable.
Cloudflare a été l’un des tout premiers grands réseaux à publier des chiffres d’adoption réels. Selon le blog de l’entreprise, la part du trafic HTTPS humain protégé par un échange de clés post-quantique hybride est passée d’environ 2 % en mars 2024 à plus d’un tiers en mars 2025, puis à environ 43 % en septembre 2025, pour atteindre près de 52 % fin 2025 selon son rapport « State of the post-quantum Internet in 2025 ». Sur ce même réseau, le groupe X25519MLKEM768 représente désormais environ 95 % des connexions post-quantiques observées, ce qui confirme sa position de standard de facto porté par les navigateurs récents, Chrome 131+, Firefox 132+ et Edge 131+ en tête.
AWS n’est pas resté à l’écart. CloudFront a annoncé le 5 septembre 2025 la prise en charge de l’établissement de clés post-quantique hybrides dans l’ensemble de ses politiques de sécurité TLS, accompagnée d’une nouvelle politique réservée à TLS 1.3. Amazon a par ailleurs étendu le support de ML-KEM à d’autres services de sa plateforme, dont KMS, ACM, Secrets Manager, S3 et Transfer Family.
Tableau comparatif : l’adoption PQC chez les grands fournisseurs cloud et CDN
La situation reste très inégale d’un fournisseur à l’autre. Certains communiquent des chiffres précis, d’autres se contentent d’annoncer une disponibilité sans publier de mesure de trafic réel. Voici l’état des lieux tel qu’il peut être établi à partir des communications officielles disponibles fin août 2026.
| Fournisseur | Statut PQC | Date de déploiement | Part de trafic PQC |
|---|---|---|---|
| Cloudflare | Hybride X25519+ML-KEM-768 par défaut pour les clients compatibles | Pilote début 2024, généralisation 2025 | ≈52 % du trafic HTTPS fin 2025 |
| Akamai | Hybride X25519MLKEM768, bout en bout (edge + origine), disponibilité générale | G2O le 30/06/2025, edge sept. 2025, GA mi-août 2026 | Non publié |
| AWS CloudFront | Établissement de clés post-quantique hybride sur toutes les politiques TLS | 5 septembre 2025 | Non publié |
| Google Cloud (répartiteurs de charge) | Hybride X25519MLKEM768 sur Application/Network Load Balancer | Feuille de route publiée le 11/08/2026 | Non publié |
| Fastly | Aucune annonce publique documentée à ce jour | Non communiqué | Non publié |
| Microsoft Azure Front Door | Aucune annonce publique documentée à ce jour | Non communiqué | Non publié |
Ce tableau montre une réalité que peu d’articles soulignent : Cloudflare est aujourd’hui le seul acteur à publier une mesure continue et chiffrée de l’adoption réelle par ses utilisateurs. Les autres fournisseurs communiquent sur la disponibilité technique de la fonctionnalité, pas sur son usage effectif. Pour un client entreprise qui doit rendre compte de sa conformité post-quantique à un régulateur, cette différence de transparence compte autant que la fonctionnalité elle-même.
Tester la prise en charge post-quantique d’un serveur
Pour vérifier concrètement si un site négocie déjà l’échange hybride X25519MLKEM768, il suffit d’une commande OpenSSL récente (version 3.2 ou supérieure, qui intègre nativement ML-KEM) :
openssl s_client -connect exemple-cdn.com:443 \
-groups X25519MLKEM768 \
-tls1_3 -briefSi le serveur répond avec “Negotiated TLS1.3 group: X25519MLKEM768” dans la sortie, la connexion est bien protégée par l’échange hybride. Cette vérification prend moins d’une minute et permet à une équipe technique de savoir si son fournisseur a réellement activé la fonctionnalité, plutôt que de se fier uniquement aux annonces marketing.
Impact sur le marché de la cryptographie post-quantique
La bascule opérée par Akamai et Google Cloud intervient dans un secteur en pleine expansion, mais où les cabinets d’analyse peinent à s’accorder sur une taille de marché commune. Les écarts viennent surtout du périmètre retenu : certains comptent uniquement les bibliothèques logicielles, d’autres y ajoutent le matériel embarqué et le conseil.
| Cabinet d’analyse | Taille du marché 2025 | Taille du marché 2026 | TCAC estimé |
|---|---|---|---|
| Research and Markets | 590 M$ | 780 M$ | 30,5 % (vers 2,23 Md$ en 2030) |
| Global Growth Insights | 810,65 M$ | 1 106,46 M$ | Non communiqué |
| Kings Research | 1 129,2 M$ | Non communiqué | 38,08 % (vers 10,8 Md$ en 2032) |
| Ken Research | 1 380 M$ | 1 877 M$ | 37,1 % (2026-2031) |
| MarketsandMarkets | ≈420 M$ | Non communiqué | ≈46 % (vers 2,84 Md$ en 2030) |
Même avec l’estimation la plus prudente, celle de Research and Markets, le marché de la cryptographie post-quantique croît d’environ 30 % par an. Cette dynamique s’explique moins par une demande grand public que par les obligations réglementaires qui s’accumulent en Europe : le CADA impose déjà des niveaux de conformité aux fournisseurs cloud opérant sur le marché européen, et l’ANSSI pousse mécaniquement les intégrateurs à investir dans des solutions prêtes pour la production.
Ce que ça change pour les entreprises et développeurs européens
Pour une entreprise française qui héberge son site derrière Akamai, Cloudflare ou un répartiteur de charge Google Cloud, la bonne nouvelle est que la migration post-quantique du transport TLS ne demande, dans la plupart des cas, aucune ligne de code à modifier côté application. Le CDN gère la négociation cryptographique à sa place, et il suffit généralement de cocher une option dans la console de gestion pour l’activer.
Le point d’attention se situe ailleurs : du côté des serveurs d’origine, des équilibreurs de charge internes et des bibliothèques TLS embarquées dans des applications plus anciennes. Une entreprise peut très bien avoir un CDN entièrement compatible post-quantique en façade, tout en conservant en coulisses des connexions internes qui reposent uniquement sur RSA-2048 ou une courbe elliptique classique. Ce trafic interne, souvent moins surveillé, reste alors exposé au scénario du « harvest now, decrypt later ».
Les équipes techniques ont donc intérêt à cartographier précisément où s’arrête la protection post-quantique offerte par leur CDN, et où recommence une chaîne de connexions encore purement classique. C’est un exercice d’inventaire, pas un chantier de développement, mais il demande du temps et une vision d’ensemble de l’architecture réseau que peu d’organisations possèdent aujourd’hui.
La France et l’Europe face à l’urgence post-quantique
La bascule d’Akamai et de Google Cloud arrive à un moment où les régulateurs européens et français durcissent leurs propres exigences. L’ANSSI a déjà indiqué vouloir rendre la cryptographie post-quantique obligatoire dans ses référentiels de certification à partir de 2027, avec une bascule complète visée pour la fin de la décennie. Aux États-Unis, l’administration a fixé un cap similaire, avec un objectif de migration des systèmes fédéraux critiques d’ici 2030, comme le rappelle notre analyse du décret présidentiel sur la cryptographie post-quantique.
Cette convergence de calendriers, réglementaire d’un côté, industrielle de l’autre, laisse peu de marge d’attente aux entreprises. Un cabinet d’avocats qui traite des dossiers confidentiels sur vingt ans, un hôpital qui conserve des dossiers médicaux pendant des décennies, ou une banque soumise à des obligations d’archivage prudentiel ont tous intérêt à activer l’option post-quantique déjà proposée par leur CDN, plutôt que d’attendre l’échéance réglementaire pour s’y pencher dans l’urgence.
Les limites et critiques de l’approche hybride actuelle
Tout n’est pas réglé pour autant. L’approche hybride a un coût : les messages échangés lors de la poignée de main TLS sont plus volumineux, ce qui peut légèrement allonger le temps d’établissement de connexion. Pour la majorité des usages web, la différence reste imperceptible, mais elle devient sensible pour des appareils IoT contraints ou des connexions satellites.
La deuxième limite tient à la couverture partielle du problème. Le chiffrement du transport n’est qu’un des piliers de la cryptographie à moderniser, aux côtés des signatures numériques (ML-DSA, SLH-DSA) et de la gestion des clés dans les infrastructures à clé publique. La généralisation de ML-KEM dans TLS ne dit rien de l’état de migration des certificats, qui reposent encore très majoritairement sur RSA ou ECDSA, comme le montre notre comparatif entre RSA, ECC et cryptographie post-quantique.
Enfin, la controverse à l’IETF sur ML-KEM « solo » rappelle que le consensus technique n’est pas figé. Si l’industrie devait un jour basculer vers un usage non hybride de ML-KEM pour gagner en performance, cela supposerait une confiance dans l’algorithme post-quantique seul que peu de cryptographes sont prêts à accorder aujourd’hui, quatre ans seulement après sa sélection définitive par le NIST.
Ce que disent les acteurs du secteur
« Traiter la menace du harvest now, decrypt later dans le contexte des CDN était une priorité évidente pour Akamai, et nous sommes heureux d’avoir livré la cryptographie post-quantique dans nos négociations TLS 1.3, aussi bien pour les connexions client-vers-Akamai que pour les connexions Akamai-vers-origine. »
Akamai, blog officiel de sécurité (source)
Sur le déploiement côté origine, l’entreprise avait posé le premier jalon dès l’été 2025 :
« Le 30 juin 2025, Akamai a déployé le support de la cryptographie post-quantique (PQC) dans les connexions Ghost to Origin (G2O) via TLS 1.3. »
Akamai, blog officiel de sécurité (source)
« Pour déployer une PQC qui interopère, côté client comme côté serveur, il faut une bibliothèque ou un framework TLS qui prenne en charge le dernier échange de clés hybride TLS 1.3 fondé sur un schéma post-quantique/traditionnel. »
Akamai, blog officiel de sécurité (source)
« Cette capacité permet aux clients d’opter pour la prise en charge du groupe de clés hybride TLS 1.3 X25519MLKEM768, fondé sur le standard ML-KEM (FIPS 203) du NIST américain. »
Akamai, blog officiel de sécurité (source)
Du côté de Google Cloud, l’équipe en charge des répartiteurs de charge a formulé son annonce sans détour :
« Nous introduisons la prise en charge de l’échange de clés post-quantique dans nos répartiteurs de charge, sous la forme de l’échange de clés hybride X25519MLKEM768. »
Google Cloud, annonce communautaire officielle (source)
Comparaison avec les précédentes vagues de migration cryptographique
Ce basculement rappelle, par son ampleur, la migration de SHA-1 vers SHA-256 entre 2015 et 2017, après la démonstration de la première collision pratique de SHA-1. Il évoque aussi le passage de TLS 1.2 à TLS 1.3, formalisé par la RFC 8446 en 2018 puis accéléré par le gel officiel de TLS 1.2 à l’IETF. Dans les deux cas, la bascule a d’abord été portée par les grands CDN et fournisseurs cloud, avant de se diffuser vers le reste de l’écosystème.
La différence, cette fois, tient à l’absence d’urgence immédiate. La migration de SHA-1 répondait à une faille démontrée. La migration post-quantique, elle, anticipe une menace qui n’existe pas encore sous forme d’ordinateur quantique opérationnel. Cela explique en partie pourquoi l’adoption reste, dix-huit mois après les premiers déploiements de Cloudflare, encore inférieure à 55 % du trafic HTTPS mondial, malgré une couverture quasi totale côté navigateurs.
Prédictions : ce qui va changer d’ici 2027-2030
- Généralisation par défaut d’ici fin 2027. À mesure que les navigateurs imposeront ML-KEM hybride comme configuration par défaut sur la quasi-totalité de leur base installée, les CDN suivront probablement le même chemin que Cloudflare, en rendant l’option active sans action du client.
- Les certificats post-quantiques deviendront le prochain chantier. Une fois le transport sécurisé, l’attention se déplacera vers les signatures ML-DSA et SLH-DSA dans les autorités de certification, un chantier plus lourd car il touche à la chaîne de confiance elle-même.
- Fastly et Azure Front Door devront communiquer des chiffres. La pression concurrentielle et réglementaire, notamment en Europe, devrait pousser les fournisseurs encore silencieux à publier leurs propres données d’adoption d’ici 2027, sous peine de paraître en retard face à Akamai, Cloudflare et AWS.
- Le débat ML-KEM solo pourrait rester sans issue avant 2028. Vu la prudence affichée par Akamai et Google Cloud, qui ont choisi l’hybridation sans attendre l’IETF, une adoption large d’un ML-KEM non hybride paraît peu probable avant que l’algorithme n’ait accumulé plusieurs années supplémentaires d’analyse cryptographique indépendante.
- La conformité post-quantique deviendra un critère de choix de fournisseur. Avec l’échéance ANSSI de 2027 qui approche, les appels d’offres publics et les audits de sécurité en France devraient commencer à exiger explicitement un support PQC démontré côté CDN et cloud, transformant une fonctionnalité optionnelle en critère contractuel.
Comment les équipes techniques peuvent se préparer
La première étape, la plus simple, consiste à vérifier auprès de son CDN ou de son fournisseur cloud si l’option hybride post-quantique est déjà disponible. Pour les clients Akamai Enhanced TLS et les utilisateurs de répartiteurs de charge Google Cloud, la réponse est désormais oui, avec une simple case à cocher dans la console d’administration.
La deuxième étape consiste à tester ses propres serveurs d’origine avec la commande OpenSSL présentée plus haut, afin d’identifier les maillons qui ne supportent pas encore les groupes hybrides. Les bibliothèques TLS récentes (OpenSSL 3.2+, BoringSSL, wolfSSL à jour) prennent déjà en charge ML-KEM : la mise à niveau logicielle est souvent le chemin le plus rapide vers la conformité.
Enfin, mieux vaut documenter dès maintenant sa trajectoire de migration, même partielle, plutôt que d’attendre une obligation réglementaire formelle. Face à un auditeur, montrer que le trafic public passe déjà par un CDN post-quantique vaut mieux qu’un silence complet sur le sujet.
Contenus liés
- Cryptographie post-quantique : Washington fixe 2030
- ANSSI : post-quantique obligatoire dès 2027
- RSA/ECC vs cryptographie post-quantique : ML-KEM 2,4x plus rapide
- SHA-256 vs SHA-3 : 1 772 vs 509 Mo/s
- Cryptographie post-quantique : ML-KEM en 12 étapes
- CADA : l’UE fixe 4 niveaux de souveraineté cloud
- Cryptographie et fonctions de hachage : le socle de la confiance numérique
Questions fréquentes
Qu’est-ce que X25519MLKEM768 ?
C’est un échange de clés hybride pour TLS 1.3 qui combine X25519, un algorithme classique sur courbe elliptique, avec ML-KEM-768, un mécanisme post-quantique standardisé par le NIST sous la référence FIPS 203 en août 2024. La session reste protégée tant que l’un des deux mécanismes n’est pas cassé.
Mon site est-il déjà protégé par la cryptographie post-quantique ?
Cela dépend de votre CDN ou fournisseur cloud, et du navigateur utilisé par vos visiteurs. Les sites servis par Cloudflare, Akamai Enhanced TLS ou AWS CloudFront peuvent déjà bénéficier de l’échange hybride si l’option est activée. Un test avec la commande OpenSSL détaillée plus haut permet de le vérifier directement.
Pourquoi migrer alors qu’aucun ordinateur quantique ne menace RSA ou l’ECC aujourd’hui ?
À cause du scénario « harvest now, decrypt later » : un adversaire peut enregistrer aujourd’hui du trafic chiffré pour le déchiffrer plus tard, une fois qu’un ordinateur quantique suffisamment puissant existera. Pour des données sensibles à durée de vie longue, la protection doit être en place avant que cette menace ne se matérialise, pas après.
L’échange hybride ralentit-il les connexions ?
L’impact reste marginal pour la majorité des connexions web, car les messages échangés sont seulement un peu plus volumineux que dans un échange classique. La différence peut devenir perceptible sur des réseaux à très faible bande passante ou à forte latence, comme certaines connexions satellites ou des objets connectés très contraints.
Les certificats SSL/TLS sont-ils aussi concernés par cette migration ?
Pas encore, dans la majorité des cas. Le déploiement d’Akamai et de Google Cloud porte sur l’échange de clés de la session, pas sur les signatures des certificats eux-mêmes, qui reposent aujourd’hui presque toujours sur RSA ou ECDSA classiques. La migration des certificats vers des signatures post-quantiques comme ML-DSA constitue un chantier distinct, encore largement à venir.
Que dit la réglementation européenne sur ce sujet ?
L’ANSSI prévoit de rendre la cryptographie post-quantique obligatoire dans ses référentiels de certification à partir de 2027, avec une bascule complète visée pour la fin de la décennie. D’autres cadres européens, dont le CADA sur la souveraineté cloud, ajoutent des exigences de conformité qui touchent indirectement les choix cryptographiques des fournisseurs opérant sur le marché européen.
Fastly et Microsoft Azure vont-ils suivre Akamai et Google Cloud ?
Aucune annonce publique équivalente n’a été documentée pour Fastly ou Azure Front Door à ce jour. Vu la dynamique concurrentielle observée depuis 2024, une annonce dans les prochains mois reste probable, mais elle n’a pas encore eu lieu.
Quel est le coût de cette migration pour une entreprise ?
Pour le trafic public passant par un CDN compatible, le coût est généralement nul ou marginal, l’activation se limitant à une option de configuration. Le coût réel se situe du côté des systèmes internes plus anciens, qui peuvent nécessiter une mise à niveau des bibliothèques TLS ou, dans certains cas, un remplacement de matériel réseau trop ancien pour supporter les nouveaux groupes cryptographiques.
