Migration post‑quantique sans drame : le plan sur 12 mois d’un CTO

Vous n’avez pas besoin d’un tableau blanc rempli de mathématiques des treillis pour prendre la bonne décision sur la cryptographie post‑quantique (PQC). Il vous faut un plan. Le PQC est passé de la recherche à votre chaîne d’outillage : GnuPG intègre le support post‑quantique en branche principale, OpenSSH livre depuis des années un échange de clés hybride PQ, et les grands clouds et CDNs ont mené des expérimentations TLS hybrides en conditions réelles. Les attaquants capturent déjà aujourd’hui du trafic chiffré pour le déchiffrer plus tard. Si vos données doivent rester confidentielles pendant 5 à 10 ans (ou plus), le compte à rebours est lancé.

Ce n’est pas du FUD. C’est un problème de séquencement. Si vous attendez que chaque HSM, carte à puce et cadre de conformité « prenne pleinement » en charge le PQC, vous raterez la fenêtre et paierez deux fois : une première pour une migration précipitée, et une seconde pour les incidents de production qui l’accompagnent. La bonne stratégie consiste à rendre votre stack crypto‑agile dès maintenant, déployer l’échange de clés hybride et la double signature là où c’est pertinent, et éviter de casser les systèmes encore coincés dans une file d’attente de validation FIPS.

Ce qui a changé en 2026

• Les algorithmes sont concrets, pas des jouets de brouillon. Le cycle du NIST s’est conclu avec des choix pour l’encapsulation de clés (ML‑KEM, dérivé de Kyber) et pour les signatures numériques (ML‑DSA issu de Dilithium ; SLH‑DSA issu de SPHINCS+ pour des cas particuliers). Les publications et profils FIPS arrivent entre 2024 et 2026.
• Le PQC est dans les outils grand public. L’arrivée du post‑quantique dans GnuPG montre que les expérimentations PGP/S/MIME sont prêtes au‑delà des builds académiques. OpenSSH livre un KEX hybride (sntrup761x25519) déployé par de grands fournisseurs. Cloudflare, Google et d’autres ont mené de vastes tests TLS 1.3 hybrides (par ex. X25519+Kyber768).
• Harvest‑now‑decrypt‑later (HNDL) est le vrai risque. AES‑256 résiste à l’accélération quadratique de Grover ; votre chiffrement symétrique est probablement OK. Votre établissement de clés et vos signatures, non. Si la confidentialité d’une session doit durer une décennie, ne comptez pas sur RSA/ECDH seuls en 2026.

Les deux décisions que vous devez réellement prendre

1. Où le PQ hybride vaut‑il aujourd’hui la peine opérationnelle ? Vos endpoints TLS publics et les accès SSH administratifs sont des paris à faible regret. Ils offrent une protection HNDL immédiate sans re‑platformer entièrement l’identité.
2. Comment gagner du temps ailleurs ? Rendez vos logiciels crypto‑agiles pour pouvoir échanger d’algorithmes sans réécrire les applications. Puis introduisez le PQ par paliers lorsque vos fournisseurs, HSM et auditeurs auront rattrapé.

Un plan sur 12 mois exécutable

Phase 0 (Semaines 0–2) : Poser les règles du jeu

• Définissez la « durée de confidentialité » par classe de données. Exemples de catégories : 0–2 ans (logs transitoires), 3–7 ans (PII/PHI utilisateurs), 8–20 ans (financiers, contrats gouvernementaux, génomique). Tout ce qui est ≥ 7 ans part sur la voie prioritaire PQ.
• Nommez une équipe DRI : 1 ingénieur sécurité, 1 SRE, 1 ingénieur plateforme. Ajoutez un TPM si vous avez une forte surface fournisseurs. Donnez‑leur un point exécutif hebdomadaire et un OKR sur 12 mois.

Phase 1 (Semaines 2–8) : Construire votre Crypto Bill of Materials (CBOM)

