MCP, A2A et ACP en pratique : comment une banque relie les outils et les agents entre eux.

Une série de mises à jour des modèles au cours des dernières années a suivi un schéma identique. Un modèle plus puissant apparaît, écrit un code de meilleure qualité, raisonne de manière plus claire et gère des contextes plus complexes. En quelques semaines, l’enthousiasme retombe, car un modèle intelligent se trouvant seul dans une fenêtre de chat ne peut toujours pas consulter le solde d’un client, bloquer une transaction suspecte ou obtenir l’historique de crédit d’un candidat. L’intelligence n’a jamais été le véritable goulot d’étranglement : c’était plutôt la connexion.

Les efforts d’ingénierie se sont déplacés du simple volume des modèles vers la conception de protocoles. Trois spécifications visent le problème de la connexion : le MCP (Model Context Protocol), l’A2A (Agent-to-Agent) et l’ACP (Agent Communication Protocol). Ensemble, elles déterminent comment un modèle accède aux outils, comment un agent communique avec un autre, et comment plusieurs agents peuvent partager des tâches sans sombrer dans le chaos.

Un exemple illustre bien tout ce qui suit : une banque qui développe un assistant IA chargé de détecter la fraude, d’évaluer les demandes de prêt et de communiquer avec les systèmes bancaires de base, tout en restant suffisamment auditable pour satisfaire les régulateurs.

Pourquoi un modèle pur a besoin de protocoles

Laiscé à lui-même, un modèle de langage ne fait que prédire du texte. Si l’on lui demande s’il y a eu des activités suspectes sur le compte d’un client ce mois-ci, il refusera de répondre ou donnera une réponse fluide mais fausse, car le véritable registre des transactions est hors de sa portée.

Les premières solutions consistaient à connecter directement les modèles aux API REST, un connecteur après l’autre. Un assistant anti-fraude nécessitait du code personnalisé pour l’API bancaire de base, encore plus pour le CRM, et encore davantage pour la gestion des dossiers. Les déploiements de petite envergure fonctionnaient. Ceux de plus grande taille se heurtaient à trois problèmes :

• Rien n’était réutilisable. Le connecteur de banque en ligne utilisé par l’équipe de lutte contre la fraude était inutile pour l’équipe des prêts, bien que les deux équipes aient eu besoin des mêmes données de transaction ; par conséquent, chaque projet devait être lancé à zéro.
• Il n’y avait pas de persistance entre les requêtes. Les API sont conçues pour être sans état. Un analyste qui avait récupéré les transactions d’un client et qui, deux questions plus tard, demandait s’il y avait quelque chose d’anormal dans ces données a constaté qu’une intégration API classique ne conservait aucun lien entre les deux requêtes, à moins que les ingénieurs ne créent manuellement une couche de mémoire.
• Les permissions étaient ajoutées à la hâte. Chaque action bancaire nécessite une vérification des permissions ainsi qu’un enregistrement pour les auditeurs. Un analyste junior spécialisé dans la fraude peut consulter l’historique des transactions, mais il ne peut pas approuver l’annulation d’un virement. L’intégration de chaque API de manière ad hoc rendait difficiles l’application de règles aussi précises et leur démonstration aux auditeurs.

Un protocole règle le contrat une seule fois. Aucune banque n’a besoin de concevoir sa propre méthode pour que le modèle appelle le moteur de détection de fraude, car MCP fournit une seule interface. Aucune équipe n’a besoin de créer sa propre façon de transmettre une affaire d’un agent de détection de fraude à un agent de conformité, car A2A en propose une autre. HTTP l’a fait pour les applications en réseau et SQL l’a fait pour les bases de données : un langage commun qui permet aux systèmes développés de manière indépendante de fonctionner ensemble.

Cinq étapes de conception

La conception de systèmes a traversé cinq étapes, dans la banque comme ailleurs.

