Modèle d'évaluation du risque quantique, avec une méthode de notation transparente

Un modèle d'évaluation du risque quantique est un tableau unique comportant une ligne par actif cryptographique et six colonnes qui déterminent sa priorité : actif, algorithme utilisé, durée de vie des données, exposition, délai de migration et dépendance fournisseur. La méthode de notation ci-dessous est volontairement transparente : chaque chiffre provient de vos propres estimations et des échéances de migration publiées, jamais d'une date d'arrivée prédite pour un ordinateur quantique. Reprenez la structure, conservez les preuves à côté, et vous disposez d'un inventaire que vous pouvez défendre lors d'un audit.

Les six colonnes, et la question à laquelle chacune répond

Gardez un modèle resserré. Six colonnes suffisent pour hiérarchiser le travail, et un tableau resserré est réellement rempli. Le responsable, la référence du ticket et la date de revue relèvent de l'administration : ces champs sont utiles, mais ils ne modifient pas une priorité.

Pourquoi l'échange de clés nécessite son propre indicateur

Le trafic enregistré n'est protégé que par l'échange de clés. C'est toute la logique de l'approche « récolter maintenant, déchiffrer plus tard » (HNDL, harvest now, decrypt later) : un adversaire stocke aujourd'hui des données chiffrées et les déchiffre lorsque les mathématiques le permettent. Les signatures se comportent différemment, car falsifier une signature plus tard n'expose pas rétroactivement une session passée. Le modèle comporte donc un indicateur de vulnérabilité qui distingue les deux cas, au lieu de traiter tous les algorithmes vulnérables au quantique comme un risque unique.

Notation : trois niveaux par colonne

Chaque colonne reçoit une note de 1, 2 ou 3, les définitions des niveaux étant inscrites dans le modèle afin que deux évaluateurs aboutissent au même chiffre à partir des mêmes faits. Les niveaux de durée de vie ci-dessous constituent un point de départ : ajustez-les à votre calendrier de conservation et à vos contrats, et consignez l'ajustement dans le modèle pour que la note reste auditable.

Deux sommes en découlent, et elles doivent rester distinctes. L'urgence, U = Q + S + E, de 3 à 9, mesure ce que coûte un retard. Le délai de mise en œuvre, L = M + D, de 2 à 6, mesure la durée de la modification une fois engagée. En faire la moyenne en un seul chiffre détruit précisément l'information dont vous avez besoin, car une ligne urgente et peu coûteuse et une ligne lente et coûteuse appellent des décisions différentes.

L'inégalité de Mosca comme raisonnement, pas comme prophétie

Michele Mosca a formulé le problème de la migration à l'aide de trois grandeurs : X, la durée pendant laquelle vos données doivent rester confidentielles ; Y, le temps nécessaire pour migrer ; Z, le temps restant avant que l'algorithme puisse être cassé. Si X plus Y est supérieur à Z, les données qui quittent vos systèmes aujourd'hui sont déjà hors de leur fenêtre de protection.

Z n'est pas connaissable, et ce site n'en publie aucune estimation. La substitution utile consiste à remplacer Z par un horizon de planification dont vous êtes redevable : la première échéance datée de votre propre périmètre réglementaire. L'inégalité cesse alors d'être une prévision pour devenir un calcul de conformité, sans aucune probabilité inventée.

Le calcul est rapide. Une ligne avec une durée de vie de 10 ans et un délai de migration de 2 ans nécessite 12 ans de protection. Un horizon fixé à fin 2030 se situe à environ 4 ans. Douze est supérieur à quatre, l'indicateur est donc activé : commencez maintenant. Cette affirmation ne dit rien de la date à laquelle un ordinateur quantique existera, seulement que la fenêtre de protection s'étend au-delà de la date que votre propre périmètre vous fixe. Consignez l'horizon retenu dans une colonne à côté de l'indicateur, afin qu'un relecteur puisse contester l'horizon sans refaire l'évaluation.

Transformer les notes en ordre de travail

1. Les lignes dont l'indicateur de Mosca est activé et dont Q vaut 3 passent en premier, par U décroissant. Ce sont les lignes HNDL, pour lesquelles un retard ne pourra pas être rattrapé plus tard.
2. À urgence égale, placez en premier le délai de mise en œuvre le plus long. Le remplacement d'un HSM doit commencer avant une modification de configuration d'une seule ligne, même si cette dernière se termine plus tôt.
3. Les lignes dont Q vaut 1 quittent la file et rejoignent une liste de surveillance, revue selon le même cycle que tout le reste, car un déploiement hybride en place aujourd'hui peut régresser demain.

U = Q + S + E          # urgency, 3 to 9
L = M + D              # lead time, 2 to 6
sort by (mosca_flag, Q, U, L), all descending

Il n'y a volontairement ni pondération ni multiplication. Une note composite pondérée masque l'estimation avec laquelle un relecteur est en désaccord. Quatre composantes visibles permettent à un auditeur de contester une cellule, et non le classement.

Remplir les colonnes avec des preuves, pas des opinions

Trois sources couvrent la plupart des lignes. Pour tout ce qui dispose d'un point de terminaison public, lisez directement le groupe négocié. OpenSSL 3.5 ou ultérieur est requis pour les groupes ML-KEM, et les noms des groupes hybrides sont enregistrés par l'IANA : X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) et SecP384r1MLKEM1024 (0x11ED).

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i 'Negotiated TLS1.3 group'

ssh -Q kex | grep mlkem

Pour les accès d'administration, OpenSSH a fait de mlkem768x25519-sha256 l'accord de clés par défaut dans la version 10.0 (9 avril 2025), et la version 10.1 (6 octobre 2025) émet un avertissement lorsqu'une connexion négocie un accord de clés non post-quantique, selon les notes de version d'OpenSSH. Pour le code, les bibliothèques et les artefacts de build, un CBOM (cryptographic bill of materials, nomenclature cryptographique) renseigne la colonne Algorithme à grande échelle, ce qui est important, car un inventaire saisi à la main vieillit le jour même où il est terminé. Testez toute modification de groupe en préproduction, et conservez un repli classique tel que X25519, listé après X25519MLKEM768.

Rattacher le modèle aux obligations

Cette section a une valeur informative et ne constitue pas un conseil juridique. Lorsqu'une ligne ci-dessus reflète notre lecture plutôt que le texte lui-même, elle est signalée comme une interprétation, et votre copie du modèle devrait conserver cette distinction visible pour les auditeurs.

Mesurer d'abord, noter ensuite

Des notes fondées sur une configuration supposée ne valent rien. Commencez par les faits visibles de l'extérieur : lancez un scan gratuit de votre domaine avec PQC Status pour voir les groupes TLS négociés, les versions et la chaîne de certificats, reportez le résultat dans les colonnes Algorithme et Exposition des premières lignes, puis progressez vers l'intérieur avec ssh -Q kex et un CBOM. Un scan décrit uniquement la configuration TLS visible de l'extérieur : ce n'est ni une certification ni une attestation de conformité, mais c'est la seule colonne que personne ne peut contester.