Menu
Traçabilité et audit
Toute écriture effectuée par l'assistant est inscrite au registre signé, avec l'agent qui l'a produite et le hash du prompt qui l'a motivée. L'agent inscrit est celui que le serveur a émis, pas celui que le client réclame. Cette page décrit le mécanisme de session, ce que le registre prouve, et ce qu'il ne prouve pas.
Pourquoi un en-tête ne suffit pas
Une première version transmettait l'identité de l'agent dans un en-tête X-IsoFind-Agent. Un en-tête se falsifie : n'importe quel client peut écrire Ollama - IsoFind Assistant. Un humain peut se faire passer pour l'IA, et l'IA pour un humain.
Tant que l'agent est une valeur déclarée par le client, le registre ne contient qu'une affirmation, que rien ne permet de recouper après coup. C'est un point que l'audit vérifie tôt.
La session d'agent
Avant de commencer, l'assistant demande une session au backend. Le serveur émet un jeton, et c'est lui qui décide de l'identité inscrite.
POST /api/agents/session
{
"connecteur": "ollama",
"modele": "llama3.1:8b",
"prompt_sha256": "3f8a1c..."
}
-> {
"session": "ag_7f3c...",
"agent": "Ollama · llama3.1:8b"
}
Les écritures suivantes portent l'en-tête X-IsoFind-Agent-Session. Le registre inscrit l'agent résolu depuis le jeton, jamais celui que le client déclare.
| En-tête reçu | Comportement du backend |
|---|---|
| Jeton de session valide | L'agent émis par le serveur est inscrit. |
| Jeton inconnu ou expiré | Avertissement dans les logs, repli sur l'agent générique. Le jeton n'est pas cru. |
| Aucun jeton, en-tête X-IsoFind-Agent seul | Valeur nettoyée et inscrite comme agent déclaratif, sans valeur probante. |
Le prompt entre dans la chaine signée
Le hash SHA-256 du prompt système est transmis à l'ouverture de session et entre dans le message signé. Sans cela, le prompt resterait modifiable après coup : la consigne qui a motivé l'écriture serait le seul élément du dossier à ne pas entrer dans la signature.
Acteur et agent
Le registre distingue deux champs, et un auditeur lit d'abord le second.
acteur : Colin Ferrari qui décide, et qui engage sa responsabilité
agent : Ollama · llama3.1 ce qui exécute
Colin Ferrari, via interface
Colin Ferrari, via workflow « Correction blanc v3 »
Colin Ferrari, via Ollama · llama3.1:8b
Une correction appliquée à quarante échantillons n'engage pas la même responsabilité selon qu'elle vient d'un geste répété, d'une règle automatique ou d'une décision de modèle. Les deux champs figurent dans chaque entrée, il n'y a rien à reconstituer.
Campagne et motif
Deux champs supplémentaires entrent dans le message signé : la campagne déclarée et le motif de l'écriture. Ils répondent à la question que le registre ne savait pas traiter : non pas quoi ni qui, mais pourquoi.
La campagne est propagée par enveloppement unique de window.fetch, filtré aux appels de l'API interne. Elle n'est jamais transmise au connecteur : Ollama ne reçoit ni le nom de la campagne, ni le motif.
Versionnage de la chaine HMAC
L'ajout de la campagne et du motif modifie la formule du message signé. La chaine est donc versionnée : les entrées V1 restent vérifiables avec leur formule d'origine, les entrées V2 incluent les deux nouveaux champs.
| Élément | Comportement |
|---|---|
| Entrées antérieures | Vérifiées avec la formule V1. Aucune réécriture, aucune perte de vérifiabilité. |
| Base existante | Migrée au démarrage : ALTER TABLE pour les colonnes, puis reconstruction des triggers. |
| Version de chaine | Stockée en pseudo-table __chaine__ dans les métadonnées du registre. |
Sans le marqueur de version, les triggers existants appelleraient la fonction de chainage avec l'ancien nombre d'arguments après mise à jour, et le logiciel deviendrait inutilisable. La version est donc lue au démarrage et déclenche la reconstruction quand la formule a changé.
Ce que le registre prouve
| Prouvé | Non prouvé |
|---|---|
| Qu'une écriture a eu lieu, à cette date, sur cette valeur. | Que la même séquence se reproduirait à l'identique. |
| Quel acteur en est responsable. | Que l'acteur avait raison. |
| Quel agent l'a exécutée, selon le serveur. | Que le modèle a suivi ses consignes de langage. |
| Sous quel prompt, par son hash. | Le contenu du prompt, s'il n'a pas été conservé par ailleurs. |
| Que la chaine n'a pas été altérée. | Qu'aucune donnée n'a été omise avant la première écriture. |
Vérifier une session
Panneau Historique
›
Échantillon
›
Évènements
›
Acteur, agent, campagne, motif
La vérification d'intégrité de la chaine est décrite dans Traçabilité et intégrité HMAC. Les exports au format ISOF portent en outre une signature ECDSA P-256 vérifiable hors ligne, y compris par le paquet open-source isof, sans IsoFind.
Cadre réglementaire
Les obligations de journalisation applicables aux systèmes d'IA selon le règlement européen dépendent de la classification du cas d'usage. Selon que l'analyse de matières premières critiques relève ou non d'une catégorie à haut risque, l'architecture décrite ici constitue un avantage ou une condition d'accès au marché.
Cette classification relève d'une qualification juridique et non d'un choix technique. Cette page décrit ce que le logiciel enregistre ; l'analyse de conformité revient aux personnes qualifiées pour la conduire.