Cryptographie 2026 : transport, stockage, identités et transition post-quantique — le cadre de décision pour dirigeants et RSSI

La cryptographie n’est plus un sujet d’ingénieurs. C’est devenu une décision de direction. Trois évolutions de fond se rejoignent en 2026 — la transition post-quantique, l’industrialisation des attaques sur l’identité, et un cadre réglementaire européen qui se clarifie — et chacune appelle des arbitrages que seul un dirigeant peut trancher : quelles données protéger en priorité, quel niveau de souveraineté viser, à quel rythme moderniser.

La bonne nouvelle, c’est que les standards existent, le calendrier est connu, et la trajectoire est balisée par l’ANSSI, le NIST et les bonnes pratiques de l’industrie. Il n’y a pas d’urgence à paniquer ; il y a une méthode à appliquer. Cet article pose le cadre de décision en trois temps — les données en transit, les données au repos, les identités — puis le situe dans la grille de maturité de la Méthode Junyr™ pour vous permettre de décider où mettre l’effort cette année.

À retenir en une phrase. Le réflexe gagnant en 2026 n’est pas d’acheter un outil de plus, mais de structurer une crypto-agilité : la capacité à changer d’algorithme sans refondre le système d’information à chaque évolution.

---

1. La transition post-quantique : un calendrier, pas une alarme

1.1. Ce qui change, et pourquoi c’est gérable

La cryptographie asymétrique qui sécurise Internet (RSA, courbes elliptiques) repose sur des problèmes mathématiques qu’un ordinateur quantique suffisamment puissant — dit « cryptographiquement pertinent » (CRQC) — saurait résoudre rapidement grâce à l’algorithme de Shor. Ce CRQC n’existe pas encore. L’enjeu pour un dirigeant n’est donc pas la machine de demain, mais une pratique d’aujourd’hui à anticiper sereinement.

Cette pratique porte un nom : « Store-Now, Decrypt-Later » (SNDL), ou « récolter maintenant, déchiffrer plus tard ». Des acteurs disposant de moyens importants peuvent intercepter et conserver aujourd’hui des communications chiffrées (trafic TLS, tunnels VPN), dans l’idée de les déchiffrer une fois la puissance quantique disponible. La conséquence est simple et actionnable : toute donnée dont la confidentialité doit tenir plus de cinq à dix ans mérite d’être protégée dès maintenant par des mécanismes résistants au quantique.

C’est pourquoi la priorité va à la confidentialité (l’échange de clés) plutôt qu’à la signature : usurper une identité par signature exigerait un ordinateur quantique opérationnel en temps réel, alors que la donnée interceptée aujourd’hui, elle, attend tranquillement.

1.2. Des standards stables sur lesquels s’appuyer

En août 2024, le NIST a publié ses premiers standards finaux de cryptographie post-quantique. Ils ne reposent plus sur la factorisation mais sur des familles mathématiques différentes, conçues pour résister aux attaques classiques comme quantiques.

Standard	Origine	Nouveau nom	Fonction	Usage principal
FIPS 203	CRYSTALS-Kyber	ML-KEM	Échange de clés (KEM)	Confidentialité en transit, protection contre le SNDL
FIPS 204	CRYSTALS-Dilithium	ML-DSA	Signature numérique	Authentification serveurs, certificats, PKI
FIPS 205	SPHINCS+	SLH-DSA	Signature numérique	Solution de repli à ML-DSA, intégrité logicielle/firmware
SP 800-208	LMS / XMSS	LMS / XMSS	Signature à état	Mises à jour de firmware

Ces standards permettent aux éditeurs, aux systèmes d’exploitation et aux agences d’engager une intégration à grande échelle. Le terrain est balisé.

1.3. La doctrine de transition : l’hybridation, choix de prudence

