Crypto-agilité : définition, enjeux et feuille de route pour 2026-2029

La plupart des organisations suisses maîtrisent partiellement le premier niveau et découvrent les deux autres à l'occasion d'un audit. Le niveau architectural est le plus coûteux parce qu'il touche des équipements amortis sur dix à quinze ans : systèmes de gestion technique du bâtiment, automates industriels, terminaux de paiement, équipements réseau.

Pourquoi la crypto-agilité est-elle importante pour votre organisation

La crypto-agilité est importante parce que la durée de vie opérationnelle des algorithmes raccourcit : SHA-1 et RSA-1024 ont été retirés, RSA et les courbes elliptiques seront obsolètes face aux menaces quantiques, et les certificats publics ne vaudront plus que 47 jours en 2029. Sans cette capacité, chaque transition devient un projet d'urgence ; avec elle, le remplacement d'un algorithme relève de la maintenance planifiée.

Le premier moteur est la menace quantique, résumée par la formule « récolter maintenant, déchiffrer plus tard ». Un flux TLS intercepté en 2026 et stocké peut être déchiffré rétroactivement lorsqu'un ordinateur quantique suffisamment puissant sera disponible. Toute donnée dont la confidentialité doit tenir au-delà d'une décennie, dossiers patients, brevets industriels, informations couvertes par le secret bancaire ou la LPD, est donc exposée aujourd'hui, sans qu'il soit nécessaire que la machine capable de casser RSA existe encore.

Le deuxième moteur est réglementaire. La FINMA attend des établissements assujettis une gestion des risques opérationnels couvrant les technologies de l'information et les cyberrisques ; la LPD impose des mesures techniques proportionnées au risque ; la LSI encadre la sécurité de l'information de la Confédération et de ses fournisseurs. En Suisse, c'est l'Office fédéral de la cybersécurité (OFCS/NCSC) qui publie les recommandations techniques de référence pour la transition post-quantique, et non une autorité étrangère. Aucun de ces textes ne nomme d'algorithme, mais tous rendent indéfendable le maintien d'un chiffrement dont l'obsolescence est publiquement documentée.

Le troisième moteur relève de la stratégie commerciale. Les grands donneurs d'ordre, en Suisse comme dans l'Union européenne, inscrivent la préparation post-quantique dans leurs questionnaires fournisseurs et leurs contrats d'externalisation. Un prestataire incapable de documenter son inventaire cryptographique perd des appels d'offres avant même la discussion technique.

Les 5 étapes pour établir une stratégie de crypto-agilité

Une stratégie de crypto-agilité se construit en cinq étapes : établir une visibilité cryptographique complète, hiérarchiser les actifs selon la durée de vie des données, introduire une couche d'abstraction (PKI, KMS, bibliothèques centralisées), automatiser la gestion du cycle de vie des clés et des certificats, puis instituer une gouvernance avec des exercices réguliers de bascule.

1. Inventaire et visibilité cryptographique. Un outil de découverte scanne le réseau, les dépôts de code et les configurations pour produire une nomenclature cryptographique (CBOM) : algorithmes, tailles de clés, emplacements, propriétaires. Les trouvailles les plus fréquentes sont des certificats auto-signés oubliés sur des équipements de gestion technique de bâtiment et des bibliothèques TLS non maintenues.
2. Analyse de risques et priorisation. Chaque actif est noté selon la sensibilité des données, leur durée de confidentialité requise et la facilité de remplacement. Les flux d'échange de clés protégeant des données à longue durée de vie passent en tête.
3. Abstraction. Les appels cryptographiques sont centralisés dans une PKI interne, un KMS et des bibliothèques validées, de sorte qu'un changement d'algorithme se fasse par configuration et non par modification du code applicatif.
4. Automatisation du cycle de vie. Émission, renouvellement, révocation et rotation des clés passent par des protocoles standards (ACME, EST, SCEP) et des pipelines supervisés.
5. Gouvernance et exercices. Une politique cryptographique fixe les algorithmes autorisés et dépréciés ; un exercice annuel simule le retrait d'un algorithme, à la manière d'un mécanisme de réponse aux incidents.

