Migration post-quantique en 2026 : plan pour développeurs

En bref. En 2026, une grande partie du travail post-quantique sur le chiffrement en transit se règle par des mises à jour. Chrome, Firefox, les versions 26 d’Apple, OpenSSL 3.5, Go 1.24+, JDK 27 et OpenSSH 10 négocient par défaut un échange de clés hybride ML-KEM. À vous de trouver les connexions qui ne le font pas encore : anciennes bibliothèques, listes de groupes fixées dans la configuration, équipements intermédiaires (middleboxes), TLS 1.2, VPN, services internes. Les signatures et les certificats sont la partie lente. Les AC publiques ne peuvent pas encore émettre de certificats ML-DSA pour les navigateurs : faites donc l’inventaire dès maintenant, lancez un pilote ML-DSA dans votre PKI privée et prévoyez l’agilité des algorithmes dès la conception. Les dates qui servent de référence sont celles du projet IR 8547 du NIST : les clés de 112 bits de sécurité comme RSA-2048 sont déconseillées après 2030, et tous les algorithmes à clé publique vulnérables au quantique sont interdits après 2035. La CNSA 2.0 de la NSA fixe des dates plus précoces pour les systèmes de sécurité nationale des États-Unis.

Deux problèmes, deux calendriers

Un ordinateur quantique cryptographiquement pertinent casserait RSA, Diffie-Hellman sur corps finis et la cryptographie sur courbes elliptiques (ECDH, ECDSA, EdDSA) grâce à l’algorithme de Shor. La cryptographie symétrique et les fonctions de hachage tiennent avec les tailles de clé actuelles, AES-256 et SHA-256 ou plus. Personne ne peut vous dire quand une telle machine existera. La page du projet OpenSSH résume ainsi les estimations publiées : « de 5 à 20 ans, de nombreux observateurs s’attendant à leur arrivée vers le milieu des années 2030 ». La migration se divise en deux problèmes d’une urgence très différente :

• La confidentialité, qui est urgente. Le trafic chiffré enregistré aujourd’hui pourra être déchiffré dès que l’ordinateur quantique existera. C’est le scénario récolter maintenant, déchiffrer plus tard. Tout ce qui doit rester secret plus de quelques années est déjà exposé si son échange de clés est classique. Le remède est l’échange de clés post-quantique, et il est déployable dès aujourd’hui.
• L’authentification, qui a une échéance. Une signature falsifiée ne pose problème qu’au moment où quelqu’un s’y fie : l’ordinateur quantique doit donc exister à ce moment-là. Mais les clés de signature et les ancres de confiance vivent longtemps. Les certificats racines, les clés de micrologiciel, les clés de signature de code et les documents signés archivés restent jugés fiables pendant des décennies, et leur remplacement prend des années.

Planifiez le travail dans cet ordre : d’abord l’échange de clés, ensuite les signatures.

Les échéances qui existent réellement

Trois points à retenir sur ce tableau :

1. IR 8547 n’est encore qu’un projet. Les agences et les fournisseurs planifient en fonction des dates de 2030 et 2035, mais celles-ci ne sont pas encore une politique définitive du NIST. Dans le projet, « déconseillé » (deprecated) signifie que vous pouvez encore utiliser l’algorithme si vous en acceptez le risque, et « interdit » (disallowed) que vous ne pouvez plus l’utiliser du tout.
2. L’étape de 2030 frappe les clés de 112 bits, avant tout RSA-2048. RSA-2048 figure encore sur de nombreux certificats et dans de nombreux signataires de jetons (deux des six points de terminaison du scan ci-dessous l’utilisent). P-256 et RSA-3072 offrent 128 bits de sécurité et restent utilisables jusqu’en 2035, mais migrer vers eux ne fait gagner que cinq ans au plus, car le projet interdit tout ce qui est vulnérable au quantique après 2035.
3. La note de bas de page de la CNSA 2.0 compte pour les hybrides. Les modes hybrides sont autorisés, mais les algorithmes CNSA 2.0 « devront obligatoirement être sélectionnés à la date indiquée », si bien qu’une configuration uniquement classique cesse d’être acceptable.

Ce qui est déjà post-quantique par défaut

Ces composants négocient un échange de clés hybride ML-KEM sans aucune configuration, à condition que les deux extrémités soient assez récentes :

Côté serveur, les choses ont aussi bougé. Un scan réalisé avec OpenSSL 3.5.7 le 20 octobre 2026, à l’aide du script de la section sur l’inventaire, a donné ceci :

www.cloudflare.com:443     TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
github.com:443             TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA256
www.google.com:443         TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
login.microsoftonline.com:443 TLSv1.3  ECDH,secp384r1    rsaEncryption 2048 bit    sha256WithRSAEncryption
api.stripe.com:443         TLSv1.3  X25519,253bits    rsaEncryption 2048 bit    sha256WithRSAEncryption
letsencrypt.org:443        TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA384

