vault backup: 2026-09-17 22:49:46

2026-09-17 22:49:46 -04:00
parent 65fd81dfbc
commit 6928fe1901
4 changed files with 2778 additions and 0 deletions
@@ -0,0 +1,46 @@
+---
+type: meeting
+date: 2026-09-17
+source: MeetMic
+status: inbox
+duration: 43m
+meetmic_id: A36365F2-7829-465C-B505-B7D9E847CFCB
+---
+
+# Daily Meeting | TFO x ZEMIND
+
+## Résumé
+
+- La réunion a clarifié la distinction entre les approches « soft » et « radicale » pour la migration de Boukili vers la V3.
+- L’approche soft permettrait encore l’accès à Firebase, avec un risque de données présentes dans deux bases sans synchronisation.
+- L’approche radicale vise à éviter ce décalage en déconnectant les utilisateurs et en bloquant l’accès à Firebase lors du lancement de la V3.
+- Une perte d’utilisateurs et une baisse temporaire des chiffres sont considérées comme inévitables et comme un risque assumé.
+- La migration au moment de la reconnexion et une éventuelle migration forcée ultérieure restent à préciser, notamment pour la planification du pipeline de données.
+
+## Décisions
+
+- Retenir l’approche radicale plutôt que l’approche soft ou un fonctionnement mixte.
+- Déconnecter les utilisateurs et couper les accès à Firebase au lancement de la nouvelle application.
+- Préparer la solution avant le lancement, puis l’activer le jour même.
+- Ne pas s’appuyer sur une période de 90 jours pour cette approche.
+
+## Actions
+
+- [ ] Organiser une rencontre avec Catherine et l’IBO afin d’aligner les terminologies et de confirmer la solution — Responsable : Abdoulah
+- [ ] Confirmer avec l’IBO le délai de mise en œuvre et la date possible d’activation — Responsable : non précisé
+- [ ] Informer Zemind de la solution et du calendrier après confirmation de l’IBO — Responsable : non précisé
+- [ ] Préparer le pipeline de données pour la migration forcée en masse — Responsable : non précisé
+
+## Blocages / Risques
+
+- Risque de perte d’utilisateurs qui ne se reconnecteront pas après la déconnexion.
+- Risque de baisse temporaire des chiffres après la migration.
+- Les utilisateurs ayant désactivé les mises à jour automatiques pourraient ne pas effectuer rapidement la mise à jour.
+- Le moment exact et le fonctionnement de la migration forcée restent incertains.
+- La migration forcée pourrait nécessiter une gestion spécifique des utilisateurs qui ne se sont pas encore reconnectés.
+
+## À suivre
+
+- Clarifier avec l’IBO le calendrier exact, la durée de mise en place et les modalités techniques de la déconnexion.
+- Déterminer quand et comment sera déclenchée la migration forcée des utilisateurs restants.
+- Valider avec Zemind le scénario retenu et ses impacts sur le pipeline de données.
@@ -0,0 +1,42 @@
+---
+type: meeting
+date: 2026-09-18
+source: MeetMic
+status: inbox
+duration: 45m
+meetmic_id: 35A86DB2-3415-4D78-9C3B-3F1EC14FB1E3
+---
+
+# Recording
+
+## Résumé
+- Le lien actuel de rediffusion sera remplacé par le VOD de la programmation principale demain ; il ne doit donc pas être partagé sur les médias sociaux.
+- Un problème de synchronisation existe entre Mogador, Directus et le site : le produit peut ne pas être disponible dans Directus le jour du live, ce qui empêche l’automatisation de l’ajout du Video ID et du Video Extra.
+- La gestion des liens et de la mise en avant du produit sera faite manuellement pendant les prochaines semaines, en attendant une solution automatisée.
+- Le live event peut être déclenché manuellement avant l’heure prévue, mais il ne peut pas commencer plus tard que l’heure programmée. L’heure de fin peut être prolongée avant le début de l’enregistrement, mais pas après.
+- Des ajustements techniques ont été réalisés sur le produit testé : synchronisation, cache, image, titre et mise en avant. La vidéo et les podcasts ont été vérifiés.
+
+## Décisions
+- Ne pas partager le lien temporaire de rediffusion sur les médias sociaux.
+- Utiliser à terme le lien Directus de type embed plutôt que le lien de rediffusion.
+- Effectuer manuellement la mise à jour et la mise en avant des produits pendant les prochaines semaines.
+- Conserver la logique du script lorsque le produit existe dans Directus le jour du live, avec remplacement automatique par la version du lendemain.
+
+## Actions
+- [ ] Prendre une capture d’écran du glitch observé et l’envoyer — Échéance : demain
+- [ ] Gérer manuellement les liens et la mise en avant des produits pendant les prochaines semaines — Responsable : Slimane et équipe
+- [ ] Vérifier avec Joël comment rendre le produit disponible dans Directus le jour même du live — Responsable : non identifié
+- [ ] Automatiser à nouveau l’écriture du Video ID et du Video Extra dans Directus lorsque le produit est disponible le jour du live — Responsable : non identifié
+- [ ] Reproduire les ajustements techniques réalisés pour le prochain live — Échéance : la semaine prochaine
+
+## Blocages / Risques
+- Le produit n’est normalement synchronisé dans Directus que le lendemain lorsqu’il est programmé pour le jour même, ce qui bloque le script et empêche de fournir le bon lien à temps.
+- Le lien de rediffusion change le lendemain, créant un risque si celui-ci est partagé dans les médias sociaux.
+- Un démarrage tardif du live ne peut pas être corrigé après l’heure programmée ; une émission plus longue ne peut pas être prolongée une fois l’enregistrement commencé.
+- Le début du live peut être difficile à déterminer lorsque la régie, notamment Corus, commence plus tôt ou lorsque le signal est précédé d’une annonce ou d’un fade-in.
+
+## À suivre
+- Clarifier avec Joël le fonctionnement attendu de la programmation et de la synchronisation dans Directus.
+- Définir une communication fiable de l’heure réelle de début du live.
+- Finaliser l’automatisation afin d’éviter le recours manuel aux liens et aux mises à jour.
+- Vérifier la cause du problème d’image et de qualité du signal observé pendant le live.