Crypto-agilité : la vraie question n’est plus « quel algorithme ? », mais « comment en changer ? »
Publié le 01/10/2026
Auteur : Arnaud DUFOURNET, Directeur Marketing & Expérience Client
La cryptographie post-quantique entre progressivement dans sa phase opérationnelle. ML-KEM, ML-DSA et SLH-DSA ont été standardisés par le NIST, tandis que HQC a été sélectionné en 2025 comme mécanisme de secours pour l’établissement de clés et que la standardisation de FALCON/FN-DSA se poursuit.
Mais le concours n’est pas clos pour autant. La liste des algorithmes retenus aujourd’hui devra probablement évoluer au cours des prochaines années, au gré des avancées de la cryptanalyse accélérée par l’IA, de la normalisation et des recommandations nationales.
Dans le contexte de la transition vers la cryptographie résistante au quantique, la crypto-agilité se révèle d’autant plus nécessaire. La question n’est donc plus seulement de savoir quel algorithme choisir, mais surtout comment pouvoir en changer sans reconstruire tout son système d’information.
Pourquoi la crypto-agilité n’est plus une option
Choisir aujourd’hui un algorithme ne suffit plus. Une vulnérabilité découverte demain dans une primitive largement déployée pourrait imposer une évolution massive et simultanée des infrastructures qui l’utilisent. C’est l’une des particularités de la transition post-quantique. Les algorithmes sélectionnés par le NIST ont certes été éprouvés par une communauté internationale d’experts en cryptographie pendant plusieurs années, mais leur implémentation reste encore jeune. Nous manquons encore de recul pour valider totalement leur robustesse. Les organisations doivent donc se préparer à changer de mécanisme cryptographique, et pas seulement à en sélectionner un nouveau.
HAWK : quand un algorithme post-quantique doit être abandonné
Fin juillet 2026, des chercheurs d’Anthropic ont utilisé le modèle d’IA Claude Mythos Preview pour découvrir une faiblesse mathématique dans HAWK, un algorithme de signature post-quantique pourtant parvenu au troisième tour du processus complémentaire de standardisation des signatures du NIST. Cette attaque cryptanalytique, exécutable sur des ordinateurs classiques, exploite une symétrie du réseau euclidien sous-jacent et réduit sensiblement la sécurité effective du schéma sans le briser complètement : elle n’a été démontrée en pratique que sur un paramètre de test de petite taille. À la suite de cette découverte, l’équipe HAWK a retiré l’algorithme du processus de standardisation dédié à la signature numérique. HAWK avait été conçu comme une alternative performante à FALCON (FN-DSA, en cours de standardisation). Les standards déjà finalisés (ML-KEM, ML-DSA, SLH-DSA) ne sont pas concernés, mais l’épisode montre qu’un candidat peut être fragilisé en quelques jours, après plusieurs années d’analyse par la communauté.
Selon l’ANSSI, la crypto-agilité est la capacité d’un système à modifier ou remplacer tout composant cryptographique (bibliothèques, accélérateurs matériels, clés, algorithmes) au cours de sa durée de vie, sans altérer ses fonctionnalités métier et en minimisant l’interruption de service. L’Agence recommande de la prendre en compte dès la conception des futurs produits de sécurité ; le NIST lui consacre désormais un document spécifique publié en décembre 2025 et mis à jour en juin 2026, qui analyse les approches permettant de remplacer et d’adapter les algorithmes cryptographiques tout en préservant la sécurité et la continuité des opérations.
Le point de départ : savoir ce que vous avez réellement déployé
Avant de pouvoir changer de cryptographie, encore faut-il savoir où elle est utilisée.
Or, dans de nombreuses organisations, la cryptographie est présente dans une multitude de composants sans faire l’objet d’un inventaire centralisé : VPN, certificats TLS, PKI, cartes à puce, applications métiers, équipements réseau, systèmes industriels, objets connectés, stockage, sauvegardes… Une étude mondiale menée en 2026 par le Ponemon Institute (pour Entrust) auprès de responsables IT, sécurité et risques montre ainsi que seuls 43 % des organisations disposent d’une visibilité complète sur leur patrimoine cryptographique.
Quels algorithmes sont utilisés ? Avec quelles tailles de clés ? Pour quels usages ? Sur quels équipements ? Quels certificats arrivent à expiration ? Quelles applications dépendent d’une PKI donnée ? Cette cartographie constitue le point de départ d’une démarche de crypto-agilité. Elle peut être structurée sous la forme d’un CBOM (Cryptography Bill of Materials), sur le modèle du SBOM désormais familier aux RSSI. Là où le SBOM décrit les composants logiciels d’un système, le CBOM vise à donner une visibilité sur son patrimoine cryptographique : algorithmes, tailles de clés, protocoles, certificats, bibliothèques et dépendances entre systèmes.
L’objectif n’est pas simplement de produire un document supplémentaire, mais de disposer d’une vue exploitable et régulièrement actualisée du patrimoine cryptographique.
De l’inventaire à la politique : la CryptoPolicy
Une fois l’inventaire établi, l’étape suivante consiste à transformer cette connaissance en règles. Une CryptoPolicy peut par exemple définir les algorithmes autorisés ou interdits, les tailles minimales de clés, les mécanismes à privilégier pour certains usages, ainsi que les échéances auxquelles certains composants devront évoluer.
L’enjeu est surtout de faire de cette politique une règle opérationnelle et homogène. Une politique cryptographique qui reste dans un document de gouvernance ne garantit pas que les mêmes exigences sont effectivement appliquées sur l’ensemble du SI.
Trois niveaux d’action peuvent être distingués :
- Configuration : faire évoluer les paramètres cryptographiques d’une solution existante, sans modifier son code. Par exemple, ML-KEM propose trois jeux de paramètres standardisés, ML-KEM-512, ML-KEM-768 et ML-KEM-1024, permettant d’adapter le niveau de sécurité aux besoins de l’usage.
- Implémentation logicielle : intégrer un nouvel algorithme ou mécanisme cryptographique dans une application ou une solution qui ne le supporte pas encore. Par exemple, ajouter le support de FrodoKEM à un client VPN qui utilise jusqu’alors uniquement ML-KEM.
- Mise à jour et distribution : diffuser ces changements à grande échelle sans intervention manuelle sur chaque système. Par exemple, appliquer une nouvelle politique cryptographique ou une nouvelle version du client VPN à plusieurs milliers de postes depuis une console d’administration centralisée.
C’est ce dernier niveau qui transforme véritablement la crypto-agilité en capacité opérationnelle.
Outiller la crypto-agilité au quotidien
Pour un RSSI, l’enjeu est donc très concret : combien de temps faudrait-il pour faire évoluer une politique cryptographique sur plusieurs milliers de postes ?
Si chaque poste doit être traité manuellement, la crypto-agilité reste théorique. À l’inverse, une architecture centralisée permet de diffuser une nouvelle politique, de modifier les paramètres cryptographiques ou de déclencher une mise à jour sans intervenir individuellement sur chaque équipement.
C’est notamment l’approche que TheGreenBow souhaite proposer avec Bowrealis Console : en centralisant l’administration des clients VPN, elle peut constituer un point de contrôle permettant de gérer et de faire évoluer les configurations cryptographiques à l’échelle du parc.
Le NIST et les agences de sécurité poussent vers la diversité des algorithmes résistants au quantique. D’ici 2030, date à laquelle les systèmes d’information sensibles doivent être sécurisés contre la menace quantique, la famille des algorithmes se sera enrichie. Il faut donc se préparer à jongler avec eux et être en capacité de procéder à des remplacements sans rupture opérationnelle.
La transition post-quantique ne doit donc pas être envisagée comme un projet ponctuel consistant à remplacer la cryptographie actuelle par un nouvel algorithme. La durée de ce projet est estimée entre 5 et 10 ans et constitue une transformation très profonde : rendre le système d’information capable d’évoluer avec la cryptographie.
La crypto-agilité permet précisément de transformer cette contrainte en capacité durable. Une organisation capable d’inventorier son patrimoine cryptographique, de définir une politique et de la déployer à grande échelle pourra faire évoluer ses mécanismes de sécurité plus rapidement, sans devoir réengager à chaque fois un nouveau chantier de migration. Mieux armée, elle demeure résiliente face aux évolutions de la menace, des standards et des recommandations.