Pourquoi les agents IA ont besoin de preuves

Un travail d’agent utile relie une réponse à la clause, à la révision, au calcul et à l’effet proposé qui la soutiennent. Si un agent recommande de ne pas renouveler un contrat fournisseur, la personne qui porte la décision peut ainsi vérifier le document, refaire le calcul et voir exactement ce qui serait envoyé.

Les preuves relient les sources, les outils, les transformations, les décisions et les versions du livrable ; la carte d’exécution V1 montre où passent ces opérations et quelles frontières elles traversent.

Suivre une recommandation jusqu’à son effet

Prenons une décision unique dans la revue de quinze contrats fournisseurs. Le contrat d’un prestataire se renouvelle le 1er mars 2027, sauf notification quatre-vingt-dix jours avant cette date. Un avenant modifie le plafond annuel. Un export comptable contient les dépenses réelles, et un registre d’incidents décrit quatre interruptions de service.

L’agent recommande de ne pas laisser le contrat se renouveler aux conditions actuelles. Il prépare une note de décision, corrige le tableau de suivi et propose un message de non-renouvellement. Pour qu’une personne puisse agir sur cette recommandation, six éléments doivent rester reliés :

1. la révision exacte du contrat et de son avenant ;
2. les passages extraits et les cellules de dépenses utilisées ;
3. le calcul de la date limite et du coût projeté ;
4. les reçus des outils qui ont lu, calculé et produit les fichiers ;
5. la version du livrable examinée par la personne ;
6. la décision ciblée et, si l’envoi a lieu, son reçu de livraison.

Ce chemin change la manière de relire. La personne n’a plus à refaire l’ensemble de l’analyse pour contrôler la date ou le montant. Elle peut partir de la recommandation, remonter au calcul, puis ouvrir la clause et la cellule exactes.

La conservation se concentre sur ce qui permet de comprendre une affirmation, un effet ou une révision matérielle. Une trace utile est structurée, attribuée et reliée à une cause.

Quatre fonctions distinctes de la preuve

Ces notions répondent à des questions différentes.

La provenance décrit l’origine et l’histoire d’un élément : fichier source, date de consultation, empreinte, outil utilisé, version produite, modèle sélectionné.

La justification expose les éléments vérifiables qui soutiennent une conclusion : clauses citées, calcul, règles appliquées, données manquantes et limites.

L’explication du modèle résume pourquoi il propose une conclusion. Elle oriente la lecture ; la source et le calcul reproductible fournissent la matière vérifiable.

La vérité reste une question distincte. Une provenance exacte peut conduire à une source erronée, et une justification cohérente peut partir d’une hypothèse devenue fausse. Les preuves montrent ce qui soutient la conclusion et rendent sa critique possible.

loqy privilégie donc la provenance et la justification. Dans l’exemple du contrat, la formule de date, l’avenant et la révision du tableau comptent davantage qu’une narration détaillée de la réflexion du modèle.

Cette approche rejoint le principe général du modèle de provenance du W3C : représenter les entités, les activités et les acteurs, puis les relations qui expliquent comment un résultat a été obtenu. loqy adapte cette idée à une exécution d’agent et à son interface de travail.

Les sources portent une identité de révision

La preuve désigne la révision de contrat.pdf qui a réellement été lue ou son empreinte exacte. Le même principe vaut pour une page web, un export CSV ou le résultat d’un outil.

Lorsqu’un contenu entre dans le travail, loqy enregistre son identité et son origine. Une transformation crée une nouvelle révision au lieu d’effacer silencieusement la précédente. La note de décision et le tableau corrigé peuvent ainsi être comparés à leur état antérieur.

Cette règle répond à une question fréquente après un incident : « qu’est-ce que l’agent voyait à ce moment-là ? » Sans révisions stables, la réponse dépend de l’état actuel des fichiers. Avec elles, le contexte important peut être reconstruit.

