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.

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.

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/manifest.json
/tfo/today.json
/tfo/latest.json
/tfo/schedule/index.json
/tfo/schedule/2026-07-30.json
/tfo/schedule/2026-07-31.json
/tfo/collections/index.json
/tfo/collections/0123456/full.json
/tfo/products/GP123456.json
/tfo/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.

manifest.json

Le manifest indique quelle version est publiee.

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

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=14
IDELLO_SCHEDULE_DAYS_AHEAD=30
ONFR_SCHEDULE_DAYS_AHEAD=14
LINEAR_SCHEDULE_DAYS_BEHIND=7
LINEAR_SCHEDULE_DAYS_AHEAD=15

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.

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/runs/20260730-0900/...
/tfo/runs/20260730-1200/...
/tfo/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.

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.