# Cryptographie post-quantique (FAQ)

> 33 questions sur Cryptographie post-quantique, en langage clair : quoi vérifier, ce que montre NetSenX et ce qu'une sonde ne voit pas.

Source page: https://netsenx.com/fr/faq/pqc

## Qu'est-ce qu'un ordinateur quantique ?

Un ordinateur quantique calcule avec des qubits, qui peuvent contenir à la fois une combinaison de 0 et de 1 et être liés de sorte que leurs états dépendent les uns des autres. Pour la plupart des tâches, il n'est pas plus rapide qu'un ordinateur classique. Pour quelques problèmes dotés de la bonne structure mathématique, un algorithme quantique fait s'annuler les mauvaises réponses et ressortir la bonne, ce qui donne une accélération énorme. Les machines actuelles ont trop peu de qubits et trop d'erreurs pour menacer le chiffrement. Il faudrait pour cela une grande machine tolérante aux fautes, capable de corriger ses propres erreurs, et personne ne l'a encore construite. Pour votre entreprise, la conséquence pratique est précise : une telle machine casserait la cryptographie à clé publique qui protège presque chacune de vos connexions, il faut donc planifier son remplacement avant qu'elle n'existe.

https://netsenx.com/fr/faq/what-is-a-quantum-computer

## Pourquoi les ordinateurs quantiques menacent-ils le chiffrement ?

Parce qu'un grand ordinateur quantique tolérant aux fautes, exécutant l'algorithme de Shor, pourrait casser les méthodes à clé publique utilisées aujourd'hui pour convenir de clés et signer des données : RSA et la cryptographie sur courbes elliptiques (ECC). Ces deux méthodes protègent l'échange de clés de presque toutes les connexions HTTPS, VPN et SSH, ainsi que les signatures des certificats, des mises à jour logicielles et des documents. Un attaquant disposant d'une telle machine pourrait lire du trafic enregistré plus tôt et falsifier des signatures. Le chiffrement symétrique comme AES, qui chiffre les données une fois la clé convenue, n'est que modérément affaibli par l'algorithme de Grover et reste utilisable avec des clés de 256 bits. Une telle machine n'existe pas aujourd'hui et personne ne peut dire en quelle année elle existera. Le risque est réel pour les données qui doivent rester secrètes de nombreuses années : il se planifie, ce n'est pas une urgence. La solution est logicielle, pas matérielle : de nouveaux algorithmes normalisés par le NIST en 2024, déployés par des mises à jour.

https://netsenx.com/fr/faq/why-are-quantum-computers-a-threat-to-encryption

## Comment l'algorithme de Shor casse-t-il RSA et ECC ?

Il rend faciles les problèmes difficiles sur lesquels ils reposent. RSA est sûr parce que personne ne sait décomposer un très grand nombre en ses deux facteurs premiers en un temps raisonnable ; la cryptographie sur courbes elliptiques est sûre parce que personne ne sait retrouver le nombre secret derrière un point public de la courbe. Peter Shor a montré en 1994 qu'un ordinateur quantique peut trouver, dans les deux problèmes, un motif répétitif caché, une période, dont le secret se déduit rapidement. Sur une machine assez grande, l'attaque prend un temps praticable au lieu d'un temps impossible. Des clés plus longues ne sauvent ni RSA ni ECC : elles ralentissent seulement un peu l'attaque quantique. C'est pourquoi la réponse passe par de nouvelles mathématiques, comme les problèmes de réseaux euclidiens derrière ML-KEM et ML-DSA, pour lesquels aucun algorithme quantique efficace n'est connu. Les estimations publiées de la machine nécessaire dépassent encore de loin tout ce qui a été construit.

https://netsenx.com/fr/faq/how-does-shors-algorithm-break-rsa-and-elliptic-curves

## Que change l'algorithme de Grover pour AES ?

Beaucoup moins que l'algorithme de Shor pour RSA : il affaiblit le chiffrement symétrique et le hachage, sans les casser. Lov Grover a montré en 1996 qu'un ordinateur quantique peut parcourir des possibilités en à peu près la racine carrée du nombre d'étapes habituel. Appliqué à la recherche d'une clé, cela divise environ par deux sa longueur en bits : en théorie, une clé AES de 128 bits se comporte plutôt comme une clé de 64 bits. En pratique, l'attaque est une très longue chaîne d'étapes qu'on ne peut pas répartir utilement sur de nombreuses machines, si bien que même AES-128 reste loin d'être facile à casser. Le conseil courant est simple : AES-256 pour les données qui doivent rester secrètes longtemps, et SHA-256 ou plus fort pour le hachage. La plupart des systèmes modernes prennent déjà en charge les deux ; cette partie du changement relève donc en général de la configuration, pas d'un projet de migration. Le vrai travail concerne les méthodes à clé publique.

https://netsenx.com/fr/faq/what-does-grovers-algorithm-mean-for-aes

## Quand un ordinateur quantique cassera-t-il RSA ?

