Migration post-quantique dans l’IT d’entreprise DACH : quels actifs cryptographiques vont réellement migrer en 2026

Les standards NIST pour la cryptographie post-quantique sont finaux depuis août 2024 – ML-KEM pour l’encapsulation de clés, ML-DSA et SLH-DSA pour les signatures. Un an et demi plus tard, les premières migrations commencent à tourner en production dans les entreprises DACH. Ce texte balaie le romantisme des roadmaps et montre quels actifs cryptographiques vont réellement migrer en 2026 – et lesquels tiendront jusqu’en 2028 ou au-delà.

En lienCloud Repatriation 2026 : le modèle TCO  /  Platform Engineering 2026 : Internal Developer Platforms

L’état des lieux en avril 2026

ML-KEM (anciennement CRYSTALS-Kyber), ML-DSA (anciennement CRYSTALS-Dilithium) et SLH-DSA (anciennement SPHINCS+) sont, en tant que FIPS 203, 204 et 205, des standards fédéraux américains finaux depuis août 2024. En parallèle, le BSI travaille à des mises à jour de la série TR-02102 qui contiendront en 2026 les premières recommandations d’action contraignantes pour les autorités fédérales et les exploitants KRITIS. Il n’existe pas en Allemagne de migration obligatoire avec une date butoir stricte – mais les questions d’audit deviennent concrètes.

Dans les audits de sécurité chez les banques et les assureurs, deux questions apparaissent systématiquement depuis le T1 2026. Premièrement : quels de vos systèmes utilisent aujourd’hui des procédés crypto considérés comme « sensibles au quantique » ? Deuxièmement : quelle roadmap de migration avez-vous documentée jusqu’en 2028 ? Les réponses qui circulent dans la plupart des entreprises sont nettement plus minces que ce que les slides laissent penser.

Qui commence en 2026 une migration post-quantique le fait rarement de plein gré. Le déclencheur est presque toujours une question de conformité, un audit fournisseur ou un cycle d’attestation C5 où l’auditeur interroge explicitement sur la PQC-readiness. La « prévoyance » classique, en tant que projet autonome, est rarement éligible au budget – la PQC est entraînée dans de plus larges chantiers d’hygiène cryptographique.

Le secteur bancaire joue dans ce mouvement un rôle particulier. BaFin et BCE ont clairement indiqué début 2026, via plusieurs lettres circulaires, que la readiness post-quantique doit figurer dans les évaluations de risque opérationnel – non comme obligation avec date butoir, mais comme catégorie soumise à documentation. Cela conduit les IT bancaires à accélérer la constitution d’inventaires, à un rythme dont les autres secteurs n’ont pas besoin. Les assureurs suivent au T2 2026, les énergéticiens et les KRITIS santé sont de toute façon dans le viseur via la loi BSI révisée.

L’industrie, en revanche, travaille avec un horizon plus long. Ici, les directions IT négocient avec les équipes OT, les constructeurs de machines et les fournisseurs de systèmes de commande – une chaîne qui ne bouge qu’au rythme des cycles d’investissement. Un équipementier automobile qui planifie de nouvelles lignes de production inscrit aujourd’hui du matériel PQC-compatible dans les cahiers des charges, mais l’environnement de fabrication existant reste en place jusqu’en 2028 ou au-delà.

Quels actifs vont réellement migrer en 2026

La réalité de la migration suit trois clusters : ce qui tourne déjà en production, ce qui est en cours de migration et ce qui reste stable. La classification se base sur des observations de projets en environnement entreprise entre le T4 2025 et le T1 2026 – groupes bancaires, deux industriels du DAX et trois grosses ETI.

Le progrès le plus net se joue sur la terminaison TLS des points publics. Google a activé dès 2024 dans Chrome le groupe hybride X25519+Kyber768, Firefox a suivi en 2025. Côté serveur, Cloudflare, Akamai et les grands load balancers prennent en charge le handshake de manière transparente – qui exploite aujourd’hui un reverse proxy moderne fait du PQC-TLS sans rien activer. La partie intéressante n’est pas le handshake lui-même, mais la question de savoir quels services internes derrière le proxy ont seulement remarqué cette refonte.

Le code-signing est le deuxième terrain où quelque chose bouge en 2026. Microsoft teste des signatures ML-DSA pour les catalogues de drivers Windows, Sigstore expérimente des chaînes de signatures hybrides. Pour les logiciels d’entreprise : qui déploie ses propres signatures produit (publication en app store ou pipelines de déploiement internes) a en 2026 un moment pertinent pour basculer, parce que les bibliothèques de vérification sont largement disponibles côté consommateur. Pour les signatures firmware avec hardware root of trust, le sujet reste en salle d’attente jusqu’en 2027 au minimum.

