ML-KEM vs ML-DSA : 2 Normes NIST, UE 2030 [2026]

Depuis août 2024, le NIST a tranché : la cryptographie post-quantique repose sur deux familles de normes distinctes, ML-KEM pour le chiffrement et ML-DSA pour la signature. Mais sur le terrain, beaucoup d’équipes techniques confondent encore les deux, ou pensent à tort qu’un seul algorithme suffit à sécuriser un système face à un futur ordinateur quantique. Ce n’est pas le cas. ML-KEM protège l’échange de clés et le chiffrement des communications. ML-DSA protège l’authenticité des signatures, des certificats et des mises à jour logicielles. Les deux sont nécessaires, et aucun ne remplace l’autre.

La question n’est plus théorique. La Commission européenne a fixé une feuille de route précise : chaque État membre doit avoir défini sa stratégie de migration post-quantique d’ici le 31 décembre 2026, soit dans trois mois. Les systèmes à haut risque (énergie, santé, finance, transport) doivent avoir basculé d’ici le 21 décembre 2030. En France, l’ANSSI pousse une approche hybride qui combine algorithmes classiques et post-quantiques pendant la période de transition. Ce comparatif, qui s’inscrit dans notre couverture plus large de la cryptographie, détaille les différences techniques entre ML-KEM et ML-DSA, leurs performances réelles, leur coût de déploiement et la manière de les intégrer concrètement dans une infrastructure existante.

Qu’est-ce que ML-KEM (FIPS 203) ?

ML-KEM, pour Module-Lattice-based Key-Encapsulation Mechanism, est le mécanisme d’encapsulation de clé standardisé par le NIST sous la référence FIPS 203 en août 2024. Il dérive de l’algorithme CRYSTALS-Kyber, vainqueur du concours post-quantique du NIST lancé en 2016. Son rôle est précis : permettre à deux parties d’établir une clé symétrique partagée sur un canal non sécurisé, exactement comme le fait aujourd’hui Diffie-Hellman ou ECDH dans une poignée de main TLS. La différence tient à la base mathématique : ML-KEM s’appuie sur la difficulté du problème Module Learning With Errors (Module-LWE), un problème de réseaux euclidiens que l’on ne sait pas résoudre efficacement, même avec un ordinateur quantique capable de faire tourner l’algorithme de Shor.

FIPS 203 définit trois jeux de paramètres, calibrés sur trois niveaux de sécurité : ML-KEM-512 (équivalent AES-128), ML-KEM-768 (équivalent AES-192, le choix par défaut recommandé pour la majorité des usages TLS) et ML-KEM-1024 (équivalent AES-256, réservé aux systèmes les plus sensibles). Chaque niveau augmente la taille des clés et du texte chiffré en échange d’une marge de sécurité plus large. ML-KEM n’effectue ni signature ni authentification : il encapsule uniquement une clé secrète qui sera ensuite utilisée pour chiffrer le trafic avec un algorithme symétrique classique comme AES-256-GCM.

Qu’est-ce que ML-DSA (FIPS 204) ?

ML-DSA, pour Module-Lattice-based Digital Signature Algorithm, est l’algorithme de signature numérique standardisé sous FIPS 204, publié le même jour que FIPS 203. Il dérive de CRYSTALS-Dilithium. Son objectif diffère totalement de celui de ML-KEM : il ne sert pas à chiffrer, mais à prouver qu’un message, un certificat ou un paquet logiciel provient bien de l’émetteur attendu et n’a pas été altéré. C’est l’équivalent post-quantique de RSA-PSS, ECDSA ou Ed25519 dans une infrastructure à clé publique.

ML-DSA repose lui aussi sur le problème Module-LWE, combiné à un second problème de réseaux appelé Module Short Integer Solution (Module-SIS). FIPS 204 propose trois jeux de paramètres : ML-DSA-44, ML-DSA-65 (le niveau recommandé pour un usage général) et ML-DSA-87 pour les cas les plus critiques. Contrairement à ML-KEM, dont les tailles de sortie restent modestes, les signatures ML-DSA pèsent plusieurs kilo-octets, ce qui pose de vrais problèmes d’intégration dans des protocoles pensés pour des signatures ECDSA de 70 octets, comme le souligne Cloudflare dans son analyse technique de la migration des certificats TLS (blog.cloudflare.com).

