NIST a fixé une date de péremption pour RSA et les courbes elliptiques : dépréciation après 2030, interdiction après 2035, selon les slides présentés par le NIST en mars 2026. En Europe, l’ENISA demande à chaque État membre de finaliser son plan de transition vers la cryptographie post-quantique avant la fin de l’année 2026. Entre-temps, Cloudflare rapporte que plus de 30 % des connexions TLS 1.3 sur son réseau négocient déjà un échange de clés hybride post-quantique, et jusqu’à 43 % des connexions humaines mi-septembre 2025. Ce comparatif met face à face RSA/ECC et le trio ML-KEM, ML-DSA, SLH-DSA : tailles de clés, vitesse réelle, coût de migration et calendrier réglementaire, avec des chiffres sourcés pour chaque affirmation.

Pourquoi ce comparatif compte maintenant pour les équipes européennes

Jusqu’à récemment, la cryptographie post-quantique restait un sujet de recherche. Ce n’est plus le cas. En août 2024, le NIST a publié trois standards définitifs : FIPS 203 (ML-KEM) pour l’échange de clés, FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA) pour les signatures numériques. Le NIST écrit noir sur blanc que ces algorithmes « peuvent et doivent être déployés dès maintenant ». Ce n’est plus une recommandation de laboratoire, c’est une feuille de route de production, et elle change la façon dont les architectes sécurité doivent planifier leurs trois prochaines années.

Côté européen, l’ENISA a publié en mai 2025 la version 2 de son document « Agreed Cryptographic Algorithms », qui fixe trois jalons : plans de transition nationaux finalisés avant fin 2026, migration des systèmes à haut risque avant 2030, et migration de la quasi-totalité des systèmes avant 2035. Un rapport du Joint Research Centre de la Commission européenne, publié en 2026, ajoute FrodoKEM à la liste des algorithmes recommandés aux côtés de ceux retenus par le NIST, en particulier pour les usages où la prudence prime sur la performance. Pour une entreprise française soumise au RGPD et bientôt à des exigences de résilience cryptographique renforcées, ce document sert déjà de référence dans les audits de conformité.

Le moteur principal derrière cette urgence porte un nom : « harvest now, decrypt later ». Un acteur étatique ou un groupe organisé peut intercepter et stocker aujourd’hui du trafic chiffré en RSA ou en ECC, puis le déchiffrer dès qu’un ordinateur quantique suffisamment puissant existera. Pour les secteurs santé, défense et finance, où les données doivent rester confidentielles pendant dix, vingt ou trente ans, ce risque justifie une migration anticipée plutôt qu’une attente du dernier moment.

RSA et ECC : ce que la cryptographie classique fait encore très bien

RSA et les courbes elliptiques (ECC, avec ECDSA pour les signatures et ECDH ou X25519 pour l’échange de clés) forment le socle de TLS depuis deux décennies. Leur force tient à leur compacité. Une clé publique RSA-2048 tient dans 256 octets, une clé publique ECDSA P-256 dans 64 octets non compressés (33 compressée), et une clé partagée X25519 dans seulement 32 octets. Ces tailles minuscules expliquent pourquoi TLS, SSH et les cartes bancaires européennes reposent encore massivement dessus.

Mathématiquement, ces algorithmes reposent sur deux problèmes : la factorisation de grands nombres premiers pour RSA, et le logarithme discret sur courbe elliptique pour ECDSA/ECDH. Un ordinateur classique met des milliards d’années à casser RSA-2048 par force brute. Mais l’algorithme de Shor, exécuté sur un ordinateur quantique suffisamment stable, résout ces deux problèmes en temps polynomial. C’est précisément pour cette raison que le NIST classe RSA, Diffie-Hellman (y compris ECDH), MQV, ECDSA et EdDSA comme « vulnérables » dans ses présentations 2026, même s’ils restent parfaitement sûrs face aux ordinateurs classiques d’aujourd’hui.

Ce distinguo compte pour la suite de l’article. RSA et ECC ne sont pas cassés aujourd’hui. Ils sont condamnés à moyen terme par une technologie qui n’existe pas encore à l’échelle nécessaire. C’est justement ce délai que le calendrier NIST/ENISA cherche à exploiter pour organiser une transition ordonnée plutôt qu’une panique de dernière minute.

