Comment estimer le périmètre d’impact d’une migration post-quantique
« Quelle est la taille de notre migration post-quantique ? » C'est la première question posée à tout programme, et celle à laquelle la plupart des inventaires ne savent pas répondre. Un nombre de findings RSA n'est pas un périmètre. Le périmètre d'impact d'une migration (son « blast radius »), c'est tout ce qui doit changer, être testé ou coordonné quand un algorithme est remplacé : code, certificats, services, partenaires et équipes.
Partir d'un inventaire avec provenance
On ne dimensionne pas ce qu'on ne sait pas localiser. Chaque finding doit dire où il se trouve — fichier et ligne, magasin de certificats ou endpoint TLS — et à quoi il sert : signature, échange de clés, chiffrement ou hachage. Le cas d'usage compte autant que l'algorithme : remplacer une signature RSA (vers ML-DSA) et un transport de clé RSA (vers ML-KEM) sont deux projets différents, avec des dépendances différentes.
Cinq étapes vers une estimation défendable
- Regrouper par algorithme et cas d'usage. Séparer la cryptographie déjà cassée (MD5, SHA-1, clés RSA courtes) des candidats à la migration PQC (RSA, ECDSA, ECDH, Ed25519) et de la cryptographie à conserver (AES-256, SHA-256+).
- Relier les findings à leurs responsables. Traduire chemins de fichiers et endpoints en services et en équipes. Le nombre de fichiers ou services distincts porteurs de findings critiques et élevés mesure mieux la portée du chantier que le nombre brut de findings.
- Trouver les points de concentration. Une clé de signature JWT partagée, une AC interne, une bibliothèque d'encapsulation cryptographique ou un terminateur TLS peuvent représenter des dizaines de findings. En changer un corrige beaucoup d'actifs d'un coup — ou casse beaucoup de parties dépendantes si c'est fait sans coordination.
- Pondérer par la complexité de migration. Remplacer un hachage n'est pas une migration asymétrique. La roadmap de CRYPTAGION utilise une heuristique simple par actif — environ 0,25 mois-personne quand peu de choses changent, 1 pour une complexité faible, 3 pour une complexité moyenne, 8 pour une complexité élevée — à ajuster avec le client, pas à utiliser comme devis.
- Séquencer en vagues. Les gains rapides d'abord, puis les chantiers prioritaires de complexité moyenne, puis les systèmes complexes et profondément embarqués, en s'appuyant sur la durée de vie des données et votre scénario de planification CRQC.
Un exemple d’inventaire de sources
Notre démonstration pyca/cryptography sur une révision figée (en anglais) distingue 46 détections dans la bibliothèque, 1 746 dans les tests et 12 dans les scripts de documentation. Elle ne mesure ni exposition en production ni effort de migration. Chaque constat doit être relié à son contexte opérationnel avant de dimensionner un chantier.
Réduire le périmètre avant de migrer
- Centraliser la cryptographie derrière un fournisseur ou un service, pour qu'un changement d'algorithme soit un changement de configuration, pas une chasse dans le code. Voir la crypto-agilité expliquée.
- Empêcher qu'il grandisse. Une gate CI sur toute nouvelle cryptographie à haut risque stabilise la base pendant la migration — voir CRYPTAGION dans la CI/CD (en anglais).
- Suivre la dérive. Prendre un instantané de l'inventaire à chaque version et le comparer, pour que l'estimation reste à jour.
Savoir ce que l'estimation ne couvre pas
Une estimation construite à partir du code source, des certificats et des endpoints TLS ne voit ni les binaires tiers compilés, ni les firmwares, ni la configuration des HSM, ni les systèmes des partenaires. Listez-les explicitement comme points ouverts, avec un responsable, plutôt que de les laisser disparaître du périmètre.
Dimensionner votre propre migration
Nous exécutons CRYPTAGION sur un dépôt représentatif pendant l'appel et montrons la portée, les vagues et l'effort — dans votre périmètre.
Réserver un appel découverte gratuit →