Votre agent IA a un problème de règlement

Les banques investissent massivement dans l’IA agentique et, séparément, dans une infrastructure tokenisée. La plupart les considèrent comme des parcours parallèles qui finiront par converger. Cette hypothèse de séquencement mérite d’être examinée, car les deux programmes sont plus interdépendants que ce que la plupart des feuilles de route technologiques reflètent actuellement.

Voici le problème sous-jacent. Les systèmes d’IA agentique sont fondamentalement différents des modèles prédictifs et des outils d’aide à la décision qui les ont précédés. Un modèle fait émerger une information. Un agent agit en conséquence. Cette distinction n’est pas une simple nuance marketing. Elle a des implications directes pour l’infrastructure, que la plupart des plans de déploiement n’ont pas encore prises en compte.

Quand un agent agit, la transaction doit être réglée. Pas à la fin de la journée. Pas le jour ouvré suivant. Au moment de l’exécution, parce que la prochaine instruction du workflow dépend du résultat de la précédente.

Le règlement par lots casse entièrement cette dépendance. Si un agent identifie un déficit de liquidité, sélectionne le collatéral optimal à déplacer et initie le transfert, mais que l’infrastructure de règlement ne peut confirmer l’irrévocabilité qu’au cours du lendemain matin, l’agent ne gère pas la trésorerie en temps réel. Il met en file des instructions dans un système qui les traitera selon un calendrier conçu pour un monde où les humains en étaient les acteurs. Au moment où ces instructions sont réglées, les conditions de marché qui les ont déclenchées peuvent ne plus être d’actualité. L’agent n’a pas échoué. Les rails, oui.

NTT DATA a décrit cela comme le « stack gap » (l’écart de couche), le fossé entre ce que l’IA agentique exige et ce que la plupart des infrastructures bancaires peuvent réellement livrer. Des recherches du MIT, citées dans plusieurs analyses sectorielles, ont constaté que les échecs d’intégration de l’infrastructure, et non la qualité des modèles, sont la principale raison pour laquelle les pilotes IA dans la banque n’apportent pas une valeur mesurable à grande échelle. L’intelligence n’est pas le facteur limitant. La fondation, si.

Cela compte particulièrement pour les opérations de trésorerie et de paiements, où la valeur de l’exécution autonome est la plus directe. Un agent qui gère le collatéral intrajournalier entre contreparties, qui surveille les expositions en continu et qui optimise les positions de trésorerie en temps réel nécessite une infrastructure capable de suivre ce rythme. La perspective 2026 d’A16z l’indique directement : les agents IA auront besoin de paiements qui évoluent à la vitesse d’Internet, soutenus par des outils de règlement programmables. Le passage vers des systèmes autonomes pilotés par l’intention n’est pas compatible avec des rails conçus autour de fenêtres de traitement humaines.

Ce dont les workflows financiers autonomes ont réellement besoin, c’est d’un règlement atomique : l’échange simultané et irrévocable de valeur qui confirme l’irrévocabilité en temps réel. C’est précisément ce que l’infrastructure tokenisée est en train d’être construite pour fournir. Le token de dépôt de JPMorgan sur Base, la plateforme de dépôts tokenisés de BNY pour les clients institutionnels, et le consortium du Cari Network, composé de cinq banques régionales, représentent tous, au cœur, la construction de rails de règlement qui ne dépendent pas de cycles de batch nocturnes. Ce ne sont pas uniquement des récits de tokenisation. Ce sont des récits d’infrastructure pour l’IA. Les institutions qui construisent aujourd’hui des rails de règlement programmables construisent les prérequis pour des opérations financières autonomes à grande échelle.

L’implication en termes de séquencement pour les banques qui exécutent ces éléments comme des programmes distincts est directe. À un moment donné, à court terme, les agents déployés dans les workflows de trésorerie et de paiements seront capables d’exécuter des décisions plus vite que l’infrastructure de règlement sous-jacente ne peut les confirmer. Quand cela se produira, l’organisation aura un choix à faire : contraindre les agents à ce que les rails permettent, en acceptant que l’exécution autonome s’arrête à la frontière où commence la transmission manuelle, ou reconstruire les rails à un coût et une complexité nettement plus élevés que si les deux programmes avaient été conçus comme un seul programme dès le départ.

Il existe aussi une dimension orientée client qu’il vaut la peine de nommer. Les équipes de trésorerie d’entreprise construisent leurs propres workflows agentiques. Un client qui construit une fonction de trésorerie native de l’IA n’aura pas besoin que sa banque gère ces décisions. Il aura besoin de l’infrastructure de sa banque pour permettre l’exécution autonome sans réintroduire une intervention manuelle à la frontière du règlement. Les banques qui ne peuvent pas le faire verront les clients d’entreprise se tourner vers des institutions ou des plateformes capables de le faire.

La question pratique pour chaque banque qui exécute actuellement un programme d’IA agentique est de savoir si l’infrastructure de règlement dont ces agents dépendront éventuellement est construite en parallèle. Pas comme une considération future. Comme une décision de conception actuelle. Les deux programmes ne sont pas séquentiels. Ils constituent le même programme.