SecondBrain/20 Work/Ideas/Proposition d'architecture Sync Mogador v2.md

Objectif

Ce document resume une proposition de refonte de la synchronisation Mogador afin de rendre le systeme plus fiable, plus simple a maintenir et plus rapide a publier vers les sites TFO, IDELLO, ONFR et Linear.

Le but n'est pas de jeter toute la connaissance metier existante. Le code actuel contient plusieurs regles importantes qui doivent etre conservees. Par contre, l'architecture actuelle est devenue lourde parce que la synchronisation, Directus, les permissions, la publication web, les rapports et les corrections d'urgence sont trop melanges.

Contexte actuel

Louise est la vraie source de verite.

Toutes les 3 heures, Louise produit un fichier SQL complet, export_mogador.sql. Ce fichier n'est jamais incremental. Il commence par des TRUNCATE, puis reinsere toutes les donnees.

Le flux actuel ressemble a ceci:

Louise
  -> export_mogador.sql complet
  -> rsync vers serveur Linux
  -> import dans une base MySQL structuree avec mogador.sql
  -> API Mogador officielle qui parle a cette base
  -> application Laravel interne
  -> synchronisation vers Directus
  -> sites web / fournisseurs consomment Directus ou redistribuent dans leurs propres bases

Aujourd'hui, il y a trois serveurs avec une copie du meme code:

P1: TFO + Linear
P2: IDELLO
P3: ONFR

Cette separation existe surtout parce qu'un seul serveur prendrait trop de temps a synchroniser toutes les plateformes. L'export, le transfert, l'import SQL et la synchronisation prennent environ 1 heure par cycle.

Contraintes importantes

• La source officielle reste le fichier SQL exporte par Louise.
• L'equipe dev peut regarder la base Mogador, mais la consommation officielle des donnees doit passer par l'API Mogador.
• L'API Mogador doit rester dans le flux pour rester conforme aux attentes contractuelles et eviter de contourner une logique API qui pourrait changer.
• L'app Laravel ne doit pas etre exposee a Internet selon les contraintes Infra actuelles.
• Les fournisseurs ont besoin d'un acces read-only aux donnees publiees.
• L'equipe interne doit pouvoir faire des corrections d'urgence sans attendre le prochain export Louise.
• Les sites veulent des donnees organisees dans le sens utilisateur: collection -> saisons -> episodes -> programmations.
• Louise expose souvent les donnees dans le sens inverse: episode -> programmation -> serie -> collection.
• Directus est utile pour les permissions et l'edition, mais devient problematique comme moteur relationnel/publication.

Problemes actuels

1. Architecture lourde

Le meme code est deploye sur plusieurs serveurs, chaque serveur etant responsable d'une plateforme. Cela rend les mises a jour, les migrations, les alertes et le debugging plus compliques.

2. Directus est force dans un role trop large

Directus sert aujourd'hui a:

• donner un acces read-only aux fournisseurs;
• permettre des corrections d'urgence par l'equipe interne;
• exposer les donnees aux sites;
• representer des relations complexes entre produits, programmations, series et collections.

Le probleme est surtout le dernier point. Les relations entre products, programmations, series et collections sont difficiles a maintenir dans Directus. Certaines relations ne peuvent pas etre creees proprement a cause de contraintes FK ou du modele de donnees.

3. Le modele attendu par les sites est different du modele Louise

Terminologie metier:

Collection = serie pour le public
Serie = saison
Episode = episode

Les sites veulent souvent:

{
  "collection": {},
  "seasons": [
    {
      "serie": {},
      "episodes": [
        {
          "product": {},
          "programmations": [],
          "media": {},
          "images": []
        }
      ]
    }
  ]
}

Mais les donnees Louise/Mogador sont souvent disponibles depuis l'episode, puis il faut remonter vers la serie/saison et la collection.

Exemple de difficulte: is_original est disponible sur les episodes, mais pas directement sur la collection. Si le site veut afficher cette information au niveau collection, il faut definir une regle de remontee.

4. Peu d'observabilite proactive

Aujourd'hui, l'equipe est souvent reactive. Les problemes sont decouverts quand la production ou les sites signalent une erreur.

Exemples de problemes deja rencontres:

• supervisor down;
• worker queue down;
• migration Laravel oubliee lors d'un changement de serveur;
• programmation attendue absente du site;
• synchro incomplete;
• donnees manquantes dans Directus.

5. Besoin de programmation future

