Un pirate n’a pas besoin d’un ordinateur quantique pour préparer une future attaque. Il peut dès aujourd’hui intercepter des communications chiffrées, les conserver et attendre de pouvoir les déchiffrer.
Face à cette menace, la cybersécurité post-quantique devient une priorité pour les autorités et les entreprises. Le NIST a publié ses premiers standards en 2024, avant de finaliser sa feuille de route le 27 octobre 2026. De son côté, l’Union européenne demande d’engager la transition d’ici fin 2026. Toutefois, la migration ne se limite pas au remplacement de RSA. Les entreprises doivent d’abord identifier les mécanismes cryptographiques présents dans leurs logiciels, leurs certificats et leurs équipements. Elles pourront ensuite les moderniser progressivement, sans compromettre la sécurité de leurs infrastructures existantes.
Trois points clés à retenir
- Le risque commence avant le « jour Q » : des échanges interceptés maintenant pourraient être déchiffrés plus tard.
- Les standards existent : FIPS 203, 204 et 205 ont été publiés par le NIST en août 2024.
- La migration commence par un inventaire : durée de sensibilité des données, dépendances et fournisseurs déterminent les priorités.
Des données volées aujourd’hui, lisibles dans dix ans ?
La stratégie harvest now, decrypt later consiste à capter du trafic chiffré, le stocker et attendre qu’une technologie permette d’en retrouver le contenu. L’attaquant n’obtient pas immédiatement les informations. Mais une archive médicale, un secret industriel ou un échange diplomatique peuvent conserver leur valeur pendant des décennies. La menace dépend donc autant de la durée de confidentialité que de la puissance des ordinateurs futurs.
Le mécanisme visé est surtout la cryptographie asymétrique. RSA repose sur la difficulté de factoriser de grands nombres. Les systèmes à courbes elliptiques utilisent entre autres des problèmes de logarithme discret. Avec un ordinateur quantique assez puissant et corrigé des erreurs, l’algorithme de Shor pourrait résoudre ces problèmes sans difficulté. Aucune machine disponible n’a démontré une telle capacité opérationnelle contre les grands systèmes modernes. L’incertitude porte sur la date, pas sur la nécessité d’anticiper. Plus les données doivent rester secrètes longtemps, moins les organisations peuvent attendre une annonce officielle du premier déchiffrement quantique. Cette asymétrie explique l’urgence malgré une échéance scientifique inconnue.
Pourquoi AES ne disparaît pas avec RSA ?
Une connexion sécurisée combine plusieurs fonctions : échange de clés, authentification, puis chiffrement des données. AES, algorithme symétrique, ne réagit pas à la menace quantique comme RSA. L’algorithme de Grover pourrait accélérer certaines recherches exhaustives, mais son effet est plus limité que celui de Shor. Des clés symétriques suffisamment longues restent une réponse crédible. Allonger une clé RSA, en revanche, ne règle pas le problème fondamental.
Trois normes NIST pour remplacer les briques vulnérables
Le 13 août 2024, le NIST a publié trois normes issues d’une sélection scientifique internationale. Elles couvrent deux besoins distincts : établir une clé secrète et signer une information. Une organisation doit vérifier les deux fonctions, car moderniser un tunnel chiffré ne suffit pas à sécuriser la chaîne de confiance.
FIPS 203 — ML-KEM pour échanger des clés
Issu de CRYSTALS-Kyber, ML-KEM permet à deux interlocuteurs d’établir un secret partagé sur un canal public. Cette brique peut notamment servir lors de la négociation d’une connexion TLS ou d’un VPN. Elle ne remplace pas, à elle seule, le chiffrement des fichiers ni l’authentification des serveurs. Sa sécurité dépend aussi de son intégration dans un protocole correctement conçu.
FIPS 204 — ML-DSA pour signer
Dérivé de CRYSTALS-Dilithium, ML-DSA sert à produire et vérifier des signatures numériques. Il concerne les logiciels, leurs mises à jour, certains certificats et les documents signés. Ces signatures peuvent être plus volumineuses que leurs équivalents classiques. Leurs tailles doivent être testées sur les cartes à puce, les appareils embarqués et les réseaux contraints.
FIPS 205 — SLH-DSA comme autre approche
SLH-DSA, issu de SPHINCS+, repose sur des fonctions de hachage. Il apporte une diversité mathématique utile face à une éventuelle faiblesse d’autres familles. En revanche, ses contraintes de performance et de taille diffèrent. Le NIST travaille aussi sur FALCON pour une future norme FIPS 206 et a sélectionné HQC comme futur mécanisme alternatif. Ces travaux ne doivent pas être confondus avec les trois normes déjà finalisées.
Europe, États-Unis, France : trois calendriers à ne pas confondre
La feuille de route européenne du 23 juin 2025 demande aux États membres de commencer leur transition avant fin 2026. Pour les infrastructures critiques, elle vise un passage à la cryptographie post-quantique au plus tard fin 2030. Il s’agit d’une coordination des politiques nationales, pas d’une sanction automatique applicable à toutes les entreprises françaises dès janvier 2027.
Aux États-Unis, le NIST a finalisé son rapport IR 8547 le 27 octobre 2026. Pour les systèmes fédéraux les plus sensibles, des échéances accélérées visent 2030 pour l’établissement de clés et 2031 pour les signatures. L’objectif général de migration fédérale reste 2035. Ces jalons sont utiles pour anticiper le marché, mais ne constituent pas des obligations françaises identiques.
En France, le décalage reste important. Selon un article LeBigData consacré aux mini-sondages du CESIN, 69 % des répondants n’avaient pas commencé à travailler sur le post-quantique au premier semestre 2026. Ce résultat décrit les participants à ces consultations, pas l’ensemble des entreprises françaises.
L’ANSSI préconise, de son côté, une analyse de risque et un inventaire des usages cryptographiques. Elle recommande de prioriser les données et systèmes qui devront rester protégés longtemps. Ses orientations générales n’ont pas toutes valeur réglementaire. Elle estime néanmoins qu’acheter après 2030 un produit incapable d’intégrer la cryptographie post-quantique ne sera pas raisonnable. Le prochain cycle de renouvellement matériel est donc déjà concerné.
L’hybridation protège la migration, pas les erreurs d’intégration
En matière de cybersécurité post-quantique, adopter de nouveaux algorithmes dans la précipitation peut introduire des vulnérabilités supplémentaires. Malgré plusieurs années d’évaluation, ces standards restent exposés aux erreurs d’implémentation, aux attaques par canaux auxiliaires et aux incompatibilités techniques. L’hybridation constitue alors une approche prudente, puisqu’elle associe un mécanisme cryptographique classique éprouvé à une solution post-quantique au sein d’un dispositif conçu pour les faire fonctionner ensemble.
Toutefois, cette combinaison ne garantit pas automatiquement une meilleure protection. La dérivation des clés, l’authentification et les mécanismes de repli doivent conserver leur robustesse. C’est pourquoi l’ANSSI recommande l’hybridation à court et moyen terme lorsque le risque quantique doit être pris en compte. Elle ne la juge cependant pas systématiquement nécessaire pour certaines signatures fondées sur le hachage, notamment SLH-DSA.
Le choix dépend donc des usages et des contraintes techniques. Par ailleurs, l’hybridation ne compense ni les failles d’un logiciel obsolète, ni une mauvaise protection des clés, ni un défaut de supervision. Ces vulnérabilités restent exploitables par les attaquants, même sans ordinateur quantique.
Autre condition : la crypto-agilité, c’est-à-dire la capacité de remplacer un algorithme ou ses paramètres sans reconstruire toute l’application. Un équipement sécurisé aujourd’hui mais impossible à mettre à jour demain risque de devenir le maillon faible. Les achats, les contrats de maintenance et les architectures logicielles doivent intégrer cette possibilité dès le départ.
TLS, certificats, objets connectés : la migration se joue dans les détails
Le premier obstacle est la dispersion des dépendances. TLS, VPN, API, certificats, autorités de certification, coffres de clés et signatures de code peuvent utiliser des mécanismes différents. Un échange post-quantique fonctionnel entre navigateur et serveur peut échouer derrière un proxy, un équipement d’inspection ou une bibliothèque ancienne. Des messages plus volumineux peuvent aussi peser sur la latence ou certains réseaux.
L’authentification constitue un chantier séparé. Un service peut adopter ML-KEM pour établir ses clés tout en conservant une signature classique pour son certificat. Il gagne alors une protection contre certaines interceptions différées, sans devenir entièrement « post-quantique ». Les équipes doivent tester l’ensemble du chemin technique, comme la négociation, les journaux d’erreurs et le retour arrière.
Les systèmes embarqués aggravent le problème. Un automate industriel ou un dispositif médical peut rester installé quinze ans, avec peu de mémoire et un micrologiciel signé par une racine de confiance figée. Changer un protocole ne met pas automatiquement à jour son mécanisme de démarrage sécurisé. Dans certains cas, la migration passera par un remplacement matériel, à planifier avant la fin du support fournisseur. À l’inverse, la messagerie Signal illustre qu’une transition hybride est réalisable dans un service largement utilisé, même si son architecture ne peut pas être copiée telle quelle partout.
Six décisions pour ne pas acheter une promesse « quantum safe »
Le chantier appartient autant aux responsables des risques qu’aux cryptographes. Un budget limité invite à traiter d’abord les flux les plus sensibles plutôt qu’à remplacer uniformément tout le parc. Les échéances contractuelles et les achats programmés peuvent devenir de véritables leviers de migration. RSSI, architectes, achats, équipes métiers et fournisseurs doivent partager le même calendrier. La méthode défendue par l’ANSSI commence par la connaissance du parc, puis une priorisation fondée sur les conséquences d’une compromission future.
1. Cartographier les usages. Recensez les protocoles, certificats, algorithmes, bibliothèques, modules matériels et dépendances externes. L’objectif est une carte des fonctions cryptographiques, pas une simple liste d’ordinateurs.
2. Classer les secrets selon leur durée de vie. Une session éphémère et un dossier de santé ne présentent pas le même risque. Identifiez les données susceptibles d’être capturées aujourd’hui et encore sensibles dans plusieurs années.
3. Exiger des réponses précises des fournisseurs. « PQC ready » ne suffit pas. Demandez les normes prises en charge, leurs versions, les modes hybrides, les équipements compatibles, les validations éventuelles et les modalités de mise à jour.
4. Lancer un pilote représentatif. Testez un VPN, une API interne ou un service non critique. Suivez les délais de connexion, la consommation mémoire, les erreurs de négociation et les clients anciens. Documentez aussi le scénario de retour arrière.
5. Traiter séparément les signatures. Vérifiez les certificats, les logiciels signés, les mises à jour et la durée de vie des équipements qui les contrôlent. Cette migration ne suit pas nécessairement celle des échanges de clés.
6. Inscrire la crypto-agilité dans les contrats. Prévoyez la rotation des clés, le changement d’algorithme, la maintenance des composants et la fin de vie des appareils non migrables. Un contrat clair évite qu’une promesse commerciale devienne une impasse technique. Le risque quantique ne justifie ni la panique ni l’attente passive. L’erreur la plus coûteuse serait de renouveler aujourd’hui une infrastructure qui restera impossible à sécuriser demain.
- Partager l'article :
