Dans une entreprise, personne ne sait toujours combien de certificats circulent, quelle bibliothèque chiffre les sauvegardes ou comment un automate vérifie ses mises à jour. Voilà pourtant où commence la préparation à l’après-quantique. Pas devant une machine de laboratoire, mais dans les configurations, les contrats fournisseurs et le code ancien. À l’horizon de septembre 2026, le chantier se précise : les standards existent, mais retrouver les mécanismes à remplacer pourrait demander davantage d’efforts que leur remplacement.
Des standards, enfin un point d’appui
Le 13 août 2024, le National Institute of Standards and Technology américain a publié ses trois premiers standards de cryptographie post-quantique. ML-KEM, issu de CRYSTALS-Kyber, sert à établir un secret partagé. ML-DSA, dérivé de CRYSTALS-Dilithium, et SLH-DSA, issu de SPHINCS+, concernent les signatures numériques. Ces textes, respectivement FIPS 203, 204 et 205, donnent aux industriels une base stable pour développer des produits interopérables et préparer leurs migrations.
La nuance compte : ces algorithmes ne nécessitent pas de réseau quantique. Ils fonctionnent sur des ordinateurs classiques et visent à résister aux attaques classiques comme aux attaques quantiques connues. Leur standardisation ne transforme pas non plus chaque produit qui les intègre en solution automatiquement sûre. Il faut encore vérifier l’implémentation, les protocoles, la gestion des clés et les conditions d’exploitation.
Dans la perspective de septembre 2026, le changement attendu est donc moins spectaculaire qu’un basculement général : davantage d’offres compatibles, d’expérimentations et d’exigences dans les appels d’offres. Mais un algorithme disponible ne signifie pas un système migré. Entre les deux se trouvent les applications métier, les équipements non remplaçables et les dépendances que personne n’avait documentées.
La menace ne commence pas le jour où la machine arrive
Un ordinateur quantique suffisamment puissant et corrigé d’erreurs pourrait compromettre les mécanismes à clé publique aujourd’hui très répandus, notamment RSA et ceux fondés sur les courbes elliptiques. Aucun calendrier fiable ne permet de dater cette capacité. Cela ne justifie ni l’alarmisme ni l’attentisme : le temps nécessaire pour migrer un système peut se compter en années.
Le scénario le plus immédiat porte un nom : collecter aujourd’hui, déchiffrer demain. Un adversaire peut conserver des communications chiffrées en espérant les ouvrir ultérieurement. Pour un dossier médical, un secret industriel ou une information diplomatique, la confidentialité utile dépasse parfois largement la durée de vie du logiciel qui assure sa protection.
Tout chiffrement n’est cependant pas menacé de la même façon. Les primitives symétriques, comme AES avec des paramètres adaptés, ne se remplacent pas selon la même logique que RSA. La priorité consiste à comprendre comment les clés sont établies, protégées et utilisées. Et la confidentialité n’est pas seule concernée : les signatures sécurisent aussi les logiciels, les identités et les mises à jour des équipements.
La cryptographie cachée dans les murs
Imaginons un groupe industriel préparant sa transition. L’équipe réseau identifie les connexions TLS et les VPN. Le chantier paraît circonscrit. Puis apparaît un serveur de transfert de fichiers, suivi d’une autorité de certification interne oubliée, d’un composant mobile et d’une passerelle de maintenance fournie par un sous-traitant. Enfin, un automate refuse toute mise à jour dont la signature ne correspond pas à un mécanisme gravé dans son micrologiciel.
Ce cas illustratif montre pourquoi l’inventaire dépasse la liste des algorithmes. La cryptographie se cache dans les bibliothèques, les composants intégrés, les services cloud, les modules matériels de sécurité et les chaînes de compilation. Une application peut utiliser plusieurs mécanismes différents sans que son responsable fonctionnel en connaisse un seul.
Il faut aussi distinguer les usages. Un certificat visible sur Internet n’indique pas comment les sauvegardes sont protégées. Une base chiffrée avec AES peut dépendre d’une infrastructure à clé publique pour distribuer ses clés. Un logiciel moderne peut embarquer une vieille bibliothèque. Cartographier les dépendances importe autant que relever les noms d’algorithmes.
Ce qu’un inventaire utile doit contenir
La bonne unité de travail n’est donc pas seulement « RSA présent » ou « TLS activé ». Chaque usage doit être relié à un actif, à un responsable et à un enjeu métier. Une première fiche exploitable rassemble au minimum :
- La fonction : établissement de clés, signature, authentification ou chiffrement des données.
- Le mécanisme : algorithme, paramètres, protocole, bibliothèque et version lorsque ces informations sont accessibles.
- Le contexte : données concernées, durée de confidentialité, exposition et durée de vie de l’équipement.
- Les dépendances : fournisseur, certificats, infrastructure de clés et contraintes d’interopérabilité.
- La capacité de changement : mise à jour possible, remplacement matériel, échéance contractuelle et responsable désigné.
Plusieurs méthodes doivent se compléter : analyse du code, examen des configurations, observation des échanges réseau, inspection des certificats et questionnaires fournisseurs. Aucune ne suffit seule. Une capture réseau voit mal les traitements internes ; un scanner de code peut manquer une dépendance chargée à l’exécution. Une nomenclature cryptographique, ou CBOM, aide à structurer les résultats, sans garantir leur exhaustivité.
Prioriser plutôt que tout remplacer
L’inventaire n’a de valeur que s’il conduit à des décisions. Les premiers candidats sont souvent les systèmes qui protègent longtemps des informations sensibles, ceux dont le renouvellement sera difficile et les infrastructures qui commandent les autres : autorités de certification, distribution logicielle, accès d’administration. Un capteur installé pour quinze ans mérite une attention différente d’un service web redéployable chaque semaine.
Les fournisseurs deviennent alors un point de passage obligé. Plutôt que demander une simple étiquette « quantum-safe », l’acheteur doit obtenir une feuille de route : quels standards, quels produits, quelles versions, quelles dépendances matérielles ? Il doit également savoir comment la solution sera mise à jour si un algorithme ou son implémentation présente une faiblesse. Cette capacité d’évolution constitue la crypto-agilité.
Les essais doivent mesurer les effets concrets : taille des clés et des signatures, mémoire consommée, latence, fragmentation réseau et compatibilité des équipements intermédiaires. Certaines approches hybrides combinent mécanismes classiques et post-quantiques pendant la transition. Elles peuvent réduire la dépendance à une seule famille cryptographique, mais ajoutent de la complexité : mieux vaut suivre des constructions examinées que bricoler son propre assemblage.
Un projet de patrimoine informatique
Le responsable sécurité ne peut pas porter seul ce programme. Les achats détiennent les leviers contractuels, les équipes d’exploitation connaissent les contraintes de disponibilité, les développeurs maîtrisent les dépendances et les métiers évaluent la sensibilité des données. La direction doit arbitrer les coûts, notamment lorsque la migration impose de remplacer un matériel encore fonctionnel.
Et maintenant ? La trajectoire la plus crédible pour septembre 2026 serait de disposer d’un inventaire vivant sur un périmètre prioritaire, de tester quelques migrations et d’intégrer des exigences post-quantiques aux nouveaux achats. Le prochain progrès décisif ne sera pas forcément un nouvel algorithme : ce sera de savoir précisément où agir, qui décide et combien de temps le changement prendra.