ML-KEM vs ML-DSA : le tableau comparatif technique

Le tableau ci-dessous reprend les valeurs normalisées publiées par le NIST dans FIPS 203 et FIPS 204, ainsi que les tailles équivalentes pour RSA-2048 et ECDSA P-256 à titre de comparaison. Les octets indiqués correspondent aux structures brutes définies par la norme, hors encodage ASN.1 ou certificat X.509, qui ajoute généralement une surcouche.

Algorithme	Fonction	Clé publique	Clé privée	Sortie (chiffré/signature)	Niveau de sécurité NIST
ML-KEM-512	Chiffrement (KEM)	800 octets	1 632 octets	768 octets	Niveau 1 (≈ AES-128)
ML-KEM-768	Chiffrement (KEM)	1 184 octets	2 400 octets	1 088 octets	Niveau 3 (≈ AES-192)
ML-KEM-1024	Chiffrement (KEM)	1 568 octets	3 168 octets	1 568 octets	Niveau 5 (≈ AES-256)
ML-DSA-44	Signature	1 312 octets	2 560 octets	2 420 octets	Niveau 2
ML-DSA-65	Signature	1 952 octets	4 032 octets	3 293 octets	Niveau 3
ML-DSA-87	Signature	2 592 octets	4 896 octets	4 595 octets	Niveau 5
RSA-2048	Chiffrement / signature	256 octets (modulo)	Variable (implémentation)	256 octets	≈ 112 bits classiques
RSA-3072	Chiffrement / signature	384 octets (modulo)	Variable (implémentation)	384 octets	≈ 128 bits classiques
ECDSA P-256	Signature	64-65 octets	32 octets	≈ 70-72 octets (DER)	≈ 128 bits classiques
X25519 / ECDH	Chiffrement (échange de clé)	32 octets	32 octets	32 octets (secret partagé)	≈ 128 bits classiques
Norme NIST	–	FIPS 203 (ML-KEM) / FIPS 204 (ML-DSA)	–	–	Finalisées août 2024

Le contraste saute aux yeux : les clés publiques ML-KEM et ML-DSA sont entre 15 et 40 fois plus lourdes que leurs équivalents classiques, et les signatures ML-DSA dépassent largement les 2 ko, contre 70 octets pour une signature ECDSA. C’est précisément ce facteur de taille qui explique pourquoi les deux normes ne se déploient pas au même rythme : ML-KEM s’intègre relativement facilement dans une poignée de main TLS, alors que ML-DSA impose de revoir la taille des certificats, des chaînes de confiance et des messages de handshake.

Performance : ce que disent les benchmarks

Les chiffres de performance post-quantique varient beaucoup selon le matériel, le compilateur et la bibliothèque utilisée, donc aucun benchmark unique ne fait référence. Trois sources indépendantes donnent cependant une idée fiable des ordres de grandeur. Une présentation du NIST lors de son atelier Crypto Agility Workshop (source : csrc.nist.gov) mesure, sur du matériel embarqué, une opération ML-KEM complète autour de 4 ms, contre environ 31 ms et 12 ms pour les deux opérations de ML-DSA (signature et vérification). L’écart est net : signer avec ML-DSA coûte nettement plus cher en temps CPU qu’encapsuler une clé avec ML-KEM.

Un benchmark 2026 réalisé sur processeur ARM embarqué va dans le même sens : un échange de clé ML-KEM-512 complet prend 35,7 ms sur le matériel testé, soit environ 17 fois plus rapide que ECDH P-256 sur ce même appareil, pendant qu’une signature ML-DSA-44 prend en moyenne 158,9 ms, avec des valeurs observées entre 70,1 ms et 541,7 ms selon la charge. Une étude distincte publiée en 2026 (source : eprint.iacr.org) mesure la génération de clé ML-KEM-768 à environ 0,28 ms, contre 2,87 ms pour une génération de clé RSA-2048 sur la même plateforme, soit un algorithme post-quantique dix fois plus rapide à ce stade précis du cycle cryptographique.

