Action IA : retrouver la proposition autorisée et le résultat observé

L’assistant annonce qu’un avoir est créé. Le middleware conserve un appel envoyé, mais aucun reçu ERP n’est encore rattaché. Un timeout a été classé comme erreur technique et le ticket paraît terminé dans la conversation. Le risque est de devoir retrouver après coup si le geste a été autorisé, appliqué ou seulement annoncé, avec une deuxième écriture possible si une équipe choisit de relancer.

En pratique, l’audit doit reconstruire les faits de l’action sans laisser un message du modèle combler les pièces manquantes. Source, paramètres proposés, accord, invocation et observation de résultat portent des identités reliées. L’intégration d’une IA au système d’information doit conserver cette filiation pour que le métier puisse distinguer effet connu, refus et résultat encore inconnu.

Vingt journaux fictifs, enregistrés dans SQLite puis relus, font varier les pièces du dossier d’un avoir : proposition, accord, invocation et reçu observé. Les empreintes et rapprochements sont calculés ; aucun modèle, ERP, IAM ou collecteur de traces n’est appelé. Une empreinte cohérente ne prouve pas l’authenticité du reçu distant. L’accompagnement IA sur mesure de Dawap peut prolonger cette recette avec les acteurs et interfaces réels, en distinguant résultat établi et décision humaine sur un cas encore inconnu.

Pour qui un dossier de preuve doit expliquer l’action

Retrouver une décision dont le résultat engage le SI

Le besoin apparaît dès qu’un agent peut préparer ou demander une écriture : avoir, note de dossier, réservation ou notification. L’équipe d’exploitation doit connaître le geste engagé sans interpréter toute la conversation. Le métier doit pouvoir revoir la règle et l’objet approuvés. Le dossier rassemble ces éléments avec leur provenance ; il ne se limite pas à une ligne indiquant que l’assistant a répondu sans erreur.

Dans le scénario, une proposition d’avoir porte commande O41, montant 120,00 EUR et révision de source 4. La mission M41 et l’opération OP41 appartiennent à la société A. Ces valeurs sont choisies pour le laboratoire, sans facture client ni règle financière réelle. La recette ne décide pas si un avoir est commercialement justifié ; elle vérifie quelle proposition le journal permet de rattacher à l’accord et au résultat.

Séparer la preuve d’une action et la supervision du service

Une supervision peut suivre latence, erreurs et consommation en tokens. Ces mesures n’expliquent pas toutes la décision métier d’un appel précis. Un taux d’erreur bas peut coexister avec des paramètres incorrects acceptés par la cible. Le dossier de preuve complète cette vue technique : il conserve ce qui a été demandé, sur quelle base, par quelle décision et avec quelle observation d’effet.

Le périmètre d’audit doit être défini avant incident. Les gestes risqués demandent les pièces qui permettent une revue, sans stocker arbitrairement tout le contexte du modèle. Le coût d’une preuve insuffisante inclut investigation, reprise manuelle et opérations non rapprochées. La qualité de l’audit se mesure notamment au travail nécessaire pour résoudre ces états, pas au volume de logs collectés.

Séparer mission, opération et trace de transport

Garder une identité durable lorsque l’exécution traverse plusieurs requêtes

Une mission peut comporter plusieurs actions ; une action peut attendre un worker ou recevoir son résultat lors d’une autre requête. L’identifiant OP41 garde le lien métier au-delà d’une réponse HTTP. La société et la mission le qualifient dans le laboratoire. La production doit définir cette portée, sa création et son unicité, notamment lorsqu’une reprise technique peut déclencher une nouvelle tentative sur le même objet.

A41-18 change le traceId du reçu sans changer mission, action, société, cible et paramètres. Le dossier reste rapprochable. Une trace de transport n’est donc pas la seule clé de filiation. Elle aide à retrouver les composants traversés ; l’identité durable relie le geste et ses observations. Le laboratoire utilise deux chaînes hexadécimales fictives de 32 caractères, sans tester une propagation de traces.

