---
canonical: https://validationfacture.fr/blog/journal-de-preuves-chaine
title: "Un contrôle sans preuve est une opinion : le journal de preuves chaîné"
description: "Chaque contrôle de facture produit un paquet de preuves signé et chaîné : empreintes SHA-256 des entrées et sorties, version du référentiel, signature HMAC. Pourquoi c'est la seule réponse sérieuse à « prouvez que vous l'aviez validée »."
date: "2026-08-23"
slug: "journal-de-preuves-chaine"
---

Le jour où une facture est rejetée en production — ou pire, contestée lors
d'un contrôle fiscal — la question n'est pas « était-elle valide ? » mais
« **pouvez-vous prouver ce que vous avez vérifié, quand, et contre quelles
règles ?** ». Un validateur qui répond « oui/non » sans laisser de trace
vous laisse seul face à cette question.

## Ce que contient un paquet de preuves

Chaque appel à l'API renvoie, à côté du résultat, un bloc `proof` :

```json
"proof": {
  "operation": "validate_invoice",
  "ruleset_version": "2026.08.1",
  "produced_at": "2026-08-23T20:04:11Z",
  "input_sha256": "d05bb694…",
  "outputs": { "validation_report.json": "96297ada…" },
  "verdict": { "valid": true, "errors": 0 },
  "previous_entry_sha256": "f05c01fc…",
  "entry_sha256": "…",
  "signature": "…",
  "signature_key_id": "prod-2026-08"
}
```

Trois propriétés font la différence avec un simple log :

**1. L'empreinte, pas le document.** Le journal ne stocke jamais vos
factures — uniquement leur SHA-256. Vous pouvez prouver *a posteriori* que
c'est bien ce document-là qui a été contrôlé (recalculez l'empreinte), sans
que nous conservions la moindre donnée commerciale. C'est aussi ce qui rend
notre [politique de confidentialité](/confidentialite) inhabituellement
courte : il n'y a rien à effacer, parce que rien n'est gardé.

**2. La chaîne.** Chaque entrée embarque l'empreinte de la précédente,
comme un registre à ancrage. Impossible d'insérer, de supprimer ou de
réordonner une entrée sans casser toute la chaîne aval — et l'API expose un
endpoint public de vérification qui la rejoue de bout en bout. Notre
supervision l'appelle toutes les quinze minutes ; vous pouvez le faire
aussi.

**3. La signature datée et versionnée.** L'entrée est signée (HMAC, clé
identifiée par `signature_key_id` pour permettre la rotation) et cite la
version exacte du référentiel. « Valide au sens des règles 2026.08.1 du 23
août 2026 » est une affirmation opposable ; « valide » tout court n'est
qu'une opinion.

## Le déterminisme comme prérequis

Une preuve n'a de valeur que si le contrôle est **rejouable** : même
document + même version de règles = même résultat, aujourd'hui ou dans six
ans. C'est pourquoi le moteur est délibérément sans modèle probabiliste —
pas d'IA dans le chemin de validation, des règles versionnées, des
[artefacts officiels épinglés](/blog/valider-facture-electronique-artefacts-officiels).
L'IA est un excellent client de ce service ; elle serait un très mauvais
juge.

## À quoi ça sert, concrètement

- **Pour un éditeur** : répondre à un client qui conteste un rejet avec la
  preuve du contrôle effectué avant émission, référentiel daté à l'appui.
- **Pour un cabinet** : documenter la diligence sur chaque pièce d'un
  dossier, sans archiver les pièces elles-mêmes.
- **Pour un agent autonome** : chaque dépense de son budget laisse un reçu
  vérifiable — la condition pour qu'un humain accepte de lui confier un
  budget.

Le détail opération par opération est dans la
[documentation interactive](/docs), et le premier contrôle se fait sans clé
sur le [scanner d'essai](/essai).