Checklist · RSSI

Checklist post-quantique : 15 questions auxquelles tout RSSI doit savoir répondre

Publié le 7 octobre 2026 · 7 min de lecture · Par Ali Korsi Si votre conseil d’administration, votre régulateur ou votre auditeur vous interrogeait demain sur le risque quantique, voici les questions auxquelles il faudrait répondre, et les preuves qui rendraient ces réponses crédibles.

Read in English

Les standards ne sont plus le goulet d’étranglement. Le NIST a approuvé FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA) en août 2024. En juin 2025, le groupe de coopération NIS a publié la feuille de route coordonnée de mise en œuvre de l’UE, qui attend de premières étapes, dont des inventaires cryptographiques, d’ici fin 2026, la migration des cas d’usage à haut risque d’ici fin 2030, et celle d’autant de systèmes que possible d’ici 2035. Le projet de NIST IR 8547 propose de déprécier les algorithmes à clé publique vulnérables au quantique après 2030 et de les interdire après 2035.

Ce qui manque encore dans la plupart des organisations, c’est une vision claire, étayée par des preuves, de leur situation réelle. Cette checklist est conçue pour vous la donner. Elle est volontairement pratique : chaque question est accompagnée de ce à quoi ressemble une « bonne » réponse, pour faire la différence entre une réponse réelle et une réponse optimiste.

Pressé ? Notre auto-évaluation gratuite de maturité post-quantique en 2 minutes pose les mêmes questions de façon interactive et vous attribue un score assorti de prochaines étapes.

1. Visibilité et inventaire

  1. Savons-nous où la cryptographie est utilisée dans l’ensemble de notre système d’information ?

    On ne peut ni migrer, ni prioriser, ni rendre compte de ce que l’on n’a pas trouvé. C’est précisément pour cette raison que la feuille de route de l’UE place les inventaires dans son premier jalon, fin 2026.

    Ce qu’on attend : un inventaire cryptographique (en anglais) couvrant le code source, les certificats et les endpoints réseau, construit par découverte outillée et pas uniquement par questionnaires.

  2. Cet inventaire est-il exploitable par machine et tenu à jour ?

    Un tableur compilé une fois pour un audit est obsolète en quelques semaines. L’inventaire doit suivre le rythme des mises en production.

    Ce qu’on attend : un CBOM au format CycloneDX 1.6 (en anglais), régénéré automatiquement, par exemple dans votre pipeline CI.

  3. Pouvons-nous nommer chaque algorithme vulnérable au quantique en usage, et dire où il se trouve ?

    RSA, ECDSA, ECDH et Diffie-Hellman sur corps finis sont les algorithmes que casse l’algorithme de Shor. Savoir qu’ils sont « quelque part » ne suffit pas.

    Ce qu’on attend : une liste par actif indiquant l’algorithme, la taille de clé, la bibliothèque et l’emplacement (fichier, certificat ou hôte), filtrable par responsable de système.

2. Risque et durée de vie des données

  1. Savons-nous combien de temps nos données sensibles doivent rester confidentielles ?

    C’est la durée de confidentialité qui fait passer le risque quantique d’un problème futur à un problème actuel.

    Ce qu’on attend : des classes de données avec des durées de conservation et de confidentialité documentées, rattachées aux systèmes qui les traitent.

  2. Avons-nous évalué notre exposition au risque « récolter maintenant, déchiffrer plus tard » ?

    Le trafic capturé aujourd’hui peut être déchiffré plus tard. Les données à longue durée de vie qui transitent sur les réseaux sous un échange de clés vulnérable au quantique sont déjà exposées.

    Ce qu’on attend : une évaluation HNDL (en anglais) documentée, identifiant les flux qui transportent des données à longue durée de vie via un échange de clés RSA ou ECDH.

  3. Le risque quantique est-il évalué par actif, et non par une note unique à l’échelle de l’organisation ?

    Une note globale ne dit pas par où commencer. La priorisation exige des écarts au niveau de chaque actif.

    Ce qu’on attend : chaque actif porte un score de risque combinant faiblesse de l’algorithme, exposition et durée de vie des données, de sorte que le haut de la liste soit défendable.

3. Gouvernance et réglementation

  1. Existe-t-il un responsable désigné et une ligne budgétaire pour la migration post-quantique ?

    La migration concerne les équipes applicatives, infrastructure, PKI et achats. Sans responsable, elle s’enlise entre elles.

    Ce qu’on attend : un dirigeant redevable, un chef de programme et un financement approuvé au moins pour l’inventaire et la première phase de migration.

  2. Avons-nous rattaché le risque quantique à nos obligations réglementaires ?

    DORA, NIS2 et le Cyber Resilience Act de l’UE exigent déjà une cryptographie et une gestion des risques appropriées. Le risque quantique relève de ces obligations.

    Ce qu’on attend : une correspondance entre les constats et les obligations de l’article 9 de DORA (en anglais), de l’article 21 de NIS2 et du CRA, revue par la conformité.

  3. Le conseil d’administration a-t-il reçu un briefing sur le risque quantique fondé sur nos propres données ?

    Les briefings génériques sur la menace n’aident pas à décider. Le conseil doit connaître votre exposition et le coût de sa correction.

    Ce qu’on attend : un rapport court au conseil présentant l’exposition actuelle, les priorités et le calendrier au regard des jalons européens 2026/2030/2035.

