vault backup: 2026-09-17 22:26:18
This commit is contained in:
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
type: meeting
|
||||
date: 2026-09-17
|
||||
source: MeetMic
|
||||
status: inbox
|
||||
duration: 25m
|
||||
meetmic_id: 5EF218C8-EA84-4686-B23B-4050707D5344
|
||||
---
|
||||
|
||||
# Boukili: Transition de la nouvelle application
|
||||
|
||||
## Résumé
|
||||
- La réunion porte sur la migration de Bookili de la V2 vers la V3, avec l’utilisation du même identifiant sur l’App Store et le Play Store.
|
||||
- Deux stratégies de gestion des anciennes versions ont été discutées : déconnexion forcée suivie d’une mise à jour, ou blocage de l’accès côté serveur/Firebase.
|
||||
- La solution radicale règle davantage de cas, mais dépend d’une communication claire pour éviter que les utilisateurs pensent que leur compte n’existe plus. La solution progressive est plus conviviale, mais laisse subsister le risque de reconnexion à l’ancienne version.
|
||||
- Des risques persistent liés aux délais de mise à jour des appareils, aux utilisateurs dont les mises à jour automatiques sont désactivées, à la communication auprès des conseils scolaires et à la réconciliation des données.
|
||||
- Aucun consensus définitif n’a été établi entre les options soft, radicale ou une combinaison avec un délai de 90 jours.
|
||||
|
||||
## Décisions
|
||||
- Attendre un alignement interne sur la stratégie avant d’en discuter avec les intervenants externes.
|
||||
- La date de déploiement sera pilotée par l’équipe, puis synchronisée avec Zemind lorsque la timeline sera connue.
|
||||
|
||||
## Actions
|
||||
- [ ] Aligner les parties prenantes sur le choix entre la solution soft, la solution radicale et une combinaison avec un délai de 90 jours.
|
||||
- [ ] Recueillir l’avis de Julie et d’Abiba sur les options techniques et leurs impacts.
|
||||
- [ ] Clarifier avec l’IBO le fonctionnement exact de la déconnexion, du blocage côté Firebase et des notifications.
|
||||
- [ ] Recontacter Zemind pour synchroniser le jour J une fois la stratégie et la timeline confirmées.
|
||||
|
||||
## Blocages / Risques
|
||||
- L’auto-update ne garantit pas que tous les utilisateurs passeront à la V3.
|
||||
- Après une simple déconnexion, certains utilisateurs pourraient se reconnecter à la V2.
|
||||
- Le blocage côté serveur/Firebase peut empêcher l’accès sans communication préalable suffisamment claire.
|
||||
- Les mises à jour peuvent être déployées à des moments différents selon les appareils et les stores.
|
||||
- La communication doit atteindre les utilisateurs, les conseils scolaires et potentiellement leurs équipes IT.
|
||||
- La création ou l’utilisation de comptes distincts pourrait entraîner des problèmes de réconciliation des données.
|
||||
|
||||
## À suivre
|
||||
- Choix final de la stratégie de migration et du délai éventuel avant le blocage définitif.
|
||||
- Validation technique de l’IBO et clarification de la distinction entre déconnexion et blocage d’accès.
|
||||
- Préparation de la communication et détermination du canal approprié : notification via la cloche ou pop-up.
|
||||
- Évaluation des impacts sur les données et sur les utilisateurs avec l’avis d’Abiba.
|
||||
Reference in New Issue
Block a user