Personne ne le sait, et quiconque avance une année fait une supposition. Une machine assez grande et stable pour exécuter l'algorithme de Shor contre les tailles de clé actuelles exige des progrès en qualité des qubits, en correction d'erreurs et en échelle qui n'ont pas encore été démontrés. Les enquêtes d'experts et les feuilles de route des fabricants donnent des fourchettes, pas des dates, et ces fourchettes bougent. Votre planification ne dépend pourtant pas de cette date. Les régulateurs ont fixé leurs propres échéances : la feuille de route coordonnée de l'UE du 23 juin 2025 demande de migrer les cas d'usage à haut risque d'ici fin 2030, et les lignes directrices de transition du NIST (NIST IR 8547, projet de novembre 2024, version finale d'octobre 2026) déprécient après 2030 les méthodes à clé publique vulnérables aux ordinateurs quantiques, comme RSA et les courbes elliptiques, et les interdisent dans les normes du NIST après 2035. Clients, auditeurs et appels d'offres poseront la question bien avant qu'un ordinateur quantique n'existe. Pour des données qui doivent rester secrètes dix ans ou plus, l'inégalité de Mosca montre pourquoi attendre cette date est une mauvaise stratégie.

https://netsenx.com/fr/faq/when-will-a-quantum-computer-break-encryption

## Qu'est-ce que la cryptographie post-quantique ?

La cryptographie post-quantique (PQC) est une cryptographie à clé publique conçue pour rester sûre face à un grand ordinateur quantique, tout en fonctionnant sur des ordinateurs ordinaires. Le NIST a publié les premières normes le 13 août 2024 : FIPS 203 (ML-KEM) pour établir des clés, FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA) pour les signatures numériques. Elles reposent sur des problèmes mathématiques, comme la recherche de vecteurs courts dans des réseaux euclidiens de grande dimension, ou sur la sécurité des fonctions de hachage, pour lesquels aucune attaque quantique efficace n'est connue. Migrer signifie mettre à jour logiciels, bibliothèques, protocoles et certificats, pas acheter du matériel quantique. Ce n'est pas non plus la distribution quantique de clés, qui exige un équipement optique spécial. Le prix du changement est la taille : clés et signatures post-quantiques sont plus grandes que celles d'aujourd'hui, les négociations grossissent et certains équipements anciens peinent. La plupart des organisations rencontrent la PQC d'abord via les mises à jour des navigateurs, des systèmes d'exploitation et des logiciels VPN, puis doivent traiter leurs propres serveurs et applications.

https://netsenx.com/fr/faq/what-is-post-quantum-cryptography

## Que sont les FIPS 203, 204 et 205 ?

Ce sont les trois premières normes post-quantiques du National Institute of Standards and Technology (NIST) américain, publiées le 13 août 2024 au terme d'une compétition ouverte et internationale lancée en 2016. FIPS 203 spécifie ML-KEM, un mécanisme d'encapsulation de clé qui permet à deux parties de convenir d'une clé secrète commune ; il reprend le rôle que jouent aujourd'hui RSA et Diffie-Hellman sur courbes elliptiques dans l'échange de clés. FIPS 204 spécifie ML-DSA, le principal schéma de signature numérique. FIPS 205 spécifie SLH-DSA, un schéma de signature plus lent, aux signatures plus grandes, qui ne repose que sur des fonctions de hachage et sert d'alternative prudente. Bien que ce soient des normes fédérales américaines, elles font référence dans le monde entier : des agences européennes comme l'ANSSI en France et le BSI en Allemagne recommandent notamment ces algorithmes, en général combinés à un algorithme classique. Pour vous, ce sont les noms à chercher dans la documentation des fournisseurs, leurs feuilles de route et les réponses aux appels d'offres.

https://netsenx.com/fr/faq/what-are-fips-203-204-and-205

## Qu'est-ce que ML-KEM ?

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) est la méthode post-quantique pour convenir d'une clé secrète sur un réseau ouvert, et celle que vous rencontrerez en premier. Elle est issue de la candidature CRYSTALS-Kyber. Une partie publie une clé publique ; l'autre s'en sert pour emballer un secret aléatoire frais que seul le détenteur de la clé privée peut déballer. Ce secret sert ensuite de clé à un chiffrement symétrique rapide comme AES. Elle existe en trois tailles, ML-KEM-512, ML-KEM-768 et ML-KEM-1024, 768 étant le choix courant. Elle est rapide, souvent comparable aux courbes elliptiques, mais sa clé publique et son chiffré pèsent chacun environ un kilo-octet, contre 32 octets pour X25519. C'est cette taille qui fait que certains vieux pare-feu et équipements intermédiaires peinent avec les négociations post-quantiques. Dans TLS, ML-KEM apparaît en général combiné à X25519 sous la forme du groupe hybride X25519MLKEM768, que la plupart des navigateurs proposent déjà.

https://netsenx.com/fr/faq/what-is-ml-kem

## Que sont ML-DSA et SLH-DSA ?

Ce sont les deux normes de signature post-quantique : ML-DSA (FIPS 204, issue de CRYSTALS-Dilithium) et SLH-DSA (FIPS 205, issue de SPHINCS+). Une signature numérique prouve qui a produit des données et que personne ne les a modifiées ; elle protège certificats, mises à jour logicielles, micrologiciels, documents et code. ML-DSA est le choix généraliste : rapide, avec des signatures de quelques kilo-octets au lieu des 64 octets d'une signature ECDSA typique. SLH-DSA ne repose que sur la sécurité des fonctions de hachage, ce qui la rend très prudente, au prix de signatures plus grandes et d'une signature plus lente ; elle convient aux racines de confiance de longue durée et à la signature de micrologiciels. Les signatures comptent moins pour « harvest now, decrypt later », car une signature falsifiée n'aide un attaquant qu'une fois l'ordinateur quantique disponible. C'est pourquoi la plupart des organisations changent d'abord l'échange de clés, puis les signatures. L'écosystème des certificats à signature post-quantique est encore en construction : demandez leurs plans à vos fournisseurs plutôt que d'attendre des certificats post-quantiques dès aujourd'hui.

