La cryptographie post-quantique arrive. Voici ce que votre organisation doit faire avant 2030

En août 2024, NIST a publié ses premières normes cryptographiques post-quantiques finalisées : ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) et FN-DSA (FIPS 206). L'annonce a été largement couverte. La réponse de la plupart des organisations a été de l'ajouter à une feuille de route de sécurité future et de passer à des priorités plus immédiates.

C'est la mauvaise décision, et la raison tient à une menace qui n'attend pas que la migration soit terminée. Comprendre le risque réel — et les étapes spécifiques nécessaires pour y faire face — est ce qui distingue les organisations qui géreront bien cette transition de celles qui seront en panique en 2029.

Le modèle de menace : récolter maintenant, déchiffrer plus tard

L'argument standard pour l'urgence autour de la cryptographie résistante aux quantiques est le suivant : les ordinateurs quantiques pertinents pour la cryptographie n'existent pas encore, alors pourquoi se précipiter ? La réponse est l'attaque de "récolter maintenant, déchiffrer plus tard" (HNDL), et elle rend la chronologie du développement des ordinateurs quantiques largement sans importance pour les décisions de migration d'aujourd'hui.

Des adversaires étatiques et des organisations criminelles sophistiquées enregistrent aujourd'hui le trafic chiffré — sessions TLS, tunnels VPN, transferts de fichiers chiffrés — et le stockent pour le déchiffrer une fois qu'un ordinateur quantique capable d'exécuter l'algorithme de Shor à grande échelle existera. Les données chiffrées aujourd'hui avec RSA-2048 ou ECDSA P-256 incluent des informations sensibles à longue durée de vie : dossiers médicaux, transactions financières, propriété intellectuelle, communications classifiées. Si ces données doivent rester confidentielles pendant 10 à 20 ans, la question pertinente n'est pas "quand les ordinateurs quantiques casseront-ils RSA ?" mais plutôt "un ordinateur quantique capable est-il possible dans la fenêtre de confidentialité des données que je chiffre aujourd'hui ?"

La plupart des estimations crédibles placent le calcul quantique pertinent pour la cryptographie (CRQC) à 8 à 15 ans. Les estimations crédibles les plus pessimistes le placent à 5 à 7 ans. La récolte a lieu maintenant. L'horloge tourne à partir du moment où les données sont capturées, et non à partir du moment où un ordinateur quantique est allumé.

Les quatre normes NIST et leur utilité

ML-KEM (FIPS 203) — basé sur l'algorithme CRYSTALS-Kyber — est un mécanisme d'encapsulation de clés conçu pour remplacer RSA et ECDH dans l'échange de clés. C'est la norme la plus immédiatement importante pour la plupart des organisations : l'échange de clés TLS 1.3, la configuration de sessions VPN et les protocoles de messagerie sécurisée reposent tous sur des mécanismes d'échange de clés que ML-KEM remplace.

ML-DSA (FIPS 204) — basé sur CRYSTALS-Dilithium — est un algorithme de signature numérique remplaçant RSA et ECDSA pour la signature. Il est pertinent partout où l'authentification repose sur des signatures : signature de code, délivrance de certificats, signature de documents, authentification SSH.

SLH-DSA (FIPS 205) — basé sur SPHINCS+ — est un schéma de signature basé sur le hachage sans état. Il est plus lent et produit des signatures plus grandes que ML-DSA mais possède une preuve de sécurité basée uniquement sur la sécurité de la fonction de hachage, ce qui en fait un algorithme de sauvegarde précieux si une vulnérabilité est découverte dans les schémas basés sur les réseaux. Recommandé pour les cas nécessitant une vérification de signature à long terme (années à décennies).

FN-DSA (FIPS 206) — basé sur FALCON — est un schéma de signature avec des tailles de signature plus petites que ML-DSA, utile dans les environnements à bande passante limitée. Il nécessite une implémentation minutieuse pour éviter les attaques par canaux auxiliaires, ce qui en fait une priorité inférieure pour la plupart des organisations par rapport à ML-DSA.

