Files
SecondBrain/20 Work/Ideas/Mogador/Untitled.md
T

258 lines
5.5 KiB
Markdown

## Résumé
L'architecture actuelle de synchronisation Louise / Mogador remplit son rôle, mais elle est devenue difficile à faire évoluer et coûteuse à maintenir.
Au fil des années, plusieurs responsabilités se sont accumulées dans la même chaîne :
- synchronisation des données;
- publication web;
- intégration Directus;
- gestion des vidéos;
- corrections d'urgence;
- consommation par les sites;
- accès fournisseurs.
Le résultat est un système qui fonctionne, mais dont la complexité augmente à chaque évolution.
Cette proposition ne vise pas à remplacer l'existant dans un « big bang », mais à définir une architecture cible plus simple, plus observable et plus facile à maintenir.
La recommandation est de construire progressivement un moteur interne de publication (« Content Publication Engine ») qui produirait des données prêtes à consommer pour les sites, tout en conservant Louise comme source officielle.
---
# Pourquoi maintenant ?
Les problèmes rencontrés récemment ne proviennent pas uniquement de bogues.
Ils mettent surtout en évidence certaines limites structurelles de notre architecture actuelle :
- plusieurs copies de la même logique sur différents serveurs;
- forte dépendance à Directus comme moteur de publication;
- difficulté à diagnostiquer rapidement les incidents;
- peu d'observabilité proactive;
- logique métier répartie dans plusieurs systèmes;
- complexité croissante lorsqu'un nouveau besoin apparaît.
Cette situation augmente progressivement le coût de maintenance et rend les évolutions plus risquées.
---
# Ce que cette proposition n'est pas
Cette proposition **n'est pas** :
- une remise en question de Louise;
- une remise en question du travail de PCI;
- un remplacement immédiat de Directus;
- un nouveau CMS;
- un projet de refonte des sites.
L'objectif est uniquement de simplifier notre chaîne interne de publication.
---
# Vision proposée
À terme, l'application interne deviendrait responsable de produire des publications versionnées prêtes à être consommées par les sites.
Le principe général serait :
```text
Louise
Export officiel
Import interne
Content Publication Engine
Publication JSON versionnée
Bucket / CDN
Sites web
```
Les sites ne dépendraient plus directement de la structure interne de Directus.
---
# Principes recherchés
L'architecture proposée repose sur quelques principes simples.
## Séparer les responsabilités
Chaque composant devrait avoir une responsabilité claire.
Par exemple :
- lecture des données officielles;
- gestion des médias;
- publication;
- corrections d'urgence;
- rapports;
- alertes.
Aujourd'hui, plusieurs de ces responsabilités sont mélangées.
---
## Publier uniquement des données validées
Une publication ne devrait jamais remplacer une version fonctionnelle tant que toutes les validations ne sont pas terminées.
Cela permet notamment :
- les rollbacks;
- les validations automatiques;
- la réduction du risque de publication incomplète.
---
## Améliorer l'observabilité
L'objectif est de pouvoir répondre rapidement à des questions comme :
- Qu'est-ce qui a changé ?
- Qu'est-ce qui a été publié ?
- Pourquoi un contenu est absent ?
- Quelle étape a échoué ?
- Quels éléments nécessitent une intervention ?
---
# Bénéfices attendus
À moyen terme, cette approche permettrait notamment :
- réduire la complexité de la synchronisation;
- diminuer la dépendance à Directus comme moteur de publication;
- faciliter les diagnostics;
- accélérer les corrections d'urgence;
- produire des rapports de publication fiables;
- simplifier le travail des fournisseurs web;
- préparer une éventuelle évolution future de Louise/Mogador sans devoir revoir toute notre architecture.
---
# Approche proposée
Aucun remplacement immédiat.
L'idée est plutôt de construire progressivement la nouvelle architecture en parallèle de l'existant.
Une approche possible serait :
### Phase 1
Ajouter davantage d'observabilité.
Aucun changement fonctionnel.
---
### Phase 2
Produire les premiers JSON en parallèle de Directus.
Comparer les résultats.
---
### Phase 3
Faire un projet pilote sur une plateforme.
Valider la performance et le fonctionnement.
---
### Phase 4
Migrer progressivement les consommateurs lorsque l'approche est validée.
---
# Collaboration avec PCI
Cette proposition est volontairement indépendante d'une éventuelle évolution de Louise/Mogador.
Deux chantiers peuvent avancer en parallèle :
**Interne**
- amélioration de notre publication;
- observabilité;
- rapports;
- architecture.
**PCI**
- discussion autour d'une API plus moderne;
- endpoints bulk;
- pagination;
- éventuels événements/webhooks.
Ainsi, notre évolution ne dépend pas d'une refonte préalable chez PCI.
---
# Décision recherchée
À ce stade, aucune décision d'implantation n'est demandée.
La décision recherchée est uniquement la suivante :
> Est-ce que cette orientation architecturale vous semble pertinente et suffisamment porteuse pour mériter une étude plus approfondie et un projet pilote ?
Si oui, la prochaine étape serait de préparer un prototype limité ainsi qu'une estimation plus détaillée de l'effort, des risques et des bénéfices.