Le piège classique consiste à acheter un outil de découverte sans désigner de propriétaire par actif : l'inventaire vieillit en six mois et la capacité opérationnelle de bascule n'existe toujours pas. La priorisation doit être validée par les métiers, car ce sont eux qui connaissent la durée de vie réelle de leurs données.

Comment migrer vers la cryptographie post-quantique : guide pratique

La migration post-quantique consiste à remplacer RSA et les courbes elliptiques par les standards publiés par le NIST en 2024 : ML-KEM (FIPS 203) pour l'établissement de clés, ML-DSA (FIPS 204) et SLH-DSA (FIPS 205) pour les signatures. L'ANSSI recommande une approche hybride qui combine un algorithme classique et un algorithme post-quantique pendant la durée de la transition.

La première décision porte sur l'ordre des chantiers. L'échange de clés passe avant les signatures, parce qu'un trafic TLS enregistré en 2026 et déchiffré en 2036 constitue un dommage réel, alors qu'une signature cassée a posteriori n'invalide pas une authentification déjà effectuée. Les VPN site à site, les sauvegardes chiffrées et les archives longues sont donc traités en premier.

La deuxième décision concerne l'hybridation. Combiner ECDH et ML-KEM dans un même échange, comme le fait déjà X25519MLKEM768 dans Chrome, protège contre une faiblesse encore inconnue des nouveaux algorithmes, au prix d'un surcoût de calcul modéré. En revanche, les tailles de messages augmentent nettement : une signature ML-DSA est significativement plus volumineuse qu'une signature ECDSA de longueur comparable, ce qui allonge les poignées de main TLS et peut saturer des liaisons contraintes ou des automates industriels.

La troisième décision porte sur les composants matériels. Beaucoup de HSM, de passerelles et de cartes à puce installés ne recevront jamais de micrologiciel post-quantique. Leur remplacement doit être planifié dans le budget d'infrastructure et dans les contrats de maintenance, faute de quoi la migration logicielle s'arrête devant un boîtier amorti sur quinze ans.

Agilité cryptographique et gestion des certificats TLS/SSL

Le CA/Browser Forum réduit la validité maximale des certificats TLS publics de 398 jours à 200 jours depuis le 15 mars 2026 (ballot SC-081), puis à 100 jours au 15 mars 2027 et à 47 jours au 15 mars 2029. À cette cadence, le renouvellement manuel devient ingérable : l'automatisation par le protocole ACME constitue le socle de l'agilité des certificats.

La logique de cette réduction est double. D'une part, un certificat ou une clé privée compromis n'offre plus qu'une fenêtre d'exploitation de quelques semaines. D'autre part, un parc renouvelé toutes les sept semaines peut adopter un nouvel algorithme de signature ou une nouvelle longueur de clé en moins de deux mois, là où un parc annuel conservait ses certificats anciens pendant plus d'un an.

La contrainte porte aussi sur la validation de domaine (DCV), dont la réutilisation sera limitée à dix jours en 2029. Pour une organisation qui exploite plusieurs centaines de certificats numériques sur des répartiteurs de charge, des portails clients et des équipements de réseau, le renouvellement automatisé constitue la seule méthode viable à cette fréquence.

Comment organiser le renouvellement automatisé