Ordre de priorité de migration pour la plupart des organisations : ML-KEM d'abord (protéger l'échange de clés en transit), puis ML-DSA (protéger l'authentification), puis envisager SLH-DSA pour les signatures à longue durée de vie. FN-DSA est destiné aux environnements spécialisés.

Ce que CISA et NIST ont réellement exigé

La publication spéciale NIST 1800-38C (décembre 2024) fournit des conseils de migration pour TLS 1.3 et recommande des configurations d'échange de clés hybrides spécifiques : X25519MLKEM768 (ML-KEM-768 combiné avec X25519) pour un déploiement immédiat. Les modes hybrides exécutent simultanément l'échange de clés classique et post-quantique — si l'un est sécurisé, la session est sécurisée — permettant aux organisations de déployer la PQC sans tout miser sur les nouveaux algorithmes avant qu'ils n'aient eu plus de temps sur le terrain.

Les directives de CISA 2025 pour les agences civiles fédérales ont fixé deux jalons : terminer l'inventaire cryptographique d'ici fin 2026 et terminer la migration des systèmes prioritaires d'ici fin 2030. "Systèmes prioritaires" signifie les systèmes traitant des informations classifiées, le contrôle des infrastructures critiques et les systèmes traitant des informations personnelles identifiables à grande échelle.

Pour le secteur privé, ce ne sont pas des mandats légaux. Mais les industries réglementées voient déjà les exigences migrer : les régulateurs financiers de l'UE ont intégré la préparation à la PQC dans leurs normes techniques DORA 2026. Les directives HIPAA mises à jour en 2025 font référence aux normes PQC de NIST pour les systèmes de santé traitant des dossiers à conservation longue. Les exigences d'approvisionnement sont en avance sur vous : si vous fournissez des agences fédérales, les systèmes capables de PQC seront une exigence contractuelle avant 2028.

Par où commencer : l'inventaire cryptographique

La première étape, et la plus sous-estimée, est de savoir quelle cryptographie vous exécutez actuellement. La plupart des organisations n'ont pas une image complète de l'utilisation de RSA et ECDSA dans leurs systèmes. L'inventaire est plus difficile qu'il n'y paraît car les primitives cryptographiques sont intégrées dans les bibliothèques d'applications, l'infrastructure réseau, les systèmes PKI, les modules de sécurité matériels et les logiciels tiers.

Le processus d'inventaire doit produire une liste de : tous les certificats et leurs algorithmes, tous les mécanismes d'échange de clés utilisés (par protocole et système), toute l'infrastructure de signature de code et de documents, tous les HSM et leur support algorithmique, et tous les fournisseurs tiers dont les capacités cryptographiques affectent votre posture de sécurité.

Outils utiles : le Centre national de cybersécurité de NIST a publié un projet de migration PQC avec des outils open source. Des fournisseurs comme Keyfactor, AppViewX et Venafi ont publié des outils d'inventaire de certificats avec cartographie de migration PQC. Des outils de scan réseau comme Qualys et Tenable ont ajouté des capacités de détection PQC. Le but n'est pas d'avoir un inventaire parfait immédiatement — c'est d'avoir un point de départ défendable.

Ce qui est déployable aujourd'hui

Plusieurs systèmes majeurs prennent déjà en charge l'échange de clés post-quantique en mode hybride :

OpenSSH 9.0 (publié en avril 2022) utilise sntrup761x25519 pour l'échange de clés par défaut. Bien que cela précède les normes NIST finales et utilise un algorithme différent, cela démontre le modèle : l'échange de clés hybride fonctionne en production et ce depuis des années.

TLS 1.3 avec X25519MLKEM768 est pris en charge dans Chrome 131 (publié en novembre 2024), Firefox 132 et OpenSSL 3.5. Cloudflare a activé l'échange de clés hybride PQC pour tout le trafic en septembre 2024. Apple a activé l'échange de clés hybride ML-KEM dans iMessage en février 2025 dans le cadre du protocole PQ3, remplaçant le schéma PQXDH lancé en 2024.

Le point de départ pratique pour la plupart des organisations en 2026 : activer X25519MLKEM768 dans votre couche de terminaison TLS (équilibreurs de charge, passerelles API, configurations CDN) et mettre à jour votre feuille de route PKI interne pour inclure la capacité de délivrance de certificats ML-DSA d'ici 2028. Aucune de ces étapes ne nécessite de prouesses organisationnelles — ce sont des changements de configuration et un travail de planification PKI qui peuvent commencer immédiatement.

Les organisations qui auront du mal en 2029 sont celles qui traitent cela comme un problème futur. Celles qui s'en sortent bien font l'inventaire maintenant, déploient l'échange de clés hybride en périphérie et intègrent des exigences fournisseurs incluant la PQC dans les cycles d'approvisionnement dès aujourd'hui.