ML-KEM, ML-DSA et SLH-DSA : les trois piliers post-quantiques expliqués

ML-KEM (anciennement Kyber, FIPS 203) gère l’échange de clés. Il repose sur des réseaux euclidiens structurés (module lattices), un problème mathématique que même un ordinateur quantique ne sait pas résoudre efficacement à ce jour. ML-KEM existe en trois variantes : ML-KEM-512 (niveau de sécurité 1), ML-KEM-768 (niveau 3, recommandé pour la majorité des usages TLS) et ML-KEM-1024 (niveau 5, pour les contextes les plus sensibles).

ML-DSA (anciennement Dilithium, FIPS 204) gère les signatures numériques, avec le même fondement mathématique que ML-KEM. Trois variantes existent aussi : ML-DSA-44, ML-DSA-65 et ML-DSA-87, du niveau de sécurité le plus léger au plus élevé. SLH-DSA (anciennement SPHINCS+, FIPS 205) prend une voie totalement différente : il s’appuie uniquement sur des fonctions de hachage, sans aucune hypothèse sur les réseaux euclidiens. Ses signatures sont nettement plus volumineuses que celles de ML-DSA, mais son modèle de sécurité, plus conservateur, en fait une police d’assurance si une faille venait à être découverte dans les schémas à base de réseaux.

Un quatrième nom circule dans les rapports européens : HQC, sélectionné par le NIST pour standardisation le 11 mars 2025 comme mécanisme de secours pour l’échange de clés, au cas où une faiblesse serait un jour identifiée dans ML-KEM. En mai 2026, le rapport NISTIR 8610 a fait le point sur un second tour de candidats pour des schémas de signature additionnels, confirmant que ML-DSA et SLH-DSA restent la base des déploiements pour l’instant.

Dans la pratique, presque personne ne bascule directement vers du « post-quantique pur ». La quasi-totalité des déploiements actuels utilisent des schémas hybrides, qui combinent un algorithme classique (X25519 le plus souvent) avec un algorithme post-quantique (ML-KEM-768). Si l’un des deux tombe, l’autre protège encore la connexion. C’est l’approche que recommande l’ENISA, et c’est celle que Chrome, Firefox et Cloudflare ont déjà activée par défaut.

Tableau comparatif : RSA, ECC et post-quantique face à face

Voici les tailles de clés et de signatures telles que publiées dans les standards officiels FIPS 203 et FIPS 204, ainsi que le statut de chaque algorithme selon la classification NIST 2026.

AlgorithmeTypeClé publiqueSignature / texte chiffréStatut NISTRésiste au quantique
RSA-2048Échange de clés / signature256 octets256 octetsFIPS 186-5, classiqueNon
RSA-3072Échange de clés / signature384 octets384 octetsFIPS 186-5, classiqueNon
ECDSA P-256Signature64 octets (33 compressée)~64 octetsFIPS 186-5, classiqueNon
ECDH X25519Échange de clés32 octets32 octetsClassique, largement adoptéNon
ML-KEM-512Échange de clés800 octets768 octetsFIPS 203, niveau 1Oui
ML-KEM-768Échange de clés1 184 octets1 088 octetsFIPS 203, niveau 3, recommandéOui
ML-KEM-1024Échange de clés1 568 octets1 568 octetsFIPS 203, niveau 5Oui
ML-DSA-44Signature1 312 octets2 420 octetsFIPS 204, niveau 2Oui
ML-DSA-65Signature1 952 octets3 293 octetsFIPS 204, niveau 3, recommandéOui
ML-DSA-87Signature2 592 octets4 595 octetsFIPS 204, niveau 5Oui
SLH-DSASignature (basée hachage)Variable selon paramètreNettement plus lourde que ML-DSAFIPS 205, secours conservateurOui
HQCÉchange de clés (secours)Variable selon niveauVariable selon niveauSélectionné mars 2025, secours de ML-KEMOui

Le contraste saute aux yeux : X25519 tient dans 32 octets, ML-KEM-768 en réclame 1 184 pour la clé publique, soit environ 37 fois plus. Pour les signatures, l’écart est encore plus marqué entre ECDSA (64 octets) et ML-DSA-65 (3 293 octets), soit un facteur supérieur à 50. C’est ce surpoids en octets, et non la puissance de calcul requise, qui explique l’essentiel du surcoût de latence mesuré en production, comme le montre la section suivante.

