SaaSFort Ce qui frappe avec le TLS post-quantique en 2026, c’est que le côté client est terminé. Chrome, Firefox et Edge livrent le groupe hybride X25519MLKEM768 par défaut depuis leur version 131. Environ dix-neuf handshakes TLS post-quantiques sur vingt l’utilisent.
Le côté serveur, lui, n’est pas terminé. Le support côté origine était mesuré autour de dix pour cent en 2026, en hausse d’environ un facteur dix sur un an après qu’Akamai l’a activé par défaut pour les connexions vers l’origine en janvier.
Cet écart est toute l’histoire. Les navigateurs de vos visiteurs réclament un accord de clés résistant au quantique. La plupart des serveurs déclinent.
Ce qui est réellement protégé
L’échange de clés post-quantique ne vous protège pas d’une attaque qui a lieu aujourd’hui. Il vous protège d’une attaque qui aura lieu plus tard contre du trafic capturé aujourd’hui.
La menace porte un nom : harvest now, decrypt later. Un adversaire disposant du budget nécessaire enregistre le trafic chiffré, le stocke, et attend. Les clés de session protégeant ce trafic ont été convenues par Diffie-Hellman sur courbes elliptiques, qu’un ordinateur quantique suffisamment capable casse rétroactivement. Tout ce qui a été enregistré devient alors lisible, y compris ce qui l’a été des années plus tôt.
La question pertinente pour un éditeur SaaS n’est donc pas « l’informatique quantique est-elle arrivée » mais « combien de temps les données qui traversent cette connexion restent-elles sensibles ». Pour des jetons d’authentification, quelques heures. Pour des dossiers clients, des données de santé, des positions financières ou des documents juridiques, des décennies.
Ce qu’est X25519MLKEM768
Un hybride : le Diffie-Hellman classique sur courbe X25519 combiné à ML-KEM-768, le mécanisme d’encapsulation de clés à base de réseaux euclidiens normalisé par le NIST. Point de code IANA 4588, soit 0x11ec.
Le caractère hybride est essentiel. La session reste sûre si l’un des deux composants tient. Si ML-KEM se révélait faible, X25519 vous protège encore, et réciproquement. C’est pourquoi l’ETSI et le cadre EUCC recommandent le déploiement hybride au moins jusqu’en 2028 et considèrent les déploiements purement post-quantiques comme prématurés.
Deux variantes existent pour d’autres niveaux de sécurité et pour les environnements FIPS : SecP256r1MLKEM768 et SecP384r1MLKEM1024.
L’activer
Le changement est une ligne de configuration serveur, pas un projet d’architecture. Avec OpenSSL 3.5 derrière Nginx :
ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;
L’ordre est délibéré. En TLS 1.3, le client envoie ses parts de clé d’emblée. S’il a proposé une part pour votre groupe préféré, le handshake se termine en un aller-retour. Sinon, le serveur émet un HelloRetryRequest et le handshake coûte un aller-retour supplémentaire.
Comme pratiquement tous les navigateurs actuels proposent déjà une part X25519MLKEM768, le placer en tête est le chemin rapide pour la majorité et un repli pour les autres. Les clients sans support négocient X25519 exactement comme avant, sans modification côté client et sans rupture de compatibilité.
Pour un déploiement progressif sur des points d’entrée sensibles à la latence, gardez X25519 en tête et ajoutez simplement l’hybride à la liste, puis réordonnez une fois la mesure faite.
La réserve FIPS à connaître
ML-KEM est approuvé FIPS. X25519 ne l’est pas. L’hybride strictement conforme FIPS est donc SecP256r1MLKEM768, que Chrome ne livre pas par défaut. Si vous opérez sous contrainte FIPS, vous préférerez P256MLKEM768 en acceptant que la plupart des navigateurs ne l’utiliseront pas.
Il existe aussi un défaut ouvert côté Go si vous terminez TLS en Go : en mode fips140=only, le runtime rejette inconditionnellement crypto/ecdh.X25519, ce qui casse les handshakes hybrides alors même que le groupe figure sur la liste des courbes approuvées.
Ce que cela ne résout pas
L’échange de clés hybride protège la confidentialité de la session. Il ne fait rien pour l’authentification : votre certificat reste signé en RSA ou ECDSA, et ces signatures restent classiques.
Cela compte moins qu’il n’y paraît. Une signature forgée doit être produite pendant une connexion active pour être utile, donc il n’existe pas d’équivalent harvest-now pour l’authentification. La migration de la chaîne de certification est un problème ultérieur, et ce n’est pas un problème que vous pouvez résoudre unilatéralement aujourd’hui.
Où cela se mappe en conformité
- NIS2 article 21(2)(h), cryptographie et chiffrement. Les auditeurs interrogent de plus en plus l’agilité cryptographique, c’est-à-dire votre capacité à changer d’algorithme sans réarchitecturer.
- ISO/IEC 27001:2022 A.8.24, usage de la cryptographie.
- DORA article 9, pour les entités financières, où les durées de conservation sont longues et où l’argument harvest-now est le plus fort.
Comment le vérifier
openssl s_client -connect votredomaine.fr:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i "negotiated\|Cipher"
Un handshake réussi prouve le support. Un échec ne prouve rien à lui seul, car l’hôte peut simplement être injoignable : c’est pourquoi toute vérification honnête refait le handshake sans restriction avant de conclure quoi que ce soit.
C’est ainsi que fonctionne le contrôle SaaSFort : il tente un handshake restreint au groupe hybride et, en cas d’échec, confirme que le serveur répond bien en TLS avant de rapporter l’absence. Le résultat est rapporté en information et non en échec, car en 2026 ne pas proposer l’échange de clés post-quantique est une exposition à effet différé, pas une erreur de configuration.
En résumé
Une ligne de configuration. Aucune modification client. Aucun risque de compatibilité, le repli étant automatique.
La raison de le faire maintenant plutôt qu’en 2028 est que les données enregistrées aujourd’hui le sont aujourd’hui. Vous ne pouvez pas les chiffrer rétroactivement.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.