Architecture de Monitoring : Séparation des Concerns et Gestion du Risque

Série : Monitorer sa Stack de Trading

Introduction — L'Architecture de Monitoring

Dans la Partie 1, nous avons analysé les post-mortems les plus instructifs du trading systématique. Chaque incident partageait un point commun : le monitoring était soit absent, soit mal architecturé. Des logs existaient, des dashboards clignotaient, mais l'architecture globale ne permettait pas de détecter, comprendre et réagir à temps.

Cette deuxième partie est le cœur de la série. Nous allons construire, couche par couche, une architecture de monitoring robuste pour une stack de trading. Pas un produit spécifique, pas un outil particulier — une architecture, c'est-à-dire un ensemble de principes, de patterns et de décisions de design qui guident ensuite tous les choix techniques.

Pourquoi l'architecture compte plus que l'outil

Un piège fréquent : commencer par choisir un outil (Grafana, Datadog, Prometheus) puis essayer de faire rentrer son système dedans. C'est comme choisir la couleur de la façade avant de dessiner les plans de la maison. L'outil vient après l'architecture, jamais avant.

Une bonne architecture de monitoring repose sur trois piliers fondamentaux :

Ce que vous allez apprendre

Ce guide couvre huit domaines essentiels, chacun dédié à un aspect critique de l'architecture de monitoring :

Que vous construisiez un système institutionnel gérant des milliards ou un bot retail sur un VPS à 10$/mois, les principes sont identiques. Seule l'échelle change.

Séparation des Concerns (SoC)

La Séparation des Concerns (Separation of Concerns, SoC) est le principe fondamental de toute architecture logicielle robuste. Dans le contexte du trading, elle prend une dimension critique : quand votre monitoring tourne dans le même processus que votre stratégie, un bug de monitoring peut crasher votre stratégie. Et inversement, une stratégie qui consomme 100% du CPU ne laisse rien au monitoring pour détecter le problème.

Les trois moteurs indépendants

Une stack de trading bien architecturée se compose de trois moteurs qui doivent tourner dans des processus séparés, idéalement sur des machines distinctes :

Le flux de données — Comprendre le chemin critique

Comprendre le flux de données est essentiel pour savoir où placer vos points d'observation. Voici le chemin que suit chaque décision de trading, depuis la donnée de marché brute jusqu'à l'exécution sur l'exchange :

Les flèches pleines représentent le flux de trading (le chemin critique — celui qui doit être le plus rapide possible). Les flèches en pointillés représentent le flux de monitoring : chaque composant émet des métriques vers le Monitoring Layer, mais le Monitoring Layer n'émet jamais rien vers le flux de trading.

Anti-patterns : le monitoring dans la boucle de trading

Voici les erreurs les plus fréquentes que nous observons dans les systèmes de trading, particulièrement chez les développeurs qui débutent en architecture :

Communication inter-processus : les options

Si les trois moteurs sont des processus séparés, comment communiquent-ils ? Voici les patterns recommandés par ordre de complexité croissante :

Exemple concret : un message de monitoring

Voici à quoi ressemble un message typé émis par le Trading Engine vers le Monitoring Layer, au format JSON structuré :

{
  "timestamp": "2026-02-27T14:30:05.123Z",
  "component": "trading_engine",
  "event_type": "order_sent",
  "correlation_id": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
  "data": {
    "symbol": "AAPL",
    "side": "BUY",
    "quantity": 100,
    "order_type": "LIMIT",
    "price": 178.50,
    "strategy": "momentum_v3"
  },
  "metrics": {
    "queue_depth": 2,
    "open_positions": 5,
    "daily_pnl": 1250.00,
    "current_drawdown_pct": 0.3
  }
}

Chaque message contient un correlation_id qui permet de retracer tout le parcours de cette décision à travers le système. Le Risk Engine verra ce même ID quand il validera l'ordre. L'Execution Engine le verra quand il enverra l'ordre au broker. Et le monitoring les connecte tous pour reconstituer l'histoire complète.

Les 4 Couches du Monitoring