Une demande recurrente est de pouvoir afficher des informations comme:

Prochain episode le 8 aout

Aujourd'hui, se limiter a la programmation du jour evite de ralentir la sync, mais limite les usages des sites.

Decision recommandee

La recommandation principale est de ne plus utiliser Directus comme moteur principal de publication web.

L'application Laravel devrait rester interne et produire des JSON statiques prets a consommer par les sites.

Architecture cible:

Louise SQL full export
  -> import MySQL Mogador
  -> API Mogador officielle
  -> Laravel interne: Sync Engine v2
  -> donnees internes / snapshots / rapports
  -> generation de JSON statiques
  -> publication vers buckets S3/CDN par plateforme
  -> sites web consomment les JSON

Laravel ne serait pas expose a Internet. Les sites ne parlent pas a Laravel. Ils lisent des fichiers JSON statiques publies dans un bucket ou CDN.

Role futur de Directus

Deux options sont possibles.

Option 1: retirer Directus progressivement

Si les sites consomment les JSON statiques et si les permissions fournisseurs sont gerees par bucket ou prefixe, Directus n'est plus necessaire dans la chaine de publication.

Les permissions peuvent etre gerees par:

bucket-tfo
bucket-idello
bucket-onfr

Ou par un seul bucket avec prefixes:

publication/tfo/
publication/idello/
publication/onfr/

Chaque fournisseur ou site a acces seulement a son bucket ou son prefixe.

Option 2: garder Directus uniquement temporairement

Directus peut rester pendant une periode de transition pour:

• consultation interne;
• edition d'urgence;
• acces read-only fournisseur existant.

Mais il ne devrait plus etre responsable de composer le JSON relationnel final utilise par les sites.

Edition d'urgence

Si Directus est retire, il faut remplacer son role d'edition d'urgence.

La proposition est de creer un mini CMS interne dans Laravel, non expose a Internet.

Ce mini CMS doit etre protege par authentification. Les edimestres qui ont aujourd'hui acces a Directus devront avoir acces a cet outil interne selon leurs roles.

Acces proposes:

Admin sync:
- peut configurer et publier
- peut gerer les utilisateurs
- peut faire rollback

Edimestre:
- peut rechercher et consulter
- peut creer une correction d'urgence
- peut voir les overrides actifs
- ne peut pas changer la configuration systeme

Read-only interne:
- peut consulter les donnees, rapports et JSON publies
- ne peut pas modifier

Le mini CMS doit rester disponible uniquement sur le reseau interne ou via VPN/SSO interne. Il ne doit pas devenir une API publique.

Fonctions minimales:

• rechercher un produit, programme, collection ou serie;
• voir les donnees venant de Mogador;
• voir le JSON actuellement publie;
• ajouter une correction temporaire;
• mettre une raison;
• mettre une date d'expiration;
• republier les JSON concernes;
• garder un historique complet.

Exemple de table:

manual_overrides
- id
- platform
- entity_type: product | program | collection | serie
- entity_key: product_key | program_key | biznumber
- field_path
- value_json
- reason
- active_from
- active_until
- created_by
- approved_by
- created_at
- updated_at

Exemple d'override:

{
  "platform": "tfo",
  "entity_type": "collection",
  "entity_key": "0123456",
  "field_path": "is_original",
  "value_json": true,
  "reason": "Correction urgente demandee par programmation",
  "active_until": "2026-08-02T23:59:59"
}

Important: il ne faut pas modifier les JSON publies directement a la main. Les overrides doivent etre appliques dans le pipeline de generation, sinon ils seront perdus ou impossibles a auditer.

Chaque override devrait inclure:

• l'utilisateur;
• le role;
• la raison;
• la date d'expiration;
• l'entite touchee;
• l'ancien contenu;
• le nouveau contenu;
• le run dans lequel la correction a ete publiee.

Fabrication d'un incremental a partir d'un full export

Louise ne fournit pas d'incremental. Chaque export est complet.

La solution est de sauvegarder des snapshots internes et de comparer les snapshots entre eux.

Exemple:

09h00: export Louise complet
      -> import MySQL
      -> extraction via API Mogador
      -> snapshot_09h00

12h00: export Louise complet
      -> import MySQL
      -> extraction via API Mogador
      -> snapshot_12h00

Diff snapshot_09h00 -> snapshot_12h00:
      -> programmes ajoutes
      -> programmes retires
      -> produits modifies
      -> images modifiees
      -> dates de programmation modifiees
      -> erreurs ou anomalies