1. Un simple LLM. Le modèle répond uniquement à partir des données d’entraînement. Il peut expliquer ce qu’est le KYC, mais il ne peut pas déterminer si le profil d’un client donné respecte les règles de KYC de la banque, car il n’a jamais accès aux données de ce client.
2. Génération augmentée par la récupération d’informations. Le modèle se connecte à un stockage de documents tels que le manuel de conformité et les directives réglementaires antérieures, de sorte que les réponses s’appuient sur du contenu actuel, privé et spécifique à l’organisation, et non sur des connaissances générales issues de l’entraînement.
3. Agents. Le modèle peut non seulement récupérer des informations mais aussi agir. Un assistant à la conformité peut désormais citer la politique KYC et vérifier en même temps les documents d’un client archivés par rapport à cette politique, en signalant toute disparité.
4. Systèmes multi-agents. Un seul agent chargé simultanément de la détection de la fraude, de l’analyse des risques et de la communication avec les clients devient peu fiable et difficile à gérer. Les tâches sont alors réparties entre des spécialistes, tels qu’un agent anti-fraude, un agent de crédit et un agent de communication client, chacun expert dans un domaine précis.
5. Protocoles. Lorsqu’il y a de nombreux agents et de nombreux systèmes, il est nécessaire d’avoir une méthode standard leur permettant de se découvrir mutuellement, de partager des informations contextuelles et de communiquer en toute sécurité. MCP, A2A et ACP répondent à ce besoin.

Aujourd’hui, la plupart des banques se trouvent entre la troisième et la quatrième étape. Des agents individuels existent, souvent un par cas d’usage, mais en l’absence de protocole commun entre eux, chaque nouvel agent exige encore davantage d’intégrations sur mesure. C’est pour combler cette lacune que les protocoles ont été conçus.

Appel d’outils, la couche sous-jacente à MCP

Avant MCP, il existait l’appel d’outils, également appelé appel de fonction. Celui-ci permet à un modèle de demander une action externe au lieu de ne produire que du texte, et MCP est construit sur cette base.

La mécanique est simple. Pour chaque outil disponible, un développeur écrit un JSON Schema indiquant un nom, une description et des paramètres de type, puis le envoie au modèle accompagné du prompt. Lorsque le modèle détermine qu’un outil est nécessaire, il ne fait rien. Sa sortie est un objet JSON structuré indiquant le nom de l’outil et fournissant les arguments, et l’application environnante exécute cette fonction et renvoie le résultat au modèle. Un schéma bancaire ressemble à ceci :

{
  "name": "get_customer_transactions",
  "description": "Returns transactions for a customer above a given amount, within a date range",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "min_amount": {"type": "number"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"}
    },
    "required": ["customer_id", "start_date", "end_date"]
  }
}

Supposons qu’un analyste de fraude demande à consulter les dernières transactions importantes d’un client, supérieures à cinq mille dollars au cours du dernier mois. La mémoire n’est pas utilisée pour répondre. Le modèle émet plutôt une requête vers get_customer_transactions en indiquant l’ID du client, le seuil de montant et la période concernée. L’application interroge ensuite la base de données bancaire pour obtenir les données réelles, les renvoie telles quelles, et le modèle les transforme en un résumé lisible.

Les outils simples qui effectuent des appels gèrent bien un seul modèle avec quelques outils prédéfinis. Les problèmes commencent lorsque des dizaines d’outils sont dispersés dans les systèmes bancaires de base, de détection des fraudes, de CRM et de gestion des documents, que des outils doivent être ajoutés sans devoir redéployer chaque client, ou encore lorsqu’un outil doit être partagé en toute sécurité entre les assistants chargés des fraudes et des prêts. MCP vise précisément ces problèmes.

MCP en détail

MCP est arrivé d’Anthropic à la fin de 2024 en tant que norme ouverte permettant de relier les applications d’IA à des systèmes externes. Pensez à un adaptateur universel. Auparavant, pour connecter un assistant bancaire au système bancaire de base, au moteur de détection des fraudes et au CRM, il fallait trois intégrations incompatibles. Désormais, tout client conforme à MCP peut communiquer avec tout serveur conforme à MCP, tout comme n’importe quel appareil USB s’adapte à n’importe quel port USB.

L’arithmétique de M fois N

