Cryptographie Post-Quantique : Migration Pratique en 2026

La cryptographie post-quantique migration 2026 est entrée dans sa phase opérationnelle. Le NIST a publié ses trois premiers standards finaux en août 2024 — ML-KEM, ML-DSA, SLH-DSA — mettant fin à une décennie de compétition algorithmique. Les organisations n'ont plus aucune excuse pour attendre. La menace quantique n'est certes pas imminente au sens où un ordinateur quantique cassant RSA-2048 n'existe pas encore en 2026, mais deux réalités changent la donne : le HNDL (Harvest Now Decrypt Later) est une pratique documentée des services de renseignement étrangers depuis au moins 2018, et les délais de migration PKI dans une grande organisation dépassent les 5 à 7 ans. Si vous commencez en 2027 ou 2028, vous serez en retard. La note ANSSI sur la cryptographie post-quantique est sans ambiguïté : les systèmes traitant des données classifiées ou sensibles à long terme doivent commencer leur migration maintenant. Les données que vous chiffrez aujourd'hui avec RSA ou ECDH pourraient être déchiffrées dans 10 à 15 ans par un adversaire patient. C'est le cas de certains secrets industriels, données médicales, communications diplomatiques, propriété intellectuelle à durée de protection longue. Ce guide vous donne les outils concrets pour démarrer — pas pour comprendre la théorie des réseaux euclidiens, mais pour migrer.

Pourquoi la menace quantique est réelle dès aujourd'hui ?

Un ordinateur quantique capable de casser RSA-2048 en temps pratique nécessite environ 4000 qubits logiques (tolérants aux fautes), selon les estimations de 2023. IBM Heron, leur processeur le plus avancé début 2026, dispose de 133 qubits physiques. Google Willow, annoncé fin 2024, atteint 105 qubits avec des performances remarquables sur des benchmarks spécifiques. L'écart entre 133 qubits physiques et 4000 qubits logiques semble énorme — mais le rythme d'amélioration est exponentiel, pas linéaire.

L'algorithme de Shor est le vrai problème. Formulé en 1994 par Peter Shor, il permet de factoriser un entier N en O(log³N) opérations quantiques. RSA repose sur la difficulté de factoriser de grands entiers — un ordinateur quantique suffisamment puissant le casse en quelques heures. ECDH (Diffie-Hellman sur courbes elliptiques) est vulnérable au même algorithme adapté au problème du logarithme discret. En clair : tous les systèmes basés sur RSA, DSA, ECDSA, ECDH, et DH classique sont vulnérables.

L'algorithme de Grover impacte la cryptographie symétrique différemment : il divise par deux la longueur de clé effective. AES-128 passe à une sécurité équivalente à 64 bits — insuffisant. AES-256 passe à 128 bits — encore acceptable. La recommandation NIST est donc de migrer AES-128 vers AES-256, mesure beaucoup plus simple que la migration PQC complète.

Le HNDL est la raison pour laquelle la migration ne peut pas attendre l'arrivée effective des ordinateurs quantiques. Les NSA Papers et diverses analyses de trafic internet montrent que des acteurs étatiques enregistrent depuis des années du trafic TLS chiffré avec RSA/ECDH, dans l'espoir de le déchiffrer ultérieurement. Si vos données doivent rester confidentielles plus de 10 ans, elles sont concernées maintenant.

Standards NIST PQC finalisés — ML-KEM, ML-DSA, SLH-DSA

Après 7 ans de compétition internationale lancée en 2017, le NIST a finalisé ses trois premiers standards PQC en août 2024. Ce sont les seuls à utiliser en production — évitez les candidats non standardisés.

ML-KEM (FIPS 203) — anciennement Kyber — est l'algorithme d'échange de clés post-quantique. Il utilise des réseaux modulaires (Module Learning With Errors, MLWE). Trois niveaux de sécurité : ML-KEM-512 (sécurité niveau 1, équivalent AES-128), ML-KEM-768 (niveau 3, équivalent AES-192, recommandé en pratique), ML-KEM-1024 (niveau 5, équivalent AES-256). ML-KEM remplace ECDH dans les protocoles TLS, SSH, et tout protocole d'échange de clés.

ML-DSA (FIPS 204) — anciennement Dilithium — est l'algorithme de signature numérique principal. Également basé sur MLWE. Trois niveaux : ML-DSA-44, ML-DSA-65, ML-DSA-87. Il remplace ECDSA et RSA pour la signature de certificats TLS, code signing, et authentification.