Ne pas donner une autorité métier à un identifiant de diagnostic

La recommandation W3C Trace Context définit la propagation du contexte de trace entre services. Elle interdit d’utiliser traceparent et tracestate pour des informations personnelles identifiantes ou sensibles. Ces champs ne constituent pas un accord métier. Un traceId reçu d’un client ne doit pas servir à choisir la société autorisée ou à déduire les droits de l’action.

Le service conserve séparément identité de personne, compte technique, mission et opération. Leur présence dans le journal ne prouve pas leur validation. Le contrôle d’accès et la délégation doivent être éprouvés dans la chaîne réelle. Le dossier peut ensuite documenter la décision effectuée, avec un lien vers sa politique et son résultat, plutôt que transformer une valeur déclarée en permission implicite.

Retrouver les faits disponibles lors de la proposition

Conserver le snapshot utile et la référence à son autorité

S41 contient ici « Commande O41 livrée », avec révision 4 et empreinte calculée. La proposition conserve la révision et l’empreinte de cette source. A41-07 modifie le corps sans modifier l’empreinte et reçoit source_fingerprint_mismatch. A41-08 change la révision de source sans changer la proposition et reçoit source_revision_mismatch. Les gardes empêchent de rapprocher silencieusement une proposition avec une pièce différente.

Les empreintes sont des SHA-256 de représentations JSON compactes, triées et encodées en UTF-8. Elles vérifient la cohérence des objets construits. Elles ne prouvent pas que la commande a été livrée, que l’auteur de l’événement est authentique ou que le stockage résiste à une réécriture complète. La provenance réelle doit identifier le logiciel source et le contrat qui permet d’utiliser son fait.

Distinguer l’état connu au moment de l’action de l’état courant

Une commande peut changer après la proposition. L’audit conserve la base de la décision passée sans la remplacer par la valeur consultée aujourd’hui. L’exécution, elle, doit vérifier si les conditions nécessaires restent présentes au moment de l’appel. Ces deux usages de source sont distincts. Un snapshot historique peut expliquer un choix sans autoriser à refaire maintenant une action fondée sur ce snapshot.

La recette locale ne rejoue pas la fraîcheur d’un ERP ou une transaction entre source et écriture. Elle vérifie seulement les liaisons enregistrées. Un système réel doit décider quels champs exigent une relecture, une précondition ou une revue en cas de modification. Le dossier garde cette règle et le contrôle observé pour que l’équipe puisse expliquer le défaut sans reconstruire une source devenue indisponible.

Conserver les paramètres avant leur exécution

Retrouver l’objet exact soumis à la décision

Le montant est une chaîne décimale 120.00 avec devise EUR ; la commande et la révision de source font partie des paramètres. Le programme calcule leur empreinte canonique. L’accord et l’invocation doivent retrouver cette même empreinte. Le dossier ne considère pas qu’une approbation de l’idée « faire un avoir » autorise n’importe quel montant, destinataire ou commande sélectionnés ensuite par un agent.

Une application peut présenter un résumé lisible tout en conservant l’objet structuré approuvé. Le résumé doit montrer les différences qui changent les conséquences : ressource, montant, unité ou portée. Si un paramètre change, l’interface ne doit pas maintenir le même accord par simple continuité de conversation. Le propriétaire du processus définit quand une nouvelle proposition et une nouvelle validation sont nécessaires.

Versionner la production de proposition sans lui attribuer un effet

Prompt, modèle, règles et version d’outil peuvent aider à diagnostiquer pourquoi une proposition a changé. Ces repères ne constituent pas le résultat de l’action. Le laboratoire n’exécute aucun prompt ; ses paramètres sont manuscrits. Une production conserve les versions réellement utilisées et le contexte pertinent pour la recette, avec les limites de ce qui peut être reproduit dans un service hébergé.

