La crypto-agilité expliquée : comment la mesurer avant la migration post-quantique

Publié le 7 octobre 2026 · 8 min de lecture · Par Ali Korsi La migration post-quantique ne sera pas votre dernière migration cryptographique. C’est l’agilité qui rendra la suivante peu coûteuse — et elle se mesure.

Read in English

La « crypto-agilité » figure dans presque tous les documents de stratégie post-quantique, généralement comme un objectif, rarement comme quelque chose que l’on mesure. C’est un problème, car le coût de votre migration vers ML-KEM et ML-DSA dépendra moins des nouveaux algorithmes que de la manière dont les anciens sont enchevêtrés dans vos systèmes.

Ce que recouvre vraiment la crypto-agilité

Le Cybersecurity White Paper 39 du NIST, finalisé en décembre 2025, définit la crypto-agilité comme l’ensemble des capacités nécessaires pour remplacer et adapter les algorithmes cryptographiques dans les protocoles, applications, logiciels, matériels, micrologiciels et infrastructures, tout en préservant la sécurité et la continuité des opérations.

En pratique, un système agile permet de changer trois choses sans refondre l’architecture :

• Les algorithmes — de RSA à ML-KEM, d’ECDSA à ML-DSA, de SHA-1 à SHA-256.
• Les paramètres — tailles de clé, courbes, niveaux de sécurité, modes.
• Les implémentations — la bibliothèque, le fournisseur cryptographique, le HSM ou le KMS qui fait le travail.

Si modifier l’un de ces éléments oblige à toucher la logique applicative à des dizaines d’endroits, à réécrire un format de fichier ou à attendre la prochaine version majeure d’un éditeur, vous n’êtes pas agile — quoi qu’en dise le schéma d’architecture.

Pourquoi le post-quantique ne sera pas la dernière migration

Les migrations cryptographiques sont la norme, pas l’exception. Quelques-unes que la plupart des entreprises ont déjà vécues :

• SHA-1 — déprécié par le NIST pour les signatures numériques en 2011, victime de la première collision pratique publique en 2017, et appelé à disparaître totalement des usages approuvés par le NIST d’ici le 31 décembre 2030.
• Triple DES — fragilisé par sa taille de bloc de 64 bits (l’attaque Sweet32 de 2016) et interdit par le NIST pour le chiffrement après le 31 décembre 2023.
• RSA-1024 — interdit pour les nouvelles signatures numériques par le NIST SP 800-131A après 2013.

Chacune de ces migrations a pris des années à la plupart des organisations, surtout parce que personne ne savait où l’algorithme était utilisé. Le post-quantique pose le même problème à plus grande échelle : le projet de plan de transition du NIST (IR 8547) propose de déprécier les algorithmes RSA et à courbes elliptiques vulnérables au quantique après 2030, puis de les interdire après 2035.

Et les nouveaux algorithmes sont jeunes. En 2022, SIKE — alors candidat au quatrième tour du processus post-quantique du NIST — a été cassé par une attaque classique de récupération de clé exécutée en une heure environ sur un seul cœur. La même année, le schéma de signature Rainbow, finaliste du troisième tour, est tombé face à une attaque classique pratique. Aucun des deux n’a été normalisé, mais tous deux montrent que la confiance dans un nouvel algorithme peut s’effondrer rapidement.

C’est pourquoi les agences européennes poussent les déploiements hybrides, qui combinent un algorithme classique et un algorithme post-quantique afin que la sécurité ne repose sur aucun des deux isolément. L’ANSSI et le BSI recommandent tous deux l’hybridation pendant la transition et, en novembre 2024, 18 États membres de l’UE, emmenés par la France, l’Allemagne et les Pays-Bas, ont publié une déclaration commune appelant les organisations à faire de la transition une priorité. L’hybridation est une couverture ; l’agilité est ce qui permet d’en retirer plus tard la moitié la plus faible.

Les anti-patterns qui tuent l’agilité

Dans les revues de code et de configuration, les mêmes schémas reviennent :

• Algorithmes codés en dur — noms d’algorithmes et constructeurs disséminés dans la logique métier.
• Tailles de clé et courbes figées — 2048 ou secp256r1 sous forme de littéraux, souvent dupliqués dans les tests, les schémas et la largeur des colonnes en base de données.
• Cryptographie intégrée aux protocoles et aux formats de stockage — champs de signature de longueur fixe, formats binaires sans identifiant d’algorithme, jetons qui supposent un seul type de clé. Les signatures ML-DSA pèsent plusieurs kilo-octets ; un champ dimensionné pour ECDSA ne pourra pas les contenir.
• Bibliothèques d’éditeurs que vous ne maîtrisez pas — appliances, SDK et composants SaaS dont la cryptographie ne change que lorsque l’éditeur livre une mise à jour.
• Aucun propriétaire — certificats et clés créés par des projets qui n’existent plus.

Les deux premiers sont les plus faciles à repérer et à corriger. Comparez :