Le problème de base est combinatoire. Relier M outils à N applications génère une matrice qui devient ingérable à mesure que ces deux nombres augmentent. Une banque disposant de cinq systèmes internes et de quatre assistants (détection des fraudes, prêts, service client, conformité) aurait besoin de jusqu’à vingt connecteurs personnalisés. Un protocole standard réduit ce nombre à cinq plus quatre, puisque chaque système et chaque assistant implémentent MCP une seule fois.

Trois rôles

• Hôte : l’application d’IA que l’utilisateur voit réellement, par exemple l’interface d’assistance d’un analyste de fraude.
• Client : un composant à l’intérieur de l’hôte qui gère une connexion vers un serveur MCP et s’occupe de la communication au niveau du protocole.
• Serveur : la partie qui expose des fonctionnalités, c’est-à-dire des données ou des actions. Une banque peut mettre en place un serveur devant son système bancaire de base, un autre devant son moteur de détection de fraude et un troisième devant son répertoire de documents, chacun étant géré par l’équipe responsable du système correspondant.

Trois primitives que peut offrir un serveur

• Ressources : elles contiennent des données en lecture seule que le modèle peut intégrer dans son contexte, par exemple un extrait de compte ou l’état des documents de vérification d’identité. Comme une requête GET, elles fournissent des informations sans rien modifier.

Outils : ils exécutent des actions telles que le gel d’une partie d’un compte ou l’envoi d’une demande à un responsable de conformité. Comme une requête POST, ils modifient l’état des données, ce qui en fait les éléments les plus nécessitant des contrôles d’approbation humaine dans une banque.

Modèles de demande : ce sont des templates paramétrables réutilisables qui guident le modèle pour générer une demande bien structurée. Un exemple est un modèle standard d’escalade en cas de fraude utilisé de la même manière par tous les assistants analystes, de sorte qu’aucune équipe n’a besoin de conserver sa propre version légèrement différente.

Échantillonnage, découverte et transfert

L’échantillonnage permet à un serveur de demander à l’LLM du hôte de compléter une tâche, en s’appuyant sur le raisonnement du modèle pour effectuer une sous-tâche. Un serveur de stockage de documents peut l’utiliser pour faire résumer par le modèle un long contrat de prêt avant de le restituer, un analyste humain examinant ensuite ce résumé avant d’intervenir.

La découverte a lieu lorsque un client se connecte et demande à un serveur quels ressources, outils et instructions il propose, ce qui rend MCP dynamique. Dès que l’équipe anti-fraude publie un nouvel outil pour vérifier l’historique du dispositif d’un client, chaque assistant connecté peut l’utiliser immédiatement, sans modification du code du client.

Le format de communication est JSON-RPC 2.0, transmis via l’un de deux protocoles courants. Stdio convient à un serveur exécuté sur la machine même du client. HTTP avec Server-Sent Events, ou HTTP streamable, convient à un serveur distant. Un serveur de banque en ligne situé dans le data center et derrière un pare-feu serait accessible via HTTP distant avec une authentification appropriée, et non via Stdio.

Sécurité

Les industries réglementées sont celles où MCP gagne sa vie, bien qu’il ne fournisse pas de contrôles automatiques. Il offre aux ingénieurs un endroit cohérent pour les créer et les appliquer, plutôt que de devoir réinventer la sécurité à chaque intégration. Une mise en œuvre bancaire de production doit :

• exiger OAuth 2.1 lorsque les clients s’authentifient auprès des serveurs ;
• accorder à chaque outil uniquement les permissions dont il a besoin, de sorte que le jeton d’un analyste junior ne puisse pas accéder à des fonctions comme approve_wire_transfer ;
• conserver un enregistrement pour chaque appel à un outil ;
• exiger une confirmation explicite d’un humain avant toute action modifiant l’état, comme la mise sous gel d’un compte ou la levée d’une restriction.

À quoi ressemble une mise en œuvre MCP

Une déploiement bancaire typique se compose de trois couches. L’hôte correspond à l’interface de chat ou au moteur d’exécution des agents que voit l’utilisateur, comme par exemple un assistant d’enquête. Un client MCP intégré à l’hôte ouvre des sessions avec les serveurs, envoie des demandes de découverte et transmet les appels aux outils d’un serveur à l’autre. Chaque serveur gère un système d’information spécifique, tel que le système bancaire de base, le moteur de détection de fraude ou le stockage de documents, et chacun est entretenu et sécurisé par l’équipe qui en est responsable.

