« Plateforme agentique » est un terme qui apparaît avec une fréquence croissante dans les présentations technologiques pour le secteur financier. Comme tout terme qui gagne en vitesse d'adoption, il risque de perdre en précision en chemin. Cet essai est l'opposé d'un pitch — c'est une description technique et fonctionnelle du fonctionnement d'une plateforme agentique pour le wealth management, écrite pour qui évaluera l'architecture, non pour qui doit être convaincu que la catégorie existe.
La structure comporte 3 couches : L'Esprit (graphe de mémoire persistante), Les Agents (force de travail autonome coordonnée) et Le Flux (cycle commercial de bout en bout). À la fin, nous parcourons un exemple réel — un message WhatsApp qui arrive à 14h23 et ce qui se produit dans les 60 secondes suivantes.
L'Esprit — graphe de mémoire persistante
Le point de départ de toute plateforme agentique efficace pour le wealth management est la résolution d'un problème fondamental : les agents ont besoin de contexte pour agir correctement. Sans contexte, un agent est aussi utile qu'un modèle générique — et les modèles génériques ne savent pas qui est votre client.
L'Esprit est un graphe de connaissances persistant — une représentation structurée d'entités (clients, proches, holdings, actifs, bankers responsables, événements) et des relations entre elles. Ce n'est pas une base de données relationnelle plate. C'est un réseau sémantique navigable : du client au portefeuille, du portefeuille aux actifs, des actifs aux événements de marché qui les affectent, des événements aux interactions enregistrées, des interactions au contexte émotionnel et stratégique capturé.
Ce que contient le graphe
- 01 Profil du client — données d'identité, suitability classé avec granularité (non simplement « conservateur » mais ce que cela signifie pour ce client : quels actifs il accepte, lesquels il rejette, quel horizon, quel contexte émotionnel face au risque).
- 02 Holdings et positions — structure patrimoniale complète : actifs sous custody, participations sociétales, holdings, offshore, biens immobiliers le cas échéant, avec mise à jour via flux de custody.
- 03 Historique des interactions — non simplement « appel — OK » mais le contenu structuré de chaque conversation pertinente : thèmes discutés, préoccupations exprimées, engagements pris, ton et contexte émotionnel.
- 04 Réseau familial et patrimonial — conjoint, enfants, héritiers, associés, relations ayant des implications pour la gestion du patrimoine et pour les décisions de suitability et de compliance.
- 05 Événements de marché connectés — news et événements rattachés aux positions affectées, avec pertinence calculée par client. Non les 500 actualités du jour — les 3 qui comptent pour ce client précis.
Le graphe est alimenté par de multiples sources : flux de custody, transcriptions WhatsApp traitées, notes de réunion des bankers, flux d'actualités filtrés, et enrichissement programmé par des agents spécialisés. Chaque donnée nouvelle est insérée avec timestamp, source et contexte — créant une ligne du temps auditable de tout ce que le système sait sur chaque client.
« L'Esprit n'est pas une base de données avec recherche. C'est ce qu'un banker avec 15 ans de maison sait — mais disponible à tout agent, instantanément, sans dégradation par turnover. »
Les Agents — force de travail coordonnée
Le second pilier est la force de travail agentique — un ensemble d'agents spécialisés qui opèrent sur le graphe de mémoire, coordonnés par un orchestrateur central. Chaque agent dispose d'un périmètre de responsabilité bien défini, de permissions délimitées et d'un mode opératoire spécifique (actif ou réactif, programmé ou event-driven).
Concierge — le point d'entrée
Le Concierge est l'agent d'intake — le point de contact entre le monde externe et le système. Tout message inbound passe par le Concierge : WhatsApp du client, email, demande du banker. Le Concierge identifie l'intention, classe l'urgence, résout ce qu'il peut résoudre dans ses permissions et transmet aux agents spécialisés ce qui requiert un traitement complémentaire.
Oghma — l'orchestrateur
Oghma est l'orchestrateur central — l'agent qui reçoit les tâches complexes et les décompose en sous-tâches distribuées entre les agents spécialisés. Lorsqu'une réunion est programmée, Oghma ne génère pas le briefing seul — il instruit l'agent portfolio de mettre à jour les positions, l'agent suitability de vérifier le profil, l'agent news de filtrer les événements pertinents, l'agent compliance de vérifier les points en suspens. Il reçoit les résultats et synthétise le briefing final.
Oghma maintient l'état de chaque tâche en cours, gère les dépendances entre sous-tâches, et garantit que les défaillances d'agents individuels ne bloquent pas le résultat final. Il est LLM-agnostique — peut orchestrer des agents qui tournent sur Anthropic Claude, OpenAI GPT, des modèles open-source, ou une combinaison.
Agents spécialisés
- Investments Agent — accède aux positions du graphe, calcule l'exposition, identifie la concentration, compare avec le benchmark et la politique d'investissement du client. Génère une analyse de portefeuille structurée, non un récit générique.
- Suitability Agent — vérifie qu'une communication proposée, une allocation suggérée ou une offre est dans le profil suitability classé pour ce client précis. Signale les divergences avant qu'elles n'arrivent au banker.
- Compliance Agent — applique les règles configurées par les compliance officers de l'institution à toutes les communications sortantes. Vérifie restrictions réglementaires et politiques internes. Génère l'audit trail de chaque décision.
- Briefing Agent — synthétise tous les inputs des autres agents dans un document structuré, lisible en moins de 60 secondes, au format que le banker reconnaît et utilise.
- News Agent — traite les flux d'actualités et filtre par pertinence pour le portefeuille de chaque client. N'envoie pas ce qui est « actualité importante » — envoie ce qui est important pour ce client, sur la base des actifs qu'il détient.
- WhatsApp Analyst — traite les messages inbound WhatsApp : transcrit les audios, identifie l'intention, extrait les engagements pris, met à jour le graphe avec le contenu de l'interaction, propose une réponse pour révision du banker.
« Chaque agent dispose de permissions délimitées. Aucun agent ne prend de décisions hors de son périmètre. Le banker demeure sur la ligne d'approbation pour toutes les actions ayant des conséquences externes. »
Le Flux — un exemple réel
La théorie est nécessaire mais insuffisante. Parcourons un exemple concret : un message WhatsApp qui arrive à 14h23. Le client est M. Monteiro, patriarche d'une famille avec patrimoine sous gestion dans une banque disposant d'une division private banking. Le message dit : « Je dois parler de ce qui se passe avec le fonds. Je suis préoccupé. »
14h23:01 — Message reçu
Le message entre par le canal d'intégration de l'API WhatsApp Business. Le Concierge le reçoit, identifie l'expéditeur comme M. Monteiro (via le numéro mappé dans le graphe), classe l'intention comme « préoccupation sur la performance — exige briefing urgent » et active Oghma en priorité haute.
14h23:04 — Oghma décompose la tâche
Oghma lit le contexte de M. Monteiro dans le graphe : profil suitability modéré-conservateur, 42 % du portefeuille en fonds multi-stratégie, la dernière interaction enregistrée date d'il y a 12 jours. Il décompose en sous-tâches parallèles : (1) Investments Agent : performance des fonds du portefeuille sur les 30 derniers jours ; (2) News Agent : événements de marché pertinents pour le portefeuille de M. Monteiro ; (3) WhatsApp Analyst : historique d'interactions antérieures sur le thème de la performance.
14h23:08 — Agents en parallèle
L'Investments Agent extrait les positions du graphe et calcule : le fonds de référence du portefeuille de M. Monteiro a baissé de 3,2 % sur le mois, contre un benchmark à −1,8 %. Le News Agent identifie deux articles pertinents publiés dans les 48 dernières heures sur le secteur d'exposition du fonds. Le WhatsApp Analyst trouve dans l'historique qu'en mars M. Monteiro a exprimé un inconfort face à une volatilité supérieure à 2 % mensuels et que le banker actuel s'est engagé à l'appeler si le fonds dépassait ce niveau.
14h23:19 — Synthèse et proposition de réponse
Oghma reçoit les résultats des 3 agents, active le Suitability Agent pour confirmer qu'une réponse de type « contexte + suggestion d'appel » est dans le périmètre, et le Compliance Agent pour vérifier qu'aucune information dans la réponse proposée ne viole les politiques de communication. Avec l'approbation des deux, le Briefing Agent synthétise un message de réponse pour M. Monteiro et un mémo interne pour le banker responsable.
14h23:41 — Le banker reçoit le paquet
Le banker reçoit dans son panneau : (1) le contexte complet de M. Monteiro, mis à jour avec le message du jour ; (2) l'analyse de performance du fonds avec contexte de marché ; (3) l'engagement de mars qui n'a pas été honoré — le banker aurait dû appeler quand la volatilité a dépassé 2 % ; (4) brouillon de réponse WhatsApp, en attente d'approbation ; (5) suggestion de programmer un appel dans les 30 prochaines minutes.
Le banker approuve le message d'un clic, ajuste deux termes, et la réponse est envoyée. L'interaction est enregistrée dans le graphe. L'engagement de mars est mis à jour comme « en suspens — résolu par appel programmé ». Tout cela entre 14h23 et 14h24.
Sécurité, isolement et déploiement — pour l'acheteur technique
Les questions que tout CIO et CTO de banque ou de société de gestion pose à ce stade sont prévisibles — et légitimes. Nous y répondons directement :
Isolement multi-tenant
Chaque tenant (chaque banque, chaque entité, chaque segment) opère avec un graphe complètement isolé. Pas de partage de données entre tenants. Une banque avec private banking et asset management dans la même institution peut configurer des tenants distincts avec des politiques de compliance distinctes, sans croisement de données entre les entités.
Déploiement on-premise
La plateforme tourne sur le VPS ou le data center de l'institution. Coolify, Kubernetes ou VM traditionnelle — le choix appartient à l'institution. Les données des clients ne sortent jamais vers des serveurs tiers. Le LLM utilisé par les agents peut être self-hosted (modèles open-source) ou via API avec contrats enterprise garantissant que les données ne sont pas utilisées pour l'entraînement. L'institution choisit — et conserve une auditabilité totale sur l'emplacement des données.
Audit trail
Toute action d'agent est enregistrée : quel agent a exécuté, avec quels inputs, avec quel output, à quel timestamp, avec quel résultat. Pour les besoins réglementaires et la supervision interne de compliance, l'audit trail est complet et immuable. Les décisions d'agents qui génèrent des communications avec les clients sont enregistrées avec le contexte complet ayant conduit à cette décision.
LLM-agnostique
Aucun agent n'est couplé à un fournisseur spécifique de modèle de langage. L'institution peut utiliser Anthropic Claude pour l'orchestrateur et un modèle open-source self-hosted pour l'agent compliance — ou toute autre combinaison. C'est particulièrement pertinent pour les institutions ayant des restrictions réglementaires sur l'usage de fournisseurs cloud spécifiques ou disposant d'une feuille de route de souveraineté des données à moyen terme.
« Ce n'est pas de la magie. C'est de l'architecture. Et l'architecture tourne sur votre VPS, avec vos données, sous vos politiques. »
Pour l'institution qui évalue une plateforme agentique, la conversation technique commence ici — non au pitch.
Nous tenons des sessions d'évaluation technique avec les CIO, CTO et équipes d'architecture — avec accès au diagramme complet de composants, à la cartographie des intégrations avec les systèmes existants et à l'analyse d'adéquation avec l'infrastructure de l'institution. Modèle commercial sur demande.
Demander une session technique