Migrer une PKI vers le post-quantique sans casser un seul client existant : voilà le vrai problème. Deux familles de solutions s'affrontent — le certificat hybride (deux certificats en parallèle) et le certificat composite (deux algorithmes dans un seul certificat). Elles se ressemblent, on les confond partout, et pourtant elles ne répondent pas au même besoin. Ce guide tranche.
Le problème : deux mondes cryptographiques à faire cohabiter
La cryptographie post-quantique n'arrive pas dans un monde vierge. Elle arrive dans des systèmes d'information peuplés de serveurs, d'équipements réseau, d'applications métier, de terminaux IoT et de middlewares dont certains ont dix ans d'âge — et qui, tous, ne comprennent aujourd'hui que RSA et ECDSA.
Basculer d'un coup vers un algorithme post-quantique comme ML-DSA (le standard de signature issu du processus NIST) reviendrait à couper la confiance avec tout ce parc existant : un client qui ne connaît pas l'algorithme ne peut ni valider la signature du certificat, ni construire la chaîne de confiance. À l'inverse, rester en cryptographie classique, c'est accepter le risque « harvest now, decrypt later » et prendre du retard sur une échéance réglementaire qui se rapproche.
D'où la question que se posent aujourd'hui la plupart des DSI et RSSI qui préparent leur feuille de route : comment faire coexister les deux mondes pendant la transition ? Deux grandes familles de réponses existent, et le vocabulaire flou qui les entoure (« hybride », « dual », « composite », « parallèle ») entretient une confusion durable. Posons les définitions.
Famille 1 — Le certificat hybride (ou « parallèle », ou « dual »)
Définition
Dans l'approche hybride — également appelée parallèle ou dual —, on émet deux certificats indépendants (ou deux paires de clés distinctes) pour la même identité :
- un certificat classique, signé en RSA ou ECDSA, exactement comme aujourd'hui ;
- un certificat post-quantique, portant par exemple une clé et une signature ML-DSA.
Le schéma mental est simple : imaginez un serveur qui détient deux badges d'accès pour la même porte. Le premier badge est au format que tous les lecteurs actuels savent lire ; le second est au nouveau format, que seuls les lecteurs modernisés reconnaissent. Chaque client utilise le certificat qu'il comprend, et ignore l'autre. Les deux chaînes de confiance vivent côte à côte, sans se toucher.
Les avantages
Le bénéfice majeur est la rétrocompatibilité totale. Un client classique n'a même pas conscience de l'existence du certificat post-quantique : rien ne change pour lui, aucune mise à jour n'est requise de son côté. C'est la propriété qui rend l'hybride déployable dès maintenant, sur un parc hétérogène, sans campagne de migration coordonnée des clients. La transition peut être progressive : on modernise les clients un par un, et chacun bascule sur la chaîne post-quantique quand il est prêt.
Le coût — et il est opérationnel, pas cryptographique
Le revers de la médaille tient en une phrase : deux fois plus de certificats à gérer. Deux émissions, deux renouvellements, deux entrées d'inventaire, deux dates d'expiration à surveiller, deux révocations éventuelles — pour chaque identité.
Ce doublement serait presque anecdotique dans le monde d'hier, celui des certificats valables un ou deux ans. Il ne l'est plus du tout à l'ère des cycles de vie courts : avec des durées de validité qui descendent à 100 jours, puis 47 jours, chaque certificat supplémentaire multiplie les opérations de renouvellement dans l'année. Un parc de 5 000 identités en dual, c'est 10 000 certificats vivants, chacun à renouveler plusieurs fois par an. Sans automatisation du cycle de vie (découverte, inventaire, renouvellement, déploiement), la tension opérationnelle devient réelle — et c'est elle, bien plus que la cryptographie, qui fait échouer les projets hybrides.
Famille 2 — Le certificat composite
Définition
L'approche composite prend le problème par l'autre bout : au lieu de deux certificats, on émet un seul certificat X.509 qui porte :
- une clé publique composite : les deux clés publiques (classique + post-quantique) encapsulées ensemble dans un même champ ;
- une signature composite : les deux signatures, produites par les deux algorithmes, liées ensemble cryptographiquement.
La règle de vérification est stricte : le vérifieur doit valider les deux signatures pour accepter le certificat. Cette conjonction est précisément ce qui fait la valeur sécuritaire du composite : la construction reste sûre tant qu'au moins un des deux algorithmes résiste. Si ML-DSA venait à être cassé demain, la composante ECDSA tient ; si un ordinateur quantique casse ECDSA après-demain, la composante ML-DSA tient. On ne parie pas sur un algorithme, on parie sur le fait qu'ils ne tomberont pas tous les deux en même temps.
Ce mécanisme est en cours de normalisation à l'IETF, dans le groupe de travail LAMPS, à travers deux documents : draft-ietf-lamps-pq-composite-sigs (signatures composites, révision -19 d'avril 2026, sur la voie de la standardisation) et draft-ietf-lamps-pq-composite-kem (encapsulation de clés composite, révision -17).
L'inconvénient rédhibitoire aujourd'hui : la rétrocompatibilité
Le certificat composite introduit de nouveaux OID (identifiants d'algorithmes) que les piles cryptographiques existantes ne connaissent pas. Conséquence directe : un client classique-seul ne comprend pas un certificat composite. Là où l'hybride laissait le parc existant intact, le composite exige que tous les vérifieurs de la chaîne soient mis à jour pour reconnaître les algorithmes composites — faute de quoi la validation échoue purement et simplement.
Le composite est donc élégant sur le plan cryptographique (un seul objet à gérer, une liaison forte entre les deux algorithmes, pas de doublement de l'inventaire), mais il déplace le fardeau vers l'écosystème : il n'est viable que dans un périmètre où l'on contrôle la totalité des clients.
La contrainte transverse : la taille
Quel que soit le chemin choisi, un paramètre physique pèse sur toute la discussion : les signatures post-quantiques sont volumineuses.
Une signature ML-DSA pèse environ 2,4 à 4,6 Ko selon le jeu de paramètres retenu. À titre de comparaison, une signature ECDSA tient dans ~64 octets. C'est un facteur de plusieurs dizaines, et il se répercute partout où des certificats transitent :
- TLS : le handshake transporte le certificat du serveur et sa chaîne ; chaque signature ML-DSA ajoutée gonfle les premiers allers-retours de la connexion, avec un impact mesurable sur la latence d'établissement, en particulier sur les liens contraints ;
- IoT et embarqué : mémoire limitée, bande passante comptée, parfois des tailles de trames plafonnées — le surcoût peut être tout simplement rédhibitoire ;
- composite spécifiquement : le certificat cumule les deux clés publiques et les deux signatures dans un seul objet, qui devient mécaniquement le plus lourd des trois options.
La taille n'est donc pas un détail d'implémentation : c'est un critère de choix à part entière entre hybride, composite et post-quantique pur, et elle explique pourquoi la réponse ne peut pas être uniforme sur tout le SI.
Le tableau de décision : quel choix dans quel contexte ?
Il n'existe pas de gagnant absolu. Le bon choix dépend du degré de contrôle que vous avez sur les vérifieurs, des contraintes de taille du canal, et du cadre réglementaire applicable.
| Contexte | Recommandation | Pourquoi |
|---|---|---|
| PKI interne (vous contrôlez tous les clients) | Composite viable | Tous les vérifieurs peuvent être mis à jour pour reconnaître les nouveaux OID ; un seul certificat à gérer par identité, liaison cryptographique forte entre les deux algorithmes. |
| eIDAS / signature qualifiée | Hybride, en suivant la doctrine de conformité (cf. ANSSI) | Le cadre réglementaire prime : alignez-vous sur la doctrine publiée par l'ANSSI plutôt que sur une préférence technique. Voir notre article dédié aux positions de l'ANSSI. |
| IoT / embarqué contraint | Prudence sur la taille : parfois un seul algorithme bien dimensionné, ou un hybride léger | Le surcoût des signatures ML-DSA (2,4–4,6 Ko contre ~64 o en ECDSA) peut dépasser les budgets mémoire et bande passante ; dimensionner au plus juste. |
| Web public / navigateurs | Ni l'un ni l'autre n'est prêt à l'échelle — surveiller le CA/Browser Forum et le groupe TLS de l'IETF | Côté navigateurs, l'échange de clés post-quantique (ML-KEM, via X25519MLKEM768) est activé par défaut dans Chrome et Firefox depuis 2024-2025 ; mais les signatures ML-DSA dans les certificats publics, elles, ne le sont pas — les mises à jour des Baseline Requirements du CA/Browser Forum sont attendues fin 2026 ou 2027, et Chrome explore une voie alternative (Merkle Tree Certificates) plutôt que le X.509 post-quantique classique. Toute anticipation unilatérale serait prématurée. |
Une lecture transversale de ce tableau : plus votre périmètre est fermé et maîtrisé, plus le composite devient attractif ; plus il est ouvert et hétérogène, plus l'hybride s'impose — jusqu'au web public, où il faut simplement attendre que la normalisation et les programmes racine convergent.
Recommandation pragmatique : commencer hybride, viser composite
Pour la majorité des organisations, la trajectoire raisonnable en 2026 se dessine ainsi :
1. Commencer par l'hybride/dual là où la transition doit démarrer maintenant. C'est la seule approche qui garantit la rétrocompatibilité totale avec le parc existant, et donc la seule qui permet d'avancer sans coordonner une mise à jour simultanée de tous les clients. Elle offre aussi un bénéfice moins visible mais précieux : elle force l'organisation à industrialiser sa gestion de certificats (inventaire exhaustif, renouvellement automatisé, supervision des expirations), un prérequis de toute façon incontournable avec les validités à 47 jours.
2. Traiter le doublement de charge par l'outillage, pas par les effectifs. Le vrai risque de l'hybride n'est pas cryptographique, il est opérationnel. Si chaque certificat supplémentaire se traduit par du travail manuel supplémentaire, le dual ne passera pas à l'échelle. Si le cycle de vie est automatisé de bout en bout, le doublement du parc devient un paramètre de configuration plutôt qu'un problème de ressources humaines.
3. Viser le composite quand l'écosystème mûrit, en commençant par les périmètres fermés (PKI interne, machine-to-machine maîtrisé) où tous les vérifieurs peuvent être mis à jour. La stabilisation des drafts LAMPS et l'arrivée du support dans les bibliothèques cryptographiques du marché seront les signaux à guetter. Une PKI bien architecturée doit pouvoir accueillir cette évolution sans refonte : c'est un critère à intégrer dès aujourd'hui dans vos choix d'outillage.
4. Garder la taille en tête à chaque étape. Avant de généraliser quoi que ce soit sur un canal contraint (TLS à fort volume, IoT, liaisons bas débit), mesurez l'impact réel des signatures post-quantiques sur vos handshakes et vos budgets mémoire. Certains segments justifieront des choix différents du reste du SI — et c'est normal.
Note produit
Chez ZetaCert, ces deux familles structurent notre feuille de route. ZetaCA sait émettre en hybride/dual — l'émission parallèle classique + ML-DSA a été validée. PKIFactor, notre plateforme de gestion du cycle de vie (CLM), adresse précisément le talon d'Achille de l'hybride : l'inventaire et le renouvellement des deux certificats de chaque identité sont gérés sans doubler la charge humaine, ce qui rend le dual soutenable même avec des validités courtes. ZetaCA émet aussi en composite (certificat unique combinant les deux mécanismes, suivant les drafts IETF LAMPS pq-composite-sigs), au rythme de leur évolution : vous couvrez ainsi les deux stratégies, dual et composite, sous une même autorité — sans avoir à choisir votre camp trop tôt.
Si vous souhaitez évaluer où en est votre parc et par où commencer : audit.zetacert.com.
📋 Que faire aujourd'hui
- Inventoriez votre parc de certificats et vos vérifieurs. Vous ne pouvez pas choisir entre hybride et composite sans savoir quels clients devront valider quoi — c'est le point de départ de toute la décision.
- Testez l'émission dual sur un périmètre pilote (une application interne, un segment machine-to-machine) pour mesurer concrètement l'impact opérationnel du doublement, avec votre outillage actuel.
- Mesurez l'impact taille sur vos canaux sensibles : chronométrez des handshakes TLS avec des chaînes alourdies de signatures ML-DSA, et vérifiez les budgets mémoire de vos équipements embarqués avant tout engagement.
- Mettez la normalisation sous veille : drafts LAMPS composites, groupe TLS de l'IETF, CA/Browser Forum et publications de l'ANSSI. Le bon moment pour basculer vers le composite sera dicté par l'écosystème, pas par votre calendrier interne.