SLH-DSA (FIPS 205) — anciennement SPHINCS+ — est une alternative de signature basée sur des fonctions de hachage (hash-based). Plus conservatrice (sécurité repose uniquement sur la sécurité des fonctions de hachage, pas sur des problèmes algébriques), mais clés et signatures plus volumineuses. Recommandée comme algorithme de sauvegarde si ML-DSA venait à être fragilisé.

Algorithmes hybrides et X25519Kyber768 — la stratégie de transition

La migration brutale de l'ensemble de votre cryptographie vers PQC est irréaliste et risquée. La stratégie recommandée par le NIST, l'ANSSI et l'ENISA dans son rapport PQC est l'approche hybride : combiner un algorithme classique éprouvé (X25519 pour l'échange de clés) avec un algorithme post-quantique (ML-KEM-768). La sécurité du secret partagé dépend alors de la résistance des deux algorithmes — si ML-KEM venait à être cassé (scénario théorique), X25519 maintient la sécurité classique. Si l'ordinateur quantique arrive, ML-KEM protège contre la menace quantique.

Cette combinaison X25519Kyber768 est maintenant implémentée dans les navigateurs : Chrome 124+ et Firefox 132+ activent cette suite par défaut pour TLS 1.3. Si votre serveur supporte ce groupe, les connexions des utilisateurs récents sont déjà post-quantiques sans aucune action de leur part.

Le groupe IETF a standardisé cette combinaison sous le nom X25519MLKEM768 (RFC en cours de finalisation). Dans les configurations TLS, on le retrouve sous l'OID 0x11ec ou X25519Kyber768Draft00 selon les implémentations.

OpenSSL 3.x et support PQC — installation et premier test

OpenSSL 3.x ne supporte pas nativement les algorithmes PQC. Il faut ajouter le OQS Provider (Open Quantum Safe), développé par l'Université de Waterloo et NIST, qui implémente tous les algorithmes FIPS 203/204/205.

# Installation des dépendances (Ubuntu 22.04/24.04)
sudo apt-get install -y cmake ninja-build libssl-dev python3-pip

# Cloner et compiler liboqs
git clone --depth 1 https://github.com/open-quantum-safe/liboqs.git
cd liboqs
cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local -DOQS_DIST_BUILD=ON .
ninja && sudo ninja install
cd ..

# Cloner et compiler oqs-provider pour OpenSSL 3.x
git clone --depth 1 https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider
cmake -GNinja \
  -DCMAKE_PREFIX_PATH=/usr/local \
  -DOPENSSL_ROOT_DIR=/usr \
  .
ninja && sudo ninja install
cd ..

# Vérifier que le provider est chargé
openssl list -providers -provider-path /usr/local/lib/ossl-modules \
  -provider oqsprovider 2>/dev/null | grep -E "oqsprovider|version"

# Générer une paire de clés ML-KEM-768
openssl genpkey \
  -provider-path /usr/local/lib/ossl-modules \
  -provider oqsprovider \
  -algorithm mlkem768 \
  -out mlkem768_private.pem

# Extraire la clé publique
openssl pkey \
  -provider-path /usr/local/lib/ossl-modules \
  -provider oqsprovider \
  -in mlkem768_private.pem \
  -pubout -out mlkem768_public.pem

# Vérifier les tailles
wc -c mlkem768_public.pem mlkem768_private.pem
# La clé publique doit faire ~1184 bytes (encodée PEM : ~1620 bytes avec base64)

# Test d'un handshake TLS PQC avec un serveur test OQS
# Lancer un serveur TLS de test local avec ML-KEM-768
openssl s_server \
  -provider-path /usr/local/lib/ossl-modules \
  -provider oqsprovider -provider default \
  -groups X25519MLKEM768:p384_mlkem1024 \
  -cert server.crt -key server.key \
  -port 4433 &

# Connecter un client en forçant le groupe hybride
openssl s_client \
  -provider-path /usr/local/lib/ossl-modules \
  -provider oqsprovider -provider default \
  -groups X25519MLKEM768 \
  -connect localhost:4433 2>&1 | grep -E "Protocol|Cipher|Server Temp Key"
# Attendu : "Server Temp Key: X25519MLKEM768, 1216 bits"

Impact sur la PKI et les certificats TLS

La migration PKI est l'enjeu central et le plus complexe. Vos certificats TLS actuels utilisent ECDSA ou RSA pour la signature — ils devront migrer vers ML-DSA. Mais la migration PKI n'est pas juste "générer de nouveaux certificats" : c'est reconstruire toute la hiérarchie de confiance, depuis la Root CA jusqu'aux certificats leaf des serveurs et des clients.

La durée de vie des certificats est un facteur critique. Apple et Chrome imposent depuis 2024 une durée maximale de 90 jours pour les certificats TLS publics. Cela signifie que vos outils d'automatisation de renouvellement (ACME/Let's Encrypt, cert-manager) devront supporter les algorithmes PQC — ce qui est déjà le cas pour cert-manager 1.15+ avec le plugin OQS. Pour les PKI internes, la migration est plus souple mais doit être planifiée sur plusieurs années.