https://netsenx.com/fr/faq/what-are-ml-dsa-and-slh-dsa

## Que sont HQC et FN-DSA ?

Ce sont les prochains algorithmes post-quantiques du parcours du NIST, pas encore des normes définitives. HQC (Hamming Quasi-Cyclic) est une méthode d'encapsulation de clé que le NIST a retenue en mars 2025 comme solution de secours à ML-KEM. Elle repose sur des codes correcteurs d'erreurs plutôt que sur des réseaux euclidiens : si une faiblesse était un jour trouvée dans les problèmes de réseaux, un algorithme d'une autre famille mathématique serait prêt. Le NIST annonçait alors un projet de norme environ un an plus tard et une norme définitive en 2027. FN-DSA, issu de la candidature FALCON, est un schéma de signature prévu comme FIPS 206 ; ses signatures sont bien plus petites que celles de ML-DSA, ce qui aide quand la place manque, mais il est plus difficile à implémenter de façon sûre. La leçon pour votre planification : ne misez pas pour toujours sur un seul algorithme. Choisissez des produits capables de changer d'algorithme par configuration ou mise à jour. Cette capacité, appelée agilité cryptographique, vous protège si une norme change ou si une faille d'implémentation apparaît.

https://netsenx.com/fr/faq/what-are-hqc-and-fn-dsa

## Qu'est-ce que l'échange de clés hybride (X25519MLKEM768) ?

L'échange de clés hybride combine dans la même négociation TLS une méthode classique (X25519, un échange sur courbes elliptiques) et une méthode post-quantique (ML-KEM-768), et dérive la clé de session des deux. La clé reste secrète tant que l'une des deux tient : si une faille était trouvée dans ML-KEM, encore jeune, X25519 tiendrait toujours les attaquants d'aujourd'hui à distance ; face à un futur ordinateur quantique, ML-KEM prendrait le relais. C'est pourquoi la plupart des recommandations, dont celles d'agences européennes comme l'ANSSI et le BSI, privilégient l'hybride pendant la transition. X25519MLKEM768 est le nom de cette combinaison dans TLS. Les grands navigateurs la proposent déjà par défaut, et les grands réseaux de diffusion de contenu comme de nombreux services cloud l'acceptent : une partie de votre trafic web l'utilise peut-être déjà sans que vous ayez rien changé. Une connexion qui l'utilise rend le trafic enregistré bien plus difficile à déchiffrer plus tard. Celles à planifier sont les connexions qui n'utilisent encore qu'un échange de clés classique : serveurs anciens, appliances, VPN et applications internes.

https://netsenx.com/fr/faq/what-is-hybrid-key-exchange-x25519mlkem768

## La distribution quantique de clés est-elle une alternative à la cryptographie post-quantique ?

Pour presque toutes les entreprises, non. La distribution quantique de clés (QKD) utilise la physique de photons uniques, envoyés sur une fibre dédiée ou une liaison en espace libre, pour convenir d'une clé de façon à révéler toute écoute. Elle exige un matériel spécial aux deux extrémités, fonctionne sur des distances limitées sauf ajout de stations relais de confiance, et n'authentifie pas les deux parties par elle-même : elle a toujours besoin de signatures classiques ou post-quantiques. La cryptographie post-quantique, elle, est un logiciel qui fonctionne sur les réseaux et les équipements que vous avez déjà. Des agences européennes de sécurité, dont l'ANSSI, le BSI allemand et la NLNCSA néerlandaise, ont publié une position commune qui fait de la cryptographie post-quantique la voie principale et réserve la QKD, au mieux, à des usages de niche. L'infrastructure européenne de communication quantique EuroQCI répond à des besoins gouvernementaux précis, ce qui est une autre question que ce qu'une entreprise de taille moyenne devrait acheter. Si un fournisseur vous propose la QKD contre « harvest now, decrypt later » pour un réseau de bureau ordinaire, demandez ce qu'elle apporte qu'une configuration TLS ou VPN hybride n'apporte pas.

https://netsenx.com/fr/faq/is-quantum-key-distribution-an-alternative-to-pqc

## Que signifie « harvest now, decrypt later » ?

