Cryptographie post-quantique : que préparer avant les grandes machines ?

La cryptographie post-quantique vise à protéger les échanges et les signatures contre des attaques qu’un ordinateur quantique suffisamment capable pourrait rendre possibles. Elle fonctionne sur des ordinateurs classiques : il n’est pas nécessaire de posséder une machine quantique pour l’utiliser. La préparation commence par un inventaire des usages cryptographiques, la durée de confidentialité des données et les possibilités de mise à jour des systèmes. Elle ne consiste pas à remplacer précipitamment un algorithme dans chaque application. La migration doit préserver la sécurité actuelle, la compatibilité et les preuves de fonctionnement tout en introduisant des mécanismes adaptés à la menace envisagée.

Une menace précise, pas la fin de toute sécurité numérique

Certaines constructions cryptographiques à clé publique reposent sur des problèmes mathématiques qu’un ordinateur quantique suffisamment puissant pourrait résoudre plus efficacement que les méthodes classiques connues. Le NIST explique cette menace et la préparation des algorithmes post-quantiques. La condition « suffisamment puissant » est essentielle : une annonce de processeur quantique ne prouve pas qu’il puisse casser les systèmes cryptographiques utilisés à grande échelle.

Il faut aussi éviter de placer tous les mécanismes dans le même panier. Établir une clé de communication, signer une mise à jour et chiffrer un volume de données sont des fonctions différentes. Une migration doit repérer le rôle de chaque mécanisme et ses dépendances. Le terme général « chiffrement » ne permet pas de décrire tout cet ensemble.

La cryptographie post-quantique, souvent abrégée PQC, utilise des constructions conçues pour résister aux attaques classiques et quantiques pertinentes. Leur sécurité reste fondée sur des hypothèses et une analyse collective, pas sur une garantie absolue valable pour tout avenir. Cette précision ne rend pas le travail inutile : elle explique pourquoi la normalisation, l’évaluation des implémentations et la capacité à évoluer restent nécessaires.

Pourquoi agir si la date de la menace est inconnue ?

Le NIST indique qu’on ne sait pas prédire précisément l’arrivée d’une machine pertinente pour ces attaques. Deux raisons justifient pourtant la préparation. D’abord, intégrer de nouveaux mécanismes dans un vaste système prend du temps. Ensuite, certaines données doivent rester confidentielles longtemps après leur transmission.

Un adversaire peut conserver aujourd’hui des communications chiffrées en espérant les déchiffrer plus tard. Le NIST décrit ce scénario sous l’expression harvest now, decrypt later, c’est-à-dire collecter maintenant et déchiffrer ultérieurement. La valeur de cette menace dépend de la durée pendant laquelle les informations conservent leur sensibilité ; toutes les données ne présentent pas le même enjeu temporel.

Prenons une situation fictive sans calendrier prédictif. Une organisation échange un dossier qui doit rester secret pendant de nombreuses années, alors que la plateforme utilisée ne peut être remplacée rapidement. Le problème n’est pas seulement la date possible d’une attaque : c’est l’intersection entre la durée de protection attendue, le temps de migration et l’incertitude technique. Cette manière de raisonner aide à prioriser sans prétendre connaître l’année d’une rupture.

L’inventaire doit suivre les usages

Un inventaire utile ne se limite pas à une liste de noms d’algorithmes. Il relie un mécanisme à une fonction, un système, un responsable et une possibilité de modification. Où sont établies les clés ? Quelles signatures sont vérifiées ? Quels équipements possèdent des composants difficiles à mettre à jour ? Quelles applications dépendent d’un service externe ?

L’ANSSI recommande d’intégrer la menace quantique à l’analyse de risque et de commencer un inventaire des usages. Sa page distingue la préparation des organisations, les produits de confiance et les cadres d’évaluation. Cette recommandation ne signifie pas qu’un même calendrier réglementaire s’appliquerait à toute entreprise. Le périmètre propre à l’organisation doit être vérifié avec les textes qui lui sont applicables.

La découverte technique doit être complétée par une enquête auprès des équipes et des fournisseurs. Certains mécanismes sont inclus dans des bibliothèques ou des équipements dont l’utilisateur ne modifie pas directement le code. L’organisation doit alors savoir quelle version est employée, qui la maintient et comment les changements seront distribués. Une dépendance inconnue est difficile à migrer de manière contrôlée.

L’inventaire gagne à distinguer ce qui a été observé de ce qui est seulement déclaré. Un fournisseur peut annoncer une feuille de route ; cela ne prouve pas qu’une version compatible soit déjà livrée dans le système étudié. Une fonction activable peut rester désactivée. Le registre doit donc conserver la preuve et son périmètre, pas seulement une réponse oui ou non.

Un algorithme normalisé n’est pas un service migré

Le NIST a publié ses trois premières normes post-quantiques finalisées en 2024, comme le rappelle sa présentation. Ce jalon concerne les mécanismes définis par ces documents. Il ne démontre pas que toutes les applications, tous les protocoles ou tous les équipements les utilisent correctement.

Une mise en œuvre doit intégrer les formats, la gestion des clés, les échanges, les erreurs et les contraintes de performance. Le comportement des autres participants compte également : un service ne communique pas dans le vide. Les versions des clients, des bibliothèques et des équipements intermédiaires doivent être compatibles avec le changement envisagé.

Cette distinction permet de poser une question plus précise à un fournisseur. Au lieu de demander seulement si son produit est « post-quantique », il faut demander quelle fonction l’est, avec quels mécanismes, dans quelle version et selon quelles conditions d’activation. Il faut aussi distinguer une démonstration, une fonctionnalité expérimentale et une version couverte par le support habituel.