Benchmarks réels : vitesse, opérations par seconde et latence TLS

Trois sources indépendantes permettent de comparer les performances réelles de ces algorithmes en production, pas seulement en théorie.

Premier point de données : une présentation de Cloudflare à la conférence PQC de mars 2025 à Austin donne des chiffres d’opérations par seconde mesurés sur ses propres serveurs.

AlgorithmeOpérations/sec (client)Opérations/sec (serveur)Source
X25519 (classique)19 00019 000Cloudflare, conférence PQC Austin, mars 2025
ML-KEM-51245 00070 000Cloudflare, conférence PQC Austin, mars 2025
ML-KEM-76829 00045 000Cloudflare, conférence PQC Austin, mars 2025
ML-KEM-102420 00030 000Cloudflare, conférence PQC Austin, mars 2025

Résultat contre-intuitif : ML-KEM-768 traite 45 000 opérations par seconde côté serveur contre 19 000 pour X25519, soit 2,4 fois plus rapide en calcul brut, malgré des clés bien plus volumineuses. Une présentation conjointe NIST/Google de 2025 sur le déploiement de FIPS 203 dans des services cloud confirme la tendance : le temps d’échange de clés de ML-KEM-768 se situe dans la même plage de dizaines de microsecondes que ECDH P-256. L’équipe d’OpenSSL Corporation résume la situation ainsi dans son analyse de 2025 : ML-KEM-768 est « à portée de tir » de P-256 pour la génération de clé, et « nettement plus rapide » pour l’encapsulation et la décapsulation que toutes les courbes classiques testées. Ce point mérite d’être répété, car il casse une idée reçue tenace : non, le post-quantique n’est pas systématiquement plus lent que le classique. Sur le calcul pur, il est parfois plus rapide. Ce qui coûte cher, ce sont les octets à transmettre sur le réseau, pas les cycles CPU consommés pour les produire.

Deuxième source : une étude académique de 2026 publiée sur arXiv (2603.11006) mesure des handshakes TLS 1.3 réels. Le temps médian de handshake grimpe de 5,547 ms pour X25519 pur à 5,879 ms pour l’hybride X25519+ML-KEM-512, puis à 6,495 ms pour X25519+ML-KEM-768. Sur un scénario de backend renvoyant 4 Ko de données, la latence de bout en bout passe de 16,54 ms (X25519 seul) à 19,63 ms pour l’hybride ML-KEM-768, soit une hausse de 18,7 %. Les auteurs concluent que la couche TLS reste globalement « neutre à l’algorithme », les écarts observés (Glass’s Δ inférieur à 0,33) restant modestes.

Troisième source, cette fois côté implémentation : un article arXiv de 2026 (2605.17061) mesure la bibliothèque liboqs sous Docker/Linux. Un handshake complet X25519+ML-KEM-768 s’exécute en 243 microsecondes, soit entre 0,5 % et 2,5 % du budget habituel d’un aller-retour TLS 1.3. Avec 5 000 utilisateurs simultanés, le débit tient à 2 848 opérations par seconde, avec une dégradation limitée à 4,9 % par rapport à un utilisateur unique.

Sur le terrain, Cloudflare rapporte dans son bilan « State of the post-quantum Internet 2025 » un ralentissement de handshake d’environ 4 % lié à l’échange de clés hybride, provoqué par 1,1 Ko de trafic supplémentaire serveur-vers-client et 1,2 Ko client-vers-serveur. C’est là que le bât blesse vraiment : pas l’échange de clés, mais les signatures. Le blog Cloudflare de 2024 chiffre précisément l’impact d’un passage généralisé à ML-DSA-44 pour les certificats serveur : ajout de 17 Ko de données transmises pendant le handshake. Au-delà de 9 Ko ajoutés, la latence grimpe d’environ 15 %. Passé le seuil de 10 Ko, un aller-retour réseau supplémentaire peut se déclencher, avec un ralentissement pouvant dépasser 60 % sur les liaisons à latence élevée.

