400 certificats, 3 algorithmes obsolètes et 1 réveil brutal — l’inventaire cryptographique post-quantique en 7 étapes

Le mot « post-quantique » produit deux réactions chez les dirigeants de PME, et les deux sont mauvaises. La première : c’est de la science-fiction, on verra dans dix ans. La seconde, plus rare mais plus coûteuse : il faut tout changer maintenant. La réponse utile est entre les deux, et elle commence par un travail qui ne demande aucune décision technologique.

Sur la mission qui a servi de base à ce guide, l’inventaire a remonté un peu plus de 400 certificats et clés dans une entreprise de 180 personnes. Le responsable informatique en connaissait environ soixante-dix. Nous avons trouvé trois algorithmes obsolètes encore actifs, dont un sur une liaison automate qu’aucun contrat de maintenance ne couvrait plus depuis quatre ans.

Aucune de ces découvertes n’avait de rapport avec l’informatique quantique. Toutes étaient des risques immédiats. C’est le premier bénéfice de cet exercice, et c’est celui qui le rend finançable.

Étape 1 — Inventorier les certificats et les clés, sans rien migrer

L’erreur de départ la plus fréquente consiste à choisir un algorithme avant de savoir ce qu’on protège. Commencez par la liste, et uniquement la liste.

Quatre sources à croiser. Les certificats TLS : ceux de vos sites publics sont faciles, ceux des services internes, des équilibreurs de charge et des interfaces d’administration le sont beaucoup moins. Les clés SSH : sur les serveurs, mais aussi dans les tâches planifiées, les dépôts de code et les postes des prestataires. Les certificats applicatifs : signature de documents, authentification client, jetons signés. Les clés matérielles : cartes, modules de sécurité, badges, et tout ce qui embarque une puce.

Pour chaque entrée, quatre colonnes suffisent : l’algorithme et la taille de clé, la date d’expiration, le système qui l’utilise, et surtout le nom d’une personne responsable. Cette dernière colonne est celle qui fait le travail : une ligne sans propriétaire est un risque non traité, quel que soit son algorithme.

Comptez trois à six semaines pour une PME de 100 à 300 personnes. Le temps ne part pas dans la collecte technique, qui s’automatise largement, mais dans l’identification des propriétaires et dans la découverte des systèmes que personne n’avait listés.

Étape 2 — Recenser les bibliothèques et les protocoles, pas seulement les clés

Une clé est visible. La bibliothèque cryptographique qui l’utilise ne l’est pas, et c’est pourtant elle qui déterminera votre capacité à migrer.

Deux questions par application : quelle bibliothèque cryptographique embarque-t-elle, et cette bibliothèque est-elle remplaçable sans recompiler l’application ? La seconde question est décisive. Une application qui utilise la bibliothèque du système d’exploitation bénéficiera des mises à jour sans effort de votre part. Une application qui embarque sa propre copie compilée devra être reprise par son éditeur — et si cet éditeur n’existe plus, vous venez de trouver votre vrai problème.

Ajoutez les protocoles : versions de TLS acceptées, suites de chiffrement autorisées, mécanismes d’échange de clés. C’est ici que remontent les algorithmes obsolètes — dans notre cas, trois, tous sur des systèmes dont personne ne se souvenait qu’ils négociaient encore ces suites.

Étape 3 — Classer les données par durée de confidentialité exigée

C’est l’étape qui transforme un inventaire technique en plan d’action, et c’est une étape métier : elle ne se fait pas dans la salle serveur mais avec les directions concernées.

Trois catégories suffisent. Vie longue — plus de dix ans : dossiers de santé, résultats de recherche, contrats à long terme, propriété intellectuelle, archives légales. Vie moyenne — trois à dix ans : données commerciales, correspondance contractuelle, éléments financiers. Vie courte — moins de trois ans : sessions, télémétrie, journaux opérationnels, échanges transactionnels.

Croisez ensuite cette classification avec l’exposition réseau du flux qui transporte la donnée. C’est ce croisement, et lui seul, qui produit votre ordre de priorité.

Étape 4 — Vérifier l’agilité cryptographique de chaque système

L’agilité cryptographique est la capacité d’un système à changer d’algorithme sans être réécrit. C’est la propriété qui décide si votre migration coûtera des jours ou des mois, et elle se mesure avant de migrer quoi que ce soit.

Trois questions par système. L’algorithme est-il configurable ou codé en dur ? S’il figure dans un fichier de configuration, vous êtes agile. S’il est dans le code source, vous dépendez de l’éditeur. Le système gère-t-il plusieurs algorithmes simultanément ? C’est indispensable pour une transition sans interruption. Existe-t-il un chemin de repli testé ? Si la nouvelle configuration échoue en production un dimanche soir, savez-vous revenir en arrière, et en combien de temps ?

Classez chaque système en trois groupes : agile — configurable, à migrer quand vous voudrez ; semi-agile — nécessite une mise à jour de l’éditeur, à inscrire au calendrier avec lui ; rigide — matériel embarqué, éditeur disparu, système non maintenu. Le groupe rigide est le seul qui commande des décisions difficiles, et il est généralement petit. Dans notre inventaire, il comptait quatre entrées sur plus de quatre cents.

