Contexte
En fondant une société de market making, nous avons dû construire l'ensemble de la plateforme à partir de zéro : moteur de trading, algorithmes, infrastructure d'exécution et supervision. En tant que co-fondateur et CTO, j'ai conçu et écrit l'ensemble du système, aujourd'hui utilisé en production pour plus de trente clients.
La plateforme regroupe plusieurs briques techniques et opérationnelles. Le schéma ci-dessous présente l'ensemble du système et les équipes qui l'exploitent ; cette étude de cas se concentre sur Warren, le copilote IA que l'équipe utilise pour tout interroger (la brique Agent IA surlignée ci-dessous). Le moteur central et l'observabilité ont leurs propres études de cas.
Le problème
La plateforme est complexe : nombreux services, configuration spécifique à chaque client, base de métriques en croissance continue. Obtenir une réponse fiable demandait souvent du temps et dépendait fortement de la personne sollicitée.
- Répondre à une question opérationnelle pouvait nécessiter de consulter le code, les configurations et les tableaux de bord.
- La plupart de l'équipe n'est pas technique : traders, équipes client et business development ont besoin d'informations mais ne savent ni lire le code ni écrire des requêtes en base.
- Seul développeur, je devenais un goulot d'étranglement, régulièrement sollicité pour extraire des données ou expliquer le comportement d'un service.
- La connaissance était dispersée entre la base de code, les configurations et les métriques, sans endroit unique où demander.
Objectifs
- Permettre à toute l'équipe d'accéder de manière autonome à la connaissance de la plateforme, en langage naturel.
- Couvrir trois sources de connaissance à la fois : le code, les configurations et les métriques en direct.
- Me décharger des questions routinières.
- Garantir la sécurité dès la conception : l'assistant doit informer, sans jamais agir sur le système.
Mon approche
J'ai construit Warren, un agent LLM (sur OpenClaw) branché à notre Slack. L'équipe lui parle simplement dans un canal ou en message direct. Warren dispose d'un accès strictement en lecture seule à trois sources : la base de code, les configurations des services et la base de séries temporelles. Il utilise des outils dédiés pour rechercher, lire, interroger et calculer à partir de ces données. Aucun mécanisme ne lui permet de modifier le système.
La solution technique
Warren est bâti sur OpenClaw, selon une architecture agentique classique : le modèle planifie, appelle des outils, lit leurs résultats, puis construit sa réponse. Les outils sont les trois sources de connaissance, exposées strictement en lecture :
- Code : il peut rechercher et lire la base de code de chaque service, pour expliquer les algorithmes et les implémentations.
- Configurations : il peut lire la configuration de chaque service en cours, pour expliquer le comportement réel d'un client, d'un service ou d'une stratégie.
- Métriques : il peut interroger la base de séries temporelles et effectuer des calculs à partir des résultats, pour répondre à des questions quantitatives et produire des rapports.
Warren est intégré directement à l'environnement de travail de l'équipe : un bot Slack que chacun peut mentionner dans un canal ou en message direct. Le modèle d'accès est délibérément à sens unique. Les identifiants de Warren sont restreints à la lecture seule : il peut chercher dans le code, lire les configs et interroger les métriques, mais il ne peut pas changer une configuration, modifier du code, ni passer un ordre. L'assistant informe ; il n'agit jamais. Cette frontière d'accès permet de l'ouvrir à toute l'entreprise, et pas seulement au développeur, sans créer de risque opérationnel direct.
Ce que l'équipe en fait
Traders, gestion client, business development et opérations utilisent tous Warren, chacun pour ses propres questions.
Récupérer et calculer rapidement
L'équipe peut demander des indicateurs en langage naturel, par exemple l'inventaire ou le PnL réalisé d'un client sur les sept derniers jours.
Comprendre le système
L'équipe peut comprendre le fonctionnement d'un algorithme, le comportement d'une stratégie ou le rôle d'un module précis, sans devoir consulter directement le code source.
Expliquer une configuration
Demandez ce qu'un client ou un service donné est configuré pour faire ; Warren lit la configuration active et l'explique en langage naturel.
Analyser les métriques
Les utilisateurs peuvent analyser les données pour comprendre un mouvement, par exemple l'élargissement d'un spread sur une plateforme pendant la nuit.
Générer des rapports
Produire des synthèses récurrentes, comme un récap de performance hebdomadaire ou un rapport par client, à la demande.
Self-service pour les non-ingénieurs
La gestion client et le business development obtiennent eux-mêmes les données et réponses dont ils ont besoin, sans dépendre de ma disponibilité.
Résultats
- Toute l'équipe du desk, y compris les profils non techniques, obtient des réponses directement dans Slack, en langage naturel.
- Je suis beaucoup moins sollicité pour des extractions de données ou des explications récurrentes sur le fonctionnement des services.
- Les équipes client et business development accèdent aux données dont elles ont besoin sans écrire de SQL ni consulter le code.
- Sûr par construction : l'accès en lecture seule permet à Warren d'informer sans jamais modifier le système ni déclencher d'action opérationnelle.
Ce que j'en retiens
En connectant un agent LLM en lecture seule au code, aux configurations et aux métriques, Warren a rendu une plateforme complexe interrogeable en langage naturel par toute l'équipe, sans compromettre la sécurité opérationnelle. Le modèle d'accès à sens unique est ce qui a rendu possible de l'ouvrir à toute l'entreprise.