Un résultat de génération valide au format JSON peut encore porter une cible interdite ou une règle non soutenue. La preuve de proposition doit donc rejoindre les contrôles applicatifs de paramètres et de portée. L’audit garde leurs décisions plutôt qu’un simple statut format valide. Cela permet de distinguer une suggestion rejetée avant outil d’un appel envoyé dont le résultat reste à résoudre.

Rattacher l’accord à son objet et à son moment

Vérifier la relation entre accord, proposition et invocation

Cas concret : A41-05 modifie l’empreinte dans l’accord ; approval_proposal_mismatch refuse le rapprochement. A41-06 modifie l’empreinte de l’invocation et reçoit invocation_proposal_mismatch. Le fait que tous les événements portent OP41 ne suffit pas. L’accord et l’appel doivent concerner les paramètres liés à la proposition, dans le périmètre de mission conservé.

A41-04 retire l’accord et reçoit authorization_unproven. A41-17 conserve une décision allow avec un autre acteur et reçoit approval_actor_unproven. La liste locale accepte Alice ; elle ne valide pas une session ou un rôle IAM. Le dossier doit retrouver le contexte d’identité et la politique effectivement évalués dans le système réel, sans confondre nom enregistré et personne authentifiée.

Comparer le moment de l’appel à la validité de l’accord

L’accord fictif intervient à 3, l’invocation à 4, et la borne de validité est strictement inférieure à 10. A41-12 place l’appel à 10 et reçoit approval_expired_at_invocation. A41-19 place l’accord après l’appel et reçoit approval_after_invocation. Ces valeurs sont des repères entiers construits, sans synchronisation d’horloges ni durée de validité recommandée pour une production.

Le modèle de logs OpenTelemetry distingue Timestamp et ObservedTimestamp, ainsi que TraceId et SpanId. Une observation tardive ne devient pas automatiquement le moment de l’effet. Le système doit conserver les horloges, leur autorité et les relations de causalité disponibles. Aucun SDK ou export OTLP n’est utilisé dans notre registre SQLite.

Distinguer appel, timeout, refus et reçu métier

Retrouver ce que la cible permet réellement d’observer

Le reçu nominal CN41 porte statut applied, cible Q41 et empreinte de paramètres. Le rapprochement produit result_applied. A41-10 conserve un reçu avec des paramètres différents et reçoit receipt_mismatch ; A41-11 conserve un résultat rejected et reçoit result_rejected. Le programme ne transforme pas une réponse reçue en succès métier sans lire le statut attendu par son contrat réduit.

Ces reçus sont injectés à la main dans les journaux fictifs. La production doit établir leur origine, leur portée et leur signification auprès de l’API ou du middleware réel. Un acquittement de transport peut seulement confirmer la réception d’une demande. Le résultat final peut nécessiter une autre consultation, une notification ou un rapprochement. L’audit ne doit pas remplacer cette distinction par un champ générique succès.

Maintenir l’inconnu lorsque la pièce de résultat manque

A41-02 conserve invocation et timeout, mais retire le reçu. Result_unknown ne signifie ni avoir absent ni avoir appliqué. La reprise de l’opération doit suivre son contrat d’idempotence et de rapprochement, sans utiliser le dossier incomplet comme permission de renvoi. L’interface peut expliquer ce qui est connu, l’observation qui manque et l’équipe chargée de la retrouver.

A41-13 reçoit l’observation du résultat à 30 alors que l’occurrence conservée est à 4. L’accord reste rapproché selon le moment fictif de l’invocation, pas selon le délai d’arrivée du reçu. Cette distinction conserve un fait passé sans autoriser une nouvelle action à 30. Dans un système distribué, les horodatages peuvent diverger ; la recette doit éprouver les relations et les incertitudes de la chaîne réelle.

Conserver une décision humaine sans inventer l’effet

Rattacher une revue à l’opération encore ouverte