Les algorithmes post-quantiques sont solides, mais récents : ils n’ont pas encore les décennies d’analyse qu’ont connues RSA ou les courbes elliptiques. Plutôt que de tout remplacer d’un coup, l’industrie et les agences européennes recommandent l’hybridation : combiner, le temps de la transition, un algorithme classique éprouvé (ECDH) avec un algorithme post-quantique (ML-KEM). Pour compromettre la session, un adversaire devrait casser les deux à la fois — l’un nécessitant un ordinateur quantique, l’autre y étant immunisé. C’est une approche de ceinture-et-bretelles, donc rassurante.

Les doctrines nationales divergent sur le tempo, ce qui a une implication concrète pour les entreprises internationales :

Agence	Pays	Posture sur l’hybridation
ANSSI	France	Exigée, stratégie de transition principale et immédiate
BSI	Allemagne	Fortement recommandée, alignée ANSSI / ENISA
NCSC	Royaume-Uni	Mesure transitoire ; préfère une transition directe à terme
NSA (CNSA 2.0)	États-Unis	Transition directe vers PQC pur pour les systèmes de sécurité nationale
CCCS	Canada	Neutre

La conséquence pratique : concevoir des architectures crypto-agiles, capables de négocier des modes hybrides en Europe (conformité ANSSI/BSI) tout en pouvant basculer sur des modes PQC purs ailleurs. C’est précisément la souplesse que vise la crypto-agilité.

---

2. Les données en transit : moderniser sans casser le réseau

Trois protocoles structurent le transport sécurisé : TLS (web, API), IPsec (interconnexions de sites, télétravail) et SSH (administration). Leur passage au post-quantique est surtout un sujet d’ingénierie réseau : les clés post-quantiques sont plus volumineuses, et certains équipements anciens tolèrent mal des paquets plus gros. Bonne nouvelle : les solutions sont connues et documentées.

2.1. TLS 1.3 et QUIC

TLS 1.3 représente plus de 93 % des connexions sécurisées et sert de fondation à QUIC (HTTP/3). La priorité est d’hybrider la phase d’établissement de clés, avec des configurations de type X25519MLKEM768. Point de vigilance : une clé hybride dépasse le kilo-octet (contre ~32 octets pour un échange classique), ce qui peut faire grossir le premier message (« ClientHello ») au-delà de la taille standard et provoquer des fragmentations mal gérées par d’anciens pare-feux ou équilibreurs de charge — un phénomène d’« ossification » du réseau.

L’action recommandée est simple : auditer la chaîne d’inspection réseau pour vérifier sa tolérance à ces paquets plus volumineux. Le mécanisme GREASE (intégré à TLS 1.3) aide déjà à éviter le figement des règles de filtrage. Pour les certificats X.509 hybrides, l’ANSSI recommande d’attendre la finalisation des standards IETF : la priorité reste la confidentialité, pas l’authentification.

2.2. IPsec et IKEv2

Le plan de données d’IPsec (ESP/AH, en AES-256-GCM) résiste bien au quantique. C’est la phase d’établissement, pilotée par IKEv2 sur UDP, qui demande une hybridation. Comme UDP gère mal les paquets très volumineux, l’ANSSI et l’IETF s’appuient sur une pile de standards désormais disponibles :

• RFC 7383 — fragmentation au niveau IKE (évite la fragmentation IP aveugle) ;

• RFC 9242 — échange intermédiaire (IKE_INTERMEDIATE) pour transporter de gros payloads de façon fiable ;

• RFC 9370 — négociation de plusieurs échanges de clés (l’hybridation proprement dite), intégrée dans StrongSwan 6.0+ ;

• RFC 8784 — clés pré-partagées post-quantiques (PPK), palliatif immédiat pour les systèmes fermés.

L’action concrète : mettre à jour les firmwares des concentrateurs VPN et pare-feux vers des versions supportant ces RFC. Sans cette mise à niveau, l’hybridation bloquerait l’établissement des tunnels — d’où l’importance de planifier ces mises à jour avant de basculer.

2.3. SSH

