vault backup: 2026-09-17 22:49:46
This commit is contained in:
@@ -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.
|
||||
Reference in New Issue
Block a user