• Inventoriez par preuves, pas au feeling. Utilisez testssl.sh ou ztls pour scanner les endpoints TLS externes et consignez les suites d’échange de clés et de signature prises en charge. Pour la mTLS interne, ajoutez de la télémétrie Envoy/HAProxy sur les chiffrements négociés. Pour SSH, analysez sshd_config à l’échelle du parc et capturez les listes KEX côté serveur.
• Fouillez vos dépôts de code à la recherche de bibliothèques crypto (OpenSSL, BoringSSL, BouncyCastle, libsodium, fournisseurs JCE). Notez les versions. Signalez la crypto maison fragile et les chaînes de chiffrement épinglées.
• Cataloguez clés et certificats : chaînes d’AC, certificats feuilles, clés de signature JWT, certificats de signature de code, clés KMS enveloppant des DEK/KEK, clés PGP. Consignez les courbes, tailles RSA et cadences de rotation.
• Cartographiez les capacités HSM/KMS et les roadmaps éditeurs. Posez des questions ciblées : calendriers de support ML‑KEM/ML‑DSA, support TLS hybride, statut FIPS, chemins de mise à jour firmware, impacts de débit et coûts.

Phase 2 (Semaines 8–16) : Rendre la plateforme crypto‑agile

• Factorisez la crypto une fois. Si vos services appellent directement OpenSSL, introduisez une fine couche fournisseur avec négociation d’algorithmes. Dans l’écosystème JVM, configurez via des providers JCE et des propriétés plutôt que de coder en dur des suites. En Go, privilégiez tls.Config avec des CurvePreferences dynamiques et des suites chargées depuis la configuration.
• Supprimez le pinning fragile. Remplacez les ancrages explicites de type « TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 » par des noms de politique (par ex. « prod‑tls‑policy‑2026 ») résolus au démarrage depuis la configuration. Cette indirection fait la différence entre un flip de config et un redeploy.
• Activez la double signature dans les pipelines. Pour les artefacts, assurez‑vous que votre flux de signature peut joindre à la fois une signature classique et une signature PQ (par ex. cosign multi‑signature, structures JOSE/COSE, ou métadonnées détachées). Vous n’activerez peut‑être pas le PQ aujourd’hui, mais vous pourrez le faire dès que vos magasins de confiance l’autoriseront.

Phase 3 (Mois 4–6) : Déployer l’hybride là où ça paie maintenant

• TLS pour les endpoints publics : Mettez en place un domaine canari utilisant un KEX hybride X25519+Kyber768 via un CDN ou un proxy edge qui le prend en charge. Attendez‑vous à ~1–2 KB de plus sur la poignée de main et à une hausse CPU négligeable sur des processeurs modernes. Ciblez 10–20 % du trafic externe pendant 2–4 semaines, suivez les taux d’échec de handshake et le mix client. Si des middleboxes se comportent mal, revenez en arrière par SNI tout en conservant l’hybride pour les clients modernes.
• SSH pour les parcours admin : Activez sntrup761x25519-sha512@openssh.com dans OpenSSH pour l’accès du personnel. C’est du drop‑in, testé, et cela vous offre une protection PQ sur les identifiants qui comptent le plus : ceux avec un shell en prod.
• Données au repos : Vérifiez AES‑256‑GCM partout. Si un service utilise encore AES‑128 ou 3DES, corrigez‑le maintenant. Pour l’enveloppement de clés (KEK protégeant des DEK), préférez l’enveloppement local symétrique ou un KMS s’engageant publiquement à supporter un KEM PQ ; évitez les secrets à longue durée de vie enveloppés en RSA pour des données à longue durée de vie.

Phase 4 (Mois 6–9) : Étendre à l’identité et à la messagerie

• JWT et identité de service : Conservez RS256/ES256 pour l’interopérabilité, mais ajoutez la plomberie prête pour le PQ. Si vous opérez votre propre AC, pilotez une AC interne qui émet des certificats à double signature (classique + PQ) pour des clients non‑navigateurs que vous contrôlez. Pour SPIFFE/SPIRE ou un service mesh mTLS, testez un KEM PQ en staging là où c’est pris en charge.
• Chiffrement des e‑mails et des fichiers : Avec l’arrivée du support PQ dans GnuPG, créez une trousse de clés parallèle pour les rôles sensibles (juridique, finance, opérations santé) en utilisant des certificats hybrides ou uniquement PQ. Lancez un pilote en groupe fermé : 20–50 personnes, sur opt‑in, avec des mécanismes de repli. Attendez‑vous à une hausse de la taille des messages (signatures Dilithium ~2–3 KB ; SPHINCS+ encore plus grandes). Documentez la compatibilité des clients.
• Signature de code et chaîne d’approvisionnement : La plupart des magasins de confiance des OS n’acceptent pas encore les signatures PQ. Le bon mouvement aujourd’hui est la double signature : conservez votre signature classique pour ces magasins et joignez une signature PQ comme attestation supplémentaire enregistrée dans la provenance (SLSA, GUAC). Cela vous permet de vérifier en PQ en interne et de basculer en externe lorsque les magasins rattrapent.

