La cryptographie post-quantique n’est plus un sujet “pour plus tard” pour les équipes d’architecture. Le NIST a finalisé ses trois premiers standards PQC principaux en août 2024 — FIPS 203 pour ML-KEM (encapsulation de clé), FIPS 204 pour ML-DSA (signatures numériques) et FIPS 205 pour SLH-DSA (signatures basées sur le hachage sans état) — et a dit aux organisations de commencer à migrer maintenant. Le calendrier de transition du NIST pointe vers la dépréciation des algorithmes à clé publique vulnérables au quantique d’ici 2030 pour la plupart des usages fédéraux et leur suppression complète des standards NIST d’ici 2035, les systèmes à haut risque devant migrer plus tôt.

Cela fait du PQC un problème de migration, pas seulement un sujet de recherche. Ce tutoriel vous donne un programme de migration de première phase réaliste. À la fin, vous aurez un format d’inventaire crypto fonctionnel, un modèle de priorisation basé sur le risque, une checklist de revue d’agilité crypto, une définition de pilote, un questionnaire fournisseur et une feuille de route phasée que vous pouvez présenter à l’architecture d’entreprise ou à la planification de sécurité. Si vous voulez le contexte stratégique avant de plonger dans le travail pratique, lisez l’article compagnon sur la construction d’une feuille de route de migration PQC.

Étape 1 : Inventorier où la cryptographie vit

Votre premier travail n’est pas de choisir des algorithmes. C’est de trouver où la cryptographie à clé publique existe réellement dans votre environnement.

Fichier : pqc-crypto-inventory.csv

system,owner,environment,category,public_key_usage,current_algorithms,certificate_or_key_source,external_facing,confidentiality_lifetime,notes
public-web-gateway,network-team,production,tls,key-establishment-and-server-auth,RSA-ECDHE,corp-pki,yes,medium,front-door internet traffic
idp-platform,identity-team,production,identity,tls-signing-and-federation,ECDSA-RSA,corp-pki,yes,high,sso and federation dependencies
site-to-site-vpn,infra-team,production,vpn,key-exchange-and-auth,ECDSA-ECDH,vendor-managed,yes,high,long-lived tunnel data
artifact-signing,platform-team,production,code-signing,digital-signatures,RSA,ci-key-store,no,high,software trust chain
internal-service-mesh,platform-team,production,mtls,key-establishment-and-auth,ECDSA,mesh-ca,no,medium,service-to-service identity

Astuce

Un inventaire cryptographique n’est utile que s’il capture le contexte. “Utilise TLS” ne suffit pas. Vous devez savoir où, pourquoi et à quel point ce sera difficile de changer.

Étape 2 : Prioriser par risque

Fichier : pqc-prioritization.yaml

systems:
  - name: public-web-gateway
    data_lifetime: medium
    external_exposure: high
    upgrade_difficulty: medium
    trust_infrastructure: high
    pqc_priority: high

  - name: artifact-signing
    data_lifetime: high
    external_exposure: medium
    upgrade_difficulty: medium
    trust_infrastructure: critical
    pqc_priority: critical

  - name: site-to-site-vpn
    data_lifetime: high
    external_exposure: high
    upgrade_difficulty: high
    trust_infrastructure: high
    pqc_priority: critical

  - name: internal-service-mesh
    data_lifetime: medium
    external_exposure: low
    upgrade_difficulty: medium
    trust_infrastructure: medium
    pqc_priority: medium

Attention

Ne priorisez pas uniquement par l’exposition internet. Un système de confiance interne difficile à remplacer protégeant des données sensibles de longue durée peut compter plus qu’un edge web public plus simple.

Étape 3 : Évaluer l’agilité crypto

Fichier : crypto-agility-checklist.md

# Crypto Agility Checklist

- [ ] Are algorithm identifiers configurable?
- [ ] Are key sizes and signature sizes assumed in code?
- [ ] Are certificates parsed with rigid size or field expectations?
- [ ] Can trust stores hold both current and PQC-related artifacts during transition?
- [ ] Can APIs, protocols, or appliances tolerate hybrid negotiation?
- [ ] Can HSMs, smart cards, or firmware be updated?
- [ ] Are there performance or packet-size assumptions tied to current crypto?

Info

“Supporte le PQC” n’est pas la même chose que “est agile cryptographiquement.” La meilleure question est si le système peut évoluer sans réécriture de plateforme ou panne en production.

Étape 4 : Construire un périmètre pilote

Fichier : pqc-pilot-plan.yaml

pilot_name: internal-artifact-signing-lab
scope:
  system: artifact-signing-service
  environment: staging
  protocols:
    - signing
    - verification
goals:
  - validate interoperability with selected pqc-capable components
  - measure signing and verification performance
  - identify tooling or certificate-chain breakage
rollback_criteria:
  - verification failures exceed 1 percent
  - downstream tooling cannot validate artifacts
  - operational latency exceeds agreed threshold
success_metrics:
  - 100 percent successful signing in pilot path
  - 100 percent successful verification in pilot path
  - no undocumented integration failures

