La cryptographie post-quantique : la feuille de route vers la Quantum Readiness

L'échelle de planification est l'ordinateur quantique cryptographiquement pertinent (CRQC) : suffisamment de qubits corrigés des erreurs et de stabilité d'exécution pour exécuter Shor contre des longueurs de clés réelles. Les systèmes actuels en sont éloignés de plusieurs ordres de grandeur. La nouvelle marquante de 2024 n'était donc pas un chiffre record, mais une inflexion de courbe : la puce Willow de Google a montré pour la première fois, dans des conditions réelles, que le taux d'erreur diminue à mesure que le code de correction d'erreurs s'agrandit — l'obstacle central du passage à l'échelle est ainsi prouvé surmontable.

Ce qui compte n'est donc pas la date du Q-Day, mais la durée de confidentialité par classe de données : combien de temps une divulgation serait-elle dommageable ? Tout ce dont la durée de confidentialité dépasse le Q-Day — inconnu — est déjà exposé aujourd'hui, dès qu'il traverse une liaison chiffrée de façon classique.

La valeur du test réside dans sa discipline : x impose une classification des données avec des durées de confidentialité, y impose une estimation honnête de sa propre vitesse de changement — valeur d'expérience dans des environnements historiquement complexes : trois à sept ans, davantage dans les grands groupes —, et z rend explicite l'hypothèse du Q-Day, au lieu de la fixer implicitement à « un jour ou l'autre ». Effectuez le test par classe de données, pas une seule fois pour toute l'entreprise : la dispersion entre les classes constitue précisément la priorisation que formalise le chapitre 11.

Vous pouvez calculer le test de façon interactive avec le calculateur de Mosca sur notre page de services PQC.

Les procédés sont rapides, mais plus volumineux : les clés et signatures passent d'octets à deux chiffres à des kilo-octets. ML-KEM-768 utilise une clé publique de 1 184 octets et un texte chiffré de 1 088 octets ; ML-DSA-65 signe avec 3 309 octets, là où ECDSA P-256 n'en nécessite qu'environ 64 ; SLH-DSA-128s se situe à 7 856 octets par signature. Il en résulte les enjeux pratiques de la migration : paquets de handshake, chaînes de certificats, stockage HSM, limites MTU et champs de protocole à longueur fixe.

Dans TLS 1.3, la norme de facto s'appelle X25519MLKEM768 : le client et le serveur exécutent X25519 et ML-KEM-768 en parallèle et fusionnent les deux secrets dans le schéma de clés. Pour le cas générique, le NIST normalise la combinaison dans SP 800-227 ; le BSI désigne dans la TR-02102-1 (2026-01) CatKDF et KeyCombine comme procédés recommandés. Important pour les auditeurs : l'hybride n'est pas un affaiblissement, mais le mode de fonctionnement des années de transition explicitement recommandé par le BSI — à partir de 2032, les établissements de clés classiques ne devront de toute façon plus fonctionner qu'en mode hybride.

• Navigateurs : Chrome, Edge et Firefox négocient X25519MLKEM768 par défaut.
• Réseau : plus de 50 % du trafic web humain chez Cloudflare est chiffré de façon quantiquement sûre (10/2025) ; depuis 09/2026, « Automatic Key Exchange » relève aussi les liaisons vers les origines.
• Messageries : Signal (PQXDH, 2023) et Apple iMessage (PQ3, 2024) protègent respectivement l'établissement de session et la communication en cours de façon hybride.
• Bibliothèques : OpenSSL 3.5 LTS (04/2025) intègre nativement ML-KEM, ML-DSA et SLH-DSA ; BouncyCastle et liboqs couvrent les piles Java et de recherche.

La feuille de route est juridiquement une recommandation — mais son effet se déploie indirectement : elle définit ce que les autorités de surveillance entendront à l'avenir par « état de l'art ». C'est précisément cette notion qui constitue, dans NIS2 et DORA, la référence en matière de cryptographie. Qui devra expliquer en 2028, lors d'un contrôle, pourquoi des systèmes à haut risque chiffrent encore de façon classique, argumentera contre un consensus européen documenté.

Le plan de transition du NIST IR 8547 (projet depuis novembre 2024) classe les procédés au niveau de sécurité de 112 bits — dont RSA-2048 et ECDSA P-256 — comme « deprecated » à partir de 2030, et prévoit « disallowed » pour RSA et ECC dans leur ensemble à partir de 2035. Encore à l'état de projet, mais déjà référence de la planification des agences américaines : les produits validés FIPS et les services cloud américains démantèleront leurs modes classiques selon ce calendrier — également pour les clients européens.

