Migration vers la cryptographie post-quantique : comment PQCensus peut-il inventorier les primitives cryptographiques ?

Un ordinateur quantique puissant peut briser ou réduire la sécurité de la cryptographie moderne, ce qui est un fait bien connu mettant en péril l'infrastructure informatique des entreprises [13]. La meilleure atténuation connue à cette menace est la migration de l'informatique d'entreprise vers un état de cryptographie post-quantique (PQC) [13]. Cette migration est difficile car l'informatique d'entreprise se compose généralement de plusieurs grandes applications avec des interdépendances complexes [13]. En raison de cette difficulté, la migration nécessitera une expertise technique ainsi que de nouveaux outils capables d'automatiser le processus et de réduire les erreurs [13]. Ces quatre faits, pris en séquence, décrivent exactement l'écart qu'un outil d'inventaire est censé combler : une menace réelle, un remède connu mais difficile, une raison structurelle pour laquelle le remède est difficile, et un appel à des outils pour rendre la tâche réalisable.

C'est la raison pratique pour laquelle un outil d'inventaire est nécessaire avant toute modification du code : personne ne peut migrer ce qu'il ne peut pas trouver, et l'audit manuel de grandes applications interdépendantes n'est pas évolutif. Deux outils ont été proposés dans la littérature pour répondre directement à ce besoin : un Inventory Generator qui produit un inventaire cryptographique pour une application donnée, et un TCS Quantum Risk Analyzer Engine qui évalue une application donnée face aux menaces quantiques [13]. Ils sont présentés comme une paire : d'abord trouver la cryptographie, puis évaluer son risque [13]. La division du travail est importante pour un développeur, car elle sépare deux problèmes d'ingénierie distincts, la découverte et l'évaluation des risques, qui pourraient autrement être confondus en un seul outil opaque.

Une préoccupation distincte mais connexe est que les réseaux étendus d'entreprise dépendent de la cryptographie à clé publique vulnérable au quantique pour authentifier les pairs et établir des clés pour IPsec, TLS et les services WAN définis par logiciel [11]. Cela montre que le problème d'inventaire ne se limite pas au code source des applications : il s'étend également à la configuration des protocoles au niveau du réseau, qu'un scanner de code source tel que PQCensus n'examine pas directement. Un programme de migration d'entreprise complet nécessite donc au moins deux types de travaux d'inventaire fonctionnant en parallèle, l'un au niveau du code source de l'application et l'autre au niveau du réseau et des protocoles, et aucune affirmation dans cette note ne décrit un outil qui unifie les deux.

Dans ce contexte, PQCensus se positionne étroitement et explicitement comme une réponse au niveau du code source à quatre questions d'ingénierie : où la cryptographie est utilisée, quel objectif chaque utilisation sert, quelles utilisations sont pertinentes pour la migration post-quantique, et ce qui peut être migré ensuite sans inventer une cible lorsque les preuves sont ambiguës [1]. Ce périmètre est important pour un développeur : PQCensus n'est pas un auditeur réseau, un moteur d'évaluation des risques à l'échelle d'une entreprise, ou un certificateur ; c'est une étape d'inventaire par analyse statique sur laquelle d'autres outils ou une revue manuelle devraient s'appuyer. La lecture des quatre questions de PQCensus à côté du cadre au niveau de l'entreprise ci-dessus montre que PQCensus ne répond qu'à la première moitié du problème de migration plus large décrit par la littérature sur les outils d'entreprise, la moitié « trouver », et non les moitiés « évaluer le risque à l'échelle de l'entreprise » ou « corriger la couche réseau ».

PQCensus est un outil d'analyse statique local [1]. Il ne nécessite aucune clé API, aucun service hébergé, aucun téléchargement dans le cloud et aucun LLM (Large Language Model, ou grand modèle de langage) [1]. Il s'agit d'un choix de conception ayant des conséquences opérationnelles directes : une équipe peut l'exécuter au sein d'un réseau fermé ou d'un pipeline de construction isolé (air-gapped) sans envoyer de code source nulle part, et sans dépendre de la disponibilité ou du coût d'un fournisseur de modèle externe. Pour les organisations ayant des exigences strictes en matière de résidence des données ou de confidentialité concernant leur propre code source, cette conception purement locale supprime toute une catégorie de questions d'approbation et de risques liés aux fournisseurs qu'un scanner hébergé dans le cloud ou basé sur un LLM soulèverait.