La leçon à retenir pour une équipe d’ingénierie : ML-KEM n’impose quasiment aucun surcoût de calcul par rapport à ECDH, parfois même l’inverse. ML-DSA, en revanche, coûte sensiblement plus cher en temps CPU et en bande passante que ECDSA ou Ed25519, ce qui en fait le principal point de friction des migrations TLS et PKI en cours.

Exemple pratique : générer des clés ML-KEM et ML-DSA avec OpenSSL

Pour une équipe qui veut tester concrètement les deux algorithmes avant de les intégrer dans un pipeline de production, OpenSSL 3.5+ suffit. Les commandes suivantes génèrent une paire de clés ML-KEM-768 pour le chiffrement, puis une paire de clés ML-DSA-65 pour la signature, directement en ligne de commande.

# Vérifier que la version d'OpenSSL supporte les algorithmes post-quantiques
openssl version
# doit afficher OpenSSL 3.5.0 ou supérieur

# Générer une paire de clés ML-KEM-768 (chiffrement / échange de clé)
openssl genpkey -algorithm ML-KEM-768 -out mlkem768_private.pem
openssl pkey -in mlkem768_private.pem -pubout -out mlkem768_public.pem

# Générer une paire de clés ML-DSA-65 (signature numérique)
openssl genpkey -algorithm ML-DSA-65 -out mldsa65_private.pem
openssl pkey -in mldsa65_private.pem -pubout -out mldsa65_public.pem

# Signer un fichier avec ML-DSA-65
openssl pkeyutl -sign -inkey mldsa65_private.pem -in message.txt -out signature.bin

# Vérifier la signature
openssl pkeyutl -verify -pubin -inkey mldsa65_public.pem -in message.txt -sigfile signature.bin

# Tester un handshake TLS 1.3 hybride (X25519 + ML-KEM-768) sur un serveur de test
openssl s_client -connect example.com:443 -groups X25519MLKEM768

Cette dernière commande illustre bien la logique hybride recommandée par l’ANSSI et la Commission européenne : le groupe X25519MLKEM768 combine un échange de clé classique et un échange de clé post-quantique dans la même poignée de main TLS 1.3, sans qu’aucun des deux algorithmes ne soit retiré tant que la confiance dans le nouveau standard ne s’est pas installée.

Impact concret sur la taille du handshake TLS 1.3

En pratique, l’ajout de ML-KEM et ML-DSA à une poignée de main TLS 1.3 alourdit sensiblement le volume de données échangées avant même le premier octet de données applicatives. Un ClientHello classique en ECDHE/ECDSA tient généralement sous 300 octets pour la partie clé publique. Avec ML-KEM-768 ajouté en mode hybride, ce même ClientHello dépasse 1 500 octets rien que pour le matériel cryptographique. Si le certificat du serveur est lui-même signé en ML-DSA-65 plutôt qu’en ECDSA, la chaîne de certificats transmise pendant le handshake peut grossir de plusieurs kilo-octets supplémentaires une fois comptabilisées la clé publique de 1 952 octets et la signature de 3 293 octets.

Sur une connexion fibre classique, cette différence reste imperceptible pour l’utilisateur final. Le problème se pose surtout sur deux terrains : les réseaux mobiles à latence variable, où un paquet TLS qui dépasse la taille d’une fenêtre TCP initiale peut déclencher un aller-retour réseau supplémentaire, et les environnements QUIC/UDP, où la fragmentation de paquets trop volumineux peut provoquer des échecs de connexion silencieux sur des équipements réseau mal configurés. C’est une des raisons pour lesquelles de nombreuses équipes commencent leur migration uniquement par ML-KEM, qui a un impact de taille bien plus limité, avant de s’attaquer au chantier plus lourd de ML-DSA sur les certificats.

ML-KEM et ML-DSA face aux autres candidats post-quantiques

ML-KEM et ML-DSA ne sont pas les seules options disponibles, et il est utile de savoir où ils se situent par rapport au reste de l’écosystème post-quantique du NIST. Pour le chiffrement, HQC a été sélectionné par le NIST comme second mécanisme d’encapsulation de clé, avec une base mathématique différente (codes correcteurs d’erreurs plutôt que réseaux euclidiens), ce qui en fait un filet de sécurité si une faiblesse structurelle venait à toucher les réseaux euclidiens : notre comparatif détaillé HQC face à ML-KEM creuse cet écart de performance, nettement en faveur de ML-KEM pour un usage quotidien. Pour la signature, SLH-DSA (FIPS 205), basé sur des fonctions de hachage plutôt que sur des réseaux, offre une diversité mathématique similaire face à ML-DSA, au prix de signatures et de temps de calcul plus importants encore, un arbitrage détaillé dans notre article ML-DSA face à SLH-DSA et FN-DSA.

