Je regardais Newton Explorer ce matin et quelque chose de petit mais d’important a retenu mon attention.
Chaque évaluation laisse derrière elle un reçu signé, déposé sur la chaîne. À première vue, cela ressemble à toute l’histoire. La politique a été appliquée, la décision a été prise et la preuve cryptographique existe. Du point de vue de l’audit, cela paraît propre. Du point de vue de la conformité, cela paraît solide. Et du point de vue du produit, il est facile d’assumer que cela suffit à expliquer ce qui s’est passé.
Mais plus je l’observais, plus je réalisais qu’un reçu et un historique de règles ne sont pas la même chose.
Un reçu indique qu’une politique a été évaluée à un moment précis. Il vous apprend que le système a produit un résultat valide selon une version donnée des règles. Mais il ne dit pas automatiquement quelles étaient ces règles, si elles ont été modifiées par la suite, ni si la politique active reflète encore l’intention actuelle du responsable de la collecte.
Cette distinction compte plus qu’il n’y paraît d’abord.
Si un responsable met à jour une politique Rego au fil du temps, alors chaque reçu est lié au hash de la politique qui était actif au moment de l’évaluation. C’est utile. Cela préserve l’intégrité. Mais cela signifie aussi qu’un reçu consulté aujourd’hui peut appartenir à une version de la politique qui n’est plus à jour. En d’autres termes, la preuve est réelle, mais le contexte peut avoir évolué.
Ce n’est pas vraiment une faiblesse. C’est plutôt un problème de documentation. Un système technique peut vérifier que quelque chose s’est produit correctement sans rendre immédiatement évident comment les règles sous-jacentes ont évolué. Pour un régulateur, un répartiteur (allocateur) ou même un développeur qui cherche à examiner le passé, cette différence est essentielle. Un reçu valide seul peut ne pas suffire pour reconstituer la posture de conformité, à moins que la trace des versions de la politique soit aussi facile à inspecter.
C’est la partie que les gens peuvent manquer.
Le reçu n’est interprétable que dans la mesure où l’enregistrement de la politique qui le sous-tend l’est. Si l’Explorer affiche la preuve mais ne fait pas clairement apparaître l’historique des versions, la chronologie des mises à jour et la raison pour laquelle une politique a changé, alors le résultat ressemble davantage à un journal de décision qu’à un récit de conformité entièrement lisible. Techniquement vérifiable, oui. Immédiatement compréhensible, pas toujours.
Je me suis rendu compte de cela parce que cela m’a rappelé une erreur simple que les gens commettent dans leurs propres flux de travail. Un tableau de bord leur montre un nombre, un indicateur ou un statut, et ils lui font confiance sans vérifier si les règles qui le sous-tendent ont été actualisées, révisées ou silencieusement ajustées. Le résultat continue de paraître valide. Les hypothèses en dessous ne sont peut-être pas celles avec lesquelles ils pensent travailler.
C’est pourquoi la question importante n’est pas seulement de savoir si le reçu existe. La question est de savoir si quelqu’un qui le lit plus tard peut comprendre quelle politique l’a produit, quelle version était active, et comment cette politique s’inscrit dans l’historique plus large des changements.
Si les reçus de Newton sont censés soutenir de vrais cas d’usage de conformité, alors l’Explorer doit faire plus que montrer qu’une décision a été prise. Il doit rendre la décision lisible dans son contexte. Sans cela, la preuve reste intacte, mais l’histoire qui l’entoure peut encore sembler incomplète.
