amadou/SecondBrain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
amadou
2026-08-01 15:51:54 -04:00
parent e8dddbf25b
commit f95fa35c0d
2 changed files with 411 additions and 318 deletions
Download Patch File Download Diff File Expand all files Collapse all files
20 Work/Ideas/Mogador/Consultation fournisseurs sites- proposition de publication JSON.md
+82 -53
View File
@@ -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 changements cassants seraient publies dans une nouvelle version.
- Les JSON seraient versionnés dans le chemin: `/v1/`, puis éventuellement `/v2/`.
- 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 sites pourraient consommer seulement les fichiers utiles a leurs pages.
- Les fournisseurs pourraient avoir acces uniquement a leur plateforme ou prefixe.
- Les fichiers seraient séparés pour éviter de télécharger un énorme JSON unique.
- Les sites pourraient consommer seulement les fichiers utiles à leurs pages.
- 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 fichier `products/{product_key}.json` contient-il le bon niveau de detail?
- Le modèle `collection -> seasons -> episodes` convient-il à vos pages?
- 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?
- Avez-vous besoin de programmation passee?
- La fenêtre future J+10 est-elle suffisante?
- 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?
Si oui, quels ajustements sont necessaires avant un pilote?
Est-ce que ce modèle JSON est techniquement viable pour les sites?
Si oui, quels ajustements sont nécessaires avant un pilote?
```