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