Le motif est cohérent. Là où la crypto est remplaçable côté logiciel et entraînée dans le cycle de mise à jour, la migration tourne en 2026. Là où matériel, firmware ou longue validité sont en jeu, il ne se passe pas grand-chose jusqu’en 2028 – ou la migration a lieu lors du prochain remplacement d’équipement, pas comme projet à part.

Ce qui coince dans les roadmaps

Quasiment chaque roadmap post-quantique écrite en 2025 a une ou plusieurs des trois faiblesses suivantes. Premièrement, elles surestiment la vitesse à laquelle les bibliothèques et les certifications suivent. OpenSSL 3.5 avec ML-KEM natif est disponible depuis le T1 2026 – mais les middlewares d’entreprise, les bases de données et les terminaisons TLS plus anciennes utilisent souvent des versions OpenSSL nettement plus anciennes. Jusqu’à ce que le support PQC ait traversé l’ensemble du graphe de dépendances d’un environnement de production, il faut 12 à 24 mois.

Deuxièmement, les roadmaps sous-estiment la gestion des certificats pour les structures trust parallèles. Qui planifie une Root-CA PQC en plus de la Root-CA existante doit penser la mécanique de déploiement pour les trust stores des navigateurs, les systèmes internes et les PKI partenaires. Ce n’est pas une question de crypto, c’est de la gestion d’identité et de cycle de vie des certificats – un domaine que la plupart des entreprises exploitent déjà aujourd’hui avec beaucoup de peine.

La vraie menace quantique pour une entreprise DACH typique ne se trouve pas dans un ordinateur quantique crypto-pertinent en 2030 – mais dans la question opérationnelle de savoir qui, dans les 36 prochains mois, remet suffisamment d’ordre dans l’hygiène PKI pour qu’une migration soit seulement possible.

Troisièmement, de nombreuses roadmaps ignorent la dimension supply chain. Les logiciels tiers, en particulier les SaaS d’entreprise avec handshake TLS géré par l’éditeur, échappent au contrôle direct. Qui demande aujourd’hui à Salesforce, Microsoft 365 ou HubSpot quand leur terminaison TLS bascule sur PQC hybride reçoit typiquement une annonce de roadmap sans date. Ce n’est pas de la négligence, mais une évaluation réaliste de leurs propres dépendances.

Un détail qui se remarque souvent tard dans les projets : les coûts de performance des handshakes TLS hybrides sont réels, mais dans la plupart des scénarios négligeables. ML-KEM-768 en procédé hybride ajoute environ un à deux kilo-octets au Client Hello et allonge le handshake de quelques millisecondes. Pour un HTTPS orienté utilisateur, ce n’est pas perceptible. Cela devient sérieux sur les pipelines mTLS à haute fréquence où chaque connexion est rétablie – là, ces quelques millisecondes peuvent devenir un écueil, en particulier dans les service meshes avec des timeouts de session courts. D’où l’intérêt, avant le rollout, d’un benchmark sur sa propre route mTLS avant que les latences de production ne deviennent une surprise.

Deuxième point rarement mentionné dans les roadmaps : les intégrations KMIP et les templates de certificats dans les logiciels PKI existants ne sont généralement pas PQC-ready. Qui exploite Microsoft Certificate Services, Dogtag, EJBCA ou des produits CA d’entreprise commerciaux doit vérifier la version – les signatures PQC n’apparaissent que dans les cycles produit récents. La migration du stack PKI est un projet de taille moyenne à part entière, en plus du pur changement d’algorithme.

Ce qu’il faut concrètement faire en 2026

Les entreprises qui abordent sérieusement leurs devoirs PQC cette année suivent un schéma peu spectaculaire. Elles commencent par un inventaire cryptographique – non comme document théorique, mais comme scan exécutable à travers SBOM CycloneDX, outils d’inventaire TLS et contrôle manuel de tous les procédés de signature dans leur propre pipeline CI/CD. L’inventaire est la base de tout le reste et prend à lui seul trois à quatre mois.

En parallèle, les upgrades de bibliothèques sont embarqués dans les releases de plateforme régulières. OpenSSL 3.5+, versions actuelles de LibreSSL ou BoringSSL, stacks TLS Java avec support PQC, paquets Go-crypto. Qui planifie l’upgrade comme projet à part le rate – qui le couple au cycle de patch régulier le mène à terme en six à neuf mois.

L’inventaire cryptographique est en pratique la partie la plus pénible. Les outils d’inventaire TLS comme testssl.sh, sslyze ou les scanners commerciaux tels que Venafi livrent une première carte des endpoints publics. Mais les questions d’inventaire surgissent à des endroits qu’aucun scanner ne trouve automatiquement : quelle couche messaging signe avec quelle clé ? Quelles interfaces de modules ERP utilisent quelles cipher suites ? Quelles clés de signature JWT tournent à quel rythme et sont vérifiées par quelles bibliothèques ? Ces questions se traitent en plusieurs itérations à travers plusieurs équipes – elles ne se règlent pas en un sprint.