L'outil trace également une frontière stricte autour de ce qu'un scan normal effectue. Le scan de dépôt normal n'importe pas intentionnellement les paquets cibles, n'installe pas les dépendances cibles, n'exécute pas setup.py, les hooks de cycle de vie des paquets, les Makefiles, les scripts shell, les tests, les binaires, les conteneurs ou les builds arbitraires, et il ne suit pas les liens symboliques en dehors de la racine de scan demandée [1]. Cela signifie qu'un scan est une passe en lecture seule au niveau de la source : il n'exécutera pas de code, ne tirera pas de dépendances tierces pour les inspecter dynamiquement, et ne s'égarera pas en dehors du répertoire vers lequel un utilisateur le pointe. Il s'agit d'une propriété de sécurité importante pour quiconque exécute l'outil contre du code non fiable ou tiers, car cela supprime le risque que le scan lui-même déclenche une exécution de code arbitraire.

PQCensus est également explicite sur ce qu'il ne revendiquera pas. Il ne prétend pas à une certification NIST, et il n'étiquettera pas un dépôt « sécurisé quantique » simplement parce qu'un scan est revenu propre [1]. C'est une limitation significative à communiquer à toute partie prenante qui pourrait autrement lire « zéro résultat » comme « sécurisé ». Un scan propre selon cette conception peut signifier soit qu'aucune cryptographie pertinente n'existe dans la source scannée, soit que la couverture de l'analyseur n'a pas atteint le code pertinent, et l'outil lui-même ne distingue pas ces deux cas comme le ferait une certification.

Pris ensemble, ces trois faits de conception, aucune dépendance au cloud, aucune exécution de code pendant le scan, et aucune revendication de certification, décrivent un outil destiné à être une première étape conservatrice et inspectable, et non un verdict final sur la posture post-quantique d'une application [1]. Un développeur adoptant PQCensus devrait traiter sa sortie comme un inventaire de départ à examiner et à étendre, et non comme un artefact de conformité qui clôture un audit de migration par lui-même.

L'analyseur de langage source stable dans PQCensus est basé sur l'AST Python [1]. Cela signifie que l'outil analyse la source Python dans son arbre syntaxique abstrait et inspecte cette structure, plutôt que de faire du texte brut ou de la correspondance par expression régulière, pour le langage qu'il traite comme prêt pour la production. Travailler à partir de l'AST plutôt que du texte brut permet à l'analyseur de raisonner sur les symboles, les appels et la structure plutôt que sur des motifs de chaînes de caractères en surface, ce qui explique probablement pourquoi c'est le seul analyseur décrit comme stable.

La couverture pour d'autres langages, JavaScript/TypeScript, Go, Java, Rust et C/C++, est décrite comme une couverture textuelle, et elle est explicitement expérimentale et délibérément de moindre confiance [1]. La propre documentation de l'outil indique que cela n'est pas présenté comme équivalent à l'analyseur Python [1]. Un développeur devrait lire cela comme suit : traitez les résultats non-Python comme un indice de départ à étudier manuellement, et non comme un résultat ayant le même poids probant qu'un résultat basé sur l'AST Python. La distinction entre l'analyse structurelle (AST) et la couverture textuelle est énoncée directement dans le matériel source, et c'est le signal le plus clair disponible sur l'endroit où réside réellement la confiance de l'outil aujourd'hui.

