Cryptographie post-quantique en production : ce qu'on active vraiment en 2026

Un attaquant n'a pas besoin d'un ordinateur quantique aujourd'hui pour vous viser aujourd'hui. Il lui suffit de capturer votre trafic chiffré maintenant et de le stocker. Le jour où une machine capable de casser RSA et les courbes elliptiques existe, il déchiffre le tout, rétroactivement. C'est le scénario « harvest now, decrypt later », et il transforme une menace théorique en problème opérationnel immédiat : tout secret qui doit rester confidentiel au-delà de 2030 est déjà exposé sur le câble si vous le transportez en crypto classique.

La bonne nouvelle, c'est que la partie défensive la plus simple est déjà déployable, gratuitement, sur des stacks que vous opérez probablement déjà. La mauvaise, c'est que le marketing « quantum-safe » mélange allègrement ce qui marche et ce qui n'existe pas encore. On trie.

NIST a publié les versions finales le 14 août 2024. Trois documents, trois usages, et des noms qui ont changé entre les drafts et la version finale (le piège des articles datés) :

• FIPS 203 : ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). C'est l'ancien CRYSTALS-Kyber. Sert à l'échange de clés. C'est lui qui compte pour TLS et SSH aujourd'hui.
• FIPS 204 : ML-DSA (Module-Lattice-Based Digital Signature Algorithm). L'ancien CRYSTALS-Dilithium. Signatures, donc certificats et authentification.
• FIPS 205 : SLH-DSA (Stateless Hash-Based Digital Signature Algorithm). Signatures basées sur des fonctions de hachage, hypothèse de sécurité différente, option de repli si jamais les réseaux euclidiens (lattices) tombaient.

Retenez la dissymétrie : le KEM (échange de clés) est mûr et déployé en volume, les signatures ne le sont pas encore. Toute la suite découle de là.

L'argument « pas d'ordinateur quantique cryptographiquement pertinent avant des années » est exact et hors sujet. La fenêtre d'exposition d'une donnée n'est pas le temps qu'il reste avant la machine, c'est la durée pendant laquelle cette donnée doit rester secrète, plus le temps de migrer toute votre flotte. Si un secret doit tenir dix ans et que votre migration crypto prend trois ans, vous êtes déjà en retard.

L'ANSSI ne dit pas autre chose. Dans son avis sur la migration et dans la déclaration conjointe du 30 novembre 2024 (ANSSI, BSI allemand et seize autres États membres), la recommandation est claire : hybrider dès maintenant pour tout produit destiné à protéger durablement de l'information, en particulier au-delà de 2030. Hybridation = on combine un algorithme pré-quantique éprouvé (X25519, ECDH) avec un algorithme post-quantique. Si l'un cède, l'autre tient. C'est une ceinture et des bretelles assumées, pas une frilosité.

Le key exchange hybride TLS, c'est concrètement le groupe X25519MLKEM768. Combinaison de X25519 (la courbe elliptique classique) et de ML-KEM-768 (niveau 2 de sécurité NIST). La clé de session dérive des deux : casser l'un ne suffit pas.

Ce n'est pas un POC de labo. Chrome l'a activé par défaut côté client, Firefox aussi, et les chiffres de mesure réseau de Cloudflare sont parlants : d'après le Radar Year in Review 2025, le trafic web humain protégé en post-quantique est passé de 29 % début 2025 à 52 % début décembre 2025. La moitié du web grand public chiffre déjà en post-quantique sur l'échange de clés. Le navigateur de votre utilisateur le demande déjà ; la question est de savoir si votre serveur sait répondre.

Côté serveur, le verrou a sauté avec OpenSSL 3.5, sortie en avril 2025 et estampillée LTS. C'est la première release stable à embarquer ML-KEM, ML-DSA et SLH-DSA en provider natif, sans patch ni fork OQS. nginx et HAProxy compilés contre OpenSSL 3.5 héritent de la capacité PQC sans rien changer d'autre à la toolchain.

Vérifier ce que votre binaire sait faire :

openssl version
# OpenSSL 3.5.x ou plus pour le support natif

openssl list -kem-algorithms | grep -i mlkem
# doit lister ML-KEM-512 / 768 / 1024

