Depuis février 2026, l’ANSSI a publié un guide très concret sur un sujet qui semblait encore théorique il y a deux ans : remplacer l’échange de clés RSA et ECDH par ML-KEM dans le handshake TLS 1.3. Ce n’est plus une hypothèse de laboratoire. Cloudflare affichait déjà 52 % de son trafic TLS 1.3 chiffré en post-quantique fin 2025, et ce chiffre continue de grimper en 2026. Chrome active l’algorithme par défaut depuis la version 131, Apple a suivi en septembre 2025, et OpenSSL 3.5 négocie désormais l’hybride sans configuration particulière. Pour les équipes techniques françaises et européennes, la question n’est plus de savoir si la bascule aura lieu, mais quand et comment l’organiser. Cet article compare ML-KEM (Kyber, normalisé sous FIPS 203) aux échanges de clés classiques RSA et ECDH : tailles de clés, benchmarks mesurés chez Google, Cloudflare et AWS, support logiciel réel, coûts de migration chiffrés et recommandations selon votre profil d’entreprise.
ML-KEM, le successeur désigné de RSA et ECDH dans TLS 1.3
ML-KEM signifie Module-Lattice-based Key-Encapsulation Mechanism. Le NIST l’a normalisé sous la référence FIPS 203, publiée le 13 août 2024, en même temps que ML-DSA (FIPS 204) pour les signatures et SLH-DSA (FIPS 205). Cet algorithme dérive directement de Kyber, le finaliste retenu par le concours post-quantique du NIST, et il vise un objectif précis : remplacer la brique d’échange de clés de TLS, pas le chiffrement symétrique. AES-256 et les fonctions de hachage comme SHA-3 restent solides face à un ordinateur quantique, à condition d’utiliser des tailles de clé suffisantes. Le problème se situe ailleurs : RSA et ECDH reposent sur la factorisation d’entiers et le logarithme discret, deux problèmes que l’algorithme de Shor casserait en un temps raisonnable sur un ordinateur quantique suffisamment puissant.
L’ANSSI structure la transition en trois phases dans sa position officielle mise à jour entre 2023 et 2026. La phase 1, en cours aujourd’hui, ajoute du post-quantique en défense en profondeur, de façon optionnelle. La phase 2, qui ne devait pas démarrer avant 2025, généralise les déploiements hybrides pour offrir une garantie post-quantique sans dégrader la sécurité pré-quantique existante. La phase 3, prévue au plus tôt en 2030, ouvrirait la voie à des schémas entièrement post-quantiques, sans composante classique. Cette prudence s’explique par un risque bien identifié : le harvest now, decrypt later. Un acteur malveillant peut enregistrer aujourd’hui du trafic chiffré avec RSA ou ECDH, puis le déchiffrer plus tard une fois qu’un ordinateur quantique suffisamment puissant existera. Pour les données à durée de vie longue (dossiers médicaux, secrets industriels, communications diplomatiques), ce scénario justifie une migration anticipée, même si la menace quantique concrète reste encore à plusieurs années.
Ce raisonnement change la nature même de la décision technique. Pour un algorithme de chiffrement classique, on migre généralement quand une faille est démontrée ou quand le matériel de calcul rend une attaque triviale. Pour la cryptographie post-quantique, la menace n’existe pas encore sous une forme opérationnelle, mais son délai de préparation dépasse largement le temps qu’il faudrait pour réagir une fois l’ordinateur quantique disponible. Migrer un parc de serveurs, former des équipes, tester la compatibilité client et auditer chaque dépendance logicielle prend des mois, parfois des années dans les grandes organisations. C’est cette asymétrie entre le temps de préparation et le temps de réaction qui pousse l’ANSSI, le NIST et la Commission européenne à pousser une adoption dès maintenant plutôt que d’attendre un signal d’alarme plus tardif.
RSA et ECDH classiques : comment fonctionne l’échange de clés aujourd’hui
TLS 1.3 a supprimé l’échange de clés RSA statique qui existait encore dans TLS 1.2. Depuis la RFC 8446, seul l’échange de clés Diffie-Hellman éphémère (ECDHE ou DHE) assure la confidentialité persistante des connexions. RSA garde un rôle, mais uniquement pour signer les certificats des autorités de certification, pas pour transporter la clé de session. Les courbes elliptiques dominent ce terrain depuis une dizaine d’années : X25519 (Curve25519) équipe la majorité des connexions HTTPS modernes, les courbes NIST P-256, P-384 et P-521 restent utilisées dans les environnements réglementés ou les bibliothèques plus anciennes.
Ces courbes ont un atout majeur : elles produisent des clés minuscules. X25519 échange une clé publique de 32 octets et génère un secret partagé de 32 octets, pour un total de 64 octets sur le fil (32 en ClientHello, 32 en ServerHello). P-256 monte à 64 octets de clé publique, P-384 à 96 octets, P-521 à 132 octets. RSA, à l’inverse, transporte des signatures qui pèsent 256 octets pour une clé de 2048 bits, 384 octets pour 3072 bits et 512 octets pour 4096 bits. Cette légèreté explique pourquoi ECDHE s’est imposé face à RSA dans le handshake TLS moderne, et pourquoi ML-KEM, avec ses clés nettement plus lourdes, doit justifier son surcoût par un gain de sécurité réel face au calcul quantique.
ML-KEM-512, 768, 1024 face à RSA et ECDH : tailles de clés et niveaux NIST
Le tableau ci-dessous rassemble les tailles exactes publiées dans FIPS 203 et les métadonnées de la bibliothèque liboqs, comparées aux standards RSA et ECDH utilisés en production. Les trois variantes de ML-KEM correspondent chacune à un niveau de sécurité NIST distinct, calé approximativement sur l’équivalent AES.
| Algorithme | Type | Niveau NIST | Clé publique | Clé privée | Ciphertext / signature | Secret partagé |
|---|---|---|---|---|---|---|
| ML-KEM-512 | KEM post-quantique | Niveau 1 (≈ AES-128) | 800 octets | 1 632 octets | 768 octets | 32 octets |
| ML-KEM-768 | KEM post-quantique | Niveau 3 (≈ AES-192) | 1 184 octets | 2 400 octets | 1 088 octets | 32 octets |
| ML-KEM-1024 | KEM post-quantique | Niveau 5 (≈ AES-256) | 1 568 octets | 3 168 octets | 1 568 octets | 32 octets |
| X25519 | ECDH classique | ≈ 128 bits | 32 octets | 32 octets | n/a | 32 octets |
| ECDH P-256 | ECDH classique | ≈ 128 bits | 64 octets | 32 octets | n/a | 32 octets |
| ECDH P-384 | ECDH classique | ≈ 192 bits | 96 octets | 48 octets | n/a | 48 octets |
| ECDH P-521 | ECDH classique | ≈ 256 bits | 132 octets | 66 octets | n/a | 66 octets |
| RSA-2048 | Signature / legacy | ≈ 112 bits | ~0,5 Ko (PEM) | ~1,7 Ko (PEM) | 256 octets | n/a |
| RSA-3072 | Signature / legacy | ≈ 128 bits | ~0,6 Ko (PEM) | ~2,5 Ko (PEM) | 384 octets | n/a |
| RSA-4096 | Signature / legacy | ≈ 140 bits | ~0,8 Ko (PEM) | ~3,2 Ko (PEM) | 512 octets | n/a |
| X25519MLKEM768 (hybride) | ECDH + KEM | Niveau 3 combiné | 1 216 octets (client) | n/a | 1 120 octets (serveur) | 64 octets |
| SecP384r1MLKEM1024 (hybride) | ECDH + KEM | Niveau 5 combiné | ~1 664 octets | n/a | ~1 664 octets | 80 octets |
Deux constats ressortent de ce tableau. D’abord, ML-KEM produit des clés bien plus volumineuses que les courbes elliptiques : ML-KEM-768 pèse 37 fois plus lourd que X25519 côté client (1 184 octets contre 32). Ensuite, à niveau de sécurité comparable, ML-KEM reste plus léger que RSA à haute robustesse : la clé publique RSA-4096 en PEM (environ 800 octets) et sa clé privée de 3,2 Ko dépassent largement les besoins d’un ML-KEM-1024, qui vise pourtant un niveau de sécurité équivalent à AES-256. Le vrai concurrent de ML-KEM n’est donc pas X25519, dont la légèreté restera longtemps inégalée, mais RSA à forte robustesse.
Le mode hybride X25519MLKEM768, le compromis choisi par l’industrie
Aucun grand acteur ne déploie ML-KEM seul en production aujourd’hui. Tous combinent un algorithme classique (le plus souvent X25519) avec ML-KEM-768, dans un mode dit hybride. Le principe est simple : le client concatène sa clé X25519 (32 octets) et sa clé publique ML-KEM-768 (1 184 octets) pour former un ClientHello de 1 216 octets. Le serveur répond avec sa clé X25519 (32 octets) et le ciphertext ML-KEM (1 088 octets), soit 1 120 octets. Les deux secrets partagés de 32 octets sont ensuite concaténés pour produire un secret final de 64 octets. Ce montage garantit une propriété précieuse : si une faille venait à briser ML-KEM demain, la sécurité de la connexion resterait garantie par X25519, et inversement pour une éventuelle attaque quantique sur les courbes elliptiques.
La normalisation de ce mode hybride a suivi un chemin progressif. Google a d’abord déployé un point de code provisoire, Kyber768+X25519, identifié 0x6399, avant de migrer vers le point de code standardisé ML-KEM768+X25519, identifié 0x11EC, une fois FIPS 203 finalisé. Le blog sécurité de Chrome a confirmé ce changement en précisant que le navigateur ne supporterait pas les deux versions simultanément, forçant une transition nette plutôt qu’une coexistence prolongée. Cette bascule technique, invisible pour l’utilisateur final, illustre la difficulté de l’exercice : chaque acteur doit synchroniser son calendrier avec celui des autres pour éviter des ruptures d’interopérabilité en pleine transition post-quantique.
Benchmarks réels : ce que mesurent Google, Cloudflare et AWS
Trois acteurs majeurs publient des chiffres de performance indépendants, et leurs résultats convergent vers une même conclusion : le surcoût de ML-KEM existe, mais il reste marginal comparé au reste du handshake TLS.
| Source | Configuration testée | Métrique mesurée | Résultat |
|---|---|---|---|
| Google (benchmark interne) | X25519 seul | Cycles CPU client / serveur | 121 000 / 121 000 |
| Google (benchmark interne) | X25519MLKEM768 hybride | Cycles CPU client / serveur | 285 000 / 348 000 (2,35x à 2,88x) |
| Google (télémétrie Chrome desktop) | ClientHello scindé en 2 paquets | Latence médiane du handshake | +4 % en médiane |
| Cloudflare (edge) | Kyber768 autonome | Opérations par seconde | 31 000 (client) / 70 000 (serveur) |
| Cloudflare (edge) | X25519Kyber768Draft00 hybride | Opérations par seconde côté client | 11 000, “plus lent que X25519 mais pas de beaucoup” |
| Cloudflare (automatic key exchange) | Sélection de groupe optimisée | HelloRetryRequests | De 52 % à 3,7 % des connexions, -150 ms au P90 |
| AWS (guide de tuning 2022) | Kyber + ECDHE hybride | Temps de calcul additionnel | 0,25 ms client / 0,23 ms serveur, +2 356 octets |
| AWS (blog ML-KEM, avril 2025) | Hybride ML-KEM sans réutilisation TLS | Débit transactionnel (TPS) | De 108,7 à 106,2 TPS (-2,3 %) |
| AWS (blog ML-KEM, avril 2025) | Hybride ML-KEM avec réutilisation TLS | Débit transactionnel (TPS) | De 216,1 à 216,0 TPS (-0,05 %) |
| Étude académique 2026 (arXiv) | X25519 vs hybride ML-KEM-512/768 | Latence médiane du handshake | 5,547 ms / 5,879 ms / 6,495 ms |
Le détail le plus utile pour un ingénieur en production tient dans les deux dernières lignes AWS. Sans réutilisation de connexion TLS, chaque handshake complet coûte cher (2,3 % de débit en moins), mais dès que la connexion se réutilise, comme c’est le cas dans l’immense majorité des architectures web modernes avec keep-alive ou HTTP/2, l’écart tombe à 0,05 %, un niveau que les ingénieurs d’AWS qualifient eux-mêmes de négligeable. L’étude académique 2026 confirme ce constat au niveau du protocole : les écarts observés entre configurations classiques et hybrides restent dans une fourchette de 0,3 à 0,9 milliseconde, jugée sans effet pratique significatif. Cloudflare ajoute une nuance importante : le vrai facteur de ralentissement du TLS post-quantique ne vient pas de ML-KEM lui-même, mais des signatures post-quantiques (ML-DSA) beaucoup plus volumineuses, qui peuvent faire franchir un seuil de taille de paquet et déclencher un aller-retour réseau supplémentaire.
Une étude présentée lors d’une conférence PQC du NIST affine encore ce constat en distinguant le coût du handshake du coût de la connexion complète. Sur des liaisons à faible bande passante, ML-KEM combiné à ML-DSA peut allonger le temps du handshake de 32 %, un chiffre qui paraît élevé isolément. Mais dès que l’on regarde le temps total jusqu’au dernier octet reçu (time-to-last-byte) pour un transfert de données réel, cet écart tombe sous 15 % à partir de 50 Kio échangés, et sous 10 % quand le volume de données augmente encore. Autrement dit, plus une connexion transporte de contenu utile, moins le surcoût du handshake post-quantique pèse dans la latence perçue par l’utilisateur final. Ce facteur explique pourquoi les grands sites à fort trafic constatent un impact quasi imperceptible, alors que des connexions très courtes et répétées (API à faible payload, requêtes DNS-over-HTTPS) ressentent l’effet de manière plus marquée.
Qui supporte déjà l’hybride post-quantique en 2026
Le support logiciel a basculé très vite entre fin 2024 et fin 2025. Voici l’état des lieux par catégorie d’acteur.
| Composant | Support hybride PQC | Depuis quand | Détail |
|---|---|---|---|
| Google Chrome (desktop) | Activé par défaut | Chrome 131, octobre 2024 | X25519MLKEM768, point de code 0x11EC |
| Google Chrome (Android) | Activé par défaut | Chrome 133 | Même groupe hybride que desktop |
| Mozilla Firefox | Activé par défaut | 2025 | Vérifiable via l’extension de contrôle Cloudflare Radar |
| Apple Safari / iOS / macOS | Activé par défaut | Mise à jour OS, septembre 2025 | Négociation automatique de l’échange de clés hybride |
| Cloudflare (edge global) | Activé par défaut sur tous les sites TLS 1.3 | Octobre 2022 | D’abord Kyber, puis migration vers ML-KEM |
| AWS KMS / ACM / Secrets Manager | Disponible sur les endpoints non-FIPS | 2022 (Kyber), 2025 (ML-KEM) | Toutes les régions AWS |
| OpenSSL 3.5 | Groupe hybride dans la liste par défaut | Version 3.5 | X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 |
| BoringSSL (Google) | Implémenté | 2024 | Base technique du support Chrome |
| wolfSSL | Implémenté, activable via build flag | 2024-2025 | Option –enable-kyber, hybride avec courbes NIST |
| AWS s2n-tls | Implémenté via AWS-LC | 2024-2025 | TLS 1.3 open source utilisé en interne chez AWS |
Ce tableau révèle un déséquilibre structurel : côté client (navigateurs) et côté grands CDN, l’hybride post-quantique est déjà la norme. Côté serveurs d’origine gérés directement par les entreprises, en dehors des grands hébergeurs, l’adoption reste beaucoup plus lente. C’est précisément ce décalage qui doit guider la priorité des équipes techniques en 2026 : le trafic entrant est déjà prêt à négocier du post-quantique, mais l’infrastructure côté serveur ne le propose pas encore systématiquement.
Cinq déploiements réels qui prouvent que la bascule est déjà amorcée
Au-delà des chiffres de laboratoire, plusieurs déploiements en production illustrent que le débat sur ML-KEM a dépassé le stade théorique depuis longtemps.
- Cloudflare, octobre 2022 : premier grand réseau à activer l’hybride post-quantique par défaut sur l’ensemble de ses sites et API en TLS 1.3, sans action requise de la part des clients. Cette décision précoce, avant même la finalisation de FIPS 203, a servi de test grandeur nature pour l’ensemble de l’industrie.
- AWS KMS, ACM et Secrets Manager, 2022 puis 2025 : AWS a d’abord déployé Kyber en 2022, avant de migrer vers ML-KEM standardisé en 2025 sur ses endpoints non-FIPS dans toutes ses régions. L’entreprise indique avoir traité des milliards de connexions TLS post-quantiques dès la première phase, preuve que le passage à l’échelle industrielle fonctionne sans incident majeur.
- Google Chrome 131, octobre 2024 : bascule du support expérimental vers une activation par défaut sur desktop, suivie par Android avec Chrome 133. Ce calendrier serré a forcé l’écosystème serveur à suivre le rythme du plus grand navigateur du marché.
- Apple, septembre 2025 : mise à jour des systèmes iOS et macOS ajoutant la négociation automatique de l’échange de clés hybride, un facteur cité par Cloudflare comme accélérateur direct de la hausse du trafic post-quantique observée fin 2025.
- OpenSSL 3.5 : première version de la bibliothèque TLS la plus utilisée au monde à inclure X25519MLKEM768 dans sa liste de groupes par défaut, ce qui signifie qu’un serveur fraîchement installé négocie déjà l’hybride sans configuration manuelle dès lors que le client le supporte.
Ce qui frappe dans ces cinq exemples, c’est la vitesse d’exécution. Entre la finalisation de FIPS 203 en août 2024 et une activation par défaut chez Chrome, Apple et OpenSSL, il ne s’est écoulé qu’entre un et treize mois. Peu de transitions cryptographiques majeures dans l’histoire de TLS ont progressé aussi vite, ce qui tend à confirmer que l’industrie considère la menace quantique comme suffisamment crédible pour justifier une réaction rapide plutôt qu’une adoption étalée sur une décennie.
Adoption mondiale : où en est le trafic TLS post-quantique en 2026
Les chiffres de Cloudflare Radar dessinent une courbe d’adoption impressionnante sur deux ans. Début 2024, moins de 3 % du trafic client supportait le post-quantique côté Cloudflare. En mars 2025, plus de 35 % du trafic HTTPS non automatisé (hors bots) était déjà sécurisé en post-quantique, selon le blog Cloudflare consacré à l’état de l’Internet post-quantique. Le rapport annuel Radar 2025 de Cloudflare va plus loin : la part du trafic humain chiffré en post-quantique est passée de 29 % en début d’année à 52 % début décembre 2025, un quasi-doublement en douze mois. Certaines analyses situent même le point de bascule majoritaire dès octobre 2025, quand la mise à jour des systèmes Apple a fait grimper mécaniquement la part de trafic mobile compatible.
Sur la partie 2026, Cloudflare rapporte un support client dépassant 60 % dès février, en partant de moins de 3 % au début de 2024. Une étude universitaire portant sur un large panel de domaines mesure une adoption par défaut passée de 31,26 % en juillet 2025 à 49,22 % en mars 2026, avec X25519MLKEM768 comme configuration hybride dominante. Le vrai point de friction reste du côté des serveurs d’origine : Cloudflare estime qu’environ 10 à 14 % seulement des origines qu’elle scanne proposent une négociation de clé préférant le post-quantique, contre moins de 1 % début 2025. Autrement dit, la demande explose côté client, mais l’offre côté infrastructure serveur reste très en retard, ce qui crée une fenêtre d’opportunité concrète pour les entreprises qui migrent tôt.
Combien coûte la migration vers ML-KEM en pratique
Contrairement à une idée reçue, le coût de la migration post-quantique ne vient presque jamais du calcul cryptographique lui-même. Il vient de l’inventaire des systèmes, des tests de compatibilité client et de la gestion des certificats. Une étude de consultance européenne publiée en 2026 propose une grille de coûts par type de projet, résumée dans le tableau ci-dessous.
| Profil | Effort estimé | Durée | Budget indicatif |
|---|---|---|---|
| Site vitrine / WordPress derrière un CDN | Vérification TLS, activation de l’hybride, monitoring | 0,5 à 2 jours | 300 à 1 200 € |
| PME e-commerce | Audit TLS, tests panier et paiement, config CDN/hébergeur | 2 à 5 jours | 1 000 à 3 500 € |
| Application SaaS avec API | Cartographie domaines/API, compatibilité clients, load balancer | 1 à 3 semaines | 4 000 à 12 000 € |
| Grande entreprise réglementée | Plan de transition, mise à jour des politiques, tests de conformité | 1 à 2 mois | À partir de 10 000 € |
Cette structure de coût colle avec les recommandations qu’AWS adresse à ses clients responsables de la sécurité : plutôt que de tenter d’inventorier manuellement chaque clé cryptographique de l’organisation, mieux vaut classer les dépendances selon trois catégories. Les composants que le fournisseur cloud mettra lui-même à jour sans action de votre part, ceux qu’il faudra remplacer explicitement, et ceux qui appartiennent en propre au client et nécessitent un plan dédié. AWS recommande aussi de mettre en place des tableaux de bord qui suivent l’usage des algorithmes, afin de distinguer en continu le trafic déjà post-quantique du trafic encore classique sur chaque endpoint.
5 cas d’usage concrets : quand choisir ML-KEM, l’hybride ou le classique
Toutes les organisations n’ont pas le même niveau d’urgence face à cette transition. La sensibilité des données traitées, la durée pendant laquelle elles doivent rester confidentielles et le niveau de contrôle qu’une équipe technique exerce sur son infrastructure déterminent largement le rythme de migration à adopter. Voici cinq profils fréquents et la stratégie qui leur correspond le mieux en 2026.
- Site vitrine ou blog derrière Cloudflare ou CloudFront : ne rien faire de spécial. L’hybride post-quantique est déjà actif par défaut sur ces réseaux depuis octobre 2022 pour Cloudflare, l’essentiel du travail consiste à vérifier la configuration plutôt qu’à la construire.
- PME e-commerce avec passerelle de paiement : migrer le reverse-proxy vers OpenSSL 3.5 ou une version de Nginx qui l’embarque, puis tester le tunnel de paiement avec les anciens terminaux de point de vente, qui négocient parfois encore uniquement RSA ou P-256.
- SaaS avec API exposée à des clients tiers : garder un fallback classique (X25519 seul) pour les clients qui ne supportent pas encore l’hybride, tout en publiant l’hybride en priorité pour les nouveaux intégrateurs.
- Secteur réglementé à données longue durée de vie (santé, défense, finance) : viser directement le niveau 5 NIST avec ML-KEM-1024 en hybride, en cohérence avec la recommandation de l’ANSSI de privilégier le plus haut niveau de sécurité disponible pour les données sensibles à protéger sur le long terme.
- Objets connectés et environnements à bande passante contrainte : évaluer d’abord l’impact des clés plus lourdes de ML-KEM-512 sur le budget réseau avant de migrer, certains déploiements IoT à très faible débit peuvent justifier un maintien temporaire de X25519 seul en attendant du matériel plus adapté.
- Éditeurs de bibliothèques cryptographiques ou de frameworks internes : adopter liboqs ou OpenSSL 3.5 dès maintenant plutôt que d’attendre, la maintenance d’un fork maison de crypto post-quantique coûte largement plus cher qu’une mise à jour de dépendance standard.
Guide de migration : passer de RSA/ECDH à l’hybride ML-KEM en pratique
Voici une trame de migration réaliste pour une équipe infrastructure qui gère ses propres serveurs TLS plutôt que de dépendre entièrement d’un CDN managé.
- Faire l’inventaire des points de terminaison TLS exposés (sites web, API, VPN, passerelles internes).
- Vérifier la version des bibliothèques TLS en place : OpenSSL 3.5 ou supérieur, BoringSSL récent, ou wolfSSL avec le flag –enable-kyber activé.
- Mettre à jour les paquets système si nécessaire, en testant d’abord sur un environnement de pré-production isolé.
- Activer explicitement les groupes hybrides côté serveur, sans désactiver les groupes classiques, pour garder la compatibilité avec les anciens clients.
- Tester la négociation avec la commande OpenSSL ci-dessous, qui force le client à proposer le groupe hybride.
- Surveiller la taille moyenne des paquets TLS et le taux de HelloRetryRequest après activation, pour détecter un éventuel dépassement de MTU réseau.
- Vérifier la compatibilité des équipements réseau intermédiaires (WAF, load balancers, appliances d’inspection TLS) qui peuvent bloquer des ClientHello plus volumineux.
- Documenter les clients ou partenaires qui échouent encore la négociation hybride, et prévoir un plan de sortie du fallback classique.
- Répéter l’opération sur les certificats et signatures (ML-DSA) dans un second temps, une fois l’échange de clés stabilisé.
- Réévaluer le calendrier tous les six mois en suivant les publications ANSSI et les statistiques Cloudflare Radar.
# Tester si un serveur négocie l'échange hybride post-quantique
openssl s_client -connect exemple.fr:443 -groups X25519MLKEM768 -tls1_3
# Extrait de configuration Nginx pour activer l'hybride en priorité
# tout en conservant un fallback classique pour les anciens clients
ssl_protocols TLSv1.3;
ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;La commande OpenSSL renvoie le groupe négocié dans sa sortie de diagnostic (New, TLSv1.3, Cipher). Si le serveur ne supporte pas encore l’hybride, la négociation retombe automatiquement sur un groupe classique déclaré dans la liste, ce qui permet de tester en production sans casser les connexions existantes. Le paramètre ssl_conf_command Groups fonctionne avec Nginx compilé contre OpenSSL 3.5 ou supérieur, et l’ordre de la liste détermine la priorité de négociation.
Deux pièges reviennent le plus souvent lors de ces migrations. Le premier concerne les équilibreurs de charge en amont d’une flotte de serveurs applicatifs : si le TLS se termine sur un load balancer plus ancien qui ne connaît pas encore les groupes hybrides, activer ML-KEM sur les serveurs applicatifs ne change rien tant que le composant de terminaison TLS n’est pas lui-même mis à jour. Le second piège touche les proxies d’inspection SSL utilisés dans certains réseaux d’entreprise pour filtrer le trafic sortant : ces boîtiers, souvent basés sur des bibliothèques TLS plus anciennes, peuvent tout simplement rejeter un ClientHello dont la taille dépasse leurs hypothèses de conception initiales. Un test en environnement contrôlé, avant tout déploiement sur le trafic de production, permet de repérer ces deux cas de figure avant qu’ils ne causent des incidents visibles pour les utilisateurs finaux.
Avantages et inconvénients : ML-KEM hybride face à RSA/ECDH classique
ML-KEM hybride (X25519MLKEM768 et équivalents)
- Résiste à une attaque par ordinateur quantique exploitant l’algorithme de Shor, contrairement à RSA et ECDH seuls.
- Ne dégrade pas la sécurité pré-quantique existante grâce au montage hybride avec X25519.
- Déjà supporté par défaut chez Chrome, Firefox, Safari, Cloudflare et AWS, sans configuration côté utilisateur final.
- Impact de latence mesuré comme négligeable dès que les connexions TLS sont réutilisées (0,05 % de perte de débit chez AWS).
- Clés bien plus légères que RSA à haute robustesse (RSA-4096) pour un niveau de sécurité comparable ou supérieur.
- Clés 37 fois plus lourdes que X25519 seul, ce qui peut faire dépasser certains seuils de MTU réseau.
- Peut déclencher un HelloRetryRequest supplémentaire sur des réseaux mal configurés, avec un coût de latence bien plus visible que le calcul lui-même.
- Support encore incomplet côté serveurs d’origine, en dehors des grands CDN et hébergeurs cloud.
- Certains équipements réseau intermédiaires plus anciens (WAF, appliances d’inspection TLS) peuvent mal gérer des ClientHello plus volumineux.
RSA et ECDH classiques
- Écosystème mature, compatible avec la quasi-totalité du parc logiciel existant, y compris les équipements anciens.
- Clés minimales (32 octets pour X25519), donc handshake le plus rapide possible et empreinte réseau la plus faible.
- Aucune migration nécessaire à court terme pour les usages sans exigence réglementaire de résistance quantique.
- Vulnérable en théorie à un futur ordinateur quantique exploitant l’algorithme de Shor sur la factorisation ou le logarithme discret.
- Expose au risque de harvest now, decrypt later pour toute donnée chiffrée aujourd’hui et destinée à rester confidentielle plusieurs années.
- Ne répond pas aux exigences de certification post-quantique que l’ANSSI prévoit de renforcer d’ici 2027-2030.
Le verdict : quelle stratégie adopter selon votre profil
Les chiffres penchent nettement en faveur de l’hybride ML-KEM pour toute organisation qui gère ses propres serveurs TLS en 2026. Le coût réel se mesure en dixièmes de milliseconde une fois la réutilisation de connexion activée, très loin des craintes initiales de ralentissement massif. Le vrai risque ne réside pas dans la performance, mais dans l’inaction face à une adoption client qui dépasse déjà 60 % selon Cloudflare, pendant que l’offre côté serveur reste sous les 15 %. Pour un site vitrine ou une boutique en ligne hébergée derrière un CDN majeur, la migration est déjà faite, il suffit de vérifier la configuration. Pour un SaaS ou une API propriétaire, la fenêtre de test raisonnable se situe entre une et trois semaines de travail, avec un budget de quelques milliers d’euros. Pour un acteur réglementé manipulant des données sensibles à longue durée de vie, l’argument du harvest now, decrypt later suffit à justifier une migration vers ML-KEM-1024 hybride dès maintenant, sans attendre l’échéance ANSSI de 2027. Rester en RSA/ECDH pur reste défendable uniquement pour des systèmes internes isolés, sans exposition réseau, et sans données destinées à rester confidentielles au-delà de la prochaine décennie.
ANSSI, ENISA et le calendrier réglementaire européen
La feuille de route de l’ANSSI reste la référence la plus citée en France pour cadrer ce calendrier. Elle recommande explicitement de viser le plus haut niveau de sécurité NIST disponible, le niveau 5 équivalent AES-256, ou à défaut le niveau 3, pour tout déploiement post-quantique dans des protocoles comme TLS 1.3. La Commission européenne relaie cette approche sur sa page consacrée à la cryptographie post-quantique, en citant les ressources nationales des États membres, dont celles de l’ANSSI, et en encourageant une migration coordonnée des services critiques vers des versions compatibles PQC de TLS 1.3, IPsec et SSH. Cette coordination européenne compte, car une transition fragmentée pays par pays créerait des zones d’incompatibilité inutiles entre administrations et entreprises partenaires au sein du marché unique.
Un point mérite d’être clarifié pour éviter toute confusion : la cryptographie post-quantique ne concerne aujourd’hui presque exclusivement que l’échange de clés, pas encore l’authentification par certificat. Les certificats serveurs restent très majoritairement signés en RSA ou ECDSA classiques en 2026, la migration des signatures suit son propre calendrier, plus lent, avec ML-DSA et SLH-DSA. Les entreprises qui préparent leur transition ont donc intérêt à traiter ces deux chantiers séparément : d’abord sécuriser l’échange de clés avec l’hybride ML-KEM, largement mûr et déjà déployé à grande échelle, puis anticiper la migration des signatures dans un second temps, une fois que l’écosystème de certificats post-quantiques aura atteint un niveau de maturité comparable.
Questions fréquentes
Qu’est-ce que ML-KEM et pourquoi remplace-t-il RSA et ECDH ?
ML-KEM est un mécanisme d’encapsulation de clé normalisé par le NIST sous FIPS 203 en août 2024. Il remplace la brique d’échange de clés de TLS pour résister à une future attaque par ordinateur quantique, qui casserait RSA et ECDH via l’algorithme de Shor.
Le chiffrement AES est-il aussi menacé par l’ordinateur quantique ?
Non, pas de la même façon. AES-256 et les fonctions de hachage comme SHA-3 restent robustes face à un ordinateur quantique tant que la taille de clé reste suffisante. Seuls les algorithmes à clé publique comme RSA et ECDH sont directement cassés par l’algorithme de Shor.
Quelle est la différence entre Kyber et ML-KEM ?
ML-KEM est la version standardisée par le NIST de l’algorithme Kyber. Les noms de paramètres et certains détails d’implémentation ont légèrement changé lors de la finalisation de FIPS 203, ce qui a obligé les navigateurs comme Chrome à migrer leur point de code de Kyber768+X25519 vers ML-KEM768+X25519.
Le passage à ML-KEM ralentit-il vraiment un site web ?
L’impact mesuré reste très faible en usage réel. AWS rapporte une baisse de débit de seulement 0,05 % lorsque les connexions TLS sont réutilisées, contre 2,3 % dans le pire cas sans réutilisation. Google observe une hausse de latence médiane de 4 % sur Chrome desktop, liée au découpage en paquets plus qu’au calcul cryptographique lui-même.
Faut-il changer ses certificats TLS pour passer au post-quantique ?
Pas dans l’immédiat. La migration post-quantique actuelle porte sur l’échange de clés, pas sur les certificats. Les certificats RSA ou ECDSA existants continuent de fonctionner normalement avec un échange de clés hybride ML-KEM.
Quels navigateurs supportent déjà ML-KEM en 2026 ?
Chrome l’active par défaut depuis la version 131 sur desktop et la version 133 sur Android. Firefox l’a activé par défaut en 2025. Apple a suivi avec une mise à jour de ses systèmes d’exploitation en septembre 2025.
Quand la cryptographie post-quantique sera-t-elle obligatoire en France ?
L’ANSSI structure sa feuille de route en trois phases, avec une généralisation de l’hybride pas avant 2025 et un passage envisageable vers du post-quantique pur pas avant 2030. Les entreprises réglementées ont intérêt à anticiper ce calendrier plutôt que d’attendre une obligation formelle.
Combien coûte une migration vers TLS post-quantique pour une PME ?
Pour une PME e-commerce classique, une estimation de consultance européenne 2026 chiffre l’effort entre 2 et 5 jours de travail, pour un budget compris entre 1 000 et 3 500 euros, incluant l’audit TLS et les tests de bout en bout sur le tunnel de paiement.
