vault backup: 2026-07-31 05:32:51
This commit is contained in:
@@ -0,0 +1,478 @@
|
||||
|
||||
## Resume executif
|
||||
|
||||
Le CTO souhaite supprimer Mogador afin que les donnees sauvegardees dans Louise puissent alimenter les sites plus directement.
|
||||
|
||||
L'objectif est legitime: le flux actuel est lourd, lent et difficile a maintenir.
|
||||
|
||||
Flux actuel simplifie:
|
||||
|
||||
```text
|
||||
Louise
|
||||
-> export SQL complet toutes les 3h
|
||||
-> rsync vers serveurs internes
|
||||
-> import MySQL
|
||||
-> API Mogador
|
||||
-> Laravel Sync
|
||||
-> Directus
|
||||
-> sites web / fournisseurs
|
||||
```
|
||||
|
||||
Le probleme principal n'est pas seulement Mogador. Le vrai probleme est que le systeme depend de plusieurs couches qui ne donnent pas assez de garanties de fiabilite, d'observabilite et de publication rapide.
|
||||
|
||||
Supprimer Mogador est possible, mais il faut remplacer ce que Mogador fournit aujourd'hui:
|
||||
|
||||
- une API officielle au-dessus de l'export Louise;
|
||||
- une logique metier implicite;
|
||||
- une structure de donnees consommee par Laravel;
|
||||
- un point de controle en cas d'audit;
|
||||
- une maniere standard d'obtenir produits, programmations, series, collections, images, videos, presses et droits.
|
||||
|
||||
La recommandation est de ne pas passer directement a "Louise save -> site". C'est trop risque si le fournisseur ne garantit pas les evenements, les retries, l'audit et le replay.
|
||||
|
||||
La meilleure cible serait:
|
||||
|
||||
```text
|
||||
Louise full snapshot JSON officiel + events optionnels
|
||||
-> Sync Engine interne
|
||||
-> validation / diff / rapports
|
||||
-> JSON statiques par plateforme
|
||||
-> buckets/CDN
|
||||
-> sites web
|
||||
```
|
||||
|
||||
Il faut retirer Mogador seulement apres une periode de double-run ou les sorties Mogador et les nouvelles sorties Louise sont comparees et validees.
|
||||
|
||||
## Contexte
|
||||
|
||||
Louise est la source de verite fonctionnelle. Toutes les 3 heures, Louise produit `export_mogador.sql`, un export SQL complet qui commence par des `TRUNCATE`, puis reinsere toutes les donnees.
|
||||
|
||||
Aujourd'hui, l'equipe consomme ces donnees via l'API Mogador. Cette API parle a une base MySQL reconstruite a partir de l'export SQL.
|
||||
|
||||
Mogador est donc une couche intermediaire entre Louise et notre systeme de publication.
|
||||
|
||||
Le CTO souhaite supprimer cette couche pour accelerer la publication et simplifier le systeme.
|
||||
|
||||
## Pourquoi supprimer Mogador
|
||||
|
||||
Les raisons sont bonnes:
|
||||
|
||||
- reduire le nombre de couches;
|
||||
- publier plus vite;
|
||||
- eviter les imports SQL lourds;
|
||||
- eviter trois serveurs avec le meme code;
|
||||
- reduire les points de panne;
|
||||
- faciliter une mise a jour rapide des sites;
|
||||
- reprendre le controle de la publication.
|
||||
|
||||
Mais supprimer Mogador cree aussi des risques si aucun remplacement fiable n'est prevu.
|
||||
|
||||
## Ce que Mogador fait aujourd'hui
|
||||
|
||||
Mogador n'est pas seulement une base de donnees. Dans le flux actuel, c'est aussi:
|
||||
|
||||
- une API officielle;
|
||||
- une couche contractuelle/audit;
|
||||
- une abstraction au-dessus de la structure SQL Louise;
|
||||
- une facon stable pour Laravel de recuperer les donnees;
|
||||
- un point d'acces pour appliquer les regles metier exposees par l'API.
|
||||
|
||||
Si on retire Mogador, il faut savoir qui reprend ces responsabilites.
|
||||
|
||||
## Options possibles
|
||||
|
||||
## Option 1: Louise envoie des webhooks a chaque sauvegarde
|
||||
|
||||
Principe:
|
||||
|
||||
```text
|
||||
Louise save
|
||||
-> webhook
|
||||
-> ingestion interne
|
||||
-> validation
|
||||
-> JSON site / bucket / CDN
|
||||
```
|
||||
|
||||
### Avantages
|
||||
|
||||
- Publication beaucoup plus rapide.
|
||||
- Flux presque temps reel.
|
||||
- Plus besoin d'attendre l'export SQL toutes les 3h.
|
||||
- Moins de couches techniques.
|
||||
|
||||
### Risques
|
||||
|
||||
- Forte dependance au fournisseur Louise.
|
||||
- Risque de pertes d'evenements.
|
||||
- Risque de doublons.
|
||||
- Risque d'evenements hors ordre.
|
||||
- Risque de payload incomplet.
|
||||
- Difficile a auditer si le fournisseur ne fournit pas de journal/replay.
|
||||
- Si un webhook echoue, il faut pouvoir rejouer.
|
||||
|
||||
### Conditions minimales
|
||||
|
||||
Cette option n'est acceptable que si Louise fournit:
|
||||
|
||||
- schema JSON versionne;
|
||||
- signature HMAC des payloads;
|
||||
- cle d'idempotence par evenement;
|
||||
- numero de sequence global ou par entite;
|
||||
- retries automatiques;
|
||||
- endpoint de replay;
|
||||
- endpoint de full snapshot;
|
||||
- documentation claire;
|
||||
- environnement staging;
|
||||
- SLA ou garanties operationnelles.
|
||||
|
||||
### Evaluation
|
||||
|
||||
Webhook seul: non recommande.
|
||||
|
||||
Webhook + full snapshot: interessant.
|
||||
|
||||
## Option 2: Louise publie un snapshot JSON complet
|
||||
|
||||
Principe:
|
||||
|
||||
```text
|
||||
Louise
|
||||
-> full snapshot JSON
|
||||
-> ingestion interne
|
||||
-> diff avec snapshot precedent
|
||||
-> JSON site / bucket / CDN
|
||||
```
|
||||
|
||||
### Avantages
|
||||
|
||||
- Remplace le SQL par un format plus simple.
|
||||
- Supprime la base MySQL Mogador locale.
|
||||
- Supprime l'API Mogador.
|
||||
- Reste compatible avec un fonctionnement par snapshots.
|
||||
- Plus fiable qu'un webhook seul.
|
||||
- Permet de fabriquer notre propre incremental en comparant deux snapshots.
|
||||
|
||||
### Risques
|
||||
|
||||
- Pas temps reel si le snapshot reste toutes les 3h.
|
||||
- Louise doit fournir toutes les donnees necessaires.
|
||||
- Il faut valider que le JSON contient les memes informations que l'API Mogador.
|
||||
- Le fichier peut etre volumineux.
|
||||
|
||||
### Evaluation
|
||||
|
||||
Option tres interessante et probablement la plus realiste si Louise accepte de produire un format officiel complet.
|
||||
|
||||
## Option 3: Louise expose une API officielle moderne
|
||||
|
||||
Principe:
|
||||
|
||||
```text
|
||||
Sync Engine interne
|
||||
-> API Louise
|
||||
-> snapshots internes
|
||||
-> validation
|
||||
-> JSON site / bucket / CDN
|
||||
```
|
||||
|
||||
### Avantages
|
||||
|
||||
- Plus besoin de SQL.
|
||||
- Plus besoin de Mogador.
|
||||
- On garde le controle du moment ou on synchronise.
|
||||
- Plus facile a auditer qu'un webhook direct.
|
||||
- Peut etre plus proche du temps reel si l'API offre les bons endpoints.
|
||||
|
||||
### Risques
|
||||
|
||||
- Disponibilite de Louise.
|
||||
- Performance API.
|
||||
- Endpoints incomplets.
|
||||
- Changements de contrat API.
|
||||
- Depend toujours fortement du fournisseur.
|
||||
|
||||
### Endpoints necessaires
|
||||
|
||||
Il faudrait au minimum:
|
||||
|
||||
```text
|
||||
GET /products?updated_since=...
|
||||
GET /programs?platform=tfo&from=...&to=...
|
||||
GET /collections/{id}/full
|
||||
GET /products/{id}/full
|
||||
GET /media?product_id=...
|
||||
GET /snapshot/full
|
||||
GET /events/replay?since=...
|
||||
```
|
||||
|
||||
### Evaluation
|
||||
|
||||
Bonne option si Louise peut s'engager sur une vraie API produit, versionnee et documentee.
|
||||
|
||||
## Option 4: Garder le SQL Louise mais supprimer l'API Mogador
|
||||
|
||||
Principe:
|
||||
|
||||
```text
|
||||
Louise SQL
|
||||
-> import MySQL
|
||||
-> Laravel lit directement les tables
|
||||
-> Sync Engine interne
|
||||
-> JSON site / bucket / CDN
|
||||
```
|
||||
|
||||
### Avantages
|
||||
|
||||
- Supprime l'API Mogador.
|
||||
- Plus rapide potentiellement.
|
||||
- Plus de controle sur les requetes.
|
||||
- Plus facile de construire le modele attendu par les sites.
|
||||
|
||||
### Risques
|
||||
|
||||
- Contourne l'API officielle.
|
||||
- Risque contractuel ou audit.
|
||||
- Si Louise change la structure SQL, notre code casse.
|
||||
- Il faut reimplementer la logique que l'API Mogador fournit.
|
||||
|
||||
### Evaluation
|
||||
|
||||
Techniquement tentant, mais risque contractuel et operationnel important. A eviter si l'obligation d'utiliser l'API Mogador reste valide.
|
||||
|
||||
## Option 5: Double-run et retrait progressif de Mogador
|
||||
|
||||
Principe:
|
||||
|
||||
```text
|
||||
Flux actuel:
|
||||
Louise SQL -> Mogador API -> Laravel -> sortie actuelle
|
||||
|
||||
Nouveau flux en parallele:
|
||||
Louise nouvelle sortie -> Sync Engine v2 -> JSON statiques
|
||||
|
||||
Comparaison:
|
||||
sortie actuelle vs sortie v2
|
||||
```
|
||||
|
||||
### Avantages
|
||||
|
||||
- Transition securisee.
|
||||
- Permet de mesurer les ecarts avant de couper.
|
||||
- Permet de prouver que la nouvelle source remplace Mogador correctement.
|
||||
- Reduit le risque de regression.
|
||||
- Permet d'avancer progressivement.
|
||||
|
||||
### Risques
|
||||
|
||||
- Demande une periode ou deux flux coexistent.
|
||||
- Demande de construire des rapports de comparaison.
|
||||
|
||||
### Evaluation
|
||||
|
||||
Option recommandee si le retrait de Mogador est un objectif serieux.
|
||||
|
||||
## Recommandation
|
||||
|
||||
Ne pas supprimer Mogador en une seule etape.
|
||||
|
||||
La trajectoire recommandee:
|
||||
|
||||
```text
|
||||
1. Stabiliser et observer le flux actuel.
|
||||
2. Construire une sortie JSON statique interne.
|
||||
3. Demander a Louise un snapshot JSON complet ou une API moderne.
|
||||
4. Faire tourner le nouveau flux en parallele de Mogador.
|
||||
5. Comparer les resultats pendant plusieurs cycles.
|
||||
6. Retirer Mogador seulement quand les ecarts sont compris et acceptes.
|
||||
```
|
||||
|
||||
La meilleure architecture cible:
|
||||
|
||||
```text
|
||||
Louise
|
||||
-> full snapshot JSON officiel
|
||||
-> events optionnels pour accelerer certains changements
|
||||
-> Sync Engine interne
|
||||
-> validation et rapports
|
||||
-> JSON statiques par plateforme
|
||||
-> buckets/CDN
|
||||
-> sites web
|
||||
```
|
||||
|
||||
Cette approche combine:
|
||||
|
||||
- fiabilite du snapshot complet;
|
||||
- possibilite de publication plus rapide via events;
|
||||
- controle interne;
|
||||
- audit;
|
||||
- rollback;
|
||||
- suppression progressive de Mogador;
|
||||
- reduction ou retrait de Directus comme moteur de publication.
|
||||
|
||||
## Ce qu'il faut demander a Louise
|
||||
|
||||
Avant de prendre une decision, il faut demander au fournisseur Louise s'il peut fournir:
|
||||
|
||||
### Donnees
|
||||
|
||||
- un full snapshot JSON complet;
|
||||
- un schema documente et versionne;
|
||||
- les produits;
|
||||
- les programmations par plateforme et date;
|
||||
- les series/saisons;
|
||||
- les collections;
|
||||
- les episodes;
|
||||
- les droits;
|
||||
- les images;
|
||||
- les videos;
|
||||
- les transcriptions;
|
||||
- les presses FR/EN;
|
||||
- les categories pedagogiques IDELLO;
|
||||
- les dates de modification;
|
||||
- les suppressions.
|
||||
|
||||
### API ou events
|
||||
|
||||
- endpoint de full snapshot;
|
||||
- endpoint de diff ou updated_since;
|
||||
- webhook optionnel;
|
||||
- replay d'evenements;
|
||||
- statut d'export;
|
||||
- journal/audit des changements.
|
||||
|
||||
### Fiabilite
|
||||
|
||||
- retries;
|
||||
- idempotency key;
|
||||
- sequence number;
|
||||
- signature HMAC;
|
||||
- environnement staging;
|
||||
- SLA;
|
||||
- monitoring cote fournisseur;
|
||||
- documentation des erreurs.
|
||||
|
||||
## Position sur les webhooks
|
||||
|
||||
Un webhook peut etre utile, mais ne doit pas etre la seule source de verite.
|
||||
|
||||
Bonne utilisation:
|
||||
|
||||
```text
|
||||
Louise webhook: "un produit ou programme a change"
|
||||
Notre systeme: recupere/valide les donnees, puis publie
|
||||
```
|
||||
|
||||
Mauvaise utilisation:
|
||||
|
||||
```text
|
||||
Louise webhook -> site directement
|
||||
```
|
||||
|
||||
Le site ne devrait pas dependre directement d'un webhook fournisseur.
|
||||
|
||||
## Publication web proposee
|
||||
|
||||
Comme l'app Laravel ne peut pas etre exposee a Internet, la publication devrait se faire par JSON statiques.
|
||||
|
||||
```text
|
||||
Laravel interne
|
||||
-> genere JSON
|
||||
-> publie vers S3/CDN/bucket
|
||||
-> sites lisent les fichiers JSON
|
||||
```
|
||||
|
||||
Exemples:
|
||||
|
||||
```text
|
||||
/tfo/manifest.json
|
||||
/tfo/today.json
|
||||
/tfo/latest.json
|
||||
/tfo/schedule/2026-08-08.json
|
||||
/tfo/products/GP123456.json
|
||||
/tfo/collections/0123456/full.json
|
||||
```
|
||||
|
||||
Cela evite d'exposer Laravel tout en donnant aux sites une source rapide, stable et cacheable.
|
||||
|
||||
## Permissions fournisseurs
|
||||
|
||||
Si Directus est retire, les permissions peuvent etre gerees au niveau bucket ou CDN.
|
||||
|
||||
Option simple:
|
||||
|
||||
```text
|
||||
bucket-tfo
|
||||
bucket-idello
|
||||
bucket-onfr
|
||||
```
|
||||
|
||||
Option plus centralisee:
|
||||
|
||||
```text
|
||||
publication/tfo/
|
||||
publication/idello/
|
||||
publication/onfr/
|
||||
```
|
||||
|
||||
Chaque fournisseur ou site a acces seulement a son bucket ou prefixe.
|
||||
|
||||
## Edition d'urgence sans Directus
|
||||
|
||||
Si Directus est retire, il faut une alternative interne.
|
||||
|
||||
Proposition:
|
||||
|
||||
```text
|
||||
mini CMS interne Laravel
|
||||
```
|
||||
|
||||
Fonctions:
|
||||
|
||||
- rechercher produit/collection/programme;
|
||||
- voir donnees source;
|
||||
- voir JSON publie;
|
||||
- ajouter override temporaire;
|
||||
- indiquer raison;
|
||||
- date d'expiration;
|
||||
- audit trail;
|
||||
- republication controlee.
|
||||
|
||||
Les corrections ne doivent pas etre faites directement dans les JSON publies. Elles doivent etre stockees comme overrides et reappliquees a chaque generation.
|
||||
|
||||
## Critere de decision
|
||||
|
||||
Mogador peut etre retire seulement si une nouvelle source fournit au moins:
|
||||
|
||||
- toutes les donnees necessaires;
|
||||
- une logique equivalente ou documentee;
|
||||
- une preuve d'audit;
|
||||
- un mode full snapshot;
|
||||
- un mode replay;
|
||||
- des garanties contre la perte d'evenements;
|
||||
- un contrat de schema stable;
|
||||
- une facon de comparer l'ancien flux et le nouveau.
|
||||
|
||||
Sans ces garanties, supprimer Mogador risque de rendre le systeme plus fragile, meme s'il semble plus simple sur papier.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Supprimer Mogador est une bonne direction strategique, mais pas sous forme de webhook direct vers les sites.
|
||||
|
||||
La recommandation est:
|
||||
|
||||
```text
|
||||
Ne pas aller vers "Louise save -> site".
|
||||
Aller vers "Louise snapshot/API officielle -> Sync Engine interne -> JSON statiques -> buckets/CDN".
|
||||
```
|
||||
|
||||
Mogador devrait etre retire progressivement, apres une periode de double-run et de comparaison.
|
||||
|
||||
Cette strategie donne:
|
||||
|
||||
- moins de dependance a Mogador;
|
||||
- une publication plus rapide;
|
||||
- moins de dependance a Directus;
|
||||
- un meilleur controle interne;
|
||||
- des rapports proactifs;
|
||||
- une meilleure fiabilite;
|
||||
- un chemin de migration prudent.
|
||||
Reference in New Issue
Block a user