On ne demande donc pas a Louise de changer son fonctionnement. On fabrique notre propre diff a partir des donnees extraites apres chaque full export.

Cela permet:

• de savoir ce qui a change;
• de generer un latest.json;
• de limiter certaines publications;
• de produire un rapport clair;
• de conserver un historique.

Donnees internes proposees

Le terme "canonical" veut simplement dire: donnees internes propres, normalisees et controlees par nous.

Il n'est pas obligatoire d'utiliser le mot canonical dans le code. L'idee est d'avoir une couche interne avant la publication.

Exemples de tables:

sync_runs
sync_run_items
sync_anomalies
products
programs
collections
series
episodes
media
publication_snapshots
manual_overrides
deleted_programs

Avec une colonne platform:

tfo
idello
onfr
linear

Cela evite de dupliquer toute la logique dans des tables separees comme tfo_products, idello_products, onfr_products, etc., sauf si une contrainte technique oblige a garder cette separation.

JSON statiques proposes

Au lieu d'un seul gros JSON, il faut publier plusieurs fichiers specialises.

Exemple pour TFO:

/tfo/v1/manifest.json
/tfo/v1/runs/20260730-0900/today.json
/tfo/v1/runs/20260730-0900/latest.json
/tfo/v1/runs/20260730-0900/schedule/index.json
/tfo/v1/runs/20260730-0900/schedule/2026-07-30.json
/tfo/v1/runs/20260730-0900/schedule/2026-07-31.json
/tfo/v1/runs/20260730-0900/collections/index.json
/tfo/v1/runs/20260730-0900/collections/0123456/full.json
/tfo/v1/runs/20260730-0900/products/GP123456.json
/tfo/v1/runs/20260730-0900/search/index.json

Pour 8 000 produits TFO et 22 000 produits IDELLO, ce volume de fichiers JSON n'est pas un probleme pour un bucket S3/CDN. C'est meme preferable a un gros fichier unique.

Le site ne devrait pas coder un chemin de run en dur. Il lit toujours le manifest:

/tfo/v1/manifest.json

Puis il utilise le base_path retourne:

/tfo/v1/runs/20260730-0900

manifest.json

Le manifest indique quelle version est publiee.

{
  "schema_version": "1.0",
  "platform": "tfo",
  "published_at": "2026-07-30T09:50:00",
  "run_id": "20260730-0900",
  "base_path": "/tfo/v1/runs/20260730-0900"
}

Le manifest est le seul fichier qui doit avoir un cache court.

Cache recommande:

/tfo/v1/manifest.json
Cache-Control: public, max-age=60, stale-while-revalidate=120

