2030 n'est pas la date d'arrivée des ordinateurs quantiques
Pendant des années, la cryptographie a fonctionné silencieusement sous la plupart des conversations de sécurité d'entreprise. RSA et ECDSA vivaient dans des pages que la plupart des administrateurs ne liraient jamais ; le handshake TLS était un détail technique oublié dès la connexion établie. En 2024, cela a changé. Le NIST a finalisé ses premiers standards de cryptographie post-quantique (PQC) et le compteur de l'infrastructure d'entreprise s'est mis en marche pour achever la transition d'ici 2030.
La Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) de la NSA fixe 2030 comme année cible pour la transition des systèmes de sécurité nationale américains vers la cryptographie post-quantique. Cette chronologie est traitée comme une échéance sectorielle pratique. Les fabricants qui approvisionnent les clients de la sécurité nationale doivent s'y conformer. Les clients d'entreprise suivent les mêmes standards, car leurs auditeurs, régulateurs et grandes contreparties les suivent.
Mais il y a ici une idée fausse répandue : l'échéance de 2030 ne signifie pas « l'année où les ordinateurs quantiques arrivent ».
Les estimations d'experts sur la date d'apparition d'un ordinateur quantique cryptographiquement pertinent varient de la fin des années 2030 à « jamais » ; cela dépend de l'analyste. L'échéance de 2030 concerne le temps de préparation. Migrer la PKI mondiale, chaque endpoint TLS, chaque autorité de certification, chaque appareil embarqué livré avec RSA codé en dur prend plus d'une décennie. Il faut commencer le travail bien avant que la menace ne devienne opérationnelle ; sinon, la transition ne sera pas achevée au moment où l'on en aura besoin.
Ajoutez à cela la menace « collecter maintenant, déchiffrer plus tard » (harvest now, decrypt later — HNDL). Un adversaire qui enregistre votre trafic chiffré en 2026 pourra déchiffrer l'enregistrement des années plus tard, lorsqu'il disposera de la capacité quantique. Si les données doivent rester confidentielles après 2030 — secrets commerciaux, communications de fusions-acquisitions, documents juridiques scellés, PII client avec de longues fenêtres de conservation — la protection post-quantique est nécessaire dès maintenant. L'échéance s'applique à la durée de vie de confidentialité des données ; pas à la date d'arrivée de l'ordinateur quantique.
La transition PQC en chiffres
ML-KEM, ML-DSA et ML-SLH ; publiés sous FIPS 203, 204, 205
NIST CSRCAnnée cible de la NSA pour les systèmes de sécurité nationale américains
NSA CNSA 2.0Ce que le NIST a finalisé en 2024
Après un processus de sélection pluriannuel entamé en 2016, le NIST a finalisé ses premiers standards de cryptographie post-quantique en août 2024. Trois algorithmes ont émergé ; chacun répond à une primitive cryptographique différente que fournissaient les algorithmes à clé publique classiques. Les trois sont basés sur les réseaux euclidiens (lattice) ou sur le hachage — les familles que le NIST a retenues après avoir éliminé les autres candidats.
ML-KEM (FIPS 203)
Module-Lattice-Based Key Encapsulation Mechanism, anciennement Kyber. Le standard pour l'échange de clés — l'étape où TLS établit un secret partagé sur un canal public. Remplace l'échange de clés basé sur RSA, en usage depuis les années 1990, et ECDH. ML-KEM-768 ajoute environ 1,1 Ko au handshake ; X25519 faisait environ 100 octets. Le coût CPU peut rivaliser avec RSA-2048.
ML-DSA (FIPS 204)
Module-Lattice-Based Digital Signature Algorithm, anciennement Dilithium. Le standard pour les signatures numériques ; utilisé dans les certificats, la signature de code, l'authentification et tout contexte où le destinataire doit vérifier l'identité de l'expéditeur. Remplace RSA et ECDSA. Les signatures ML-DSA-65 font environ 3,3 Ko ; ECDSA environ 70 octets. Les performances de signature sont comparables à ECDSA.
ML-SLH (FIPS 205)
Stateless Hash-Based Signature Algorithm, anciennement SPHINCS+. Un schéma de signature alternatif avec des compromis différents. Il produit des signatures plus lentes et plus volumineuses que ML-DSA ; mais il est basé sur le hachage — sa sécurité repose sur des hypothèses plus faciles à défendre que les problèmes de réseaux euclidiens sous-jacents à ML-DSA. La plupart des déploiements utiliseront ML-DSA pour les performances ; ML-SLH sera réservé à la signature d'archives à long terme, où des hypothèses prudentes sont plus critiques.
Les capacités que les ADC d'entreprise doivent satisfaire
Les contrôleurs de distribution d'applications d'entreprise — équilibreurs de charge, WAF, terminateurs SSL, systèmes GTM — se situent à la frontière de la terminaison TLS. Cette position fait du support PQC une porte pour une transition plus large : si l'ADC ne peut pas parler PQC, rien derrière lui ne le peut non plus.
ML-KEM dans l'échange de clés TLS 1.3
L'ADC doit accepter et pouvoir négocier ML-KEM comme algorithme d'échange de clés dans le handshake TLS 1.3. La plupart des déploiements choisiront le mode hybride — ML-KEM combiné avec X25519 ou P-256 — c'est pourquoi le support des groupes hybrides est également nécessaire.
ML-DSA pour les signatures de certificats
Les certificats que l'ADC présente aux clients et ceux qu'il valide auprès des services en amont — les deux requièrent le support de ML-DSA. La validation de chaîne de certificats, l'OCSP stapling et la vérification SCT doivent toutes être conscientes de ML-DSA.
Capacité de payload de handshake plus grande
ML-KEM-768 ajoute environ 1,1 Ko au handshake ; les signatures ML-DSA-65 font environ 3,3 Ko. L'ADC doit gérer des paquets de handshake plus volumineux ; cela est directement pertinent pour la configuration MTU, le budgétage du taux de connexion et le réglage fin de l'atténuation DDoS.
Outils du cycle de vie des certificats
Les outils de gestion de certificats existants supposent des tailles de clés et de signatures classiques. Les certificats PQC sont plus volumineux ; les workflows ACME, les magasins de certificats et les intégrations HSM nécessitent des mises à jour pour gérer le nouveau profil de taille.
Mode hybride par défaut
Les déploiements PQC pur sont encore prématurés ; les algorithmes sont plus récents et leur historique de cryptanalyse est limité. Le mode hybride (classique et PQC dans le même handshake) est la voie prudente : si l'un des deux composants est sûr, la connexion est sûre. L'hybride devrait être planifié par défaut au moins jusqu'en 2028.
Marge de performance
Le coût CPU de ML-KEM peut rivaliser avec RSA-2048 ; la signature ML-DSA est comparable à ECDSA. L'impact pratique sur les performances est faible mais non nul. La planification de capacité doit tenir compte du coût CPU de handshake TLS légèrement plus élevé pendant la transition hybride.
Les déploiements PQC pur reposent sur une seule nouvelle famille d'algorithmes pour la confidentialité. Si un futur résultat de cryptanalyse affaiblit ML-KEM, chaque connexion utilisant uniquement ML-KEM devient rétroactivement vulnérable. Le mode hybride — la combinaison de ML-KEM avec X25519 ou P-256 — dérive le secret de session des deux ; tant que l'un des algorithmes résiste, la connexion est sûre. Le coût est la taille du handshake hybride (la plus grande des deux contributions). L'avantage est une défense en profondeur contre les faiblesses futures inconnues dans l'une ou l'autre des familles. Les principaux navigateurs (Chrome, Firefox) et les bibliothèques TLS ont déployé le mode hybride entre 2024 et 2026 ; l'IETF a standardisé les identifiants de groupes hybrides. Pour les déploiements d'entreprise, l'hybride devrait être le défaut au moins jusqu'en 2028.
Chronologie opérationnelle pour la transition d'entreprise
Maintenant (2026) : inventoriez les surfaces cryptographiques
Listez chaque endpoint TLS, chaque relation avec une autorité de certification, chaque workflow de signature de code et chaque flux de données à confidentialité longue durée. Sans inventaire, la portée de la transition ne peut être planifiée. La plupart des organisations découvrent des surfaces oubliées — services internes, anciens clients, appareils embarqués, intégrations B2B.
Maintenant (2026) : activez la PQC sur le TLS public
Pour les ADC qui le prennent en charge, activez le mode hybride ML-KEM sur les endpoints TLS publics. Le changement est prudent : le mode hybride retombe sur la sécurité classique si la PQC est ultérieurement affaiblie. Le trafic de production réel en bénéficie immédiatement.
2026-2027 : pilotez les certificats ML-DSA
Commencez à émettre des certificats signés ML-DSA pour des charges de travail non critiques afin de valider les outils de gestion de certificats, la supervision et les procédures opérationnelles. Les chemins de code de validation de chaîne de certificats s'entraînent avant de porter la charge des services critiques.
2027-2028 : étendez aux services internes
Étendez le TLS hybride et les certificats ML-DSA au trafic est-ouest interne. Les services internes ont une tolérance plus élevée aux problèmes de compatibilité pendant le pilote ; les problèmes de compatibilité de longue traîne émergent avant de devenir publics.
2028-2029 : nettoyage de la longue traîne
Traitez les appareils embarqués dépourvus de support PQC, les anciennes intégrations et les API tournées vers les partenaires. Certains fabricants nécessitent de la pression ; certains anciens systèmes nécessitent un remplacement. La longue traîne est l'endroit où le budget temps de la transition est réellement consommé.
2030 : PQC opérationnelle
Toutes les nouvelles connexions TLS utilisent l'hybride ou la PQC pure. Seules les connexions classiques nécessitent une exception explicite et une chronologie de fin de vie documentée. La transition n'est plus un projet mais une opération — l'agilité cryptographique continue est la nouvelle norme.
Qu'est-ce que cela signifie pour les choix de produits ADC en 2026 ?
Les décisions d'infrastructure d'entreprise prises en 2026 perdurent tout au long de la fenêtre de transition PQC. Un ADC choisi aujourd'hui mais dépourvu de support PQC est un remplacement obligatoire avant 2030 — un coût que l'acheteur n'avait pas planifié. Pour l'évaluation des fabricants, les conséquences pratiques se regroupent sous trois rubriques.
Premièrement, le support PQC doit être vérifié en tant que capacité fondamentale ; pas en tant qu'élément de feuille de route. « Nous prendrons en charge ML-KEM dans notre version 2027 » et « ML-KEM est dans notre version actuelle » ne sont pas la même chose. La transition hybride exige une validation en production réelle, ce qui requiert que la fonctionnalité soit disponible dès maintenant.
Deuxièmement, le statut de validation FIPS 140-3 des implémentations PQC est important pour les secteurs réglementés — gouvernement, défense, banque. La validation est en retard sur l'adoption ; elle doit donc être intégrée aux chronologies d'achat.
Troisièmement, le récit opérationnel peut être plus important que le récit cryptographique : comment l'ADC gère-t-il les workflows de gestion de certificats sous les tailles PQC, comment règle-t-il finement le budget de handshake plus grand, comment rapporte-t-il la répartition des sessions PQC vs classiques. Les mathématiques sont établies ; les opérations sont encore en cours de résolution à l'échelle du secteur.
Le positionnement de TR7 sur la technologie moderne inclut le support de ML-KEM et ML-DSA dans les versions actuelles ; pas comme une porte de fonctionnalité future. Le choix architectural qui rend cela possible est le même que celui qui rend possibles HTTP/3 et les mises à jour sans interruption : TR7 a été conçu à partir d'une base propre ; il n'a pas été rétro-patché sur une architecture antérieure à ces exigences. Pour les organisations qui mesurent la préparation PQC dans le cadre de leurs évaluations de fabricants en 2026, cette posture native est une entrée qui facilite la décision.
Références et sources
Août 2024 — publication de FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (ML-SLH) à l'issue d'un processus de sélection pluriannuel. https://csrc.nist.gov/projects/post-quantum-cryptography
La Commercial National Security Algorithm Suite 2.0 fixe 2030 comme année cible pour la transition des systèmes de sécurité nationale américains vers la cryptographie post-quantique. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/
Spécification complète de ML-KEM (Kyber), incluant les ensembles de paramètres, les tailles de texte chiffré et les propriétés de sécurité. https://csrc.nist.gov/pubs/fips/203/final
Spécification complète de ML-DSA (Dilithium), incluant les tailles de signature, la vérification et l'analyse de sécurité. https://csrc.nist.gov/pubs/fips/204/final
Internet draft définissant les identifiants de groupes d'échange de clés hybrides post-quantiques pour TLS 1.3. https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Conçu pour la suite, 2030 inclus
L'ADC d'entreprise de TR7 prend en charge ML-KEM et ML-DSA dans les versions actuelles — y compris les modes TLS hybrides combinant algorithmes classiques et post-quantiques. HTTP/3, QUIC, les mises à jour sans interruption et la cryptographie post-quantique font partie du même engagement architectural : construire pour la suite plutôt que rapiécer l'ancien.
Découvrir la technologie moderne TR7