Phase 5 (Mois 9–12) : L’inscrire dans l’exploitation et les achats

• Observabilité : Ajoutez aux dashboards la taille des handshakes TLS et des métriques d’échecs par groupe. Suivez « hybrid negotiated » comme un ratio. Fixez un SLO : moins de 0,1 % d’échecs de handshake imputables à la négociation KEX pendant les déploiements.
• Politique de rotation : Raccourcissez la durée de vie des certificats et des clés (par ex. 30–90 jours) pour rendre les changements crypto peu risqués. Concrètement, vous ferez plus de rotations, mais avec l’automatisation cela constitue une assurance peu coûteuse pour des changements d’algorithme rapides.
• Qualification fournisseurs : Mettez à jour votre questionnaire de sécurité : « Listez les KEM et schémas de signature pris en charge ; confirmez la capacité à négocier ML‑KEM/ML‑DSA ; fournissez le statut FIPS et la roadmap. » Refusez les boîtes noires qui codent les chiffrements en dur.
• Runbooks d’incident : Documentez le comportement de repli/déclassement afin qu’un ingénieur ops ne désactive pas l’hybride sur tout le site sous pression. La bonne réponse à une défaillance de middlebox est une politique ciblée par SNI ou plage IP, pas un rollback global.

Ce que ça coûte (et ce que ça économise)

• Ressources/temps : Une équipe de 3–4 personnes peut réaliser un CBOM crédible en 6–8 semaines, ajouter l’abstraction d’agilité crypto en 4–6 semaines pour le top 10 des services, et piloter le TLS/SSH hybride en 4–6 semaines supplémentaires. Soit ~3–4 mois calendaires pour commencer à protéger là où ça compte.
• Surcharge infra : Les handshakes TLS hybrides ajoutent environ 1–2 KB et un léger surcoût CPU (la décapsulation ML‑KEM est rapide sur des CPU modernes). Attendez‑vous à une hausse CPU à un chiffre faible en pourcentage sur les handshakes à l’edge. Pour la plupart des profils de trafic SaaS, c’est dans le bruit.
• Dépenses éditeurs/fournisseurs : La partie coûteuse, ce sont les mises à niveau HSM et KMS si vous exigez du PQ en matériel. Si vous pouvez tolérer une terminaison TLS hybride logicielle à l’edge pendant les 12–24 prochains mois, vous différez des capex majeurs le temps que le marché HSM mûrisse.

Compatibilité et performance : les compromis à accepter

• Des signatures et des clés plus grosses. Les ordres de grandeur comptent pour la planification : clés publiques ML‑KEM‑768 ~1,1 KB ; chiffrés ~1,1 KB. Les signatures ML‑DSA font ~2–3 KB. Les signatures SPHINCS+ peuvent faire 8–30 KB. Cela impacte l’e‑mail, les logs et la facturation de bande passante.
• Les middleboxes vont vous surprendre. Certains proxies d’entreprise et IDS rejettent des groupes TLS inconnus. D’où l’intérêt de démarrer avec un domaine canari et des politiques basées sur le SNI. N’activez pas l’hybride sur votre hostname de login principal le premier jour.
• FIPS et audits sont en retard. Les environnements régulés ont besoin de modules validés FIPS. Très bien : exécutez du PQ en pilotes contrôlés et dans des chemins de code crypto‑agiles maintenant, puis rattachez un module validé quand il arrive. Attendre le tampon avant d’écrire une ligne de code, c’est comment on finit en mode héroïque au T4.

Brazil et LatAm : réalités à prendre en compte