La recommandation pratique est de créer une PKI parallèle post-quantique dès 2025-2026, en conservant l'ancienne PKI RSA/ECDSA le temps de la transition. Les deux PKI coexistent, et les systèmes migrent progressivement. Voir notre guide d'audit de sécurité Microsoft 365 pour la gestion des certificats dans les environnements Microsoft.

Migration pratique par taille d'organisation

La stratégie de migration ne doit pas être identique pour une PME de 50 personnes et un groupe de 10 000 collaborateurs. Voici une approche différenciée réaliste.

PME (< 250 personnes) — Priorités sur 3 ans : (1) Activer immédiatement X25519Kyber768 sur le reverse proxy ou le CDN (Cloudflare l'a activé par défaut en 2024). (2) Migrer les certificats TLS publics vers ML-DSA dès que votre autorité de certification (Let's Encrypt, DigiCert) les supporte — prévu pour 2026-2027. (3) Remplacer AES-128 par AES-256 dans tous les chiffrements stockés. Budget estimé : principalement du temps ingénieur, pas de coût de licence si vous utilisez OpenSSL/OQS open source.

ETI (250-5000 personnes) — La priorité est d'abord l'inventaire cryptographique. Sans savoir où vous utilisez RSA/ECC, impossible de planifier la migration. Construisez un Crypto Bill of Materials : toutes les applications, tous les services, tous les protocoles utilisant de la cryptographie asymétrique. Ensuite, appliquez une priorisation par sensibilité des données et durée de confidentialité requise. Consultez notre guide cloud encryption et gestion des clés pour les bonnes pratiques de gestion du cycle de vie des clés cryptographiques.

Grande entreprise (> 5000 personnes) — La migration PQC doit être traitée comme un programme pluriannuel avec sponsorship CISO. Les jalons recommandés : Q4 2025 — inventaire crypto complet (outils : CryptoScanner, OWASP Dependency-Track). Q1-Q2 2026 — POC hybride TLS sur les périmètres exposés. 2027-2028 — migration PKI interne. 2029-2030 — dépréciation de tous les algorithmes classiques pour les données sensibles. Voir notre guide AWS Lambda Security pour la gestion de la cryptographie dans les architectures serverless.

Inventaire cryptographique — identifier tous les usages RSA/ECC

La première étape concrète de toute migration PQC est l'inventaire. Sans connaître où vos systèmes utilisent RSA, ECDH, ECDSA, DH, vous ne pouvez pas planifier. Voici comment construire un inventaire automatisé :

#!/bin/bash
# Script d'audit des certificats TLS d'une organisation
# Scanne les IPs/domaines et rapporte algorithme + date d'expiration

TARGETS_FILE="targets.txt"  # Liste de host:port, un par ligne
OUTPUT_CSV="crypto_audit_$(date +%Y%m%d).csv"

echo "host,port,issuer,not_after,sig_algorithm,pubkey_bits,pqc_ready" > "$OUTPUT_CSV"

while IFS=':' read -r host port; do
    port="${port:-443}"

    # Récupérer les infos du certificat
    CERT_INFO=$(timeout 5 openssl s_client \
        -connect "${host}:${port}" \
        -servername "$host" \
        /dev/null | \
        openssl x509 -noout -issuer -dates -text 2>/dev/null)

    if [ -z "$CERT_INFO" ]; then
        echo "${host},${port},ERROR,N/A,N/A,N/A,false" >> "$OUTPUT_CSV"
        continue
    fi

    NOT_AFTER=$(echo "$CERT_INFO" | grep 'Not After' | sed 's/.*Not After : //')
    SIG_ALGO=$(echo "$CERT_INFO" | grep 'Signature Algorithm' | head -1 | awk '{print $NF}')
    PUBKEY_BITS=$(echo "$CERT_INFO" | grep 'Public-Key:' | grep -o '[0-9]*')
    ISSUER=$(echo "$CERT_INFO" | grep 'issuer=' | sed 's/issuer=//')

    # Déterminer si PQC-ready (présence de ML-KEM ou ML-DSA dans la négociation)
    PQC_GROUP=$(timeout 5 openssl s_client \
        -connect "${host}:${port}" \
        -servername "$host" \
        /dev/null | grep "Server Temp Key" | grep -i "mlkem\|kyber")

    PQC_READY="false"
    [ -n "$PQC_GROUP" ] && PQC_READY="true"

    echo "${host},${port},${ISSUER},${NOT_AFTER},${SIG_ALGO},${PUBKEY_BITS},${PQC_READY}" >> "$OUTPUT_CSV"
    echo "[+] ${host}:${port} — ${SIG_ALGO} ${PUBKEY_BITS}bit — PQC: ${PQC_READY}"

