5.5 KiB
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 :
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.