Un attaquant enregistre aujourd'hui du trafic chiffré et le conserve, pour le déchiffrer quand un ordinateur quantique suffisamment puissant existera. L'enregistrement coûte peu et vous reste invisible : il peut se faire sur un point d'échange internet, un routeur compromis ou chez un opérateur, loin de votre réseau. Seul est menacé le trafic dont l'échange de clés est vulnérable au quantique, et seules les données qui compteront encore au moment du déchiffrement. Dossiers médicaux, plans, code source, contrats de longue durée, dossiers juridiques et données personnelles conservées de nombreuses années en sont des exemples typiques ; le planning de livraison de la semaine, non. On l'évalue souvent avec l'inégalité de Mosca : si les années pendant lesquelles les données doivent rester secrètes plus les années de votre migration dépassent les années qui nous séparent d'un tel ordinateur, il faut commencer maintenant. La réponse pratique consiste à faire passer d'abord à des méthodes hybrides post-quantiques l'échange de clés qui protège les données de longue durée, car c'est là que les enregistrements d'aujourd'hui deviendraient les fuites de demain. Les signatures peuvent suivre plus tard.

https://netsenx.com/fr/faq/what-is-harvest-now-decrypt-later

## Quelles données sont menacées par « harvest now, decrypt later » ?

Les données qui traversent un réseau aujourd'hui et doivent rester confidentielles au-delà de l'arrivée d'un grand ordinateur quantique. Posez deux questions pour chaque ensemble de données : circule-t-il sur une connexion dont l'échange de clés est vulnérable au quantique, et pendant combien d'années sa divulgation ferait-elle encore du tort ? Exemples typiques de données à longue durée de vie : dossiers patients et RH, plans de produits et code source, dossiers de fusion et contentieux, contrats publics, données biométriques et identifiants jamais renouvelés. Les données éphémères, comme un code à usage unique ou les prix du mois, ne méritent pas d'inquiétude. Les données stockées relèvent d'une autre question : elles sont en général protégées par un chiffrement symétrique comme AES, qu'un ordinateur quantique ne casse pas, sauf si leurs clés sont échangées ou enveloppées avec RSA. Écrivez la liste avec un responsable et une durée de conservation par élément : elle devient l'ordre de priorité de votre migration et la base du calcul de Mosca. Un capteur réseau ne peut pas classer vos données ; cette liste vient de votre métier.

https://netsenx.com/fr/faq/which-data-is-at-risk-from-harvest-now-decrypt-later

## Comment appliquer l'inégalité de Mosca ?

Mettez trois nombres côte à côte pour chaque ensemble de données ou système important. X est le nombre d'années pendant lesquelles les données doivent rester secrètes. Y est le nombre d'années qu'il vous faudra pour faire passer ce système à la cryptographie post-quantique, fournisseurs, tests et cycles budgétaires compris. Z est le nombre d'années restant avant qu'un ordinateur quantique puisse casser la cryptographie à clé publique actuelle. Si X plus Y dépasse Z, les données envoyées aujourd'hui sont déjà exposées à « harvest now, decrypt later ». Michele Mosca a décrit cette inégalité en 2015, dans un article publié sous la référence IACR ePrint 2015/1075. Z est inconnu, ne prétendez donc pas le connaître : essayez une valeur prudente et une valeur détendue, et regardez quels systèmes échouent même avec la seconde. Par exemple, des contrats qui doivent rester confidentiels 10 ans, sur un système dont la migration prend 5 ans, échouent pour tout Z inférieur à 15 ans. Le résultat est une liste de priorités, pas une prévision, et un raisonnement qu'un auditeur ou un conseil d'administration peut suivre.

https://netsenx.com/fr/faq/how-to-apply-moscas-inequality

## La cryptographie post-quantique est-elle un effet de mode ?

La menace n'en est pas un, mais une bonne partie du marketing qui l'entoure, si. Les faits sont solides : le NIST a publié des normes définitives en août 2024, les navigateurs et les grands fournisseurs cloud utilisent déjà l'échange de clés hybride post-quantique, et l'UE dispose d'une feuille de route coordonnée avec des dates. Ce qui est incertain, c'est la date à laquelle un ordinateur quantique capable existera, et c'est précisément pourquoi planifier vaut mieux qu'attendre : changer la cryptographie de toute une entreprise prend des années. L'effet de mode, ce sont les produits qui promettent de vous immuniser contre les attaques quantiques, les comptes à rebours et la pression pour acheter du matériel dont vous n'avez pas besoin. Position raisonnable pour la plupart des entreprises de taille moyenne : pas de dépense d'urgence, mais un inventaire cette année, des questions post-quantiques à chaque nouvel achat, des mises à jour qui activent l'échange hybride là où les fournisseurs le proposent, et la priorité aux données qui doivent rester longtemps secrètes. Cela coûte peu et évite une migration précipitée et coûteuse plus tard.

https://netsenx.com/fr/faq/is-post-quantum-cryptography-hype

## La cryptographie post-quantique est-elle un sujet pour la direction ?

Oui, comme sujet de planification et de risque, pas comme une crise. Elle a sa place à l'ordre du jour de la direction pour trois raisons. C'est un changement long, transversal, qui touche fournisseurs, produits et budgets pendant plusieurs années, et seule la direction peut l'ordonnancer. Il concerne des données que l'entreprise a promis de protéger longtemps, comme les données clients, patients ou les plans. Et les clients, les assureurs et les marchés publics commencent à poser la question, la réponse devient donc un enjeu commercial. Selon NIS2, les organes de direction des entités concernées doivent approuver les mesures de gestion des risques en matière de cybersécurité et superviser leur mise en œuvre, et une politique de cryptographie en fait partie. La direction a besoin de peu : un inventaire des endroits où une cryptographie vulnérable au quantique est utilisée, une liste de priorités fondée sur la durée pendant laquelle les données doivent rester secrètes, un responsable désigné et un calendrier aligné sur les jalons européens de 2030 et 2035. Elle n'a pas besoin d'un exposé technique sur les qubits.

