Le 11 mars 2025, le NIST a tranché un débat qui agitait les cryptographes depuis des années : fallait-il un deuxième mécanisme d’échange de clés post-quantique, au cas où le premier tomberait ? La réponse a été oui, avec la sélection de HQC (Hamming Quasi-Cyclic) comme cinquième algorithme post-quantique standardisé, et surtout comme filet de sécurité pour ML-KEM, déjà normalisé sous la référence FIPS 203. Dix-huit mois plus tard, alors que l’ANSSI et l’ENISA poussent les entreprises européennes à migrer avant l’échéance de 2027, la question posée par les équipes techniques n’est plus de savoir s’il faut passer au post-quantique, mais quel algorithme utiliser, et quand ajouter le deuxième.

Ce comparatif détaille les différences techniques entre HQC et ML-KEM, leurs performances mesurées, leur calendrier de normalisation et les cas où chacun s’impose. Objectif : donner aux équipes sécurité et infrastructure de quoi arbitrer sans attendre la publication finale du FIPS HQC, prévue courant 2027.

Ce choix concerne directement les équipes françaises et européennes qui pilotent des projets de conformité NIS2, DORA ou des référentiels de certification ANSSI. Contrairement à un simple changement de version logicielle, la migration vers un chiffrement post-quantique touche toute la chaîne : bibliothèques cryptographiques, équipements réseau, terminaux clients, et parfois même le matériel dédié comme les modules de sécurité matériels (HSM). Comprendre où se situe chaque algorithme dans le calendrier du NIST évite de se lancer trop tôt sur un standard encore mouvant, ou trop tard face à des obligations réglementaires qui se rapprochent.

ML-KEM et HQC : deux familles mathématiques, un même objectif

ML-KEM (Module-Lattice Key Encapsulation Mechanism), dérivé de CRYSTALS-Kyber, repose sur la difficulté supposée de résoudre certains problèmes sur les réseaux euclidiens (lattices). C’est l’algorithme que le NIST recommande en priorité pour l’échange de clés post-quantique depuis la publication du FIPS 203 en août 2024. Il équipe déjà TLS 1.3 chez plusieurs grands fournisseurs cloud et CDN, et sert de base à la plupart des déploiements pilotes menés en France et en Allemagne depuis 2025.

HQC prend le problème sous un angle totalement différent : c’est un schéma basé sur les codes correcteurs d’erreurs, avec une structure quasi-cyclique de Hamming. Cette différence n’est pas cosmétique. Si une faiblesse structurelle venait à être découverte dans les hypothèses latticielles qui sous-tendent ML-KEM, un scénario que personne ne peut exclure avec certitude sur un horizon de dix ou vingt ans, HQC resterait a priori intact puisqu’il ne partage aucune des mêmes fondations mathématiques. C’est précisément cette logique de diversification des hypothèses de sécurité qui a poussé le NIST à retenir un second mécanisme plutôt que de s’appuyer sur un seul cheval.

Le NIST a été clair sur la hiérarchie : HQC n’est pas un concurrent de ML-KEM, c’est une police d’assurance. Dans son communiqué de sélection, l’agence américaine présente HQC comme un algorithme de secours, destiné à prendre le relais uniquement en cas de défaillance avérée de ML-KEM, et non comme un remplacement à déployer en parallèle par défaut. Cette distinction change radicalement l’approche de migration : la plupart des organisations n’ont aucune urgence à implémenter HQC en production tant que ML-KEM tient la route.

Pourquoi le NIST a voulu deux familles mathématiques différentes

Cette insistance sur la diversification n’est pas théorique, elle vient d’un précédent douloureux. En 2022, SIKE, un candidat post-quantique arrivé jusqu’au quatrième tour du concours NIST, a été cassé en quelques heures de calcul sur un simple ordinateur portable par une équipe de chercheurs belges. La même année, Rainbow, un candidat pour les signatures, a lui aussi été fragilisé par une attaque algébrique. Ces deux épisodes ont rappelé une évidence que les cryptographes connaissaient déjà, mais que le grand public découvrait : un algorithme jugé solide après plusieurs années d’examen public peut malgré tout tomber, parfois brutalement.

