## 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.