Le monitoring d'une stack de trading s'organise naturellement en quatre couches, de la plus basse (l'infrastructure physique) à la plus haute (le marché lui-même). Chaque couche a ses propres métriques, ses propres seuils, et ses propres responsables.

L'idée clé à retenir : un problème dans une couche basse se manifeste toujours dans les couches supérieures, mais avec un délai et une perte de contexte. Un problème réseau (Layer 1) apparait d'abord comme de la latence (Layer 2), puis comme du slippage (Layer 3), et finalement comme une perte inexplicable (Layer 4). Si vous ne monitorez que le P&L, vous détectez le problème trop tard pour agir.

La pyramide se lit de bas en haut. Plus on monte, plus les métriques sont « business » et moins elles sont « techniques ». Mais les couches basses sont les fondations — sans elles, rien au-dessus ne fonctionne.

Layer 1 — Infrastructure

La base de la pyramide. Même le meilleur algorithme ne peut rien si le serveur n'a plus de mémoire, si le réseau est saturé, ou si le disque est plein. Le monitoring d'infrastructure est le socle indispensable — souvent négligé par les traders qui pensent que seul le P&L compte.

Layer 2 — Application

La couche application vérifie que vos composants logiciels fonctionnent correctement. Même si l'infrastructure est parfaitement saine, un bug logiciel, une dépendance cassée, une API qui change de format de réponse ou un WebSocket qui se déconnecte silencieusement peut paralyser le système.

Layer 3 — Business Logic

C'est la couche qui parle la langue du trader, pas celle de l'ingénieur. P&L, drawdown, exposition, taille des positions, concentration sectorielle. C'est ici que les décisions de risque se prennent et que les limites opérationnelles sont appliquées.

Layer 4 — Marché

La couche la plus haute et la plus subtile. Ici, ce n'est pas votre système qui a un problème — c'est le marché qui a changé. Un regime shift, un flash crash, une évaporation de la liquidité, un gap overnight massif. Votre algorithme qui était profitable hier peut devenir catastrophique aujourd'hui si les conditions de marché ont fondamentalement changé.

Gestion du Risque en Temps Réel

La gestion du risque est la seule raison pour laquelle les systèmes de trading institutionnels survivent sur le long terme. Pas la qualité de l'alpha, pas la vitesse d'exécution, pas la sophistication du modèle — le risk management. Un système avec un alpha médiocre mais un excellent risk management sera profitable sur 10 ans. L'inverse ne survivra pas 6 mois.

Le risk management en trading systématique s'organise en trois phases temporelles : avant, pendant, et après le trade.

Phase 1 — Pre-Trade Checks

Avant qu'un ordre ne quitte votre système, il doit passer une série de vérifications automatiques. Ce sont des garde-fous qui empêchent les erreurs les plus coûteuses : les fat fingers, les dépassements de limites, et les ordres absurdes.

Phase 2 — Intra-Trade Monitoring

Une fois l'ordre envoyé, le monitoring ne s'arrête pas — il s'intensifie. C'est pendant l'exécution que les problèmes les plus subtils et coûteux apparaissent : slippage excessif, fills partiels, ordres zombies en attente qui bloquent la queue.

Phase 3 — Post-Trade Analysis

Après chaque trade et à la fin de chaque journée, une analyse automatique évalue la qualité de l'exécution et les performances. Ce n'est pas du monitoring temps réel — c'est de l'analyse batch qui alimente les améliorations continues du système.

Le Kill Switch — Dernier Recours

Le kill switch est le mécanisme d'arrêt d'urgence de votre système de trading. Quand tout va mal — vraiment mal — le kill switch arrête tout immédiatement. C'est l'extincteur de la finance algorithmique.

Risk Budgeting & Drawdown Limits

Le risk budgeting est l'art d'allouer un « budget de risque » à chaque stratégie, chaque instrument, et chaque période temporelle. L'idée fondamentale : vous définissez à l'avance combien vous êtes prêt à perdre par jour, par semaine, par mois. Quand le budget est épuisé, le trading s'arrête automatiquement. Pas de négociation, pas de « juste un dernier trade ».

Alerting et Escalation

Un système de monitoring sans alerting, c'est un détecteur de fumée sans sirène. L'alerting est le pont entre l'observation et l'action. Mais un alerting mal conçu est parfois pire que pas d'alerting du tout — il crée de l'alert fatigue, cette insensibilisation progressive aux alertes qui fait qu'on finit par ignorer même les vraies urgences.

Les 4 niveaux d'alerte

Matrice d'escalation

La matrice d'escalation définit qui est notifié, quand, et comment. Elle évite le bystander effect — ce phénomène où personne n'agit parce que chacun pense que quelqu'un d'autre s'en occupe.

Alert Fatigue : Le Garçon qui Criait au Loup

L'alert fatigue est le phénomène où les opérateurs deviennent insensibles aux alertes parce qu'il y en a trop, trop souvent, et trop peu pertinentes. Des études dans le domaine médical montrent que quand le taux de fausses alertes dépasse 85%, les opérateurs finissent par ignorer toutes les alertes — y compris les vraies urgences. C'est exactement le même problème en trading.

Voici les quatre techniques clés pour lutter contre l'alert fatigue :

Flux de traitement des alertes

Le diagramme Sankey ci-dessus illustre un point crucial : sur 100 événements bruts, seulement 3 devraient déclencher une alerte EMERGENCY, et environ 40% devraient être supprimés (dupliqués, déjà connus, en cooldown). Si votre ratio est très différent — trop d'alertes critiques ou trop peu de suppression — votre système d'alerting est mal calibré et génère de la fatigue.

Les 20 Métriques Essentielles

Si vous ne pouvez monitorer que 20 métriques sur votre système de trading, voici celles qui comptent le plus. Elles couvrent les quatre couches et donnent une vue complète et équilibrée de la santé de votre stack.

Exécution (5 métriques)

Risque (5 métriques)

Infrastructure (5 métriques)

Marché (5 métriques)

Patterns et Anti-Patterns

En architecture de monitoring, il existe des patterns éprouvés qui fonctionnent dans presque tous les contextes, et des anti-patterns qui mènent invariablement à des incidents. Voici les plus importants.

Bons Patterns

1. Immutable Logs (Logs Immuables)

Les logs ne doivent jamais être modifiés après écriture. Pas de rotation destructive, pas de troncature. Chaque événement est écrit une fois et conservé pour une durée définie (30-90 jours minimum). Les logs immutables sont votre boîte noire — quand l'avion s'écrase, c'est la seule chose qui permet de comprendre pourquoi.

2. Circuit Breakers

Inspiré du pattern électrique : quand un composant détecte trop d'erreurs (ex: 5 rejets consécutifs de l'API broker), il « ouvre le circuit » et arrête d'envoyer des requêtes au composant défaillant. Après un cooldown (ex: 30 secondes), il envoie une requête test (half-open state). Si elle réussit, le circuit se referme. Sinon, il reste ouvert.