Pour les équipes qui se demandent encore si la migration post-quantique est justifiée face aux algorithmes classiques, notre dossier RSA/ECC face à la cryptographie post-quantique détaille le calendrier de la menace et pourquoi les données chiffrées aujourd’hui avec RSA ou ECC restent exposées à une capture puis un déchiffrement différé, une fois qu’un ordinateur quantique suffisamment puissant existera. Et pour les environnements qui ont déjà basculé leur couche TLS vers ML-KEM mais hésitent encore entre les deux algorithmes classiques de référence pour l’échange de clé hybride, notre comparatif ML-KEM face à RSA et ECDH en TLS 1.3 détaille les gains de performance mesurés en conditions réelles.

Côté matériel, les fabricants de modules de sécurité matériels (HSM) ajoutent progressivement le support post-quantique à leurs gammes, une évolution couverte dans notre article sur le HSM post-quantique Thales Luna 8, utile pour les organisations qui doivent conserver leurs clés privées ML-KEM et ML-DSA dans un module certifié plutôt qu’en logiciel pur.

Pourquoi deux normes distinctes et pas une seule ?

La confusion la plus fréquente consiste à croire qu’un seul algorithme post-quantique peut couvrir tous les usages. En cryptographie classique, RSA peut théoriquement servir à la fois au chiffrement et à la signature, ce qui a longtemps entretenu cette habitude. Les réseaux euclidiens ne fonctionnent pas de la même manière : les problèmes mathématiques qui rendent un KEM sûr (Module-LWE pur) ne sont pas identiques à ceux qui rendent une signature sûre (Module-LWE combiné à Module-SIS), et les paramètres optimisés pour l’un dégradent fortement l’autre.

Le NIST a donc choisi, dès le départ du concours de standardisation post-quantique, de séparer clairement les deux familles d’algorithmes. C’est un changement culturel pour les équipes sécurité : une migration post-quantique complète nécessite d’inventorier séparément tous les usages de chiffrement (TLS, VPN, messagerie chiffrée) et tous les usages de signature (certificats, signature de code, authentification de firmware), puis de planifier deux chantiers distincts avec des échéances et des contraintes différentes. C’est exactement la distinction que fait le gouvernement américain dans son mémorandum de migration post-quantique de juin 2026, qui sépare une phase dédiée à la migration du chiffrement d’une phase ultérieure consacrée à la migration des signatures (source : whitehouse.gov).

Coût de mise en œuvre : bibliothèques, cloud et HSM

Adopter ML-KEM et ML-DSA n’impose pas nécessairement d’acheter une nouvelle licence. La voie la plus accessible reste le logiciel libre : OpenSSL 3.5.0, sorti en avril 2025, intègre nativement ML-KEM et ML-DSA sans frais. Le projet Open Quantum Safe (liboqs), bibliothèque C open source maintenue par une communauté académique et industrielle, propose les mêmes algorithmes sous licence libre et sert de base à de nombreuses intégrations dans OpenSSH, les navigateurs et les serveurs TLS (source : github.com/open-quantum-safe).

Côté cloud managé, aucun des trois grands fournisseurs n’a publié de surcoût spécifique pour les opérations post-quantiques à ce jour : elles sont facturées au même tarif que les opérations classiques. Le tableau suivant reprend les grilles tarifaires publiques de gestion de clés, utiles pour chiffrer un budget de migration.

