Appel d'offres cryptographie post-quantique : modèle de cahier des charges et checklist (2026)

Ce modèle d'appel d'offres pour la cryptographie post-quantique vous donne un cahier des charges neutre vis-à-vis des éditeurs : exigences, grille de notation pondérée, questions aux candidats, plan de preuve de concept et clauses contractuelles à coller dans votre propre appel d'offres. Il couvre dix groupes d'exigences : découverte et inventaire (CBOM), évaluation du risque, prise en charge des algorithmes (ML-KEM, ML-DSA, SLH-DSA, hybride et composite), certificats PQC et PKI, préparation du TLS et des protocoles, impact sur la gestion des clés, orchestration de la migration, reporting et conformité, déploiement, et l'éditeur lui-même. Les tableaux se copient directement dans un tableur.

Chaque exigence est une chose qu'un produit sérieux de la catégorie peut satisfaire et prouver. Les éléments que seules certaines architectures offrent sont marqués Avancé, pour que l'appel d'offres n'écarte pas de bons éditeurs par accident. Pour connaître le marché avant de rédiger, lisez le guide d'achat de la gestion de la posture cryptographique.

---

Table des matières

1. À qui s'adresse ce document et comment l'utiliser
2. Avant de rédiger l'appel d'offres
3. La checklist des exigences
4. Grille de notation pondérée
5. Questions à poser aux candidats
6. Signaux d'alerte dans les réponses
7. Plan de preuve de concept
8. Clauses de contrat et de sortie
9. Introduction d'appel d'offres prête à copier
10. FAQ
11. Références

---

À qui s'adresse ce document et comment l'utiliser

Ce cahier des charges s'adresse aux RSSI, architectes sécurité, responsables PKI ou cryptographie et acheteurs qui achètent l'un ou plusieurs des éléments suivants : une plateforme de découverte et de gestion de la posture cryptographique, une capacité de certificats et de PKI post-quantiques, ou une gestion de clés devant accueillir des clés post-quantiques. Il peut servir d'appel d'offres complet, d'annexe technique d'un appel d'offres plus large ou de grille de critères pour une revue de présélection.

Mode d'emploi :

1. Supprimez les groupes hors périmètre. Ne gardez pas d'exigences que vous ne noterez pas.
2. Réglez chaque priorité selon votre contexte. Obligatoire signifie qu'une offre qui échoue est écartée ou fortement pénalisée. Souhaitable est noté. Avancé est un facteur de différenciation noté en bonus, jamais un critère éliminatoire.
3. Gardez la colonne « Preuve à demander » : elle transforme une affirmation en élément vérifiable.
4. Copiez chaque tableau dans un tableur, ajoutez des colonnes pour la réponse et la note de chaque candidat, et appliquez les pondérations de la section notation.

Les identifiants d'exigence portent un préfixe de groupe, par exemple DI pour découverte et inventaire. Les normes sont nommées précisément pour que les éditeurs répondent à la même question : ML-KEM est la norme NIST FIPS 203, ML-DSA la FIPS 204 et SLH-DSA la FIPS 205.

---

Avant de rédiger l'appel d'offres

Un bon appel d'offres commence par des réponses que vous détenez déjà. Sans elles, les candidats rédigent des réponses génériques, impossibles à comparer.

Questions de périmètre

• Quels environnements sont concernés : centres de données, clouds publics, SaaS, OT et IoT, chaînes de développement, produits tiers ?
• Quelles surfaces cryptographiques comptent le plus : TLS externe, TLS interne, VPN et IPsec, SSH, signature de code, signature de documents, clés de chiffrement au repos, chiffrement des bases, micrologiciels ?
• Quelles données ont une longue durée de confidentialité ? Celles qui doivent rester secrètes pendant de nombreuses années sont exposées au risque « stocker maintenant, déchiffrer plus tard ».
• Avez-vous des réseaux isolés (air-gapped) et quelles règles de résidence des données s'appliquent ?

Inventaire que vous pouvez apporter

• Des ordres de grandeur : certificats, autorités de certification internes, répartiteurs de charge, HSM, comptes cloud, dépôts de code, langages.
• Les contraintes connues : équipements contraints, protocoles anciens, appliances d'éditeurs que vous ne pouvez pas modifier.

Parties prenantes

• Architecture sécurité, PKI et gestion des clés, responsables applicatifs, réseau et infrastructure, risques et conformité, achats et juridique. Nommez un responsable par groupe d'exigences.

