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