https://netsenx.com/fr/faq/is-post-quantum-cryptography-a-board-level-topic

## L'UE exige-t-elle un plan de migration post-quantique ?

La recommandation (UE) 2024/1101 de la Commission du 11 avril 2024 a invité les États membres à coordonner la transition, et le groupe de coopération NIS a publié le 23 juin 2025 une feuille de route coordonnée : engager la transition, protéger les cas d'usage à haut risque d'ici fin 2030 et migrer autant de systèmes que possible d'ici 2035. C'est une feuille de route pour les États membres, pas une loi qui s'impose directement à votre entreprise ; les autorités nationales peuvent la traduire en recommandations ou en règles. Sa première étape pratique est de savoir où vous utilisez la cryptographie.

https://netsenx.com/fr/faq/does-the-eu-require-a-post-quantum-migration

## Que demande la feuille de route de l'UE d'ici fin 2026 ?

Que la transition ait commencé partout. La feuille de route coordonnée publiée par le groupe de coopération NIS le 23 juin 2025, à la suite de la recommandation (UE) 2024/1101 de la Commission, fixe trois étapes : premiers pas d'ici fin 2026, migration des cas d'usage à haut risque d'ici fin 2030 et d'autant de systèmes que possible d'ici 2035. La première étape porte sur la préparation : les États membres établissent des plans nationaux de transition, les organisations commencent l'inventaire des endroits où elles utilisent une cryptographie vulnérable au quantique, et le risque de chaque usage est évalué afin que les cas à haut risque puissent être pilotés tôt. La feuille de route s'adresse aux États membres et à leurs secteurs publics et critiques, pas directement à votre entreprise, et les autorités nationales la traduiront dans leurs propres recommandations. Sa logique vaut pourtant pour toute organisation : d'ici fin 2026, sachez où se trouve votre cryptographie, qui est responsable de chaque système et lesquels doivent migrer en premier. Suivez ce que publie votre autorité nationale de cybersécurité.

https://netsenx.com/fr/faq/what-does-the-eu-pqc-roadmap-ask-for-by-2026

## NIS2 ou le CRA exigent-ils la cryptographie post-quantique ?

Pas nommément, mais tous deux vont dans ce sens. NIS2, la directive (UE) 2022/2555, exige des entités concernées des politiques et procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement, dans le cadre des mesures de gestion des risques en matière de cybersécurité de l'article 21. Le règlement sur la cyberrésilience (CRA), règlement (UE) 2024/2847, exige que les produits comportant des éléments numériques protègent la confidentialité des données par des mécanismes conformes à l'état de l'art, parmi les exigences essentielles de son annexe I. Aucun ne nomme d'algorithme. Mais l'état de l'art évolue : dès lors que les normes du NIST, les recommandations des agences européennes et la feuille de route de l'UE traitent l'échange de clés hybride post-quantique comme la norme, un produit ou une politique qui l'ignore devient plus difficile à défendre lors d'un audit ou d'un appel d'offres. La feuille de route de l'UE présente d'ailleurs la transition post-quantique comme une mesure sans regret qui soutient NIS2 et le CRA. Vérifiez la transposition nationale de NIS2 et les recommandations de votre autorité nationale, car les détails peuvent varier selon les pays.

https://netsenx.com/fr/faq/do-nis2-or-the-cra-require-post-quantum-cryptography

## Que doit faire une petite entreprise dès maintenant pour le post-quantique ?

Surtout des choses ordinaires et peu coûteuses. D'abord, tenez à jour navigateurs, systèmes d'exploitation, clients VPN, serveurs et bibliothèques : une grande partie du changement post-quantique arrive par les mises à jour, et les navigateurs modernes utilisent déjà par défaut l'échange de clés hybride. Ensuite, listez où vous utilisez une cryptographie que vous contrôlez vous-même : votre site web et son hébergement, l'accès à distance, la messagerie, l'échange de fichiers avec les clients et tout équipement doté de ses propres certificats. Troisièmement, repérez les données qui doivent rester secrètes de nombreuses années. Quatrièmement, ajoutez une question à chaque nouvel achat ou renouvellement de contrat : le produit prend-il en charge l'échange de clés hybride post-quantique, et sinon, quand ? Cinquièmement, préférez les fournisseurs capables de changer d'algorithme par mise à jour. Acheter des produits quantiques spéciaux ne figure pas sur la liste. NetSenX peut aider pour la deuxième étape : NQCI, en préversion, est visible dans chaque offre et actif à partir de l'offre Pro, et nécessite le capteur de capture de paquets, désactivé par défaut, activé pour un agent Linux ou une sonde SPAN/TAP ; le mode de base sous macOS ne voit pas les négociations.

https://netsenx.com/fr/faq/what-should-a-small-company-do-about-pqc-now

## Combien de temps dure une migration post-quantique ?