Fournisseur	Coût par clé	Coût par opération	Support ML-KEM / ML-DSA	Source
AWS KMS	1 $/clé/mois	20 000 requêtes gratuites/mois, puis facturation à la requête	Aucun surcoût post-quantique publié	aws.amazon.com/kms/pricing
Google Cloud KMS	0,06 $/version de clé active/mois	0,03 $ pour 10 000 opérations	Aucun surcoût post-quantique publié	cloud.google.com/kms/pricing
Azure Key Vault	Facturation à l’usage (clé facturée si utilisée sur 30 jours)	Tarif usage standard, non détaillé par algorithme	Aucun surcoût post-quantique publié	azure.microsoft.com/pricing/key-vault
OpenSSL 3.5+	Gratuit (open source)	Gratuit	Natif depuis avril 2025	openssl.org
liboqs (Open Quantum Safe)	Gratuit (open source)	Gratuit	Natif, toutes les variantes ML-KEM et ML-DSA	github.com/open-quantum-safe/liboqs
HSM dédié (appliance physique)	Sur devis, dépend du modèle et du contrat	Dépend du débit et de la licence firmware	Variable selon le fournisseur et la version du firmware	Contacter le fournisseur

Le coût réel d’une migration ne se trouve donc presque jamais dans le prix de l’algorithme lui-même, qui reste gratuit ou intégré à des grilles tarifaires existantes. Il se situe dans le temps d’ingénierie nécessaire pour auditer les usages de chiffrement, mettre à jour les bibliothèques clientes, tester la compatibilité des pare-feux et des équilibreurs de charge avec des paquets TLS plus volumineux, et former les équipes à la cryptographie hybride.

Qui déploie déjà ML-KEM et ML-DSA en production ?

Cinq cas concrets illustrent où en est réellement l’adoption, avec une distinction importante entre déploiement du standard final et déploiement d’une version pré-normative de la même famille d’algorithmes (Kyber, l’ancêtre direct de ML-KEM).

Cloudflare a commencé à déployer un mécanisme hybride de la famille Kyber dès 2022 pour protéger le trafic arrivant sur ses serveurs, une initiative antérieure à la publication finale de FIPS 203, puis a confirmé sa migration vers le standard ML-KEM une fois celui-ci finalisé (source : blog.cloudflare.com).
Google Chrome a activé par défaut le groupe d’échange de clé hybride X25519MLKEM768 dans Chrome 131, sorti en novembre 2024, en remplacement du groupe expérimental basé sur Kyber utilisé jusque-là.
Apple a lancé le protocole PQ3 pour iMessage en février 2024, déployé avec iOS 17.4, iPadOS 17.4 et macOS 14.4 : une conception hybride basée sur la famille Kyber, antérieure elle aussi à la finalisation de FIPS 203.
Signal a introduit PQXDH en septembre 2023, un protocole d’accord de clé hybride combinant X25519 et un algorithme de la famille Kyber pour protéger l’établissement des sessions de messagerie chiffrée.
Microsoft indique, via sa bibliothèque cryptographique SymCrypt, un support de ML-KEM et ML-DSA déployé progressivement sur Azure, Microsoft 365, Windows 11 et Windows Server 2025, une annonce à confirmer au cas par cas dans la documentation produit de chaque service.

Un point mérite d’être souligné : la plupart des déploiements grand public antérieurs à 2024-2025 reposent sur Kyber, la version pré-standardisation de ML-KEM, et non sur l’implémentation finale FIPS 203 au sens strict. Les deux partagent la même base mathématique, mais les paramètres exacts ont pu être ajustés lors de la finalisation par le NIST. Pour un projet qui démarre aujourd’hui, il faut viser directement l’implémentation FIPS 203/204 conforme, disponible dans OpenSSL 3.5+ ou liboqs.

Calendrier de migration : France et Union européenne

La Commission européenne a publié sa feuille de route coordonnée de transition post-quantique, adoptée par les États membres en juin 2025 après une recommandation initiale datant d’avril 2024 (source : digital-strategy.ec.europa.eu). Trois jalons structurent le calendrier : d’ici le 31 décembre 2026, chaque État membre doit avoir défini sa propre feuille de route post-quantique et engagé la planification pour les cas d’usage à risque élevé et moyen. D’ici le 21 décembre 2030, les systèmes à haut risque (infrastructures critiques : eau, énergie, santé, finance, transport) doivent avoir migré, et les mises à jour logicielles et firmware doivent activer la cryptographie post-quantique par défaut. D’ici le 31 décembre 2035, l’ensemble des catégories de risque doit avoir achevé sa migration.