La conservation reste proportionnée. Les gros résultats n’ont pas besoin d’être copiés intégralement dans chaque message. Ils peuvent rester dans le stockage canonique, tandis que le contexte du modèle reçoit un extrait borné et une référence. La preuve conserve alors le lien vers le résultat complet sans saturer la conversation.

Un appel d’outil produit un reçu

Lorsqu’un agent exécute un calcul, recherche une page ou transforme un document, trois éléments doivent rester liés : l’intention, les entrées admises et le résultat. C’est le rôle d’un reçu d’outil. Dans le dossier fournisseur, un reçu relie la formule des quatre-vingt-dix jours à la date lue dans le contrat et à la valeur écrite dans le tableau.

Le reçu indique ce qui a été appelé, dans quel périmètre et avec quel résultat. Une API peut répondre avec une donnée erronée, une page peut être malveillante et un script peut contenir un défaut ; la vérification porte alors au bon endroit.

Le reçu aide aussi à gérer les échecs. Si un outil renvoie une erreur sans avoir modifié l’extérieur, l’agent peut essayer une autre approche. Si l’état extérieur a peut-être changé, la situation est différente.

Prenons le message de non-renouvellement. La connexion se coupe juste après la requête. Relancer automatiquement peut créer un doublon. Considérer l’envoi comme échoué peut masquer un message déjà parti. loqy doit alors marquer l’effet comme incertain, vérifier son état si le connecteur le permet, puis demander une décision lorsqu’aucune réconciliation sûre n’est possible.

Après un crash, la reprise réconcilie l’état d’un effet extérieur en attente avant toute nouvelle tentative. La continuité conserve ainsi l’unicité de ses conséquences.

Une décision humaine est un événement précis

« Oui, vas-y » dans une conversation peut répondre à une question, approuver une formulation ou simplement exprimer un accord. Une autorisation vise donc une demande typée et précise.

Dans loqy, une action conséquente est représentée par une demande typée liée à l’exécution et aux preuves exactes. Pour le non-renouvellement, la carte montre le destinataire, l’objet, le corps du message, les pièces jointes, la date calculée et la révision de la note. La réponse vise cette demande précise. Une clé d’idempotence relie la demande, sa charge utile et son effet, de sorte qu’un double clic ou une reconnexion ne peut pas appliquer l’action deux fois.

Si le fichier, la destination ou un autre élément de preuve change avant la réponse, l’approbation devient périmée. La personne doit revoir la nouvelle version. Une autorisation ne peut pas être détachée de ce qu’elle autorisait.

loqy exécute dans les limites déjà accordées et réserve les décisions aux effets qui le nécessitent. Lire un fichier autorisé, calculer un total ou préparer un brouillon reste dans le périmètre courant. Publier, supprimer, envoyer ou élargir un accès franchit une autre frontière.

L’agent peut ainsi avancer dans un périmètre clair et présenter une décision exacte au moment où ce périmètre doit changer.

La preuve accompagne chaque version du livrable

Dans la revue des contrats, l’agent produit d’abord un tableau et une note. L’utilisateur corrige le plafond annuel parce que la clause renvoie à un avenant. L’agent intègre la correction, recalcule la synthèse et crée une nouvelle révision. La demande d’envoi précédente devient automatiquement périmée, car elle visait un autre contenu.

Si le livrable final remplace simplement l’ancien fichier, trois informations disparaissent : la proposition initiale, la correction humaine et l’effet de cette correction sur le résultat. Des révisions reliées permettent au contraire de distinguer :

• le contenu extrait par le modèle ;
• les transformations déterministes ;
• les modifications proposées par l’agent ;
• les corrections ou décisions humaines ;
• la version validée et livrée.

La dernière étape vérifie davantage que la création du fichier : format, contraintes demandées, références et limites connues. Un classeur doit s’ouvrir et contenir les feuilles attendues. Un rapport doit citer ses sources. Une modification de code doit passer les contrôles pertinents. Le livrable reste marqué comme proposition jusqu’à la vérification ou la décision attendue.

