vault backup: 2026-08-01 15:51:54

20 Work/Ideas/Mogador/Consultation fournisseurs sites- proposition de publication JSON.md

@@ -1,17 +1,16 @@
-
 ## Objectif
 
-Nous evaluons une nouvelle facon de fournir les donnees de programmation et de contenus aux sites web TFO, IDELLO, ONFR et lineaire.
+Nous évaluons une nouvelle façon de fournir les données de programmation et de contenus aux sites web TFO, IDELLO, ONFR et linéaire.
 
-L'objectif est de savoir si une publication sous forme de fichiers JSON versionnes peut bien repondre a vos besoins techniques et operationnels.
+L'objectif est de savoir si une publication sous forme de fichiers JSON versionnés peut bien répondre à vos besoins techniques et opérationnels.
 
-Ce document ne presente pas une decision finale. Il sert a recueillir vos commentaires avant de figer le format.
+Ce document ne présente pas une décision finale. Il sert à recueillir vos commentaires avant de figer le format.
 
-## Idee generale
+## Idée générale
 
-Aujourd'hui, les donnees sont disponibles via Directus ou via des mecanismes de synchronisation propres a chaque site.
+Aujourd'hui, les données sont disponibles via Directus ou via des mécanismes de synchronisation propres à chaque site.
 
-La proposition est de publier des fichiers JSON prets a consommer, organises par plateforme, par version et par publication.
+La proposition est de publier des fichiers JSON prêts à consommer, organisés par plateforme, par version et par publication.
 
 Exemple:
 
@@ -32,7 +31,7 @@ Les sites ne devraient pas coder un chemin de run en dur. Ils liraient d'abord:
 /tfo/v1/manifest.json
 ```
 
-Puis utiliseraient le `base_path` retourne par le manifest pour charger les fichiers du run actif.
+Puis utiliseraient le `base_path` retourné par le manifest pour charger les fichiers du run actif.
 
 ## Exemple de manifest
 
@@ -46,13 +45,43 @@ Puis utiliseraient le `base_path` retourne par le manifest pour charger les fich
 }
 ```
 
-Le `manifest.json` permet de changer de publication de facon atomique. Si une nouvelle generation echoue, le manifest continue de pointer vers le dernier run valide.
+Le `manifest.json` permet de changer de publication de façon atomique. Si une nouvelle génération échoue, le manifest continue de pointer vers le dernier run valide.
 
-## Types de fichiers proposes
+## Runs complets et changements incrémentaux
+
+Chaque run publié doit être considéré comme une version complète des données disponibles pour une plateforme.
+
+Par contre, entre deux runs, tous les fichiers ne changent pas nécessairement.
+
+Exemple:
+
+```text
+Run 1:
+8 000 produits
+
+Run 2:
+10 nouveaux produits
+5 produits retirés
+7 produits modifiés
+```
+
+Dans ce cas, le run 2 reste un run complet pour le site, mais seuls les fichiers réellement impactés devraient changer.
+
+Conséquence pour les sites:
+
+- il faut toujours lire le `manifest.json` pour connaître le run actif;
+- il ne faut pas supposer que tous les fichiers changent à chaque run;
+- un fichier produit inchangé peut être identique entre deux runs;
+- un produit retiré ne devrait plus apparaître dans les indexes du nouveau run;
+- `latest.json` peut aider à savoir ce qui a été ajouté, modifié ou retiré.
+
+Cette approche permet de publier plus vite et de réduire le risque de remplacer des données valides par des données incomplètes.
+
+## Types de fichiers proposés
 
 ### today.json
 