Chaque résultat produit par PQCensus préserve un ensemble spécifique de champs de preuves révisables : identifiants de résultat et de règle stables, chemin et étendue de la source, informations sur les symboles/appels, algorithme et objectif, analyseur et confiance, références de règle/autorité, risque contextuel et entrées HNDL (harvest-now-decrypt-later, ou récolter maintenant pour déchiffrer plus tard), état de suppression, et cibles de migration, la cible de migration n'étant incluse que lorsque les preuves d'objectif soutiennent le mappage [1]. Cette liste de champs est le mécanisme central par lequel l'outil soutient la planification de la migration : chaque résultat n'est pas juste un indicateur, c'est un enregistrement autonome et auditable qu'un réviseur ou un outil en aval peut retracer jusqu'à un fichier, une étendue de ligne et une classification algorithme/objectif exacts. Parce que les identifiants sont décrits comme stables, une équipe peut comparer les résultats à travers des scans successifs du même dépôt et suivre si un résultat donné persiste, disparaît ou est supprimé, sans perdre le fil entre les scans.

L'étape de classification de l'objectif est la charnière sur laquelle tourne l'orientation de la migration. Lorsque l'analyseur ne peut pas établir l'objectif avec confiance, il étiquette le résultat UNKNOWN (inconnu), et l'objectif UNKNOWN ne reçoit pas de cible de migration PQC automatique [1]. C'est le mécanisme concret derrière la quatrième question d'ingénierie à laquelle l'outil cherche à répondre, ce qui peut être migré ensuite, sans inventer une cible lorsque les preuves sont ambiguës [1]. Cet état UNKNOWN n'est pas un échec du scan ; c'est un refus délibéré de deviner, ce qui est cohérent avec la position globale de l'outil de préférer un écart honnête à une réponse fabriquée.

Lorsque PQCensus propose une cible de migration candidate, il est prudent quant au statut de cette suggestion. Les cibles de migration candidates sont décrites comme des conseils d'ingénierie, et non comme des promesses de compatibilité immédiate [1]. La propre documentation de l'outil liste ce qui doit encore être validé avant qu'une telle cible puisse être adoptée : protocole, PKI (Public Key Infrastructure, ou infrastructure à clés publiques), HSM/KMS (Hardware Security Module / Key Management Service), support des pairs, taille des messages, cycle de vie, restauration et contraintes opérationnelles [1]. Il s'agit d'une liste de contrôle longue et spécifique, et elle signale qu'un champ de cible de migration est le début d'une enquête d'ingénierie, et non la fin.

Ce qualificatif est important pour quiconque construit un plan de migration sur la base des résultats de PQCensus. Un champ de cible de migration rempli dans un enregistrement de résultat indique à un réviseur quelle primitive post-quantique pourrait remplacer celle classique utilisée, compte tenu des preuves d'objectif disponibles, mais il ne vérifie pas que le système environnant, une pile TLS, une hiérarchie PKI, un module de sécurité matériel, ou un pair qui doit également supporter le nouvel algorithme, peut réellement accepter cet échange. Chacun des huit éléments de validation listés ci-dessus correspond à une dépendance de déploiement réelle qu'un scanner purement au niveau de la source ne peut pas observer à partir du code seul.

Cette retenue est cohérente avec la conception de base déclarée de l'outil dans la première section : ne pas inventer une cible lorsque les preuves sont ambiguës [1]. Elle se connecte également directement à la règle de l'objectif UNKNOWN : si l'objectif d'un appel cryptographique ne peut pas être établi, aucune cible n'est proposée du tout, plutôt qu'une cible devinée [1]. Les deux règles décrivent ensemble une politique sous-jacente unique : ne rapporter une cible de migration que lorsque la chaîne de preuves, du site d'appel à l'objectif jusqu'au remplacement plausible, est intacte de bout en bout.

Pour un développeur, la conclusion pratique est que les résultats de PQCensus doivent être lus en deux niveaux : les résultats avec une cible de migration remplie sont des candidats pour un élément de backlog de migration, nécessitant toujours le travail de validation listé, et les résultats sans cible (objectif UNKNOWN) sont des candidats pour une enquête manuelle avant même qu'une décision de migration puisse être formulée [1]. Traiter ces deux niveaux avec des flux de travail différents, plutôt que de les fusionner en un seul backlog, maintient la prudence probante de l'outil intacte à mesure que la sortie passe dans le processus de planification d'une équipe.