En France, l’ANSSI recommande une approche hybride associant un algorithme classique (RSA ou courbe elliptique) à un algorithme post-quantique pour les nouveaux produits candidats à une certification ou une qualification de sécurité, une position détaillée dans son avis dédié à la migration post-quantique (source : cyber.gouv.fr). Cette hybridation, qui combine par exemple X25519 et ML-KEM-768 au sein d’une même poignée de main TLS, permet de garder une sécurité au moins équivalente à l’existant même si une faiblesse imprévue était découverte dans l’un des deux algorithmes. Les détails précis du calendrier de certification français sont couverts dans notre article dédié sur l’obligation ANSSI post-quantique dès 2027.

ML-KEM : avantages et inconvénients

ML-KEM présente un profil globalement favorable à une adoption rapide. Ses tailles de clés restent proches de celles de l’existant, son coût de calcul est comparable voire inférieur à ECDH sur certaines plateformes, et son intégration dans une poignée de main TLS 1.3 ne nécessite pas de réécrire l’ensemble de la chaîne de certificats. Les principales limites tiennent à la jeunesse relative de la norme : ML-KEM n’a pas encore quinze ans de cryptanalyse publique cumulée contrairement à RSA ou ECC, et certains équipements réseau anciens (pare-feux, équilibreurs de charge) peuvent mal gérer des paquets TLS légèrement plus volumineux que prévu, provoquant des erreurs de fragmentation silencieuses.

Avantages : performance proche ou supérieure à ECDH, intégration TLS 1.3 relativement simple, soutenu par un déploiement hybride déjà actif chez Cloudflare, Google et Apple, gratuit via OpenSSL et liboqs.
Inconvénients : norme récente (finalisée en 2024) avec moins de recul que RSA/ECC, clés 15 à 20 fois plus lourdes pouvant casser certains équipements réseau legacy, nécessite un mode hybride pour les certifications les plus strictes en 2026.

ML-DSA : avantages et inconvénients

ML-DSA pose davantage de difficultés pratiques. Ses signatures, qui dépassent 2,4 ko au niveau de sécurité le plus bas, alourdissent sensiblement les certificats X.509, les chaînes de confiance TLS et les mécanismes de signature de code. Un certificat intermédiaire classique signé en ECDSA tient en quelques centaines d’octets ; le même certificat signé en ML-DSA-65 peut dépasser plusieurs kilo-octets une fois la chaîne complète comptabilisée, ce qui ralentit les poignées de main sur des réseaux à latence élevée ou dans des contextes IoT à bande passante limitée. Le temps de signature, mesuré jusqu’à dix fois plus long que pour ECDSA dans certains benchmarks embarqués, pèse également sur les infrastructures qui signent un grand volume de transactions ou de paquets logiciels.

Avantages : sécurité post-quantique prouvée mathématiquement sur la même base que ML-KEM, norme NIST finalisée et stable, alternative SLH-DSA (FIPS 205) disponible comme filet de sécurité si une faiblesse structurelle était découverte dans les réseaux euclidiens.
Inconvénients : signatures et clés nettement plus lourdes que ECDSA ou Ed25519, temps de signature plus long, impact direct sur la taille des certificats et le volume de données échangées lors du handshake TLS.

Guide de migration : comment adopter ML-KEM et ML-DSA

La migration se construit par étapes, sans bascule brutale. Voici la séquence recommandée pour une équipe infrastructure ou sécurité qui démarre son chantier post-quantique aujourd’hui.

Inventorier séparément chiffrement et signature. Lister tous les points où du chiffrement ou un échange de clé a lieu (TLS, VPN, messagerie), puis lister séparément tous les points où une signature est vérifiée (certificats, mise à jour logicielle, authentification de firmware). Les deux chantiers ont des priorités et des risques différents.
Mettre à jour les bibliothèques cryptographiques. Migrer vers OpenSSL 3.5 ou une version intégrant liboqs, qui supportent nativement ML-KEM et ML-DSA sans développement maison.
Activer un mode hybride, pas un remplacement pur. Combiner X25519 et ML-KEM-768 pour le chiffrement, ECDSA et ML-DSA-65 pour la signature, le temps que la cryptanalyse publique post-quantique mûrisse. C’est la recommandation explicite de l’ANSSI pour les systèmes sensibles.
Tester la compatibilité réseau. Vérifier que les pare-feux, proxys et équilibreurs de charge gèrent correctement des paquets TLS ClientHello plus volumineux, en particulier sur des connexions UDP/QUIC où la fragmentation peut provoquer des échecs silencieux.
Prioriser la signature de code et les mises à jour firmware. C’est l’usage le plus critique à long terme : un firmware signé aujourd’hui doit rester vérifiable dans dix ou vingt ans, bien après la fenêtre où un ordinateur quantique pourrait casser ECDSA rétroactivement.
Documenter et former les équipes. La confusion entre ML-KEM et ML-DSA reste la première source d’erreur de configuration observée sur les premiers projets pilotes, un choix d’algorithme pour le mauvais usage compromettant tout l’exercice.
Planifier une revue annuelle. Avec l’arrivée possible de FN-DSA (FIPS 206, basé sur FALCON, encore en projet de norme) et de nouveaux candidats de signature évalués par le NIST, la stratégie de cryptographie doit rester révisable sans tout reconstruire.