Des années pour la plupart des organisations, c'est pourquoi commencer tôt compte plus que la date exacte. Le changement touche tous les endroits où l'on convient de clés ou signe des données : sites web, VPN, SSH, messagerie, applications internes, certificats, modules matériels de sécurité (HSM), cartes à puce, machines et leurs micrologiciels. Beaucoup dépend du moment où les fournisseurs livreront le support post-quantique, et de vos propres cycles de remplacement : un pare-feu acheté cette année fonctionnera peut-être encore la décennie prochaine, un automate industriel bien plus longtemps. Les changements passés donnent l'échelle : retirer SHA-1 et les anciennes versions de TLS a pris de nombreuses années au secteur, des premiers avertissements à l'arrêt définitif. Une petite entreprise qui utilise surtout des services cloud et des logiciels à jour peut faire une bonne partie du chemin par de simples mises à jour, dans un cycle de renouvellement normal. Une entreprise dotée de logiciels maison, d'équipements à longue durée de vie ou de sa propre autorité de certification doit s'attendre à un programme étalé sur plusieurs années. Le Y de l'inégalité de Mosca est votre propre estimation : notez-la avec ses raisons.

https://netsenx.com/fr/faq/how-long-does-a-post-quantum-migration-take

## Que gagnons-nous à migrer vers la cryptographie post-quantique ?

Vous protégez le trafic d'aujourd'hui contre le déchiffrement de demain, et vous obtenez plusieurs gains qui ne dépendent pas du tout des ordinateurs quantiques. Les données à longue durée de vie cessent d'être exposées à « harvest now, decrypt later » dès que leur échange de clés passe à une méthode hybride. L'inventaire que vous construisez en chemin révèle d'anciennes versions de TLS, des suites de chiffrement faibles, des certificats expirés ou oubliés et des serveurs non gérés, autant de risques actuels. L'agilité cryptographique, la capacité de changer d'algorithme par configuration, rend le prochain changement imposé moins coûteux, quelle qu'en soit la cause. Commercialement, vous répondez aux questions des appels d'offres et des clients avec des faits et des dates plutôt qu'une case vide, et vous êtes prêt quand les autorités nationales traduiront la feuille de route de l'UE en recommandations. Menée dans les cycles de remplacement normaux, la migration coûte bien moins qu'une migration sous pression. Ce que vous ne gagnez pas, c'est une immunité : la cryptographie post-quantique protège l'échange de clés et les signatures, pas les mots de passe volés, l'hameçonnage ou les systèmes non corrigés.

https://netsenx.com/fr/faq/what-do-we-gain-by-migrating-to-post-quantum-cryptography

## Que peut-il mal se passer lors d'une migration post-quantique ?

Surtout la compatibilité et les performances, rarement les mathématiques. Les clés post-quantiques sont plus grandes : un ClientHello TLS portant X25519MLKEM768 ne tient plus dans un seul paquet réseau, et certains pare-feu, répartiteurs de charge et systèmes de prévention d'intrusion anciens le gèrent mal, puis abandonnent ou réinitialisent la connexion. Les modules matériels de sécurité, cartes à puce et équipements embarqués peuvent manquer de mémoire ou de micrologiciel pour les nouveaux algorithmes. Des signatures de plusieurs kilo-octets alourdissent les chaînes de certificats et ralentissent les liaisons contraintes. Les implémentations jeunes peuvent contenir des bogues, une raison de plus d'utiliser des méthodes hybrides et des bibliothèques bien maintenues. Les proxys d'interception qui déchiffrent TLS peuvent ne pas prendre en charge les nouveaux groupes et ramener discrètement les connexions à l'échange de clés classique. Anticipez : testez avec du trafic réel dans un segment de préproduction, gardez le repli classique pendant la transition, vérifiez la mise à jour des équipements intermédiaires et mesurez ensuite quelles connexions utilisent réellement l'échange hybride. Une vue des négociations sur le réseau révèle des régressions que les fichiers de configuration ne montrent pas.

https://netsenx.com/fr/faq/what-can-go-wrong-in-a-post-quantum-migration

## Qu'est-ce que l'agilité cryptographique ?

L'agilité cryptographique est la capacité de changer les algorithmes cryptographiques qu'un système utilise sans le réécrire ni le remplacer. Concrètement, les algorithmes sont choisis par configuration et non codés en dur ; les logiciels s'appuient sur des bibliothèques maintenues qui reçoivent de nouveaux algorithmes par mise à jour ; certificats et clés sont gérés de façon centralisée, avec des responsables et des dates d'expiration connus ; et vous savez où chaque algorithme est utilisé. C'est important maintenant, car la transition post-quantique ne sera pas la dernière : HQC et FN-DSA arrivent encore, des paramètres peuvent être révisés et une faille peut apparaître dans une implémentation jeune. Une organisation qui mène une migration manuelle et douloureuse vivra la même douleur la fois suivante ; celle qui construit son agilité fait du changement suivant une simple livraison de configuration. Posez la question à chaque achat : le produit peut-il changer ses algorithmes d'échange de clés et de signature par mise à jour ou paramétrage, et le fournisseur s'y engage-t-il ? Un produit qui ne le peut pas est un problème de migration que vous achetez aujourd'hui.

https://netsenx.com/fr/faq/what-is-crypto-agility

## SSH et les VPN prennent-ils en charge l'échange de clés post-quantique ?