Exemple concret : A41-03 garde l’action sans reçu et ajoute une revue de Bob à 15, demandant hold_for_reconciliation. Le verdict devient result_unknown_reviewed. La décision documente qui a choisi l’attente et quand ; elle n’ajoute pas de preuve d’application. Le journal doit conserver cette nuance pour que le prochain intervenant sache quelle investigation continue et quelles nouvelles capacités restent fermées.

Une décision de correction ou de compensation peut ensuite constituer une autre action, avec ses paramètres et son accord. Elle ne réécrit pas l’ancien résultat pour donner l’impression que la première opération s’est bien passée. Le dossier doit relier les deux gestes et leur motivation. La chaîne d’effets reste explicable lorsque plusieurs personnes participent à la résolution d’un incident.

Garder les observations contradictoires et les décisions successives

A41-14 répète le même événement de reçu avec le même contenu ; le programme ignore un doublon. A41-15 réutilise son eventId avec un statut différent et reçoit event_id_conflict. Une seconde observation ne doit pas écraser arbitrairement la première. Le service doit distinguer retransmission identique, évolution légitime d’un statut et contradiction à instruire, selon le protocole de la cible.

Le banc accepte une occurrence par type d’événement et refuse les types ambigus ; il ne représente pas une histoire générale de plusieurs approbations ou reçus successifs. Une production doit versionner ces relations et définir les transitions valides. L’audit conserve les décisions reçues et le motif de résolution plutôt qu’une dernière ligne isolée dont personne ne peut retrouver les états précédents.

Vingt journaux et les dossiers effectivement reconstruits

Comparer chaque sortie aux événements persistés

Chaque scénario crée une base SQLite, insère ses événements JSON, ferme la connexion puis recharge les lignes dans l’ordre enregistré. Le contrôle compare contexte, snapshot, paramètres, accord et résultat. Les valeurs sont fictives et aucun effet métier n’est envoyé. Le tableau montre le verdict calculé, pas une mesure de qualité d’agent ou de fréquence d’erreur sur un trafic réel.

Lire le dossier nominal sans en faire une certification

Le dossier nominal conserve la mission, l’opération, l’empreinte de proposition, la relation d’autorisation, le statut observé, le reçu et son instant d’observation. Le résultat ci-dessous est calculé à partir des événements fictifs. Matched signifie que les relations attendues passent les gardes locales ; il ne certifie ni la signature d’un accord ni l’autorité d’un résultat distant.

{"mission":"M41","action":"OP41","proposalHash":"d61bc6526b67c69603078cdaa83575bbe55ca36e11136696ec7f326479e76b28","authorization":"matched","result":"applied","receipt":"CN41","decisionReview":null,"observedAt":20}

La base est réellement persistée et relue, mais aucun arrêt OS, perte de journal, stockage inviolable ou système distribué n’est testé. Les structures et horloges sont prévues par le jeu. La recette réelle doit ajouter événements hors ordre, champs manquants, rétention, contrôle d’accès et observations authentifiées. Le résultat métier reste attaché au contrat qui permet de l’établir, pas au seul calcul d’une empreinte.

Protéger le contenu des preuves et des conversations

Conserver les pièces utiles sans ouvrir tout le contexte à l’exploitation

Le dossier peut garder des références vers des pièces protégées plutôt que copier partout leur corps. La personne qui suit une erreur technique n’a pas automatiquement besoin de lire la conversation privée ou les données commerciales détaillées. Définissez accès au diagnostic, accès à la preuve et accès au contenu, avec les durées de conservation et les usages réellement nécessaires au processus.

La fiche OWASP sur la journalisation décrit contexte d’événement et identifiant d’interaction pour rapprocher les faits. Elle demande aussi d’examiner les données sensibles à exclure ou protéger. La corrélation doit éviter de disperser secrets et contenu dans les logs techniques. La recette locale ne teste pas une politique de rétention ou de confidentialité.

Réexaminer le droit de lecture lorsque l’action appartient au passé

