Checklist de préparation post-quantique pour les équipes sécurité

Une checklist de préparation à la cryptographie post-quantique (PQC) n'a qu'une fonction : transformer une migration pluriannuelle en tâches qu'une équipe peut terminer ce trimestre, chacune laissant derrière elle une preuve lisible par un tiers. L'ordre compte. L'échange de clés vient en premier, car le trafic enregistré n'est protégé que par l'échange de clés ; l'inventaire, les fournisseurs, les signatures et la surveillance suivent. Chaque point ci-dessous nomme le livrable à produire, pas seulement l'idée à considérer.

Comment utiliser cette checklist

Traitez les phases dans l'ordre, mais menez l'inventaire (phase 2) et les gains rapides (phase 3) en parallèle : attendre un inventaire complet avant d'activer l'échange de clés hybride sur un point de terminaison web public retarde la seule mesure qui atténue le risque lié au trafic enregistré. Attribuez à chaque point un responsable, une date et un livrable. Le livrable est l'essentiel : PCI DSS, DORA et NIS2 demandent des politiques, des inventaires et des revues documentés, et une migration non documentée ressemble exactement à une absence de migration. Cet article est fourni à titre d'information et ne constitue pas un conseil juridique.

Quatre termes reviennent tout au long du texte. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) est l'échange de clés post-quantique normalisé dans NIST FIPS 203, publié comme norme définitive le 13 août 2024. Un KEM (key encapsulation mechanism, mécanisme d'encapsulation de clé) est la primitive qui établit un secret partagé. HNDL (harvest now, decrypt later, « collecter maintenant, déchiffrer plus tard ») désigne la pratique consistant à enregistrer dès aujourd'hui du trafic chiffré pour le déchiffrer une fois qu'un ordinateur quantique suffisamment puissant existera. Un CBOM (cryptographic bill of materials) est un inventaire des actifs cryptographiques lisible par machine.

Phase 1 : gouvernance et périmètre

• Désignez un responsable unique et un groupe de travail réunissant l'architecture sécurité, la PKI, le réseau, les responsables applicatifs et les achats. Preuve : une lettre de mission d'une page indiquant les noms, le périmètre et la fréquence des réunions.
• Choisissez le calendrier qui sert d'ancrage à votre plan (régulateur sectoriel, recommandations nationales, contrats clients). Preuve : une courte déclaration d'applicabilité nommant les cadres qui vous engagent et ceux que vous traitez comme des recommandations. Notre panorama des échéances officielles de migration post-quantique les recense avec leurs sources.
• Intégrez l'agilité cryptographique à la politique de chiffrement. Les normes techniques de réglementation DORA, Commission Delegated Regulation (EU) 2024/1774, Art. 6, exigent une politique de chiffrement et de contrôles cryptographiques comprenant des dispositions pour mettre à jour ou changer la technologie cryptographique en fonction des évolutions de la cryptanalyse. NIS2, Directive (EU) 2022/2555, Art. 21(2)(h), exige des politiques et procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement. Preuve : la version approuvée de la politique, datée, avec la clause visible.
• Identifiez les données dont la confidentialité doit durer longtemps : secrets, données de santé et financières, propriété intellectuelle, tout ce dont l'exposition en 2040 serait encore préjudiciable. Preuve : une liste des systèmes avec la durée de confidentialité requise par classe de données.
• Inscrivez le HNDL au registre des risques sous ce nom, avec les systèmes concernés. Preuve : l'entrée de risque avec son responsable et sa date de revue.

Dates d'ancrage pour la planification

Phase 2 : découverte et inventaire

