Les deux tiers du trafic web humain qui atteint le réseau de Cloudflare négocient désormais un échange de clés hybride post-quantique, parce que Chrome, Edge et Firefox le font en silence. Pendant ce temps, une étude de mesure de 2026 trouve encore la moitié des domaines analysés totalement exposés à un futur ordinateur quantique, les banques et les administrations étant les plus lentes. Le plan de transition du NIST déprécie RSA-2048 et P-256 après 2030 et les interdit après 2035 ; la feuille de route coordonnée de l'UE demande aux États membres d'avoir commencé fin 2026 et d'avoir migré les systèmes à haut risque d'ici 2030. Cet article explique ce qui a été normalisé, ce que signifient les échéances, et comment mener une migration qui commence par un inventaire plutôt que par un produit.
La chronologie
tadata
Les dates relèvent de la politique, pas de la physique : personne ne sait quand un ordinateur quantique cryptographiquement pertinent existera. Ce qui les rend contraignantes, c'est l'attaque récolter maintenant, déchiffrer plus tard : le trafic enregistré aujourd'hui pourra être déchiffré quand la machine arrivera, donc les données qui doivent rester secrètes dix ans sont déjà en risque.
Ce qui est normalisé
tadata
L'échange de clés est résolu et déployé ; les signatures sont le front ouvert. Les certificats ML-DSA pèsent plusieurs kilo-octets, ce qui casse des hypothèses dans les poignées de main TLS, DNSSEC, la signature de code et les cartes à puce, et les travaux de l'IETF sur ML-DSA dans TLS étaient encore en finalisation mi-2026.
tadata
Une chaîne de certificats TLS avec trois signatures ML-DSA et deux clés publiques ML-DSA pèse environ 15 Ko, contre moins de 2 Ko aujourd'hui. C'est pourquoi les navigateurs ont migré l'échange de clés d'abord et pourquoi votre autorité de certification ne vous a pas encore proposé de certificat post-quantique.
L'essentiel de votre cryptographie est sous la ligne de flottaison
tadata
Chaque élément sous la ligne a un responsable, un fournisseur et un cycle de remplacement, et c'est le vrai contenu d'un plan de migration.
Que migrer d'abord
tadata
La logique : l'urgence suit la part de ce trafic ou de ces données qu'un adversaire peut enregistrer aujourd'hui ; l'impact suit la durée pendant laquelle elles doivent rester secrètes et le nombre de systèmes qui dépendent de la clé. Les signatures sont peu urgentes (une signature forgée ne compte qu'une fois l'ordinateur quantique en service) mais à fort impact pour les racines qui ne se remplacent pas vite ; on les planifie, on ne les précipite pas.
Une feuille de route qui tient les dates de l'UE
tadata
Deux notes pratiques. Les modules certifiés sont en retard sur les normes : la file de validation FIPS comptait plus de 200 soumissions ML-KEM et ML-DSA en mai 2026 avec plus d'un an d'attente, donc le « post-quantique validé FIPS » est un achat de 2027 pour la plupart des produits. Et l'hybride est le bon défaut pour des années : un échange hybride (X25519 plus ML-KEM-768) n'est cassé que si ses deux composants le sont, ce qui protège d'une faille dans les nouveaux schémas à réseaux autant que des ordinateurs quantiques.
En résumé
Les algorithmes sont normalisés, les navigateurs ont bougé, et les échéances sont écrites. Ce qui reste, c'est un inventaire que la plupart des organisations n'ont jamais fait : où vit la cryptographie, qui en est responsable, et quels fournisseurs doivent livrer quoi et quand. Commencez cet inventaire en 2026 comme le demande la feuille de route de l'UE, activez l'échange de clés hybride partout où un interrupteur existe, et traitez signatures et matériel comme un programme de renouvellement 2028-2030 plutôt que comme une urgence 2026. Nos articles sur la gestion des secrets et le zero trust couvrent les contrôles voisins.
Sources : NIST FIPS 203, 204, 205 et IR 8547 (projet initial) ; sélection de HQC par le NIST (mars 2025) ; feuille de route coordonnée du groupe de coopération NIS de l'UE (juin 2025) ; données d'adoption post-quantique de Cloudflare Radar rapportées par les études de mesure de 2026 (arXiv 2606.16473 et apparentées) ; projets du groupe de travail TLS de l'IETF sur ML-KEM et ML-DSA ; file CMVP rapportée en mai 2026. Lus le 15 octobre 2026.
Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.