184 lines
11 KiB
Markdown
184 lines
11 KiB
Markdown
|
|
|
|
## 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| |