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

vault backup: 2026-08-01 17:07:09

Browse Source
This commit is contained in:
amadou
2026-08-01 17:07:09 -04:00
parent 006017c6b2
commit 18c4587d69
3 changed files with 276 additions and 88 deletions
Download Patch File Download Diff File Expand all files Collapse all files
20 Work/Ideas/Mogador/Proposition d'architecture - Content Publication Engine.md
+176 -13
View File
@@ -234,7 +234,7 @@ Ce chantier a une relation directe avec la synchro interne, mais il ne doit pas
```mermaid
flowchart TD
Louise["LouiseSysteme source editorial"]
Louise["LouiseSystème source éditorial"]
LouiseExport["Louise ExportSQL complet toutes les 3h"]
Importer["Import SQL interneBase source locale"]
Toolkit["Mogador ToolkitAPI legacy actuelle"]
@@ -244,8 +244,12 @@ flowchart TD
Diff["Diff Builderfabrique l'incrémentiel interne"]
MediaPipeline["Media PipelineAdonisJS/JWP"]
JWP["JWPplateforme video"]
MediaAssets["media_assetsétat media interne"]
JWP["JWPplateforme vidéo"]
MediaAssets["media_assetsétat média interne"]
AssetPipeline["Asset Pipelineimages + transcriptions"]
S3Assets["S3 Assetsoriginaux optimisés"]
ImageLayer["Image Transformation Layerresize/crop/cache"]
Console["Publication Consolemini CMS interne"]
Overrides["overridescorrections d'urgence"]
@@ -255,7 +259,7 @@ flowchart TD
Validator["Validation + rapportsattendu vs publié"]
Runs["Published Content Feedruns JSON immuables"]
Manifest["manifest.jsonpointe vers le run actif"]
Bucket["Bucket/CDNexposition publique contrôlee"]
Bucket["Bucket/CDNexposition publique contrôlée"]
Sites["Sites webTFO / IDELLO / ONFR / linéaire"]
Alerts["Slack / Better Stackalertes anomalies"]
@@ -274,6 +278,12 @@ flowchart TD
MediaPipeline --> MediaAssets
MediaPipeline --> Jobs
Snapshot --> AssetPipeline
AssetPipeline --> S3Assets
S3Assets --> ImageLayer
AssetPipeline --> Jobs
ImageLayer --> Engine
Console --> Overrides
Console --> Jobs
@@ -290,7 +300,49 @@ flowchart TD
Bucket --> Sites
```
Ce schema représente ce qu'on contrôle nous-mêmes. Il ne depend pas d'une API Louise/Mogador v2.
Ce schéma représente ce qu'on contrôle nous-mêmes. Il ne dépend pas d'une API Louise/Mogador v2.
## Services autour du CPE
L'architecture cible doit être vue comme un ensemble de services spécialisés autour du Content Publication Engine.
La règle principale:
> Chaque service est responsable de son domaine, mais seul le CPE décide ce qui est publié aux sites.
Services proposés:
```text
Import Service
Responsable de recevoir/importer le Louise Export SQL dans MySQL.
Produit un statut d'import lisible par le CPE.
Source Reader
Responsable de lire les données officielles via Mogador Toolkit aujourd'hui,
puis potentiellement via Louise API v2 plus tard.
Asset Pipeline
Responsable des images, transcriptions, audio et autres fichiers vers S3.
Optimise les originaux quand nécessaire, par exemple via tinyjpg.
Image Transformation Layer
Responsable du redimensionnement/crop/cache des images à la demande.
Remplace la capacité de resize on the fly qui était utile dans Directus.
Media Pipeline
Responsable des vidéos JWP et de l'état média dans `media_assets`.
Publication Console
Responsable des corrections d'urgence, overrides, audit et rollback interne.
Content Publication Engine
Responsable de valider, assembler, générer et publier les JSON.
Published Content Feed
Responsable de servir les JSON versionnés via bucket/CDN.
```
Le CPE ne doit pas faire l'import SQL, transcoder les vidéos, redimensionner les images ou devenir un CMS complet. Il orchestre la publication à partir des états produits par les autres services.
### Chantier B: évolution PCI
@@ -312,7 +364,7 @@ flowchart TD
Events -.declenche une relecture officielle.-> InternalReader
```
Ce deuxieme schema est un projet avec PCI. Il peut ameliorer fortement la vitesse et la fiabilite, mais il doit rester interchangeable.
Ce deuxième schéma est un projet avec PCI. Il peut améliorer fortement la vitesse et la fiabilité, mais il doit rester interchangeable.
Le `Content Publication Engine` devrait avoir un `Source Reader` abstrait:
@@ -342,7 +394,7 @@ Le reste du système interne ne devrait pas changer:
3. Le Mogador Toolkit expose les données officielles.
4. Le Snapshot Collector lit les données officielles.
5. Le Diff Builder compare le snapshot courant au snapshot précédent.
6. Le Media Pipeline gère JWP et écrit l'état media dans `media_assets`.
6. Le Media Pipeline gère JWP et écrit l'état média dans `media_assets`.
7. La Publication Console gère les corrections d'urgence et écrit les overrides.
8. Les changements créent des `publication_jobs`.
9. Le Content Publication Engine combine données officielles, media, overrides et règles métier.
@@ -750,6 +802,117 @@ Contient le détail d'un produit.
}
```
## Images et resize on the fly
Un avantage important de Directus est sa capacité à redimensionner les images à la demande. Si Directus est retiré ou réduit, cette capacité doit être remplacée explicitement.
Certaines images sources peuvent être très grandes, parfois en format 4K. Le service tinyjpg peut continuer à optimiser le poids des originaux avant stockage dans S3, mais cela ne remplace pas le besoin des sites d'obtenir plusieurs tailles et ratios selon les pages.
Recommandation:
```text
S3 originaux optimisés
-> Image Transformation Layer
-> CDN cache les rendus
-> sites consomment les URLs d'images transformées
```
Options recommandées, dans l'ordre:
1. **Solution AWS/CloudFront de transformation d'images**
C'est l'option à privilégier si l'infrastructure est déjà orientée AWS/S3/CloudFront.
Avantages:
- reste dans l'écosystème AWS;
- S3 peut rester privé;
- CloudFront sert les images;
- les transformations peuvent être contrôlées par presets;
- le cache CDN absorbe la charge;
- moins de service applicatif public à opérer;
- plus facile à faire accepter par l'infrastructure.
2. **imgproxy derrière CloudFront**
Option technique solide si la solution AWS ne répond pas au besoin.
Avantages:
- service spécialisé pour resize/crop/format;
- URLs signées possibles;
- fonctionne bien avec S3/CDN;
- évite de pré-générer trop de variantes.
Point de vigilance: cela ajoute un service à opérer, patcher, surveiller et sécuriser.
3. **Cloudflare Images / Transformations**
Option intéressante techniquement si Cloudflare est déjà accepté dans l'infrastructure web.
Avantages:
- resize/optimisation à la demande;
- cache global;
- peu d'opération applicative interne.
Point de vigilance: si l'organisation veut rester principalement AWS/S3/CloudFront, cette option risque d'être moins acceptable.
La recommandation pragmatique est donc:
```text
Choix 1: AWS/CloudFront Image Transformation
Choix 2: imgproxy derrière CloudFront
Choix 3: Cloudflare Images/Transformations
```
Cela évite de mettre du traitement image dans le CPE et évite aussi de pré-générer trop de variantes.
Le CPE ne devrait pas redimensionner les images lui-même. Il devrait seulement publier les informations nécessaires:
```json
{
"images": [
{
"type": "thumbnail",
"source_url": "https://assets.example.com/originals/abc.jpg",
"alt": "Description de l'image",
"transform": {
"base_url": "https://images.example.com",
"presets": {
"card": "w=400,h=225,fit=cover",
"hero": "w=1600,h=900,fit=cover",
"poster": "w=600,h=900,fit=cover"
}
}
}
]
}
```
Les sites peuvent ensuite utiliser les presets documentés, ou recevoir directement des URLs prêtes à l'emploi si on veut limiter la logique côté site.
Point important: il faut décider si les sites construisent les URLs de transformation ou si le CPE publie des URLs déjà construites. Pour réduire les risques d'intégration, la v1 devrait probablement publier des URLs prêtes à l'emploi pour les principaux usages:
```json
{
"images": [
{
"type": "thumbnail",
"alt": "Description de l'image",
"variants": {
"card": "https://images.example.com/tfo/card/abc.jpg",
"hero": "https://images.example.com/tfo/hero/abc.jpg",
"poster": "https://images.example.com/tfo/poster/abc.jpg",
"original": "https://assets.example.com/originals/abc.jpg"
}
}
]
}
```
Cela garde la flexibilité du resize on the fly, tout en donnant aux sites un contrat simple.
### collections/{biznumber}/full.json
Contient le modèle attendu par les sites.
@@ -859,7 +1022,7 @@ Principe:
Si la génération du run `20260730-1200` échoue, `manifest.json` continue de pointer vers `20260730-0900`. Une sync ratée ne casse pas le site.
Cette règle s'applique aussi aux corrections rapides: si une correction d'urgence ou une republication media échoue, le manifest reste sur le dernier run valide.
Cette règle s'applique aussi aux corrections rapides: si une correction d'urgence ou une republication média échoue, le manifest reste sur le dernier run valide.
Retention proposée:
@@ -1103,7 +1266,7 @@ Tout ce qui dépasse ce périmètre doit être questionné avant d'être ajouté
### Table `media_assets`
Cette table représente l'état media interne d'un produit.
Cette table représente l'état média interne d'un produit.
Champs proposés:
@@ -1258,7 +1421,7 @@ Produits publiés: 8139
Ecarts:
- 1 programme absent du JSON final
- 2 produits sans video JWP
- 2 produits sans vidéo JWP
- 5 images manquantes
- 1 produit ignoré car type extrait
@@ -1278,7 +1441,7 @@ Alertes à mettre en place:
- sync trop longue;
- écart entre attendu et publié;
- programme prévu à 6h absent de la publication avant 6h;
- video JWP manquante;
- vidéo JWP manquante;
- image ou transcription manquante;
- override actif proche expiration.
@@ -1522,7 +1685,7 @@ Avec cette séparation, le Media Pipeline peut évoluer indépendamment. La nouv
```text
Louise
Systeme source editorial.
Système source éditorial.
Louise Export
Export SQL complet génère par Louise.
@@ -1537,7 +1700,7 @@ Content Publication Engine
Notre moteur interne qui génère les JSON publics.
Media Pipeline
Notre service interne qui gère JWP et l'état media.
Notre service interne qui gère JWP et l'état média.
Publication Console
Mini CMS interne pour édimestres/admins et overrides.