L'émergence du commerce agentique soulève une question majeure : comment permettre aux entreprises d'automatiser leurs paiements tout en garantissant la sécurité des transactions ? Ralio, start-up fondée à Londres en juillet 2025, entend y répondre en développant une couche de confiance entre agents IA et infrastructures de paiement B2B. Son co-fondateur et CEO, Ghali Bennani Laafiret nous en détaille la vision.

La notion de "trust", de confiance, recouvre plusieurs dimensions. Concrètement, il s'agit de faire en sorte que les entreprises puissent faire confiance à leurs agents IA au moment de réaliser des paiements. Pour y parvenir, il faut trois choses : d'abord, que l'agent dispose des paramètres adéquats au moment où il décide d'effectuer une action de paiement. Ensuite, qu'on puisse authentifier l'agent et s'assurer que c'est bien lui qui effectue l'action. Et enfin, que toutes les parties de l'écosystème aient accès à un journal d'audit retraçant l'ensemble des actions effectuées. C'est ce qui doit permettre de lever le frein principal que l'on observe aujourd'hui : les entreprises voient ce que ces agents sont capables de faire, mais n'ont pas encore suffisamment confiance pour leur confier des paiements sensibles, comme des salaires, par exemple.

Il faut distinguer trois grandes catégories lorsqu’on parle de paiement agentique. La première, c'est le paiement consommateur : un utilisateur qui effectue ses achats via ChatGPT, par exemple, et arrive chez un marchand qui doit pouvoir l'accueillir. La deuxième, c'est le machine-to-machine : un agent qui, pour accéder à des ressources, doit payer pour utiliser un navigateur, accéder à du contenu payant, etc. C'est un agent qui interagit avec un autre agent. Et la troisième, c'est le B2B, sur lequel nous intervenons : une entreprise qui veut automatiser des pans de ses processus, dont ses paiements: régler des prestataires, gérer sa trésorerie... Nos clients typiques sont des entreprises qui utilisent plusieurs solutions de paiement sans vraiment s'y retrouver, ou qui ont commencé à explorer des outils d'automatisation pour gagner en efficacité.

Nos clients peuvent interagir de plusieurs façons. Ils peuvent utiliser directement notre console, une interface classique où ils connectent leur agent et configurent les différentes tâches. Ils peuvent aussi y accéder depuis leur outil d'automatisation, via un MCP (Model Context Protocol, ndlr), qui est l'interface de connexion standard dans l'écosystème agentique. Ou encore via un CLI, un outil en ligne de commande, plus natif pour les agents. En résumé : l'interface graphique s'adresse plutôt aux humains qui configurent les règles. L'agent, lui, interagira via MCP ou CLI selon le profil: CLI pour un développeur, MCP pour un profil métier.

Cela se configure pour chaque agent. On peut avoir des agents en lecture seule, qui se contentent d'extraire de la donnée: "combien ai-je dépensé ce mois-ci ?" Ensuite, il y a le mode supervisé : l'agent agit dans ses limites définies et fait appel à un humain dès qu'il les dépasse, ou s'il reçoit une instruction hors de son périmètre. Si on a configuré un agent pour gérer des salaires et qu'on lui demande de payer une facture fournisseur, il bloque ou demande la validation. Enfin, nous avons aussi des agents autonomes, qui sur des cas d'usage bien définis n'ont pas besoin d'approbation humaine. C'est volontaire de notre part : une facture qui doit être payée doit l'être.

Nous sommes vraiment aux prémices du paiement agentique, et la technologie est loin d’être adoptée. Une fois qu'un agent commence à être mis en production, et c'est là le vrai sujet, le problème fondamental c'est qu'un modèle, aussi bien entraîné soit-il, va formuler des hypothèses sur la meilleure façon d'agir dans un contexte donné. Dans le domaine des paiements, une hypothèse peut mener dans le bon ou le mauvais sens. Ce que nous faisons, c'est remettre l'agent sur des rails : on définit les attentes pour chaque type de paiement B2B qu'il pourrait vouloir effectuer. Un développeur ou un acteur de l'infrastructure de paiement pourrait reconstruire cela lui-même, mais cela nécessite d'anticiper un grand nombre de scénarios, ce qui représente beaucoup de temps et d'énergie. Nous leur permettons d'abstraire ce raisonnement et d'aller plus vite.