Une personne peut avoir approuvé le geste puis perdre l’accès au dossier. L’autorisation historique reste une pièce de son explication ; elle n’ouvre pas un droit permanent de consulter toutes les sources. Le service doit séparer la vue courante de l’utilisateur et la revue réservée aux personnes habilitées. Le diagnostic peut indiquer l’opération et son état sans exposer une commande ou un passage désormais interdit au lecteur.

Les métadonnées elles-mêmes peuvent porter une information sensible : montant, destinataire ou identité de ressource. Leur classement doit rejoindre la politique de lecture, pas seulement celui des conversations. Les empreintes facilitent le rapprochement sans dispenser de protéger les objets auxquels elles renvoient. La recette d’accès doit être exécutée sur les vues, exports et liens de preuve ; elle n’est pas couverte par les vingt contrôles de liaison locaux.

Erreurs fréquentes dans l’audit d’une action IA

Prendre une annonce ou une absence de log pour un état métier

Une synthèse du modèle peut annoncer le travail qu’il avait prévu de faire. Une ligne d’exception peut seulement indiquer que le service a cessé d’attendre. Une absence de reçu peut venir d’un défaut de collecte. Aucun de ces faits ne suffit seul à établir l’effet. Le signal faible est une résolution de ticket rapide, suivie d’une investigation dans la cible pour découvrir ce qui a réellement été appliqué.

Paradoxalement, un dossier qui conserve clairement l’inconnu peut être plus exploitable qu’un statut terminé produit trop tôt. Il indique l’opération à rapprocher et empêche de perdre sa filiation dans une nouvelle mission. La complétude du journal doit être suivie séparément du succès apparent : un résultat absent de la collecte peut demander un autre chemin de preuve, sans attribuer automatiquement la faute à l’agent.

Réunir les événements uniquement par proximité de temps

Deux actions proches peuvent concerner la même commande ou partager un compte technique. Une corrélation par minute et utilisateur risque de rattacher le mauvais accord ou reçu. Les identités durables et les paramètres doivent soutenir le rapprochement. La recette ajoute des opérations parallèles et des retransmissions pour éprouver cette relation, sans faire dépendre la preuve d’un seul timestamp supposé fiable.

Une autre erreur consiste à remplacer la preuve d’autorisation par un accord retrouvé après incident. La revue ultérieure peut décider une correction, mais elle ne rend pas rétroactivement l’invocation conforme au contrat initial. Le journal distingue les moments et les objets de décision. Une amélioration du temps d’audit ne justifie pas d’écraser les états qui expliquent pourquoi une opération a dû être revue.

Plan d’action pour un rapprochement exploitable

L’implémentation définit les événements d’entrée, le dossier de sortie et la responsabilité de chaque pièce. Le middleware conserve l’invocation ; le propriétaire d’outil établit le résultat ; le métier arbitre les revues. L’instrumentation suit les liens manquants et les états inconnus. Le repli empêche une nouvelle écriture tant que le contrat de résolution de l’opération n’est pas satisfait.

1. Définir l’identité de chaque action. Conservez mission, opération, société et cible, indépendamment des traces de transport. Attribuez l’identité avant l’appel et suivez-la dans la reprise et le résultat. Décrivez les retransmissions qui conservent la même opération et les corrections qui doivent créer un geste distinct relié au premier.
2. Conserver la proposition et sa base. Stockez les paramètres canoniques, unités, source et révision, avec les références protégées nécessaires à la revue. Identifiez les versions de production de proposition. Une empreinte facilite la comparaison mais ne remplace pas l’origine et l’accès aux pièces ; précisez comment elles restent vérifiables après évolution du SI.
3. Rattacher l’accord à l’invocation. Enregistrez objet approuvé, acteur vérifié, politique et moment utile. Testez changement de paramètres, accord absent, borne dépassée et revue postérieure. La journalisation doit retrouver les contrôles réellement effectués, sans traiter une identité ou un traceId déclaré comme autorisation de nouvelle capacité.
4. Décrire le résultat et l’inconnu. Établissez le contrat de reçu auprès de la cible : réception, application, refus ou état encore ouvert. Conservez occurrence et observation quand elles sont disponibles. Un timeout ouvre le rapprochement attendu ; il ne rend pas l’effet absent et ne donne pas un droit automatique de rejouer.
5. Éprouver collecte, lecture et revue. Rejouez pertes, doublons et contradictions dans la chaîne réelle, puis contrôlez les droits d’accès au dossier et aux pièces. Mesurez volume inconnu, délai de résolution et travail de vérification. Gardez une décision humaine datée et rattachée, avec un suivi des opérations de correction et de leur propre autorisation.