Critères de décision et calendrier

• Fixez les pondérations avant de lire les offres (voir la section notation). Définissez le périmètre et les dates de la preuve de concept dans l'appel d'offres lui-même, pour que les candidats puissent mobiliser leurs équipes.
• Ancrez le calendrier sur les échéances réglementaires qui vous concernent, par exemple le projet NIST IR 8547 (dépréciation après 2030 des algorithmes vulnérables au quantique à 112 bits, interdiction après 2035), CNSA 2.0 si vous servez des systèmes de sécurité nationale américains, ou des textes nationaux comme ceux du NCSC et de la FINMA en Suisse et le BSI TR-02102 en Allemagne. NIST IR 8547 est un projet : considérez les dates comme des repères de planification.

---

La checklist des exigences

Légende des priorités : O = Obligatoire, S = Souhaitable, A = Avancé.

Groupe 1 : Découverte et inventaire (CBOM)

Groupe 2 : Évaluation du risque et priorisation

Groupe 3 : Prise en charge des algorithmes

Groupe 4 : Certificats PQC et PKI

Groupe 5 : Préparation du TLS et des protocoles

Groupe 6 : Impact sur la gestion des clés

Groupe 7 : Orchestration de la migration

Groupe 8 : Reporting et conformité

Groupe 9 : Déploiement

Groupe 10 : Éditeur

---

Grille de notation pondérée

Utilisez une échelle de 0 à 5 pour chaque exigence notée et multipliez par le poids du groupe. Fixez les poids avant de lire les réponses.

Échelle

Pondérations suggérées (à adapter ; le total doit faire 100)

Toute exigence Obligatoire notée sous 3 est éliminatoire : le candidat est écarté ou doit fournir un plan de remédiation écrit avec des dates. Les éléments Avancés ajoutent au total 5 points de bonus au plus et n'entraînent jamais d'exclusion.