Coût et tarification : HSM, certificats et budgets de migration

La cryptographie post-quantique elle-même n’a pas de prix : ML-KEM et ML-DSA sont des algorithmes ouverts, implémentés gratuitement dans OpenSSL et liboqs. Le coût réel se situe dans l’infrastructure matérielle (HSM) et les certificats compatibles.

Service / produitFournisseurTarif indicatifRemarque
AWS CloudHSM (à la demande)AWSEnv. 1,40 à 2,56 $/heure selon la région UEAucun coût initial, facturation horaire, pas de palier gratuit
Azure Managed HSM (pool Standard B1)Microsoft AzureEnv. 3,20 $/heure par poolEnviron 2 300 à 2 400 $/mois en usage continu
Google Cloud HSM (mono-tenant)Google CloudEnv. 4,79 $/heure par instance15 000 versions de clé incluses par instance
Google Cloud KMS (clé HSM RSA/AES)Google Cloud1,00 $ par version de clé/moisTarif standard pour clés protégées HSM multi-tenant
Certificat TLS PQC-ready (Secure Site Pro)DigiCertÀ partir de 995 $/an (OV, domaine unique)Le certificat marque une compatibilité post-quantique
OpenSSL 3.5 + liboqsOpen sourceGratuitPrise en charge hybride ML-KEM/ML-DSA, mais vérification des certificats composites encore limitée

Ces montants restent modestes comparés au vrai poste de coût : le projet de migration lui-même. Un rapport sectoriel 2026 sur le marché de la migration PQC en entreprise situe le budget d’une transition complète pour un grand groupe entre 15 et plus de 150 millions de dollars, étalés sur trois à cinq ans, avec la répartition suivante : 10 à 15 % pour l’inventaire et la découverte des systèmes cryptographiques, 55 à 65 % pour la refonte d’architecture et l’implémentation, 15 à 20 % pour la mise à niveau matérielle des HSM, et 8 à 12 % pour les tests et la validation. Pour une organisation de taille moyenne, ce même rapport avance une fourchette de 500 000 à 8 millions de dollars pour une migration complète, selon le nombre de certificats à traiter.

Un point rassurant : Akamai propose déjà son offre PQC (X25519MLKEM768 vers l’origine et depuis le navigateur) sans surcoût pour ses clients Ion et Dynamic Site Accelerator, disponible en accès général depuis le 31 octobre 2025. Le message des grands fournisseurs de CDN est clair : la couche transport post-quantique devient une fonctionnalité incluse, pas un supplément facturé. C’est l’application applicative et l’inventaire cryptographique interne, pas le protocole lui-même, qui représentent l’essentiel de la facture.

Calendrier réglementaire : les échéances NIST 2030 et ENISA 2035

Le calendrier n’a rien de flou. Une présentation NIST de mars 2026 fixe une date de dépréciation après 2030 et d’interdiction après 2035 pour les schémas de clé basés sur RSA (SP 800-56B) et pour les signatures RSA, ECDSA et EdDSA (FIPS 186-5). Cette échéance concerne directement les systèmes bancaires, les infrastructures PKI d’entreprise et les cartes à puce européennes qui reposent encore sur ces algorithmes.

Côté européen, la feuille de route ENISA/ECCG s’articule en trois jalons précis : plans de transition nationaux et sensibilisation achevés au 31 décembre 2026, systèmes à haut risque migrés et pilotes déployés au 31 décembre 2030, puis migration quasi complète visée pour 2035. Le rapport JRC 2026 de la Commission européenne recommande explicitement aux États membres de finaliser la migration des systèmes à haut risque avant 2030, en cohérence avec le calendrier du NIST.

PQShield, dans sa feuille de route PQC 2026 destinée aux industriels, détaille trois étapes similaires côté déploiement technique : sensibilisation et inventaire avant fin 2026, passage au « PQC par défaut » sur les cas à haut risque d’ici 2030, puis transition quasi complète d’ici 2035, avec SSH, VPN, messageries et infrastructures PKI comme premiers segments concernés. Le NISTIR 8547, document de transition publié fin 2024 et toujours cité en 2026, insiste sur une étape souvent négligée : cartographier précisément où RSA et ECC sont utilisés dans l’organisation avant même de choisir un calendrier de migration.