Astuce

Un premier pilote PQC devrait vous apprendre la compatibilité, les opérations et la propriété. Il ne devrait pas devenir un projet furtif de transformation d’infrastructure.

Étape 5 : Engager les fournisseurs et les propriétaires internes

Fichier : vendor-pqc-questionnaire.md

# Vendor PQC Questionnaire

1. Which NIST-standardized PQC algorithms do you support or plan to support first?
2. What is your expected timeline for production support?
3. Do you support hybrid deployment modes?
4. Which protocols or product features will gain PQC support first?
5. What interoperability testing have you completed?
6. What hardware, firmware, or software versions are required?
7. What logging and monitoring changes should we expect?
8. What are the rollback or downgrade considerations?
9. Are there licensing, hardware refresh, or contract impacts?
10. What is the documented roadmap and who owns it on your side?

Attention

Une migration PQC stagne vite quand chaque équipe suppose que quelqu’un d’autre possède la conversation sur le protocole, le certificat, le matériel ou le fournisseur.

Étape 6 : Créer une feuille de route phasée

Fichier : pqc-roadmap.yaml

phase_1_discovery:
  target: now
  objectives:
    - complete cryptographic inventory
    - identify critical quantum-vulnerable systems
    - map owners and vendor dependencies

phase_2_pilot:
  target: within_6_months
  objectives:
    - complete one bounded interoperability pilot
    - document operational and compatibility findings
    - refine success and rollback criteria

phase_3_hybrid_transition:
  target: 6_to_18_months
  objectives:
    - deploy selected systems in dual-stack or hybrid-compatible patterns
    - update monitoring and operational runbooks
    - validate broader ecosystem interoperability

phase_4_broader_migration:
  target: 18_months_and_beyond
  objectives:
    - expand to prioritized production systems
    - retire or reduce dependence on quantum-vulnerable public-key algorithms
    - fold pqc planning into normal architecture and procurement cycles

Étape 7 : Documenter et gouverner

Fichier : crypto-governance-checklist.md

# Crypto Governance Checklist

- [ ] Inventory owner assigned
- [ ] Quarterly review scheduled
- [ ] New systems must declare public-key crypto usage
- [ ] Vendor roadmap status reviewed at renewal
- [ ] Exceptions tracked with expiry dates
- [ ] Pilot findings fed back into architecture standards

Note

La gouvernance PQC ne consiste pas à forcer chaque équipe à devenir experte en cryptographie. Il s’agit de s’assurer que les dépendances crypto sont visibles, possédées et revues avant de devenir des projets d’urgence.

Problèmes courants de configuration

L’inventaire semble complet mais manque la crypto embarquée

Les rapports de certificats et PKI ne couvrent que l’infrastructure que vous gérez centralement. De nombreuses applications embarquent directement des bibliothèques crypto. Lancez des recherches au niveau du code source et des scans de dépendances à travers les dépôts applicatifs.

Le fournisseur dit “nous supportons le PQC” mais signifie autre chose

“Supporte le PQC” peut signifier n’importe quoi entre “nous avons un prototype en labo” et “notre prochaine release livre ML-KEM en production.” Demandez toujours des noms d’algorithmes spécifiques, des versions de protocole, des dates de release et des résultats de tests d’interopérabilité.

Le périmètre du pilote dérive vers une migration complète

Un pilote qui essaie de couvrir de nouveaux algorithmes, un nouveau PKI, du nouveau matériel et de nouveaux contrats fournisseurs simultanément n’est pas un pilote. C’est une migration. Contraignez votre premier pilote à un système, un environnement et le moins de changements de variables possible.

Conclusion

Un programme de migration PQC réaliste de première phase devrait atteindre quatre choses : un inventaire crédible d’où la cryptographie à clé publique vit, un modèle de priorisation basé sur le risque, une évaluation d’agilité crypto pour les systèmes clés et au moins un pilote borné avec des métriques de rollback et de succès.

Ce qu’il ne faut pas faire maintenant : ne forcez pas un changement d’algorithme big-bang à travers chaque protocole, ne supposez pas que chaque produit est agile cryptographiquement et ne traitez pas les feuilles de route fournisseurs comme le problème de quelqu’un d’autre. Ce qu’il faut commencer immédiatement : construisez l’inventaire, classez les systèmes à haut risque, ouvrez les conversations fournisseurs, définissez un pilote et faites de l’agilité crypto une partie de la revue d’architecture et d’achats.

Pour le cas d’affaires stratégique et le cadrage au niveau architecture derrière ce travail, consultez Post-Quantum Cryptography Migration Roadmap. Pour le durcissement d’infrastructure connexe, les tutoriels sur le durcissement de votre pipeline CI/CD avec Sigstore, SLSA et SBOMs et le déploiement de passkeys d’entreprise couvrent des sujets d’infrastructure de confiance complémentaires.

Comment démarrer une migration vers la cryptographie post-quantique : inventaire, priorisation, pilote

Avant de commencer

Ce que vous apprendrez