Exemple chiffré (valeurs fictives, à titre d'illustration seulement). Supposons que la note moyenne du groupe 1 soit de 3,5 pour l'éditeur A et de 4,0 pour l'éditeur B. Le groupe 1 apporte 3,5 / 5 x 20 = 14,0 points à A et 4,0 / 5 x 20 = 16,0 à B. Répétez pour chaque groupe et additionnez. Si A atteint 74 et B 71 sur les dix groupes, A est mieux classé au global alors que B est plus fort en découverte. Vérifiez ensuite les critères éliminatoires et les résultats de la preuve de concept avant de décider : une note plus basse sur le papier qui réussit la preuve de concept vaut mieux qu'une note plus haute qui échoue.

---

Questions à poser aux candidats

Posez-les dans la réponse écrite. Exigez des réponses précises, datées et vérifiables.

1. Quels types d'actifs la découverte couvre-t-elle aujourd'hui, et lesquels sont à la feuille de route ? Donnez des dates de livraison pour ces derniers.
2. Qu'est-ce qui est exactement analysé dans les binaires et les images de conteneurs : les dépendances seules, ou le code compilé ?
3. Quelle version de CycloneDX utilise votre export CBOM, et pouvez-vous fournir un exemple qui valide le schéma ?
4. Comment détectez-vous l'échange de clés hybride, et quels groupes sont reconnus ?
5. Comment le score de risque est-il calculé, et pouvons-nous voir la formule et la pondération ?
6. Comment représentez-vous la durée de confidentialité des données dans la notation ?
7. Quelles réglementations et normes sont reliées dans le produit lui-même, et lesquelles seulement dans le matériel marketing ?
8. Quels KMS cloud et HSM sont pris en charge en production, et lesquels en bêta ?
9. La découverte peut-elle fonctionner dans un réseau isolé ? Comment les mises à jour sont-elles livrées ?
10. Quel est le privilège minimal requis sur chaque système scanné, et qu'est-ce qui s'exécute sur notre infrastructure ?
11. Où les données clients sont-elles stockées et traitées, et qui sont vos sous-traitants ?
12. Quels profils de certificats post-quantiques pouvez-vous émettre, quelles versions de RFC ou de projets suivent-ils, et qu'est-ce qui a été testé en interopérabilité ?
13. Comment gérez-vous la croissance de la taille des certificats et des chaînes dans votre émission et votre distribution ?
14. Comment les clés post-quantiques sont-elles protégées, et quelles versions de micrologiciel HSM sont prises en charge ?
15. Quel est le processus lorsque le NIST ou l'IETF modifie une spécification après notre déploiement ?
16. Comment vous intégrez-vous à nos outils ITSM, CMDB, SIEM et CI/CD ? Montrez un exemple de chacun.
17. Qu'est-ce qui peut être automatisé de bout en bout, et où une validation humaine est-elle requise ?
18. Comment détectez-vous et rapportez-vous la dérive de configuration vers des algorithmes interdits ?
19. Que deviennent nos données, notre CBOM et nos rapports si nous résilions ?
20. Quelles certifications indépendantes couvrent le service, et quel en est le périmètre ?
21. Combien de clients de notre taille et de notre secteur exploitent le produit en production ?
22. Quels services professionnels proposez-vous pour la migration, et qui les réalise ?

---

Signaux d'alerte dans les réponses

• Des affirmations « quantum-safe » sans mention de la norme (FIPS 203, 204 ou 205) ni du jeu de paramètres.
• Un CBOM « pris en charge » sans format, version ni fichier d'exemple.
• Des scores de préparation dont la méthode n'est pas communiquée, ou un « 100 % prêt » sans périmètre.
• Une correspondance réglementaire visible seulement dans le matériel marketing, pas dans le produit ni dans la documentation.
• Des promesses de scan qui supposent discrètement d'installer des agents partout ou un accès Internet sortant que vous ne pouvez pas autoriser.
• Des éléments de feuille de route présentés au présent.
• L'impossibilité de faire une preuve de concept sur vos propres données dans un délai raisonnable.
• Aucune déclaration claire de ce que l'éditeur ne fait pas. Tout produit a des limites ; un éditeur qui n'en cite aucune n'est pas franc.
• Des certificats post-quantiques présentés comme prêts pour les sites web publics. La PKI web publique n'accepte pas encore les certificats ML-DSA.
• L'enfermement : formats de données propriétaires sans export, ou conditions de résiliation qui suppriment immédiatement vos données.

---

Plan de preuve de concept

Menez la même preuve de concept avec chaque candidat présélectionné, sur la même tranche de votre parc, pendant deux à quatre semaines.

Notez pour chaque candidat le délai avant le premier résultat, le nombre d'étapes manuelles et le taux de faux positifs. Reportez ces mesures dans la grille de notation.

---

Clauses de contrat et de sortie

• Propriété des données. Toutes les données d'inventaire, CBOM, résultats de scan et rapports sont vos données. L'éditeur ne peut utiliser de la télémétrie anonymisée qu'avec votre accord écrit.
• Export et sortie. Export complet en formats ouverts (CycloneDX pour le CBOM, formats standard pour les rapports) à tout moment et pendant une période définie après la résiliation, sans frais supplémentaires.
• Suppression. Suppression certifiée de vos données dans un délai indiqué après la résiliation.
• Niveaux de service. Disponibilité, délais de réponse du support et pénalités en cas de manquement.
• Obligations de sécurité. Maintien des certifications annoncées dans la réponse, notification des incidents dans un nombre d'heures indiqué, droits d'audit proportionnés au risque.
• Engagements de feuille de route. Les fonctions promises dans la réponse figurent en annexe avec dates de livraison et recours en cas de retard.
• Évolution des normes. L'éditeur implémentera les versions finales des normes pertinentes (par exemple la spécification IETF finale des signatures composites) dans un délai convenu, sans coût de licence supplémentaire.
• Sous-traitants. Préavis et droit d'opposition pour tout changement.
• Soutien réglementaire. Coopération aux demandes d'information de votre régulateur lorsque c'est applicable (par exemple au titre de DORA pour les entités financières).
• Protection tarifaire. Plafonds de hausse au renouvellement et indicateurs clairs de ce qui détermine le prix (actifs, scans, utilisateurs).

---

Introduction d'appel d'offres prête à copier

[Organisation] lance un appel d'offres pour une plateforme et des services destinés à inventorier, évaluer et migrer sa cryptographie en vue de la transition vers les normes post-quantiques. Le périmètre couvre [environnements]. Les candidats doivent démontrer la découverte des actifs cryptographiques sur les points réseau, les certificats et magasins de clés, le code source, les services de gestion de clés cloud et les modules de sécurité matériels ; l'export d'une nomenclature cryptographique (CBOM) au format CycloneDX ; une notation du risque documentée qui tient compte de la durée de confidentialité des données ; la prise en charge des normes NIST ML-KEM (FIPS 203), ML-DSA (FIPS 204) et SLH-DSA (FIPS 205) dans la détection et, le cas échéant, dans l'émission de certificats et la gestion des clés ; ainsi qu'une planification de migration avec conseils hybrides d'abord. Les réponses doivent fournir une preuve vérifiable pour chaque exigence de l'annexe A, distinguer capacités en production et feuille de route, et permettre une preuve de concept sur une part représentative de notre environnement. L'évaluation utilisera le modèle pondéré de l'annexe B, les exigences obligatoires jouant le rôle de critères éliminatoires. Les réponses sont attendues pour le [date] ; les preuves de concept se dérouleront les [dates].

---

FAQ

Que doit contenir un appel d'offres pour la cryptographie post-quantique ?

Il doit contenir le périmètre et les contraintes, puis des exigences regroupées par découverte et CBOM, évaluation du risque, prise en charge des algorithmes, certificats PQC et PKI, TLS et protocoles, gestion des clés, orchestration de la migration, reporting et conformité, déploiement et qualification de l'éditeur. Il doit aussi inclure une grille de notation, un plan de preuve de concept et des clauses sur l'export des données et l'évolution des normes.

Quelles normes NIST nommer dans le cahier des charges ?

Nommez la FIPS 203 (ML-KEM) pour l'établissement de clés, la FIPS 204 (ML-DSA) pour les signatures et la FIPS 205 (SLH-DSA) pour les signatures à base de fonctions de hachage. Demandez aux éditeurs quels jeux de paramètres ils prennent en charge et comment ils traitent les constructions hybrides et composites qui les associent à des algorithmes classiques.

Faut-il une exigence de CBOM ?

Oui. Un CBOM dans un format ouvert comme CycloneDX permet de partager des preuves avec les auditeurs, d'alimenter d'autres outils et de quitter un éditeur sans perdre votre inventaire. Demandez la version de la spécification et un fichier d'exemple qui valide le schéma.

L'appel d'offres doit-il exiger des certificats post-quantiques de la PKI web publique ?

Non. À la date de rédaction, les certificats ML-DSA ne sont pas acceptés dans la PKI web publique et les travaux du CA/Browser Forum à ce sujet ne sont pas finalisés. Limitez les exigences de certificats PQC à la PKI privée et aux environnements de test, et exigez une déclaration écrite de ce qui est pris en charge pour chaque domaine de confiance.

Une preuve de concept est-elle nécessaire ?

Pour cette catégorie, oui. Les outils de découverte diffèrent dans ce qu'ils voient de votre environnement, et les scores de risque diffèrent dans leur calcul. Une preuve de concept de deux à quatre semaines sur la même tranche pour chaque finaliste est le moyen de comparer le plus fiable.

Comment éviter un appel d'offres qui favorise un seul éditeur ?

Rédigez les exigences en termes de résultats et de preuves, marquez les capacités liées à une architecture comme Avancées et notez-les en bonus, et fixez les pondérations avant de lire les offres. Si une exigence n'est satisfaite que par un seul éditeur, demandez-vous si elle est essentielle à votre cas d'usage.

Peut-on commencer sans scan interne ?

Vous pouvez obtenir une première vue de votre exposition externe sans accès interne. Le Quantum Risk Score gratuit de DuoKey est calculé à partir de signaux publics et ne nécessite aucune installation ; c'est un point de départ, et l'inventaire lui-même provient d'un scan interne, par exemple avec la gestion de la posture cryptographique.

---

Références

• NIST FIPS 203 : ML-KEM
• NIST FIPS 204 : ML-DSA
• NIST FIPS 205 : SLH-DSA
• NIST IR 8547 (projet initial) : Transition to Post-Quantum Cryptography Standards
• RFC 9881 : identifiants d'algorithme ML-DSA dans X.509
• RFC 9909 : identifiants d'algorithme SLH-DSA dans X.509
• IETF Datatracker : draft-ietf-lamps-pq-composite-sigs
• IETF Datatracker : draft-ietf-tls-ecdhe-mlkem
• CycloneDX Cryptography Bill of Materials
• Documentation DuoKey : aperçu du CPM (PQC Scanner)
• Documentation DuoKey : planification de la migration