Le concours de normalisation post-quantique du NIST a démarré en 2016 avec 82 propositions initiales. Il en restait 7 finalistes et 8 alternatifs au troisième tour en 2020, puis 4 candidats retenus pour la standardisation initiale en juillet 2022 (Kyber, Dilithium, Falcon, SPHINCS+), et un quatrième tour consacré spécifiquement à la recherche d’un second mécanisme d’échange de clés, avec BIKE, Classic McEliece, HQC et SIKE en lice. SIKE a été éliminé en cours de route après sa cassure. Classic McEliece, malgré des clés publiques énormes (plus de 250 000 octets), reste étudié pour des cas de niche, mais sa marge de sécurité a été revue à la baisse par des travaux publiés en 2026. HQC est sorti vainqueur de ce quatrième tour le 11 mars 2025, précisément parce qu’il repose sur des codes correcteurs d’erreurs, une famille mathématique étudiée depuis les années 1970 et qui n’a aucun lien structurel avec les réseaux euclidiens de ML-KEM.

C’est cette leçon tirée de la cassure de SIKE qui explique pourquoi le NIST a refusé de mettre tous ses œufs dans le même panier latticiel. ML-KEM, ML-DSA et FN-DSA partagent tous les trois une base mathématique voisine. Si un jour une avancée en cryptanalyse des réseaux euclidiens venait fragiliser l’un, elle menacerait probablement les deux autres en même temps. HQC, en s’appuyant sur les codes correcteurs, casse cette dépendance et donne aux architectes sécurité une vraie option de repli plutôt qu’une simple variante du même risque.

Le calendrier de normalisation, algorithme par algorithme

Comprendre où en est chaque algorithme dans le pipeline NIST est essentiel avant de planifier une migration. Le tableau ci-dessous récapitule l’état de la suite post-quantique complète au 7 septembre 2026.

AlgorithmeRéférence FIPSTypeFondement mathématiqueStatut (sept. 2026)Taille clé publiqueTaille du chiffré/signatureUsage recommandé
ML-KEM-512FIPS 203KEMRéseaux euclidiens (lattices)Final, publié août 2024800 octets768 octetsNiveau de sécurité équivalent AES-128
ML-KEM-768FIPS 203KEMRéseaux euclidiens (lattices)Final, publié août 20241 184 octets1 088 octetsRecommandé par défaut (TLS, VPN)
ML-KEM-1024FIPS 203KEMRéseaux euclidiens (lattices)Final, publié août 20241 568 octets1 568 octetsSécurité maximale, données longue durée
HQC-128FIPS en projetKEMCodes correcteurs (quasi-cyclique)Draft attendu 2026, final visé 2027~2 250 octets~4 500 octetsFilet de secours, pas de prod isolée
HQC-192FIPS en projetKEMCodes correcteurs (quasi-cyclique)Draft attendu 2026, final visé 2027~4 500 octets~9 000 octetsFilet de secours renforcé
ML-DSA (Dilithium)FIPS 204SignatureRéseaux euclidiens (lattices)Final, publié août 20241 312 à 2 592 octets2 420 à 4 595 octetsSignatures générales
SLH-DSA (SPHINCS+)FIPS 205SignatureFonctions de hachageFinal, publié août 202432 à 64 octets7 856 à 49 856 octetsCas critiques longue durée de vie
FN-DSA (Falcon)FIPS 206 (draft)SignatureRéseaux euclidiens (NTRU)Draft, finalisation fin 2026/début 2027897 à 1 793 octets~666 à 1 280 octetsEnvironnements contraints (IoT, cartes à puce)
BIKENon retenu par le NISTKEMCodes correcteurs (QC-MDPC)Écarté après le 4e round~3 100 octets~5 900 octets (pk+ct)Abandonné au profit de HQC
Classic McElieceToujours en évaluationKEMCodes correcteurs de GoppaSécurité fragilisée en 2026~261 000 octets~261 000 octets (pk+ct)Cas de niche, clés très volumineuses

Ce qui saute aux yeux dans ce tableau, c’est l’écart de volumétrie entre les deux KEM. HQC produit des clés et des chiffrés environ trois à six fois plus volumineux que ML-KEM pour un niveau de sécurité comparable. Sur une poignée de main TLS isolée, la différence est négligeable. À l’échelle d’un CDN qui traite des dizaines de milliards de connexions par jour, elle pèse en bande passante et en latence, ce qui explique pourquoi HQC reste cantonné à un rôle de secours plutôt que de standard par défaut.