# Lister les groupes négociables, X25519MLKEM768 doit apparaître
openssl list -tls-groups | grep -i mlkem

Côté nginx, l'activation passe par la directive de groupes, en gardant les classiques en repli :

ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

Tester le handshake réel contre un serveur, et confirmer le groupe négocié :

openssl s_client -connect exemple.fr:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i -E 'negotiated|group'

Une chose à surveiller avant de pousser en prod : la taille du ClientHello. Le keyshare ML-KEM-768 fait gonfler le handshake bien au-delà des tailles classiques. Des connexions se font couper par des équipements intermédiaires ou des load balancers qui n'aiment pas le ClientHello fragmenté ou surdimensionné. HAProxy a eu un fil ouvert (issue #3148, octobre 2025) sur des connexions avortées en RST juste après le ClientHello quand le client préfère X25519MLKEM768 : classé en configuration plutôt qu'en bug, mais l'effet pour vous est identique, des coupures non déterministes. Donc on valide avec une vraie capture, pas juste un curl qui passe. Pour le reste du durcissement TLS (suites, OCSP, HSTS), nos bonnes pratiques TLS 2026 restent le socle ; la PQC s'ajoute par-dessus, elle ne remplace rien.

OpenSSH propose de l'échange de clés post-quantique par défaut depuis la version 9.0 (avril 2022), au départ via sntrup761x25519-sha512 (Streamlined NTRU Prime hybridé X25519). En 9.9, un second mécanisme aligné NIST est arrivé, mlkem768x25519-sha256, et il est devenu le défaut à partir d'OpenSSH 10.0 (avril 2025).

Traduction ops : si votre flotte est sur OpenSSH 10.x, vos sessions SSH sont déjà protégées contre le « harvest now, decrypt later » sans aucune action. Sur une version plus ancienne mais supérieure ou égale à 9.9, le mécanisme existe, il suffit de le mettre en tête de liste. En dessous de 9.0, vous n'avez aucune protection post-quantique, ce qui est en soi un argument de mise à jour.

Vérifier la version et les algorithmes supportés :

ssh -V
# OpenSSH_10.x souhaité

ssh -Q kex | grep -E 'mlkem|sntrup'
# mlkem768x25519-sha256 et/ou sntrup761x25519-sha512

Forcer explicitement le post-quantique dans sshd_config (et côté client dans ~/.ssh/config), avec repli ordonné :

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

Confirmer le KEX réellement négocié sur une connexion :

ssh -v utilisateur@serveur 2>&1 | grep -i 'kex: algorithm'

Attention à l'asymétrie client/serveur lors d'un déploiement progressif : un vieux client ne négociera pas le mécanisme post-quantique même contre un serveur 10.x. La protection n'existe que si les deux bouts savent le faire. Ça ne casse rien (le repli vers curve25519-sha256 joue), mais ça ne protège pas, et c'est silencieux. Si vous gérez l'authentification SSH par autorité de certification, voyez comment l'articuler avec une PKI SSH centralisée via OpenSSH CA : le KEX post-quantique protège le transport, la signature des certificats SSH reste, elle, en crypto classique pour l'instant.

Les signatures post-quantiques en production n'existent pas encore à l'échelle d'Internet. En 2025, une bonne partie du trafic est protégée par l'échange de clés post-quantique, mais pas un seul certificat post-quantique public n'est en usage. Un programme racine prépare un pilote pour accepter des certificats ML-DSA-87, possiblement fin 2025, et les premiers certificats sont attendus en 2026, mais leur disponibilité large et leur confiance par tous les navigateurs avant 2027 sont improbables.

Concrètement : vos certificats TLS restent signés en RSA ou ECDSA, et c'est normal. Migrer la signature aujourd'hui n'aurait pas de sens (tailles de signatures importantes, écosystème d'AC pas prêt, pas de confiance navigateur). La priorité défensive est l'échange de clés, parce que c'est lui qui est exposé au « capture aujourd'hui, déchiffre demain ». Une signature, elle, doit être valide au moment de la connexion ; on ne déchiffre pas rétroactivement une signature. La menace temporelle est donc bien moindre sur les signatures, ce qui justifie de prendre le temps.