/tfo/v1/runs/20260730-0900/*
Cache-Control: public, max-age=31536000, immutable

Meme si Louise exporte seulement toutes les 3 heures, le manifest ne devrait pas etre cache 3 heures. Il doit pouvoir changer rapidement pour:

• correction d'urgence via mini CMS;
• rollback;
• republication apres erreur;
• correction d'un mapping;
• correction d'une video/image;
• publication manuelle.

Compromis acceptable si Infra veut reduire les appels:

manifest.json: max-age=300

Donc 5 minutes. Mais 3 heures est trop long pour les corrections d'urgence.

today.json

Contient ce qui doit etre en ligne aujourd'hui.

{
  "date": "2026-07-30",
  "programs": []
}

latest.json

Contient les nouveautes et changements depuis la derniere publication.

{
  "run_id": "20260730-0900",
  "added": [],
  "updated": [],
  "removed": []
}

schedule/YYYY-MM-DD.json

Contient la programmation d'une date precise.

{
  "date": "2026-08-08",
  "programs": [
    {
      "program_key": 123,
      "product_key": 456,
      "begin": "2026-08-08T06:00:00",
      "end": "2026-08-08T06:24:00",
      "title": "..."
    }
  ]
}

products/{id}.json

Contient le detail d'un produit.

{
  "product": {},
  "programmations": {
    "current": [],
    "upcoming": [],
    "next": {
      "date": "2026-08-08",
      "begin": "2026-08-08T06:00:00"
    }
  },
  "media": {},
  "images": []
}

collections/{biznumber}/full.json

Contient le modele attendu par les sites.

{
  "collection": {
    "biznumber": "0123456",
    "title": "...",
    "is_original": true,
    "next_programmation": {
      "date": "2026-08-08",
      "begin": "2026-08-08T06:00:00"
    }
  },
  "seasons": [
    {
      "serie": {},
      "episodes": [
        {
          "product": {},
          "programmations": [],
          "media": {},
          "images": []
        }
      ]
    }
  ]
}

Programmations futures

Pour afficher des messages comme "prochain episode le 8 aout", il faut extraire une fenetre future de programmation.

Proposition configurable:

TFO_SCHEDULE_DAYS_AHEAD=10
IDELLO_SCHEDULE_DAYS_AHEAD=10
ONFR_SCHEDULE_DAYS_AHEAD=10
LINEAR_SCHEDULE_DAYS_BEHIND=7
LINEAR_SCHEDULE_DAYS_AHEAD=10

Les programmations futures sont publiees dans:

/tfo/schedule/2026-08-08.json

Et resumees dans les JSON produit/collection:

{
  "next_programmation": {
    "date": "2026-08-08",
    "begin": "2026-08-08T06:00:00"
  }
}

Cela evite aux sites de parcourir toute la grille future pour afficher une information simple.

Le maximum propose pour la v1 est J+10. Cette limite garde les JSON raisonnables et evite que la generation future ralentisse inutilement la synchronisation.

Le site peut ensuite appliquer sa logique d'affichage selon l'heure. Par exemple, si un programme est prevu a 6h, le JSON contient deja begin: 06:00, et le site decide quand l'afficher ou le mettre en evidence.

Search et Algolia

Un fichier comme:

/tfo/search/index.json

peut servir a alimenter Algolia, Meilisearch, Typesense ou un autre moteur de recherche.

Il peut contenir seulement les champs utiles a la recherche:

[
  {
    "objectID": "GP123456",
    "type": "product",
    "title": "...",
    "slug": "...",
    "image": "...",
    "collection_biznumber": "0123456"
  }
]

Si les sites ont besoin d'une vraie recherche rapide sur 8 000 a 22 000 items, un moteur dedie comme Algolia reste preferable a un gros fichier recherche charge cote client.

Publication atomique

Il faut eviter qu'un site lise une publication incomplete.

Principe:

/tfo/v1/runs/20260730-0900/...
/tfo/v1/runs/20260730-1200/...
/tfo/v1/manifest.json

Le site lit d'abord:

/tfo/manifest.json

Puis utilise le base_path indique.

Si la generation du run 20260730-1200 echoue, manifest.json continue de pointer vers 20260730-0900.

Ainsi, une sync ratee ne casse pas le site.

Exemple simplifie:

/tfo/v1/runs/1/collections/...
/tfo/v1/runs/1/products/...

/tfo/v1/runs/2/collections/...
/tfo/v1/runs/2/products/...

/tfo/v1/manifest.json -> pointe vers /tfo/v1/runs/2

Retention des runs

Il faut supprimer les anciens runs pour eviter une croissance infinie du bucket.

Politique proposee:

JSON publies:
- garder les runs des 10 derniers jours
- garder au minimum les 3 derniers runs valides
- supprimer les runs incomplets jamais publies

Rapports:
- garder 90 jours

Anomalies importantes / audit:
- garder 1 an ou selon politique interne

Pourquoi garder au moins 3 runs valides:

• rollback rapide;
• comparaison entre publications;
• diagnostic si un site signale un probleme.

Versioning du contrat JSON

Les JSON deviennent un contrat avec les sites. Il faut donc versionner le format.

Version dans le chemin:

/tfo/v1/manifest.json
/tfo/v1/runs/20260730-0900/products/GP123456.json
/tfo/v1/runs/20260730-0900/collections/0123456/full.json

Version dans chaque fichier:

{
  "schema_version": "1.0",
  "platform": "tfo",
  "run_id": "20260730-0900"
}

Si un changement cassant est necessaire:

/tfo/v2/manifest.json

La v1 et la v2 peuvent coexister pendant une periode de transition.

Documentation et validation

Swagger/OpenAPI est surtout utile pour des API dynamiques. Pour des JSON statiques, la documentation devrait plutot etre:

docs/
  publication-contract.md
  files.md
  cache-strategy.md
  versioning.md
  examples/
    manifest.json
    product.json
    collection-full.json
    schedule-day.json
  schemas/
    manifest.schema.json
    product.schema.json
    collection-full.schema.json
    schedule-day.schema.json

Les JSON Schema sont importants parce qu'ils permettent de valider automatiquement les fichiers avant publication.

Avant de publier un run:

1. generer tous les JSON
2. valider chaque type de fichier contre son JSON Schema
3. produire le rapport
4. publier seulement si les erreurs critiques sont absentes
5. mettre a jour manifest.json

Rapport et alertes

Le rapport est une piece centrale de la v2.

Il doit comparer:

ce que le fichier Louise/Mogador contient
vs
ce que Laravel a traite
vs
ce qui a ete publie en JSON
vs
eventuellement ce qui reste dans Directus pendant la transition

Exemple de rapport:

Plateforme: TFO
Run: 20260730-0900

Export SQL recu: oui
Import MySQL: succes
API Mogador: OK

Programmes attendus aujourd'hui: 1230
Programmes publies: 1229
Produits attendus: 8142
Produits publies: 8139

Ecarts:
- 1 programme absent du JSON final
- 2 produits sans video JWP
- 5 images manquantes
- 1 produit ignore car type extrait

Publication:
- statut: publie avec avertissements
- manifest pointe vers: /tfo/runs/20260730-0900

Alertes a mettre en place:

• export SQL non recu;
• fichier SQL trop petit ou checksum identique de facon suspecte;
• import MySQL echoue;
• API Mogador ne repond pas;
• workers down;
• queue bloquee;
• sync trop longue;
• ecart entre attendu et publie;
• programme prevu a 6h absent de la publication avant 6h;
• video JWP manquante;
• image ou transcription manquante;
• override actif proche expiration.

Fichier SQL hors Laravel

Le fait que export_mogador.sql soit hors du repertoire Laravel n'est pas un probleme.

Le script d'import peut ecrire un fichier de statut dans un chemin connu:

{
  "export_received_at": "2026-07-30T09:01:00",
  "import_started_at": "2026-07-30T09:35:00",
  "import_finished_at": "2026-07-30T09:48:00",
  "sql_file_size": 306184192,
  "checksum": "abc123",
  "status": "success"
}

Laravel lit ce statut pour produire son rapport.

Chemins configurables:

MOGADOR_EXPORT_PATH=/data/mogador/export_mogador.sql
MOGADOR_IMPORT_STATUS_PATH=/data/mogador/import-status.json
MOGADOR_IMPORT_LOG_PATH=/var/log/mogador-import.log

Plan de migration propose

Phase 1: Observabilite

Objectif: savoir ce qui se passe avant de tout changer.

• Ajouter sync_runs.
• Ajouter sync_run_items.
• Ajouter sync_anomalies.
• Generer un rapport par plateforme.
• Alerter sur les ecarts critiques.
• Garder Directus tel quel.

Phase 2: Publication JSON en parallele

Objectif: produire les JSON sans encore remplacer Directus.

• Generer /manifest.json.
• Generer /today.json.
• Generer /schedule/YYYY-MM-DD.json.
• Generer quelques /products/{id}.json.
• Generer quelques /collections/{id}/full.json.
• Comparer JSON vs Directus.

Phase 3: Premier site pilote

Objectif: faire consommer les JSON par un site ou une section limitee.

• Choisir une plateforme simple, probablement ONFR ou une portion TFO.
• Publier dans un bucket/prefix dedie.
• Valider performance, structure JSON, cache et rollback.

Phase 4: Mini CMS interne

Objectif: remplacer l'edition d'urgence Directus.

• Ajouter manual_overrides.
• Ajouter interface interne Laravel.
• Ajouter audit trail.
• Ajouter expiration automatique.
• Ajouter rapport des overrides actifs.

Phase 5: Reduction ou retrait de Directus

Objectif: retirer Directus de la publication si les JSON remplissent le besoin.

• Garder Directus seulement pendant transition.
• Migrer les usages fournisseurs vers buckets/CDN.
• Retirer progressivement les dependances Directus.

Position finale

La proposition recommandee est:

Laravel interne + snapshots + diff maison + JSON statiques + buckets/CDN + rapports + mini CMS d'urgence

Directus peut etre garde temporairement, mais ne devrait plus etre le moteur principal de publication web.

Cette approche respecte les contraintes:

• Louise reste source de verite.
• L'API Mogador officielle reste utilisee.
• Laravel n'est pas expose a Internet.
• Les sites recoivent des donnees simples et rapides.
• Les fournisseurs peuvent etre isoles par bucket ou prefixe.
• L'equipe interne garde la capacite de corriger en urgence.
• Les erreurs deviennent visibles avant que la production les signale.