• Recensez d'abord la surface externe : chaque nom d'hôte public, ses versions TLS, les groupes d'échange de clés proposés, les suites de chiffrement et la chaîne de certificats. Preuve : un export de scan daté par nom d'hôte, conservé comme état initial.
• Étendez à l'interne : terminaisons TLS et répartiteurs de charge, concentrateurs VPN, parcs SSH, TLS mutuel entre services, connexions aux bases de données et aux files de messages, HSM, chiffrement des sauvegardes, chaînes de signature de micrologiciels et de logiciels. Preuve : un inventaire indiquant la finalité, l'emplacement et le responsable de chaque entrée, ce qui correspond aussi à ce qu'attend l'exigence 12.3.3 de PCI DSS v4.0.1 pour les suites de chiffrement et protocoles utilisés.
• Rendez la découverte reproductible, plutôt qu'un tableur ponctuel. OMB M-26-15 demande aux agences américaines un inventaire cryptographique automatisé et mis à jour en continu ; ce niveau d'exigence constitue un objectif raisonnable ailleurs, même là où il ne s'applique pas.
• Produisez un CBOM. Il s'agit de notre interprétation, et non d'une exigence littérale des textes cités : un CBOM est un moyen pratique de prouver l'existence d'un inventaire et d'en comparer les versions d'une release à l'autre. Consultez ce que contient un CBOM pour sa structure.
• Signalez l'obsolète et le vulnérable au quantique : RSA, ECDSA, EdDSA, ECDH, DH sur corps finis et DSA sont cassés par l'algorithme de Shor sur un ordinateur quantique suffisamment grand, quelle que soit la taille de clé. RC4 est interdit dans TLS (RFC 7465), MD5 et SHA-1 sont obsolètes pour les signatures, et le groupe TLS Kyber pré-normalisation X25519Kyber768Draft00 (codepoint 0x6399) devrait être retiré.

openssl version
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"
ssh -Q kex | grep mlkem
ssh -v user@example.com 2>&1 | grep "kex: algorithm"

OpenSSL 3.5 ou ultérieur est nécessaire pour les groupes ML-KEM. Si openssl s_client refuse le nom du groupe, le client est trop ancien et le résultat ne dit rien du serveur.

Phase 3 : gains rapides sur l'échange de clés

• Activez l'échange de clés hybride sur les points de terminaison TLS publics. Proposez X25519MLKEM768 (codepoint IANA 0x11EC) en premier et conservez X25519 classique après lui comme solution de repli. SecP256r1MLKEM768 (0x11EB) et SecP384r1MLKEM1024 (0x11ED) sont les alternatives enregistrées. Les versions actuelles de Chrome, Edge et Firefox proposent déjà X25519MLKEM768 par défaut : l'adoption est donc immédiate pour le trafic des navigateurs. Preuve : le diff de configuration ainsi qu'un scan avant et après.
• Testez d'abord en préproduction et surveillez les équipements intermédiaires qui tolèrent mal des messages ClientHello plus volumineux. Preuve : le compte rendu des tests de préproduction et les éventuels constats relatifs au MTU ou à la fragmentation.
• Mettez à jour SSH. OpenSSH 9.9 (19 septembre 2024) a ajouté mlkem768x25519-sha256, OpenSSH 10.0 (9 avril 2025) en a fait l'accord de clés par défaut, et OpenSSH 10.1 (6 octobre 2025) émet un avertissement lorsqu'une connexion négocie un accord de clés non post-quantique. Preuve : rapport des versions du parc et échange de clés négocié pour chaque hôte de rebond.
• Privilégiez AES-256 pour les données au repos à longue durée de vie. Les algorithmes symétriques et les fonctions de hachage ne sont pas cassés par Shor ; c'est l'algorithme de Grover qui justifie la préférence pour AES-256 en vue d'une protection à long terme.

# nginx built against OpenSSL 3.5 or later: hybrid first, classical kept as fallback
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

La syntaxe et la version de compilation requise varient selon les serveurs et les distributions ; notre guide pour activer ML-KEM sur nginx, Apache, HAProxy et Caddy détaille les directives propres à chaque serveur. Le RFC 10024 (août 2026) spécifie l'accord de clés hybride post-quantique et traditionnel pour TLS 1.3.

Phase 4 : fournisseurs et achats

L'essentiel du parc appartient à d'autres. Envoyez les cinq mêmes questions à chaque fournisseur critique et archivez les réponses avec le contrat.

1. Quels groupes d'échange de clés TLS votre service propose-t-il aujourd'hui, et pouvons-nous le vérifier depuis l'extérieur ?
2. Quelle est votre feuille de route datée pour la prise en charge de ML-KEM, et quelles notes de version l'annonceront ?
3. Quelles implémentations de FIPS 203, 204 ou 205 utilisez-vous, et dans quels composants ?
4. Pouvez-vous fournir un CBOM ou un inventaire cryptographique équivalent pour le produit livré ?
5. Comment le contrat traite-t-il un changement d'algorithme imposé par une évolution de la cryptanalyse ?