Benchmarks : ce que mesurent les implémentations actuelles

Les chiffres de performance bruts varient selon le matériel, le compilateur et le jeu d’instructions disponible (AVX2, AVX-512, NEON), donc toute comparaison doit être lue avec cette réserve. Plusieurs éditeurs de bibliothèques cryptographiques, dont wolfSSL, ont publié des benchmarks comparatifs entre ML-KEM et HQC sur leur implémentation wolfCrypt, disponibles sur leur blog technique. La tendance qui ressort, confirmée par les analyses indépendantes de la suite PQC du NIST, est constante : ML-KEM génère des clés et effectue l’encapsulation/décapsulation plus rapidement que HQC, avec un facteur qui va de 2x à plus de 10x selon l’opération et le niveau de sécurité choisi.

La raison tient à la nature même des opérations. ML-KEM manipule des polynômes sur des réseaux structurés avec des transformées qui se prêtent bien à la vectorisation SIMD moderne. HQC repose sur du décodage de codes correcteurs, une opération plus coûteuse en cycles CPU, notamment côté décapsulation où l’algorithme doit corriger les erreurs introduites par le chiffrement. C’est un classique compromis cryptographique : la diversité des hypothèses de sécurité a un coût en performance et en taille des données échangées.

Sur le terrain des signatures, la comparaison entre Kyber et Dilithium avait déjà montré des arbitrages similaires entre taille de clé et vitesse de vérification. Le même exercice, appliqué cette fois à la paire ML-KEM/HQC, confirme que le NIST n’a jamais cherché l’algorithme parfait, mais un portefeuille équilibré entre rapidité et redondance des hypothèses mathématiques.

Deux autres sources donnent des chiffres précis et convergents. Un article académique comparant une implémentation HQC optimisée AVX2 à ML-KEM standard mesure entre 505 et 1 020 opérations par seconde pour HQC selon le niveau de sécurité, contre 9 090 à 12 500 opérations par seconde pour ML-KEM sur le même matériel, soit un écart de 9 à près de 25 fois en faveur de ML-KEM. Le blog technique de Cloudflare consacré aux protocoles post-quantiques confirme la tendance sur un autre angle : sur sa table de comparaison des KEM candidats aux round successifs du NIST, Kyber512 pèse 1 632 octets en cumulant clé publique et chiffré, avec une vitesse classée en tête de sa grille, contre 6 730 octets pour HQC, classé un cran en dessous. Un registre indépendant d’algorithmes post-quantiques, qui reprend des mesures effectuées sur un processeur Intel Core i7-11850H avec l’implémentation AVX2 de liboqs, relève des temps de décapsulation de 141 microsecondes pour HQC-128 contre des temps nettement inférieurs pour ML-KEM au même niveau de sécurité. Trois sources indépendantes, trois méthodologies différentes, un seul verdict chiffré : ML-KEM l’emporte largement en vitesse brute.

Cinq déploiements réels de ML-KEM déjà en production

La théorie des benchmarks est une chose, l’adoption industrielle en est une autre. Voici cinq déploiements concrets et documentés qui montrent où en est réellement ML-KEM sur le terrain en 2026. HQC, à l’inverse, ne figure encore dans aucun de ces déploiements de production à grande échelle, précisément parce que sa norme n’est pas finalisée.

Cloudflare a été l’un des tout premiers à bouger, avec une version préliminaire de Kyber déployée dès 2022 pour protéger le trafic vers ses propres serveurs. Le déploiement en sortie vers les serveurs d’origine des clients (X25519Kyber768Draft00) a atteint 100 % des comptes Entreprise en mars 2024, avant la bascule vers le hybride standardisé X25519ML-KEM-768 après la publication du FIPS 203.

Google Chrome a basculé son point de code TLS hybride de Kyber768+X25519 (draft, 0x6399) vers ML-KEM768+X25519 (standard, 0x11EC). Selon le blog sécurité de Google, ce changement s’est généralisé avec la version 131 de Chrome, sortie le 6 novembre 2024, rendant l’échange de clés post-quantique actif par défaut pour l’essentiel du trafic web mondial passant par ce navigateur.