PQCensus rapporte son efficacité à travers trois couches de benchmark distinctes et de plus en plus réalistes, et chaque couche a sa propre taille d'échantillon et ses propres conditions ; elles ne doivent pas être regroupées en un seul chiffre global. Sur la couche de benchmark sémantique synthétique, composée de 26 cas et 26 résultats étiquetés, PQCensus a atteint 26 vrais positifs, 0 faux positifs et 0 faux négatifs [1]. Il s'agit d'un test synthétique entièrement contrôlé : chaque cas a une étiquette connue, et l'outil a fait correspondre chacun d'eux exactement. Un score parfait sur une couche synthétique construite spécifiquement pour exercer des motifs sémantiques connus est un comportement attendu pour un analyseur bien réglé, et il doit être lu comme une vérification que le moteur de règles fonctionne comme prévu, plutôt que comme une preuve concernant du code réel arbitraire.

Sur la couche de benchmark des extraits amont sélectionnés, composée de 5 extraits et 6 sites d'appel étiquetés, PQCensus a atteint 6 vrais positifs, 0 faux positifs et 0 faux négatifs [1]. Cette couche passe des constructions synthétiques à de courts extraits tirés de code amont réel, toujours un échantillon petit et sélectionné, mais plus proche de la forme du code réel que la couche synthétique. La taille de l'échantillon ici, cinq extraits et six sites d'appel, est suffisamment petite pour qu'un seul site d'appel manqué ou mal classé aurait produit un score visiblement pire, donc le résultat parfait doit être lu à la lumière de ce petit dénominateur.

Sur la couche de benchmark des dépôts de bout en bout épinglés, utilisant python-jose 3.3.0 plus PyJWT 2.10.1 sur 96 fichiers, PQCensus a produit 193 résultats et a fait correspondre 12 des 12 observations requises [1]. C'est la plus réaliste des trois couches : deux paquets réels, version épinglée, scannés en entier, plutôt que des extraits isolés. Le chiffre de 193 résultats est un décompte brut de ce que le scanner a fait apparaître, et le chiffre de 12 sur 12 est le sous-ensemble de ces résultats que le benchmark avait prédéfini comme requis, les deux ont été correspondus. Il vaut la peine de noter explicitement que 193 résultats totaux contre 12 observations requises signifie que la majorité des résultats dans cette couche réelle ne sont pas directement notés par rapport à une vérité de terrain étiquetée dans le chiffre rapporté ; le chiffre de 12 sur 12 établit que le sous-ensemble requis et étiqueté a été entièrement récupéré, mais il n'établit pas par lui-même un chiffre de précision sur l'ensemble des 193 résultats.

Aucune affirmation ne donne ces chiffres par rapport à un outil de référence externe, donc aucun chiffre de précision comparative (par exemple, par rapport à dotnet-cbom ou un autre scanner) ne peut être rapporté ici ; chaque chiffre ne tient que par rapport à sa propre vérité de terrain étiquetée au sein de sa propre couche [1]. Un développeur qui veut savoir comment PQCensus se comporterait sur sa propre base de code non sélectionnée devrait traiter les trois chiffres comme des bornes supérieures obtenues dans des conditions favorables, sélectionnées ou épinglées, et non comme des garanties qui se transfèrent automatiquement à un dépôt arbitraire.

dotnet-cbom est un outil séparé et connexe pour un écosystème différent : il utilise l'analyse statique Roslyn pour inventorier l'utilisation cryptographique, classer le risque quantique et démontrer les progrès de la migration post-quantique, ciblant le code .NET [7]. Il découvre la cryptographie à travers System.Security.Cryptography, la validation JWT, la gestion TLS/certificat et les API post-quantiques (ML-KEM/ML-DSA/SLH-DSA), en attachant une confiance de détection à chaque résultat [7]. Il classe chaque résultat sur deux axes indépendants, faiblesse classique et vulnérabilité quantique, plutôt que sur une étiquette de risque unique [7]. Cette conception à deux axes est un schéma de classification plus élaboré que tout ce qui est décrit pour PQCensus, qui rapporte l'algorithme, l'objectif et une cible de migration lorsque cela est justifié, mais ne rapporte pas de score de risque à deux axes dans les affirmations disponibles ici.