done < "$TARGETS_FILE"

echo ""
echo "Rapport généré : $OUTPUT_CSV"
echo "Certificats RSA : $(grep -c 'rsaEncryption\|sha256WithRSAEncryption' "$OUTPUT_CSV")"
echo "Certificats ECDSA : $(grep -c 'ecdsa-with' "$OUTPUT_CSV")"
echo "Déjà PQC-ready : $(grep -c ',true$' "$OUTPUT_CSV")"

Configuration TLS 1.3 + PQC sur nginx

Une fois OpenSSL 3.x avec OQS Provider installé sur votre serveur, voici la configuration nginx recommandée pour activer les groupes hybrides :

# /etc/nginx/conf.d/pqc-tls.conf
server {
    listen 443 ssl;
    server_name exemple.com;

    ssl_certificate     /etc/ssl/certs/exemple.pem;
    ssl_certificate_key /etc/ssl/private/exemple.key;

    # TLS 1.3 uniquement — TLS 1.2 ne supporte pas les groupes PQC
    ssl_protocols TLSv1.3;

    # Groupes hybrides : X25519MLKEM768 en priorité (hybride PQC+classique)
    # X25519 comme fallback pour les clients sans support PQC
    ssl_ecdh_curve X25519MLKEM768:X25519:P-256;

    # Suites chiffrées TLS 1.3 (obligatoires, pas de choix en TLS 1.3)
    ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # HSTS — forcer HTTPS pendant 2 ans
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # OCSP Stapling pour performances
    ssl_stapling on;
    ssl_stapling_verify on;

    location / {
        proxy_pass http://backend;
    }
}

#!/usr/bin/env python3
"""
Exemple de Key Encapsulation avec liboqs-python (ML-KEM-768)
Illustre le flux KEM : génération de clés, encapsulation, décapsulation
"""
import oqs  # pip install liboqs-python

def demo_mlkem768():
    # Côté serveur : générer une paire de clés ML-KEM-768
    with oqs.KeyEncapsulation('ML-KEM-768') as kem_server:
        public_key = kem_server.generate_keypair()
        print(f"Clé publique ML-KEM-768 : {len(public_key)} octets")

        # Côté client : encapsuler un secret avec la clé publique du serveur
        with oqs.KeyEncapsulation('ML-KEM-768') as kem_client:
            ciphertext, shared_secret_client = kem_client.encap_secret(public_key)
            print(f"Ciphertext : {len(ciphertext)} octets")
            print(f"Secret partagé (client) : {shared_secret_client.hex()[:32]}...")

        # Côté serveur : décapsuler pour retrouver le même secret
        shared_secret_server = kem_server.decap_secret(ciphertext)
        print(f"Secret partagé (serveur) : {shared_secret_server.hex()[:32]}...")

        # Vérification — les deux secrets doivent être identiques
        assert shared_secret_client == shared_secret_server, "ERREUR : secrets différents !"
        print("[OK] Échange de clés ML-KEM-768 réussi — secrets identiques")

if __name__ == '__main__':
    demo_mlkem768()

Calendrier de migration NIST 2025-2035

Le NIST a publié sa feuille de route de dépréciation de la cryptographie classique. Les jalons sont clairs et non négociables pour les systèmes traitant des données gouvernementales américaines — la France et l'UE s'alignent progressivement sur ces dates :

• 2025-2026 : Finalisation des standards PQC (FIPS 203/204/205 publiés). Début des POC hybrides dans les organisations critiques. L'ANSSI publie ses recommandations finales de migration.
• 2027-2028 : Dépréciation recommandée de RSA-2048 et ECDSA P-256 pour les nouvelles implémentations gouvernementales US. Migration des systèmes à durée de vie longue (PKI, HSM, firmware).
• 2030 : Interdiction de RSA et ECC pour les systèmes gouvernementaux US classifiés. Les navigateurs commencent à marquer les sites TLS sans support PQC comme "non sécurisés".
• 2035 : Dépréciation complète de tous les algorithmes classiques pour les données sensibles. Tout système utilisant RSA, ECDSA, DH classique pour protéger des données sensibles est considéré non conforme.

