SecondBrain/20 Work/Ideas/Mogador/Charte de projet - Content Publication Engine.md

Responsable

A confirmer.

Responsables pressentis:

• Sponsor: CTO / Direction technique
• Responsable produit/métier: Direction production / édition numerique
• Responsable execution: Manager équipe web / Tech lead
• Équipe contributrice: developpeurs web, infra, édimestres, PCI, fournisseurs sites

Resultat attendu

Quand ce projet réussit, la publication des données issues de Louise/Mogador vers les sites TFO, IDELLO, ONFR et linéaire devient plus fiable, plus observable et plus rapide.

Concretement:

• on ne depend plus de trois serveurs séparés qui executent chacun une copie de la même synchro;
• les sites consomment des fichiers JSON publics, versionnés et atomiques;
• les erreurs sont détectées avant les plaintes de production;
• les corrections d'urgence sont possibles via une interface interne contrôlee;
• l'état des vidéos JWP est intégré proprement sans demander à PCI de connaitre JWP;
• Directus peut être retiré ou reduit si son rôle n'est plus nécessaire;
• l'architecture reste compatible avec une future API Louise/Mogador v2 fournie par PCI.

Valeur d'affaires

Le système actuel fonctionne, mais il est fragile, lent a operer et difficile a expliquer. Il crée un risque direct sur la mise en ligne des emissions, particulierement quand une programmation doit apparaitre a une heure précise.

Ce projet vise a réduire:

• les incidents de publication;
• les retards de mise en ligne;
• les interventions manuelles non tracees;
• la dépendance opérationnelle à Directus pour des usages qu'il ne sert pas bien;
• la complexite des relations collection/saison/épisode;
• la duplication entre TFO, IDELLO, ONFR et linéaire;
• la dépendance à une API Mogador legacy lente ou limitée.

La valeur principale est opérationnelle: publier de façon previsible, auditable et reçuperable.

La valeur secondaire est strategique: preparer une transition future vers une API Louise/Mogador v2 ou des événements PCI sans devoir recommencer l'architecture.

Definition de termine

• Le Content Publication Engine génère les JSON publics pour au moins une plateforme pilote.
• Les JSON sont publiés en runs immuables avec un manifest.json actif.
• Le système supporte les produits, collections, programmations, today, latest, recherche/index et programmations futures jusqu'à J+10.
• Le Media Pipeline alimente une table media_assets avec l'état JWP.
• Le contrat publication_jobs permet de republier un produit, une collection, un horaire ou une plateforme.
• Les corrections d'urgence passent par une Publication Console interne avec authentification, rôles et audit.
• Un rapport compare ce qui est attendu selon Louise/Mogador et ce qui a été publié.
• Des alertes sont envoyees en cas d'anomalie critique.
• Un rollback peut être fait en repointant le manifest.json vers un run précédent.
• Une documentation existe pour les JSON, les schemas, les opérations, les alertes et le rollback.
• Un pilote est valide avec production, édition, infra et au moins un fournisseur/site consommateur.

Portee

Inclus

• Analyse et formalisation des règles de publication actuelles.
• Creation du Content Publication Engine.
• Generation des JSON publics versionnés.
• Gestion des runs et retention.
• Generation du manifest.json.
• Support des programmations futures jusqu'à J+10.
• Creation du contrat media_assets.
• Creation du contrat publication_jobs.
• Integration avec le Media Pipeline AdonisJS/JWP.
• Mini CMS interne, ou Publication Console, pour les corrections d'urgence.
• Authentification et rôles pour édimestres/admins internes.
• Rapports de validation attendu vs publie.
• Alertes opérationnelles.
• Documentation technique et opérationnelle.
• Pilote sur une plateforme.
• Strategie de migration progressive depuis Directus.

Exclu

• Refonte complète de Louise.
• Suppression immediate de Mogador Toolkit.
• Livraison d'une API Louise/Mogador v2 par PCI.
• Publication directe depuis Louise vers les sites.
• Gestion JWP par PCI.
• Remplacement complet de JWP.
• Refonte des sites web consommateurs.
• Migration big bang de toutes les plateformes sans pilote.
• Exposition publique de l'application interne si Infra ne l'autorise pas.

Jalons

Jalon	Cible	Statut
Charte validée	À définir	Brouillon
Contrats media_assets et publication_jobs valides	Semaine 1	A faire
Prototype JSON local valide	Semaines 2-3	A faire
Integration Media Pipeline minimale	Semaines 3-4	A faire
Generation pilote ONFR ou sous-ensemble TFO	Semaines 5-6	A faire
Rapports et alertes pilote	Semaines 6-7	A faire
Publication bucket/CDN de test	Semaines 7-8	A faire
Publication Console minimale	Semaines 8-10	A faire
Validation production/édition/infra	Semaines 10-11	A faire
Decision de generalisation	Semaine 12	A faire

Dependances

Dependance	Responsable	Requis pour	Statut
Accès export Louise/Mogador actuel	Interne / Infra	Snapshot source	Existant
Mogador Toolkit actuel	Interne / PCI	Lecture officielle initiale	Existant, fragile
App AdonisJS/JWP	Tech lead / équipe web	Etat media JWP	A intégrer
Accès JWP	Équipe web / Infra	Media Pipeline	A confirmer
Bucket/CDN	Infra	Publication JSON	À définir
Auth interne	Infra / équipe web	Publication Console	À définir
Better Stack / alerting	Infra / équipe web	Alertes	En cours / a confirmer
Validation production	Production	Definition des anomalies critiques	A planifier
Validation édimestres	Edition numerique	Corrections d'urgence	A planifier
Decision sur Directus	CTO / équipe web	Strategie migration	A prendre
Discussion PCI API v2	CTO / PCI	Evolution long terme	Separe