-Contient les contenus ou programmations pertinents pour la journee courante.
+Contient les contenus ou programmations pertinents pour la journée courante.
 
 ```json
 {
@@ -66,7 +95,7 @@ Contient les contenus ou programmations pertinents pour la journee courante.
 
 ### latest.json
 
-Contient les contenus ajoutes, modifies ou retires depuis la derniere publication.
+Contient les contenus ajoutés, modifiés ou retirés depuis la dernière publication.
 
 ```json
 {
@@ -81,7 +110,7 @@ Contient les contenus ajoutes, modifies ou retires depuis la derniere publicatio
 
 ### schedule/YYYY-MM-DD.json
 
-Contient la programmation pour une date precise.
+Contient la programmation pour une date précise.
 
 ```json
 {
@@ -95,17 +124,17 @@ Contient la programmation pour une date precise.
       "product_key": "GP123456",
       "begin": "2026-08-08T06:00:00-04:00",
       "end": "2026-08-08T06:24:00-04:00",
-      "title": "Titre de l'episode"
+      "title": "Titre de l'épisode"
     }
   ]
 }
 ```
 
-La premiere version viserait une fenetre future jusqu'a J+10.
+La première version viserait une fenêtre future jusqu'à J+10.
 
 ### products/{product_key}.json
 
-Contient le detail d'un produit ou episode.
+Contient le détail d'un produit ou épisode.
 
 ```json
 {
@@ -115,7 +144,7 @@ Contient le detail d'un produit ou episode.
   "product": {
     "product_key": "GP123456",
     "biznumber": "0123456",
-    "title": "Titre de l'episode",
+    "title": "Titre de l'épisode",
     "description": "..."
   },
   "programmations": {
@@ -133,10 +162,10 @@ Contient le detail d'un produit ou episode.
 
 ### collections/{biznumber}/full.json
 
-Contient une vue complete d'une collection, dans le sens attendu par les sites:
+Contient une vue complète d'une collection, dans le sens attendu par les sites:
 
 ```text
-collection -> saisons -> episodes
+collection -> saisons -> épisodes
 ```
 
 Exemple:
@@ -169,7 +198,7 @@ Exemple:
         {
           "product": {
             "product_key": "GP123456",
-            "title": "Episode 1"
+            "title": "Épisode 1"
           },
           "programmations": [],
           "media": {},
@@ -183,14 +212,14 @@ Exemple:
 
 ### search/index.json
 
-Fichier optionnel pouvant servir a alimenter un moteur de recherche comme Algolia, Meilisearch, Typesense ou un index interne.
+Fichier optionnel pouvant servir à alimenter un moteur de recherche comme Algolia, Meilisearch, Typesense ou un index interne.
 
 ```json
 [
   {
     "objectID": "GP123456",
     "type": "product",
-    "title": "Titre de l'episode",
+    "title": "Titre de l'épisode",
     "slug": "titre-de-lepisode",
     "image": "https://...",
     "collection_biznumber": "0123456"
@@ -198,7 +227,7 @@ Fichier optionnel pouvant servir a alimenter un moteur de recherche comme Algoli
 ]
 ```
 
-## Cache propose
+## Cache proposé
 
 Le manifest aurait un cache court:
 
@@ -207,7 +236,7 @@ Le manifest aurait un cache court:
 Cache-Control: public, max-age=60, stale-while-revalidate=120
 ```
 
-Les fichiers d'un run seraient immuables et pourraient etre caches longtemps:
+Les fichiers d'un run seraient immuables et pourraient être cachés longtemps:
 
 ```text
 /tfo/v1/runs/20260730-0900/*
@@ -216,19 +245,19 @@ Cache-Control: public, max-age=31536000, immutable
 
 Logique:
 
-- le site consulte regulierement `manifest.json`;
+- le site consulte régulièrement `manifest.json`;
 - si `run_id` change, le site charge les fichiers du nouveau run;
 - les fichiers des runs ne changent jamais;
-- un rollback peut etre fait en repointant le manifest vers un run precedent.
+- un rollback peut être fait en repointant le manifest vers un run précédent.
 
 ## Points importants pour les sites
 
-- Les JSON seraient versionnes dans le chemin: `/v1/`, puis eventuellement `/v2/`.
+- Les JSON seraient versionnés dans le chemin: `/v1/`, puis éventuellement `/v2/`.
-- Les changements cassants seraient publies dans une nouvelle version.
+- Les changements cassants seraient publiés dans une nouvelle version.
 - Les dates seraient fournies avec timezone explicite.
-- Les fichiers seraient separes pour eviter de telecharger un enorme JSON unique.
+- Les fichiers seraient séparés pour éviter de télécharger un énorme JSON unique.
-- Les sites pourraient consommer seulement les fichiers utiles a leurs pages.
+- Les sites pourraient consommer seulement les fichiers utiles à leurs pages.
-- Les fournisseurs pourraient avoir acces uniquement a leur plateforme ou prefixe.
+- Les fournisseurs pourraient avoir accès uniquement à leur plateforme ou préfixe.
 
 ## Questions pour vous
 
@@ -237,28 +266,28 @@ Merci de nous dire si cette approche fonctionnerait pour votre site, et de comme
 ### Consommation
 
 - Est-ce que votre site peut consommer des fichiers JSON statiques via HTTP/CDN?
-- Est-ce que votre site peut lire un `manifest.json` avant de charger les donnees?
+- Est-ce que votre site peut lire un `manifest.json` avant de charger les données?
 - Avez-vous besoin d'une API dynamique, ou des fichiers JSON suffisent?
-- Avez-vous des contraintes sur le nombre de fichiers charges?
+- Avez-vous des contraintes sur le nombre de fichiers chargés?
 
-### Structure des donnees
+### Structure des données
 
-- Le modele `collection -> seasons -> episodes` convient-il a vos pages?
+- Le modèle `collection -> seasons -> episodes` convient-il à vos pages?
-- Le fichier `products/{product_key}.json` contient-il le bon niveau de detail?
+- Le fichier `products/{product_key}.json` contient-il le bon niveau de détail?
 - Le fichier `collections/{biznumber}/full.json` est-il trop gros, trop petit ou correct?
 - Avez-vous besoin d'autres regroupements?
 - Quels champs sont obligatoires pour vos pages?
 
 ### Programmation
 
-- La fenetre future J+10 est-elle suffisante?
+- La fenêtre future J+10 est-elle suffisante?
-- Avez-vous besoin de programmation passee?
+- Avez-vous besoin de programmation passée?
 - Avez-vous besoin d'un fichier par date, par semaine ou par mois?
-- Comment affichez-vous "prochain episode" aujourd'hui?
+- Comment affichez-vous "prochain épisode" aujourd'hui?
 
 ### Media et images
 
-- Quels champs media sont requis pour votre lecteur video?
+- Quels champs media sont requis pour votre lecteur vidéo?
 - Avez-vous besoin de plusieurs formats d'image?
 - Avez-vous besoin de sous-titres, transcriptions, audio ou autres assets dans le JSON?
 
@@ -266,24 +295,24 @@ Merci de nous dire si cette approche fonctionnerait pour votre site, et de comme
 
 - Utilisez-vous Algolia, Meilisearch, Typesense ou un autre moteur?
 - Un fichier `search/index.json` vous serait-il utile?
-- Quels champs devraient etre inclus dans l'index?
+- Quels champs devraient être inclus dans l'index?
 
-### Cache et mise a jour
+### Cache et mise à jour
 
 - Un cache court sur `manifest.json` vous convient-il?
-- Quelle frequence de verification du manifest serait acceptable?
+- Quelle fréquence de vérification du manifest serait acceptable?
 - Avez-vous besoin d'un webhook ou signal pour savoir qu'un nouveau run est disponible?
-- Comment votre site ferait-il un rollback si necessaire?
+- Comment votre site ferait-il un rollback si nécessaire?
 
 ### Migration
 
-- Pouvez-vous tester cette approche en parallele de votre integration actuelle?
+- Pouvez-vous tester cette approche en parallèle de votre intégration actuelle?
 - Quel serait le meilleur pilote pour vous: une page, une plateforme, une collection, une section?
-- Quels risques voyez-vous dans une migration vers ce modele?
+- Quels risques voyez-vous dans une migration vers ce modèle?
 
 ## Commentaires attendus
 
-Pour nous aider a valider l'approche, merci de repondre avec:
+Pour nous aider à valider l'approche, merci de répondre avec:
 
 - les fichiers que vous utiliseriez;
 - les champs manquants;
@@ -291,15 +320,15 @@ Pour nous aider a valider l'approche, merci de repondre avec:
 - les contraintes de performance ou cache;
 - les impacts sur votre architecture;
 - les risques de migration;
-- une estimation du travail cote site.
+- une estimation du travail côté site.
 
-## Decision recherchee
+## Décision recherchée
 
-Nous voulons confirmer si cette approche JSON peut devenir un contrat stable entre notre systeme de publication et les sites.
+Nous voulons confirmer si cette approche JSON peut devenir un contrat stable entre notre système de publication et les sites.
 
-La decision attendue n'est pas encore "on migre tout". La decision attendue est plutot:
+La décision attendue n'est pas encore "on migre tout". La décision attendue est plutôt:
 
 ```text
-Est-ce que ce modele JSON est techniquement viable pour les sites?
+Est-ce que ce modèle JSON est techniquement viable pour les sites?
-Si oui, quels ajustements sont necessaires avant un pilote?
+Si oui, quels ajustements sont nécessaires avant un pilote?
 ```