dotnet-cbom produit également des sorties lisibles par machine et par humain : CycloneDX 1.6, SARIF 2.1.0, Markdown, HTML et un résumé exécutif [7]. Il suit le changement au fil du temps avec un mécanisme de diff/--baseline qui tamponne chaque résultat comme Nouveau, Inchangé, Régressé ou Renoncé [7], et il valide ses propres CBOM générés par rapport au schéma JSON officiel CycloneDX 1.6 et au profil dotnet-cbom [7]. Il voit la cryptographie tierce par la détection Bouncy Castle et un inventaire de manifeste de paquet tiré de project.assets.json / PackageReference [7], et au moment de son readme, il compte 17 règles [7]. Sa formule de risque pour un résultat unique est 0,45 fois Q plus 0,35 fois C plus 0,20 fois X, combinant les facteurs quantiques, de faiblesse classique et d'exposition à l'utilisation, avec des planchers de fermeture en cas d'échec [7], et son score de préparation PQC est défini comme 100 fois le poids de sécurité divisé par le poids total, calculé sur les algorithmes pertinents pour le quantique uniquement [7]. Il mesure sa propre précision avec un benchmark de précision de corpus étiqueté qui exécute des détecteurs réels contre une vérité de terrain rédigée indépendamment et échoue l'intégration continue (CI) sur toute régression [7]. Cette dernière propriété, une porte de régression intégrée à la CI sur la précision, est une forme de validation continue qui n'est pas décrite pour PQCensus dans les affirmations disponibles ici ; les chiffres de benchmark de PQCensus sont rapportés comme des résultats ponctuels à travers les trois couches décrites ci-dessus.

Deux clarifications importent ici. Premièrement, les passages décrivant dotnet-cbom ne décrivent pas du tout PQCensus ; ils décrivent une tâche de migration basée sur contrat pour les agents de codage et le générateur dotnet-cbom séparé [5]. Deuxièmement, l'Inventory Generator et le Quantum Risk Analyzer Engine de TCS sont proposés comme une paire d'outils pour les applications d'entreprise en général, et non comme une méthode d'analyse statique avec des chiffres de précision/rappel rapportés dans le matériel disponible [13]. Aucune de ces sources ne rapporte un benchmark partagé, une base de code partagée ou une exécution face à face contre PQCensus, donc cette section est une description côte à côte de systèmes rapportés séparément, et non une comparaison de précision mesurée.

Au-delà des outils d'inventaire au niveau de la source, le défi de migration plus large touche également à d'autres dimensions que ces outils ne couvrent pas. La migration basée sur des agents de codage, testée via une tâche basée sur contrat déplaçant un signataire de fichier Go de RSA vers ML-DSA-44 sur 160 tentatives dans quatre configurations d'agent local, a produit douze correctifs finaux qui passent la vérification locale mais échouent aux exigences externes [5]. L'accès au vérificateur n'a pas augmenté le taux de complétion observé dans aucune comparaison de cette étude [5], réduire la fenêtre de contexte d'un modèle de 128K à 32K a abaissé les passages complets de 36/40 à 4/40 [5], et quatre essais exploratoires utilisant deux autres combinaisons modèle/outil ont passé les 40 vérifications, y compris les deux lignes de base [5]. Il s'agit d'un problème distinct, la transformation de code automatisée, et non l'inventaire, et il est rapporté sur un benchmark différent (une tâche de migration de signataire Go unique) que n'importe quel chiffre PQCensus. C'est un contraste utile pour un développeur néanmoins : il montre que même là où un inventaire identifie correctement un site d'appel cryptographique et une cible de migration plausible, l'acte en aval de réécrire réellement le code pour utiliser cette cible est une tâche séparée et, selon cette étude, toujours sujette aux erreurs, avec douze tentatives sur 160 passant les vérifications locales mais échouant aux exigences externes [5].

