Cryptographie post-quantique : Let's Encrypt met en œuvre les Merkle Tree Certificates

Le 3 juin 2026, Let's Encrypt a annoncé comment elle rendra la couche d'authentification du web résistante au quantique. Le plan repose sur une nouvelle conception appelée Merkle Tree Certificates. Les détails techniques sont intéressants, mais le message concret pour quiconque gère des certificats est plus simple : la couche des certificats est sur le point de changer sous vos pieds, et l'ampleur de la douleur dépendra des choix que vous faites dès maintenant.

Voici ce qui s'est passé et ce que cela signifie.

La menace quantique s'est déplacée vers l'authentification des identités

Pendant des années, les travaux post-quantiques se sont concentrés sur le chiffrement. La logique : un attaquant enregistre aujourd'hui votre trafic chiffré et le déchiffre plus tard, une fois les ordinateurs quantiques prêts. Récolter maintenant, déchiffrer plus tard.

L'authentification, la partie de TLS qui prouve qu'un serveur est bien celui qu'il prétend être, était considérée comme moins urgente, car falsifier une signature exige qu'un ordinateur quantique existe au moment de l'attaque, et non des années plus tard.

Cela a changé rapidement en 2026. En mars, Google s'est engagé à migrer l'ensemble de son infrastructure vers la cryptographie post-quantique d'ici 2029, un an plus tôt que prévu, en s'appuyant sur des travaux qui abaissaient le coût estimé pour casser les algorithmes actuels. De nouvelles estimations situent le coût pour casser la courbe P-256 à environ 10 000 qubits, bien moins que ce que le domaine supposait. En deux semaines, Cloudflare s'est aligné sur l'objectif de 2029 et a placé l'authentification en priorité. Leur formulation était sans détour : une fuite de données est grave, mais une identité falsifiée est catastrophique, car une seule clé vulnérable au quantique devient une porte d'entrée.

Quand les deux entreprises qui traitent une large part du trafic Internet choisissent la même année, cette année devient une échéance.

Pourquoi le web ne peut pas se contenter de changer d'algorithmes

Les schémas de signature post-quantiques normalisés par le NIST sont sûrs mais volumineux. C'est un vrai problème pour TLS.

Une poignée de main TLS typique transporte cinq signatures et deux clés publiques. Remplacez-les par leurs équivalents post-quantiques et la poignée de main dépasse les 10 Ko. Les travaux de Cloudflare montrent qu'à cette taille, une part significative des connexions échoue purement et simplement sur les réseaux réels, et que le reste ralentit.

Le coût touche chaque connexion, pas uniquement les échecs. Plus de données, une négociation plus lente, une expérience dégradée, en échange d'une protection contre une menace qui n'est pas encore arrivée. Et les valeurs par défaut déterminent la sécurité à grande échelle : un changement qui dégrade chaque connexion est un changement auquel le web résiste. Voilà pourquoi l'authentification post-quantique est bien plus difficile à déployer que le chiffrement post-quantique.

Ce que font les Merkle Tree Certificates

Les Merkle Tree Certificates résolvent le problème de taille en changeant la manière dont les certificats sont signés.

Aujourd'hui, une autorité de certification signe chaque certificat individuellement. Une autorité MTC signe les certificats par lots, une signature par lot. Les navigateurs suivent ces signatures de lots (appelées landmarks) séparément de la poignée de main. Résultat : dans le cas courant, l'authentification à l'intérieur d'une poignée de main se réduit à une signature, une clé publique et une courte preuve. C'est plus petit que ce que le web transporte aujourd'hui, même avec des algorithmes post-quantiques. Lorsque le landmark d'un navigateur est périmé, il bascule vers une forme légèrement plus volumineuse.

Il y a un second bénéfice. Comme chaque certificat MTC doit appartenir à un arbre de Merkle publié pour exister, la Certificate Transparency cesse d'être ajoutée après coup et devient partie intégrante de l'émission elle-même.

