Chiffrement post-quantique et votre site web: un contrôle pratique
Où le chiffrement post-quantique touche-t-il votre site web? Un contrôle TLS 1.3 calme et pratique pour un site d'entreprise, sans alarmisme ni jargon.
Équipe rabbitclipPublié: 6 min de lecture
En bref
Le chiffrement post-quantique est le nom donné à de nouvelles méthodes conçues au cas où des ordinateurs quantiques casseraient un jour le chiffrement actuel. Pour un site d'entreprise, cela ne signifie pas un gros chantier mais un contrôle: TLS 1.3 est-il activé? Si c'est le cas et que le navigateur du visiteur le prend en charge, l'échange de clés post-quantique s'active souvent tout seul, sans rien faire de plus de votre part. Pour un site derrière Cloudflare, c'est exactement ainsi que cela fonctionne.
D'après l'article de Cloudflare du 29 septembre 2026, le côté navigateur s'est déjà largement répandu; ce qui reste se trouve côté serveur. La question n'est donc pas de savoir s'il faut prévoir un budget pour préparer l'avenir, mais si votre configuration actuelle fait obstacle à cette prise en charge.
Vous trouverez ci-dessous où le chiffrement post-quantique touche votre site, les chiffres publiés par Cloudflare, comment vérifier, les erreurs les plus fréquentes et les cas où vous n'avez pas à y consacrer de temps du tout.
Où le chiffrement post-quantique touche-t-il un site web?
Quand un visiteur se connecte à votre site en https, le navigateur et le serveur s'accordent d'abord sur une clé secrète commune; c'est ce qu'on appelle l'échange de clés. Le chiffrement post-quantique vise cette étape. La méthode décrite dans l'article de Cloudflare est hybride: la méthode actuelle X25519 fonctionne avec la nouvelle méthode ML-KEM (X25519MLKEM768). Si l'une se révèle inopinément faible, l'autre tient toujours.
Cela ne change ni votre contenu, ni vos pages, ni votre base de données. Ce qui change, c'est la manière dont s'effectue la poignée de main entre navigateur et serveur. C'est donc moins un travail de conception web ou de logiciel qu'une question de réglages d'infrastructure.
Que montrent les chiffres de Cloudflare?
L'article de Cloudflare du 29 septembre 2026, qui s'appuie sur les données de Cloudflare Radar, indique qu'environ 70 pour cent du trafic des navigateurs utilise l'échange de clés hybride ML-KEM. Pour les serveurs d'origine auxquels Cloudflare se connecte, c'est-à-dire les machines où le site est réellement hébergé, la part est d'environ 15 pour cent.
Cet écart dit quelque chose de pratique: le côté visiteur est en grande partie prêt, le côté serveur pas encore. Les chiffres concernent le trafic propre de Cloudflare; ils ne reflètent ni la Turquie ni votre propre site. Ils montrent tout de même où se situe le maillon manquant.
- Environ 70 pour cent du trafic des navigateurs utilise ML-KEM hybride
- Seulement environ 15 pour cent des serveurs d'origine le font
- Les chiffres décrivent le réseau propre de Cloudflare, pas tous les sites
Comment faire un contrôle pratique de votre site?
Si vous utilisez Cloudflare, le premier endroit à regarder est le réglage Edge Certificates sous SSL/TLS; TLS 1.3 doit être activé. D'après l'article de Cloudflare, si le navigateur du visiteur le prend en charge, Cloudflare choisit lui-même l'échange de clés post-quantique, et il n'existe pas de réglage distinct pour cela.
Il y a deux façons de voir ce qui se passe réellement. L'onglet Security des Chrome DevTools affiche l'algorithme d'échange de clés d'une connexion. Côté Cloudflare, une nouvelle carte TLS Key Exchange Groups est apparue dans HTTP Traffic Analytics, ainsi que les champs ClientTLSKeyExchangeGroup et OriginTLSKeyExchangeGroup dans Logpush et Log Explorer. Si vous n'utilisez pas Cloudflare, vous pouvez examiner l'état général de sécurité de votre site avec le contrôle de sécurité de rabbitclip.
- TLS 1.3 est-il activé sous SSL/TLS, Edge Certificates
- L'onglet Security des Chrome DevTools montre-t-il l'échange de clés
- La carte TLS Key Exchange Groups dans HTTP Traffic Analytics
- Les champs ClientTLSKeyExchangeGroup et OriginTLSKeyExchangeGroup dans Logpush et Log Explorer
- Demander à votre hébergeur si le serveur prend en charge TLS 1.3
Et si le serveur d'origine ne le prend pas en charge?
La recommandation de Cloudflare, si votre serveur d'origine ne prend pas en charge cet échange de clés, est d'utiliser Cloudflare Tunnel. Le tunnel établit la connexion entre Cloudflare et votre serveur. Pour la mise en place détaillée, il faut la documentation de Cloudflare; nous ne relayons ici que la recommandation citée dans l'article.
Il y a aussi du mouvement du côté des certificats. Le 29 septembre 2026, Cloudflare a exposé un plan d'autorité de certification post-quantique fondée sur les Merkle Tree Certificates et a écrit qu'elle délivrerait des certificats gratuits. Le 1er octobre 2026, elle a annoncé la prise en charge native de Web Crypto pour ML-KEM et ML-DSA dans Workers, en option. Ce sont un plan et une fonction pour développeurs; ne les considérez pas comme du travail à faire aujourd'hui sur un site d'entreprise.
Quelles erreurs sont fréquentes ici?
L'erreur la plus courante est soit d'ignorer complètement le sujet, soit de paniquer et d'acheter un conseil coûteux. Ni l'un ni l'autre n'est nécessaire. La troisième est de ne pas se souvenir d'un réglage qui a désactivé TLS 1.3 il y a des années, peut-être à la suite d'une ancienne consigne de sécurité.
Une autre est de confondre le chiffrement post-quantique avec le renouvellement du certificat. L'expiration de votre certificat est une affaire distincte, et le chiffrement post-quantique n'y change rien aujourd'hui.
- L'ignorer ou paniquer à ce sujet
- Acheter un conseil coûteux
- Ne pas remarquer un réglage TLS 1.3 désactivé depuis des années
- Confondre le renouvellement du certificat et l'échange de clés
Quand ce travail est-il inutile ou mal choisi?
Si votre site n'est pas derrière Cloudflare ou un réseau semblable et que son panneau de contrôle n'existe que chez votre hébergeur, la première étape est de poser la question à cette entreprise; n'allez pas toucher seul aux réglages du serveur. Pour un site vitrine avec très peu de visiteurs et sans données sensibles, y passer des heures serait aussi une mauvaise priorité.
Cloudflare écrit viser 2029 pour une sécurité post-quantique complète et renvoie à une proposition du NIST de retirer RSA et ECC d'ici 2030. Ces dates sont le récit de Cloudflare et une proposition, pas un calendrier arrêté. Un contrôle posé suffit pour aujourd'hui.
En bref: assurez-vous que TLS 1.3 est activé, interrogez votre hébergeur sur votre serveur d'origine et ne paniquez pas pour le reste. Le côté visiteur est en grande partie prêt; le maillon manquant se trouve surtout côté serveur. Si vous souhaitez passer en revue ensemble vos réglages d'infrastructure, nous serons heureux d'avoir avec vous une conversation de découverte posée chez rabbitclip.
Questions fréquentes
Dois-je installer quelque chose sur mon site pour le chiffrement post-quantique?
Derrière Cloudflare, en général non. D'après l'article de Cloudflare, si TLS 1.3 est activé et que le navigateur du visiteur le prend en charge, Cloudflare choisit lui-même l'échange de clés post-quantique. Il n'y a pas de réglage distinct.
Comment savoir si TLS 1.3 est activé?
Dans Cloudflare, regardez sous Edge Certificates dans la section SSL/TLS. Si vous n'utilisez pas Cloudflare, demandez à votre hébergeur. L'onglet Security des Chrome DevTools montre aussi les détails d'une connexion.
Qu'est-ce que ML-KEM?
C'est une méthode d'échange de clés pour l'ère post-quantique. Dans la forme hybride décrite par Cloudflare, elle fonctionne avec la méthode actuelle X25519, et la combinaison s'écrit X25519MLKEM768.
Est-ce une urgence?
L'article de Cloudflare ne décrit pas une urgence; il décrit de la visibilité et de la préparation. L'étape raisonnable pour un site d'entreprise est de vérifier TLS 1.3 et de s'informer de l'état du serveur d'origine.
Sources
Les informations concrètes de cet article s'appuient sur ces pages officielles ; vérifiez-y la situation actuelle.
