La sécurité postquantique dépend de vos fournisseurs

Sommaire
L’essentiel
Un questionnaire actualisé distingue les normes cryptographiques des produits déployables. Les risques d’achat concernent les dépendances, le support et les coûts de remplacement.
Une norme ne met pas un service à jour
Le 5 novembre 2026, l’agence australienne de cybersécurité a annoncé une actualisation de ses recommandations pour évaluer la préparation des fournisseurs à la cryptographie postquantique, élaborées avec la CISA et la NSA. Elles visent les achats, les renouvellements de contrats et l’évaluation continue des prestataires. La question pratique est de savoir si une organisation peut remplacer les mécanismes cryptographiques vulnérables dans les produits qu’elle utilise réellement, y compris les composants contrôlés par d’autres entreprises.
Selon notre analyse, il s’agit autant d’un problème d’achat que de mathématiques. Un client peut approuver un budget de migration sans contrôler la bibliothèque logicielle, le micrologiciel ou le service d’identité géré qui conditionne cette migration. L’engagement public d’un fournisseur doit donc définir un périmètre de produit et fournir des preuves de réalisation. Ni une feuille de route séduisante ni un badge de sécurité ne démontre qu’un service installé a changé.
L’annonce du NIST du 13 août 2024 fournit le point de départ technique : l’institut a finalisé des normes pour un mécanisme d’encapsulation de clés et des signatures numériques. ML-KEM permet d’établir des secrets partagés ; ML-DSA et SLH-DSA concernent les signatures. Ces fonctions sont différentes. Citer un algorithme dans une annonce ne montre pas quelles connexions l’utilisent, s’il est activé ou ce qui se passe lorsque l’autre partie ne le prend pas en charge. [2][3]
Les dépendances déterminent la facture
Les recommandations communes interrogent les fournisseurs sur leurs inventaires cryptographiques, les composants tiers, les mécanismes liés au matériel et les possibilités de mise à jour. Elles distinguent également les risques de confidentialité de ceux liés à la signature et à l’authentification. Ces questions comptent car un même produit commercial peut comporter plusieurs couches avec des responsables et des cycles de remplacement différents. Une mise à jour logicielle peut modifier une couche sans toucher à une racine de confiance matérielle.
Prenons un service financier hypothétique achetant une plateforme gérée. Le fournisseur annonce une prise en charge postquantique, mais son engagement ne couvre qu’une connexion entre certains serveurs. Les applications clientes, les micrologiciels et un service de signature distinct restent hors de cette déclaration. Il s’agit d’un exemple de situation d’achat, pas d’une accusation contre un prestataire nommé. La comparaison utile porte sur le périmètre promis et la carte réelle des dépendances du client.
Dans ce scénario, le prix d’achat sous-estime le coût de transition. Les tests, l’intégration, les contrats de support et le remplacement du matériel peuvent relever de budgets différents. Nous en déduisons qu’un renouvellement moins cher peut devenir coûteux s’il prolonge une dépendance envers un composant dont l’évolution est incertaine. À l’inverse, tout remplacer immédiatement peut gaspiller des ressources lorsqu’une mise à niveau prise en charge existe. Le choix nécessite des preuves propres au produit, pas une prévision générale sur l’informatique quantique. [1]
Trois promesses exigent des preuves différentes
Une démonstration de recherche indique si une solution peut fonctionner dans des conditions définies. Une version prise en charge indique ce que les clients peuvent déployer et maintenir. Une migration client achevée indique ce qui fonctionne dans un environnement donné. Confondre ces états masque le travail restant. La comparaison suivante est notre grille d’analyse éditoriale, pas un dispositif officiel de certification.
- Une feuille de route doit préciser le produit, l’équipe responsable, les dépendances et les conditions de livraison. Une date sans ces limites est difficile à faire respecter.
- Une fonction publiée doit avoir une documentation, des configurations prises en charge et un parcours de déploiement vérifiable. Son seul nom ne suffit pas.
- Une migration opérationnelle doit disposer d’un inventaire des systèmes modifiés, de résultats de tests et d’exceptions consignées. Un pilote réussi ne prouve pas une couverture complète.
Cette grille permet aussi de mieux interpréter les réponses incomplètes. Un fournisseur qui reconnaît une dépendance non résolue et présente un plan crédible peut fournir des informations plus utiles qu’un autre proclamant une préparation universelle sans limites. L’absence de réponse détaillée justifie une investigation et une gestion de l’exposition ; elle ne prouve ni une intrusion ni une volonté de tromper les clients. [1]
Séparer confidentialité et disponibilité
Les recommandations soulignent l’importance de la durée de vie des données, notamment la possibilité de déchiffrer ultérieurement des informations chiffrées collectées aujourd’hui. Cela ne signifie pas que chaque fichier conservé ou chaque transaction en cryptomonnaie soit déjà exposé. L’organisation doit déterminer quels mécanismes protègent les informations concernées et pendant combien de temps leur confidentialité compte. Un questionnaire institutionnel ne peut pas répondre à ces questions pour un portefeuille ou une plateforme d’échange en particulier.
La fiabilité opérationnelle exige ses propres critères d’acceptation. Dans notre exemple, une migration interrompant l’accès aux dossiers clients crée un risque commercial distinct, même si la conception cryptographique est appropriée. La discussion d’achat devrait donc préciser qui teste la compatibilité, qui autorise le changement et comment le service est rétabli si le déploiement échoue. Ce sont nos implications pratiques de la dépendance au fournisseur, pas des garanties données par le document.
Pour évaluer la conservation d’actifs ou une technologie financière, la conclusion défendable doit être plus précise que l’affirmation d’une « sécurité quantique ». Demandez quelle partie du service a changé, ce qui dépend encore d’un autre fournisseur et quelles preuves soutiennent la réponse. Les publications examinées ne fixent aucune date d’arrivée d’un ordinateur quantique pertinent pour la cryptanalyse, ne certifient aucun prestataire particulier et ne prédisent pas le prix d’un actif numérique. Leur intérêt immédiat est de rendre une transition de longue durée mesurable avant qu’une décision d’achat ne fige des hypothèses erronées. [1]
Preuves et sources
Document source: · Vérifié:
Limites des documents · Sources vérifiées le 6 novembre 2026. Les exemples hypothétiques sont une analyse éditoriale, pas des constats sur un fournisseur particulier.
- Rapporté par une source
Les recommandations communes traitent des dépendances cryptographiques envers les fournisseurs.
Extrait à l’appui: Recommandations sur la préparation des fournisseurs
vendor-neutral questions
vendor-neutral questions
Vendor readiness guidance ↗ - Rapporté par une source
ACSC a annoncé des recommandations communes actualisées.
Extrait à l’appui: Actualisation des recommandations fournisseurs
we have updated our guidance
we have updated our guidance
Vendor guidance update ↗ - Rapporté par une source
NIST a finalisé des normes d’encapsulation de clés et de signatures.
Extrait à l’appui: Normes finalisées du NIST
Module-Lattice-Based Key-Encapsulation Mechanism
Module-Lattice-Based Key-Encapsulation Mechanism
NIST finalized standards ↗