Adoption réelle en 2025-2026 : Cloudflare, Chrome, Akamai et OpenSSL

La théorie est une chose, le déploiement en production en est une autre. Voici cinq exemples concrets d’adoption mesurée en 2025 et 2026.

  • Cloudflare : plus de 30 % des connexions TLS 1.3 sur son réseau négocient un groupe hybride post-quantique (X25519MLKEM768) mi-2025, un taux qui dépasse 50 % en filtrant sur les navigateurs récents, selon le bilan « State of the post-quantum Internet 2025 ». Le blog « Automatically Secure » de Cloudflare annonce une mise à niveau automatique de 6 000 000 de domaines, portant à environ 43 % la part des connexions humaines protégées mi-septembre 2025.
  • Google Chrome : la version 124, sortie en avril 2024, a activé par défaut l’échange hybride post-quantique dans TLS 1.3. Google a ensuite fait migrer le point de code TLS de Kyber768+X25519 (0x6399) vers ML-KEM768+X25519 (0x11EC) pour s’aligner sur le standard final FIPS 203, documenté dans son billet de blog sécurité de septembre 2024.
  • Akamai : prise en charge du PQC vers les serveurs d’origine via HTTP/1 et HTTP/2 depuis le 30 juin 2025 (accès anticipé), avec passage en disponibilité générale au 31 octobre 2025. Le PQC entre le navigateur et Akamai a suivi en accès limité à partir du 1er septembre 2025.
  • OpenSSL 3.5 : cette version prend en charge l’échange de clés hybride ML-KEM-768 « prêt à l’emploi » via le point de code X25519MLKEM768, selon l’analyse publiée par OpenSSL Corporation en 2025. La vérification des certificats composites (par exemple MLDSA44+RSA2048) reste toutefois identifiée comme une lacune à combler.
  • Infrastructures critiques européennes : le rapport JRC de la Commission européenne cite des projets pilotes dans les secteurs bancaire et des télécommunications testant des architectures hybrides RSA/ECC + ML-KEM avant une migration à grande échelle des systèmes à haut risque prévue pour 2030.

Ce qui frappe dans ces cinq cas, c’est la convergence vers une même approche : personne ne coupe le cordon avec RSA/ECC du jour au lendemain. Tout le monde déploie l’hybride, qui garde la compatibilité descendante tout en ajoutant la protection post-quantique en couche supplémentaire. Cette convergence rassure les équipes techniques qui redoutaient une rupture brutale de compatibilité avec les millions d’appareils clients encore en circulation, des smartphones vieux de cinq ans aux automates industriels qui ne recevront jamais de mise à jour logicielle.

Cas d’usage : quand garder RSA/ECC, quand migrer vers le post-quantique

Le choix ne se résume pas à un simple « pour ou contre ». Il dépend du profil de risque, de la durée de vie des données et des contraintes matérielles. Voici six profils concrets et la recommandation qui en découle, à ajuster selon la criticité réelle de chaque système.

  • Santé et dossiers médicaux : les données doivent rester confidentielles pendant plusieurs décennies. Le risque « harvest now, decrypt later » est maximal. Migration vers l’hybride ML-KEM-768 recommandée dès maintenant, en priorité sur les flux de transmission de données patients.
  • Défense et administrations publiques : ce sont les secteurs explicitement visés par les échéances 2030 de l’ENISA pour les systèmes à haut risque. À traiter en priorité absolue, avec ML-KEM-1024 et ML-DSA-87 pour le niveau de sécurité maximal.
  • Sites web grand public à faible sensibilité : blogs, sites vitrines, contenus publics sans données personnelles sensibles. RSA/ECC reste acceptable jusqu’à l’approche de l’échéance 2030, à condition de suivre l’évolution des navigateurs, qui basculeront progressivement vers l’hybride par défaut.
  • Objets connectés et systèmes embarqués contraints : la mémoire limitée de certains microcontrôleurs rend difficile l’intégration de clés ML-KEM de plus d’un kilo-octet. Pour ces cas, ML-KEM-512 (le plus compact) ou une migration différée avec surveillance accrue du calendrier NIST sont les options réalistes.
  • Signatures de code et chaînes d’approvisionnement logicielles : la persistance des binaires signés dans le temps justifie un passage rapide à ML-DSA, dont les signatures restent vérifiables même après l’arrivée d’ordinateurs quantiques capables de casser ECDSA.
  • Applications bancaires et cartes à puce : secteur directement cité dans les projets pilotes JRC 2026. La contrainte matérielle des cartes à puce (mémoire, temps de calcul) pousse vers des schémas hybrides progressifs plutôt qu’un remplacement brutal du RSA embarqué.