Le contrat de sortie distingue preuve complète, pièce absente et relation contradictoire. Son instrumentation suit les seuils d’escalade décidés avec le métier et la file de rapprochement. Un rollback du service conserve les actions déjà engagées et leurs dossiers ; l’équipe garde la responsabilité de résolution même lorsque la version qui a proposé le geste n’est plus utilisée.

Relier contrats d’outil, contexte et capacités SI

Retrouver la frontière entre proposition et écriture

Le contrat d’un agent entre ERP, CRM et contexte métier précise les objets à lire et les gestes admissibles. Le contrat d’outil entre autorisation et exécution fixe les preuves à conserver pour chaque capacité. Le dossier d’audit retrouve ces décisions sans devenir lui-même le contrôleur qui accorde un nouvel effet.

Le contrôle d’un contexte ERP devenu périmé complète le snapshot de proposition avec la vérification nécessaire avant l’appel. Un journal historique peut expliquer un choix sans prouver que la source était encore admissible au moment de l’exécution. La recette doit relier la précondition effectivement contrôlée et son résultat.

Préserver l’identité et l’effet à travers les protocoles

La frontière d’autorisation entre MCP et API métier empêche qu’un protocole disponible devienne une capacité libre. La délégation entre utilisateur et compte technique conserve le périmètre de l’acteur. L’audit doit retrouver ces deux contrats, pas déduire la permission d’un appel qui a simplement traversé le réseau.

La reprise d’une mission depuis son checkpoint conserve les faits et les opérations pendantes avant un nouveau choix d’agent. Le dossier de preuve sert à leur rapprochement et à la revue de leurs conditions. La conversation peut continuer tandis que l’action précédente garde un état distinct qui demande encore une décision.

Conclusion : expliquer l’effet depuis des faits rattachés

Une action IA se comprend par les relations entre faits disponibles, proposition, accord, invocation et observation de résultat. La trace de transport aide au diagnostic ; l’identité durable et les paramètres conservent la filiation métier. Une preuve manquante reste un état à résoudre. Une décision de revue peut organiser cette résolution sans transformer l’inconnu en résultat établi.

Les vingt journaux SQLite vérifient des liaisons, empreintes et frontières de temps sur des événements fictifs. Aucun effet métier, IAM, signature, modèle ou instrumentation distribuée n’est exécuté. Le reçu nominal et les paramètres sont injectés à la main. La recette réelle doit établir leur origine, la collecte et les accès avant de considérer un dossier comme une preuve utilisable pour le processus concerné.

L’intégration d’une IA au système d’information doit conserver ces frontières dans le parcours utilisateur et le middleware. Le métier retrouve l’objet autorisé et le statut réellement observé, tandis que l’exploitation conserve la capacité de diagnostiquer sans lire arbitrairement tous les contenus. Les cas ouverts gardent un propriétaire et une prochaine vérification explicites.

Lorsqu’un avoir reste sans résultat confirmé, l’expertise IA sur mesure de Dawap peut vous aider à retrouver les paramètres autorisés, le moment de l’appel et les observations de la cible. La recette doit éprouver un reçu tardif, des événements contradictoires et une décision de mise en attente. Le dossier garde séparément ces faits et leurs acteurs : une décision humaine de suspendre la reprise ne devient pas une preuve que l’avoir a été appliqué.