Architecture

Vue d’ensemble du pipeline#

Stream-Ingest → Validateurs de features → Persistance
                                            ↓
                                       Bus d'événements (PG LISTEN/NOTIFY)
                                            ↓
                              ┌────────────────────┐
                              │ Daemon de décision │ (config par tenant)
                              └─────────┬──────────┘
                                        ↓
                                  Action validée
                                        ↓
                                  Feedback résultat
                                        ↓
                              Entraînement / Tuning du modèle

La plateforme convertit les flux de données bruts en décisions convergentes via un pipeline délibérément étagé. Chaque étape a une responsabilité unique et émet des événements durables pour la suivante.

Cœur événementiel#

• Bus d’événements. PostgreSQL LISTEN/NOTIFY transporte les événements entre daemons. Les événements sont persistés en table durable, pas seulement diffusés — les consommateurs peuvent rejouer depuis un curseur après une reconnexion.
• Livraison at-least-once. Les consommateurs accusent réception des événements traités. Les événements non acquittés sont relivrés après timeout. L’idempotence est la responsabilité du consommateur.
• Replay tracé par curseur. Chaque consommateur maintient son propre curseur. Après une déconnexion, il reprend là où il s’est arrêté — aucun événement perdu, aucun doublement au-delà des sémantiques de retry configurées.

Pipeline ML#

• Modèles. XGBoost entraîné sur les features historiques, avec ONNX Runtime pour l’inférence (2–5× plus rapide que le framework d’entraînement).
• Sorties. Les modèles classifient les régimes selon trois dimensions — direction, volatilité, qualité. Pas de prévision ponctuelle spéculative.
• Tuning des hyperparamètres. Optuna avec walk-forward holdout, vagues champion/challenger, quality gates.
• Boucle de feedback. Le résultat de chaque décision est enregistré et réinjecté dans le tour de tuning suivant.

Modèle multi-tenant#

L’isolation des tenants est appliquée à deux niveaux :

• Stored procedures. Toutes les opérations côté tenant passent par des stored procedures qui imposent la propriété. Les écritures directes en table par du code tenant ne sont pas permises.
• Row-level security. Le RLS Postgres comme garde-fou. Même si la logique applicative a un bug, le RLS empêche tout accès inter-tenant aux données.

La configuration par tenant couvre :

• Clés et limites de débit.
• Kill-switch. Override opérateur pour désactiver un tenant immédiatement sans redéploiement.
• Profil de risque. Paramètres de seuil par classe de décision.

Validateurs#

Trois endroits où la validation se produit :

1. Avant persistance. Les événements stream qui échouent à la validation sont marqués, pas droppés silencieusement. Les opérateurs les voient dans le dashboard.
2. Avant entraînement du modèle. Les features utilisées pour l’entraînement sont re-validées contre le schéma. Une dérive déclenche une alerte avant que les modèles ne soient ré-entraînés.
3. À l’exécution. Les validateurs de features tournent en continu avec auto-récupération DATAMISSING — quand une feature attendue est absente, le daemon retombe sur un défaut documenté et émet un événement structuré.

Observabilité#

• 21 tableaux de bord live. Heartbeat, latence, détection de dérive, distribution des décisions, volume par tenant.
• Logging structuré. Console, fichier et base de données — mêmes événements de log lisibles depuis les trois avec la même requête.
• Monitoring de santé. Chaque daemon émet des événements de santé à cadence fixe. Les événements manquants déclenchent un page.

Mécanismes prêts pour la production#

• Circuit breakers par source de données — les pannes dégradent gracieusement plutôt que de cascader.
• Alerting email et XMPP pour les événements visibles à l’opérateur.
• Valeurs par défaut universelles pilotées par config. Mappings de sources, chaînes de fallback, conversions d’unités, seuils — tout en JSON. Pas de magic number dans le code.
• Isolation de processus via tmux + Devuan — les daemons peuvent être redémarrés individuellement sans coordination.

Ce que ce n’est pas#

• Pas une plateforme d’autoscaling style Kubernetes. Ceci tourne sur un petit nombre de machines bien comprises avec placement délibéré des daemons.
• Pas “installer et oublier”. Les jeux de tokens, versions de modèles, configs de tenants et tableaux de bord requièrent attention opérateur.
• Pas générique. La plateforme reflète une classe spécifique de problèmes de décision haute fréquence — l’adapter à une charge très différente est le service Développement.