Crypto-agilité : l'agilité qu'on n'a pas exercée n'existe pas

Lors d'un exercice, changer d'algorithme de signature a pris un dixième de seconde, et retirer l'ancienne clé a fait échouer 501 preuves. Ce que DORA demande déjà, et comment s'exercer en une journée.

Le 5 octobre 2026, sur une plateforme de test que j'ai construite, un registre de preuves signées, comparable à une piste d'audit, a changé d'algorithme. Ses cinq cents premiers enregistrements étaient signés avec Ed25519, un algorithme classique qu'un ordinateur quantique suffisamment puissant pourrait casser. La suite devait l'être avec ML-DSA-65, l'une des signatures post-quantiques normalisées par le NIST en 2024. Dans l'unique essai chronométré, le premier enregistrement post-quantique a été signé et vérifié 96,9 millisecondes après le début de la génération de la nouvelle clé.

Il a ensuite fallu demander au vérificateur de ne plus faire confiance à l'ancienne clé, comme une migration finit par l'exiger. Aussitôt, 501 des 1 001 enregistrements, les cinq cents anciens et celui qui marquait la bascule, ont échoué ensemble à la vérification. Remettre l'ancienne clé publique les rétablissait, mais laissait aussi quiconque détiendrait un jour l'ancienne clé privée ajouter après la bascule un faux enregistrement, que le moteur acceptait comme valide. Une règle courte, quelques lignes de code dans le vérificateur, a levé le dilemme. Elle vit hors du registre. Elle sait où la bascule a eu lieu, exige une signature post-quantique pour tout ce qui suit et vérifie que le registre a la longueur prévue. Aucun composant ne la portait, et personne n'avait été chargé de l’écrire.

Trois autres exercices, le même angle mort

Sur des chaînes de certificats de test minimales, une chaîne signée en ML-DSA-65 portait le premier envoi du serveur à 14 880 octets. C'est au-delà du plafond de 14 600 octets que l'IETF propose pour la fenêtre initiale de TCP, ce qui coûte en principe un aller-retour réseau de plus. Trois clients anciens échouaient face aux serveurs purement post-quantiques, alors qu'un serveur portant aussi un certificat classique les gardait en service. Ce choix de certificat tombait entre l'infrastructure de clés et les points d'entrée, deux équipes distinctes en entreprise.

Sur une maquette locale, j'ai aussi déplacé le point où se termine la connexion chiffrée vers un équipement de bordure configuré selon un ancien modèle. En le traversant, les clients testés capables d'un échange hybride, classique et post-quantique, sont tous revenus au seul classique, dans cinq essais sur cinq, pendant que les contrôles de santé restaient au vert. Enfin, isoler un agent IA supposé compromis a interrompu ses délégations en 60,7 millisecondes en médiane. Sa clé continuait néanmoins de signer des reçus que la vérification acceptait, et un redémarrage le remettait en service.

Alors que chaque signature, vérification ou connexion prenait quelques millisecondes, les défaillances qui comptaient se logeaient à la frontière entre des composants qui faisaient chacun correctement leur travail. En entreprise, cette frontière sépare souvent deux équipes dont aucune n'en a la charge. Obtenus avec une cryptographie réelle et une flotte d'agents simulée, ces chiffres ne valent que pour cette plateforme, même si la méthode et le type de défaillance devraient se retrouver ailleurs. Ils ne mesurent pas non plus le temps d'écrire les règles manquantes.

Ce que DORA demande déjà

En janvier 2026, le groupe d'experts en cybersécurité du G7 a publié pour la finance une feuille de route non contraignante, qui propose de traiter les systèmes critiques vers 2030-2032. Elle compte parmi ses phases des tests de migration et des exercices de résilience quantique.

Dans la finance, le règlement européen sur la résilience opérationnelle numérique, DORA, fournit ce cadre depuis janvier 2025. Son article 24 demande un programme de tests de résilience opérationnelle numérique, et l'article 25 y cite les tests fondés sur des scénarios et de compatibilité. L'article 11 fait tester les plans de continuité chaque année, et après toute modification substantielle des systèmes qui soutiennent des fonctions critiques ou importantes. Changer l'algorithme d'un registre de preuves qui soutient une telle fonction en est une, à mon sens. Hors régime simplifié, les normes techniques demandent aussi une politique de chiffrement qui prévoie de faire évoluer la technologie cryptographique avec la cryptanalyse. Une entité qui n'a jamais changé d'algorithme aura du mal à montrer cette capacité, et le compte rendu d'un exercice en est probablement la preuve la plus directe.

Aucun de ces textes ne prescrit d'exercice post-quantique. Un exercice sur une copie ne remplace pas non plus les tests d'intrusion fondés sur la menace que DORA impose au moins tous les trois ans aux entités désignées, sur la production. Un test, même sans sanction, peut aussi déplacer les priorités. Selon un document de travail de la Banque des règlements internationaux de mai 2026, rappelé le 1er octobre à la conférence annuelle du Comité européen du risque systémique, le test de résilience cyber mené par la BCE en 2024 en donne la mesure. Sans conséquence directe en capital, il a conduit les banques qui sous-investissaient au regard de leur risque à relever leur investissement en cybersécurité d'environ 80 % par rapport à leurs pairs.

Une journée sur une copie

Les quatre exercices ont tenu en une matinée. Pour une entreprise qui dispose déjà d'une copie de son parc, une journée paraît un objectif raisonnable, la construction de la copie et la remédiation se comptant à part. On y prend la surface au plus petit rayon d'impact et à la signature la plus ancienne, sur une copie dotée de ses propres clés de test et sans route vers la production. Avant tout lancement, on écrit le temps prévu et le résultat qui vaudra réussite, car l'écart avec le résultat peut être l'un des constats les plus utiles.

Le matin, les scénarios vont de la clé classique supposée cassée le jour même à l'agent supposé compromis. L'après-midi, chaque point resté sans propriétaire reçoit un nom, une date et une règle écrite, ou une acceptation explicite du risque. La décision se prend devant le RSSI, les responsables des clés, du réseau et des agents, et la conformité. Le format ressemble aux exercices de crise que beaucoup d'établissements tiennent déjà, sauf que la copie du parc y change vraiment de cryptographie.

Une question au prochain comité des risques suffit à mesurer l'écart. Quand l'entreprise a-t-elle changé un algorithme cryptographique pour la dernière fois, sur quel système, et qui a tranché ce que ce changement a cassé ?

Sources

• Exercices du 5 octobre 2026, mesures publiées : DOI 10.5281/zenodo.23322699
• NIST FIPS 204 (2024) et IETF RFC 6928
• Feuille de route du G7 Cyber Expert Group pour la finance, janvier 2026 : home.treasury.gov
• DORA, articles 11, 24, 25 et 26 · règlement délégué 2024/1774, article 6
• BRI, document de travail n° 1351, mai 2026 : bis.org · conférence annuelle du CERS, 1er octobre 2026