Cryptographie Post-Quantique : Anticiper la Rupture dans une Architecture Zero Trust
La menace quantique : pas demain, aujourd’hui
L’émergence de l’informatique quantique représente une menace existentielle pour la confidentialité des données chiffrées avec les algorithmes classiques. Un ordinateur quantique cryptographiquement pertinent (CRQC) pourrait casser les algorithmes RSA et ECDSA actuels en heures ou jours, via l’algorithme de Shor, rendant obsolète la quasi-totalité des mécanismes de chiffrement asymétrique déployés dans les systèmes d’information.
Les estimations de calendrier convergent : les agences de sécurité nationales estiment que le risque se matérialisera entre le début et le milieu des années 2030. L’agence allemande de sécurité des systèmes d’information a réduit son horizon de prévision de « 20 ans » fin 2023 à « maximum 16 ans » début 2025, l’accélération des progrès ayant dépassé les prévisions des experts.
Mais la menace la plus immédiate n’est pas le cassage futur des clés, c’est le « Harvest Now, Decrypt Later » (HNDL). Des adversaires collectent dès aujourd’hui les données chiffrées (trafic réseau intercepté, sauvegardes exfiltrées), les stockent, et les déchiffreront dans 5-10 ans lorsqu’un CRQC sera disponible. Les données exigeant une confidentialité de longue durée (> 10 ans), secrets d’État, propriété intellectuelle, données médicales, R&D, sont vulnérables dès maintenant.
L’agence nationale de sécurité des systèmes d’information est formelle : la transition vers la cryptographie post-quantique est non optionnelle. C’est un enjeu majeur de la prochaine décennie, qui impactera l’intégralité de l’écosystème numérique.
Le théorème de Mosca : quand faut-il migrer ?
Un outil de décision objectif pour les décideurs
Le débat « quand migrer vers la PQC ? » reste souvent abstrait dans les comités de direction. Le théorème de Mosca fournit un cadre mathématique simple et universellement reconnu pour transformer cette question en scoring de risque quantifiable par asset :
Si X + Y > Q, l’organisation est déjà en retard.
Où :
- X = durée de confidentialité requise des données (combien de temps les données doivent-elles rester secrètes ?)
- Y = temps nécessaire pour migrer les systèmes qui protègent ces données vers la PQC
- Q = horizon d’arrivée estimé d’un ordinateur quantique cryptographiquement pertinent
Application concrète
Scénario | X (confidentialité) | Y (migration) | Q (CRQC) | X + Y > Q ? | Verdict |
Données de santé (vie du patient) | 60 ans | 3 ans | ~10 ans | 63 > 10 ✅ | En retard : migrer immédiatement |
Propriété intellectuelle R&D | 15 ans | 2 ans | ~10 ans | 17 > 10 ✅ | En retard : migrer immédiatement |
Données financières (archivage réglementaire) | 10 ans | 2 ans | ~10 ans | 12 > 10 ✅ | Migration prioritaire |
Données marketing (campagnes) | 1 an | 1 an | ~10 ans | 2 < 10 ❌ | Migration planifiable, non urgente |
Sessions web transactionnelles | 0 an | 1 an | ~10 ans | 1 < 10 ❌ | Migration planifiable |
Le théorème de Mosca rend visible une réalité contre-intuitive : pour toute donnée dont la confidentialité dépasse 7-8 ans, la migration est déjà urgente, même si le CRQC n’arrive que dans 10 ans. Le temps de migration (Y) consomme la marge disponible.
Ce scoring doit être appliqué asset par asset dans l’inventaire cryptographique de l’organisation, et présenté au comité de direction comme outil de priorisation budgétaire.
Les standards post-quantiques : une base solide
FIPS 203, 204, 205 : les trois piliers
En août 2024, l’institut national américain de standardisation a finalisé les trois premiers standards de cryptographie post-quantique, fruit de huit années de compétition mondiale et d’évaluation rigoureuse :
Standard | Algorithme | Fonction | Remplace | Basé sur |
FIPS 203 | ML-KEM | Échange de clés (Key Encapsulation) | RSA, ECDH (Diffie-Hellman) | CRYSTALS-Kyber (réseaux euclidiens) |
FIPS 204 | ML-DSA | Signatures numériques | ECDSA, RSA signatures | CRYSTALS-Dilithium (réseaux euclidiens) |
FIPS 205 | SLH-DSA | Signatures numériques (alternative) | ECDSA, RSA signatures | SPHINCS+ (fonctions de hachage) |
Niveaux de sécurité
Chaque algorithme propose plusieurs niveaux de sécurité, alignés sur les standards de chiffrement symétrique :
Variante | Niveau de sécurité | Équivalent |
ML-KEM-512 / ML-DSA-44 | Niveau 1 | AES-128 |
ML-KEM-768 / ML-DSA-65 | Niveau 3 | AES-192 |
ML-KEM-1024 / ML-DSA-87 | Niveau 5 | AES-256 |
Le niveau 3 (ML-KEM-768 / ML-DSA-65) est le niveau recommandé par défaut pour la majorité des usages entreprise, offrant un excellent compromis entre sécurité et performance.
Différences clés avec les algorithmes classiques
Les algorithmes post-quantiques fonctionnent différemment des algorithmes classiques sur plusieurs aspects opérationnels :
- Tailles de clés et de signatures plus grandes : les artefacts cryptographiques PQC sont significativement plus volumineux que ceux d’ECDSA ou RSA, ce qui impacte la bande passante et le stockage.
- ML-KEM n’est pas un échange de clés non-interactif : contrairement à ECDH, ML-KEM requiert une interaction entre les parties. Pour les applications nécessitant une non-interactivité, ML-KEM n’est pas un remplacement direct.
- Performances de calcul différentes : ML-KEM et ML-DSA offrent de bonnes performances en calcul, mais les profils de latence diffèrent de RSA/ECDSA.
Ces différences imposent des tests de compatibilité et de performance approfondis avant tout déploiement en production.
Impact sur le chiffrement symétrique
Le risque quantique ne concerne pas uniquement le chiffrement asymétrique. L’algorithme de Grover permet à un ordinateur quantique de diviser par deux la force effective d’un algorithme symétrique.
Concrètement :
- AES-128 → force effective réduite à 64 bits (insuffisant)
- AES-192 → force effective réduite à 96 bits (limite)
- AES-256 → force effective réduite à 128 bits (sûr)
La recommandation est claire : AES-256 minimum pour tout nouveau déploiement, et planification de la migration des systèmes encore en AES-128. Les fonctions de hachage doivent également être dimensionnées en conséquence : SHA2-384 ou SHA2-512 minimum.
La stratégie hybride : la défense en profondeur cryptographique
Pourquoi l’hybridation est indispensable
Les autorités de sécurité nationales et européennes recommandent unanimement une approche hybride durant la transition : algorithmes classiques (RSA, ECDSA) ET post-quantiques (ML-KEM, ML-DSA) déployés en parallèle.
La logique est celle de la défense en profondeur cryptographique : si l’un des deux algorithmes est cassé (l’algorithme classique par un CRQC, ou l’algorithme PQC par une cryptanalyse imprévue), l’autre préserve la sécurité. L’hybridation protège dans les deux directions.
Handshake TLS 1.3 hybride
Dans une négociation TLS 1.3 hybride, le client et le serveur échangent simultanément deux ensembles de clés publiques :
- Un échange de clés classique (ECDH)
- Un échange de clés post-quantique (ML-KEM)
Le secret partagé final est dérivé de la combinaison des deux échanges. Si l’un des deux mécanismes est compromis, l’autre fournit toujours la sécurité. Cette approche est déjà supportée par les navigateurs et les bibliothèques TLS majeurs.
L’hybridation s’applique aux deux fonctions
- Échange de clés : ECDH + ML-KEM → protège la confidentialité de la session.
- Signatures : ECDSA + ML-DSA → protège l’authentification des certificats.
Les deux dimensions doivent être hybridées pour une protection complète.
L’inventaire cryptographique : le CBOM comme livrable structuré
Au-delà du tableur : le Cryptographic Bill of Materials
La première étape de toute migration PQC est l’inventaire cryptographique. Mais un tableur Excel de certificats ne suffit pas. Le CBOM (Cryptographic Bill of Materials) est le standard émergent qui formalise cet inventaire de manière structurée, machine-readable et auditable.
Le CBOM documente, pour chaque composant du SI :
- Quels algorithmes sont utilisés (RSA-2048, ECDSA P-256, AES-128, SHA-256…)
- Quelles tailles de clés sont configurées
- Quels protocoles transportent la cryptographie (TLS 1.2/1.3, IPsec, SSH, S/MIME…)
- Quelles bibliothèques implémentent les algorithmes (OpenSSL, BoringSSL, NSS, Java Crypto…)
- Quel est le propriétaire de chaque composant cryptographique
- Quel est le statut PQC : vulnérable, en cours de migration, migré, non applicable
Pourquoi le CBOM est supérieur à l’inventaire classique
Aspect | Inventaire classique (tableur) | CBOM |
Format | Manuel, non standardisé | Standardisé (CycloneDX), machine-readable. |
Granularité | Certificats et domaines | Algorithmes, bibliothèques, protocoles, dépendances |
Automatisation | Saisie manuelle | Génération automatisée par scanners et agents |
Maintenabilité | Obsolète en quelques semaines | Mis à jour en continu par intégration CI/CD |
Auditabilité | Difficile à vérifier | Vérifiable, exportable, intégrable dans les outils de conformité |
Réutilisabilité | Usage interne uniquement | Partageable avec les régulateurs, les auditeurs et les partenaires |
Le CBOM répond directement à l’exigence d’inventaire cryptographique de la roadmap européenne PQC (fin 2026) et à l’obligation NIS2 de cartographie des risques. Il constitue le livrable fondateur de tout programme de migration post-quantique.
Méthodologie de construction du CBOM
- Découverte automatisée : déployer des sondes réseau et des scanners applicatifs pour identifier les suites cryptographiques en usage (handshakes TLS, tunnels VPN, échanges SSH).
- Analyse des dépendances logicielles : intégrer l’analyse des bibliothèques cryptographiques dans les pipelines CI/CD (inventaire SBOM étendu au CBOM).
- Cartographie des flux : identifier chaque flux réseau chiffré, le protocole utilisé, l’algorithme négocié et la version du protocole.
- Classification par risque Mosca : appliquer le scoring X + Y > Q à chaque entrée du CBOM pour prioriser la migration.
- Gouvernance continue : le CBOM est un document vivant, mis à jour à chaque changement de configuration, chaque déploiement, chaque renouvellement de certificat.
La roadmap européenne : des échéances concrètes
Le calendrier à trois horizons
En juin 2025, la Commission européenne et les États membres ont dévoilé une feuille de route coordonnée pour la transition vers la cryptographie post-quantique, développée par le groupe de travail PQC du NIS Cooperation Group :
Échéance | Obligation |
Fin 2026 | Tous les États membres doivent avoir lancé la transition : stratégie nationale, inventaires cryptographiques (CBOM), cartographie des dépendances, programme de sensibilisation |
Fin 2030 | Les systèmes à haut risque (infrastructures critiques, secteurs vitaux) doivent être sécurisés par cryptographie post-quantique. Les logiciels et firmwares quantum-safe doivent être le standard. |
2035 | La transition PQC doit être achevée pour la majorité des systèmes, y compris les systèmes legacy et à risque modéré |
En parallèle, la roadmap nationale précise :
Échéance | Recommandation |
2027 | Qualification opérationnelle des implémentations PQC ; déploiement de certificats hybrides pour données long-terme. Mise à jour du référentiel IPsec DR avec algorithmes PQC. Plus d’entrée en qualification sans PQC intégrée. |
2030 | PQC obligatoire pour données exigeant > 5 ans de confidentialité. Il ne sera plus raisonnable d’acheter des produits n’intégrant pas de PQC. |
2032 | PQC obligatoire pour données exigeant > 3 ans |
2035 | Fin du support des algorithmes classiques seuls ; PQC-only |
Le message est sans ambiguïté : la transition n’est pas optionnelle, et les échéances sont définies.
Mythes et réalités : ce que la PQC est (et n’est pas)
La migration post-quantique souffre d’idées reçues qui freinent la prise de décision. Voici les dix mythes les plus répandus, confrontés à la réalité :
Mythe | Réalité |
« Les ordinateurs quantiques sont encore très loin » | Les attaques HNDL sont actives dès aujourd’hui. La collecte de données chiffrées est en cours. Le théorème de Mosca prouve que pour les données à confidentialité > 7-8 ans, la migration est déjà urgente. |
« Il suffit d’attendre que les fournisseurs cloud gèrent la PQC » | Les fournisseurs cloud ne couvrent que leurs propres services. Les VPN, PKI internes, signatures de code, systèmes OT et protocoles métier restent de la responsabilité de l’organisation. |
« Seul le chiffrement asymétrique est menacé » | Le chiffrement symétrique est aussi impacté (algorithme de Grover) : AES-128 est affaibli, d’où la recommandation AES-256 minimum. |
« La PQC nécessite un ordinateur quantique pour fonctionner » | Les algorithmes PQC s’exécutent sur des ordinateurs classiques. Ce sont des algorithmes mathématiques résistants aux attaques quantiques, pas de la physique quantique. |
« L’inventaire cryptographique prend des mois » | Des outils automatisés (sondes réseau, scanners d’applications, CBOM) permettent de constituer un inventaire en quelques semaines. |
« L’hybridation est une complexité inutile » | L’hybridation est indispensable pendant la transition : elle protège à la fois contre le CRQC (si l’algorithme classique est cassé) et contre une cryptanalyse imprévue (si l’algorithme PQC présente une faiblesse). |
« Toutes les implémentations PQC offrent le même niveau de sécurité » | La sécurité dépend de la qualité de l’implémentation (protection contre les attaques par canaux auxiliaires), pas seulement du choix de l’algorithme. |
« La migration PQC est un projet IT » | C’est un programme de transformation qui touche les achats, les contrats, la conformité, la supply chain, la gouvernance et les relations fournisseurs. |
« On a le temps de voir venir » | L’autorité nationale n’acceptera plus en qualification des produits sans PQC dès 2027. La roadmap UE fixe un « niveau minimal de préparation » fin 2026. |
« La PQC ne concerne que les militaires et le renseignement » | Toute organisation manipulant des données à confidentialité > 5 ans est concernée : santé, finance, propriété intellectuelle, données personnelles RGPD, archivage réglementaire. |
ACME + PQC : la crypto-agilité comme pont entre présent et futur
L’automatisation ACME est la fondation de la migration PQC
Comme détaillé dans l’article précédent (SSL/TLS & PKI), l’automatisation ACME permet de changer l’algorithme de chiffrement par simple modification de configuration, appliquée automatiquement à chaque renouvellement. Cette crypto-agilité est le prérequis technique de la migration post-quantique.
Sans ACME, le passage à des certificats hybrides (RSA + ML-DSA) ou PQC-only (ML-DSA seul) nécessiterait le renouvellement manuel de chaque certificat, opération irréaliste à l’échelle d’une entreprise. Avec ACME, c’est une modification de politique propagée automatiquement.
Trajectoire de migration cryptographique
Phase | Période | Action | Algorithmes |
Inventaire (CBOM) | 2025-2026 | Cartographie de tous les usages cryptographiques ; classification des données par durée de confidentialité (Mosca) | RSA 2048 / ECDSA P-256 (existant) |
Pilote hybride | 2027-2028 | Déploiement de certificats hybrides sur les systèmes protégeant des données long-terme ; tests de compatibilité | RSA + ML-DSA (signatures) ; ECDH + ML-KEM (échange de clés) |
Généralisation hybride | 2028-2030 | Extension à tous les systèmes critiques ; TLS 1.3 hybrid par défaut | Hybride généralisé |
Migration PQC-only | 2030-2035 | Dépréciation des algorithmes classiques seuls ; PQC-only en production | ML-KEM-768 / ML-DSA-65 |
Enjeux sectoriels spécifiques
Secteur financier (DORA)
DORA exige une gestion sécurisée de la cryptographie, ce qui implique une roadmap PQC documentée dans le cadre de la gestion des risques. Les entités financières doivent démontrer qu’elles ont identifié les systèmes vulnérables à la menace quantique et planifié leur migration. Les données financières à conservation longue (archivage réglementaire 10+ ans) sont directement exposées au HNDL.
Secteur santé (HDS, RGPD)
Les données de santé exigent une confidentialité long-terme la durée de vie du patient, soit potentiellement 80+ ans. Le HNDL est une menace immédiate pour les données de santé. Les référentiels d’hébergement de données de santé recommandent explicitement la préparation post-quantique pour les données sensibles.
Secteur public et infrastructures critiques
Les organisations soumises à supervision par les autorités nationales de cybersécurité sont les premières concernées par la roadmap européenne. Une roadmap PQC documentée est attendue, avec des jalons alignés sur le calendrier 2026-2030-2035.
Systèmes industriels et OT : le défi des cycles de vie longs
Le cas le plus critique pour le HNDL
Les environnements industriels (OT, SCADA, IoT industriel) décrits dans l’article on-premise présentent un défi spécifique et aigu pour la migration post-quantique. Les équipements OT ont des cycles de vie de 15 à 25 ans, et nombre d’entre eux embarquent de la cryptographie asymétrique (authentification des commandes, chiffrement des communications entre automates et systèmes de supervision, signatures de firmware) sans capacité de mise à jour cryptographique.
L’application du théorème de Mosca aux environnements OT est alarmante :
Équipement | X (confidentialité / intégrité) | Y (migration) | X + Y > Q ? |
Automate PLC avec firmware signé RSA-2048 | 15 ans (durée de vie restante) | 5 ans (remplacement requis) | 20 > 10 ✅ Critique |
Passerelle SCADA avec VPN IPsec | 10 ans | 3 ans | 13 > 10 ✅ Urgent |
Capteur IoT avec certificat codé en dur | 10 ans | Non migrable | ∞ ✅ Contournement requis |
Stratégies de contournement pour les systèmes non migrables
Pour les équipements OT qui ne peuvent pas être mis à jour vers des algorithmes PQC, trois stratégies de contournement doivent être combinées :
- Encapsulation PQC engateway
Déployer des passerelles de chiffrement PQC en amont des équipements legacy. Le trafic entre la passerelle et le réseau externe est protégé par des tunnels hybrides ou PQC-only, tandis que le trafic entre la passerelle et l’équipement OT reste en cryptographie classique — mais confiné dans un périmètre isolé et contrôlé.
- Segmentation réseau renforcée
Appliquer la segmentation réseau décrite dans l’article on-premise (micro-segmentation, zones et conduits IEC 62443) pour isoler physiquement les équipements non migrables. L’objectif est de réduire la surface d’exposition au HNDL en empêchant l’interception du trafic cryptographiquement vulnérable.
- Remplacement planifié
Intégrer la fin de vie cryptographique dans le cycle de vie des actifs OT. Les équipements dont la cryptographie ne peut pas être mise à jour doivent être identifiés dans le CBOM, scorés par le théorème de Mosca, et planifiés pour remplacement dans le cadre du plan d’investissement industriel.
Intégration avec le référentiel IEC 62443
La norme IEC 62443 (sécurité des systèmes d’automatisation et de contrôle industriels) structure les environnements OT en zones et conduits avec des niveaux de sécurité (SL 1 à 4). La migration PQC doit s’intégrer dans ce cadre :
- SL 3-4 (protection contre attaques sophistiquées) : migration PQC prioritaire, hybridation obligatoire dès 2027.
- SL 1-2 (protection contre attaques opportunistes) : migration planifiable, mais CBOM et scoring Mosca requis dès 2026.
- Conduits inter-zones : les tunnels chiffrés entre zones doivent migrer vers des cipher suites hybrides en priorité — c’est le trafic le plus exposé au HNDL.
Les exigences de crypto-agilité dans les nouveaux déploiements OT
Pour tout nouveau déploiement OT à partir de 2026, la crypto-agilité doit être une exigence contractuelle non négociable :
- L’équipement doit supporter la mise à jour des algorithmes cryptographiques sans remplacement matériel.
- Le firmware doit pouvoir être signé avec des algorithmes hybrides ou PQC.
- Les protocoles de communication doivent supporter TLS 1.3 avec des cipher suites configurables.
- Le fournisseur doit fournir une roadmap PQC documentée et s’engager contractuellement sur le support des algorithmes NIST FIPS 203/204/205.
Supply chain et fournisseurs : intégrer la PQC dans les achats
Évaluation des fournisseurs
La roadmap européenne et NIS2 exigent l’évaluation de la chaîne d’approvisionnement en matière de résilience cryptographique. Pour chaque fournisseur critique, l’organisation doit évaluer :
- Support PQC : le fournisseur supporte-t-il les algorithmes NIST FIPS 203/204/205 ? Si oui, dans quels produits et à quelle échéance ?
- Crypto-agilité : les produits du fournisseur permettent-ils de changer d’algorithme sans remplacement matériel ni interruption de service ?
- Roadmap PQC documentée : le fournisseur a-t-il publié un calendrier de migration ?
- Hybridation : les produits supportent-ils les certificats hybrides et les cipher suites hybrides TLS 1.3 ?
Clauses contractuelles type
À partir de 2026, les appels d’offres pour tout équipement réseau, sécurité et infrastructure doivent inclure des clauses de crypto-agilité et de support PQC :
- Exigence de support des algorithmes FIPS 203/204/205 avant une date définie.
- Engagement de maintenance cryptographique sur la durée de vie du produit.
- Capacité de mise à jour des cipher suites sans interruption de service.
- Fourniture d’un CBOM pour chaque produit livré.
Après 2030, il ne sera plus raisonnable d’acquérir des produits n’intégrant pas de cryptographie post-quantique.
Conformité réglementaire : la PQC dans le périmètre d’exigence
Exigence réglementaire | Implication PQC |
Gestion des risques (NIS2 art. 21) | La menace quantique doit être intégrée dans l’analyse de risque ; CBOM obligatoire |
Sécurité cryptographique (NIS2, DORA) | Roadmap PQC documentée ; déploiement hybride pour données long-terme |
Résilience opérationnelle (DORA) | Tests de compatibilité PQC ; plans de migration validés |
Roadmap UE PQC (recommandation juin 2025) | Début transition fin 2026 ; haut risque sécurisé fin 2030 ; achèvement 2035. |
Avis national migration PQC | Hybridation obligatoire ; pas d’achat de produits sans PQC après 2030. |
CRA — Security by design | Les produits numériques doivent intégrer la crypto-agilité et supporter les algorithmes PQC |
Visas de sécurité nationaux | Premiers visas de sécurité pour la cryptographie post-quantique hybride délivrés 2024-2025. |
IEC 62443 (OT) | La migration PQC doit s’intégrer dans le cadre des zones et conduits, avec priorisation par SL |
La PQC traverse toute l’architecture Zero Trust
La migration post-quantique n’est pas un chantier isolé elle traverse tous les piliers de l’architecture Zero Trust couverts dans cette série :
Pilier Zero Trust | Impact PQC |
Segmentation réseau on-premise | Les tunnels IPsec et le SD-WAN doivent migrer vers des cipher suites hybrides puis PQC-only. Les appliances NGFW doivent supporter ML-KEM dans le handshake TLS. Les passerelles OT doivent encapsuler le trafic legacy dans des tunnels PQC. |
Cloud-native SASE/SSE | Les PoP cloud doivent supporter TLS 1.3 hybride. Les tunnels ZTNA doivent être crypto-agiles. |
PAM / Bastions | Les certificats SSH éphémères (utilisés pour les sessions bastion) doivent migrer vers des algorithmes PQC. La rotation automatique via ACME facilite cette transition. |
API Security | Le mTLS entre microservices (via service mesh) doit supporter les cipher suites hybrides. Les JWT doivent être signés avec des algorithmes PQC. |
Certificats SSL/TLS | L’automatisation ACME est le véhicule de la migration PQC. Chaque renouvellement automatique est une opportunité de migration transparente. |
Recommandations pour l’action
Pour les DSI et RSSI, sept axes d’action prioritaires :
- Construire le CBOM : cartographier tous les systèmes utilisant de la cryptographie asymétrique en format CBOM standardisé. Classifier les données par durée de confidentialité. Automatiser la mise à jour du CBOM via les pipelines CI/CD et les sondes réseau.[11][14]
- Appliquer le théorème de Mosca à chaque entrée du CBOM : scorer chaque asset par X + Y > Q pour produire une liste priorisée de migration, présentable au comité de direction.[4]
- Dimensionner le chiffrement symétrique : passer à AES-256 minimum et SHA2-384/512 pour anticiper l’impact de l’algorithme de Grover. C’est une action immédiate, sans attendre la migration asymétrique.
- Déployer ACME et le CLM (article précédent) : l’automatisation des certificats est le prérequis technique de la migration PQC. Sans ACME, la migration hybride est opérationnellement impossible à grande échelle.
- Planifier les pilotes hybrides pour 2027 : identifier 3-5 systèmes protégeant des données long-terme et déployer des certificats hybrides (RSA + ML-DSA) et des cipher suites TLS hybrides (ECDH + ML-KEM). Valider la compatibilité et mesurer l’impact sur les performances.
- Intégrer la PQC dans les achats et la supply chain : exiger la crypto-agilité et le support PQC dans les appels d’offres dès 2026. Évaluer les fournisseurs critiques. Après 2030, ne plus acquérir de produits sans PQC.[18]
- Traiter les systèmes OT non migrables : identifier les équipements industriels sans capacité de mise à jour cryptographique, déployer des passerelles de chiffrement PQC en gateway, renforcer la segmentation réseau, et planifier le remplacement dans le cadre du plan d’investissement.
Métriques et pilotage
Indicateur | Cible | Échéance |
CBOM complet et à jour | 100% des systèmes | Fin 2026 |
Scoring Mosca appliqué à chaque asset du CBOM | 100% | Fin 2026 |
Données long-terme (> 10 ans) protégées en hybride | 100% | 2028 |
Certificats hybrides (RSA + ML-DSA) | 100% | 2030 |
Connexions TLS supportant ML-KEM | 100% | 2030 |
Chiffrement symétrique en AES-256 minimum | 100% | Fin 2027 |
Systèmes OT non migrables identifiés et contournés | 100% | Fin 2027 |
Fournisseurs critiques évalués sur leur roadmap PQC | 100% | Fin 2026 |
Produits achetés sans support PQC | 0 | À partir de 2030 |
Roadmap PQC documentée et validée direction | Oui | Fin 2026 |
La cryptographie post-quantique n’est pas un sujet de recherche lointain, c’est un chantier de transformation qui commence maintenant. Le théorème de Mosca le prouve : pour toute donnée dont la confidentialité dépasse 7-8 ans, la migration est déjà urgente. L’automatisation ACME, déployée pour répondre aux certificats courts de 2026, est le même véhicule qui portera la migration post-quantique de 2027-2035. Le CBOM en est le tableau de bord. L’un ne va pas sans l’autre. Dans une architecture Zero Trust, la confiance cryptographique est le socle sur lequel reposent tous les autres piliers : segmentation réseau, identités privilégiées, API, agents IA. Si ce socle s’effondre, tout s’effondre.