Ressources Post-quantique · juillet 2026

La préparation post-quantique pour TLS consiste principalement en un travail d’inventaire

La cryptographie post-quantique n’est plus un simple sujet de recherche, mais la migration de TLS ne se résume pas au remplacement des certificats. Pour la plupart des équipes d’infrastructure, le travail utile consiste aujourd’hui à recenser les usages de cryptographie à clé publique vulnérables aux attaques quantiques, leurs responsables et les systèmes qui peuvent évoluer sans rompre la compatibilité avec les clients.

Ce qui est réellement standardisé

Le NIST a finalisé les trois premières normes de cryptographie post-quantique en août 2024. Les noms sont importants car ils décrivent des tâches différentes. ML-KEM est destiné à l’établissement de clés. ML-DSA et SLH-DSA sont destinés aux signatures numériques. Ils ne sont pas interchangeables.

Le sujet concerne surtout la cryptographie asymétrique : RSA, DSA, ECDSA, EdDSA, DH sur corps fini et ECDH. Le chiffrement symétrique et les fonctions de hachage ne sont pas affectés de la même façon. Un plan de préparation TLS ne doit donc pas présenter chaque suite cryptographique ou chaque fonction de hachage comme également compromise.

Pour les acheteurs européens, il s’agit aussi de plus en plus d’un sujet de gouvernance et de planification. La feuille de route coordonnée par l’UE présente la PQC comme une transition à préparer dans l’ensemble des États membres et avec les parties prenantes, et non comme un changement de produit isolé.

Algorithme Norme Rôle Note opérationnelle

ML-KEM FIPS 203 Établissement des clés La famille d’algorithmes la plus directement concernée par les travaux sur l’échange de clés TLS.

ML-DSA FIPS 204 Signatures numériques Concerne les futurs mécanismes de signature des certificats et des logiciels.

SLH-DSA FIPS 205 Signatures numériques Une norme de signature basée sur le hachage destinée à fournir une diversité d’algorithmes.

TLS présente deux axes de migration distincts

Les équipes TLS doivent distinguer l’établissement des clés de l’authentification par certificat. Confondre les deux mène rapidement à un plan de préparation convaincant en apparence, mais impossible à exécuter.

Établissement des clés

Il s’agit de la partie de la négociation TLS qui crée les secrets de session. La voie hybride ECDHE-MLKEM est plus avancée à l’IETF que les groupes nommés ML-KEM autonomes, mais les deux dépendent encore de la prise en charge par le client, le serveur, les bibliothèques et les règles applicables.

Authentification par certificat

Il s’agit de la chaîne de certificats X.509 utilisée pour authentifier le serveur. Des RFC existent pour les identifiants ML-DSA, SLH-DSA et ML-KEM dans X.509, mais ce n’est pas la même chose que la prise en charge en production des certificats de serveur TLS de confiance publique.

Le risque réel n’est pas le même pour chaque système

À court terme, une raison importante de préparer la transition vers la PQC est le risque « collecter maintenant, déchiffrer plus tard » : un attaquant peut enregistrer aujourd’hui du trafic chiffré et tenter de le déchiffrer ultérieurement si un ordinateur quantique pertinent pour la cryptanalyse devient disponible. Ce risque est particulièrement important lorsque les données doivent rester confidentielles pendant des années.

Un site web marketing, une interface d’administration interne, un portail de paie et un point de terminaison d’export de données clients n’ont pas la même durée de confidentialité. Traiter tous les points de terminaison TLS comme aussi urgents les uns que les autres n’est pas un modèle de risque ; c’est une file d’attente impossible à hiérarchiser.

La migration des signatures de certificats présente un risque différent. Elle concerne l’authentification future, les chaînes de confiance, les règles des programmes racines, le comportement de Certificate Transparency et la compatibilité des clients. Elle ne permet pas de déchiffrer un trafic déjà enregistré.

Ce que les équipes peuvent faire dès maintenant

Inventoriez les endroits où RSA, ECDSA, EdDSA, DH sur corps fini et ECDH apparaissent dans les certificats, les points de terminaison TLS, les équipements, les répartiteurs de charge, les VPN et les services gérés.
Consignez quels systèmes assurent la terminaison TLS, quels certificats ils présentent, quelles équipes en ont la responsabilité et quels fournisseurs contrôlent la pile cryptographique.
Classez les données selon leur durée de confidentialité. Les données confidentielles qui doivent le rester longtemps modifient les priorités ; ce n’est généralement pas le cas des courtes sessions web publiques.
Demandez aux fournisseurs des dates précises et le nom exact des mécanismes pris en charge : ML-KEM plutôt que Kyber avant normalisation, ML-DSA, SLH-DSA, TLS hybride, validation d’algorithme CAVP, validation de module FIPS 140-3 si nécessaire, ainsi que le comportement en cas de rétrogradation ou de repli.
Ne testez TLS hybride que lorsque la population de clients est connue et qu’un retour arrière est simple. Mesurez la latence, la taille de la négociation, le comportement des équipements intermédiaires et l’observabilité.
Évitez de considérer la réémission de certificats comme un plan de migration. Les règles applicables aux certificats publics et la compatibilité des clients restent importantes.

Ce qu’il ne faut pas faire

Acheter un produit seulement parce qu’il se prétend « résistant aux attaques quantiques ».
Remplacer tous les certificats publics avant que les navigateurs, autorités de certification et clients ne prennent en charge les algorithmes concernés.
Supposer qu’un échange de clés PQC fournit aussi des signatures de certificats PQC.
Traiter la PQC et la distribution quantique de clés comme un seul et même projet de migration.
Négliger la responsabilité, le renouvellement et l’hygiène TLS des certificats existants au motif que la PQC paraît plus stratégique.

La place de Nocert

Nocert n’émet pas de certificats et ne rend pas, à lui seul, un point de terminaison post-quantique. Les espaces de travail Compliance de Business et Custom ont un rôle plus circonscrit : maintenir la visibilité sur l’état des certificats et de TLS à partir des observations publiques et internes, notamment les algorithmes des certificats, les constats issus des règles TLS et les preuves horodatées.

La préparation post-quantique peut ainsi être suivie dans le cadre des opérations TLS courantes, plutôt que dans une feuille de calcul séparée. Le résultat attendu est une liste de systèmes, de responsables, de fournisseurs, d’algorithmes et de contraintes de migration, pas un badge générique « résistant aux attaques quantiques ».

Sources primaires

Cette note est basée sur les normes NIST PQC et les conseils de migration, les travaux de l’IETF TLS et X.509, les exigences de base du CA/Browser Forum et la feuille de route PQC coordonnée par l’UE.