Le premier obstacle à la cryptographie postquantique n’est pas un ordinateur quantique surpuissant. C’est souvent un fichier Excel incomplet. Où se trouvent les clés ? Quels logiciels utilisent RSA ? Qui renouvelle les certificats d’un équipement industriel installé il y a dix ans ? À l’horizon de septembre 2026, ces questions dessinent un chantier informatique décisif. Les standards existent ; reste à préparer leur adoption dans des systèmes qui ne peuvent pas s’arrêter. Cette analyse s’appuie sur les jalons établis depuis 2024 ; les trajectoires de déploiement évoquées sont prospectives.
Une menace future, des décisions présentes
L’ordinateur quantique capable de casser les mécanismes cryptographiques aujourd’hui déployés à grande échelle n’a pas de date d’arrivée certaine. Il serait donc trompeur d’annoncer une échéance universelle. Le risque est néanmoins identifié : avec une machine suffisamment puissante et corrigée des erreurs, l’algorithme de Shor permettrait d’attaquer les problèmes mathématiques sur lesquels reposent notamment RSA et la cryptographie sur courbes elliptiques.
Ces mécanismes servent à établir des secrets partagés, à authentifier des interlocuteurs et à signer des documents ou des logiciels. Leur fragilisation toucherait aussi bien les connexions sécurisées que les infrastructures de certificats et les chaînes de mise à jour. Cela ne signifie pas que toute cryptographie deviendrait inutile : le chiffrement symétrique, dont AES, n’est pas exposé de la même manière, même si ses paramètres doivent être évalués.
Pourquoi agir avant que la menace soit opérationnelle ? Parce qu’un adversaire peut enregistrer aujourd’hui des communications chiffrées pour tenter de les déchiffrer plus tard. Cette stratégie, dite « collecter maintenant, déchiffrer plus tard », concerne particulièrement les informations dont la confidentialité doit durer : données de santé, secrets industriels, dossiers diplomatiques. Leur durée de sensibilité peut dépasser celle des protections actuelles.
Ce que les standards de 2024 ont changé
Le 13 août 2024, le NIST, l’institut américain de normalisation, a publié trois premiers standards postquantiques finalisés. FIPS 203 définit ML-KEM, issu de CRYSTALS-Kyber, pour l’encapsulation de clés. FIPS 204 définit ML-DSA, issu de CRYSTALS-Dilithium, pour les signatures numériques. FIPS 205 définit SLH-DSA, issu de SPHINCS+, une autre famille de signatures fondée sur les fonctions de hachage.
La distinction compte. ML-KEM ne remplace pas directement le chiffrement de tous les fichiers : il permet d’établir un secret ensuite utilisable, notamment, avec un chiffrement symétrique. Les deux autres standards répondent à des besoins d’authenticité et d’intégrité. Il n’existe donc pas un bouton « activer le postquantique » valable pour toute l’entreprise.
Ces publications fournissent un socle commun aux éditeurs, équipementiers et équipes de sécurité. Elles ne garantissent ni la maturité de chaque implémentation, ni son intégration immédiate dans tous les protocoles. Entre un algorithme standardisé et un service robuste, il faut encore des bibliothèques éprouvées, des profils d’utilisation, des essais d’interopérabilité et, selon les secteurs, des validations réglementaires.
Le vrai départ : retrouver la cryptographie cachée
Dans une organisation, la cryptographie dépasse largement le périmètre du navigateur. Elle se niche dans les tunnels VPN, les connexions entre applications, les sauvegardes, les cartes à puce, les modules matériels de sécurité ou les mécanismes de démarrage sécurisé. Certaines dépendances appartiennent à l’entreprise ; d’autres sont enfouies dans un service cloud ou un composant acheté.
Imaginons un groupe industriel : son portail client utilise une bibliothèque récente, mais ses automates vérifient les mises à jour avec une clé publique inscrite dans un composant difficilement remplaçable. Le portail semble plus visible ; l’automate pourrait être beaucoup plus compliqué à migrer. L’inventaire doit donc documenter les usages, pas seulement dresser une liste d’algorithmes.
- Repérer les fonctions : échange de clés, signature, authentification, chiffrement des données.
- Identifier les dépendances : bibliothèques, certificats, équipements, fournisseurs et versions réellement déployées.
- Relier chaque usage à un enjeu : durée de confidentialité, criticité du service et durée de vie du matériel.
- Attribuer un responsable : une dépendance sans propriétaire risque de rester sans plan de migration.
Les scans réseau et l’analyse du code peuvent alimenter cette cartographie. Aucun outil ne verra cependant, à lui seul, le micrologiciel d’un appareil isolé, les engagements d’un prestataire et les règles d’une autorité de certification. La démarche doit associer exploitation, développement, achats et métiers, puis rester à jour.
Migrer sans transformer la sécurité en panne
Le remplacement n’est pas neutre. Selon les mécanismes retenus, clés publiques, signatures ou messages d’établissement de session deviennent plus volumineux. Un serveur puissant peut absorber certaines différences ; un capteur contraint, un lien étroit ou un équipement intermédiaire ancien, beaucoup moins. Il faut mesurer la latence, la mémoire et le comportement sous charge, mais aussi vérifier les limites de taille parfois codées en dur.
Les essais menés avant même la publication des standards, notamment autour de TLS dans les navigateurs et les infrastructures Internet, ont montré l’importance du terrain. Une primitive mathématique peut fonctionner parfaitement tout en révélant une incompatibilité dans un boîtier réseau. Le laboratoire doit donc reproduire la chaîne complète, et pas seulement comparer deux algorithmes sur un processeur.
L’hybridation, une transition à encadrer
Une approche consiste à combiner un mécanisme classique et un mécanisme postquantique pour établir les clés. Correctement conçue, cette hybridation vise à préserver la sécurité si l’un des deux reste sûr. Elle répond à une prudence compréhensible : conserver une protection éprouvée tout en ajoutant une défense contre le risque quantique.
Mais assembler soi-même deux mécanismes n’offre aucune garantie automatique. La construction cryptographique, la négociation du protocole et la résistance aux attaques par rétrogradation doivent être examinées. Mieux vaut privilégier des intégrations documentées et interopérables, avec un déploiement progressif et une procédure de retour arrière qui ne transforme pas une erreur technique en affaiblissement silencieux.
Acheter aujourd’hui la capacité de changer demain
La priorité budgétaire n’est pas nécessairement de remplacer immédiatement tout le parc. Elle est d’éviter de renouveler des dépendances impossibles à faire évoluer. Pour chaque achat durable, les organisations devraient demander comment seront mises à jour les fonctions cryptographiques, quels standards sont prévus et quelles contraintes matérielles pourraient bloquer leur adoption.
Cette capacité porte un nom : la crypto-agilité. Elle suppose de pouvoir changer d’algorithme, de paramètres ou de fournisseur sans reconstruire toute une application. Concrètement, cela signifie séparer la logique métier des opérations cryptographiques, automatiser la gestion des certificats et tester les procédures de rotation. Une simple mention « compatible postquantique » sur une fiche commerciale ne suffit pas.
La trajectoire raisonnable commencerait par les données à longue durée de confidentialité et les équipements à cycle de remplacement lent, avant des pilotes sur des services maîtrisés. Les indicateurs utiles seraient très opérationnels : dépendances identifiées, fournisseurs disposant d’une feuille de route, applications testées et obstacles restant à lever. Pas le nombre de présentations consacrées au sujet.
Et maintenant ? À l’horizon de septembre 2026, le scénario souhaitable n’est pas une bascule générale précipitée, mais une migration devenue gouvernable. Inventorier, prioriser, expérimenter et contractualiser permettraient de réduire les angles morts avant l’urgence. La meilleure préparation au risque quantique commence ainsi par une compétence très classique : savoir précisément de quoi son informatique dépend.