Ce n'est pas théorique. Let's Encrypt exploite la même structure d'arbre de Merkle en ajout seul pour ses journaux de transparence depuis 2019. Cloudflare et Chrome testent les MTC sur du trafic réel, le groupe PLANTS de l'IETF les normalise, et Chrome en a fait sa voie privilégiée. Let's Encrypt vise un environnement de préproduction fin 2026 et une mise en production en 2027.

La phrase la plus importante de l'annonce

La phrase la plus importante du billet de Let's Encrypt passe presque inaperçue. Prendre en charge les MTC, notent-ils, implique des changements dans l'ensemble de leur pile : l'émission, le protocole ACME qu'utilisent les abonnés, la révocation, l'outillage opérationnel et les journaux de transparence.

C'est là la vraie leçon. Le nouvel algorithme est la partie visible. La tuyauterie qui le délivre en est la plus grande partie, et c'est là que la transition se gagne ou se perd.

La question qui compte donc pour votre organisation n'est pas quel algorithme post-quantique vos certificats utiliseront. C'est celle-ci : lorsque les algorithmes et les formats changeront sous vos pieds, combien de travail manuel faudra-t-il pour suivre le rythme ?

• Si les certificats sont obtenus et renouvelés automatiquement via ACME, le changement est en grande partie absorbé par une mécanique déjà en place.
• S'ils vivent dans des tableurs et sont renouvelés à la main, vous héritez de tout le poids du changement, un certificat à la fois, au moment où l'industrie avance à son rythme le plus rapide.

Les commentaires sur les annonces de Google et Cloudflare répètent le même constat : la plupart des organisations manquent de visibilité sur les endroits où réside la cryptographie, n'ont pas identifié leurs données sensibles à longue durée de vie, et n'ont aucune crypto-agilité intégrée. Sans ces fondamentaux, aucune échéance n'est atteignable.

Ce qu'il faut réellement faire maintenant

Deux choses, dans l'ordre.

Activez le chiffrement post-quantique dès aujourd'hui. Contrairement à l'authentification, il est prêt. Toute connexion TLS qui en est dépourvue est potentiellement en train d'être récoltée en ce moment même. Activez l'échange de clés hybride post-quantique (X25519MLKEM768) sur le serveur. Les navigateurs et systèmes d'exploitation modernes le prennent déjà en charge. Il ne nécessite la coopération de personne d'autre.

Rendez votre parc de certificats automatisé et visible. Tout, dans la transition MTC, récompense un parc déjà découvert, automatisé et agile, et pénalise celui qui ne l'est pas.

C'est là qu'intervient Evertrust CLM. Il fonctionne comme un proxy ACME (le même protocole RFC 8555 qu'utilise Let's Encrypt) et se connecte déjà aux autorités publiques, dont Let's Encrypt, si bien qu'il parle le canal par lequel arriveront les certificats post-quantiques. Il découvre les certificats à travers tout votre parc, y compris ceux qu'aucun scan réseau ne trouve. Il émet déjà les algorithmes post-quantiques au cœur de ce changement, ayant ajouté le support de ML-DSA et SLH-DSA en 2025, ainsi que les certificats hybrides. Et il renouvelle et réinstalle automatiquement, sans le travail manuel qui rend pénible un changement cryptographique profond. En tant que plateforme européenne avec hébergement des données dans l'UE et certification ANSSI CSPN, il maintient ce parc sous contrôle européen tout au long de la transition.

À retenir

Le titre parle d'un nouveau format de certificat. La vraie histoire, c'est la manière dont un changement de sécurité générationnel se produit réellement : des années de travail discret sous une surface qui semble à peine bouger. Les autorités de certification font leur part. Que ce basculement vous parvienne comme une mise à jour en douceur ou comme une course contre la montre se décide en grande partie maintenant, selon la part de votre parc de certificats qui est automatisée, visible et agile, bien avant l'émission du premier certificat post-quantique.