2.1 KiB
2.1 KiB
date, status, owner
| date | status | owner |
|---|---|---|
| 2026-08-13 | proposed | Amadou |
🟡 Proposed · 🟢 Decided · 🔴 Rejected · ⚫ Superseded
Context
L'architecture actuelle Louise/Mogador fonctionne, mais devient de plus en plus complexe à maintenir et à faire évoluer.
La synchronisation repose aujourd'hui sur plusieurs serveurs, Directus porte plusieurs responsabilités et le système offre peu d'observabilité proactive.
Une nouvelle approche permettrait de simplifier progressivement la chaîne de publication sans remplacer l'existant en une seule étape.
Options Considered (optional)
- Option 1 : Continuer à faire évoluer l'architecture actuelle
- Pros : moins de changement à court terme
- Cons : conserve la complexité et les limitations actuelles
- Option 2 : Construire progressivement un Content Publication Engine interne
- Pros : meilleure séparation des responsabilités, observabilité, publication atomique et architecture plus facile à faire évoluer
- Cons : effort de développement et migration progressive des consommateurs
Decision
Proposer la construction progressive d'un Content Publication Engine interne, en parallèle de l'architecture actuelle, avec un premier pilote avant toute migration complète.
La décision finale reste à valider avec le Team Lead et le CTO.
Why
- Réduire la complexité de l'architecture actuelle
- Améliorer l'observabilité et le diagnostic des problèmes
- Découpler progressivement les sites de Directus
- Permettre des publications validées et des rollbacks
- Préparer l'architecture pour une future évolution de Louise/Mogador
- Éviter une migration « big bang »
Consequences
- Directus reste en place pendant la transition
- L'approche doit être validée avec le Team Lead et le CTO avant de devenir un projet
- Habiba doit être impliquée dans la définition des validations et de la data lineage
- Les fournisseurs seront consultés sur la viabilité du modèle de publication JSON avant de figer le contrat
Related
Proposition d'architecture Sync Mogador v2