Les caractéristiques de performance doivent être testées dans le contexte d’usage. Une taille de message différente peut affecter un équipement contraint ou un protocole donné. Un calcul rapide sur un serveur ne prédit pas le comportement d’un appareil embarqué. La migration exige donc des essais qui correspondent aux systèmes réellement exploités.

L’hybridation protège la transition sous conditions

L’ANSSI présente des mécanismes hybrides qui combinent un mécanisme à clé publique éprouvé et un mécanisme post-quantique. Le but est de préparer une protection supplémentaire tout en préservant les garanties attendues du mécanisme existant. Il ne suffit pas d’assembler arbitrairement deux algorithmes pour obtenir ce résultat.

La construction, ses paramètres et son implémentation doivent être analysés. Une erreur d’intégration peut compromettre un système même si les briques prises séparément sont reconnues. Cet article ne fournit donc pas de recette de combinaison ni de code de déploiement. La sélection doit s’appuyer sur les recommandations techniques actuelles et sur des implémentations évaluées pour le contexte concerné.

Cette prudence porte sur l’ingénierie de la transition, pas sur une invitation à attendre sans préparer. L’inventaire, la clarification des responsabilités et les essais contrôlés peuvent avancer pendant que les choix précis sont examinés. Le travail préparatoire réduit le nombre de décisions qui devront être prises dans l’urgence.

Le schéma décrit un parcours de migration. Chaque flèche représente un passage assorti de preuves : inventaire documenté, priorités justifiées, essais reproductibles, déploiement contrôlé et vérification. Il ne fixe aucune date réglementaire et ne valide aucun produit.

La cryptoagilité doit être démontrée

La capacité à faire évoluer les mécanismes cryptographiques est souvent appelée cryptoagilité. Pour l’évaluer, il faut aller au-delà d’une promesse. Peut-on modifier un algorithme sans remplacer tout l’équipement ? Comment les nouvelles versions sont-elles distribuées ? Comment l’authenticité des mises à jour est-elle protégée ? Que deviennent les systèmes qui ne peuvent pas évoluer ?

Une architecture très configurable n’est pas automatiquement plus sûre. Elle doit empêcher les choix incompatibles avec la politique de sécurité et rendre les modifications traçables. La possibilité de changement doit donc être associée à des règles d’administration, à des tests et à une visibilité sur l’état réellement actif.

Le retour arrière mérite aussi une réflexion. Une procédure de reprise peut être nécessaire pour rétablir un service après un incident, mais elle ne doit pas devenir un mécanisme invisible de dégradation permanente. Les conditions de reprise et les conséquences de sécurité doivent être connues avant le changement. Le dossier de migration doit traiter ensemble disponibilité et protection.

Prioriser sans inventer une urgence identique partout

La grille suivante est une proposition d’organisation éditoriale, pas un référentiel de conformité. Elle sert à relier les informations de l’inventaire à des décisions de préparation.

Dimension	Question	Preuve attendue
Durée de confidentialité	Jusqu’à quand les données restent-elles sensibles ?	Classification et besoin métier documentés
Durée de vie du système	Peut-il encore être utilisé lors d’une future transition ?	Cycle de renouvellement et support
Possibilité de mise à jour	Quels mécanismes peuvent réellement changer ?	Essai et documentation de version
Dépendances	Qui doit évoluer en même temps ?	Cartographie des clients et fournisseurs
Compatibilité	Le service conserve-t-il ses fonctions ?	Tests fonctionnels et de performance
État après migration	Le mécanisme prévu est-il effectivement actif ?	Vérification et journal de changement

Une priorité peut provenir d’une longue durée de confidentialité, d’un équipement difficile à modifier ou d’un nombre important de dépendances. Ces facteurs ne produisent pas une date universelle ; ils orientent l’ordre du travail. La stratégie doit être revue lorsque les recommandations, les produits ou le périmètre de l’organisation évoluent.

Une migration se termine par une vérification d’état

Installer une nouvelle version ne prouve pas que le mécanisme prévu protège effectivement les échanges. La configuration, les capacités du correspondant et les choix négociés peuvent produire un comportement différent. Le dossier de validation doit donc associer la version installée à une observation du fonctionnement réellement obtenu, dans un environnement d’essai autorisé.

Les critères d’acceptation doivent être écrits avant le déploiement. Ils peuvent inclure la continuité des fonctions, l’absence de régression connue et la visibilité sur les paramètres actifs. Une équipe doit aussi savoir qui examine les écarts et qui décide de la suite. Cette organisation ne remplace pas l’expertise cryptographique ; elle évite qu’une recommandation correcte reste une intention non vérifiée dans le système exploité.

Ce que cela change pour une entreprise : préparer la transition revient d’abord à connaître ses usages et ses contraintes. Un achat portant simplement le mot post-quantique ne remplace pas ce travail. Les critères utiles sont la fonction protégée, l’implémentation, la compatibilité et la preuve du déploiement effectif.

Ce qui reste à démontrer : aucune infrastructure n’a été auditée ni modifiée dans ce dossier. Les recommandations techniques et réglementaires doivent être relues avant une mise en production, avec une revue spécialisée. Les sources expliquent la démarche ; elles ne certifient aucun choix particulier du lecteur.

Sources et limites

• NIST, What Is Post-Quantum Cryptography?, consulté via Firecrawl le 19 octobre 2026 ; menace, normalisation, inventaire et confidentialité de longue durée.
• ANSSI, Cryptographie post-quantique, page officielle consultée via lecture web le 19 octobre 2026 après échec de l’extraction Firecrawl. Le PDF extrait de manière corrompue a été exclu des preuves utilisées.