La fin de la période d’évaluation
Pendant huit ans — de 2016 à 2024 — la cryptographie post-quantique était un problème de recherche. Le NIST a sollicité 82 algorithmes candidats auprès de chercheurs de 25 pays, a mené plusieurs rounds d’évaluation, et en août 2024 a publié trois standards finalisés : FIPS 203 (ML-KEM, pour l’encapsulation de clés), FIPS 204 (ML-DSA, pour les signatures numériques) et FIPS 205 (SLH-DSA, un schéma alternatif de signature basé sur des hachages). La période d’évaluation est terminée.
En parallèle, la NSA a publié CNSA 2.0 (Suite d’algorithmes nationaux de sécurité commerciale 2.0) avec un calendrier contraignant pour les systèmes de sécurité nationale américains : algorithmes quantiques-sécurisés requis dans tous les nouveaux systèmes d’ici janvier 2027, migration complète des applications d’ici 2030, migration complète de l’infrastructure d’ici 2035. L’ANSSI française a annoncé qu’à partir de 2027, les produits ne recevront pas de certification de cybersécurité française à moins d’incorporer la cryptographie post-quantique. Google a déployé ML-KEM dans Chrome en 2024. OpenSSL 3.5 inclut le support ML-KEM. L’infrastructure n’est plus expérimentale.
La menace qui alimente cette urgence n’est pas hypothétique. Les attaques « récolter maintenant, déchiffrer plus tard » (HNDL) — où des adversaires capturent des communications chiffrées aujourd’hui pour les déchiffrer une fois les ordinateurs quantiques mûrs — sont confirmées actives. L’analyse du Boston Consulting Group indique que « commencer en 2030 sera déjà trop tard » pour les données exigeant une confidentialité de 10 ans. Cette fenêtre comprend les données financières, les communications gouvernementales, la propriété intellectuelle et les données de santé personnelles actuellement transmises sur des canaux cryptographiques classiques.
Le problème de migration est opérationnel, pas algorithmique
L’enseignement le plus important du cadre de migration de Meta d’avril 2026 est que le problème difficile de la migration PQC n’est pas les algorithmes eux-mêmes — c’est la complexité opérationnelle d’exécuter la transition sur un grand environnement d’entreprise hétérogène.
Meta définit cinq niveaux de maturité pour la préparation PQC : PQ-Non conscient (aucune sensibilisation à la menace quantique), PQ-Conscient (évaluation initiale effectuée, implémentation non démarrée), PQ-Prêt (solution conçue mais non déployée), PQ-Durci (toutes les protections disponibles déployées, bien que certaines primitives manquent d’alternatives quantiques-sécurisées) et PQ-Activé (protection quantique complète déployée). La plupart des grandes entreprises, en 2026, se situent à PQ-Conscient ou PQ-Prêt précoce — ce qui signifie qu’elles ont évalué le risque mais n’ont pas encore commencé le déploiement.
Les défis de migration identifiés par Meta sont structurels : les dépendances cryptographiques sont réparties sur des milliers d’applications, de services, d’API et de composants d’infrastructure. Beaucoup se trouvent dans des bibliothèques tierces, des micrologiciels matériels ou des systèmes hérités à mise à jour limitée. L’échange de clés se produit au niveau du protocole (TLS, SSH, VPN), ce qui signifie que toute infrastructure terminant des connexions chiffrées — équilibreurs de charge, pare-feux, HSM, passerelles API — nécessite des mises à jour ou des remplacements. Et la transition doit être exécutée sans briser les systèmes existants, car une migration manquée qui interrompt TLS pour une plateforme bancaire ou un portail gouvernemental n’est pas un résultat acceptable.
Publicité
Trois étapes pour la feuille de route d’entreprise
1. Réalisez un inventaire cryptographique avec un cadre de niveaux de risque
Vous ne pouvez pas migrer ce que vous ne pouvez pas trouver. La première étape est un inventaire cryptographique complet — identifier chaque application, service, API et composant d’infrastructure utilisant RSA, ECDH ou ECDSA, et classer chacun par niveau de risque HNDL.
Le cadre de priorisation de Meta définit trois niveaux : haute priorité (applications vulnérables aux attaques HNDL hors ligne — données avec des exigences de confidentialité de 10+ ans transmises via TLS), priorité moyenne (applications vulnérables aux futures attaques en ligne lorsque des CRQC existeront), et faible priorité (données à courtes fenêtres de confidentialité où le déchiffrement futur apporte peu de valeur aux adversaires).
En pratique : le chiffrement des transactions bancaires, les communications gouvernementales, les données de santé et la propriété intellectuelle constituent le Niveau 1. Le trafic web standard, les outils internes à courte durée de vie des données et les environnements de développement constituent le Niveau 3. Tout le reste tombe dans le Niveau 2 en fonction de la sensibilité et de la longévité des données impliquées.
Des outils automatisés de découverte cryptographique (Venafi, Keyfactor et des options open source) peuvent analyser les inventaires de certificats et identifier les algorithmes d’échange de clés à grande échelle. Pour les services internes, l’analyse du trafic réseau peut identifier les handshakes RSA/ECDH au niveau des paquets. La sortie de l’inventaire doit alimenter directement un plan de séquençage de migration — le niveau de risque le plus élevé en premier.
2. Déployez la cryptographie hybride pour les nouveaux déploiements dès maintenant
Les recommandations consensuelles de Meta, de l’ANSSI, du NIST et du NCSC britannique sont identiques : utilisez la cryptographie hybride — classique plus post-quantique en parallèle — pendant la période de transition, plutôt que de passer brusquement à la PQC seule. Cela fournit une assurance sécurité contre la possibilité (improbable mais non nulle) qu’un algorithme PQC nouvellement standardisé ait une faiblesse non découverte.
ML-KEM768 (niveau de sécurité NIST 3, équivalent à AES-192) est l’algorithme d’encapsulation de clés recommandé pour TLS. L’approche hybride combine ECDH P-256 ou X25519 avec ML-KEM — les deux sont calculés et la fonction de dérivation de clés utilise les deux sorties. Si l’un des algorithmes est compromis, l’autre assure la protection. Le déploiement de Chrome utilise X25519+ML-KEM768. OpenSSL 3.5 prend en charge ce mode hybride nativement.
Pour les nouveaux déploiements d’infrastructure en 2026-2027 — pare-feux, équilibreurs de charge, HSM, concentrateurs VPN — le support ML-KEM/ML-DSA doit être une exigence d’approvisionnement. Les HSM méritent une urgence particulière : ils gèrent les clés privées pour la PKI, la signature de code et les systèmes d’authentification, ont des cycles de remplacement de 5 à 7 ans, et la plupart des HSM actuels nécessitent des mises à jour de micrologiciels ou des remplacements matériels pour la prise en charge PQC. Les HSM approvisionnés en 2026 sans support PQC seront un goulot d’étranglement en 2028-2030 lorsque les cibles de migration l’exigeront.
3. Établissez un cadre de gouvernance qui empêche les régressions
La migration technique est la moitié la plus facile du problème. Le problème de gouvernance — s’assurer que les nouveaux systèmes déployés pendant la période de transition ne réintroduisent pas de cryptographie classique uniquement — est plus difficile. Meta appelle cela « mettre en place des garde-fous » : mettre à jour les lignes directrices cryptographiques pour interdire la nouvelle génération de clés vulnérables, empêcher l’utilisation des API affectées dans le nouveau code, et déprécier les interfaces classiques uniquement selon un calendrier publié.
Pour les organisations d’entreprise, le cadre de gouvernance requiert : un standard de crypto-agilité (quels algorithmes sont approuvés, à quelles longueurs de clés minimales, avec quelles exigences hybrides), un calendrier de dépréciation pour les configurations classiques uniquement, un processus d’exceptions cryptographiques (que se passe-t-il lorsqu’un système tiers ne peut pas être mis à jour selon le calendrier) et un audit annuel par rapport au standard.
La projection de marché de 15 milliards de dollars d’ici 2030 suppose que les entreprises budgétisent 2 à 5 % de leurs dépenses annuelles de sécurité IT par an pour la migration PQC. Pour une entreprise disposant d’un budget annuel de sécurité de 20 millions de dollars, cela représente 400 000 à 1 000 000 de dollars par an alloués à cette transition — un programme d’investissement, pas un projet ponctuel. Les conseils d’administration et les directeurs financiers doivent comprendre ce cadrage avant que les équipes techniques commencent à présenter des plans de migration.
Ce qui vient ensuite : le calendrier PQC 2026-2030
Les 18 prochains mois clarifieront considérablement le paysage commercial. NIST IR 8547 (recommandations sur la sélection et le déploiement des algorithmes) est en projet public ; la version finale donnera aux entreprises un langage d’approvisionnement plus clair. HQC (un algorithme d’encapsulation de clés de sauvegarde offrant une diversité mathématique par rapport à la base lattice de ML-KEM) pourrait être standardisé, offrant aux grandes organisations une option de diversification.
Les navigateurs et les fournisseurs CDN déploient déjà ML-KEM à grande échelle. Cloudflare, Google et Akamai gèrent suffisamment de trafic TLS mondial pour que leurs décisions de déploiement établissent un standard de fait pour l’écosystème plus large. Les entreprises qui n’ont pas déployé la PQC verront leurs schémas de trafic réseau évoluer en 2026-2027 au fur et à mesure que les contreparties se mettent à niveau — créant une pression d’interopérabilité pour suivre.
L’Agence de sécurité cybernétique de Singapour, le NCSC britannique et l’Australian Cyber Security Centre ont tous publié des feuilles de route de migration PQC. La convergence réglementaire internationale est claire : la PQC n’est pas optionnelle pour les organisations opérant dans des secteurs réglementés ou avec des contreparties internationales. La seule variable est la vitesse à laquelle les organisations reconnaissent que leur objectif 2030 nécessite une planification en 2026.
Questions fréquentes
Dans quelle mesure la menace post-quantique est-elle urgente si les ordinateurs quantiques capables de casser RSA n’existent pas encore ?
La menace est urgente aujourd’hui en raison des attaques « récolter maintenant, déchiffrer plus tard ». Des adversaires — principalement des acteurs étatiques — collectent activement des communications chiffrées maintenant dans l’intention de les déchiffrer une fois que des ordinateurs quantiques cryptographiquement pertinents (CRQC) existeront. Si les données transmises aujourd’hui ont une exigence de confidentialité s’étendant jusqu’en 2035 ou au-delà (secrets gouvernementaux, dossiers financiers à long terme, données médicales), et que des CRQC arrivent avant 2035, ces données sont rétrospectivement exposées. Le Boston Consulting Group estime que « commencer en 2030 sera déjà trop tard » pour cette catégorie de données.
Quelle est la différence pratique entre ML-KEM et le RSA qu’il remplace ?
ML-KEM (FIPS 203, anciennement CRYSTALS-Kyber) est un mécanisme d’encapsulation de clés basé sur la cryptographie lattice (le problème Module Learning With Errors), qui est considéré comme difficile à résoudre pour les ordinateurs quantiques. RSA est basé sur la difficulté de factoriser de grands entiers — un problème que l’algorithme de Shor sur un ordinateur quantique suffisamment puissant peut résoudre efficacement. ML-KEM au niveau 3 (ML-KEM768) fournit une sécurité classique approximativement équivalente à AES-192, avec des tailles de clés significativement plus petites que RSA-4096. Les connexions TLS utilisant ML-KEM768 ont des paquets de handshake plus grands qu’ECDH (environ 1,5 Ko contre 64 octets) mais des frais généraux de performance négligeables sur le matériel moderne.
Pourquoi l’approche hybride (classique + PQC) est-elle sensée pendant la transition ?
L’approche hybride combine un algorithme classique (ECDH P-256 ou X25519) avec ML-KEM dans la même dérivation de clés. Un attaquant doit casser les deux algorithmes pour récupérer la clé. Cela fournit une protection contre deux scénarios de risque distincts : (1) un attaquant classique aujourd’hui qui ne peut pas casser les algorithmes classiques, et (2) un futur attaquant quantique qui peut casser les algorithmes classiques mais pas les algorithmes PQC. L’approche hybride coûte légèrement plus en calcul et en taille de paquets mais élimine le risque qu’un algorithme PQC nouvellement standardisé ait une faiblesse non découverte. L’ANSSI, le NIST et le NCSC britannique recommandent tous le déploiement hybride pendant la période de transition.
—
Sources et lectures complémentaires
- Migration vers la cryptographie post-quantique chez Meta : cadre, leçons et enseignements — Meta Engineering
- NIST IR 8547 : Standards de cryptographie post-quantique — NIST CSRC
- La migration post-quantique à 15 milliards de dollars — PR Newswire
- Cryptographie post-quantique pour l’authentification : Guide de migration d’entreprise 2026 — Security Boulevard
- Migration de cryptographie post-quantique 2026 — ISACA Journal
- Migration de cryptographie post-quantique 2026 : préparation des entreprises — Programming Helper Tech
🔗 Intelligence Connexe
Cryptographie post-quantique : les échéances d’avril 2026 sont arrivées
Collecter maintenant, déchiffrer plus tard : pourquoi la menace quantique sur le chiffrement d’entreprise est déjà là
L’horloge quantique tourne : pourquoi chaque organisation doit agir maintenant sur la
Cryptographie Post-Quantique : La feuille de route algérienne avant que 2027 ne vous bloque