La valeur d'un outil d'inventaire dépend en partie de ce qui se passe après l'identification d'une cible de migration, et la littérature signale que les algorithmes eux-mêmes ne sont pas interchangeables en termes de coût. Les besoins en énergie, bande passante et latence des algorithmes PQC couvrent plusieurs ordres de grandeur, et cela est suffisamment substantiel pour impacter l'autonomie de la batterie, l'expérience utilisateur et la conception des protocoles d'application [6]. C'est une conséquence directe pour tout plan de migration construit à partir d'un résultat PQCensus : une cible de migration proposée est un algorithme candidat, mais son profil de ressources nécessite toujours une évaluation séparée avant d'être adopté à grande échelle.

Pour les contextes mobiles et connectés au cloud spécifiquement, les schémas PQC à réseau structuré rapide sont rapportés comme le choix préféré pour les appareils mobiles connectés au cloud dans la plupart des cas d'utilisation, même lorsque le coût énergétique de transmission de données par bit de ces schémas est relativement élevé [6]. Ce résultat illustre pourquoi la propre prudence de PQCensus, à savoir qu'une cible de migration est un conseil d'ingénierie et non une promesse de compatibilité immédiate [1], est bien fondée : même un algorithme candidat techniquement correct peut entraîner des coûts opérationnels très différents selon le contexte de déploiement, et un schéma qui est rapide sur l'appareil peut toujours être coûteux à transmettre, ce qui compte différemment pour un client mobile alimenté par batterie que pour un serveur.

Cela renforce également pourquoi PQCensus préserve le risque contextuel et les entrées HNDL comme champs de preuves sur chaque résultat [1], puisque l'exposition au risque « récolter maintenant pour déchiffrer plus tard » et le contexte de déploiement, mobile versus serveur par exemple, affectent tous deux l'urgence et la manière dont un résultat donné doit être migré, même avant que les compromis énergie et bande passante ne soient pesés [6]. Un résultat marqué avec une exposition HNDL élevée mais destiné à un déploiement mobile aux ressources limitées se situe à l'intersection de deux préoccupations distinctes, l'urgence de la migration et le coût de l'algorithme de remplacement, qu'un développeur doit peser ensemble plutôt qu'isolément.

Aucune affirmation ne lie un résultat PQCensus spécifique à une mesure d'énergie ou de bande passante spécifique, donc cette connexion est présentée ici comme deux faits rapportés séparément qu'un développeur doit combiner manuellement : PQCensus vous dit où une primitive classique est utilisée et ce qui pourrait la remplacer [1] ; la littérature sur l'énergie mobile vous dit que le coût des ressources du remplacement nécessite toujours une évaluation séparée avant le déploiement [6]. Combiner les deux nécessite une étape manuelle qu'aucune source n'effectue par elle-même, et un développeur devrait budgétiser un temps d'ingénierie explicite pour cela plutôt que de supposer que la cible de migration de l'outil d'inventaire prend déjà en compte le coût de déploiement.

La limite la plus immédiate est le statut de version : aucune preuve de version canonique n'est actuellement établie pour PQCensus, et aucune version GitHub ou PyPI n'est autorisée au moment du matériel source [1]. Un développeur évaluant cet outil aujourd'hui regarde un projet sans artefact de version stable et citable, ce qui affecte la confiance à long terme qu'une équipe devrait accorder au comportement d'une version particulière sans épingler à un commit ou un build spécifique.

La deuxième limite est la couverture linguistique. Seul l'analyseur Python est décrit comme stable et basé sur l'AST [1] ; le support de JavaScript/TypeScript, Go, Java, Rust et C/C++ est expérimental, basé sur le texte et délibérément de moindre confiance, explicitement non équivalent à l'analyseur Python [1]. Toute organisation avec une base de code multilingue devrait s'attendre à des garanties matériellement plus faibles en dehors de Python, et ne devrait pas supposer que les mêmes taux de faux positifs et de faux négatifs rapportés sur les benchmarks orientés Python tiendraient pour un dépôt Go ou Java.