Étape 5 — Adopter le mode hybride, jamais le remplacement sec

Sur les flux prioritaires, la bonne pratique de transition consiste à négocier simultanément un algorithme classique et un algorithme résistant au quantique, la sécurité de la liaison reposant sur la combinaison des deux. C’est le mode hybride, et il est aujourd’hui le consensus des recommandations publiques sur le sujet.

Sa vertu principale est prosaïque : il ne casse rien. Si l’algorithme post-quantique retenu se révèle faible — hypothèse qui n’a rien de théorique, plusieurs candidats ayant été écartés en cours d’évaluation — la sécurité classique tient toujours. Et si un correspondant ne sait pas encore négocier le nouvel algorithme, la connexion s’établit quand même.

La conséquence opérationnelle est qu’une migration hybride se déploie progressivement, service par service, sans fenêtre de bascule et sans coordination avec vos partenaires. C’est ce qui la rend réalisable dans une PME qui n’a pas d’équipe dédiée.

Attention à un point souvent négligé : les clés post-quantiques et les échanges associés sont plus volumineux que leurs équivalents classiques. Sur des liaisons contraintes — supervision industrielle, capteurs, liens satellitaires — cela se mesure. Testez avant de généraliser.

Étape 6 — Inscrire l’exigence dans les contrats avant de la traiter en projet

Voici l’étape la moins technique et la plus rentable. La majorité de votre parc migrera d’elle-même, au rythme des renouvellements de matériel et des mises à jour logicielles — à condition que vous l’ayez exigé au moment de l’achat.

Ajoutez donc à vos cahiers des charges et à vos renouvellements de contrat une clause simple : le fournisseur s’engage à prendre en charge les algorithmes résistants au quantique et à documenter son calendrier. Cette clause ne coûte rien aujourd’hui et supprime, dans cinq ans, la ligne budgétaire correspondante.

Le même raisonnement s’applique à vos prestataires d’hébergement et de sauvegarde. Un prestataire incapable de décrire son calendrier sur ce sujet vous en apprend beaucoup sur sa gestion technique en général, indépendamment du sujet quantique.

Étape 7 — Réévaluer chaque année, et documenter la décision de ne rien faire

Un inventaire cryptographique se périme. Les certificats sont renouvelés, les applications changent, de nouveaux services apparaissent. Une revue annuelle d’une demi-journée suffit à le maintenir, à condition que la colonne « propriétaire » ait été remplie à l’étape 1.

Le point le plus important de cette étape est contre-intuitif : documentez explicitement ce que vous avez décidé de ne pas migrer, et pourquoi. « Les journaux applicatifs restent en chiffrement classique parce que leur durée de confidentialité est inférieure à dix-huit mois » est une décision défendable, tracée et opposable. La même absence de migration sans écrit est un oubli.

Cette distinction n’est pas cosmétique. En cas de contrôle, d’audit d’assurance ou d’incident, l’écart entre une décision motivée et un angle mort est exactement ce qui sépare une organisation sérieuse d’une organisation négligente — et les conséquences ne sont pas les mêmes.

Ce que ça coûte, réellement

Les ordres de grandeur constatés pour une PME française de 100 à 300 personnes. Inventaire et classification : de 8 000 à 18 000 euros hors taxes selon l’hétérogénéité du parc, ou trois à six semaines en interne si vous disposez de la compétence. Migration des flux de priorité 1 : très variable, généralement de 15 000 à 60 000 euros, l’essentiel du coût venant des systèmes semi-agiles nécessitant une coordination éditeur.

Le reste du parc devrait tendre vers zéro, et c’est le test de qualité de votre plan. Si votre chiffrage prévoit un budget significatif pour les priorités 3 et 4, c’est que vous avez transformé en projet ce qui devait être absorbé par les cycles de renouvellement normaux.

Rapporté au bénéfice immédiat — trois algorithmes obsolètes trouvés, quatre systèmes rigides identifiés, plus de trois cents certificats sortis de l’ombre — l’inventaire se justifie sans invoquer le moindre ordinateur quantique. C’est l’argument à présenter en comité de direction.

Pour aller plus loin

La gestion documentée des actifs et des vulnérabilités relève des mêmes attendus que ceux décrits dans notre page audit de périmètre NIS2, et l’inventaire cryptographique en constitue une brique directement réutilisable. Notre page migration post-quantique détaille le déroulé d’accompagnement.

Côté développement, la question de l’agilité cryptographique se joue largement dans les bibliothèques embarquées par vos applications : nos confrères de D-Open traitent régulièrement la gestion des dépendances et des chaînes de compilation, où se règle une bonne part du problème. Et si vos flux alimentent des plateformes d’intelligence artificielle — dont les jeux de données ont souvent une durée de confidentialité longue et mal évaluée — Plug-Tech couvre la gouvernance de ces pipelines en PME.