Apple a intégré ML-KEM-1024 (sous l’appellation Kyber-1024) dans son protocole PQ3 pour iMessage, en hybride avec Curve25519. Le déploiement a démarré avec iOS 17.4, iPadOS 17.4 et macOS 14.4 en mars 2024. Apple présente ce protocole comme le premier système de messagerie chiffrée de bout en bout à grande échelle à intégrer un KEM post-quantique normalisé par le NIST.

Amazon Web Services a étendu le support ML-KEM à plusieurs services entre 2025 et 2026 : AWS KMS, AWS Certificate Manager et Secrets Manager supportent l’échange de clés hybride post-quantique via ML-KEM sur l’ensemble des régions AWS, selon la page dédiée d’AWS. Amazon S3 a activé le support ML-KEM pour ses points de terminaison TLS en novembre 2025, suivi par les Network et Application Load Balancers le même mois.

Le projet Open Quantum Safe (liboqs), utilisé comme brique de base par une grande partie de l’écosystème pour prototyper et benchmarker le post-quantique, a publié sa version 0.14.0 avec une implémentation stable et optimisée de ML-KEM (AVX2 et AArch64). HQC y est également disponible, mais reste désactivé par défaut le temps que sa spécification se stabilise, ce qui illustre bien l’écart de maturité entre les deux algorithmes.

Tableau de synthèse : HQC contre ML-KEM en dix critères

CritèreML-KEM (FIPS 203)HQC (FIPS en projet)
Date de sélection NISTJuillet 2022 (round 3)11 mars 2025 (round 4)
Statut de normalisationFinal, publiéDraft attendu en 2026, final visé 2027
Fondement mathématiqueRéseaux euclidiens (module-lattices)Codes correcteurs quasi-cycliques
Rôle recommandé par le NISTStandard principalFilet de secours (assurance en cas de faille)
Taille des clés publiques800 à 1 568 octets~2 250 à 4 500 octets
Vitesse d’encapsulationRéférence (rapide)2x à 10x plus lent selon l’implémentation
Support TLS 1.3 actuelOui, déployé chez plusieurs CDN et cloudsNon, encore expérimental
Diversité des hypothèsesPartagée avec ML-DSA et FN-DSA (lattices)Indépendante des lattices
Maturité des bibliothèquesÉlevée (OpenSSL, BoringSSL, wolfCrypt, liboqs)Émergente (liboqs, wolfCrypt en test)
Recommandation pour la production 2026Oui, prioritaireNon, à surveiller

Coût d’implémentation : ce que la migration change pour l’infrastructure

Contrairement à un changement de fournisseur cloud, la migration post-quantique n’a pas de tarif catalogue. Le coût réel se répartit entre trois postes : l’audit cryptographique de l’existant, la mise à jour des bibliothèques et des équipements matériels, et la charge de calcul supplémentaire en production. Le tableau suivant donne un ordre de grandeur des coûts indirects associés à chaque scénario de déploiement, basé sur des retours de migration publiés par des fournisseurs de cryptographie post-quantique et des cabinets de conseil en 2026.

ScénarioEffort d’intégrationSurcoût CPU estiméSurcoût bande passanteHorizon réaliste
ML-KEM-768 seul (remplacement RSA/ECDH)Modéré : mise à jour de la pile TLS+5 à 15 % par poignée de main+1 à 2 Ko par connexionDéployable dès maintenant
ML-KEM + RSA en mode hybrideModéré à élevé : double calcul+15 à 25 %+2 à 3 Ko par connexionRecommandé en transition 2025-2027
ML-KEM + HQC en double KEMÉlevé : deux implémentations à maintenir+40 à 60 %+6 à 10 Ko par connexionRéservé aux cas à très haut risque
Statu quo (RSA/ECDH classique)Nul à court termeRéférenceRéférenceNon conforme aux échéances ANSSI/ENISA 2027-2030

Ce dernier scénario mérite d’être souligné : rester sur RSA ou ECDH sans plan de migration n’est plus une option neutre. L’ANSSI a fixé des jalons de certification qui rendent le post-quantique obligatoire pour certains produits dès 2027, avec une bascule complète attendue d’ici 2030, comme détaillé dans notre article sur l’obligation post-quantique de l’ANSSI. Le statu quo a donc un coût caché, celui de la non-conformité, qui dépasse largement le surcoût de calcul d’une migration vers ML-KEM.

