Comment prouver ce qu'une IA a répondu ?

La réponse courte

Une réponse d'IA se prouve avec un certificat signé, pas avec une capture d'écran ni un journal que l'on a écrit soi-même. Le certificat engage, par des empreintes, trois choses : ce qui a été demandé, ce qui est réellement parti vers le fournisseur du modèle, et ce qui est revenu. Il est signé, puis chaîné au certificat précédent. Un tiers qui détient le fichier et la clé publique le vérifie seul.

Subsidia émet un certificat de ce type pour chaque réponse qui passe par son Gateway. La suite explique comment cela fonctionne et, surtout, jusqu'où cela va.

Pourquoi un journal ordinaire ne suffit pas

Quand un client conteste une réponse, ou qu'un auditeur demande comment l'IA est utilisée, il faut établir quel modèle a répondu, à partir de quoi, et dans quel ordre les choses se sont passées. Un journal applicatif est écrit par la partie qu'il met en cause : il s'efface, se corrige, et ne se vérifie pas sans son auteur.

Un certificat répond à trois exigences :

• Intégrité : si un caractère change, la vérification échoue.
• Origine : seule la clé privée de l'émetteur peut produire une signature valide ; la clé publique suffit pour contrôler.
• Continuité : on ne peut pas retirer un maillon sans que cela se voie.

Ce que contient un certificat

Le certificat est un document JSON : un contenu (le payload), son empreinte (payload_hash) et une ou plusieurs signatures. Le contenu comprend :

Deux détails comptent. Le certificat est enregistré avant que la réponse ne se termine : si vous voyez l'en-tête x-pulse-proof, le certificat existe. Et en flux continu, ce que l'utilisateur a vu défiler est ce qui est signé.

Ce que le certificat ne contient pas

Aucun texte. Ni la question, ni la réponse, ni vos documents : seulement des empreintes. C'est ce qui permet de le remettre à un tiers.

Pour un appel rattaché à un espace de travail, ces empreintes sont calculées avec un secret propre à l'espace (engagement à clé, HMAC-SHA-256). Une phrase courte ne peut donc pas être confirmée par dictionnaire à partir du seul certificat, alors que les membres de l'espace peuvent toujours re-vérifier le contenu. Certaines empreintes restent simples, par exemple celles des étapes d'une trace d'agent ; leur confirmation par dictionnaire est possible pour qui devine le contenu.

Un point d'honnêteté : un certificat émis avant le retrait des noms de fichiers peut nommer les pièces citées. La page de contrôle le signale lorsqu'elle le détecte.

Comment un tiers le vérifie

Le calcul tient en trois étapes, que la page /certificat réalise dans votre navigateur :

1. L'empreinte. Le contenu est remis en forme canonique (JSON dont les clés sont triées récursivement, sans espaces), encodé en UTF-8, puis haché en SHA-256. Le résultat doit être égal à payload_hash.
2. La signature. La signature Ed25519 porte sur les octets UTF-8 de l'empreinte hexadécimale. On la vérifie avec la clé publique de l'émetteur.
3. La chaîne. Chaque certificat contient l'empreinte du précédent ; deux certificats voisins se relient, et un retrait apparaît comme un index manquant.

En Node, sans rien installer de Subsidia, le cœur du contrôle ressemble à ceci :

const hash = sha256hex(canonicalJson(cert.payload)) // clés triées
if (hash !== cert.payload_hash) throw new Error("contenu modifié")
const ok = crypto.verify(null,
  Buffer.from(cert.payload_hash, "utf8"),
  crypto.createPublicKey(clePubliquePem),
  Buffer.from(cert.signature, "base64"))

La clé publique s'obtient sans authentification (GET /v1/gateway/public-key). Le paquet @protypa/subsidia-verify, sans dépendance, couvre aussi les certificats à double signature, la chaîne et l'ancrage horodaté ; le détail est dans le guide de vérification.

Signature hybride et chaîne

Les certificats actuels (v2) portent deux signatures sur les mêmes octets : Ed25519 et ML-DSA-65, un schéma de signature à réseaux euclidiens normalisé par le NIST (FIPS 204). Les algorithmes exigés sont inscrits dans les octets signés : retirer la signature post-quantique d'un certificat est un abaissement détectable. Les certificats v1 restent vérifiables à l'identique.