Nous sommes parmi les acteurs les plus avancés sur ce segment, mais le domaine lui-même est encore naissant. Faire exécuter un paiement à un agent est techniquement possible aujourd'hui. Mais le vrai enjeu, c'est de le faire à l'échelle et sur différents rails. Aujourd'hui, nous travaillons principalement sur le virement de compte à compte, car cela fonctionne nativement via des API. Les cartes bancaires nécessitent encore des développements, la tokenisation n'est pas encore déployée à grande échelle, même si les grands réseaux y travaillent. Nous avons intégré des acteurs du Banking-as-a-Service et du business banking, et nous allons continuer ce travail d'intégration pour aller ensuite voir leurs clients. La levée nous donne trois leviers pour accélérer : l'éducation du marché, le développement technique - on tourne des millions de simulations pour comprendre le comportement des agents - et le réseau. Avec neuf investisseurs, cela nous ouvre des portes vers des partenaires et des clients. L'objectif est de démontrer, via nos partenariats et nos développements, que ce n'est pas juste une idée, mais que le potentiel est réel.

L'industrie des paiements est probablement la plus déterministe qui soit. On cherche à atteindre des taux de succès proches de 100 %, avec des systèmes anti-fraude et d'autorisation très stricts. L'agentique, à l'inverse, est l'interface la moins déterministe qui existe. Ce sont deux mondes qui ne sont pas naturellement faits pour se marier. L'idée reçue, c'est de dire : "On ne pourra jamais s'assurer qu'un agent fasse toujours les bons paiements." C'est vrai, dans l'absolu. Mais ce n'est pas la bonne façon de poser le problème. Sur des cas d'usage définis, avec les bonnes règles, on peut guider l'agent pour atteindre les mêmes taux de succès que dans le paiement traditionnel. C'est difficile, c'est pour ça qu'on a levé des fonds et qu'on y travaille, mais c'est possible.

C'est un sujet extrêmement intéressant, et si vous observez la posture de chaque acteur de l'écosystème, vous verrez que personne ne revendique la responsabilité. Elle sera nécessairement définie par un tiers. Notre réponse à ça, c'est l'audit. Un paiement agentique peut échouer pour des raisons qui n'ont rien à voir avec l'agent: une infrastructure de paiement qui n'a pas répondu à temps, par exemple. Avoir une trace précise de chaque étape permet de discuter entre acteurs ou avec les régulateurs, sur n'importe quel terrain. 

Les modèles vont effectivement s'améliorer dans leur compréhension de l'intention utilisateur. Mais il y a une limite structurelle : certains problèmes ne sont pas des problèmes de modèle. Un exemple concret : dans beaucoup d'API de paiement, les montants doivent être transmis en centimes pour éviter les problèmes liés aux virgules. Si on ne le précise pas à l'agent, il va envoyer 100 fois le montant voulu. Ce n'est pas un bug du modèle, c'est une contrainte de l'infrastructure de paiement que seul quelqu'un qui travaille dans ce domaine connaît. C'est pour ça que notre approche, aujourd'hui, c'est de prendre les modèles tels que nos clients vont les utiliser, et d'apporter nous-mêmes les configurations nécessaires pour que l'agent agisse correctement. À terme, on réfléchit à développer nos propres configurations directement au niveau du modèle, mais ce n'est pas notre priorité actuelle.

Honnêtement, je ne pense pas que ce soit sur cette période-là qu'on verra des entreprises existantes basculer massivement vers le tout-agentique. Ce qui m'intéresse davantage, ce sont les entreprises qui naissent aujourd'hui en étant natives de cette façon de fonctionner. Des entreprises où les ingénieurs n'auront jamais écrit de code qui n'ait pas été assisté par l'IA, et où l'automatisation est le mode par défaut, et non l'exception qu'on décide d'implémenter après coup. Historiquement, on a toujours fonctionné en mode manuel, et on automatisait quand c'était suffisamment utile. Avec un système agentique, la barrière à l'automatisation est beaucoup plus basse, et celle pour le maintenir aussi, parce que le système comprend lui-même les différents cas d'usage.