La troisième limite est le périmètre. L'outil n'exécute pas les dépendances installées, les étapes de build, les tests ou les conteneurs pendant un scan normal [1], donc toute cryptographie dont l'utilisation n'apparaît qu'au moment de l'exécution, à l'intérieur du comportement compilé d'une dépendance, ou via une configuration non visible dans la source statique, est hors de portée de cette méthode par conception. Il ne fait également aucune revendication sur la certification ou un statut global « sécurisé quantique » [1], et aucune affirmation dans le matériel disponible ne donne un chiffre de précision pour des dépôts réels non sélectionnés au-delà du benchmark de deux paquets épinglés rapporté [1]. Cela signifie que la précision démontrée de l'outil repose sur une couche synthétique, une petite couche d'extraits sélectionnés et une seule couche de bout en bout de deux paquets épinglés ; aucune de celles-ci n'établit un chiffre de précision général à travers des dépôts arbitraires, non vus et non sélectionnés.

Enfin, cette note ne peut pas rapporter une comparaison mesurée face à face entre PQCensus et tout autre outil, dotnet-cbom, l'Inventory Generator de TCS ou les méthodes de migration basées sur des agents de codage, car aucune affirmation n'en fournit une. Les chiffres de chaque outil ne tiennent que par rapport à son propre benchmark et ses propres conditions rapportés : les trois couches de PQCensus [1], le benchmark de précision de corpus étiqueté de dotnet-cbom [7], et la tâche de 160 tentatives et quatre configurations de l'étude sur les agents de codage [5]. Un développeur qui a besoin d'une décision comparative entre ces approches devrait effectuer une telle comparaison directement, sur la même base de code, puisqu'aucune n'existe actuellement dans les preuves citées.