• Ancres de confiance : Si vous servez des clients au Brazil, suivez les orientations de l’ICP‑Brasil pour les signatures numériques utilisées en e‑facturation et marchés publics. Ne préemptez pas le programme de racines ; à la place, signez en double les artefacts et attestations internes pour être prêt lorsque des profils PQ apparaîtront.
• Paiements et fintech : Les fournisseurs PIX/Open Finance sont sensibles aux budgets de latence. Une hausse de 1–2 KB sur le handshake est généralement tolérable si vous terminez aux PoP edge de São Paulo et Rio. Mesurez le p95 du temps de handshake avant/après ; budgétez 5–10 ms de plus sur les liens congestionnés.
• Exécution nearshore : Une équipe basée au Brazil avec 6–8 heures de recouvrement avec les US peut conduire votre CBOM, l’abstraction d’agilité crypto et les canaris de trafic sans douleur de fuseaux horaires. Ce n’est pas de la R&D exotique ; c’est de l’ingénierie de plateforme robuste avec un contrôle du changement discipliné.

À ne pas faire

• Ne « faites pas bouillir l’océan ». Vous n’avez pas besoin de PQ dans chaque microservice d’ici décembre. Protégez d’abord l’ingress public et les chemins de racine de confiance.
• Ne vous enfermez pas dans un appliance sans issue. Si un fournisseur ne peut pas nommer les KEM/schémas de signature pris en charge et montrer une démo hybride fonctionnelle, il n’est pas prêt—peu importe la beauté de la fiche technique.
• Ne confondez pas agilité crypto et chaos. Centralisez la politique de chiffrement en un seul endroit, déployez avec des canaris, et observez. Vous voulez des mouvements réversibles avec un périmètre d’impact serré.

Un cadre de décision simple

Utilisez‑le pour prioriser où le PQ va en premier :

• Les données nécessitent‑elles une confidentialité ≥ 7 ans ? Oui → priorisez le PQ hybride sur le transport et l’enveloppement de clés. Non → conservez le classique pour l’instant ; assurez des chemins de code crypto‑agiles.
• Contrôlez‑vous entièrement les deux extrémités de la connexion ? Oui → allez plus vite (mTLS, service mesh, SSH). Non → utilisez des canaris sur le TLS public et mesurez la casse côté clients.
• Le chemin est‑il une racine de confiance ? Signature de code, provenance CI/CD, accès admin → implémentez tôt la double signature ou un KEX hybride, quel que soit le mix client.

Répondre aux questions des dirigeants

• « Sommes‑nous exposés aujourd’hui ? » Si vous exécutez uniquement RSA/ECDHE pour du TLS dont la confidentialité doit durer une décennie, oui—HNDL est un risque réel. Vous pouvez le réduire sensiblement en un trimestre en ajoutant un KEX hybride à l’edge.
• « Les clients vont‑ils le remarquer ? » Très probablement non. Les octets et le CPU du handshake augmentent un peu ; la latence de queue bouge de quelques millisecondes au pire. C’est bien en dessous de la variance habituelle due à la météo réseau.
• « Et si les algorithmes changeaient ? » C’est pour cela que vous implémentez l’agilité crypto. Vous ne vous tatouez pas Kyber sur le front ; vous en faites un bouton de configuration.

Pourquoi maintenant, pas plus tard

Attendre ne vous apporte pas de certitude ; cela vous apporte de la dette. Les standards sont suffisamment mûrs, les outils grand public livrent, et le coût d’un pilote est faible. Le prix de l’inaction, c’est d’expédier davantage de secrets à longue durée de vie sous crypto classique pendant que les adversaires enregistrent votre trafic. Vous pouvez obtenir 80 % du bénéfice pour 20 % de l’effort en vous concentrant sur l’ingress TLS, l’admin SSH et des logiciels crypto‑agiles. Tout le reste peut mûrir derrière cette tête de pont.

Points clés à retenir

• Démarrez par un CBOM en 6–8 semaines et rendez votre code crypto‑agile ; c’est le déverrouillage pour tout le reste.
• Déployez le TLS hybride (X25519+Kyber768) sur l’ingress public et le SSH hybride pour l’admin ; mesurez, canarisez et gardez des replis par SNI.
• Utilisez AES‑256‑GCM pour les données au repos et évitez les KEK enveloppés RSA à longue durée de vie pour des données à longue durée de vie.
• Double‑signez artefacts et provenance maintenant pour pouvoir basculer la confiance externe lorsque les magasins l’adopteront.
• Attendez‑vous à de petits coûts de performance (quelques KB et millisecondes), des signatures plus grosses, et des problèmes occasionnels de middlebox—planifiez les déploiements en conséquence.
• Traitez le PQ comme une capacité produit : observabilité, rotation, langage achats, et runbooks—pas une simple mise à niveau crypto ponctuelle.