SSH est la porte d’entrée de l’administration. OpenSSH a été pionnier : dès la version 9.0, échange de clés hybride par défaut (X25519 + NTRU Prime) ; avec la 10.0, hybridation ML-KEM par défaut, alignée sur FIPS 203. L’action recommandée : passer le parc administrateurs à OpenSSH 10.0+. L’authentification des clés (utilisateurs et hôtes) reste classique faute de standard IETF finalisé ; en attendant, on automatise une rotation fréquente des clés (Vault, Ansible) et on segmente les réseaux d’administration.

2.4. Messagerie de groupe : le standard MLS

Pour les communications de groupe chiffrées de bout en bout (E2EE), l’approche historique (le « Double Ratchet » de Signal) passe mal à l’échelle : ajouter ou retirer un membre dans un groupe de n personnes coûte un effort proportionnel à n. L’IETF a publié en juillet 2023 le standard Messaging Layer Security (MLS, RFC 9420), qui réduit ce coût à un ordre logarithmique grâce à une structure en arbre (TreeKEM). MLS est déjà en production (Cisco Webex, RCS 2.0) et a été conçu pour intégrer nativement les futurs mécanismes post-quantiques — un bon repère pour choisir une plateforme de collaboration pérenne.

---

3. Les données au repos : la vraie question est celle des clés

Pour le stockage, l’algorithme de chiffrement n’est pas le sujet : l’AES-256 reste la norme et résiste au quantique. L’algorithme de Grover divise par deux la robustesse effective d’une clé symétrique — une AES-128 tomberait à un niveau vulnérable, tandis qu’une AES-256 conserve une marge de sécurité confortable. Le vrai enjeu se déplace vers la gestion des clés et la souveraineté.

3.1. Le chiffrement en enveloppe

Le cloud moderne repose sur une hiérarchie de clés : une DEK (clé de données, éphémère) chiffre les fichiers ; une KEK (clé maîtresse) chiffre la DEK. La DEK n’est jamais stockée en clair. Les KEK doivent être générées, gérées et stockées dans des HSM (modules de sécurité matériels) validés FIPS 140-3 niveau 3, via un service KMS. Toute opération de déchiffrement se fait dans la mémoire protégée du HSM.

3.2. Souveraineté : la question à trancher au niveau direction

Le risque n’est pas seulement criminel (rançongiciels visant les sauvegardes), il est aussi juridique. La CNIL, s’appuyant sur l’ANSSI, alerte : si le fournisseur de cloud détient à la fois les données et les clés maîtresses, il peut techniquement être contraint, par des législations à portée extraterritoriale (Cloud Act américain, section 702 du FISA, lois de renseignement de juridictions tierces), de fournir des données en clair. La souveraineté se raisonne donc en termes de juridiction et d’infrastructure, pas d’origine nationale supposée des menaces.

Trois niveaux de maîtrise des clés, à arbitrer selon la sensibilité des données :

• Par défaut : le fournisseur gère tout. Simple, mais aucune protection contre une injonction extraterritoriale.

• BYOK (Bring Your Own Key) : vous générez vos clés et les importez. Meilleur contrôle des rotations, mais le fournisseur garde un accès technique en mémoire lors du traitement.

• HYOK / External KMS (« Approche 4 » de la CNIL) : vous conservez la maîtrise physique des KEK dans vos propres HSM (on-premise ou fournisseur souverain). C’est la seule option qui garantit une souveraineté cryptographique stricte ; elle est plus exigeante à intégrer. C’est aussi l’esprit du visa SecNumCloud de l’ANSSI.

3.3. Protéger l’intégrité des sauvegardes

Chiffrer ne suffit plus : les attaquants ciblent les sauvegardes pour les effacer ou les altérer. On s’appuie sur des fonctions de hachage robustes (SHA-384, SHA-512, famille SHA-3) et des mécanismes d’intégrité (MAC) pour garantir l’immuabilité de sauvegardes hors-ligne — la condition pour se relever sereinement d’une attaque.

---