1. Confirmez la langue principale de la base de code cible avant de commencer. Si c'est Python, prévoyez de vous appuyer sur l'analyseur stable basé sur l'AST de PQCensus [1] ; s'il inclut JavaScript/TypeScript, Go, Java, Rust ou C/C++, prévoyez que ces résultats soient des résultats expérimentaux, de moindre confiance, basés sur le texte qui nécessitent un suivi manuel plutôt qu'une confiance automatique [1].
2. Configurez le scan pour qu'il s'exécute localement, sans clé API, service hébergé, téléchargement dans le cloud ou dépendance LLM, afin que la base de code ne quitte jamais votre environnement [1]. Cela signifie également que vous pouvez l'exécuter à l'intérieur d'un pipeline CI fermé sans appels réseau externes, ce qui est utile pour les bases de code soumises à des exigences de confidentialité strictes.
3. Avant d'exécuter, vérifiez que le scan n'exécutera rien : il ne doit pas importer ou installer de paquets cibles, exécuter setup.py, les hooks de cycle de vie des paquets, les Makefiles, les scripts shell, les tests, les binaires, les conteneurs ou les builds arbitraires, et il ne doit pas suivre les liens symboliques en dehors de la racine de scan [1]. Si votre wrapper de build fait l'une de ces choses automatiquement, désactivez ce comportement pour la passe de scan, afin que le scan reste une opération purement en lecture seule au niveau de la source.
4. Exécutez le scan contre la racine du dépôt et collectez l'ensemble des résultats. Chaque résultat doit porter : un identifiant de résultat et de règle stable, le chemin et l'étendue de la source, les informations sur les symboles/appels, l'algorithme et l'objectif, l'analyseur et la confiance, les références de règle/autorité, le risque contextuel et les entrées HNDL, l'état de suppression et, uniquement là où les preuves d'objectif le soutiennent, une cible de migration [1]. Stockez-les comme votre base de preuves, indexée par les identifiants stables afin que les scans ultérieurs puissent être comparés par rapport à elle.
5. Séparez immédiatement les résultats en deux seaux : ceux avec une cible de migration remplie, et ceux étiquetés objectif UNKNOWN sans cible [1]. Acheminez le seau UNKNOWN vers une revue de code manuelle ; n'essayez pas de le migrer automatiquement, car l'outil lui-même a refusé de proposer une cible précisément parce que les preuves ne le soutenaient pas.
6. Pour chaque résultat avec une cible de migration, traitez-le strictement comme un conseil d'ingénierie, et non comme un remplacement immédiat [1]. Ouvrez une liste de contrôle de validation par résultat couvrant le protocole, la PKI, le HSM/KMS, le support des pairs, la taille des messages, le cycle de vie, la restauration et les contraintes opérationnelles [1], et ne fermez pas l'élément de migration tant que chacun n'est pas vérifié.
7. Croisez le contexte de déploiement de chaque résultat validé avec les coûts de ressources connus : si l'environnement cible est mobile ou connecté au cloud, notez que les schémas PQC varient en énergie, bande passante et latence par ordres de grandeur [6], et que les schémas à réseau structuré rapide sont généralement préférés pour les appareils mobiles connectés au cloud même à un coût énergétique de transmission par bit relativement élevé [6]. Enregistrez cela comme un élément de ligne séparé, puisque PQCensus lui-même ne mesure pas le coût des ressources.
8. Validez la sortie de l'outil par rapport aux couches de benchmark rapportées avant de lui faire confiance sur votre propre base de code : vérifiez si vos cas de test ressemblent à la couche sémantique synthétique (26 cas/26 résultats étiquetés, VP 26 FP 0 FN 0) [1], la couche d'extraits amont sélectionnés (5 extraits/6 sites d'appel, VP 6 FP 0 FN 0) [1], ou la couche de bout en bout épinglée (python-jose 3.3.0 plus PyJWT 2.10.1, 96 fichiers, 193 résultats, 12/12 observations requises correspondus) [1]. Ne supposez pas que ces chiffres se transfèrent à une base de code non liée et non sélectionnée, puisque chacun a été obtenu dans ses propres conditions contrôlées ou sélectionnées.
9. Ne rapportez pas un scan propre (zéro résultat) comme une certification ou une revendication de sécurité globale. PQCensus lui-même ne prétend pas à une certification NIST ou n'étiquette pas un dépôt sécurisé quantique à partir d'un scan statique propre [1], et tout rapport en aval que votre équipe produit devrait porter la même mise en garde plutôt que de mettre à niveau silencieusement un scan propre en une garantie de sécurité.
10. Si la base de code dépend également de l'infrastructure réseau d'entreprise, telle qu'IPsec, TLS ou les services WAN définis par logiciel qui authentifient les pairs avec une cryptographie à clé publique vulnérable au quantique, traitez cela comme une tâche d'inventaire séparée en dehors du périmètre de PQCensus [11], puisque le scan au niveau de la source n'examine pas directement la configuration réseau ou protocolaire.
11. Lorsqu'une cible de migration a été validée et que la base de code est Python, considérez si une étape de transformation de code automatisée (un agent de codage, par exemple) sera utilisée pour appliquer le changement ; si c'est le cas, budgétisez des échecs de vérification même après que les vérifications locales passent, puisqu'une étude d'une tâche de migration analogue de RSA vers ML-DSA-44 a trouvé que douze tentatives sur 160 à travers quatre configurations d'agent ont passé la vérification locale mais ont échoué aux exigences externes [5].
12. Gardez l'enregistrement complet des preuves, pas seulement un résumé succès/échec, pour chaque résultat qui va dans un backlog de migration. Parce que PQCensus préserve les identifiants de résultat et de règle stables, le chemin et l'étendue de la source, et l'état de suppression dans le cadre de ses champs de preuves [1], un réviseur des mois plus tard peut rouvrir le raisonnement exact derrière une décision de migrer, supprimer ou laisser un résultat comme UNKNOWN, ce qui est le but de préserver des preuves révisables en premier lieu.

pour fichier dans dépôt (Python, analysé par AST):
    pour site_appel dans fichier:
        classifier(algorithme, objectif)
        si objectif == UNKNOWN:
            enregistrer résultat (pas de cible de migration)
        sinon:
            enregistrer résultat (cible de migration = primitive PQC candidate)
    attacher : id, id règle, chemin, étendue, info symbole/appel,
            analyseur, confiance, références règle/autorité,
            risque contextuel, entrées HNDL, état de suppression
examiner le seau UNKNOWN manuellement
pour chaque résultat avec une cible:
    valider protocole, PKI, HSM/KMS, support des pairs,
             taille message, cycle de vie, restauration, contraintes ops
    vérifier coût des ressources pour contexte de déploiement (mobile/serveur)