3. Health Checks Composés

Chaque composant expose un endpoint /health qui retourne non seulement « healthy / unhealthy » mais un état détaillé incluant : la vérification de ses propres dépendances (DB, broker, feed) et son état business (positions, dernier trade, P&L). Cela détecte les composants « zombies » — techniquement vivants mais fonctionnellement morts.

4. Correlation IDs

Chaque décision de trading reçoit un identifiant unique (UUID) qui la suit à travers tous les composants, du signal initial à l'exécution finale. En cas de problème, il suffit de filtrer les logs par cet ID pour retracer le parcours complet d'une décision en quelques secondes.

Anti-Patterns à Éviter

Application Retail

Tout ce que nous avons couvert peut sembler écrasant pour un trader retail avec un bot sur un VPS à 10$/mois. La bonne nouvelle : les principes sont exactement les mêmes, seule l'échelle change. Voici comment adapter cette architecture à un budget et une complexité de niveau retail.

Architecture simplifiée pour le retail

L'architecture retail se résume à trois composants simples et gratuits :

Checklist du Monitoring Viable Minimum (MVM)

Voici les 12 éléments que tout trader retail doit avoir, même avec le système le plus simple possible :

De retail à semi-pro : la roadmap de maturité

Une fois le MVM en place et fonctionnel, voici les étapes pour monter en maturité progressivement :

Synthèse — Les 6 Principes Fondamentaux

Voici la synthèse des principes clés de cette Partie 2. Ces six principes s'appliquent à tout système de trading, quelle que soit l'échelle :

Série : Monitorer sa Stack de Trading