Une enquête sur une fraude montre le chemin de la demande :

1. Un analyste souhaite obtenir toutes les transactions supérieures à dix mille dollars effectuées par un client au cours des trente derniers jours, ainsi qu’une vérification pour savoir si l’empreinte du dispositif a récemment changé.
2. Le LLM de l’hôte détermine qu’il faut effectuer deux appels aux outils et indique au client d’exécuter get_transactions sur le serveur du système bancaire de base et get_device_history sur le serveur du moteur de détection de fraude.

Le client envoie des requêtes JSON-RPC vers les deux serveurs via HTTPS.

Chaque serveur vérifie la portée OAuth de l’analyste ainsi que son droit d’accéder aux données de ce client, interroge son propre système de base de données et répond.

Le client transmet les deux réponses au modèle, qui les combine en un résumé unique.

Tout, y compris les appels, les réponses et l’identité de l’analyste, est enregistré dans le journal d’audit.

Un serveur Python minimal utilisant le modèle SDK officiel montre à quel point peu de code est nécessaire pour un outil de ce type :

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("core-banking-server")
@mcp.tool()
def get_transactions(customer_id: str, min_amount: float, days: int) -> list:
    """Fetch transactions above a threshold for a customer, scoped to the caller's authorization."""
    # In production this calls the real core banking API,
    # scoped and logged, never queried directly by the model.
    return query_core_banking(customer_id, min_amount, days)
@mcp.tool()
def place_transaction_hold(transaction_id: str, reason: str) -> dict:
    """Places a temporary hold on a transaction pending review. Requires human confirmation before execution."""
    return execute_hold(transaction_id, reason)
if __name__ == "__main__":
    mcp.run(transport="stdio")

Les deux outils qu’ils contiennent méritent une gestion différente en pratique. get_transactions est un outil de lecture, similaire à un Resource, et peut être exécuté sans étape de confirmation. place_transaction_hold modifie l’état dans un système financier réel, il ne doit donc jamais être déclenché simplement parce que le modèle le demande. La couche d’application doit d’abord le faire passer par une confirmation explicite de l’analyste.

Quelques habitudes permettent de maintenir les serveurs de production en bon état :

• Attribuer à chaque serveur un seul système à gérer, et non un monolithe couvrant la banque de détail, la lutte contre la fraude et le CRM.
• Rédiger des descriptions des outils de la même manière que l’on écrirait de la documentation destinée à un nouvel analyste, car c’est uniquement à partir de ce texte que le modèle détermine quand un outil est applicable.
• Versionner les schémas des outils. Modifier un paramètre obligatoire dans get_transactions sans préavis endommage tous les assistants qui en dépendent, y compris ceux qui ne font pas partie de l’équipe chargée de la lutte contre la fraude.

Considérez que chaque appel à outil représente une entrée non fiable pour le système suivant et validez-la, car une sortie de modèle manipulée pourrait sinon tenter une requête non autorisée.

A2A, agents qui communiquent entre eux

MCP gère les liens entre modèles et outils. A2A, introduit par Google en 2025 et maintenant maintenu par la Linux Foundation, gère un type de lien différent : un agent autonome qui sollicite un autre, en particulier lorsque ceux-ci ont été développés par des équipes ou des fournisseurs différents.

Un seul agent ne suffit pas, car un agent unique chargé de la détection de la fraude, de l’underwriting et de la communication devient un système complexe difficile à gérer, et il devient très difficile de prouver à un auditeur quelle logique a pris les décisions. Des spécialistes qui se déléguent les tâches les uns aux autres offrent une solution plus claire et plus sûre.

La délégation s’appuie sur la carte de l’agent, un document lisible par machine décrivant ce que l’agent peut faire. Elle ressemble à la liste d’outils d’un serveur MCP, mais décrit les capacités d’un agent dans son ensemble, et non des fonctions individuelles. Un agent assistant client coordonnateur lit la carte de l’agent chargé de la fraude et apprend qu’il peut examiner les transactions contestées ; il lit ensuite la carte de l’agent chargé des prêts et découvre qu’il peut évaluer l’éligibilité au refinancement, avant de choisir le bon agent délégué pour répondre à la demande du client.