La troisième colonne est la conversation fournisseurs. Qui exploite du logiciel dans le cloud devrait en 2026 demander explicitement à ses trois principaux fournisseurs SaaS quand leur terminaison TLS bascule sur PQC hybride et quand leurs infrastructures de signature internes prendront en charge les procédés PQC. Les réponses sont rarement précises, mais elles marquent les dépendances à documenter comme risques résiduels dans ses propres roadmaps. Un bon schéma : point annuel PQC dans les supplier-review meetings, documenté dans le vendor risk register à côté des sujets RGPD et NIS2.

Enfin, le volet communication en fait partie. Les directions générales à qui un auditeur ou une autorité de supervision demandera en 2027 l’état PQC ont besoin d’un rapport sobre – pas d’un document glacé. Un aperçu d’une page avec trois chiffres (part des endpoints TLS migrés, statut du code-signing, dépendances supply chain documentées) bat tout concept de quarante pages que personne ne lit.

La feuille de route jusqu’en 2028

Calendrier réaliste du point de vue projet – non comme prescription, mais comme orientation pour les CIO qui doivent rendre plausible auprès de la direction et des auditeurs pourquoi telle étape arrive à tel moment.

Ce qui reste – et ce qui ne reste pas

L’attente selon laquelle la cryptographie post-quantique tournera en production partout d’ici 2027 est irréaliste. L’attente qu’il ne se passera rien l’est tout autant. 2026 est l’année où le TLS hybride se généralise sur le web public, où les projets de code-signing démarrent sérieusement et où les inventaires cryptographiques se construisent. La vraie migration des cas durs – Root-CAs, clés liées aux HSM, firmware embarqué – s’étale jusqu’à la fin de la décennie.

Pour les CIO et les Security Leads, la question opérationnelle pertinente n’est pas de savoir où en sont les ordinateurs quantiques. Elle est de savoir quelle hygiène cryptographique survit au prochain audit dans leur maison et quels devoirs doivent être traités maintenant pour que la migration dans trois ans soit simplement réalisable. Qui dispose aujourd’hui d’un inventaire crypto propre et maintient ses bibliothèques à jour a fait 70 pour cent de la préparation post-quantique – sans faire tourner un seul procédé PQC en production.

Questions fréquentes

Dois-je déjà déployer du PQC en production en 2026 ?

Non, sauf dans des contextes spécifiques avec des clés à longue validité ou une exigence de conformité claire. Pour la plupart des entreprises DACH, 2026 est l’année où le TLS hybride devient largement disponible et où les inventaires cryptographiques se construisent. La migration PQC pure est l’exception, pas la règle.

Quelles bibliothèques supportent le PQC en production aujourd’hui ?

OpenSSL 3.5 (mars 2025) avec ML-KEM natif en TLS 1.3, BoringSSL (Chrome, Edge), Mozilla NSS (Firefox) depuis 2025 avec hybride X25519+ML-KEM. Sigstore teste ML-DSA pour le code-signing. Java supporte le PQC à partir d’OpenJDK 24 à titre expérimental. Pour l’embarqué, wolfSSL et mbedTLS avec des branches PQC sont disponibles.

Quel est le coût d’une migration post-quantique pour un grand compte moyen ?

Les chiffres sérieux sont rares, car la migration est intégrée au cycle de patch plateforme et rarement facturée comme projet à part. L’effort séparé pour l’inventaire crypto, le refactoring PKI et la gestion des trust stores se situe pour une entreprise de 1000 collaborateurs, d’expérience, dans la fourchette médiane à six chiffres répartie sur trois ans – moins que la plupart des mises en œuvre NIS2.

« Harvest-Now-Decrypt-Later » est-il un modèle de menace réaliste ?

Pour les secrets d’État, les contrats à longue validité et les données d’identité exploitables sur dix ans : oui. Pour les données d’affaires classiques à courte demi-vie opérationnelle : plutôt non. La BSI-TR-02102 différencie en conséquence. Qui chiffre aujourd’hui du trafic TLS qui n’aura plus de valeur dans cinq ans n’a pas besoin du post-quantique comme prévoyance.

Quel rôle joue la BSI-TR-02102 pour les entreprises non-KRITIS ?

Formellement aucun caractère obligatoire. En pratique, la TR-02102 est le cadre de référence auquel se rapportent auditeurs, assureurs et partenaires contractuels. Qui participe à des appels d’offres ou souscrit à des cyber-assurances est de plus en plus interrogé sur la conformité TR-02102 – même au-delà de l’obligation formelle.

Source image de couverture : Pexels / Markus Spiske (px:1089438)