Le scénario du double KEM mérite une explication plus fine. Maintenir deux implémentations cryptographiques en parallèle ne double pas seulement le calcul, il double aussi la surface d’audit de sécurité, la charge de tests de non-régression, et le nombre de bibliothèques à surveiller pour les correctifs. Une équipe sécurité qui choisit cette voie pour ses données les plus critiques doit budgéter un effort d’ingénierie récurrent, pas seulement un coût de migration ponctuel. C’est pour cette raison que la plupart des guides de migration publiés en 2026 recommandent de réserver le double KEM aux données dont la durée de confidentialité dépasse clairement l’horizon de vingt à trente ans, et non de le généraliser par précaution excessive.

Cinq cas d’usage concrets et l’algorithme à privilégier

1. Terminaison TLS sur un CDN ou un reverse proxy à fort trafic. ML-KEM-768 en mode hybride avec X25519 est le choix quasi unanime. La taille réduite des clés limite l’impact sur la latence de la poignée de main, un critère décisif quand on traite des dizaines de milliers de requêtes par seconde. HQC serait ici contre-productif : son overhead en bande passante se répercuterait sur chaque connexion.

2. VPN d’entreprise et accès distant. Les fournisseurs de VPN qui ont commencé à intégrer le post-quantique en 2025-2026 misent également sur ML-KEM, pour les mêmes raisons de performance. Le volume de connexions simultanées justifie de privilégier la rapidité, tant que HQC n’est pas finalisé.

3. Archivage de documents à très longue durée de conservation (notariat, santé, défense). C’est le cas d’usage où HQC prend tout son sens, en complément de ML-KEM. Un document chiffré aujourd’hui pour rester confidentiel pendant trente ou quarante ans doit résister à une attaque de type “collecter maintenant, déchiffrer plus tard” menée avec un futur ordinateur quantique, mais aussi à l’hypothèse, certes improbable mais pas nulle, d’une faille future dans les réseaux euclidiens. Un chiffrement en double couche ML-KEM + HQC répond directement à ce scénario, au prix d’un stockage plus volumineux.

4. Infrastructures bancaires et interbancaires. Les tests menés par plusieurs banques sur la signature ML-DSA-65 montrent une approche similaire pour le chiffrement : ML-KEM en production, HQC en veille technologique pour les échanges les plus sensibles (compensation, règlement-livraison), en attendant sa finalisation FIPS.

5. Objets connectés et environnements contraints. Ni ML-KEM ni HQC ne sont réellement optimaux ici à cause de la taille des clés et du calcul embarqué. Les équipes qui travaillent sur l’IoT post-quantique regardent plutôt du côté de FN-DSA pour les signatures, en réservant HQC et ML-KEM aux passerelles et serveurs, pas aux capteurs eux-mêmes. Un microcontrôleur alimenté par batterie qui doit tenir plusieurs années sur le terrain ne peut pas se permettre les 4 500 octets d’un chiffré HQC-128 à chaque échange, ni le calcul de décodage associé, sous peine de vider sa batterie bien plus vite que prévu.

6. Opérateurs télécoms et infrastructures 5G/6G. Les cœurs de réseau mobiles traitent des volumes de signalisation chiffrée considérables entre stations de base et fonctions réseau. Là encore, la légèreté de ML-KEM en fait le candidat naturel pour les protocoles de contrôle, HQC restant réservé aux liens de gestion les plus sensibles où la bande passante compte moins que la résilience cryptographique à très long terme.

Guide de migration : passer à ML-KEM en gardant HQC en réserve

