Post-quantique : avant de migrer, savez-vous où votre SI utilise réellement la cryptographie ?

La transition vers la cryptographie post-quantique peut facilement être abordée comme un sujet d’algorithmes : quels standards adopter, quelles bibliothèques remplacer, quels produits acheter ?

Pour beaucoup d’organisations, ce n’est pourtant pas le premier problème à résoudre.

Avant de choisir une technologie post-quantique, il faut être capable de répondre à une question beaucoup plus élémentaire : où la cryptographie est-elle réellement utilisée dans le système d’information, pour protéger quoi, pendant combien de temps et avec quelles dépendances ?

L’ANSSI recommande désormais aux organisations publiques comme privées de démarrer un travail d’inventaire de leurs usages cryptographiques. Sa feuille de route 2026-2027 prévoit également de premières étapes d’inventaire pour les administrations de l’État, avec une transition qui doit être anticipée sur plusieurs années.12

Le sujet post-quantique commence donc moins par une migration technique que par un problème de visibilité sur le SI.

Le premier inventaire n’est pas une liste d’algorithmes

Chercher RSA, ECC ou AES dans des fichiers de configuration peut être utile. Mais une liste d’algorithmes ne permet pas à elle seule de décider quoi migrer en priorité.

Pour préparer une transition, il faut comprendre le cas d’usage derrière le mécanisme cryptographique.

Un certificat TLS exposé sur un site institutionnel, une signature électronique engageant juridiquement une entreprise, une liaison VPN avec un partenaire industriel ou une clé protégeant des archives confidentielles pendant quinze ans n’ont pas les mêmes conséquences.

L’ANSSI recommande notamment d’identifier les produits et usages métier intégrant de la cryptographie, les algorithmes employés et les données dont la confidentialité ou l’authenticité doivent rester garanties au-delà de 2030.1

Cela revient à transformer un inventaire technique en une cartographie de relations.

| Élément à connaître | Exemple de question | |---|---| | Usage métier | Pourquoi utilise-t-on la cryptographie ici ? | | Donnée protégée | Quelle information doit rester confidentielle ou authentique ? | | Durée de protection | Jusqu’à quelle date cette protection reste-t-elle nécessaire ? | | Application ou service | Quel système exploite ce mécanisme ? | | Protocole | TLS, IPsec, SSH, S/MIME, signature… ? | | Algorithme / mécanisme | Quels mécanismes cryptographiques sont réellement employés ? | | Produit ou équipement | Quel composant les implémente ? | | Fournisseur | Qui contrôle sa feuille de route de migration ? | | Dépendances | Quels autres services utilisent le même composant ? | | Cycle de renouvellement | À quelle date peut-il raisonnablement être remplacé ? |

La valeur de cet inventaire n’est donc pas dans le nombre de lignes collectées. Elle est dans les relations entre ces lignes.

Une application ne « fait » généralement pas sa cryptographie toute seule

Prenons une application métier accessible depuis Internet.

Son équipe peut considérer qu’elle utilise simplement HTTPS. En réalité, plusieurs couches du SI peuvent participer à cette protection : un reverse proxy termine TLS, un gestionnaire de certificats renouvelle les clés, une autorité de certification interne délivre certains certificats, un équipement réseau sécurise les échanges intersites et une bibliothèque applicative signe certains documents.

Une seule application peut donc dépendre de plusieurs mécanismes cryptographiques dont les propriétaires et les cycles de vie sont différents.

Inversement, un même composant cryptographique peut être partagé par des dizaines d’applications.

C’est ce qui rend une migration conduite application par application difficile à piloter.

Une représentation utile pourrait suivre une chaîne de ce type :

processus métier → application → flux → protocole → composant cryptographique → produit ou équipement → fournisseur → stratégie de migration

Cette représentation n’est pas un modèle réglementaire ni une méthode imposée par l’ANSSI. C’est une manière opérationnelle de transformer l’inventaire en outil de décision.

