## Responsable

A confirmer.

Responsables pressentis:

- Sponsor: Amadou Ndiaye
- Responsable produit/metier: Julie Bessière
- Responsable execution: Joel Ymele
- Equipe contributrice: SN, infra, edimestres, PCI, fournisseurs sites

## Resultat attendu

Quand ce projet reussit, la publication des donnees issues de Louise/Mogador vers les sites TFO, IDELLO, ONFR et lineaire devient plus fiable, plus observable et plus rapide.

Concretement:

- on ne depend plus de trois serveurs separes qui executent chacun une copie de la meme synchro;
- les sites consomment des fichiers JSON publics, versionnes et atomiques;
- les erreurs sont detectees avant les plaintes de production;
- les corrections d'urgence sont possibles via une interface interne controlee;
- l'etat des videos JWP est integre proprement sans demander a PCI de connaitre JWP;
- Directus peut etre retire ou reduit si son role n'est plus necessaire;
- l'architecture reste compatible avec une future API Louise/Mogador v2 fournie par PCI.

## Valeur d'affaires

Le systeme actuel fonctionne, mais il est fragile, lent a operer et difficile a expliquer. Il cree un risque direct sur la mise en ligne des emissions, particulierement quand une programmation doit apparaitre a une heure precise.

Ce projet vise a reduire:

- les incidents de publication;
- les retards de mise en ligne;
- les interventions manuelles non tracees;
- la dependance operationnelle a Directus pour des usages qu'il ne sert pas bien;
- la complexite des relations collection/saison/episode;
- la duplication entre TFO, IDELLO, ONFR et lineaire;
- la dependance a une API Mogador legacy lente ou limitee.

La valeur principale est operationnelle: publier de facon previsible, auditable et recuperable.

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

## Definition de termine

- [ ]  Le `Content Publication Engine` genere les JSON publics pour au moins une plateforme pilote.
- [ ]  Les JSON sont publies en runs immuables avec un `manifest.json` actif.
- [ ]  Le systeme supporte les produits, collections, programmations, `today`, `latest`, recherche/index et programmations futures jusqu'a J+10.
- [ ]  Le `Media Pipeline` alimente une table `media_assets` avec l'etat 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, roles et audit.
- [ ]  Un rapport compare ce qui est attendu selon Louise/Mogador et ce qui a ete publie.
- [ ]  Des alertes sont envoyees en cas d'anomalie critique.
- [ ]  Un rollback peut etre fait en repointant le `manifest.json` vers un run precedent.
- [ ]  Une documentation existe pour les JSON, les schemas, les operations, les alertes et le rollback.
- [ ]  Un pilote est valide avec production, edition, infra et au moins un fournisseur/site consommateur.

## Portee

### Inclus

- Analyse et formalisation des regles de publication actuelles.
- Creation du `Content Publication Engine`.
- Generation des JSON publics versionnes.
- Gestion des runs et retention.
- Generation du `manifest.json`.
- Support des programmations futures jusqu'a 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 roles pour edimestres/admins internes.
- Rapports de validation attendu vs publie.
- Alertes operationnelles.
- Documentation technique et operationnelle.
- Pilote sur une plateforme.
- Strategie de migration progressive depuis Directus.

### Exclu

- Refonte complete 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 validee|A definir|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/edition/infra|Semaines 10-11|A faire|
|Decision de generalisation|Semaine 12|A faire|

## Dependances