La migration recommandée par la plupart des guides publiés en 2026 suit un principe simple : déployer ML-KEM maintenant, préparer HQC sans le mettre en production tant que son FIPS n’est pas final. Le tutoriel ML-KEM en 12 étapes détaille l’implémentation technique ; voici les grandes étapes de la démarche de migration côté organisation.

  • Faire l’inventaire cryptographique de tous les systèmes utilisant RSA, ECDH ou ECDSA pour l’échange de clés, en priorisant les données à durée de vie longue.
  • Mettre à jour les bibliothèques TLS vers des versions supportant ML-KEM en mode hybride (par exemple X25519MLKEM768), disponible dans OpenSSL 3.2+ et les principales piles serveur.
  • Tester la compatibilité des équipements réseau intermédiaires (load balancers, WAF, pare-feux) qui peuvent rejeter les paquets TLS plus volumineux liés aux clés post-quantiques.
  • Déployer ML-KEM-768 en hybride avec l’algorithme classique existant sur les environnements de test, puis mesurer l’impact réel sur la latence et le CPU.
  • Étendre progressivement à la production, en commençant par les services internes avant les services exposés au public.
  • Pour les données à conservation longue (archives, notariat, secret défense), évaluer un chiffrement en couche supplémentaire avec HQC dès que son implémentation liboqs ou wolfCrypt atteint un niveau de stabilité jugé suffisant par l’équipe sécurité.
  • Suivre la publication du draft FIPS HQC attendue en 2026 pour ajuster le calendrier de bascule complète.
  • Documenter la stratégie de crypto-agilité pour pouvoir basculer rapidement entre ML-KEM et HQC si une faille était découverte sur l’un des deux.

Un point de vigilance revient dans presque tous les retours d’expérience de 2025-2026 : le mode hybride (algorithme classique + post-quantique combiné) reste la norme de transition. Personne ne recommande de couper immédiatement RSA ou ECDH, précisément parce que ML-KEM et HQC, bien que solides sur le papier, n’ont pas encore le recul de plusieurs décennies d’analyse cryptographique dont bénéficient RSA et les courbes elliptiques. Notre comparatif RSA/ECC contre post-quantique détaille cette phase de transition.

Un dernier point technique mérite d’être anticipé avant le déploiement : la gestion des certificats. Une autorité de certification qui délivre déjà des certificats compatibles ML-DSA pour la signature peut être combinée à un échange de clés ML-KEM sans dépendance directe entre les deux, puisque signature et échange de clés sont deux fonctions distinctes dans TLS. En revanche, les équipes doivent vérifier que leur chaîne d’outils de gestion de certificats (émission, révocation, rotation automatique) supporte déjà les tailles de clés post-quantiques, qui restent sensiblement plus grandes que celles utilisées avec ECDSA.

Avantages et inconvénients de chaque algorithme

ML-KEM : les points forts

  • Norme finale publiée depuis août 2024, donc juridiquement et techniquement stable pour la production.
  • Clés et chiffrés compacts, adaptés au trafic à très fort volume.
  • Support déjà mature dans OpenSSL, BoringSSL, wolfCrypt et liboqs.
  • Déploiements réels en cours chez plusieurs grands CDN et fournisseurs cloud depuis 2025.

ML-KEM : les limites

  • Repose entièrement sur les réseaux euclidiens : en cas de percée cryptanalytique sur cette famille de problèmes, ML-KEM et ML-DSA tomberaient probablement ensemble.
  • Aucune diversité d’hypothèses si utilisé seul, d’où la recommandation NIST d’anticiper un plan B.

HQC : les points forts

  • Fondement mathématique totalement distinct de ML-KEM, ce qui apporte une vraie redondance de sécurité.
  • Choix validé par un processus NIST de plusieurs années, avec un examen public poussé pendant le quatrième round.
  • Pertinent pour les données dont la confidentialité doit tenir plusieurs décennies.

HQC : les limites

  • Norme finale non publiée : le draft FIPS n’est attendu qu’en 2026, la version finale vers 2027.
  • Clés et chiffrés nettement plus volumineux, avec un impact réel sur la bande passante à grande échelle.
  • Performances de calcul inférieures à ML-KEM sur la plupart des benchmarks publiés à ce jour.
  • Écosystème logiciel encore jeune, avec peu de déploiements en production réelle en 2026.

Ce que ça change concrètement dans la configuration serveur

Pour une équipe infrastructure, la bascule vers ML-KEM en mode hybride se traduit d’abord par une ligne de configuration TLS. Avec une version récente d’OpenSSL (3.2 ou supérieure) ou de BoringSSL, il suffit de déclarer le groupe hybride dans la liste des courbes/groupes acceptés côté serveur. Un exemple typique pour un serveur Nginx compilé avec un OpenSSL récent ressemble à ceci :

ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1;
ssl_prefer_server_ciphers off;