De plus en plus, oui, mais il faut vérifier chaque produit. OpenSSH a fait d'un échange de clés hybride post-quantique son choix par défaut dans la version 9.0 en 2022, et la version 10.0 de 2025 a mis par défaut l'hybride fondé sur ML-KEM, mlkem768x25519-sha256 ; si les deux extrémités utilisent des versions récentes, vos sessions SSH l'emploient probablement déjà. Pour les VPN, la situation varie. L'échange de clés IPsec IKEv2 a obtenu avec la RFC 9370 un moyen normalisé d'ajouter des échanges supplémentaires, comme ML-KEM ; certains fournisseurs et projets libres le prennent en charge, d'autres l'ont seulement annoncé. WireGuard peut ajouter une clé symétrique pré-partagée comme couche de protection post-quantique, mais sa négociation reste classique. Consultez les notes de version du micrologiciel de votre pare-feu ou passerelle VPN et les versions de clients réellement utilisées, et rappelez-vous qu'un vieux serveur à une extrémité maintient toute la connexion en mode classique. Les VPN d'accès distant et de site à site transportent beaucoup de données à longue durée de vie : ils méritent une place élevée dans votre ordre de migration.

https://netsenx.com/fr/faq/do-ssh-and-vpns-support-post-quantum-key-exchange

## Comment trouver où nous utilisons une cryptographie vulnérable au quantique ?

Commencez par un inventaire : certificats, VPN, TLS sur vos serveurs, SSH, signature de code et bibliothèques utilisées par vos applications. Le trafic réseau en montre une grande partie, car l'échange de clés de chaque connexion TLS est visible sans déchiffrement. NQCI, l'inventaire cryptographique de NetSenX (en préversion), est visible dans chaque offre et actif à partir de l'offre Pro : il montre quelles connexions utilisent un échange de clés vulnérable au quantique et lesquelles un échange hybride post-quantique. Il faut pour cela le capteur de capture de paquets, désactivé par défaut : activé pour un agent Linux, ou une sonde sur un port SPAN ou TAP. Le mode de base de l'agent, utilisé sous macOS, ne voit pas les négociations TLS. Il apporte de la visibilité ; la migration elle-même reste à votre charge et à celle de vos fournisseurs.

https://netsenx.com/fr/faq/how-to-find-quantum-vulnerable-cryptography

## Un capteur réseau peut-il construire un inventaire cryptographique ?

Une grande partie, oui, mais pas tout. Chaque connexion TLS annonce, avant tout chiffrement, quels groupes d'échange de clés le client propose et lequel le serveur choisit, ainsi que la version de TLS ; SSH fonctionne de façon semblable. Un capteur qui voit ces négociations peut lister, par serveur et par client, où l'échange de clés vulnérable au quantique est encore utilisé et où l'échange hybride post-quantique l'est déjà, pour chaque équipement du segment, y compris imprimantes, appliances et machines qui ne peuvent pas accueillir d'agent. Ce qu'il ne voit pas : la cryptographie à l'intérieur des applications et des bases de données, les clés et certificats stockés sur disque, la signature de code, les sauvegardes chiffrées, les segments non surveillés et les connexions dont la négociation ne passe jamais par le capteur. NQCI, l'inventaire cryptographique de NetSenX (en préversion), est visible dans chaque offre et actif à partir de l'offre Pro ; il nécessite le capteur de capture de paquets, désactivé par défaut, activé pour un agent Linux ou une sonde sur un port SPAN ou TAP. Le mode de base sous macOS ne voit pas les négociations. Combinez-le avec un inventaire des certificats et des questionnaires fournisseurs.

https://netsenx.com/fr/faq/can-a-network-sensor-build-a-cryptographic-inventory

## Comment savoir quelles connexions utilisent déjà l'échange de clés hybride ?

Regardez le groupe d'échange de clés choisi dans chaque négociation TLS : X25519MLKEM768 signifie hybride post-quantique ; X25519, secp256r1 ou un échange de clés RSA signifient classique uniquement. Pour un serveur isolé, vous pouvez tester de l'extérieur : OpenSSL 3.5 et versions ultérieures, et les outils qui s'appuient dessus comme curl, peuvent proposer le groupe hybride et afficher ce que choisit le serveur, et certains testeurs TLS en ligne l'indiquent. Les outils de développement du navigateur montrent aussi le groupe négocié pour un site visité. Pour tout le réseau, un test ponctuel ne suffit pas, car ce qui compte est ce qui se passe réellement chaque jour entre vos clients et vos serveurs : vieux clients, appliances et applications internes reviennent souvent à des groupes classiques. NQCI, en préversion, le montre par connexion sur le trafic surveillé. Il est visible dans chaque offre et actif à partir de l'offre Pro, avec le capteur de capture de paquets activé pour un agent Linux ou une sonde SPAN ou TAP, car le mode de base sous macOS ne voit pas les négociations. Le résultat montre où les mises à jour ont déjà fait la migration et où elle reste à faire.

https://netsenx.com/fr/faq/which-connections-already-use-hybrid-key-exchange

## Que doit contenir un inventaire cryptographique ?