Guide de migration : passer de RSA/ECC à l’hybride post-quantique

La migration ne se fait pas en un week-end. Voici les étapes recommandées par le NISTIR 8547 et reprises dans les feuilles de route sectorielles 2026. Aucune de ces étapes ne se saute : sauter l’inventaire pour foncer directement sur la configuration TLS est la façon la plus sûre de laisser un vieux serveur SSH ou une passerelle VPN oubliée exposée en RSA-1024 pendant encore dix ans.

  1. Inventaire cryptographique : cartographier chaque usage de RSA et ECC dans l’organisation (TLS, VPN, SSH, signatures de code, cartes, PKI interne). Sans cet inventaire, aucune priorisation n’est possible.
  2. Identification des systèmes « harvest-now, decrypt-later » : repérer les flux qui transportent des données devant rester confidentielles au-delà de 2030-2035.
  3. Mise à jour des bibliothèques : passer à une version d’OpenSSL supportant l’échange hybride ML-KEM (OpenSSL 3.5 ou supérieur) et à liboqs pour les tests d’intégration.
  4. Activation du mode hybride en environnement de test : configurer X25519MLKEM768 comme groupe TLS préféré, sans désactiver les groupes classiques.
  5. Tests de compatibilité client : vérifier que les anciens clients (navigateurs obsolètes, appareils embarqués) négocient toujours correctement une connexion en repli classique.
  6. Déploiement progressif en production : activer l’hybride sur un sous-ensemble de trafic, surveiller la latence de handshake et le taux d’échec de négociation.
  7. Migration des signatures et certificats : évaluer l’impact de ML-DSA sur la taille des certificats (jusqu’à 17 Ko de handshake supplémentaire en cas de bascule totale) et prioriser les chaînes de certification les plus critiques.
  8. Mise à niveau des HSM : vérifier la compatibilité ML-KEM/ML-DSA des modules matériels de sécurité existants avant d’investir dans du nouveau matériel.
  9. Documentation et agilité cryptographique : documenter l’architecture pour permettre un futur changement d’algorithme sans réécriture complète, un principe que l’ENISA place au cœur de ses recommandations.

Voici un exemple de commande pour tester la disponibilité de l’échange hybride post-quantique avec OpenSSL 3.5 ou supérieur, contre un serveur qui le prend en charge :

openssl s_client -connect exemple.fr:443 -groups X25519MLKEM768 -tls1_3

# Vérifier la version d'OpenSSL et la disponibilité de ML-KEM
openssl list -kem-algorithms | grep -i mlkem

Si la connexion aboutit et que le groupe négocié affiché est bien X25519MLKEM768, le serveur accepte déjà l’hybride post-quantique. Si la commande échoue, la mise à jour de la bibliothèque TLS doit devenir la première étape du chantier.

Avantages et inconvénients de chaque approche

RSA et ECC : avantages

  • Clés et signatures minuscules (32 à 384 octets), idéales pour les environnements contraints en mémoire.
  • Support universel depuis vingt ans, compatible avec la quasi-totalité des clients existants.
  • Aucune migration nécessaire à court terme pour les usages à faible sensibilité.
  • Écosystème d’outils, de bibliothèques et de HSM mature et bien documenté.

RSA et ECC : inconvénients

  • Vulnérables à l’algorithme de Shor sur ordinateur quantique, classés « vulnerable » par le NIST dès 2026.
  • Dépréciation officielle après 2030, interdiction après 2035 pour certains usages selon le calendrier NIST.
  • Exposés au risque « harvest now, decrypt later » pour toute donnée devant rester confidentielle après 2030.