5 cas d’usage : quel algorithme choisir ?

Le choix entre ML-KEM et ML-DSA (ou les deux) dépend entièrement du besoin métier. Voici cinq scénarios concrets rencontrés par les équipes qui planifient leur migration.

Sécuriser une API REST ou un site web en TLS 1.3 : ML-KEM-768 en mode hybride avec X25519 suffit pour le chiffrement du transport ; la signature du certificat peut rester en ECDSA tant que l’autorité de certification ne propose pas ML-DSA en production.
Signer des mises à jour logicielles ou du firmware embarqué : ML-DSA-65 ou ML-DSA-87 s’impose, car la menace quantique porte avant tout sur la capacité à forger une fausse mise à jour des années après la signature d’origine (attaque de type « store now, decrypt/forge later »).
Protéger une messagerie chiffrée de bout en bout : ML-KEM pour l’établissement de session, à l’image de l’approche hybride déjà utilisée par Signal et Apple iMessage, sans besoin direct de ML-DSA côté protocole de messagerie lui-même.
Authentifier des transactions financières ou bancaires : ML-DSA-87 est recommandé pour le niveau de sécurité le plus élevé, les signatures de transaction devant rester vérifiables sur de longues périodes réglementaires.
Déployer un objet connecté à bande passante limitée (IoT, capteur industriel) : ML-KEM-512 reste praticable malgré son coût réseau, alors que ML-DSA impose souvent de revoir entièrement le budget de bande passante de l’appareil ; SLH-DSA (FIPS 205) ou une signature différée côté passerelle peuvent être des alternatives à étudier selon le contexte.

Ce que disent les sources officielles

Plusieurs organisations ont publiquement détaillé leur position sur la nécessité de migrer rapidement les deux familles d’algorithmes. Le NIST a insisté sur l’urgence dès l’annonce des trois premières normes finalisées : “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time” (nist.gov).

Le mémorandum de migration post-quantique de la Maison-Blanche, publié en juin 2026, distingue explicitement les deux normes et leur calendrier propre. Il cadre ML-KEM comme le “FIPS 203 ML-KEM (Key Encapsulation Mechanism (KEM)/Encryption)” et ML-DSA comme le “FIPS 204 ML-DSA (Digital Signature Algorithm)”, avant de préciser que la phase de migration des signatures doit couvrir, d’ici 2031, “all HVAs, high impact systems, systems with highly sensitive data, and systems that an agency determines are likely to be particularly vulnerable to CRQC-based attacks” (whitehouse.gov).

Google résume de son côté l’enjeu global de la double migration dans son blog technique : “Quantum computers will pose a significant threat to current cryptographic standards, and specifically to encryption and digital signatures” (blog.google), confirmant que le chiffrement et la signature doivent être traités comme deux chantiers de migration distincts, chacun avec ses propres contraintes de performance et de compatibilité.

Le verdict : ML-KEM et ML-DSA ne sont pas en concurrence