Elle permet surtout de répondre à une question importante : si ce composant doit être remplacé, quel est le véritable rayon d’impact ?

La durée de vie de la donnée peut être plus importante que la criticité du serveur

La transition post-quantique introduit une dimension inhabituelle dans la priorisation : le temps.

Un système peut être parfaitement protégé aujourd’hui et néanmoins exposer des informations qui devront encore être confidentielles lorsque des capacités cryptographiques aujourd’hui hors de portée deviendront disponibles.

L’ANSSI demande ainsi aux organisations d’intégrer la menace quantique à leur analyse de risque et d’identifier les données et usages dont la protection doit persister dans le temps.13

Cela change la manière de hiérarchiser l’inventaire.

Une plateforme peu critique pour la disponibilité peut par exemple traiter des informations dont la confidentialité doit être maintenue pendant vingt ans. Elle peut alors devenir prioritaire dans une stratégie post-quantique.

À l’inverse, un service extrêmement critique mais manipulant uniquement des données publiques et éphémères peut présenter un enjeu différent.

La question n’est donc pas seulement :

« Quel système est le plus critique aujourd’hui ? »

Elle devient aussi :

« Quelle information doit encore être protégée lorsque le contexte cryptographique aura changé ? »

Cas construit : cinq usages cryptographiques derrière un seul service

Prenons une entreprise fictive qui exploite un portail permettant à ses clients industriels d’échanger des dossiers techniques.

L’application apparaît dans le catalogue SI comme un seul service.

En examinant ses dépendances, l’équipe découvre pourtant cinq usages distincts de la cryptographie :

• TLS est terminé par un load balancer cloud ;
• les utilisateurs internes s’authentifient au moyen d’une fédération d’identité ;
• certains documents déposés sont signés ;
• les données archivées sont chiffrées par un service de gestion de clés ;
• les échanges avec un partenaire historique passent par un VPN installé sur un équipement physique.

Les documents techniques doivent rester confidentiels pendant quinze ans.

L’équipe ne peut donc pas créer une ligne « portail client — cryptographie à migrer » et considérer l’inventaire terminé.

Elle doit retrouver plusieurs responsables, plusieurs technologies et plusieurs fournisseurs.

Le load balancer dépend de la feuille de route du fournisseur cloud. Le VPN dépend d’un équipement dont le remplacement est prévu dans quatre ans. La signature repose sur une bibliothèque intégrée au développement interne. Le service de gestion de clés suit encore un autre cycle d’évolution.

Le problème de migration n’est déjà plus un problème d’algorithme.

C’est un problème d’architecture et de dépendances.

Le fournisseur fait partie de l’inventaire

Une part significative des mécanismes cryptographiques n’est pas directement contrôlée par l’entreprise.

Les algorithmes peuvent être implémentés dans un pare-feu, une appliance VPN, un HSM, une plateforme cloud, un logiciel SaaS, une PKI externe ou une bibliothèque maintenue par un tiers.

L’ANSSI recommande explicitement d’identifier les équipements qui devront évoluer et de contacter leurs fournisseurs pour connaître leur feuille de route post-quantique.1

Pour chaque dépendance structurante, plusieurs informations deviennent donc utiles :

• produit et version utilisés ;
• mécanisme cryptographique concerné ;
• statut de support ;
• date prévue de fin de support ;
• capacité annoncée à intégrer des mécanismes post-quantiques ;
• date prévisionnelle de disponibilité ;
• dépendances SI utilisant ce produit ;
• possibilité ou non de remplacer le composant indépendamment du reste du système.

Une feuille de route fournisseur ne doit cependant pas être confondue avec une stratégie de migration interne.

Savoir qu’un éditeur proposera une version compatible post-quantique en 2028 ne dit pas quand l’entreprise pourra réellement la déployer, ni quelles applications seront impactées par cette mise à niveau.

L’inventaire doit préparer l’agilité cryptographique