Cette chaîne réduit le coût nécessaire pour localiser une erreur, comprendre sa propagation et produire une version corrigée.

Le modèle et le fournisseur font partie de l’attribution

Deux modèles peuvent produire des réponses différentes avec le même contexte. Un fournisseur peut modifier un modèle hébergé. Un modèle local peut être mis à jour ou lancé avec une autre quantification.

Chaque exécution possède donc une identité de modèle immuable. Pour l’inférence locale, elle comprend l’artefact et la configuration. Pour l’inférence hébergée, elle comprend le fournisseur et l’identifiant admis. Un changement de modèle ou de fournisseur s’applique à une nouvelle exécution et ne réécrit pas l’attribution de la précédente.

Cette information permet de comparer une révision, de reproduire un défaut et de savoir quelles conditions de traitement s’appliquaient. Elle contribue aussi à la portabilité : le travail peut survivre au modèle, tout en conservant l’identité du modèle, du fournisseur et de la configuration associés à chaque version. Le chemin de sortie du travail repose sur cette continuité.

Preuves et télémétrie sont deux plans distincts

La trace détaillée d’un travail appartient à l’utilisateur et reste locale par défaut. Elle peut contenir des documents, des extraits, des calculs et des décisions sensibles. La télémétrie du mainteneur suit un plan séparé.

loqy sépare trois plans :

1. les preuves du travail, conservées pour que l’utilisateur puisse comprendre et reprendre son activité ;
2. les diagnostics opérationnels appartenant au client, utiles pour administrer son propre environnement ;
3. les signaux techniques éventuellement transmis au mainteneur, limités à ce qui est nécessaire pour diagnostiquer un crash ou améliorer le produit.

Le diagnostic technique ordinaire reste sans contenu de travail : version de l’application, état des composants, codes d’erreur et événements nécessaires. Si une personne choisit de transmettre un contenu pour obtenir de l’aide, ce partage doit être distinct, explicite, inspectable et révocable. Les identifiants d’authentification, jetons et secrets en restent exclus.

Cette séparation est importante pour la confiance : une preuve visible dans l’application reste dans le plan du travail de l’utilisateur.

L’application elle-même doit fournir des preuves

La traçabilité couvre aussi l’application distribuée : de quelles sources provient cette version, quels composants contient-elle, et comment vérifier son intégrité ?

loqy distingue pour cela la reproductibilité du contenu non signé et l’intégrité de la version distribuée. La signature et la notarisation Apple ajoutent des identités et des horodatages, de sorte que le fichier final n’est pas nécessairement identique octet par octet à une reconstruction locale. En revanche, la provenance de la version relie le code source, les entrées verrouillées, le contenu non signé, la signature, la nomenclature des composants logiciels et le livrable publié.

Le code source ouvert rend l’architecture inspectable. La reproductibilité rapproche le binaire de cette source. La signature identifie la version distribuée. Ces mécanismes se renforcent lorsqu’ils sont reliés par des preuves.

La confiance reste un jugement humain

À la fin de la revue, l’utilisateur ne reçoit pas seulement un tableau rempli. Il reçoit une révision qui peut être parcourue dans les deux sens : du contrat vers la recommandation, et de la recommandation vers le contrat. Les calculs ont des entrées, les actions ont des reçus, les décisions ont une portée et les corrections ont une histoire.

Les documents peuvent se contredire, une source publique peut être obsolète et un modèle peut mal interpréter une clause. Les preuves donnent au jugement humain une matière précise pour trancher.

Un agent digne de confiance rend visible ce qui soutient le résultat, ce qui a changé, ce qui reste incertain et ce qui exige encore une décision.

Sources et méthode

• W3C, PROV Overview
• loqy, décisions humaines contextuelles
• loqy, architecture générale et chaîne de révisions
• loqy, Live Artifacts et provenance de publication
• loqy, constructions reproductibles et provenance des versions
• NIST, cadre de gestion des risques liés à l’IA