Comparer ML-KEM et ML-DSA comme on comparerait deux concurrents sur un même marché n’a pas vraiment de sens : ce sont deux outils complémentaires, destinés à deux problèmes différents. Les chiffres parlent d’eux-mêmes. Côté performance, ML-KEM s’impose comme le candidat le plus simple à déployer : coût de calcul proche voire inférieur à ECDH selon les benchmarks (jusqu’à 17 fois plus rapide qu’ECDH P-256 sur certaines plateformes ARM), tailles de clés contenues entre 800 et 1 568 octets, et déploiement hybride déjà actif chez Cloudflare, Google Chrome et Apple depuis plusieurs années. Côté signature, ML-DSA reste la norme de référence malgré son coût plus élevé (signatures de 2,4 à 4,6 ko, temps de signature jusqu’à dix fois supérieur à ECDSA dans certains tests), faute d’alternative aussi mature : SLH-DSA (FIPS 205) offre un filet de sécurité mathématique différent mais avec des signatures encore plus volumineuses, et FN-DSA (FIPS 206) n’est encore qu’un projet de norme.

Pour une équipe technique française ou européenne qui doit boucler sa feuille de route avant l’échéance du 31 décembre 2026 fixée par la Commission européenne, la priorité pragmatique consiste à démarrer par ML-KEM en mode hybride sur les flux TLS, qui n’exige quasiment aucun compromis de performance, puis à planifier le chantier ML-DSA séparément en commençant par les usages les plus critiques à long terme : signature de code, firmware et transactions financières, là où la menace de type « forger plus tard » est la plus concrète.

Questions fréquentes

ML-KEM et ML-DSA peuvent-ils remplacer RSA et ECC du jour au lendemain ?
Non. La quasi-totalité des recommandations officielles, y compris celles de l’ANSSI et de la Commission européenne, préconisent un mode hybride combinant un algorithme classique et un algorithme post-quantique pendant toute la période de transition, qui s’étend jusqu’en 2030, voire 2035 pour les systèmes à risque faible.

Pourquoi ML-DSA produit-il des signatures aussi volumineuses ?
La sécurité des signatures à base de réseaux euclidiens repose sur des polynômes de grande dimension qui, une fois encodés, dépassent largement la taille d’une signature ECDSA classique. C’est un compromis structurel du problème Module-LWE/Module-SIS, pas un défaut d’implémentation.

Faut-il utiliser ML-KEM-512, 768 ou 1024 ?
ML-KEM-768 est le choix par défaut recommandé pour la majorité des usages, car il offre un bon équilibre entre sécurité et performance. ML-KEM-1024 se réserve aux systèmes les plus sensibles, tandis que ML-KEM-512 convient aux environnements contraints en bande passante.

Kyber et ML-KEM sont-ils la même chose ?
Ils partagent la même base mathématique, mais Kyber désigne la version soumise au concours du NIST avant sa finalisation, tandis que ML-KEM est le nom officiel de la norme FIPS 203 publiée en août 2024, avec des paramètres ajustés lors du processus de standardisation.

Quel est le lien entre ML-DSA et FN-DSA ?
FN-DSA, basé sur l’algorithme FALCON, est un projet de norme distinct (futur FIPS 206) encore en cours de finalisation par le NIST. Il viserait des signatures plus compactes que ML-DSA, au prix d’une implémentation plus complexe, mais n’est pas encore disponible comme standard final.

Un HSM classique peut-il gérer ML-KEM et ML-DSA ?
Cela dépend entièrement du modèle et de la version du firmware installée. Les fabricants de modules matériels de sécurité ajoutent progressivement le support post-quantique, mais il faut vérifier au cas par cas auprès du fournisseur avant de planifier une migration sur du matériel existant.

Quelle est la différence de coût réel entre les deux migrations ?
Le coût logiciel est identique (gratuit via OpenSSL ou liboqs). La différence se situe dans l’effort d’ingénierie : la migration ML-KEM touche surtout la couche transport (TLS, VPN) et se teste rapidement, tandis que la migration ML-DSA touche l’ensemble de la chaîne de confiance (certificats, autorités de certification, signature de code) et demande généralement plus de temps de validation.

La France impose-t-elle une date limite légale pour ML-KEM et ML-DSA ?
L’ANSSI formule des recommandations fortes et un calendrier de certification propre aux produits qualifiés, détaillé dans son avis dédié, mais la feuille de route contraignante la plus large reste celle de la Commission européenne, avec des jalons en 2026, 2030 et 2035 selon le niveau de risque du système concerné.

ML-KEM vs ML-DSA : 2 Normes NIST, Échéance UE 2030 [2026]