Coordination définit la manière dont les agents se transmettent des tâches, diffusent des résultats partiels et communiquent des succès ou des échecs via un transport standard. Chaque partie considère l’autre comme une boîte noire. L’agent d’assistance au client n’a pas besoin de savoir comment l’agent de lutte contre la fraude a été conçu, s’il utilise des outils MCP dans le système bancaire de base, quel modèle le pilote ou combien d’étapes il implique. Il a seulement besoin des capacités de l’agent et d’un moyen de lui envoyer des tâches.

Deux cas bancaires illustrent cela. Tout d’abord, un client signale une charge inconnue de cinq cents dollars sur sa carte et demande également des informations sur un taux d’emprunt plus avantageux. L’assistant ne gère ni l’un ni l’autre directement. Il envoie le litige à l’agent de lutte contre la fraude et la question concernant l’emprunt à l’agent de prêts, les exécute en parallèle, puis fusionne les réponses en une seule réponse.

Deuxièmement, l’agent anti-fraude examine cette charge en appelant les serveurs MCP pour la banque de détail ainsi que le moteur anti-fraude afin d’obtenir les enregistrements des transactions et des appareils. Lorsque sa confiance dans un verdict de fraude est faible, il évite de deviner et transmet l’affaire via A2A à un agent d’examen de la conformité, qui applique des règles réglementaires plus strictes et, si nécessaire, la transmet à un responsable de conformité humain. Assistant client, agent anti-fraude, agent d’examen de la conformité, agent humain : telle est la délégation structurée pour laquelle A2A a été conçu.

ACP, la couche de messagerie

Tandis qu’A2A se concentre sur la délégation des tâches, ACP se concentre sur la messagerie au sein des conversations entre plusieurs agents, en particulier sur la gestion de l’état, de la mémoire et des erreurs au cours d’interactions plus longues.

• Architecture. Les conversations se transforment en séquences de messages tapés. Chaque message contient du contenu ainsi que des métadonnées sur son expéditeur, son fil de discussion et la réponse attendue. Une escalade de fraude à conformité inclurait donc plus que le dossier lui-même : des champs structurés pour l’ID du dossier, l’agent demandeur, le degré d’urgence et le type de réponse attendu.
• Communication par messages. La structure remplace le texte brut, tout comme un e-mail possède un sujet, un expéditeur et un corps, et n’est pas un bloc unique de caractères. Lorsque une dizaine d’agents travaillent sur un même processus de prêt, chaque message doit parvenir à l’agent approprié ainsi qu’au responsable compétent au sein de ce dernier.

État. L’underwriting qui passe par un agent d’éligibilité, un agent de risque et un agent d’approbation doit conserver l’état de l’application au cours de multiples échanges. ACP définit des conventions pour enregistrer et mettre à jour cet état partagé, tel que les vérifications effectuées et les documents en attente, afin que aucun agent ne perde de vue l’application, même lorsque le processus dure des jours.

Mémoire. La mémoire de conversation à court terme, liée à l’application en cours, est conservée séparément de la mémoire à long terme transmise entre les sessions ; par exemple, les préférences connues d’un client pour un prêt immobilier à taux fixe, qui doivent guider la conversation sans nécessiter de questions répétées.

Gestion des erreurs. Une tentative d’appel à un agent échouée dans la banque ne peut pas simplement disparaître. Supposons que l’agent chargé des risques ne puisse pas obtenir un rapport de crédit en raison d’une panne interne. ACP définit des erreurs structurées, ce qui permet à l’agent chargé de l’évaluation de choisir entre une nouvelle tentative, une transmission à un évaluateur humain ou une pause, et empêche que des décisions partielles ou erronées ne passent inaperçues.

Comparaison des cinq solutions

Lorsqu’elles sont présentées côte à côte, ces options diffèrent selon plusieurs critères :