4. Les identités : le mot de passe seul a fait son temps

C’est probablement le chantier au meilleur rapport effort/impact pour une PME en 2026.

4.1. Stocker les mots de passe correctement

En base de données, on ne stocke jamais un mot de passe en clair, et on bannit les hachages rapides (MD5, SHA-1), cassables par des fermes de GPU. La règle OWASP/ANSSI : utiliser des fonctions « memory-hard », gourmandes en mémoire vive, qui rendent l’attaque économiquement inintéressante.

Algorithme	Statut	Repère de configuration
Argon2id	Recommandé (standard de facto)	m = 19 MiB minimum, t = 2, p ajusté au serveur
scrypt	Bonne alternative	N = 2¹⁷ (≈128 MiB), r = 8
bcrypt	Hérité	Work factor > 10 ; attention à la troncature au-delà de 72 octets
PBKDF2	Toléré (conformité)	Non « memory-hard » : à éviter pour tout nouveau projet

On y ajoute systématiquement un sel (unique, contre les tables arc-en-ciel) et, en haute sécurité, un poivre (clé secrète globale stockée dans un HSM). Ces mécanismes sont résistants au quantique tant que la fonction de hachage sous-jacente est robuste.

4.2. Pourquoi le MFA « classique » ne protège plus

Le MFA par SMS, code temporaire (TOTP) ou notification push était considéré comme suffisant. Il ne l’est plus face aux attaques par procuration « Adversary-in-the-Middle » (AiTM), devenues industrielles.

Le principe, expliqué simplement : l’attaquant place entre vous et le vrai site un proxy transparent. Vous voyez la vraie page de connexion (relayée en temps réel), vous saisissez vos identifiants puis votre code MFA — et l’attaquant récupère au passage le jeton de session émis après validation. À partir de là, votre mot de passe n’a plus d’importance : l’attaquant détient une session légitime. Ces kits sont commercialisés « clés en main » (Phishing-as-a-Service), parfois combinés à du vishing (appel téléphonique d’un faux support, éventuellement assisté par voix synthétique). Un incident marquant de fin janvier 2026 a ainsi conduit, par cette méthode, au vol d’identifiants SSO et à l’exfiltration de bases CRM — sans qu’aucune formation à la vigilance n’aurait pu l’éviter.

Le constat est posé sans dramatiser : aucune méthode reposant sur la répétition humaine d’un secret ne résiste à une interception par proxy. La parade existe, elle est mathématique.

4.3. FIDO2 / passkeys : la parade par conception

Les passkeys (standard FIDO2 / WebAuthn) résolvent le problème par un principe appelé liaison d’origine (origin binding). À l’inscription, votre appareil génère une paire de clés propre au service ; la clé privée ne quitte jamais l’enclave sécurisée (TPM, Secure Enclave, clé matérielle type YubiKey). À la connexion, le navigateur vérifie lui-même le domaine exact et ne signe le défi que s’il correspond au domaine enregistré. Sur un faux site, la signature est refusée automatiquement : l’attaque échoue sans que l’utilisateur ait à juger de la validité de l’URL.

L’adoption a atteint une masse critique en 2026 : plus de 5 milliards de passkeys en usage, 68 % des organisations en déploiement. Des entreprises pionnières (Cloudflare, Snap) rapportent zéro compromission par hameçonnage après bascule complète et désactivation des méthodes de repli vulnérables.

---

5. Le cadre réglementaire européen : un horizon qui se clarifie

Deux dossiers européens méritent l’attention des dirigeants, non pour inquiéter mais pour anticiper.

