En travaillant sur un prototype de remédiation, j’ai examiné le dossier censé conserver l’état avant et après les corrections.
À première vue, sa structure semblait crédible : des identifiants de règles, des statuts et un fichier présenté comme le scan initial.
Deux vérifications ont suffi à montrer que ce dossier ne pouvait pas être utilisé. Certains identifiants ne correspondaient à aucun contrôle réel du scanner. Le fichier présenté comme l’état initial ne contenait pas un scan : il contenait une réponse HTTP d’erreur.
Il aurait été facile de considérer ces éléments comme des données de démonstration et de poursuivre. Mais un exemple présenté comme une preuve finit presque toujours par être lu comme un résultat. La forme du dossier lui donnait une autorité que son contenu ne méritait pas.
Je l’ai supprimé et remplacé uniquement par des faits que je pouvais rattacher à une exécution réelle.
Quatre règles d’intégrité
- Un identifiant de preuve doit référencer un contrôle existant.
- Un artefact doit être validé avant d’être archivé.
- Une erreur de collecte doit apparaître comme une erreur, jamais comme un résultat.
- Une donnée synthétique doit être explicitement identifiée comme telle.
La qualité d’une preuve ne dépend pas de son apparence. Un JSON bien formé peut être faux. Un rapport élégant peut agréger des identifiants imaginaires. Un pipeline peut archiver avec succès une réponse d’erreur.
La vérification doit donc porter aussi sur le mécanisme qui produit la preuve.
Pour une activité qui promet de rendre les décisions techniques défendables, ce n’est pas un détail. Une preuve douteuse n’affaiblit pas seulement un rapport : elle attaque directement la confiance placée dans toute la méthode.
Valider avant d’archiver
Contrôle minimalLe hash prouve la stabilité d’un artefact, pas sa justesse. Les deux contrôles sont nécessaires.
- Valider le schéma attendu et vérifier que le fichier n’est pas une enveloppe d’erreur HTTP archivée comme un résultat.
- Résoudre chaque identifiant vers un contrôle existant dans la version exacte du catalogue utilisée pendant l’exécution.
- Consigner le périmètre, l’horodatage UTC, la version de l’outil, le code de retour et l’empreinte SHA-256 de l’artefact.
- Marquer explicitement tout contenu synthétique, partiel ou produit après une erreur de collecte.
Frontière de preuveRevue interne. L’examen porte sur un prototype Geek Guru et sur ses propres artefacts de preuve. Aucune donnée client n’est concernée. Le constat décrit un défaut de mon outillage à un instant donné, corrigé depuis ; il ne qualifie pas la fiabilité d’un produit tiers.