|Dependance|Responsable|Requis pour|Statut|
|---|---|---|---|
|Acces export Louise/Mogador actuel|Interne / Infra|Snapshot source|Existant|
|Mogador Toolkit actuel|Interne / PCI|Lecture officielle initiale|Existant, fragile|
|App AdonisJS/JWP|Tech lead / equipe web|Etat media JWP|A integrer|
|Acces JWP|Equipe web / Infra|Media Pipeline|A confirmer|
|Bucket/CDN|Infra|Publication JSON|A definir|
|Auth interne|Infra / equipe web|Publication Console|A definir|
|Better Stack / alerting|Infra / equipe web|Alertes|En cours / a confirmer|
|Validation production|Production|Definition des anomalies critiques|A planifier|
|Validation edimestres|Edition numerique|Corrections d'urgence|A planifier|
|Decision sur Directus|CTO / equipe 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 meme temps|Elevee|Eleve|Decouper en pilote, garder API PCI comme chantier separe, livrer par increments|Sponsor / Tech lead|
|L'equipe manque de disponibilite pour un projet d'architecture|Elevee|Eleve|Limiter le MVP, choisir une plateforme pilote, documenter les arbitrages|Manager / Tech lead|
|Les regles metier actuelles sont implicites dans le vieux code|Elevee|Eleve|Extraire les regles, valider avec production, ajouter rapports de comparaison|Equipe 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 recree 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|Elevee|Eleve|Definir precedence, expiration d'override, audit et rapport d'ecart|Equipe web / edition|
|Le `manifest.json` est cache trop longtemps|Moyenne|Eleve|TTL court sur manifest, runs immuables caches longuement, procedure de purge CDN|Infra / equipe web|
|La publication atomique est mal implementee|Moyenne|Eleve|Publier d'abord un run complet, valider, puis seulement changer le manifest|Equipe web|
|La gestion des programmations futures J+10 augmente le volume et la complexite|Moyenne|Moyen|Limiter explicitement a J+10, mesurer performance, eviter requetes par episode|Equipe web|
|Le Media Pipeline et le Sync Engine se couplent trop fortement|Moyenne|Eleve|Passer uniquement par `media_assets` et `publication_jobs`, eviter 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|Equipe web|
|Le systeme publie un JSON incomplet mais valide techniquement|Moyenne|Eleve|Ajouter validations metier, rapports attendu vs publie et seuils bloquants|Equipe web / production|
|L'absence d'API PCI v2 maintient certaines lenteurs|Elevee|Moyen|Concevoir le `Source Reader` remplacable et optimiser avec snapshots/diffs internes|Equipe web|
|PCI ne livre pas d'events/webhooks a court terme|Elevee|Moyen|Ne pas en faire une dependance 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 reseau interne|Infra|
|Les permissions edimestres sont sous-estimees|Moyenne|Moyen|Definir roles simples, audit obligatoire, environnement interne seulement|Edition / equipe web|
|Migration depuis Directus cause une interruption|Moyenne|Eleve|Double-run, comparaison, pilote, rollback, aucun big bang|Tech lead / Infra|
|Les couts operationnels du bucket/CDN/logs augmentent|Faible|Moyen|Retention limitee, monitoring taille, lifecycle policies|Infra|
|Le choix Laravel vs AdonisJS devient un debat bloquant|Moyenne|Moyen|Decider selon maintenabilite, separer contrat et implementation, timeboxer la decision|CTO / Tech lead|

## Sante actuelle

Jaune.

Le besoin est clair et la direction technique est raisonnable, mais le projet touche plusieurs systemes critiques: Louise/Mogador, Directus, JWP, sites consommateurs, infra, edition et production. Le principal risque n'est pas technique pur; c'est la portee.

## Statut actuel

Une proposition d'architecture Sync v2 existe. Une suite precise maintenant la separation entre:

- le chantier interne de publication;
- le chantier PCI pour moderniser Louise/Mogador;
- le role 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 retire, reduit ou garde temporairement en double-run.
- Confirmer que les JSON publics via bucket/CDN sont acceptables pour Infra.
- Confirmer les roles de la Publication Console: edimestres, admins, read-only.
- Valider la strategie 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 portee

|Date|Changement|Impact|Decision|
|---|---|---|---|
|A definir|Ajout de l'integration JWP via Media Pipeline|Augmente la portee, mais evite une architecture incomplete|Propose|
|A definir|Separation du chantier PCI et du chantier interne|Reduit le risque de blocage fournisseur|Propose|
|A definir|Ajout Publication Console pour corrections d'urgence|Ajoute auth/audit, mais remplace un besoin fort de Directus|Propose|
|A definir|Support des programmations futures J+10|Augmente le volume JSON, mais repond a une demande recurrente|Propose|