# ArchitecturePlateforme de décision événementielle, multi-tenant, augmentée par ML — comment elle est structurée.

## 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](/fr/services/development/).