Si un fournisseur vous propose aujourd'hui un certificat « quantum-safe » prêt à l'emploi pour le web public, demandez sur quelle chaîne de confiance il s'appuie. La réponse honnête, en 2026, c'est qu'il n'y en a pas encore pour le web public.

Le piège, c'est de traiter la PQC comme un interrupteur unique. Ce n'est pas ça. Le vrai livrable, c'est la capacité à changer d'algorithme cryptographique sans réarchitecturer, parce que les standards bougeront encore, et parce que demain on basculera les signatures comme on bascule l'échange de clés aujourd'hui.

Ce qu'on met en place, dans l'ordre :

1. Inventaire crypto. On ne migre pas ce qu'on ne connaît pas. Lister où vit la crypto : terminaisons TLS, tunnels VPN, SSH, secrets longue durée, PKI interne. Tant que cet inventaire n'existe pas, tout plan de migration est de la fiction.
2. Activer l'échange de clés hybride là où c'est gratuit et sans risque. SSH (mise à jour OpenSSH 10.x), terminaisons TLS sortantes et entrantes (OpenSSL 3.5). C'est le quick win réel, à effet immédiat sur le « harvest now, decrypt later ».
3. Rendre les choix d'algorithmes pilotables par configuration, pas codés en dur dans les binaires ou les images. La directive ssl_ecdh_curve, la ligne KexAlgorithms : centralisées, versionnées, auditables.
4. Surveiller les versions logicielles comme un risque crypto. Une stack figée sur OpenSSL 3.0 ou OpenSSH 8.x n'est pas seulement obsolète, elle est non éligible à la PQC. Le capacity planning des mises à jour devient un sujet sécurité.
5. Tester côté repli. L'hybridation impose que le repli classique fonctionne proprement quand un bout est trop vieux. Un repli mal géré, c'est soit une coupure, soit une fausse impression de protection.

La même logique s'applique aux autres terminaisons chiffrées que vous opérez. Un tunnel WireGuard repose aujourd'hui sur de la crypto classique côté handshake ; c'est un point d'inventaire à tracer, pas à bricoler dans l'urgence. Et si vous opérez une PKI interne avec step-ca, c'est l'endroit où la crypto-agilité se teste à moindre risque : vous contrôlez l'AC et les clients, donc vous pouvez expérimenter les signatures post-quantiques en circuit fermé bien avant que le web public ne suive.

Pour 2026, la position défendable tient en trois lignes. Activez l'échange de clés hybride partout où il est gratuit : SSH via OpenSSH 10.x, TLS via OpenSSL 3.5. Laissez les signatures et certificats en crypto classique, l'écosystème n'est pas prêt et la menace y est moindre. Construisez la crypto-agilité maintenant, parce que le vrai coût n'est pas dans l'algorithme, il est dans l'incapacité à en changer.

Ce qui distingue une migration sérieuse d'un autocollant « quantum-safe » sur la plaquette commerciale, c'est l'inventaire crypto et le test du repli. Le reste, c'est de la configuration. Si votre flotte SSH et vos terminaisons TLS n'ont pas été passées en revue sous cet angle, on peut auditer votre exposition crypto et activer le post-quantique là où c'est pertinent, sans casser le repli classique ni gonfler le ClientHello au point de couper vos clients.

• Federal Register : issuance of FIPS 203, 204 and 205 : acte officiel daté du 14 août 2024, source primaire pour les noms et statuts des trois standards.
• OpenSSH : Post-Quantum Cryptography : page officielle du projet, détaille les algorithmes et les versions (9.0, 9.9, défaut en 10.0).
• OpenSSL 3.5 final release : annonce officielle de la sortie du 8 avril 2025, confirme le statut LTS et le support PQC natif.
• Cloudflare Radar : 2025 Year in Review : mesures réseau réelles, paliers d'adoption du KEM hybride (29 % début 2025, 52 % début décembre 2025).
• Cloudflare : State of the post-quantum Internet in 2025 : état des signatures et certificats post-quantiques, encore absents du web public.
• ANSSI : cryptographie post-quantique (PQC) : position française officielle sur l'hybridation et le calendrier de migration.