• Ce qu’elles relient. Une API classique relie une application à une autre. L’appel de outil relie un modèle à une fonction. MCP relie un modèle ou une application à des outils, des données et des instructions. A2A relie des agents entre eux. ACP relie des agents entre eux au niveau des messages.
• Standardisation entre les fournisseurs. Les API classiques : non. L’appel de outil : partiellement. MCP, A2A et ACP : oui.
• Découverte des capacités. Aucune pour les API simples et les appels d’outils. Dynamique pour MCP, via des cartes d’agent pour A2A, limitée pour ACP.
• Conventions intégrées de statut et de mémoire. Aucune pour les API simples et les appels d’outils, partielles pour MCP et A2A, et c’est le point central pour ACP.
• Illustration bancaire. La banque de base qui communique avec un CRM ; un assistant qui appelle une fonction de solde prédéfinie ; un assistant qui découvre et appelle de manière uniforme les outils de banque de base, de détection de fraude et de gestion de documents ; un agent de détection de fraude qui délègue à un agent d’examen de conformité ; suivi de l’état d’approbation d’un prêt sur plusieurs jours par trois agents.

Ces options se complètent plutôt qu’elles ne se concurrencent. Un assistant bancaire de production combinera probablement MCP pour relier les agents aux systèmes centraux, A2A pour la délégation entre spécialistes, et les conventions ACP pour gérer des workflows complexes impliquant plusieurs agents, tels que l’underwriting, du début à la fin.

Un seul message client, du début à la fin

Prenons un seul message : le client ne comprend pas une facture de cinq cents dollars et souhaite également connaître des taux d’emprunt plus avantageux. L’ensemble du système répond étape par étape.

1. Le client envoie le message à l’Assistant IA, l’application hôte intégrée à l’application bancaire.
2. Grâce à A2A, l’assistant transmet la question liée à la fraude à l’Agent anti-fraude et la question concernant l’emprunt à l’Agent prêt, les deux étant traités en même temps.
3. L’agent anti-fraude appelle le serveur CRM via MCP pour obtenir l’historique des contacts et des plaintes, ainsi que le serveur de banque de détail pour la transaction contestée. Après avoir appliqué ses règles anti-fraude, il utilise l’outil place_transaction_hold du serveur de banque de détail, toujours via MCP. Cette demande est transmise à un analyste humain pour confirmation avant d’être exécutée, car elle modifie l’état de la transaction.
4. L’agent chargé des prêts récupère les conditions actuelles du prêt immobilier et le profil de crédit depuis le serveur de banque de détail via MCP, les compare aux tableaux des taux actuels et élabore une recommandation. Comme proposer un taux de refinancement nécessite l’approbation d’un évaluateur, aucune action n’est exécutée ; l’agent transmet simplement sa recommandation ainsi que les données de soutien dans un résumé destiné aux humains.
5. Les deux agents communiquent à nouveau avec l’assistant par l’intermédiaire d’A2A, en utilisant des messages structurés de type ACP qui indiquent l’état du dossier, les approbations humaines en attente et les constatations relevées.
6. L’assistant utilise MCP pour envoyer au client un e-mail confirmant le blocage, et enregistre chaque appel à outil, chaque transfert de responsabilité ainsi que chaque limite de décision dans le système d’audit, car les autorités de régulation s’attendent précisément à ce type de trace en cas d’examen du dossier.

L’interopérabilité dans une banque se manifeste donc ainsi : pas de modèle géant unique tentant de tout gérer, mais des agents spécialisés disposant d’un accès contrôlé aux outils, chacun excellant dans sa tâche, avec en plus une trace d’audit claire.

Sécurité entre agents et protocoles

• Injection de commandes. Une instruction malveillante dissimulée dans un document, un e-mail ou un fichier téléchargé peut tenter de contrôler la prochaine action d’un agent. Imaginez un litige frauduleux contenant du texte caché qui ordonne à l’agent chargé des fraudes d’approuver la demande sans vérification. Les outils MCP modifient l’état réel, ce qui rend le danger concret. Mesures de prévention : traiter tout contenu récupéré comme non fiable, ne jamais permettre à la sortie du modèle de déclencher un outil à haut risque tel que place_transaction_hold sans vérification préalable, et limiter les outils que le modèle peut voir dans un contexte donné.
• Authentification. Chaque liaison client-serveur MCP ainsi que chaque transfert A2A nécessitent une authentification, généralement via OAuth 2.1, afin qu’un utilisateur anonyme ne puisse pas utiliser d’outil de banque en ligne ou assigner des tâches à l’agent chargé de l’examen de conformité.