Le groupe X25519MLKEM768 place ML-KEM-768 en tête de liste, avec repli automatique sur X25519 classique si le client ne le supporte pas encore. C’est exactement le mode hybride recommandé pendant toute la période de transition. Ajouter HQC à cette liste aujourd’hui n’aurait aucun sens : aucun navigateur ni aucune bibliothèque cliente grand public ne le négocie en dehors de tests expérimentaux, et son code de groupe TLS n’est pas encore stabilisé par l’IETF.

Le vrai travail ne se limite pas à changer une ligne de configuration. Il faut aussi vérifier que les équipements intermédiaires (WAF, load balancers matériels, proxys d’inspection TLS) acceptent des paquets ClientHello plus volumineux : un ClientHello classique pèse quelques centaines d’octets, un ClientHello avec ML-KEM-768 peut dépasser 1,5 Ko, et un ClientHello combinant ML-KEM et HQC franchirait largement les 5 Ko. Plusieurs retours d’expérience publiés en 2025 par des équipes ayant déployé le hybride en interne signalent des rejets silencieux de connexion sur des boîtiers réseau anciens qui appliquent des limites de taille de paquet héritées de l’époque pré-TLS 1.3.

Ce que disent les textes réglementaires européens

Le calendrier réglementaire européen s’est nettement précisé en 2026. Un document de l’ENISA sur la feuille de route de transition vers la cryptographie post-quantique fixe une échéance au 31 décembre 2026 : chaque État membre doit avoir établi sa propre feuille de route nationale, avec une planification déjà engagée pour les cas d’usage à risque élevé et moyen. La France, via l’ANSSI, a intégré cette logique dans ses référentiels de certification, avec une bascule vers l’obligation post-quantique dès 2027 pour certains produits qualifiés, et un objectif de couverture complète d’ici 2030, un calendrier proche de celui déjà couvert dans notre suivi de l’alerte du G7 sur le post-quantique.

Un projet de texte européen sur la certification cybersécurité, publié en mai 2026, va plus loin en fixant des exigences techniques précises : dans les contextes utilisant des mécanismes post-quantiques, l’entropie minimale des graines cryptographiques (seeds) devrait atteindre au moins 188 bits. Cette exigence touche directement la manière dont ML-KEM et HQC génèrent leurs clés, et oblige les éditeurs de bibliothèques cryptographiques à revoir leurs générateurs aléatoires en conséquence.

Cette pression réglementaire explique pourquoi le sujet dépasse largement le cercle des cryptographes. Les directions conformité et les RSSI des grandes entreprises françaises et européennes doivent désormais présenter un calendrier de migration crédible, avec ML-KEM comme socle et HQC comme option documentée pour les cas les plus sensibles.

Les secteurs les plus exposés à cette pression sont sans surprise ceux qui manipulent déjà des données à durée de vie longue ou soumises à une régulation stricte : la banque et l’assurance, l’énergie, la santé et les administrations publiques. Ces secteurs recoupent largement le périmètre de la directive NIS2, qui impose déjà une gestion documentée des risques cyber à des milliers d’entités en France. Un audit cryptographique post-quantique devient, de fait, une pièce du dossier de conformité NIS2 pour ces organisations, même si le texte européen ne cite pas nommément ML-KEM ou HQC.

Verdict : lequel choisir en 2026 ?

Sur la base des données disponibles au 7 septembre 2026, le choix n’a rien d’un match nul. Pour l’immense majorité des cas, ML-KEM-768 en mode hybride est la réponse : norme finalisée depuis 2024, performances éprouvées, support logiciel large, et c’est aussi la recommandation explicite du NIST pour un déploiement immédiat. HQC ne doit pas être écarté pour autant : c’est l’assurance que prennent les organisations qui protègent des données devant rester confidentielles au-delà de 2040, ou celles qui veulent une architecture cryptographique capable d’encaisser une mauvaise surprise sur les réseaux euclidiens sans tout reconstruire dans l’urgence.

