Le pattern Custody Chain pour les systèmes d'IA agentique

Les systèmes d'IA agentique échouent d'une manière spécifique et prévisible. Non pas parce que les modèles sont faux. Parce que personne n'a convenu de qui possède l'état entre les étapes. Un agent transforme un enregistrement, le transmet, et l'agent suivant opère sur une hypothèse qui n'a jamais été vérifiée. Au moment où quelque chose se casse, la trace a disparu. C'est le problème que le pattern Custody Chain résout.

J'ai commencé à réfléchir à ce pattern en construisant des systèmes où une mauvaise réponse avait des conséquences réelles, une déclaration fiscale déposée avec un mauvais chiffre, une évaluation d'admissibilité de visa qui envoyait quelqu'un sur la mauvaise voie. Dans les deux cas, la contrainte n'était pas la précision du modèle. C'était l'auditabilité. Un régulateur ne veut pas savoir que le modèle avait probablement raison. Il veut un enregistrement signé de chaque transition d'état, qui ou quoi l'a produit, et sur quoi il était basé.

Ce que le modèle mental Custody Chain est réellement

Le Custody Chain est un principe de conception, pas une bibliothèque. L'idée est empruntée à la gestion des preuves médico-légales. Chaque pièce à conviction dans une affaire criminelle a une chaîne de possession documentée : qui l'a collectée, quand, comment elle a été stockée, qui l'a transférée, et qui l'a reçue. Si cette chaîne se casse, la preuve est inadmissible.

Appliqué à l'IA agentique, la règle est la même. Chaque objet d'état qui passe entre les agents doit porter un enregistrement scellé de sa provenance, de la transformation appliquée, et des entrées au moment de la transformation. Aucun agent ne consomme une charge utile qu'il ne peut pas vérifier. Aucun agent ne produit une sortie sans la signer. La chaîne n'est jamais rompue.

C'est différent de la journalisation. La journalisation est ajout seul et externe. Le Custody Chain est intégré à la charge utile elle-même. L'objet d'état est sa propre piste d'audit.

Pourquoi la plupart des architectures agentiques l'ignorent

Le chemin rapide est plus facile. Vous définissez un graphe de tâches, connectez les agents ensemble, et transmettez des objets de données simples entre eux. Ça marche en développement. Ça marche dans les démos. Ça casse en production quand un agent en amont retourne un résultat partiel sous charge, ou quand une nouvelle tentative produit une sortie différente de l'exécution originale, et l'agent en aval n'a aucun moyen de le savoir.

La plupart des frameworks traitent l'état comme une ressource partagée. Un agent y écrit, un autre lit, et la coordination est gérée par l'orchestrateur. Ce modèle convient aux pipelines simples. Pour tout ce qui a une logique de branchement, des étapes avec intervention humaine, ou des exigences réglementaires, il crée une classe de bugs qui sont presque impossibles à reproduire, parce que le bug est dans la séquence, pas dans un seul agent.

L'approche JAKARTA Agentic AI, que j'applique dans les builds 2026, aborde cela directement. Jakarta EE 11 vous donne les primitives de transaction et de propagation de contexte dont vous avez besoin pour rendre les transferts de possession explicites au niveau du framework. Vous ne collez pas l'auditabilité après coup. Vous la construisez dans le contrat d'agent dès le départ. Le même modèle mental s'applique si vous travaillez dans un stack différent. Les primitives diffèrent, mais le principe tient.

Comment l'implémenter en pratique

L'implémentation a trois règles.

• —Charges utiles immuables. Chaque agent reçoit une charge utile et produit une nouvelle charge utile. Il ne mute jamais l'entrée. L'enregistrement original est préservé à chaque étape.
• —Transferts signés. Avant de transmettre une charge utile à l'agent suivant, l'agent actuel attache un enregistrement de possession : identifiant d'agent, horodatage, hash d'entrée, hash de sortie, et une brève déclaration de la transformation appliquée. Ce n'est pas une entrée de journal. C'est partie de la charge utile.
• —Vérification à l'entrée. Chaque agent, avant de faire un travail, vérifie l'enregistrement de possession de la charge utile entrante. Si le hash ne correspond pas, l'agent rejette la charge utile et lève une faute de possession, pas une erreur générique.

La faute de possession est importante. C'est un mode de défaillance nommé et spécifique. Quand une faute de possession se déclenche, vous savez exactement où la chaîne s'est cassée et quel était le dernier état vérifié. C'est la différence entre un système qui échoue bruyamment et un qui échoue silencieusement et mal.

Dans un contexte Jakarta EE, vous l'implémentez en utilisant des intercepteurs CDI sur vos beans d'agent. L'intercepteur gère la vérification à l'entrée et la signature à la sortie. Le code d'agent lui-même ne touche jamais l'enregistrement de possession. Il ne voit que la charge utile vérifiée. Cette séparation garde la logique métier propre et rend le comportement de possession testable isolément.

Où ça devient difficile

La partie difficile est les étapes avec intervention humaine. Quand un humain examine et approuve une transition d'état, il agit comme un agent dans la chaîne. L'enregistrement de possession doit capturer cela. Qui l'a approuvé, à quel moment, sur la base de quelle version de la charge utile.

J'ai rencontré cela directement sur le build OptimalTax, où les résultats de calcul fiscal devaient passer par une étape d'examen humain avant le dépôt. La tentation était de traiter l'approbation humaine comme un événement de canal latéral et simplement enregistrer un drapeau booléen. Ça ne tient pas sous audit. L'enregistrement de possession pour l'étape humaine a besoin de la même structure que n'importe quelle autre étape : état d'entrée, identité de l'examinateur, horodatage, et état de sortie. Quand le système a atteint 99% de précision de calcul fiscal, une partie de ce qui a rendu ce chiffre significatif était que chaque étape de la chaîne, y compris les étapes humaines, était entièrement traçable.

Le même principe s'appliquait sur la Financial Services Platform, où les transitions d'état de paiement devaient être auditables entre plusieurs services. Les transferts d'état entre services sont des transferts de possession. Les traiter de cette façon dès le départ était ce qui a permis à l'équipe de diagnostiquer et d'éliminer la latence sans perdre la piste d'audit.

La limite entre agents est le contrat

Beaucoup de conception d'IA agentique se concentre sur ce que chaque agent fait. Le pattern Custody Chain vous force à vous concentrer sur ce qui se passe entre les agents. Cette limite est le contrat. C'est où la correction est soit garantie, soit perdue.

Si vous construisez un système agentique et vous ne pouvez pas répondre à ces questions pour chaque transfert, le système n'est pas prêt pour la production : quel est le schéma de la charge utile, à quoi ressemble un enregistrement de possession valide, que se passe-t-il quand la vérification échoue, et qui est notifié. Ce sont des questions d'ingénierie, pas des questions d'IA. Le modèle est la partie la moins intéressante du problème.

L'IA agentique construite sans cette discipline tend à bien fonctionner jusqu'à ce qu'elle ne fonctionne pas, et quand elle échoue, elle échoue de manières qui sont coûteuses à diagnostiquer et difficiles à expliquer à un client ou un régulateur. Le pattern Custody Chain ne rend pas le système plus intelligent. Il rend le système honnête sur ce qu'il sait et quand il l'a su.

Si vous êtes un fondateur ou propriétaire de produit qui travaille sur la façon de structurer un build agentique, le système d'admissibilité de visa Fursa est un exemple concret de ce type de raisonnement appliqué à un vrai produit avec de vrais enjeux. Et si vous voulez travailler sur l'architecture de votre propre système, engagez une conversation avec Kadon ou contactez directement.