Authentification. L’authentification indique qui appelle, tandis que l’autorisation précise ce que cet appelant peut faire. Un agent anti-fraude authentifié doit néanmoins se voir refuser l’accès à un outil permettant d’approuver une modification du taux d’emprunt, car cela dépasse ses compétences, quel que soit le degré de certitude de ses raisonnements.

Zéro confiance. Aucun maillon de la chaîne n’est considéré comme fiable par défaut, que ce soit le modèle, un autre agent ou un serveur intermédiaire. La politique est vérifiée à chaque exécution d’un appel, sans être ignorée simplement parce qu’elle provient du système d’IA interne de la banque.

Approbation humaine. Les actions ayant des conséquences financières, de sécurité ou réglementaires, telles que le gel d’un compte, la levée d’une restriction ou l’approbation d’un prêt, nécessitent une confirmation humaine. Il s’agit d’une décision de conception adaptée à l’importance de l’action, et non d’une faiblesse de la technologie.

Journal des audits. Enregistrer chaque appel à l’outil, chaque délégation et chaque changement d’état avec suffisamment de détails pour reconstituer ce qui s’est passé et pourquoi. Si un régulateur demande pourquoi un compte a été retenu pendant six heures, la banque doit pouvoir présenter la chaîne exacte des décisions des agents et des appels aux outils, et non une estimation.

La direction future

La direction du trajet est facile à lire. Des protocoles tels que MCP deviennent la couche de pilote de dispositif pour l’IA, offrant une voie standard pour relier n’importe quel modèle à n’importe quel outil, sans avoir recours à des solutions sur mesure. On peut s’attendre à ce que les systèmes d’exploitation pour l’IA deviennent une catégorie à part entière, où les serveurs de type MCP constituent une infrastructure de premier plan, à l’instar des bases de données et des files d’attente de messages, et où un serveur bancaire de base est quelque chose que chaque projet d’IA interne peut intégrer directement, sans avoir à le développer à nouveau. On peut également s’attendre à l’apparition de marchés de serveurs prévérifiés et audités, permettant à une banque d’adopter un serveur de vérification KYC approuvé pour les exigences réglementaires, au lieu de devoir en créer un elle-même. Des outils de gouvernance devraient également voir le jour pour auditer les appels MCP et les délégations A2A, car les équipes chargées du respect des réglementations et de la gestion des risques souhaiteront disposer de cette visibilité avant que tout cela ne touche de l’argent réel. Enfin, on peut s’attendre à ce que ces mêmes schémas s’étendent bien au-delà du secteur bancaire, vers tous les domaines où un système de raisonnement a besoin d’une méthode standard et auditable pour agir dans le monde réel.

La version courte

Un modèle seul ne peut pas vérifier un solde, placer un gel ou évaluer un prêt immobilier. MCP standardise l’accès aux outils, aux données et aux instructions, permettant à un assistant anti-fraude et à un assistant prêts de partager un même serveur bancaire de base sans intégration redondante. A2A standardise la manière dont les agents spécialisés se transmettent le travail sans avoir à connaître les mécanismes internes de l’autre. ACP standardise la messagerie, la gestion des états et la gestion des erreurs dans des processus complexes tels que l’approbation d’un prêt sur plusieurs jours. Dans une banque, ces protocoles ne sont pas de simples commodités : ce sont eux qui permettent d’assurer l’autorisation, les traçabilités et l’approbation humaine à grande échelle.

Deux règles de conception en découlent. MCP sépare les ressources en lecture seule des outils qui modifient l’état, et la conception des autorisations doit suivre cette séparation, car vérifier un solde et envoyer un signal de transmission présentent des risques très différents. De plus, des mécanismes d’approbation humaine ainsi que des traces d’audit pour chaque appel de protocole sont des exigences fondamentales ; ils doivent donc figurer dans la première ligne de code et non dans une mise à jour ultérieure.