Deux colonnes résument la situation. L’échange de clés est hétérogène : certains services ont l’hybride, d’autres non. Les colonnes du certificat sont uniformément classiques : ECDSA P-256 ou RSA-2048. Il en va de même pour SSH, où GitHub choisit déjà l’hybride pour un client OpenSSH 10 :

debug1: kex: algorithm: mlkem768x25519-sha256

Étape 1 : l’inventaire

Vous ne pouvez pas migrer ce que vous ne savez pas recenser. Un inventaire cryptographique utile répond, pour chaque usage de la cryptographie à clé publique, aux questions suivantes : quel algorithme et quelle taille de clé, quelle bibliothèque et quelle version, qui contrôle la configuration, combien de temps les données protégées doivent rester confidentielles, et pendant combien de temps la clé ou la signature doit rester digne de confiance.

Commencez par ce que vous pouvez mesurer de l’extérieur, vos points de terminaison TLS :

#!/bin/bash
for target in "$@"; do
  host=${target%:*}; port=${target##*:}; [ "$host" = "$target" ] && port=443
  out=$(openssl s_client -connect "$host:$port" -servername "$host" -brief </dev/null 2>&1)
  proto=$(grep -m1 "^Protocol version" <<<"$out" | cut -d: -f2 | xargs)
  group=$(grep -m1 "^Negotiated TLS1.3 group" <<<"$out" | cut -d: -f2 | xargs)
  [ -z "$group" ] && group=$(grep -m1 "^Peer Temp Key" <<<"$out" | cut -d: -f2 | cut -d, -f1-2 | tr -d ' ')
  cert=$(openssl s_client -connect "$host:$port" -servername "$host" </dev/null 2>/dev/null | openssl x509 -noout -text 2>/dev/null)
  key=$(grep -m1 "Public Key Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  bits=$(grep -m1 -o -E "\([0-9]+ bit\)" <<<"$cert" | tr -d '()')
  sig=$(grep -m1 "Signature Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  printf '%-26s %-8s %-17s %-25s %s\n' "$host:$port" "$proto" "$group" "$key $bits" "$sig"
done

Le script doit être exécuté avec un client OpenSSL 3.5, car les clients plus anciens ne proposent jamais l’hybride et tous les serveurs leur paraissent classiques. Pour de nombreux domaines à la fois, le vérificateur de domaines en masse indique, pour chaque hôte, l’échange de clés, les algorithmes du certificat et la date d’expiration.

Passez ensuite à l’intérieur, où se trouve l’essentiel du travail :

• Bibliothèques et environnements d’exécution. Recensez les versions d’OpenSSL, BoringSSL, Go, JDK, .NET, Node.js et Python dans chaque image et sur chaque hôte. OpenSSL 3.0 n’est plus maintenu en amont et ne propose pas ML-KEM, alors qu’Ubuntu 24.04 le livre toujours. Ce seul fait explique bien des résultats.
• Configuration explicite. Recherchez les listes de groupes et de suites de chiffrement comme ssl_ecdh_curve, SSLOpenSSLConfCmd Groups, CurvePreferences, jdk.tls.namedGroups et KexAlgorithms. Chacune marque un endroit où une mise à jour des valeurs par défaut n’aura aucun effet.
• Code. Recherchez les appels directs aux API RSA, ECDSA, ECDH et Ed25519, les tailles de clé, les valeurs alg des JWT et les clés publiques stockées en base de données. Les signatures stockées dans des formats de données sont ce qu’il y a de plus difficile à changer par la suite.
• Clés et certificats à longue durée de vie. Racines d’AC privées, clés de signature de code et de micrologiciel, signature de documents, AC SSH, clés conservées dans des HSM. Notez pour chacun la date d’expiration et les algorithmes que le HSM prend en charge.
• Fournisseurs. Répartiteurs de charge, WAF, proxys d’inspection TLS, concentrateurs VPN, bases de données managées, API SaaS. Demandez par écrit à chaque fournisseur sa feuille de route pour ML-KEM et ML-DSA.

Consignez le résultat sous une forme lisible par machine. CycloneDX a ajouté une nomenclature cryptographique (Cryptography Bill of Materials, CBOM) précisément pour cela. Elle décrit les algorithmes, les clés, les certificats et les protocoles comme des composants de votre inventaire logiciel, à côté du SBOM des paquets que vous générez peut-être déjà.

Étape 2 : achever la migration de l’échange de clés

Pour chaque point de terminaison TLS que vous contrôlez :

1. Mettez à jour la bibliothèque TLS. OpenSSL 3.5, Go 1.24 ou ultérieur, JDK 27, ou un build récent de BoringSSL ou d’AWS-LC.
2. Supprimez les listes de groupes fixées, ou placez-y X25519MLKEM768 en tête. Une ligne de durcissement copiée d’un ancien guide est la raison la plus fréquente pour laquelle un serveur moderne négocie du X25519 simple. Le mécanisme est détaillé dans X25519MLKEM768 expliqué.
3. Testez par le chemin réseau réel. Le ClientHello hybride fait environ 1,5 Ko. Certains pare-feu, répartiteurs de charge et proxys d’inspection TLS échouent sur les ClientHello qui s’étendent sur deux paquets. Comparez un handshake hybride et un handshake purement classique sur le même chemin avant d’incriminer le serveur.
4. Vérifiez les deux tronçons. Derrière un CDN ou un répartiteur de charge, la connexion entre la périphérie (edge) et l’origine est une session TLS distincte. Le trafic enregistré sur ce tronçon peut tout autant être récolté.
5. Abandonnez TLS 1.2 là où c’est possible. Les groupes hybrides ne sont définis que pour TLS 1.3.

Viennent ensuite les canaux hors web :

• SSH. OpenSSH 9.0 et les versions ultérieures négocient déjà un hybride post-quantique quand les deux extrémités le prennent en charge. Les anciens serveurs, les équipements réseau et les piles SSH embarquées, souvent, non. Les clients OpenSSH 10.1 et ultérieurs affichent un avertissement qui nomme le risque : « This session may be vulnerable to 'store now, decrypt later' attacks. »
• VPN et IPsec. IKEv2 prend en charge des échanges de clés supplémentaires (RFC 9370), que les fournisseurs utilisent pour ajouter ML-KEM. Consultez les notes de version du micrologiciel de votre passerelle.
• Chiffrement applicatif. Tout ce qui enveloppe des clés de données avec RSA ou ECDH, comme le chiffrement d’enveloppe, les sauvegardes chiffrées ou la messagerie de bout en bout, a besoin d’une voie fondée sur ML-KEM ou sur un KEM hybride. HPKE (RFC 9180) avec un KEM hybride en est la brique de base habituelle. Le bac à sable HPKE montre comment les pièces s’assemblent.

Étape 3 : signatures et certificats

Ici, l’écosystème n’est pas prêt à faire le travail à votre place. En 2026, il s’agit donc de préparer le terrain :

• Certificats web publics : attendez, mais préparez-vous. Aucun navigateur n’accepte de certificats ML-DSA émis par des AC publiques. Chrome a indiqué en février 2026 qu’il n’envisage pas dans l’immédiat d’ajouter à son magasin de certificats racines des certificats X.509 à clés post-quantiques. Il construit un magasin de certificats racines distinct, résistant au quantique, autour des Merkle Tree Certificates, en cours de normalisation au sein du groupe de travail PLANTS de l’IETF. D’ici là, le travail utile, c’est l’automatisation. Une équipe capable de remplacer n’importe quel certificat en quelques minutes changera d’algorithme sans peine, et la réduction de la durée de vie des certificats pousse dans le même sens.
• PKI privée : lancez un pilote ML-DSA dès maintenant. Le mTLS interne, les maillages de services (service mesh), l’identité des appareils et les certificats VPN sont sous votre contrôle aux deux extrémités. OpenSSL 3.5, Go 1.27, Java 24+, .NET 10 et BouncyCastle gèrent tous les clés et les certificats ML-DSA. Comptez environ 5,5 Ko pour un certificat feuille ML-DSA-65 et testez ce qui casse : tailles de tampon, limites d’en-têtes, prise en charge par les HSM. ML-DSA côté développeur fournit du code fonctionnel et décrit les pièges des formats de clé.
• D’abord les ancres de confiance à longue durée de vie. Une clé racine ou de micrologiciel créée en 2026 sera encore jugée fiable après 2035. Pour la signature des micrologiciels et des mises à jour logicielles, la CNSA 2.0 exige les schémas de signature à état fondés sur le hachage LMS ou XMSS (SP 800-208) et attend leur usage exclusif d’ici 2030. SLH-DSA, sans état (FIPS 205), est l’alternative prudente quand vous ne pouvez pas gérer l’état des signatures.
• Artefacts signés qui doivent rester vérifiables. Les documents, archives et journaux signés aujourd’hui avec ECDSA doivent être protégés à nouveau avant que leurs signatures ne cessent d’être fiables. Prévoyez le renouvellement des horodatages et la re-signature des archives, comme le fait déjà la validation à long terme des PDF pour les certificats qui expirent.
• Jetons et API. JOSE et COSE disposent d’identifiants (code points) pour ML-DSA (RFC 9964). Une signature de 3,3 Ko porte un JWT à environ 4,5 Ko en base64url, ce qui compte pour les cookies et les en-têtes. Mesurez avant de basculer.

Étape 4 : rendre le prochain changement peu coûteux

La migration ne se fera pas en une seule bascule. L’échange de clés hybride pourrait plus tard céder la place à ML-KEM seul. ML-DSA pourrait être rejoint par FN-DSA, que le NIST prévoit de publier sous le nom de FIPS 206. Les signatures composites et hybrides sont encore en cours de conception. L’agilité cryptographique est ce qui empêche chacun de ces changements de devenir un nouveau projet pluriannuel :

• Les identifiants d’algorithme accompagnent les données (un OID, un alg JOSE, un octet de version), et les vérificateurs choisissent leur traitement d’après eux au lieu de faire des suppositions.
• Les tailles de clé et de signature ne sont pas codées en dur. Les colonnes, les tampons et les champs de protocole peuvent contenir plusieurs kilo-octets.
• Les clés sont générées, stockées et renouvelées automatiquement. Personne ne copie à la main un fichier PEM dans une configuration.
• La configuration se trouve en un seul endroit par pile, si bien que le prochain changement de groupe ou d’algorithme tient en une seule modification.

Erreurs courantes

• Tester avec un ancien client. openssl s_client d’OpenSSL 3.0, ou curl lié à cette version, ne propose jamais l’hybride. Tous les serveurs paraissent alors classiques, y compris ceux qui ont déjà migré.
• Prendre la périphérie du CDN pour la connexion entière. Le tronçon entre le navigateur et la périphérie est souvent post-quantique, alors que le tronçon entre la périphérie et l’origine, pour la même requête, ne l’est pas.
• Désactiver l’hybride pour contourner un équipement intermédiaire défaillant. Cela retire la protection à toutes les connexions. Réparez ou remplacez l’équipement.
• Attendre les certificats ML-DSA publics avant de faire quoi que ce soit. L’inventaire, les mises à jour de bibliothèques et l’automatisation des certificats sont de toute façon nécessaires, et ils prennent plus de temps que l’attente.
• Lire « déconseillé après 2030 » comme « autorisé jusqu’en 2035 ». Les données que vous chiffrez en 2029 avec un échange de clés classique restent exposées pendant toute la durée où elles doivent rester confidentielles. Les échéances relèvent de la conformité, pas de la sécurité.

Liste de contrôle pour le reste de 2026

1. Lancez un scan OpenSSL 3.5 de chaque point de terminaison TLS public et interne, et consignez le groupe, l’algorithme du certificat et la version de la bibliothèque.
2. Mettez à jour les bibliothèques TLS des images de base. Supprimez les listes de groupes fixées. Relancez le scan.
3. Testez l’hybride à travers chaque équipement intermédiaire du chemin, y compris sur le tronçon entre la périphérie et l’origine.
4. Mettez à jour les serveurs SSH vers OpenSSH 9.9 ou ultérieur pour ML-KEM (les versions 9.0 et ultérieures proposent déjà l’hybride sntrup761), ainsi que les équipements réseau pour lesquels un micrologiciel est disponible.
5. Recensez chaque clé de signature et chaque ancre de confiance à longue durée de vie, avec sa date d’expiration et les algorithmes que son HSM prend en charge.
6. Mettez en place une AC de test ML-DSA et émettez des certificats pour un service interne.
7. Automatisez l’émission et le renouvellement des certificats partout où ils sont encore manuels.
8. Demandez par écrit à vos fournisseurs leurs dates de prise en charge de ML-KEM et ML-DSA.

Sources

• NIST IR 8547 ipd, Transition vers les normes de cryptographie post-quantique (novembre 2024), tableaux 2 à 4.
• NSA, Annonce de la Commercial National Security Algorithm Suite 2.0 (CSA PP-22-1338, septembre 2022) : algorithmes et calendrier de transition.
• Feuille de route coordonnée de mise en œuvre pour la transition vers la cryptographie post-quantique, groupe de travail PQC de l’UE (EU PQC Workstream), version 1.1, 11 juin 2025.
• NCSC, Calendrier de migration vers la cryptographie post-quantique (mars 2025).
• FIPS 203, FIPS 204, FIPS 205, SP 800-208.
• OpenSSH, Cryptographie post-quantique, et notes de version d’OpenSSH 9.0, 9.9, 10.0 et 10.1.
• Stratégie de publication d’OpenSSL (3.5 LTS jusqu’au 2030-04-08). Notes de version de Go 1.24, JEP 527.
• Google Security Blog, Vers un HTTPS résistant au quantique, robuste et efficace (février 2026).

Les scans ont été effectués le 20 octobre 2026 dans node:24.22.0-trixie (OpenSSL 3.5.7, OpenSSH 10.0p2).