ML-KEM/ML-DSA post-quantique : avantages

  • Résistance aux attaques par ordinateur quantique connu à ce jour.
  • Performance de calcul égale ou supérieure à ECDH sur le débit d’opérations par seconde côté serveur, selon les benchmarks Cloudflare.
  • Déploiement hybride déjà activé par défaut dans Chrome, Firefox et sur Cloudflare, sans rupture de compatibilité.
  • Standardisation définitive et stable via FIPS 203/204/205 depuis août 2024.

ML-KEM/ML-DSA post-quantique : inconvénients

  • Clés et signatures beaucoup plus volumineuses, jusqu’à 50 fois plus lourdes que ECDSA pour les signatures.
  • Surcoût de latence de handshake mesuré entre 4 % (Cloudflare, échange de clés seul) et plus de 60 % en cas de bascule totale des certificats vers ML-DSA sur des liaisons à forte latence.
  • Vérification des certificats composites encore incomplète dans certains outils, dont OpenSSL 3.5.
  • Contraintes mémoire sur les systèmes embarqués les plus anciens.

Le risque « harvest now, decrypt later » pour les entreprises européennes

Ce concept mérite qu’on s’y attarde, car il change la logique habituelle de gestion du risque en cybersécurité. D’ordinaire, une vulnérabilité s’exploite au moment où elle est découverte. Ici, l’exploitation peut survenir des années après la collecte des données chiffrées, une fois qu’un ordinateur quantique suffisamment puissant existera.

Les rapports de transition PQC cités par le NIST et la Commission européenne pointent trois secteurs particulièrement exposés en Europe : la défense, où les communications interceptées aujourd’hui garderaient une valeur stratégique dans dix ou vingt ans, la santé, où les dossiers médicaux doivent rester confidentiels sur toute la vie du patient, et la finance, où les transactions et les données patrimoniales ont une valeur d’exploitation qui ne s’éteint pas avec le temps.

Un DPO ou un RSSI français qui doit prioriser un budget de sécurité limité peut se poser une question simple pour trancher : « si ce flux chiffré était intercepté et stocké aujourd’hui, quelle serait sa valeur pour un adversaire en 2035 ? » Pour un flux de télémétrie IoT public, la réponse est proche de zéro. Pour un dossier patient, un contrat de défense ou un virement bancaire, la réponse justifie une migration hybride sans attendre l’échéance réglementaire. Cette grille de lecture, simple à appliquer, évite de traiter tous les systèmes de la même façon et concentre les efforts là où le risque « harvest now, decrypt later » pèse réellement.

C’est ce raisonnement qui justifie une migration hybride anticipée plutôt qu’une attente confortable jusqu’en 2030. Chiffrer aujourd’hui en RSA-2048 des données qui doivent rester secrètes jusqu’en 2040 revient à parier que personne ne collecte ce trafic maintenant pour le déchiffrer plus tard. Le calendrier ENISA, avec son jalon 2030 pour les systèmes à haut risque, reflète directement cette urgence.

Verdict : que choisir en 2026 ?

Les chiffres tranchent assez nettement. Pour toute nouvelle infrastructure TLS déployée en 2026, l’hybride X25519MLKEM768 s’impose : il coûte environ 4 % de latence de handshake supplémentaire selon Cloudflare, offre un débit d’opérations par seconde supérieur à X25519 seul sur les benchmarks Cloudflare et NIST/Google, et il est déjà activé par défaut dans Chrome, Firefox et sur plus de 6 millions de domaines Cloudflare. Le coût d’entrée est nul : OpenSSL 3.5 et liboqs sont gratuits, et les CDN comme Akamai l’incluent sans surcoût.

La bascule complète des signatures et certificats vers ML-DSA demande plus de prudence. L’ajout de 17 Ko de données de handshake en cas de remplacement généralisé des certificats peut faire grimper la latence de plus de 15 %, voire déclencher un aller-retour réseau supplémentaire sur les connexions à forte latence. Pour ce volet, une approche progressive, en commençant par les chaînes de certification les plus critiques (santé, défense, finance), reste la voie la plus raisonnable avant l’échéance ENISA de 2030.