Pour chaque endroit où la cryptographie protège quelque chose, notez ce qui est protégé, comment, et qui peut le modifier. Champs pratiques : le système ou le service et son responsable ; ce qu'il protège, avec le type de données et le nombre d'années pendant lesquelles elles doivent rester secrètes ; le protocole, comme TLS, SSH, IPsec, S/MIME, la signature de code ou le chiffrement des disques et des bases de données ; les algorithmes d'échange de clés, de signature et de chiffrement, avec les tailles de clé ; les certificats, leur émetteur et leur expiration ; la version de la bibliothèque ou du produit et l'existence d'un plan post-quantique chez le fournisseur ; et la possibilité de changer l'algorithme par configuration. Ajoutez une priorité tirée de l'inégalité de Mosca. Les sources diffèrent selon la couche : observation du réseau pour ce qui transite, gestion des certificats et scanners pour les certificats, analyse de la composition logicielle et questionnaires fournisseurs pour ce qui se trouve dans les applications. Un inventaire limité aux certificats oublie l'échange de clés, et un inventaire construit seulement à partir du réseau oublie les données stockées. Tenez-le à jour, car chaque mise à jour peut changer la réponse, et datez chaque entrée : auditeurs et appels d'offres demandent quand il a été vérifié pour la dernière fois.

https://netsenx.com/fr/faq/what-should-a-cryptographic-inventory-include

## NetSenX nous protège-t-il contre les ordinateurs quantiques ?

Non, et aucun produit de surveillance réseau ne le peut. La protection contre un futur ordinateur quantique vient du changement de la cryptographie dans vos propres systèmes et dans ceux de vos fournisseurs : d'abord l'échange de clés hybride, ensuite les signatures post-quantiques. NetSenX n'est pas un produit de chiffrement et ne modifie, ne met à niveau ni ne migre rien. Il vous donne de la visibilité, point de départ de toute migration. NQCI, l'inventaire cryptographique de NetSenX, est en préversion : visible dans chaque offre et actif à partir de l'offre Pro. Il montre quelles connexions du trafic surveillé utilisent encore un échange de clés vulnérable au quantique et lesquelles utilisent déjà un échange hybride post-quantique : vous voyez où les mises à jour ont déjà fait le travail et où non, et vous repérez plus tard les régressions. Il nécessite le capteur de capture de paquets, désactivé par défaut : activé pour un agent Linux, ou une sonde sur un port SPAN ou TAP ; le mode de base sous macOS ne voit pas les négociations. Il ne voit pas la cryptographie à l'intérieur des applications, sur les disques ni sur les segments qu'aucun capteur ne surveille.

https://netsenx.com/fr/faq/does-netsenx-protect-us-against-quantum-computers

## Comment répondre à une question d'appel d'offres sur la préparation post-quantique ?

Avec des faits sur votre plan, pas des slogans. Les évaluateurs cherchent en général quatre choses : que vous sachiez où vous utilisez une cryptographie vulnérable au quantique, que vous ayez fixé des priorités, que vous ayez un calendrier et que quelqu'un en soit responsable. Une bonne réponse cite l'inventaire et sa date ; la méthode de priorisation, par exemple l'inégalité de Mosca appliquée aux durées de conservation ; les mesures déjà prises, comme l'échange de clés hybride activé sur les services publics et les versions VPN et SSH vérifiées ; les dépendances envers les fournisseurs, avec leurs plans déclarés ; et des jalons alignés sur la feuille de route coordonnée de l'UE : premiers pas d'ici fin 2026, cas d'usage à haut risque d'ici fin 2030. Citez nommément les normes NIST FIPS 203, 204 et 205. N'affirmez pas que votre service est immunisé contre les attaques quantiques : un évaluateur averti vous pénalisera. Si votre inventaire provient en partie de l'observation du réseau, dites-le et précisez ce qu'il ne couvre pas. Une réponse honnête et partielle, datée, obtient une meilleure note qu'un vide assuré.

https://netsenx.com/fr/faq/how-to-answer-an-rfp-question-on-post-quantum-readiness

## Que demander aux fournisseurs sur leur préparation post-quantique ?

Posez des questions dont les réponses sont vérifiables. Quels algorithmes post-quantiques ou hybrides le produit prend-il en charge aujourd'hui, nommément, comme X25519MLKEM768 pour TLS ou ML-DSA pour les signatures, et depuis quelle version ? S'il n'y en a pas encore, dans quelle version et pour quand ? Les algorithmes peuvent-ils être changés par configuration ou mise à jour, sans remplacer le matériel ? Quelle bibliothèque cryptographique le produit utilise-t-il, et qui la maintient ? Le matériel, comme un pare-feu, un module matériel de sécurité ou un automate, a-t-il la capacité de gérer des clés plus grandes, ou faudra-t-il le remplacer ? Comment le fournisseur signera-t-il ses propres mises à jour quand les algorithmes de signature changeront ? Le produit continuera-t-il de fonctionner pendant la transition avec des clients qui ne gèrent que les algorithmes classiques ? Demandez les réponses par écrit, avec des dates. Méfiez-vous des réponses qui promettent une immunité contre les attaques quantiques ou qui ne parlent que de chiffrement symétrique : elles éludent la vraie question. Un fournisseur incapable de répondre est une dépendance à intégrer à votre plan, et sa réponse a sa place dans votre inventaire.

https://netsenx.com/fr/faq/what-to-ask-vendors-about-post-quantum-readiness

FAQ: https://netsenx.com/fr/faq