Risques

Risque	Probabilite	Impact	Reponse	Responsable
Le projet devient trop large et tente de remplacer Directus, Mogador, JWP et les sites en même temps	Élevée	Eleve	Decouper en pilote, garder API PCI comme chantier séparé, livrer par increments	Sponsor / Tech lead
L'équipe manque de disponibilite pour un projet d'architecture	Élevée	Eleve	Limiter le MVP, choisir une plateforme pilote, documenter les arbitrages	Manager / Tech lead
Les règles métier actuelles sont implicites dans le vieux code	Élevée	Eleve	Extraire les règles, valider avec production, ajoutér rapports de comparaison	Équipe web
Les sites consommateurs ont des besoins differents ou non documentes	Moyenne	Eleve	Publier JSON schemas, faire valider les formats avec chaque fournisseur/site	Manager / fournisseurs sites
La Publication Console recrée un mini Directus trop complexe	Moyenne	Eleve	Limiter aux overrides d'urgence, audit, preview et publication; ne pas refaire un CMS complet	Product / Tech lead
Les corrections d'urgence entrent en conflit avec Louise au prochain export	Élevée	Eleve	Definir precedence, expiration d'override, audit et rapport d'ecart	Équipe web / édition
Le manifest.json est cache trop longtemps	Moyenne	Eleve	TTL court sur manifest, runs immuables cachés longuement, procedure de purge CDN	Infra / équipe web
La publication atomique est mal implementee	Moyenne	Eleve	Publier d'abord un run complet, valider, puis seulement changer le manifest	Équipe web
La gestion des programmations futures J+10 augmente le volume et la complexite	Moyenne	Moyen	Limiter explicitement a J+10, mesurer performance, éviter requetes par épisode	Équipe web
Le Media Pipeline et le Sync Engine se couplent trop fortement	Moyenne	Eleve	Passer uniquement par media_assets et publication_jobs, éviter les appels directs obligatoires	Tech lead
JWP est lent ou indisponible pendant une publication	Moyenne	Eleve	Publier statut media explicite, alerter, retry, ne pas bloquer tout le run si un media est en erreur	Équipe web
Le système publie un JSON incomplet mais valide techniquement	Moyenne	Eleve	Ajouter validations métier, rapports attendu vs publie et seuils bloquants	Équipe web / production
L'absence d'API PCI v2 maintient certaines lenteurs	Élevée	Moyen	Concevoir le Source Reader remplacable et optimiser avec snapshots/diffs internes	Équipe web
PCI ne livre pas d'events/webhooks à court terme	Élevée	Moyen	Ne pas en faire une dépendance du MVP; garder le polling 3h et overrides internes	Sponsor
Infra refuse l'exposition de l'app interne	Moyenne	Moyen	Exposer seulement les JSON via bucket/CDN; garder la console sur réseau interne	Infra
Les permissions édimestres sont sous-estimees	Moyenne	Moyen	Definir rôles simples, audit obligatoire, environnement interne seulement	Edition / équipe web
Migration depuis Directus cause une interruption	Moyenne	Eleve	Double-run, comparaison, pilote, rollback, aucun big bang	Tech lead / Infra
Les couts opérationnels du bucket/CDN/logs augmentent	Faible	Moyen	Retention limitée, monitoring taille, lifecycle policies	Infra
Le choix Laravel vs AdonisJS devient un debat bloquant	Moyenne	Moyen	Decider selon maintenabilite, séparer contrat et implementation, timeboxer la décision	CTO / Tech lead

Sante actuelle

Jaune.

Le besoin est clair et la direction technique est raisonnable, mais le projet touche plusieurs systèmes critiques: Louise/Mogador, Directus, JWP, sites consommateurs, infra, édition et production. Le principal risque n'est pas technique pur; c'est la portée.

Statut actuel

Une proposition d'architecture Sync v2 existe. Une suite précise maintenant la séparation entre:

• le chantier interne de publication;
• le chantier PCI pour moderniser Louise/Mogador;
• le rôle du Media Pipeline AdonisJS/JWP;
• les contrats media_assets et publication_jobs;
• les noms recommandes pour clarifier l'architecture.

Prochain jalon recommande: valider les contrats media_assets, publication_jobs et la structure JSON v1 avec le tech lead avant de choisir definitivement Laravel, AdonisJS ou une autre stack pour le moteur interne.

Decisions / aide requise

• Choisir la plateforme pilote: ONFR, TFO reduit ou autre.
• Decider si Directus est retiré, reduit ou garde temporairement en double-run.
• Confirmer que les JSON publics via bucket/CDN sont acceptables pour Infra.
• Confirmer les rôles de la Publication Console: édimestres, admins, read-only.
• Valider la stratégie de cache du manifest.json.
• Valider la retention des runs: recommandation initiale de 10 jours minimum.
• Valider si le Sync Engine principal est Laravel, AdonisJS ou autre.
• Confirmer qui porte la discussion avec PCI pour l'API v2 et les events futurs.

Changements de portée

Date	Changement	Impact	Decision
À définir	Ajout de l'integration JWP via Media Pipeline	Augmente la portée, mais evite une architecture incomplète	Proposé
À définir	Separation du chantier PCI et du chantier interne	Reduit le risque de blocage fournisseur	Proposé
À définir	Ajout Publication Console pour corrections d'urgence	Ajoute auth/audit, mais remplace un besoin fort de Directus	Proposé
À définir	Support des programmations futures J+10	Augmente le volume JSON, mais répond à une demande reçurrente	Proposé