eIDAS 2.0 (article 45 / QWAC). Le règlement crée un portefeuille d’identité numérique européen — une avancée utile. Une disposition technique fait débat : l’obligation faite aux navigateurs d’intégrer certaines autorités de certification adoubées par les États (QWAC) sans pouvoir les retirer librement. Les éditeurs de navigateurs, des cryptographes et des organisations de défense des libertés numériques (EFF, Internet Society) alertent sur le fait que cela pourrait ralentir la réponse à incident (révocation d’une autorité compromise) et créer un précédent susceptible d’être invoqué par d’autres juridictions aux garde-fous démocratiques plus faibles, alimentant la fragmentation d’Internet. Action dirigeant : pour les applications critiques, mettre en place du certificate pinning et surveiller la Certificate Transparency.

« Chat Control » et le chiffrement de bout en bout. La proposition visant à analyser préventivement les messageries pour lutter contre les contenus pédocriminels a buté sur une impossibilité technique : analyser des messages chiffrés de bout en bout supposerait un « client-side scanning » (analyse sur l’appareil avant chiffrement), qui revient à affaiblir le chiffrement pour tout le monde et fragilise le secret professionnel (avocats, médecins, journalistes). Fin 2025–début 2026, sous l’impulsion du Danemark, le Conseil de l’UE a fait évoluer le texte pour exclure l’obligation de détection forcée sur les espaces E2EE — une clarification bienvenue. Le dossier entre en phase de trilogues ; la vigilance reste de mise, mais la direction est rassurante.

---

6. Où mettre l’effort en 2026 : la lecture par la Méthode Junyr™

Tout ne se fait pas en même temps. La Méthode Junyr™ distingue trois niveaux de maturité — Artisan, Orchestre, Architecte — qui donnent un ordre de marche clair et tenable. Voici comment la cryptographie s’y inscrit :

Niveau Artisan — sécuriser les fondations (0–6 mois). Les gestes à fort impact, faibles en complexité : généraliser les passkeys / FIDO2 pour les comptes à privilèges (direction, IT, finance) et désactiver les méthodes MFA de repli vulnérables ; vérifier que le stockage des mots de passe utilise Argon2id ; confirmer que tout le chiffrement au repos est en AES-256. C’est ici que se gagne l’essentiel de la résilience, vite.

Niveau Orchestre — structurer la crypto-agilité (6–18 mois). Cartographier les flux chiffrés et les certificats (inventaire cryptographique), activer l’hybridation TLS 1.3 sur les services exposés, planifier les mises à jour réseau (IPsec/IKEv2, OpenSSH 10.0+), et arbitrer le niveau de souveraineté des clés (BYOK vs HYOK) selon la sensibilité des données. L’objectif : pouvoir changer d’algorithme sans tout refondre.

Niveau Architecte — piloter par la donnée et la durée (18 mois et au-delà). Classer les données par durée de confidentialité requise et prioriser la protection post-quantique des plus longues (logique SNDL) ; intégrer une architecture External KMS / HYOK souveraine ; choisir des plateformes de collaboration bâties sur des standards pérennes (MLS) ; intégrer la veille réglementaire (eIDAS, E2EE) à la gouvernance.

Cette progression évite deux écueils : l’attentisme (« on verra quand le quantique arrivera ») et la précipitation coûteuse (« on remplace tout »). Pour les organisations qui souhaitent déléguer une partie de cette orchestration — inventaire, surveillance des certificats, rotation des clés — Junyr Agents™ peut automatiser les tâches répétitives sous supervision, dans une logique de méthode plutôt que d’empilement d’outils.

---

Conclusion

La cryptographie a changé de statut : elle conditionne désormais la confiance numérique d’une organisation autant que sa conformité. Mais le tableau de 2026 n’est pas celui d’une menace insurmontable — c’est celui d’une trajectoire balisée : des standards stables (NIST, ANSSI), une doctrine prudente (l’hybridation), des parades éprouvées (FIDO2), et un cadre européen qui se clarifie. Le travail du dirigeant n’est pas de tout faire d’un coup, mais de structurer la crypto-agilité et de mettre l’effort au bon endroit, dans le bon ordre. C’est tenable, et c’est même un avantage compétitif pour qui s’y prend méthodiquement.

