La migration vers la cryptographie post-quantique consiste à repérer tous les endroits où votre organisation utilise une cryptographie à clé publique vulnérable aux attaques quantiques, à classer les risques par ordre de priorité, à tester des solutions de remplacement approuvées par le NIST, puis à les déployer sans perturber les systèmes. Commencez dès maintenant si vous protégez des données qui doivent rester confidentielles pendant des années. Le NIST a finalisé ML-KEM, ML-DSA et SLH-DSA en 2024 et a indiqué qu’ils étaient prêts pour une utilisation immédiate, mais la migration réelle prendra des années.
Pourquoi la migration vers la cryptographie post-quantique est passée de la théorie au plan de projet
L’intention de recherche ici est informative avec une forte dimension pratique : vous voulez savoir quoi faire, dans quel ordre et pourquoi le timing compte. La version courte est inconfortable. Attendre l’arrivée d’un grand ordinateur quantique cryptographiquement pertinent est le mauvais déclencheur.
Les attaquants peuvent capturer dès maintenant du trafic chiffré ou des fichiers stockés et les conserver pour les déchiffrer plus tard. Le NIST, Google et d’autres équipes de sécurité décrivent cela comme « harvest now, decrypt later » ou « store now, decrypt later ». Si vos contrats, dossiers de santé, secrets d’État, conceptions de produits ou archives clients doivent rester secrets jusque dans les années 2030, le compteur de risque tourne déjà.
Le NIST a changé la donne le 13 août 2024 en approuvant les trois premières normes de cryptographie post-quantique : FIPS 203 pour ML-KEM, FIPS 204 pour ML-DSA et FIPS 205 pour SLH-DSA. FIPS 203 provient de CRYSTALS-Kyber, FIPS 204 de CRYSTALS-Dilithium et FIPS 205 de SPHINCS+. Le NIST a déclaré que les normes finalisées étaient « prêtes pour une utilisation immédiate » et a encouragé les administrateurs à commencer l’intégration, car l’adoption complète prend du temps.
Il existe un autre point de pression. Le 7 septembre 2022, la NSA a publié les exigences CNSA 2.0 pour les National Security Systems et a demandé aux propriétaires, exploitants et fournisseurs de planifier, préparer et budgétiser la transition vers des algorithmes résistants aux attaques quantiques. Cette formulation est importante, car les fournisseurs ont tendance à bouger lorsque les équipes d’approvisionnement commencent à poser des questions précises.
De quoi vous éloignez-vous exactement ?
Une migration vers la cryptographie post-quantique n’est pas un simple remplacement d’un certificat par un autre. Vous abandonnez des systèmes à clé publique que l’on considère comme vulnérables à de futures attaques quantiques, en particulier RSA, Diffie-Hellman sur corps finis, Diffie-Hellman sur courbes elliptiques et ECDSA dans les rôles où des algorithmes quantiques pourraient les compromettre.
Le chiffrement symétrique, c’est une autre histoire. AES et les fonctions de hachage de la famille SHA ne sont pas remplacés de la même manière, même si les tailles de clé et les marges de sécurité méritent toujours d’être revues. Le travail compliqué se trouve dans TLS, les VPN, SSH, la signature de code, l’identité des appareils, la PKI, S/MIME, les systèmes de paiement, les mises à jour de firmware, les API, les systèmes de gestion des clés, les intégrations HSM et les anciennes applications Java que personne ne veut toucher.
Le NIST et le National Cybersecurity Center of Excellence décrivent deux grands chantiers pour la migration de 2024 à 2026 : la découverte et l’inventaire cryptographiques, puis les tests d’interopérabilité des algorithmes PQC normalisés par le NIST. Cela semble austère. C’est pourtant tout le travail.
Si votre équipe suit déjà des investissements plus larges en sécurité, reliez cet effort à votre planification des risques existante au lieu de le traiter comme un projet scientifique. Les mêmes discussions budgétaires qui apparaissent dans planification des tendances de la cybersécurité pour 2026 s’appliquent ici : visibilité des actifs, responsabilité des fournisseurs et modernisation par phases valent mieux que des achats paniqués.
Les normes du NIST que vous pouvez utiliser dès maintenant, et ce qui reste encore à venir
Trois normes constituent le point de départ pratique pour la plupart des organisations. ML-KEM, normalisé comme FIPS 203 en 2024, est utilisé pour l’établissement de clés et les flux de travail généraux de chiffrement lorsque l’encapsulation de clé est appropriée. ML-DSA, normalisé comme FIPS 204 en 2024, sert aux signatures numériques. SLH-DSA, normalisé comme FIPS 205 en 2024, est une option de signature numérique sans état fondée sur le hachage.
N’interprétez pas trop cette liste. Cela ne signifie pas que chaque protocole, bibliothèque, service cloud, appliance, autorité de certification et régime de conformité est également prêt. Les normes sont nécessaires. Les produits réellement déployables, c’est autre chose.
| Norme ou élément | Année | Basé sur | Rôle principal | Pertinence pour la migration |
|---|---|---|---|---|
| FIPS 203 : ML-KEM | 2024 | CRYSTALS-Kyber | Établissement de clés / chiffrement | Principal KEM approuvé par le NIST à tester pour TLS, VPN et d'autres cas d'usage d'échange de clés |
| FIPS 204 : ML-DSA | 2024 | CRYSTALS-Dilithium | Signatures numériques | Principal candidat de signature pour les certificats, la signature et les flux de travail d'identité |
| FIPS 205 : SLH-DSA | 2024 | SPHINCS+ | Signatures sans état basées sur le hachage | Utile lorsque des signatures conservatrices basées sur le hachage sont préférées, sous réserve de compromis en matière de performances et de taille |
| HQC | Sélectionné en 2025 | Famille HQC | KEM supplémentaire | Le NIST l'a sélectionné pour compléter ML-KEM ; la publication finale était attendue après le projet et l'examen des commentaires du public, environ deux ans à partir de 2025 |
| FIPS 206 : FN-DSA | Travail de projet en 2025 | Falcon | Signatures numériques | Norme de signature supplémentaire encore en cours de développement en 2025 |
HQC mérite une mention attentive. Le 11 mars 2025, le NIST a sélectionné HQC pour la normalisation en tant que second mécanisme d’encapsulation de clé afin de compléter ML-KEM, avec une publication finale attendue dans environ deux ans après l’examen du projet et la période de commentaires publics. C’est utile pour une diversité future, pas une raison de suspendre dès aujourd’hui les tests de ML-KEM.
Le NIST a également poursuivi en 2025 la rédaction de la norme FIPS 206 pour FN-DSA, basée sur Falcon. Si vous exploitez un environnement fortement contraint où la taille des signatures, la vitesse de vérification ou la complexité de mise en œuvre comptent, suivez ces travaux. Pour la plupart des organisations, toutefois, la démarche la plus sensée consiste à faire l’inventaire dès maintenant et à lancer des pilotes avec les normes de 2024 là où le support fournisseur existe.
Établissez votre inventaire cryptographique avant d’acheter quoi que ce soit
Le plus grand écueil dont personne ne parle assez fort : beaucoup d’entreprises ne savent pas où se trouve leur cryptographie à clé publique. Elles connaissent leur autorité de certification et peut-être leurs points de terminaison TLS exposés sur Internet. Elles ne savent pas ce qu’il y a dans les contrôleurs industriels, les applications mobiles, les pipelines de build, les API des fournisseurs, les outils de sauvegarde, les entrepôts de données, les anciens concentrateurs VPN ou les intégrations SaaS-to-SaaS.
Commencez par la découverte. Les recommandations de migration du NIST/NCCoE indiquent que les organisations doivent identifier les usages d’algorithmes à clé publique vulnérables au quantique dans le matériel, les logiciels et les services, puis établir des inventaires cryptographiques et des feuilles de route hiérarchisées. En clair, vous avez besoin d’une nomenclature de votre cryptographie.
- Dressez la liste des systèmes utilisant RSA, Diffie-Hellman, elliptic-curve Diffie-Hellman, ECDSA et des mécanismes à clé publique apparentés.
- Consignez où chaque usage apparaît : TLS, SSH, VPN, PKI, signature de code, signature de firmware, S/MIME, chiffrement de base de données, authentification d’API, HSM ou services gérés par un fournisseur.
- Étiquetez les données protégées par chaque système et la durée pendant laquelle elles doivent rester confidentielles.
- Identifiez les dépendances de protocole et de bibliothèque, y compris OpenSSL, BoringSSL, les fournisseurs de cryptographie Java, le firmware HSM et les services cloud KMS, le cas échéant.
- Demandez aux fournisseurs leurs feuilles de route PQC, les algorithmes NIST pris en charge, les options en mode hybride, les plans de certification et les échéances de mise à niveau.
- Classez les systèmes selon l’exposition, la sensibilité des données, la criticité opérationnelle et la difficulté de remplacement.
Un calcul concret aide. Supposons que vous ayez 240 applications et qu’une première analyse montre que 35% utilisent un TLS exposé à l’extérieur, 20% utilisent un mTLS interne, 15% s’appuient sur la signature de code et 10% intègrent des fonctions SSH ou VPN. Même avec des recoupements, vous pourriez avoir devant vous 120 à 160 points de contact cryptographiques, et non 240 simples mises à niveau d’applications. Si chaque point de contact nécessite un entretien avec un responsable, une vérification fournisseur, un test et une fenêtre de changement, une migration « modeste » devient des centaines de tâches.
Les services cloud rendent l’inventaire plus difficile, pas plus facile. Vous ne contrôlez peut-être pas l’implémentation cryptographique à l’intérieur d’une base de données gérée, d’un CDN, d’un fournisseur d’identité ou d’une passerelle de paiement, mais la décision de risque vous appartient toujours. Le reporting public de Cloudflare sur les tendances d’adoption du chiffrement post-quantique est un rappel utile que l’adoption au niveau des plateformes peut progresser rapidement tandis que les dépendances des entreprises restent à la traîne.
Donnez la priorité aux systèmes où le retard crée de vrais dommages
Toutes les charges de travail ne méritent pas le même degré d’urgence. Une page marketing publique avec un TLS ordinaire n’est pas la même chose qu’une archive de recherche, un dossier administratif public ou des dossiers patients qui doivent rester privés pendant des décennies. Votre migration vers la cryptographie post-quantique doit commencer là où la confidentialité de longue durée et l’interception à forte valeur se recoupent.
Classez en premier les systèmes qui protègent des données ayant une longue durée de secret. Les dossiers juridiques, les pièces d’identité, les dossiers de fusion, la recherche pharmaceutique, les informations de défense, les clés de signature de code source et les autorités de certification racines ou intermédiaires méritent tous une attention précoce. Un VPN transportant les e-mails de la direction peut être plus urgent qu’un tableau de bord interne avec une télémétrie jetable.
Il existe un contre-argument qu’il faut prendre au sérieux : déployer trop tôt des intégrations immatures peut créer des pannes et de nouvelles vulnérabilités. Je suis d’accord. Basculer aveuglément des systèmes de production vers tout ce que votre fournisseur étiquette comme « PQC-ready » est imprudent. La meilleure réponse est le test hybride, un déploiement progressif et l’agilité cryptographique, pas un retard déguisé en prudence.
L’agilité cryptographique signifie que vous pouvez changer d’algorithmes, de tailles de clés, de bibliothèques et de profils de certificats sans reconstruire la moitié de votre parc. Si vos systèmes codent en dur les algorithmes ou supposent des tailles de signature minimes, vous avez un problème de conception que la PQC mettra en évidence. Le coût caché ressemble à celui de toute mise à niveau technologique majeure ; la pression budgétaire décrite dans les coûts de modernisation technologique des entreprises s’applique douloureusement bien à la cryptographie.
Tester l’interopérabilité avant le déploiement en production
Le NIST/NCCoE identifie les tests d’interopérabilité des algorithmes PQC normalisés comme un chantier de migration distinct, et ce pour une bonne raison. Les algorithmes peuvent être solides alors que les implémentations ne sont pas d’accord, fonctionnent mal ou échouent sous de vraies contraintes de protocole. Les certificats deviennent plus volumineux. Les handshakes peuvent changer. Les appareils embarqués peuvent manquer de mémoire. Les middleboxes peuvent mal se comporter.
Construisez une plateforme de test hors production qui reflète vos schémas de trafic réels. Incluez les navigateurs, les clients mobiles, les passerelles API, les équilibreurs de charge, les service meshes, les clients VPN, les HSM, les outils de journalisation, les produits de sécurité des terminaux et les systèmes de supervision. Honnêtement, c’est là que beaucoup de plans de migration deviennent réels pour la première fois.
La position de Google mérite d’être suivie, car ses décisions d’infrastructure ont tendance à influencer les navigateurs, les piles TLS et les attentes des développeurs. Des informations publiques d’avril 2026 indiquaient que Google s’était fixé une échéance interne à 2029 pour « sécuriser l’ère quantique » en migrant vers des méthodes PQC, le risque store-now-decrypt-later étant considéré comme une préoccupation actuelle. Considérez cela comme un signal, pas comme une norme.
Les conférences sur la sécurité transforment elles aussi la PQC, passant de la recherche aux feuilles de route produit. Si vous suivez les affirmations des fournisseurs lors d’événements tels que la RSAC, comparez-les à une couverture fondée de les innovations en cybersécurité présentées à la RSAC 2026 puis posez une question terre à terre : ce produit peut-il montrer une intégration fonctionnelle avec FIPS 203, FIPS 204 ou FIPS 205 dans votre environnement ?
Surveillez les cas limites. La vérification hors ligne des firmwares peut nécessiter des signatures PQC tout en disposant d’un stockage limité. Les appareils IoT peuvent ne pas prendre en charge des clés ou des signatures plus volumineuses sans modifications du firmware. Les certificats racine à longue durée de vie peuvent être difficiles à faire tourner. Les archives de sauvegarde chiffrées selon d’anciennes hypothèses d’établissement de clés peuvent rester exposées si l’échange de clés qui les protégeait a été capturé.
Une feuille de route pratique pour la migration vers la cryptographie post-quantique
Une feuille de route viable comporte des étapes, des responsables et des dates. Ce ne doit pas être une diapositive qui dit « surveiller le risque quantique ». Les orientations du NIST, de la CISA et alignées sur la NSA entre 2024 et 2026 pointent vers la même séquence : inventorier la cryptographie, identifier les usages de clés publiques vulnérables au quantique, prioriser les données sensibles à longue durée de vie et les systèmes critiques, tester l’interopérabilité, mettre à jour les produits et les protocoles, déployer par phases et maintenir l’agilité cryptographique.
Pour la planification 2026, je répartirais le travail en quatre volets. Premièrement, l’inventaire des actifs et la découverte cryptographique. Deuxièmement, la préparation des fournisseurs et des protocoles. Troisièmement, les tests d’interopérabilité en laboratoire. Quatrièmement, la migration en production des systèmes les plus à risque. L’ordre compte, mais certains travaux peuvent être menés en parallèle une fois que l’inventaire est suffisamment fiable.
Les achats ont besoin d’un nouveau langage. Demandez aux fournisseurs quelles normes PQC du NIST ils prennent en charge, si la prise en charge est hybride ou purement PQC, quelles versions sont requises, comment les certificats et les clés sont gérés, et si la fonctionnalité est généralement disponible ou seulement en préversion. Demandez des dates. Un marketing vague autour du « quantum-safe » n’est pas un plan.
Les équipes en charge des politiques doivent aussi surveiller les échéances du secteur public. Une présentation du NIST de 2025 faisait référence à une migration obligatoire du gouvernement américain vers la PQC d’ici 2035, soutenue par le NIST IR 8547 et les travaux de migration du NCCoE. Même si vous n’êtes pas une agence fédérale, ce type de calendrier peut façonner les exigences des fournisseurs, les audits et la formulation contractuelle.
Enfin, reliez le projet à la stratégie quantique au lieu de le traiter comme une corvée ponctuelle de conformité. Le débat plus large sur la place de l’informatique quantique parmi les grandes évolutions technologiques est intéressant, mais votre équipe de sécurité a besoin d’une réponse plus ciblée : quels secrets auront encore de l’importance lorsque des machines quantiques pertinentes sur le plan cryptographique arriveront ?
FAQ
Quand une entreprise devrait-elle commencer la migration vers la cryptographie post-quantique ?
Commencez en 2026 si vous protégez des données qui doivent rester confidentielles pendant des années, ou si vous exploitez des systèmes critiques avec de longs cycles de mise à niveau. NIST a indiqué que les trois premières normes PQC finalisées étaient prêtes à être utilisées immédiatement en 2024, tout en avertissant que l’intégration complète prendra du temps.
Quelle est la première étape d’une migration PQC ?
La première étape consiste à réaliser un inventaire cryptographique. Identifiez où RSA, Diffie-Hellman, l’échange de clés à courbe elliptique, ECDSA et les mécanismes à clé publique associés apparaissent dans le matériel, les logiciels, les services cloud, les certificats, les systèmes de signature et les produits des fournisseurs.
ML-KEM est-il le même que Kyber ?
ML-KEM, normalisé en tant que FIPS 203 en 2024, est dérivé de CRYSTALS-Kyber. Pour la planification de la migration, utilisez le nom standard du NIST lors de la rédaction des exigences et des clauses d’approvisionnement.
La cryptographie post-quantique remplacera-t-elle AES ?
Pas de la même manière. La cible urgente de la migration est la cryptographie à clé publique vulnérable au quantique utilisée pour l’échange de clés et les signatures ; le chiffrement symétrique tel qu’AES nécessite un examen de la marge de sécurité, et non un remplacement PQC à l’identique.
Faut-il attendre HQC ou FN-DSA avant de migrer ?
Habituellement non. HQC a été sélectionné par NIST en 2025 comme KEM supplémentaire, et les travaux sur FN-DSA se sont poursuivis en 2025, mais les organisations peuvent dès maintenant inventorier, prioriser et tester avec les normes de 2024.
FR 
EN 
ES