Il y a un moment rassurant dans tout projet post-quantique. La bibliothèque est à jour, l'échange de clés affiche ML-KEM-768, le ticket est fermé. Terminé.

Sauf que non. Vous avez remplacé une serrure. Vous n'avez vérifié ni les fenêtres, ni le sceau des lettres, ni si quelqu'un tenait l'inventaire des autres serrures.

Dans le secteur, on commence à appeler cela la différence entre migration PQC et transformation PQC. La migration change les algorithmes. La transformation change les algorithmes et reconstruit la vérification, la visibilité et la confiance autour d'eux. La plupart des fournisseurs s'arrêtent à la première.

La migration, c'est l'algorithme. La transformation, c'est tout ce qui l'entoure.

La migration est nécessaire et nous ne la minimisons pas. RSA et ECC tomberont face à un ordinateur quantique cryptographiquement pertinent, et les FIPS 203 (ML-KEM) et FIPS 204 (ML-DSA) du NIST sont leurs remplaçants. Si vous n'avez pas commencé, commencez.

Mais un algorithme est un composant, pas une posture de sécurité. Un échange de clés quantum-safe protège la confidentialité d'un message. Il ne dit rien sur l'authenticité du message, sur le fait que le jeton qui a autorisé la requête ait été forgé, ou que le certificat à l'autre bout de la connexion ait été émis par quelqu'un qui a cassé ECDSA l'an dernier.

La transformation pose quatre questions au lieu d'une : Est-ce confidentiel ? Est-ce vérifiable ? Est-ce que je sais où vit toute ma cryptographie ? Et à qui, au final, est-ce que je fais confiance ?

Le chiffrement n'arrête pas un man-in-the-middle. La vérification, si.

Harvest Now, Decrypt Later est une affaire de confidentialité : un attaquant enregistre du chiffré aujourd'hui et le lit quand le matériel aura rattrapé son retard. ML-KEM ferme cette porte. Nous en avons déjà parlé, et cela reste le problème le plus urgent pour quiconque détient des données à longue durée de vie.

Mais le même ordinateur quantique qui casse le chiffrement RSA casse aussi les signatures RSA et ECDSA. C'est une attaque différente, avec une conséquence différente. Au lieu de lire vos données plus tard, l'attaquant vous usurpe maintenant. Pensez à ce qui, dans une pile technique classique, n'est protégé que par une signature classique :

Jetons d'accès et JWT — forgez-en un et vous n'avez plus besoin de voler un mot de passe.
Certificats TLS — un certificat forgé, c'est un man-in-the-middle avec un cadenas valide.
Signature de code et de firmware — une signature forgée distribue un malware comme mise à jour officielle.
Webhooks, réponses d'API et journaux d'audit — l'intégrité de tout ce qui suit.

Si vous avez mis à niveau le chiffrement en laissant les signatures sur ECDSA, vous avez scellé l'enveloppe et laissé le cachet de cire falsifiable. ML-DSA (FIPS 204) et SLH-DSA (FIPS 205) existent précisément pour ce côté du problème. Une vraie transformation protège les deux côtés.

On ne migre pas ce qu'on ne voit pas

Demandez à un RSSI où RSA est utilisé dans son organisation et la réponse honnête est « à plus d'endroits qu'on ne le sait ». Il est dans les en-têtes JWT, les clés SSH, les clés KMS cloud, les signatures PDF, les registres de conteneurs, les SDK des fournisseurs et cet outil interne de 2017.

C'est pourquoi toute feuille de route PQC sérieuse — y compris la feuille de route coordonnée de l'UE de juin 2025 — place l'inventaire avant la migration. Le premier jalon n'est pas « être quantum-safe ». C'est « connaître son patrimoine cryptographique » : quels algorithmes, quelles tailles de clés, quels systèmes, quelles durées de vie des données. Sans cela, vous migrerez les 60 % visibles et vous serez compromis par les 40 % que personne n'a listés.

L'inventaire cryptographique n'a rien de glamour. C'est aussi l'étape qui décide si une transformation est réelle ou cosmétique.

À quoi ressemble une transformation complète

Mises bout à bout, quatre couches — chacune est nécessaire, aucune ne suffit seule :

Confidentialité — encapsulation de clés ML-KEM autour d'AES-256-GCM pour les données au repos et en transit. C'est la défense contre HNDL.
Vérification — signatures ML-DSA ou SLH-DSA sur les jetons, documents, artefacts et messages, pour que l'altération et l'usurpation échouent même face à un adversaire quantique.
Ancres de confiance — des clés générées à partir d'une entropie quantique réelle, émises et vérifiées par une infrastructure sous une juridiction fiable. Zero-trust signifie que chaque couche est post-quantique, pas seulement le transport.
Inventaire — une vue vivante des algorithmes, clés et systèmes en jeu, pour que la migration soit mesurable et que rien ne soit oublié.

Où en est QuantumAPI — honnêtement

Voici ce qui est en production aujourd'hui. QuantumAPI chiffre et déchiffre avec ML-KEM-512/768/1024 encapsulant AES-256-GCM, et signe et vérifie avec ML-DSA-44/65/87 et SLH-DSA. QuantumID émet des jetons d'accès porteurs d'une preuve ML-DSA-65 à côté de la signature classique, pour que les clients compatibles PQC puissent vérifier les deux. QuantumVault stocke secrets, clés et certificats sous le même chiffrement hybride ML-KEM, et son moteur transit signe avec ML-DSA. Les clés sont issues de matériel quantique réel, avec repli automatique. Tout tourne sur une infrastructure européenne, sous juridiction de l'UE, facturé à l'usage — jamais par utilisateur.

Et voici ce qui n'est pas encore livré. Un tableau de bord d'inventaire cryptographique, pour voir votre patrimoine d'algorithmes d'un coup d'œil, est sur notre feuille de route, pas dans le produit. Les réponses d'API signées sont prévues, pas en service. Nous préférons vous le dire plutôt que de cocher une case dans un tableau.

Si vous planifiez un projet post-quantique, planifiez une transformation, pas une migration. Commencez par les deux côtés — chiffrement et vérification — et exigez un inventaire de tous ceux avec qui vous travaillez. Vous pouvez tester dès aujourd'hui les endpoints de chiffrement et de signature avec le plan gratuit sur quantumapi.eu, et la documentation sur docs.quantumapi.eu montre exactement ce que fait chaque algorithme.