La bonne question à se poser n’est donc pas de choisir entre HQC et ML-KEM, mais de déterminer quand ajouter HQC à côté de ML-KEM. Pour la grande majorité des systèmes en production aujourd’hui, la réponse est : pas encore, mais en gardant un œil sur la publication du FIPS HQC attendue en 2026-2027, et en documentant dès maintenant la stratégie de crypto-agilité qui permettra de l’activer rapidement le moment venu. Voir aussi le comparatif de Cloudflare sur le déploiement post-quantique à grande échelle pour une vision côté infrastructure réseau.

En résumé chiffré : ML-KEM tourne de 9 à 25 fois plus vite que HQC selon les benchmarks académiques les plus récents, produit des clés 3 à 4 fois plus compactes, et équipe déjà Cloudflare, Chrome, Apple iMessage et plusieurs services AWS en production. HQC, sélectionné en mars 2025, n’atteindra son statut FIPS final qu’en 2027, et son rôle assumé par le NIST lui-même reste celui d’une doublure, pas d’un premier choix. Pour une équipe qui doit arbitrer aujourd’hui entre les deux, ces chiffres suffisent à trancher : ML-KEM d’abord, HQC en réserve documentée.

Questions fréquentes

ML-KEM et HQC peuvent-ils être utilisés ensemble ?

Oui, et c’est précisément l’architecture recommandée pour les données les plus sensibles : un chiffrement en couche combinant ML-KEM et HQC garantit que la compromission d’une seule des deux familles mathématiques ne suffit pas à casser la protection globale. Le coût est un surcroît de calcul et de bande passante, ce qui limite cette combinaison aux cas à très haut risque.

Pourquoi HQC n’est-il pas encore utilisable en production ?

Parce que sa norme FIPS n’est pas finalisée. Le NIST a sélectionné l’algorithme le 11 mars 2025, mais un draft de standard n’est attendu qu’en 2026, avec une publication finale visée pour 2027. Déployer un algorithme avant sa normalisation finale expose à des changements de paramètres susceptibles de casser la compatibilité.

ML-KEM est-il vraiment plus rapide que HQC ?

Sur la quasi-totalité des benchmarks publiés par les éditeurs de bibliothèques cryptographiques, oui, notamment sur les opérations d’encapsulation et de décapsulation. L’écart s’explique par la nature des calculs : les opérations sur réseaux euclidiens de ML-KEM se vectorisent plus efficacement sur les processeurs modernes que le décodage de codes correcteurs utilisé par HQC.

Que devient RSA face à ML-KEM et HQC ?

RSA reste utilisé en mode hybride pendant la période de transition, combiné à ML-KEM pour ne pas dépendre entièrement d’un algorithme post-quantique récent. À terme, les échéances fixées par l’ANSSI et l’ENISA prévoient une sortie progressive de RSA seul pour l’échange de clés, au profit de combinaisons hybrides puis d’un post-quantique pur.

Quel est l’impact de HQC sur la taille des paquets réseau ?

Significatif à grande échelle. Les clés publiques et les textes chiffrés de HQC sont environ trois à six fois plus volumineux que ceux de ML-KEM pour un niveau de sécurité équivalent, ce qui peut représenter plusieurs kilooctets supplémentaires par connexion TLS. Sur un service à fort trafic, cela se traduit par une charge réseau et une latence mesurables.

Les entreprises françaises sont-elles obligées de migrer ?

Cela dépend du secteur et du niveau de certification visé. L’ANSSI a fixé des jalons rendant le post-quantique obligatoire pour certains produits qualifiés dès 2027, avec un objectif de généralisation d’ici 2030. Les entités soumises à NIS2 ou opérant dans des secteurs critiques ont donc un intérêt direct à documenter leur plan de migration dès maintenant, même si le déploiement complet peut s’étaler sur plusieurs années.

FN-DSA et SLH-DSA entrent-ils dans cette comparaison ?

Non directement : ce sont des algorithmes de signature, pas d’échange de clés, donc ils répondent à un besoin différent de ML-KEM et HQC. ML-DSA (Dilithium) et SLH-DSA (SPHINCS+) sont déjà finalisés depuis août 2024, tandis que FN-DSA (Falcon) est encore en draft, avec une finalisation attendue fin 2026 ou début 2027, un calendrier proche de celui de HQC.