Pour les organisations françaises, l'alignement sur ces dates est recommandé pour les opérateurs d'importance vitale (OIV) et les opérateurs de services essentiels (OSE) soumis à NIS 2. Notre analyse sur IA quantique et cybersécurité explore les implications plus larges du quantique sur les systèmes de détection.

Une ressource essentielle : le site officiel NIST PQC publie les mises à jour des standards, les vecteurs de test et les bibliothèques de référence.

Questions fréquentes

ML-KEM est-il compatible avec TLS 1.2 ?

Non — les groupes post-quantiques comme ML-KEM sont uniquement supportés en TLS 1.3. TLS 1.2 n'a pas la flexibilité de négociation de groupes nécessaire pour les KEM post-quantiques. Si vous avez encore des clients qui ne supportent pas TLS 1.3 (navigateurs anciens, applications legacy), vous devrez maintenir TLS 1.2 pour eux en parallèle, sans protection PQC. Cependant, en 2026, la proportion de clients TLS 1.2 uniquement est inférieure à 1% — il est raisonnable de planifier leur dépréciation complète.

Les performances de ML-KEM dégradent-elles l'expérience utilisateur ?

Dans la pratique, l'impact sur les performances est négligeable pour les utilisateurs finaux. ML-KEM-768 est plus rapide que ECDH P-256 en termes de cycles CPU pour les opérations de clé. Le seul overhead visible est la taille augmentée des messages ClientHello/ServerHello dans TLS (+1100 octets environ pour X25519MLKEM768 vs X25519 seul), ce qui peut légèrement augmenter le temps du handshake TLS sur des connexions à très haute latence. Cloudflare a mesuré un impact inférieur à 1 ms sur 99% des connexions.

Let's Encrypt supporte-t-il déjà les certificats ML-DSA ?

Pas encore en production à la date de publication de cet article (juillet 2026). Let's Encrypt travaille sur le support ML-DSA mais la complexité d'intégration avec les RFC PKIX existantes retarde le déploiement. DigiCert et Entrust proposent des certificats PQC en beta depuis mi-2025 pour les clients enterprise. L'alternative immédiate : continuer avec ECDSA P-256 pour les certificats leaf et activer uniquement X25519MLKEM768 pour l'échange de clés — c'est la configuration qui protège contre le HNDL.

Faut-il migrer SSH en priorité ?

Oui — SSH est une cible de choix pour le HNDL. Les sessions SSH d'administration système peuvent contenir des secrets critiques (clés privées, mots de passe, configurations). OpenSSH 9.4+ supporte mlkem768x25519-sha256 nativement. La migration SSH est donc gratuite, sans dépendance à OQS Provider, et peut être faite immédiatement en ajoutant deux lignes à votre sshd_config. C'est la quick win PQC la plus accessible.

La cryptographie post-quantique protège-t-elle aussi contre les attaques classiques ?

Oui — avec l'approche hybride. Un algorithme comme X25519MLKEM768 maintient la sécurité classique de X25519 contre les attaques non-quantiques actuelles. Si une vulnérabilité était découverte dans ML-KEM (hypothétique), X25519 maintient la protection. C'est précisément pourquoi l'approche hybride est recommandée pendant la transition plutôt qu'une migration brutale vers PQC seul. Pour la cryptographie symétrique (AES, ChaCha20), les algorithmes actuels restent sécurisés contre les attaques classiques — seule AES-128 doit être migré vers AES-256 pour la sécurité post-quantique.

Conclusion

La migration vers la cryptographie post-quantique est un projet d'infrastructure, pas un projet de sécurité réactive. Les standards sont prêts, les bibliothèques sont disponibles, et les navigateurs et systèmes d'exploitation commencent à activer le support PQC par défaut. Ce qui manque dans la majorité des organisations, c'est l'inventaire cryptographique et la roadmap de migration. Commencez par les quick wins sans risque — X25519MLKEM768 sur le TLS entrant, SSH avec mlkem768x25519 — et construisez progressivement votre PKI post-quantique parallèle. Les 4 ans restants avant 2030 semblent longs, mais la migration d'une PKI d'entreprise prend en général 3 à 5 ans. L'horloge tourne. Pour approfondir la gestion du chiffrement cloud, consultez notre article de fond sur la cryptographie post-quantique.