4. Fournisseurs et tiers

  1. Connaissons-nous les feuilles de route PQC de nos fournisseurs critiques ?

    Une grande partie de votre cryptographie se trouve dans des produits que vous ne maîtrisez pas : HSM, KMS cloud, passerelles VPN, plateformes de paiement et d’identité.

    Ce qu’on attend : des engagements écrits de vos fournisseurs critiques sur leur feuille de route, avec des dates de prise en charge de FIPS 203/204, suivis dans votre registre des risques tiers.

  2. Notre PKI et nos HSM peuvent-ils émettre et gérer des certificats post-quantiques ou hybrides ?

    La PKI (IGC) est souvent l’élément aux délais les plus longs : durée de vie des racines, mises à jour de firmware et compatibilité des parties utilisatrices prennent du temps.

    Ce qu’on attend : une évaluation testée du logiciel d’AC, du firmware des HSM et des consommateurs de certificats, avec un plan de renouvellement des AC racines et intermédiaires.

  3. Nos nouveaux contrats et achats intègrent-ils des exigences PQC ?

    Les systèmes achetés aujourd’hui pourraient encore fonctionner en 2035. Chaque nouveau contrat sans exigence prolonge votre exposition.

    Ce qu’on attend : des clauses d’achat types exigeant la prise en charge des standards PQC du NIST et la crypto-agilité, ainsi que la divulgation des composants cryptographiques (par exemple via un CBOM).

5. Exécution et crypto-agilité

  1. Disposons-nous d’une feuille de route de migration séquencée ?

    « Tout migrer » n’est pas un plan. C’est le séquencement par risque et par dépendances qui rend le travail réalisable.

    Ce qu’on attend : une feuille de route par phases, commençant par les actifs les plus exposés et au risque HNDL élevé, alignée sur le parcours de migration FIPS 203/204/205 (en anglais).

  2. Pouvons-nous changer d’algorithme sans réécrire l’application ?

    Les premiers algorithmes post-quantiques ne seront pas les derniers. La crypto-agilité détermine le coût de chaque changement futur.

    Ce qu’on attend : une cryptographie encapsulée dans des bibliothèques ou services centraux, des algorithmes définis par configuration, et aucune primitive codée en dur dans la logique métier.

  3. Empêchons-nous l’introduction de nouvelle cryptographie vulnérable au quantique ?

    Un inventaire sans contrôle à l’entrée, c’est un seau percé : les équipes continuent d’ajouter du RSA et de l’ECDSA pendant que vous les retirez.

    Ce qu’on attend : des contrôles automatisés dans la CI qui signalent tout nouvel usage vulnérable au quantique, avec un processus de dérogation.

Comment vous évaluer

Comptez un point pour chaque question à laquelle vous pourriez répondre aujourd’hui preuves à l’appui, et non sur la base d’intentions. Considérez le résultat comme un point de départ pour la discussion, pas comme une mesure : les niveaux ci-dessous sont des repères de praticien, pas un modèle de maturité validé.

ScoreCe que cela signifie généralement
0–5Stade initial. Commencez par l’inventaire (questions 1 à 3) : tout le reste en dépend.
6–10Fondations en place. Concentrez-vous sur le scoring du risque par actif, les feuilles de route fournisseurs et un plan séquencé.
11–15Bonne position. Portez votre attention sur l’exécution, la crypto-agilité et le maintien à jour de l’inventaire.

La place de CRYPTAGION

Plusieurs de ces questions reposent sur un inventaire exact. CRYPTAGION le construit par analyse statique de code Python, JavaScript/TypeScript, Java, Go et C/C++, analyse des certificats X.509 et scan en direct des endpoints TLS. Il attribue à chaque actif un score de risque quantique de 0 à 100 tenant compte de l’exposition HNDL, exporte un CBOM CycloneDX 1.6 (en anglais), produit un rapport PDF prêt pour le conseil d’administration, mappé sur DORA, NIS2, le CRA de l’UE et FIPS 203/204/205, et propose une feuille de route de migration en quatre vagues. Il se déploie sur site ou en environnement isolé (air-gapped).

Vous voulez votre score sans papier ni crayon ? Faites l’auto-évaluation gratuite de maturité post-quantique en 2 minutes.

Sources

Êtes-vous vraiment prêt ?

Obtenez un score de maturité en deux minutes, avec les prochaines étapes les plus importantes pour votre organisation.

Faire l’auto-évaluation en 2 minutes →

Vous préférez en parler ? Réserver un appel de découverte gratuit.