# Fragile : algorithme et taille de clé figés à l’appel
from Crypto.PublicKey import RSA
key = RSA.generate(2048)

# Agile : algorithme choisi par la politique, derrière une seule interface
from crypto_provider import get_signer
signer = get_signer(purpose="document-signing")  # lit la politique centrale
signature = signer.sign(payload)

La seconde version ne rend pas le code post-quantique. Elle transforme le changement en une mise à jour de politique et une implémentation de fournisseur, au lieu d’un rechercher-remplacer dans chaque dépôt — et elle conserve l’identifiant d’algorithme avec les données, de sorte que les anciennes et les nouvelles signatures peuvent coexister pendant la transition.

Un modèle de maturité pratique en cinq niveaux

Un modèle de maturité n’est utile que si chaque niveau est observable. Celui-ci est volontairement fondé sur des preuves : vous devez pouvoir montrer à un auditeur pourquoi vous êtes à tel ou tel niveau.

Beaucoup d’organisations se situeront au niveau 1 ou 2. C’est un point de départ normal, pas un échec — mais on ne peut pas planifier une migration de façon crédible depuis le niveau 1.

Des indicateurs réellement mesurables

Choisissez quelques indicateurs, mesurez-les dès maintenant et remesurez-les chaque trimestre. Quatre suffisent pour commencer :

1. Couverture de l’inventaire — pourcentage d’applications, de certificats et d’endpoints dont la cryptographie est connue. Sans cela, tous les autres chiffres sont des suppositions. Voir notre guide sur l’inventaire cryptographique (en anglais).
2. Taux de centralisation — pourcentage de points d’appel cryptographiques qui passent par un fournisseur ou une couche d’abstraction approuvés plutôt que d’appeler directement une primitive.
3. Délai de rotation — temps nécessaire pour remplacer un algorithme, une taille de clé ou un certificat sur un système représentatif, mesuré lors d’un exercice plutôt qu’estimé.
4. Contrôle bloquant la nouvelle cryptographie faible — existe-t-il, dans la chaîne CI/CD, un contrôle qui empêche de fusionner de la cryptographie nouvelle vulnérable au quantique ou dépréciée ? Sinon, votre inventaire se dégrade dès le jour où vous le terminez.

Un programme d’agilité sans contrôle bloquant n’est qu’un nettoyage ponctuel. La dette recommence à croître dès la prochaine pull request.

Deux mesures complémentaires méritent d’être suivies le cas échéant : la proportion d’actifs vulnérables au quantique qui protègent des données à longue durée de vie (votre exposition HNDL, en anglais), et le nombre de dépendances critiques dont seul l’éditeur peut modifier la cryptographie.

Par où commencer

1. L’inventaire d’abord. Analysez le code, les certificats et les endpoints TLS. Vous devez savoir où se trouvent RSA, ECC, SHA-1 et 3DES avant de pouvoir mesurer la centralisation.
2. Établissez une référence pour les quatre indicateurs sur deux ou trois systèmes représentatifs, pas sur l’ensemble du parc.
3. Introduisez une couche d’abstraction (fournisseur cryptographique) pour le nouveau code et pour les systèmes que vous migrerez en premier.
4. Ajoutez un contrôle dans la CI pour que toute nouvelle cryptographie faible soit détectée au moment de la pull request.
5. Intégrez les résultats à votre plan de migration — les systèmes peu agiles doivent démarrer plus tôt et disposer de davantage de budget. Notre feuille de route de migration PQC (en anglais) explique comment séquencer les vagues.

Pour vous situer rapidement, l’auto-évaluation gratuite de maturité PQC en 2 minutes est un premier pas raisonnable. Pour voir comment CRYPTAGION accompagne chaque étape, lisez la crypto-agilité avec CRYPTAGION.

À retenir

La crypto-agilité n’est ni une fonctionnalité produit ni un slogan ; c’est une propriété mesurable de votre système d’information. Les organisations capables de démontrer une couverture d’inventaire, un taux de centralisation, un délai de rotation testé et un contrôle CI opérationnel trouveront la migration post-quantique — et la suivante — bien moins coûteuse que celles qui repartent de zéro à chaque fois.

Sources

• NIST, CSWP 39, Considerations for Achieving Cryptographic Agility: Strategies and Practices (version finale, 19 décembre 2025).
• NIST, IR 8547 (projet initial soumis à consultation), Transition to Post-Quantum Cryptography Standards (novembre 2024).
• NIST NCCoE, SP 1800-38, Migration to Post-Quantum Cryptography (projets préliminaires, 2023 ; pas encore finalisé).
• NIST, SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (2019).
• NIST, NIST retires SHA-1 cryptographic algorithm (décembre 2022).
• W. Castryck et T. Decru, An efficient key recovery attack on SIDH, IACR ePrint 2022/975.
• ANSSI, BSI et al., Securing Tomorrow, Today: Transitioning to Post-Quantum Cryptography (déclaration commune, novembre 2024).
• ANSSI, PQC transition in France.

← Toutes les ressources · Accueil