Les signaux sont sans équivoque : le Quantum Safe Financial Forum d'Europol a appelé en février 2025 les établissements, prestataires et décideurs politiques à ériger la migration PQC en objectif stratégique — remarquable : non pas via une nouvelle réglementation, mais de façon coordonnée dans le cadre existant. En janvier 2026 a suivi, avec FS-ISAC, une méthodologie commune de priorisation qui met en balance le risque quantique et l'effort de migration. Dès septembre 2024, le G7 Cyber Expert Group avait demandé aux autorités de surveillance financière d'intégrer les risques quantiques dans leur planification.

Le résultat se consolide dans une Cryptography Bill of Materials (CBOM) — un inventaire lisible par machine des composants cryptographiques, analogue à la SBOM pour les composants logiciels et représentable de façon normalisée avec CycloneDX. La différence avec une liste Excel : une CBOM est versionnable, comparable (diff), vérifiable en CI/CD — et répond aux questions des auditeurs (PCI 12.3.3, registre des certificats DORA) comme sous-produit. Les constats typiques sont partout les mêmes : SHA-1 et 3DES dans des interfaces legacy, cryptographie codée en dur dans le code source, prolifération incontrôlée de certificats en dehors de toute gouvernance des CA, stores de clés fantômes dans les déploiements — et une chaîne d'approvisionnement incapable de dire d'emblée quelle cryptographie se trouve dans ses produits.

L'architecture cible n'« intègre » pas la PQC, elle construit l'interchangeabilité : des algorithmes et longueurs de clés dans des politiques centrales plutôt que dans le code applicatif, une couche d'abstraction cryptographique, des protocoles avec de la marge pour des clés plus grandes et de nouveaux identifiants, des ancres de confiance mobiles — et une gestion centralisée des clés ancrée sur HSM comme épine dorsale, qui satisfait au passage à l'art. 7 du DORA-RTS. Le test pratique de l'agilité tient en une seule question : « combien de temps nous faudrait-il pour changer l'établissement de clés dans tous les services accessibles de l'extérieur ? » Des réponses en jours témoignent d'agilité, des réponses en années d'un besoin d'action.

Le pilote (phase 4) ne prouve pas que la PQC fonctionne — des milliards de connexions de navigateurs s'en sont déjà chargés —, mais que votre exploitation en est capable : l'infrastructure supporte-t-elle les handshakes plus volumineux ? La surveillance, les règles IDS et les analyseurs SIEM reconnaissent-ils les nouveaux identifiants d'algorithmes, au lieu de signaler les handshakes ML-KEM comme une anomalie ? Et le chemin de repli documenté fonctionne-t-il ? Le pilote se termine par une feuille de chiffres (écarts de latence, taux d'erreur par classe de client, constats sur les middleboxes, taux de détection du SOC) — ce qui transforme la décision de déploiement en un exercice de calcul.

• Semaines 1-2 : obtenir le mandat — note d'une page pour la direction avec échéances, HNDL et coûts du retard ; désigner le comité de pilotage.
• Semaines 2-4 : scanner la façade externe — analyse TLS/certificats de tous les services accessibles de l'extérieur, le contrôle de réalité le plus rapide.
• Immédiatement : éliminer les procédés obsolètes — désactiver SHA-1, 3DES, RSA-1024 ou les inscrire avec échéance au registre des exceptions.
• Semaines 3-6 : fixer les durées de confidentialité par classe de données et calculer le test de Mosca par classe — la diapositive la plus forte pour la direction.
• Semaines 4-10 : mandater l'inventaire cryptographique comme projet de découverte, consolider le résultat en CBOM v1.
• En parallèle : interroger de façon structurée les fournisseurs critiques sur leurs feuilles de route PQC et intégrer la clause type dans les marchés en cours.
• Semaines 8-13 : lancer un pilote hybride sur un service réel (X25519MLKEM768) avec relevés de mesures.
• Semaines 12-13 : présenter un projet de feuille de route avec plan des vagues, trajectoire budgétaire, jeu de KPI et rythme de reporting.

Tous les modèles — diapositive pour la direction, clause type d'achat, guide des objections — figurent dans le whitepaper « Quantum Readiness pour CISO » (téléchargement en haut de cette page).