Le TLS post-quantique, c’est du HTTPS qui reste sécurisé même face à un attaquant disposant d’un grand ordinateur quantique. Il remplace les mathématiques qui sous-tendent l’échange de clés actuel — qu’un ordinateur quantique pourrait casser — par des algorithmes conçus pour résister aux attaques quantiques.
Ce n’est pas un projet de recherche lointain. À la mi-2026, plus de 65 % du trafic web humain transitant par Cloudflare est déjà chiffré de manière post-quantique, et Chrome, Edge et Firefox négocient par défaut un échange de clés résistant au quantique dès que le serveur le prend en charge. Si vous avez consulté Google récemment depuis un navigateur moderne, vous avez presque certainement utilisé du TLS post-quantique sans même le remarquer.
Pourquoi le TLS classique est menacé
Le TLS actuel repose sur deux types de mathématiques à clé publique :
- L’échange de clés (ECDHE, à l’aide de X25519 ou P-256) — permet de s’accorder sur un secret partagé via un canal ouvert.
- Les signatures (RSA, ECDSA) — prouvent l’authenticité du certificat.
Les deux dépendent de problèmes difficiles à résoudre pour les ordinateurs classiques — la factorisation de grands nombres (RSA) et le logarithme discret sur courbe elliptique (ECC). L’algorithme de Shor, exécuté sur un ordinateur quantique suffisamment puissant, résout les deux efficacement. Un « ordinateur quantique cryptographiquement pertinent » (CRQC) n’existe pas encore, mais le domaine progresse assez vite pour que la planification soit passée du « si » au « quand ».
Cryptographie à clé publique → explique les mathématiques sous-jacentes que les ordinateurs quantiques menacent.
« Moissonner maintenant, déchiffrer plus tard » — pourquoi c’est urgent dès aujourd’hui
Vous pourriez penser qu’il n’y a pas d’urgence : aucun ordinateur quantique ne peut casser le TLS aujourd’hui, alors pourquoi migrer maintenant ?
La menace, c’est le moissonner maintenant, déchiffrer plus tard (harvest now, decrypt later, ou HNDL). Un adversaire enregistre votre trafic chiffré aujourd’hui et le stocke. Lorsqu’un ordinateur quantique deviendra disponible — peut-être dans les années 2030 — il déchiffrera rétroactivement le trafic stocké.
Cela rend l’échéance pour l’échange de clés bien plus proche que l’arrivée des ordinateurs quantiques. Toute donnée ayant une longue durée de confidentialité — dossiers médicaux, données financières, secrets d’État, code source, identifiants — a besoin d’un chiffrement résistant au quantique dès maintenant, car l’enregistrement est déjà en cours.
L’échange de clés est urgent. Les signatures le sont moins. On ne peut pas falsifier rétroactivement une signature sur du trafic qui a déjà eu lieu — une signature doit seulement être résistante au quantique avant que les ordinateurs quantiques n’existent, pas avant. C’est pourquoi l’industrie a déployé en premier l’échange de clés post-quantique.
Les standards : ML-KEM et ML-DSA
En août 2024, le NIST a publié les premiers standards post-quantiques finalisés :
| Standard | Nom | Rôle | Remplace |
|---|---|---|---|
| FIPS 203 | ML-KEM (anciennement Kyber) | Encapsulation de clé (échange de clés) | Échange de clés ECDHE / RSA |
| FIPS 204 | ML-DSA (anciennement Dilithium) | Signatures numériques | Signatures RSA / ECDSA |
| FIPS 205 | SLH-DSA (SPHINCS+) | Signatures basées sur le hachage | Solution de repli conservatrice pour les signatures |
ML-KEM (Module-Lattice Key Encapsulation Mechanism) est celui qui est déjà déployé dans le TLS. Il existe en trois tailles : ML-KEM-512, ML-KEM-768 et ML-KEM-1024. ML-KEM-768 est le compromis idéal utilisé sur le web.
Échange de clés hybride : X25519MLKEM768
Les navigateurs n’abandonnent pas la cryptographie classique pour basculer du jour au lendemain vers du post-quantique pur. Ce serait imprudent — ML-KEM est récent, et une faille pourrait tout compromettre. À la place, TLS 1.3 utilise un échange de clés hybride qui combine un algorithme classique et un algorithme post-quantique.
Le groupe nommé que vous verrez en 2026 est X25519MLKEM768 :
X25519MLKEM768 = X25519 (ECDHE classique) + ML-KEM-768 (post-quantique)Les deux secrets partagés sont concaténés (32 bytes issus de X25519 + 32 bytes issus de ML-KEM = un secret combiné de 64 bytes) puis injectés dans le calendrier de clés (key schedule) du TLS.
La garantie de sécurité, c’est « sûr si l’un des deux tient ». Un attaquant doit casser à la fois X25519 et ML-KEM-768 pour récupérer la clé de session. Ainsi :
- Si ML-KEM-768 s’avère présenter une faille → X25519 continue de vous protéger (contre les attaquants classiques).
- Si un ordinateur quantique casse X25519 → ML-KEM-768 continue de vous protéger.
Cette approche « ceinture et bretelles » explique pourquoi l’hybride est la valeur par défaut partout, plutôt que le post-quantique pur.
Où cela s’insère dans le handshake
L’échange de clés hybride utilise le même handshake TLS 1.3 que celui décrit dans Qu’est-ce que TLS 1.3 →. La seule différence se situe au niveau du key_share : le ClientHello transporte une key share X25519MLKEM768 au lieu d’une simple X25519. Les clés ML-KEM sont plus volumineuses (~1,2 KB contre 32 bytes), de sorte que le ClientHello grossit d’environ un kilo-octet — généralement négligeable, même si cela peut occasionnellement déborder sur plusieurs paquets sur les réseaux contraints.
Cela vous offre également toujours le Forward Secrecy → : une nouvelle paire de clés par connexion, en version post-quantique.
Ce qui est déjà déployé en 2026
| Composant | État du post-quantique (mi-2026) |
|---|---|
| Chrome / Edge | X25519MLKEM768 négocié par défaut |
| Firefox | X25519MLKEM768 pris en charge et activé |
| Cloudflare | 65 %+ du trafic humain chiffré en PQ ; échange de clés terminé |
| Propose l’échange de clés post-quantique | |
| AWS | ML-KEM dans KMS, ACM, Secrets Manager ; abandon de l’ancien Kyber en 2026 |
| OpenSSL 3.5+ | Prise en charge native de ML-KEM et X25519MLKEM768 |
| Java (SunJSSE) | X25519MLKEM768 activé par défaut |
La pièce qui n’est pas encore en place à grande échelle, ce sont les certificats post-quantiques — signer les certificats avec ML-DSA au lieu de RSA/ECDSA. Les signatures et les clés publiques ML-DSA sont bien plus volumineuses (des kilo-octets contre ~64 bytes), ce qui alourdit le handshake et met sous tension les limites de taille des chaînes de certificats. Cloudflare prévoit ML-DSA sur les connexions d’origine d’ici la mi-2026 et explore les Merkle Tree Certificates pour maintenir une taille gérable, avec pour objectif un post-quantique complet (y compris l’authentification) d’ici 2029.
Comment vérifier si vous utilisez du TLS post-quantique
Dans le navigateur
Ouvrez n’importe quel site majeur dans Chrome → DevTools → onglet Security → consultez les détails de la connexion. Une connexion post-quantique affiche un échange de clés tel que X25519MLKEM768 (ou X25519Kyber768 sur les versions plus anciennes).
Avec OpenSSL 3.5+
openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 2>/dev/null | grep -i "Negotiated TLS1.3 group"
# Attendu : Negotiated TLS1.3 group: X25519MLKEM768Si vous obtenez une erreur ou un autre groupe, c’est soit que votre OpenSSL est antérieur à la 3.5, soit que le serveur ne propose pas encore d’échange de clés post-quantique.
Vérifiez votre version d’OpenSSL
openssl version
# Nécessite : OpenSSL 3.5+ pour le support natif de X25519MLKEM768Comment l’activer sur votre serveur
Pour la plupart des sites, la réponse est mettre à jour et ne pas le désactiver — l’échange de clés hybride post-quantique est activé automatiquement dès que votre stack le prend en charge.
Nginx / Apache
L’échange de clés post-quantique réside dans votre bibliothèque TLS, et non dans la configuration du serveur web. Compilez ou exécutez avec OpenSSL 3.5+ (ou BoringSSL avec ML-KEM). Une fois lié, X25519MLKEM768 est proposé automatiquement aux côtés de X25519 — aucune nouvelle directive n’est nécessaire. N’épinglez pas ssl_ecdh_curve à une seule courbe classique, sinon vous excluriez le groupe hybride.
Derrière un CDN
La voie la plus simple : placez votre site derrière Cloudflare (ou un autre CDN compatible PQC). La connexion entre le navigateur et le edge devient immédiatement post-quantique, sans aucune modification de votre origine. C’est ainsi que la majeure partie de ces 65 % de trafic est devenue résistante au quantique — les opérateurs n’ont pas touché du tout à leurs serveurs d’origine.
Votre certificat ne change pas encore
Vous n’avez pas besoin d’un nouveau certificat pour l’échange de clés post-quantique. Votre certificat RSA ou ECC existant fonctionne très bien — l’échange de clés hybride protège la session, tandis que le certificat continue d’utiliser des signatures classiques pour l’instant. Les certificats post-quantiques (ML-DSA) constituent une migration distincte et ultérieure.
Foire aux questions
Dois-je acheter un « certificat résistant au quantique » spécial ?
Non. L’échange de clés post-quantique (la partie urgente) ne touche pas du tout à votre certificat — votre certificat RSA/ECC actuel continue de fonctionner. Quiconque vend aujourd’hui un « certificat SSL résistant au quantique » fait essentiellement du marketing ; les signatures post-quantiques en production (ML-DSA) ne sont pas encore largement émises par les autorités de certification publiques.
Le TLS post-quantique est-il plus lent ?
À peine. ML-KEM-768 est rapide à calculer — souvent plus rapide qu’ECDHE. Le coût principal réside dans la taille : les key shares plus volumineuses ajoutent ~1 KB au handshake, ce qui ne peut coûter un aller-retour supplémentaire que sur les réseaux dont les limites de paquets sont très réduites. Pour la quasi-totalité des utilisateurs, la différence est imperceptible.
Quand les ordinateurs quantiques casseront-ils réellement RSA ?
Personne ne le sait. Les estimations crédibles vont du début des années 2030 à « peut-être jamais à grande échelle ». Mais à cause du moissonner-maintenant-déchiffrer-plus-tard, l’échéance de déploiement pour l’échange de clés est déjà là — ce qui explique précisément pourquoi les navigateurs et les CDN ont agi en 2024-2026 plutôt que d’attendre.
Et qu’en est-il de TLS 1.2 ?
L’échange de clés hybride post-quantique est défini uniquement pour TLS 1.3. C’est une raison de plus d’activer TLS 1.3 → — c’est la seule voie vers un HTTPS résistant au quantique. TLS 1.2 ne recevra pas d’échange de clés post-quantique.
ML-KEM est-il la même chose que Kyber ?
Oui — ML-KEM est la version standardisée par le NIST de l’algorithme auparavant appelé CRYSTALS-Kyber. Les anciennes versions de navigateurs et outils affichent Kyber768 ; les déploiements standardisés utilisent ML-KEM-768. Ils sont étroitement liés mais pas strictement identiques bit pour bit, de sorte qu’un client conforme au standard final et un serveur antérieur au standard peuvent échouer à négocier. D’ici 2026, l’écosystème a largement basculé vers le ML-KEM final.
Devrais-je faire quoi que ce soit dès maintenant ?
Pour un site web classique : assurez-vous d’être sur TLS 1.3, maintenez votre bibliothèque TLS à jour (OpenSSL 3.5+), et envisagez un CDN compatible PQC si vous traitez des données sensibles à longue durée de vie. C’est suffisant pour bénéficier dès aujourd’hui d’un échange de clés résistant au quantique. Les certificats post-quantiques peuvent attendre que les standards et l’outillage des autorités de certification arrivent à maturité.