Le groupe de travail cybersécurité du G7 recommande lui aussi de structurer la transition autour de plusieurs dimensions : gouvernance, identification des usages cryptographiques, gestion des risques, agilité cryptographique et conduite de la transformation.4

L’agilité cryptographique consiste notamment à éviter qu’un mécanisme soit si profondément intégré à une architecture qu’il devienne extrêmement difficile de le remplacer.

L’inventaire peut révéler ces situations.

Deux applications utilisant le même algorithme ne présentent pas nécessairement la même capacité de migration.

Dans la première, la cryptographie est fournie par une bibliothèque maintenue, abstraite derrière une interface et facilement mise à niveau.

Dans la seconde, le mécanisme est inscrit dans un protocole propriétaire utilisé par plusieurs partenaires et intégré à un équipement en fin de support.

Techniquement, les deux lignes de l’inventaire peuvent afficher le même algorithme.

Architecturalement, elles n’ont rien à voir.

Une cartographie utile doit donc également faire apparaître la difficulté prévisible de remplacement.

L’objectif n’est pas de tout inventorier au même niveau de détail

Chercher dès le premier jour chaque certificat, chaque clé et chaque primitive cryptographique du SI risque de produire un projet interminable.

L’ANSSI indique d’ailleurs que les outils automatisés d’inventaire cryptographique peuvent compléter la démarche, mais qu’ils ne remplacent pas un processus plus large d’identification des besoins et des cas d’usage.1

Une approche progressive peut commencer par les usages présentant au moins l’une de ces caractéristiques :

1. données dont la confidentialité doit être conservée longtemps ;
2. fonctions de signature ou d’authentification importantes ;
3. équipements ayant un cycle de renouvellement long ;
4. produits fortement partagés dans le SI ;
5. dépendances fournisseurs difficiles à substituer ;
6. protocoles inter-organisations nécessitant une migration coordonnée.

Une fois ces périmètres identifiés, l’inventaire peut être approfondi jusqu’au niveau technique nécessaire.

Cette approche évite de confondre deux objectifs différents : découvrir tous les objets cryptographiques et savoir où commencer la transition.

Le calendrier de renouvellement du SI devient une variable post-quantique

La transition ne se fera pas en une seule opération.

L’ANSSI estime qu’elle s’inscrira sur plus d’une décennie et recommande de l’intégrer aux cycles normaux de renouvellement des systèmes. L’agence indique également qu’il ne serait pas raisonnable, à partir de 2030, d’acquérir de nouveaux produits qui ne prennent pas en compte la cryptographie post-quantique.13

Cette perspective rend les décisions prises aujourd’hui importantes.

Un équipement acheté en 2027 et prévu pour rester en production huit ans peut traverser une grande partie de la période de transition.

La question post-quantique peut donc apparaître bien avant le projet de migration lui-même, dans les appels d’offres, les exigences fournisseurs et les décisions d’architecture.

L’inventaire cryptographique devient alors également un moyen de répondre à une autre question :

quels investissements effectués aujourd’hui risquent de créer la dette cryptographique de demain ?

Un exercice simple pour commencer

Une organisation peut tester son niveau de visibilité sans lancer immédiatement un programme de transformation complet.

Choisir une donnée dont la confidentialité doit être conservée pendant au moins dix ans.

Puis tenter de reconstruire toute sa chaîne de protection :

donnée → processus métier → applications → flux → protocoles → équipements ou services → mécanismes cryptographiques → fournisseurs → cycles de renouvellement.

Si cette chaîne peut être obtenue rapidement, l’organisation dispose déjà d’une base exploitable.

Si elle nécessite plusieurs jours d’entretiens, de recherches dans les configurations et de rapprochement entre inventaires indépendants, le premier chantier post-quantique est probablement identifié.

Il ne s’agit pas encore de remplacer la cryptographie existante.

Il s’agit de savoir précisément ce qu’il faudra un jour remplacer, dans quel ordre, et pourquoi.