La preuve après un incident : comment nous répondons à « qui a autorisé cela »

Une situation hypothétique, le problème derrière, et ce que nous avons construit pour qu'elle ne se répète pas

La situation

Un client vient nous voir — pas une startup, mais une entreprise avec un processus : demandes, validations, paiements. Nous déployons un agent qui conduit une partie de ce processus. Deux mois plus tard, un incident : l'agent a envoyé un paiement que personne n'avait validé.

L'analyse commence par une question simple : « montrez-nous sur quelle base il l'a fait ». Et il s'avère qu'il n'y a rien à montrer.

Il y a des journaux. Il y a un fil de conversation. Il y a un export CRM. Mais aucun de ces artefacts ne répond si l'agent avait le droit de faire cette action à cette seconde-là, ni qui le lui avait accordé. L'autorisation est à un endroit, la décision à un autre, l'envoi à un troisième, et le fait d'exécution chez le destinataire — et personne ne les a jamais vérifiés ensemble.

Le problème

Nous l'avons formulé ainsi : il y a un écart entre autorisation, décision, envoi et effet, et l'industrie le comble par des assurances plutôt que par des preuves.

L'attestation et les standards d'identité répondent à « qui est de l'autre côté » : quel workload, quelle clé. C'est nécessaire, mais cela ne répond pas à « de quel droit avez-vous agi ». Un serveur correctement attesté peut accepter une action hors du périmètre délégué sans qu'aucune propriété d'attestation ne soit violée.

Les journaux répondent à « que s'est-il passé », pas à « était-ce permis ». Un enregistrement peut être complet et décrire une action que personne n'a autorisée.

Après un incident, le client reste donc avec beaucoup de données et sans réponse. Et le fournisseur avec « tout est journalisé », qui ne résiste pas à une revue.

Ce que nous avons construit

Nous n'avons pas construit une implémentation d'agent de plus. Nous avons construit un instrument qui permet de vérifier des affirmations sur les autorisations — les nôtres et celles des autres — selon un même règlement.

Un contrat de comparaison. Quatre scénarios qui cassent presque toute conception : refus au point de décision, décision sur preuve périmée, instance approbatrice injoignable, révocation après envoi. Quatorze champs obligatoires — de l'autorisation et de la décision jusqu'à l'effet réel, le reçu, l'empreinte de l'action, l'échéance et le nombre de reprises. Quatre états de preuve : mesuré, non applicable, non émis, non mesuré.

Ce dernier est décisif. Il interdit la principale manipulation des rapports : présenter « nous n'avons pas mesuré » comme « cela ne s'applique pas ».

Un vérificateur hors ligne avec contrôles négatifs. Le contrôle doit rejeter un paquet où un cas a été supprimé, dupliqué, un verdict inversé, un enregistrement cité retiré, ou deux lignes échangé leurs reçus. Et il doit accepter le paquet inchangé. Cela ressemble à une formalité jusqu'au jour où cela se déclenche : dans un paquet publié, un enregistrement affirmait que l'exécutant avait refusé à sa frontière, tandis que l'enregistrement du job montrait une tentative bloquée et un refus plus tard, à la reprise. Aucun contrôle d'intégrité ne l'attrape — seule la confrontation de l'affirmation avec l'enregistrement le fait.

L'ouverture. Le contrat, les cas et les règles de refus sont publiés ; le travail se fait dans un groupe de travail ouvert sur l'identité et la confiance, avec des résultats dans un dépôt public et un article en relecture. Nous ne demandons pas d'être crus sur parole : chacun peut prendre un paquet et lancer le contrôle.

Ce que cela apporte au client

Après un incident — non pas un « journal », mais une analyse : quelle autorisation s'appliquait, quelle décision a été prise, ce qui a été envoyé, ce qui s'est produit côté destinataire et où les preuves manquent. Avant un incident — la possibilité de convenir à l'avance de ce qui est normal et de ce qui est un incident.

Et surtout, la possibilité de nous vérifier par un tiers. C'est précisément ce qui manque à « faites-nous confiance, tout est sous contrôle ».

Ce que nous n'affirmons pas

Nous ne délivrons pas de certificats et ne revendiquons aucune conformité à un standard. Nous n'avons pas prouvé qu'un agent est sûr en général. Nous disons clairement qu'une partie de la garantie vit chez l'exécutant et la cible : nous pouvons montrer qu'une décision a été prise dans le cadre de l'autorisation accordée, mais nous ne pouvons pas prouver seuls que le destinataire a exécuté exactement cette action.

Et nous énonçons les limites de notre méthode : la comparaison est hors ligne, sur des enregistrements conservés ; elle n'établit pas l'application en direct ni les effets côté cible.

À quoi cela ressemble en pratique

Un pilote : nous examinons les enregistrements de votre agent, les passons dans le contrat et montrons ce qu'ils prouvent et ce qu'ils ne prouvent pas. Ensuite, soit l'enregistrement est amélioré, soit les frontières de l'autorisation sont modifiées, soit la partie non couverte est écrite honnêtement dans le contrat.

Si vous avez un agent en production et la question « que montrerons-nous si quelque chose tourne mal » — c'est là que nous commençons.