Pour situer votre organisation sur l’échelle de maturité et bâtir votre feuille de route : Diagnostic IA & Sécurité Express — croissance-transitions.fr.

---

Sources — liens directs vérifiés (audit 29 mai 2026)

37 références (doublon R Street fusionné ; source AiTM remplacée par une source au titre conforme). Tous les liens vérifiés le 29 mai 2026.

Post-quantique — standards et transition 1. NIST — NIST Releases First 3 Finalized Post-Quantum Encryption Standards 2. NIST CSRC — Post-Quantum Cryptography 3. Akamai — A Guide to International Post-Quantum Cryptography Standards 4. Akamai — Post-Quantum Cryptography Implementation Considerations in TLS 5. Palo Alto Networks — A Complete Guide to Post-Quantum Cryptography Standards 6. ANSSI — Follow-up position paper on Post-Quantum Cryptography (addendum 2023)

Transport (TLS, QUIC, IPsec, SSH) 7. ANSSI — Transition post-quantique du protocole TLS 1.3 8. ANSSI — Transition post-quantique de SSHv2 (PDF) 9. ANSSI — Transition post-quantique du protocole IPsec 10. DataGuidance — France: ANSSI releases guide on Post-Quantum Transition of IPsec 11. blog.ogwilliam.com — Concrete Technical Steps for Post-Quantum TLS, SSH, and IPsec 12. AWS Security Blog — Enable post-quantum key exchange in QUIC with the s2n-quic library 13. Cloudflare Blog — The state of the post-quantum Internet

Messagerie de groupe / MLS 14. IETF Datatracker — RFC 9420 — The Messaging Layer Security (MLS) Protocol 15. Feisty Duck — RFC 9420: Messaging Layer Security 16. Gopher Security — Understanding Messaging Layer Security 17. YouTube (37C3) — RFC 9420 or how to scale end-to-end encryption with Messaging Layer Security

Stockage, KMS, souveraineté cloud 18. Google Cloud — Envelope encryption / Chiffrement encapsulé (Cloud KMS) 19. AWS — Protection des données dans AWS Key Management Service 20. Entrust — Quelles sont les meilleures stratégies de gestion des clés d’entreprise ? 21. CERT-FR (ANSSI) — Secteur du cloud — État de la menace informatique (CERTFR-2025-CTI-001) 22. CNIL — Les pratiques de chiffrement dans l’informatique en nuage (cloud) public 23. ANSSI — Recommandations de déploiement d’un service IaaS OpenStack SecNumCloud (ANSSI-BP-104)

Hachage de mots de passe 24. OWASP — Password Storage Cheat Sheet 25. ANSSI / MonServiceSécurisé — Protéger les mots de passe stockés sur le service 26. ANSSI — Guide des mécanismes cryptographiques : règles et recommandations (ANSSI-PG-083)

AiTM, MFA, FIDO2 / passkeys 27. The Hacker News — How AitM Phishing Attacks Bypass MFA and EDR — and How to Fight Back 28. Luxgap — Okta/SSO hit by vishing: how FIDO2 blocks MFA bypass 29. WorkOS — Passkeys stop phishing. Your MFA fallbacks undo it. 30. FIDO Alliance — The State of Passkeys 2026: Global Consumer and Workforce Report

eIDAS 2.0 31. EFF — eIDAS 2.0 Sets a Dangerous Precedent for Web Security 32. R Street Institute — Cybersecurity Score — European Union Electronic Identification, Authentication, and Trust Services (eIDAS 2.0)

Chat Control / E2EE 33. European Newsroom — Privacy vs. child protection: EU’s “chat control” plans split member states 34. EFF — EU Parliament Blocks Mass-Scanning of Our Chats — What’s Next? 35. EFF — After Years of Controversy, the EU’s Chat Control Nears Its Final Hurdle: What to Know 36. EDRi — Chat Control is in the final stretch – but it could be a marathon, not a sprint 37. Tech Policy Press — How Europe’s “Chat Control” Regulation Could Compromise American Communications