Preuve : des réponses écrites et datées pour chaque fournisseur, ainsi qu'une clause d'agilité cryptographique dans les renouvellements. Pour les produits vendus dans l'UE, le Cyber Resilience Act (règlement sur la cyberrésilience), Regulation (EU) 2024/2847, Annex I, Part I (2)(e), exige de protéger la confidentialité, par exemple en chiffrant les données pertinentes au repos ou en transit au moyen de mécanismes conformes à l'état de l'art ; il ne nomme pas d'algorithmes post-quantiques. Ses obligations de signalement s'appliquent à partir du 11 septembre 2026 et il s'applique pleinement à partir du 11 décembre 2027.

Phase 5 : signatures, certificats et PKI

• Inventoriez les algorithmes de signature et les périodes de validité. Listez chaque certificat et chaque clé de signature dont la validité s'étend au-delà de vos dates d'ancrage. Preuve : un registre des certificats, que DORA RTS Art. 7 exige pour les actifs TIC soutenant des fonctions critiques ou importantes, avec une gestion des clés couvrant l'ensemble de leur cycle de vie.
• Raccourcissez les durées de vie et automatisez le renouvellement afin qu'un changement d'algorithme soit un changement de configuration, et non un projet. Preuve : la couverture de l'émission automatisée, exprimée en pourcentage de certificats gérés automatiquement.
• Planifiez séparément la signature de code et de micrologiciels. ML-DSA (FIPS 204) et SLH-DSA (FIPS 205) sont les normes définitives ; LMS et XMSS sont spécifiés dans NIST SP 800-208 et sont à état, si bien que la gestion de l'état constitue la principale difficulté d'ingénierie. Pour les National Security Systems américains, CNSA 2.0 exige l'usage exclusif de ses algorithmes d'ici fin 2030 pour la signature de logiciels et de micrologiciels et les équipements réseau traditionnels, et d'ici fin 2033 pour les navigateurs et serveurs web, les services cloud, les systèmes d'exploitation et les équipements de niche.
• N'imposez pas encore de certificats post-quantiques sur le web public. Gardez l'échange de clés hybride comme priorité : le trafic enregistré est protégé par l'échange de clés, de sorte que signatures et certificats peuvent migrer plus tard, selon un calendrier planifié.
• Testez dès maintenant la tolérance à la taille : des clés publiques et des signatures plus volumineuses sollicitent les magasins de certificats, les équipements embarqués et les tampons de négociation. Preuve : un rapport de laboratoire par famille d'équipements.

openssl x509 -in cert.pem -noout -subject -issuer -enddate
openssl x509 -in cert.pem -noout -text | grep -i -E "Signature Algorithm|Public-Key"

Phase 6 : surveillance et revue

• Rescannez la surface externe à intervalles réguliers et déclenchez une alerte en cas de régression. Le remplacement d'un répartiteur de charge ou une modification de configuration du CDN peut supprimer silencieusement le groupe hybride. Preuve : un historique mensuel des scans par nom d'hôte.
• Revoyez les suites de chiffrement et les protocoles au moins tous les 12 mois. Cette fréquence reprend le texte littéral de l'exigence 12.3.3 de PCI DSS v4.0.1, obligatoire depuis le 31 mars 2025, assortie d'un suivi de leur viabilité continue et d'une stratégie documentée face aux évolutions prévisibles des vulnérabilités cryptographiques. Preuve : le compte rendu signé de la revue annuelle.
• Suivez l'évolution des normes. Le NIST a sélectionné HQC comme cinquième algorithme et KEM de secours le 11 mars 2025, prévu sous la forme de FIPS 207, sans projet publié en septembre 2026. NIST IR 8547 et SP 800-131A Rev. 3 restent des projets publics initiaux.
• Remontez un seul indicateur à la direction : la part des points de terminaison critiques qui négocient un échange de clés hybride. Preuve : une tendance trimestrielle, et non un instantané ponctuel.

Transformer la checklist en première mesure

Les phases 2 et 6 nécessitent la même donnée d'entrée : une vue externe de ce que vos serveurs négocient réellement. Vous pouvez scanner votre domaine avec PQC Status gratuitement pour voir les versions TLS, les groupes d'échange de clés proposés et la chaîne de certificats, puis conserver l'export comme référence datée pour le point d'inventaire. Un scan décrit uniquement la configuration TLS visible depuis l'extérieur : ce n'est ni une certification ni une attestation de conformité. La prochaine étape concrète consiste à l'exécuter sur vos trois noms d'hôte les plus exposés, à archiver les résultats et à ouvrir un ticket pour chaque nom d'hôte qui ne propose pas encore de groupe hybride.