RSA et ECC ne disparaissent pas du jour au lendemain, et rien n’oblige à les abandonner en 2026 pour un site vitrine à faible sensibilité. Mais pour toute donnée dont la confidentialité doit survivre au-delà de 2030, le calendrier NIST est sans ambiguïté : dépréciation après 2030, interdiction après 2035. Le verdict tient donc en une phrase : hybride post-quantique dès maintenant pour l’échange de clés, migration planifiée mais méthodique pour les signatures, avec 2030 comme échéance réaliste pour les systèmes sensibles.

Ce qui différencie vraiment ce cycle de transition cryptographique des précédents, c’est la disponibilité immédiate de l’outillage. Passer de MD5 à SHA-256, ou de SSL 3.0 à TLS 1.2, avait pris des années faute de bibliothèques prêtes. Ici, OpenSSL 3.5, liboqs, Chrome, Firefox, Cloudflare et Akamai proposent déjà des implémentations en production. Le frein n’est plus technique, il est organisationnel : inventaire incomplet, budgets non alloués, priorisation floue. Les équipes qui commencent leur cartographie cryptographique maintenant, avant l’échéance ENISA de fin 2026, arriveront à l’échéance 2030 avec une marge confortable plutôt qu’avec un chantier d’urgence.

Questions fréquentes sur RSA/ECC et la cryptographie post-quantique

RSA-2048 est-il déjà cassé par un ordinateur quantique ?

Non. Aucun ordinateur quantique actuel ne dispose de la puissance nécessaire pour exécuter l’algorithme de Shor à l’échelle de RSA-2048. Le risque est celui d’une collecte de données aujourd’hui pour un déchiffrement futur, pas d’une rupture immédiate.

Qu’est-ce que le mode hybride X25519MLKEM768 ?

C’est une combinaison qui exécute à la fois l’échange de clés classique X25519 et le post-quantique ML-KEM-768. La connexion reste protégée tant qu’au moins l’un des deux algorithmes résiste. C’est le groupe TLS recommandé par Cloudflare et activé par défaut dans Chrome et Firefox.

Faut-il migrer immédiatement vers ML-KEM et ML-DSA ?

Pour l’échange de clés en mode hybride, oui, sans attendre, car le coût est faible (environ 4 % de latence) et le bénéfice immédiat. Pour les signatures et certificats, une migration planifiée d’ici 2030 pour les systèmes à haut risque est recommandée par l’ENISA, plutôt qu’un remplacement brutal.

Quelle est la différence entre ML-KEM et ML-DSA ?

ML-KEM (FIPS 203) sert à l’échange de clés, comme X25519 ou ECDH. ML-DSA (FIPS 204) sert aux signatures numériques, comme ECDSA. Les deux reposent sur les réseaux euclidiens structurés, mais ils remplissent des fonctions différentes dans une connexion TLS.

Pourquoi les clés ML-KEM sont-elles tellement plus grosses que X25519 ?

La sécurité des réseaux euclidiens structurés repose sur des matrices et des vecteurs de grande dimension, contrairement aux courbes elliptiques qui compressent l’information dans des points de courbe très compacts. C’est un compromis mathématique inhérent à la famille d’algorithmes, pas un défaut d’implémentation.

SLH-DSA est-il utile si ML-DSA existe déjà ?

Oui, comme police d’assurance. SLH-DSA repose uniquement sur des fonctions de hachage, un fondement mathématique différent de celui de ML-DSA. Si une faille venait à être découverte dans les réseaux euclidiens structurés, SLH-DSA resterait une option de repli fiable, au prix de signatures plus lourdes.

Les cartes bancaires européennes vont-elles passer au post-quantique ?

Des projets pilotes existent déjà dans le secteur bancaire européen selon le rapport JRC 2026, mais la contrainte de mémoire des puces de carte à puce complique l’intégration de clés ML-KEM ou de signatures ML-DSA volumineuses. Une transition progressive, probablement via des schémas hybrides allégés, est l’approche la plus probable avant 2030.

Le passage au post-quantique coûte-t-il cher pour une PME ?

Le protocole lui-même est gratuit : OpenSSL et les CDN comme Akamai incluent déjà l’hybride sans frais. Le coût principal vient de l’audit interne et de l’inventaire cryptographique, estimé entre 500 000 et 8 millions de dollars pour une migration complète d’une organisation de taille moyenne selon les rapports sectoriels 2026, un montant qui varie fortement selon le nombre de certificats et de systèmes à traiter.