diff --git a/20 Work/Ideas/Mogador/Untitled.md b/20 Work/Ideas/Mogador/Untitled.md
new file mode 100644
index 0000000..faf2cc8
--- /dev/null
+++ b/20 Work/Ideas/Mogador/Untitled.md	
@@ -0,0 +1,258 @@
+
+
+## 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.
\ No newline at end of file