Un déploiement ACME se construit en quatre couches : un client ACME par plateforme (certbot, acme.sh, win-acme ou l'agent intégré du répartiteur de charge), une méthode de validation adaptée (DNS-01 pour les certificats génériques et les serveurs internes, HTTP-01 pour les sites exposés), une autorité émettrice publique ou privée qui parle ACME, et une supervision qui alerte dix jours avant expiration. Les certificats internes suivent la même discipline via une PKI d'entreprise, afin que les équipes n'entretiennent pas deux processus distincts.

Feuille de route 2026-2029 : préparation post-quantique en Suisse

En Suisse, aucune loi ne fixe encore de date butoir pour la migration post-quantique, mais la FINMA, la LPD et la LSI exigent des mesures de sécurité proportionnées au risque. L'OFCS publie les recommandations techniques de référence à l'attention des organisations suisses. La feuille de route coordonnée de l'Union européenne vise 2030 pour les cas à haut risque et 2035 pour le reste. Une organisation suisse doit avoir achevé son inventaire en 2026 et sécurisé ses flux critiques avant 2030.

• 2026 : inventaire cryptographique complet, désignation des propriétaires, premiers certificats à 200 jours, politique cryptographique approuvée par la direction
• 2027 : passage à 100 jours, automatisation ACME généralisée, pilotes hybrides ML-KEM sur les VPN et les sauvegardes, clauses post-quantiques dans les nouveaux contrats fournisseurs
• 2028 : extension des échanges de clés hybrides à l'ensemble des flux externes, plan de remplacement des HSM et équipements non compatibles, premiers tests de signatures ML-DSA
• 2029 : certificats à 47 jours, réutilisation DCV limitée à dix jours, bascule des signatures de code et de micrologiciel, exercice de retrait d'algorithme
• 2030 et au-delà : flux à haut risque entièrement post-quantiques, décommissionnement progressif des algorithmes classiques dans les systèmes restants

Le calendrier européen pèse directement sur les entreprises suisses exportatrices et sur les prestataires de services aux institutions financières, qui doivent s'aligner sur leurs clients et partenaires. Le mouvement est international : plusieurs autorités nationales, dont l'OFCS pour la Suisse, ont publié des appels à l'action sur la transition post-quantique, et les administrations fédérales de premier plan ont inscrit la question parmi leurs priorités de sécurité numérique.

Checklist : 10 actions immédiates pour débuter votre transformation crypto-agile

Dix actions permettent d'engager la crypto-agilité sans programme de transformation lourd : elles portent sur l'inventaire, la responsabilité, l'automatisation des certificats et les clauses contractuelles, et se mènent avec les équipes et budgets existants en un à deux trimestres.

1. Lister les certificats publics et leur date d'expiration à partir des journaux de transparence des certificats
2. Scanner les ports TLS internes pour identifier les versions de protocole et les suites de chiffrement actives
3. Désigner un propriétaire nommé pour chaque application utilisant de la cryptographie
4. Classer les données selon leur durée de confidentialité requise (moins de 5 ans, de 5 à 10 ans, plus de 10 ans)
5. Déployer un client ACME sur un premier périmètre non critique et mesurer le taux de renouvellement réussi
6. Interroger les éditeurs et constructeurs sur leur calendrier de support des algorithmes post-quantiques
7. Ajouter une clause de crypto-agilité dans les nouveaux contrats d'externalisation et de maintenance
8. Activer un échange de clés hybride (X25519MLKEM768 ou équivalent) sur un tunnel VPN de test entre deux sites
9. Rédiger une politique cryptographique d'une page listant les algorithmes autorisés, tolérés et interdits
10. Planifier un exercice de retrait d'algorithme sur table avec les équipes infrastructure, applicatives et conformité

FAQ : réponses aux questions fréquentes sur la crypto-agilité

Quelle est la différence entre cryptographie post-quantique et cryptographie quantique ?

La cryptographie quantique désigne les mécanismes qui reposent sur les propriétés physiques de la mécanique quantique, comme la distribution quantique de clés (QKD). Les algorithmes post-quantiques, eux, sont des procédés mathématiques classiques (standardisés par le NIST sous les références FIPS 203 à 205) conçus pour résister à un ordinateur quantique tout en s'exécutant sur les infrastructures actuelles. C'est cette seconde famille qui est déployable à court terme et qui constitue le cœur de la migration post-quantique.

Quel est le meilleur algorithme de chiffrement post-quantique ?

Il n'existe pas d'algorithme unique adapté à tous les usages. ML-KEM (FIPS 203) est la référence pour l'établissement de clés post-quantiques : c'est déjà celui qu'utilisent Chrome et Cloudflare en mode hybride. ML-DSA (FIPS 204) s'impose pour les signatures courantes, SLH-DSA (FIPS 205) pour les signatures à très haute assurance malgré une taille importante, et HQC a été retenu par le NIST comme algorithme de secours à ML-KEM. Pour les données au repos, AES-256 reste adapté. Le choix dépend des contraintes de taille, de performance et de certification des composants.

Pourquoi prioriser la migration de l'échange de clés avant celle des signatures ?

Un trafic TLS chiffré avec RSA ou ECDH aujourd'hui peut être enregistré et déchiffré rétroactivement dès qu'un ordinateur quantique suffisamment puissant existera : c'est l'attaque dite « récolter maintenant, déchiffrer plus tard ». En revanche, une signature numérique cassée a posteriori n'invalide pas une authentification déjà effectuée et consignée. Les VPN, les sauvegardes chiffrées et les archives longues doivent donc migrer vers ML-KEM en priorité, avant même de traiter les signatures.

Comment automatiser le renouvellement des certificats TLS avec ACME ?

ACME est un protocole normalisé (RFC 8555) par lequel un client installé sur le serveur prouve le contrôle d'un domaine (par un enregistrement DNS ou un fichier HTTP) puis obtient et installe un certificat sans intervention humaine. L'automatisation complète suppose un client par plateforme (certbot, acme.sh, win-acme ou agent natif du répartiteur de charge), une autorité compatible publique ou privée, des droits d'écriture DNS maîtrisés et une supervision des échecs de renouvellement. Avec la réutilisation DCV limitée à dix jours en 2029, cette automatisation devient non optionnelle.

Quelles sont les recommandations de l'OFCS, de l'ANSSI et du NIST pour l'agilité cryptographique ?

Le NIST a standardisé ML-KEM, ML-DSA et SLH-DSA en 2024 et définit la crypto-agilité comme l'ensemble des capacités nécessaires pour remplacer et adapter les algorithmes dans les protocoles, applications, logiciels et matériels. L'ANSSI préconise une transition en phases avec hybridation obligatoire tant que le recul sur les nouveaux algorithmes reste insuffisant. En Suisse, l'Office fédéral de la cybersécurité (OFCS/NCSC) est l'autorité de référence locale : ses recommandations techniques s'adressent directement aux administrations et aux opérateurs d'infrastructures critiques suisses.

Qu'est-ce que le ballot SC-081 du CA/Browser Forum ?

Le ballot SC-081 est la décision formelle du CA/Browser Forum qui fixe le calendrier de réduction de la durée de validité des certificats TLS publics : 200 jours maximum depuis le 15 mars 2026, 100 jours au 15 mars 2027, et 47 jours au 15 mars 2029. Il limite également la réutilisation de la validation de contrôle de domaine (DCV) à dix jours en 2029. Ce calendrier rend l'automatisation par ACME indispensable pour tout parc de taille significative.

Ce qu'il faut retenir

Trois points résument la démarche. La crypto-agilité commence par la visibilité : sans inventaire cryptographique à jour, aucune migration n'est pilotable. L'automatisation des certificats imposée par le passage à 47 jours en 2029 constitue le terrain d'entraînement le plus accessible pour aborder la migration post-quantique. Enfin, les équipements matériels et les contrats fournisseurs déterminent le calendrier réel bien plus que le code applicatif.

SPIE Switzerland accompagne les entreprises et les institutions suisses dans l'inventaire de leur parc cryptographique, l'automatisation de leurs services ICT et la préparation post-quantique de leurs infrastructures techniques. Pour évaluer la maturité crypto-agile de votre organisation, consultez notre page cybersécurité ou contactez nos équipes.

Participez à nos événements et webinaires