PQC StatusLa crypto-agilité est la capacité d'un système à changer ses algorithmes, paramètres et clés cryptographiques sans réécrire le code applicatif et sans attendre une nouvelle version du produit. Ce n'est pas une fonctionnalité que l'on achète : c'est un ensemble de propriétés d'ingénierie, principalement une configuration plutôt que des choix codés en dur, une négociation au niveau du protocole, un inventaire à jour, des frontières d'abstraction nettes et des cycles de vie des clés et certificats automatisés. Les régulateurs décrivent désormais la même capacité avec leurs propres mots : par exemple, les normes techniques de DORA exigent une politique de chiffrement comportant des dispositions pour changer de technologie cryptographique à mesure que la cryptanalyse progresse.
Ce que signifie la crypto-agilité
Une définition opérationnelle utile : un système est cryptographiquement agile lorsqu'un opérateur compétent peut remplacer un algorithme, une taille de clé ou une version de protocole dans une fenêtre de changement maîtrisée, à l'aide d'une configuration et d'une automatisation déjà existantes, et peut prouver ensuite ce qui est effectivement utilisé. Le test est opérationnel, pas théorique. Si changer un groupe d'échange de clés implique de modifier le code source, de reconstruire une image de conteneur, de renégocier avec un fournisseur ou de découvrir des dépendances non documentées, le système n'est pas agile, quoi qu'en dise sa documentation.
Trois distinctions méritent d'être retenues :
- L'agilité n'est pas la même chose que la préparation post-quantique. La cryptographie post-quantique (PQC) est une destination. L'agilité est le véhicule. Un serveur qui propose aujourd'hui un échange de clés hybride post-quantique mais ne peut pas le modifier l'an prochain a réussi une migration et n'en a préparé aucune.
- L'agilité ne se limite pas à la négociation. Transport Layer Security (TLS) négocie. Les formats de données stockées, les micrologiciels signés, les modules matériels de sécurité (HSM), les terminaux de paiement et les équipements embarqués, souvent, ne négocient pas. C'est là que l'agilité doit être conçue plutôt que configurée.
- L'agilité suit un ordre de priorité. « Récolter maintenant, déchiffrer plus tard » (harvest now, decrypt later, HNDL) désigne un trafic enregistré qu'un adversaire conserve jusqu'à ce que son déchiffrement devienne possible. Les sessions enregistrées ne sont protégées que par l'échange de clés : c'est pourquoi l'établissement de clés migre en premier et les signatures peuvent suivre. Notre article sur harvest now, decrypt later détaille cet ordre.
La configuration plutôt que le code, la négociation plutôt que le codage en dur
La première propriété est que le choix des algorithmes réside dans une configuration dont un opérateur est responsable, en un seul endroit par hôte ou par service, et qu'elle est revue comme n'importe quel autre contrôle. Une politique cryptographique centralisée vaut mieux que des options propres à chaque application, car ce sont précisément ces options que l'on oublie.
TLS : groupes nommés et liste de préférences ordonnée
En TLS 1.3, l'échange de clés est un groupe nommé, négocié à chaque connexion. Le registre de l'Internet Assigned Numbers Authority (IANA) recense les groupes hybrides X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) et SecP384r1MLKEM1024 (0x11ED), aux côtés des groupes ML-KEM purs (paramètres TLS de l'IANA). ML-KEM est le mécanisme d'encapsulation de clés (KEM) normalisé par le NIST dans FIPS 203 le 13 août 2024. La RFC 10024 (août 2026) spécifie l'accord de clés hybride post-quantique et traditionnel pour TLS 1.3.
Une configuration agile énonce une préférence ordonnée et conserve un repli classique, afin qu'un client qui ne prend pas en charge le groupe hybride puisse toujours se connecter. OpenSSL 3.5 ou ultérieur est requis pour les groupes ML-KEM :
# /etc/ssl/openssl.cnf (OpenSSL 3.5 or later)
openssl_conf = default_conf
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
Groups = X25519MLKEM768:X25519:P-256
MinProtocol = TLSv1.2
Vérifiez depuis l'extérieur avant et après chaque changement, à l'aide d'un test en lecture seule :
# read-only test: does the server accept the hybrid group?
openssl s_client -groups X25519MLKEM768 -connect example.com:443 < /dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'
Au niveau du serveur web, la même préférence tient en une directive, par exemple ssl_ecdh_curve X25519MLKEM768:X25519; dans nginx compilé avec une version d'OpenSSL adaptée. Notre guide pour activer ML-KEM sur nginx, Apache, HAProxy et Caddy donne la syntaxe propre à chaque produit et les versions minimales. Testez d'abord en préproduction, et conservez le groupe de repli.
SSH : le même schéma, déjà déployé
OpenSSH est un bon modèle d'agilité en pratique. La version 9.0 (8 avril 2022) a fait d'un échange de clés hybride le choix par défaut. La version 9.9 (19 septembre 2024) a ajouté mlkem768x25519-sha256. La version 10.0 (9 avril 2025) en a fait l'accord de clés par défaut, et la 10.1 (6 octobre 2025) avertit lorsqu'une connexion négocie un accord de clés non post-quantique, via WarnWeakCrypto, activé par défaut (notes de version d'OpenSSH). Les opérateurs qui avaient exprimé des préférences dans la configuration ont hérité du changement ; ceux qui avaient figé un algorithme dans des scripts, non.
# list what this client supports, then set an ordered preference
ssh -Q kex
# /etc/ssh/sshd_config (OpenSSH 9.9 or later), classical fallback last
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256
Inventaire, abstraction et automatisation
Un inventaire que l'on peut interroger, pas un tableur que l'on réécrit
On ne peut pas changer ce que l'on ne sait pas lister. Un inventaire justifie sa place lorsqu'il répond à une question en quelques minutes : quels services négocient encore un échange de clés uniquement classique, quels certificats utilisent quel algorithme de signature, quelles bibliothèques fournissent les primitives, et qui est responsable de chacun. Consignez au minimum l'actif, le protocole et sa version, les algorithmes et tailles de clés, la finalité, le responsable, la version de la bibliothèque ou du module, et le mécanisme de renouvellement. Une nomenclature cryptographique (CBOM) est une manière lisible par machine de conserver ces informations ; voir ce qu'est un CBOM. Considérez le CBOM comme une pratique que nous suggérons plutôt que comme une exigence légale.
Des couches d'abstraction qui masquent l'algorithme
Le code applicatif doit demander une capacité, pas un nom. Quatre schémas apportent l'essentiel du bénéfice :
- Passer par un fournisseur (provider) ou une fine bibliothèque interne. Un seul module traduit la politique en primitives, de sorte qu'un seul changement se propage.
- Versionner chaque format stocké. Préfixez les chiffrés, jetons et enveloppes signées par un identifiant d'algorithme et une version de format, afin que les anciennes données restent lisibles pendant que les nouvelles utilisent le nouvel algorithme.
- Ne jamais présumer des tailles. Les clés publiques et chiffrés ML-KEM, ainsi que les signatures ML-DSA, sont nettement plus volumineux que leurs équivalents à courbes elliptiques. Les colonnes de base de données à longueur fixe, les tampons fixes, les plafonds de taille de message et les champs de protocole dimensionnés pour des clés de 32 octets sont le blocage dur le plus fréquent. Privilégiez les champs préfixés par leur longueur.
- Conserver un double chemin de vérification. Acceptez et vérifiez à la fois l'ancien et le nouvel algorithme pendant la transition, puis retirez l'ancien selon un calendrier daté.
Des clés et certificats qui tournent sans intervention humaine
Une rotation effectuée une fois par an à la main n'est pas un contrôle, c'est une répétition que vous raterez. L'émission et le renouvellement automatisés, des durées de vie de certificats courtes et une alerte sur tout certificat non renouvelé sont ce qui rend un changement d'algorithme routinier : lorsque l'algorithme de signature change, la chaîne émet simplement des certificats différents. Les exercices de rotation ont leur place dans le calendrier des changements. Les signatures à base de hachage avec état (LMS et XMSS, normalisées dans NIST SP 800-208) sont l'exception qui confirme la règle : leur gestion d'état rend dangereuse la duplication naïve d'une clé de signature, elles exigent donc une gestion des clés délibérée plutôt qu'une automatisation générique.
Où la réglementation demande de l'agilité, et quelles preuves conviennent
Plusieurs textes exigent cette capacité sans employer l'expression. Le tableau distingue ce que chaque texte dit littéralement de la manière dont nous suggérons d'en apporter la preuve. Il s'agit d'une information, pas d'un conseil juridique : confirmez vos propres obligations auprès de votre conseil ou de votre autorité de supervision.
| Source | Ce que le texte exige | Preuves adaptées (notre interprétation) |
|---|---|---|
| DORA, règlement délégué (UE) 2024/1774 de la Commission, Art. 6 | Une politique de chiffrement et de contrôles cryptographiques comprenant des dispositions pour mettre à jour ou changer la technologie cryptographique en fonction des évolutions de la cryptanalyse | Une clause de politique désignant le déclencheur, le responsable de la décision et la procédure de changement, ainsi que la dernière revue datée |
| DORA RTS Art. 7 | La gestion des clés sur l'ensemble de leur cycle de vie, et un registre des certificats pour les actifs TIC soutenant des fonctions critiques ou importantes | Un registre des certificats indiquant émetteur, algorithme, expiration et responsable, ainsi que les journaux de l'automatisation des renouvellements |
| PCI DSS v4.0.1 exigence 12.3.3 (obligatoire depuis le 31 mars 2025) | Les suites de chiffrement et protocoles utilisés, documentés et revus au moins tous les 12 mois, avec un suivi de leur viabilité continue et une stratégie documentée pour les changements cryptographiques anticipés | Un inventaire des suites de chiffrement par service, la revue annuelle datée et le plan de migration auquel elle renvoie |
| NIS2, directive (UE) 2022/2555, Art. 21(2)(h) | Des politiques et procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement | La même politique, mise en correspondance avec la transposition nationale |
| Fédéral américain : OMB M-26-15 (24 juin 2026) | Un inventaire cryptographique automatisé et mis à jour en continu pour les agences | Des résultats d'outillage produits selon un calendrier, et non un fichier tenu à la main |
Lisez la formulation exacte dans le règlement (UE) 2024/1774, et consultez nos pages sur DORA et PCI DSS v4.0.1 pour les échéances datées. Gardez les nuances à leur juste niveau : la feuille de route de mise en œuvre coordonnée de l'UE (Coordinated Implementation Roadmap) v1.1 est une orientation coordonnée destinée aux États membres et non un règlement contraignant pour les entreprises, la BSI TR-02102-1 est une ligne directrice technique, l'ANSSI indique que ses recommandations post-quantiques ne constituent pas encore des obligations réglementaires en dehors de son périmètre réglementé, et le NIST IR 8547 reste un projet initial soumis à consultation publique.
Les écueils qui neutralisent discrètement l'agilité
- Figer un algorithme dans le code ou les scripts au lieu d'exprimer une préférence ordonnée dans la configuration.
- Supprimer trop tôt le repli classique. Conservez X25519 après X25519MLKEM768 tant que votre parc de clients n'a pas été mesuré.
- Conserver des groupes pré-normalisation obsolètes. Les groupes TLS issus des brouillons Kyber sont obsolètes : passez à X25519MLKEM768 et aux autres hybrides enregistrés.
- Un inventaire sans responsables. Une liste dont personne n'est comptable ne produit aucun changement.
- Oublier les artefacts à longue durée de vie : micrologiciels signés, signatures de documents, sauvegardes et données archivées survivent aux systèmes qui les ont créés.
Mesurez ce que vos systèmes négocient aujourd'hui
L'agilité commence par un état des lieux honnête, et sa partie visible de l'extérieur s'obtient rapidement : analysez votre domaine avec PQC Status pour voir quelles versions de TLS, suites de chiffrement, groupes d'échange de clés et algorithmes de certificat votre serveur négocie réellement. Une analyse décrit uniquement la configuration TLS visible de l'extérieur : ce n'est ni une certification ni une attestation de conformité, comme l'explique notre page de méthodologie. L'étape concrète suivante consiste à reprendre ce résultat, à consigner chaque service dans votre inventaire cryptographique avec un responsable, puis à déplacer le choix des algorithmes d'un service vers une configuration centrale et à répéter son changement en préproduction.