diff --git a/.obsidian/plugins/templater-obsidian/data.json b/.obsidian/plugins/templater-obsidian/data.json index 6a8645c..05d8cdb 100644 --- a/.obsidian/plugins/templater-obsidian/data.json +++ b/.obsidian/plugins/templater-obsidian/data.json @@ -20,6 +20,18 @@ { "folder": "20 Work/Decisions/2026", "template": "10 Knowledge/Templates/Decision Template.md" + }, + { + "folder": "20 Work/Decisions", + "template": "10 Knowledge/Templates/Decision Template.md" + }, + { + "folder": "20 Work/Journal", + "template": "10 Knowledge/Templates/Journal Template.md" + }, + { + "folder": "20 Work/Weekly Review", + "template": "10 Knowledge/Templates/Weekly Review Template.md" } ], "file_templates": [], diff --git a/10 Knowledge/Templates/Decision Template.md b/10 Knowledge/Templates/Decision Template.md index b490850..2c1387b 100644 --- a/10 Knowledge/Templates/Decision Template.md +++ b/10 Knowledge/Templates/Decision Template.md @@ -1,3 +1,8 @@ +--- +date: <% tp.date.now("YYYY-MM-DD") %> +status: proposed +owner: Amadou +--- <%* const date = tp.date.now("YYYY-MM-DD"); @@ -26,10 +31,6 @@ await tp.file.move( ); -%> -**Date:** <% date %> -**Status:** 🟡 Proposed -**Owner:** - > 🟡 **Proposed** · 🟢 **Decided** · 🔴 **Rejected** · ⚫ **Superseded** ## Context @@ -38,11 +39,11 @@ await tp.file.move( ## Options Considered *(optional)* -- **Option 1:** +- **Option 1** - Pros: - Cons: -- **Option 2:** +- **Option 2** - Pros: - Cons: @@ -50,12 +51,12 @@ await tp.file.move( ## Why -- +- ## Consequences -- +- ## Related -- [[]] +- [[]] \ No newline at end of file diff --git a/20 Work/Decisions/2026/2026-08-13 - Proposition synchro v2.md b/20 Work/Decisions/2026/2026-08-13 - Proposition synchro v2.md new file mode 100644 index 0000000..5ad21f3 --- /dev/null +++ b/20 Work/Decisions/2026/2026-08-13 - Proposition synchro v2.md @@ -0,0 +1,50 @@ +--- +date: 2026-08-13 +status: proposed +owner: Amadou +--- + + +> 🟡 **Proposed** · 🟢 **Decided** · 🔴 **Rejected** · ⚫ **Superseded** + +## Context + +L'architecture actuelle Louise/Mogador fonctionne, mais devient de plus en plus complexe à maintenir et à faire évoluer. + +La synchronisation repose aujourd'hui sur plusieurs serveurs, Directus porte plusieurs responsabilités et le système offre peu d'observabilité proactive. + +Une nouvelle approche permettrait de simplifier progressivement la chaîne de publication sans remplacer l'existant en une seule étape. + +## Options Considered _(optional)_ + +- **Option 1 : Continuer à faire évoluer l'architecture actuelle** + - Pros : moins de changement à court terme + - Cons : conserve la complexité et les limitations actuelles +- **Option 2 : Construire progressivement un Content Publication Engine interne** + - Pros : meilleure séparation des responsabilités, observabilité, publication atomique et architecture plus facile à faire évoluer + - Cons : effort de développement et migration progressive des consommateurs + +## Decision + +Proposer la construction progressive d'un **Content Publication Engine interne**, en parallèle de l'architecture actuelle, avec un premier pilote avant toute migration complète. + +La décision finale reste à valider avec le Team Lead et le CTO. + +## Why + +- Réduire la complexité de l'architecture actuelle +- Améliorer l'observabilité et le diagnostic des problèmes +- Découpler progressivement les sites de Directus +- Permettre des publications validées et des rollbacks +- Préparer l'architecture pour une future évolution de Louise/Mogador +- Éviter une migration « big bang » + +## Consequences + +- Directus reste en place pendant la transition +- L'approche doit être validée avec le Team Lead et le CTO avant de devenir un projet +- Habiba doit être impliquée dans la définition des validations et de la data lineage +- Les fournisseurs seront consultés sur la viabilité du modèle de publication JSON avant de figer le contrat + +## Related +[[Proposition d'architecture Sync Mogador v2]]