La chaîne est unique : les réponses du Gateway, les rapports du Vérificateur et les exports du Registre y sont tous ajoutés. Les mécanismes de date opposable (horodatage) sont traités dans le guide sur l'horodatage.

Ce que cela ne fait pas

Un certificat est une preuve forte sur le pipeline, et ne dit rien au-delà. Annoncez-le ainsi à celui à qui vous le montrez :

• Il ne prouve pas que la réponse est exacte. Il prouve ce qui a été répondu. Pour confronter un texte à vos pièces, utilisez le Vérificateur.
• Il n'est pas indépendant de l'émetteur. La clé de signature appartient à l'installation qui émet. Le certificat prouve que le document vient d'elle et n'a pas été modifié ; il ne peut pas prouver que l'installation a consigné la vérité, par exemple que le fournisseur a reçu exactement le texte masqué dont l'empreinte figure dans le certificat. Cette empreinte est calculée par la partie auditée.
• Il ne fournit pas de date indépendante par lui-même. La date d'émission est déclarée par l'émetteur. Seule une ancre d'horodatage RFC 3161 fixe une date que nous ne contrôlons pas, et l'ancrage est actif par défaut sur le cloud, désactivé par défaut en installation locale.
• Il ne couvre pas ce qui n'est pas passé par le Gateway. Un appel fait ailleurs n'a pas de certificat. La chaîne montre un certificat supprimé, pas un appel qui n'a jamais été fait chez nous.
• Il ne dit rien du comportement du fournisseur. Conservation, entraînement, journalisation chez le fournisseur relèvent de votre contrat avec lui. Le certificat indique quel fournisseur et quel modèle ont répondu, et si l'appel est resté local.
• Il n'atteste pas que la réponse a fidèlement utilisé les passages cités. Il montre quels passages ont été fournis au modèle, pas que le modèle les a cités exactement.
• Il n'est pas une attestation de conformité. C'est un enregistrement vérifiable, pas un avis juridique.

En pratique, pour commencer

1. Faites passer vos appels par le Gateway en changeant l'URL de base de votre client (documentation du Gateway).
2. Relevez l'en-tête x-pulse-proof de la réponse : c'est l'identifiant du certificat.
3. Téléchargez le certificat (fichier .json) depuis la fiche de preuve de la réponse, ou par GET /v1/proofs/:id.
4. Contrôlez-le sur la page de vérification, ou avec votre propre code.
5. Conservez-le avec le dossier que la réponse a servi à instruire.

Pour le cadre d'ensemble (Gateway, registre, vérificateur), voir Preuve et registre d'usage de l'IA.

Questions fréquentes

Un certificat contient-il ma question et la réponse de l'IA ?

Non. Il ne contient que des empreintes SHA-256 de la demande, de ce qui est réellement parti vers le fournisseur et de la réponse, plus des métadonnées (modèle, fournisseur, nombre de données masquées, position dans la chaîne). On peut le remettre tel quel à un client ou à un auditeur : il prouve la forme de l'échange sans en montrer le contenu.

Peut-on falsifier un certificat après coup ?

Modifier un seul caractère du contenu change l'empreinte et invalide la signature. Retirer un certificat de la chaîne laisse un trou, puisque chacun contient l'empreinte du précédent. Sans la clé privée de l'émetteur, on ne peut pas en fabriquer un qui vérifie. En revanche, l'émetteur reste la partie auditée : voir la section sur les limites.

Un certificat prouve-t-il que la réponse de l'IA est exacte ?

Non. Il prouve qu'une réponse précise a été produite par un modèle précis, à partir d'une demande précise, dans un ordre donné. Pour confronter le contenu à vos pièces, c'est le rôle du Vérificateur, qui est un contrôle distinct.

Faut-il utiliser Subsidia comme assistant pour obtenir ces certificats ?

Les certificats sortent du Gateway de Subsidia, compatible avec les formats OpenAI et Anthropic. Un outil existant (Claude Code, Cursor, n8n, LangChain) y accède en changeant l'URL de base. Chaque réponse revient avec l'identifiant de son certificat dans l'en-tête x-pulse-proof.

Mon prestataire d'IA peut-il me donner la même chose ?

Nous ne parlons que de Subsidia. La question utile à poser à n'importe quel fournisseur : le journal est-il signé, chaîné, et vérifiable par un tiers sans passer par lui ? Un historique de conversation modifiable par son auteur n'est pas une preuve.