vault backup: 2026-09-11 15:49:16

This commit is contained in:
2026-09-11 15:49:16 -04:00
parent 55a9be9c4c
commit 48f5f29182
13 changed files with 478 additions and 0 deletions
@@ -0,0 +1,41 @@
---
type: meeting
date: 2026-09-10
source: MeetMic
status: inbox
duration: 21m
meetmic_id: 0D6EED25-BB8C-4366-BC07-819F4DABDB7C
---
# Recording
## Résumé
- La migration de Firebase vers AWS présente un risque important pour les utilisateurs connectés sur plusieurs appareils, notamment en cas de versions différentes de lapplication et dabsence de synchronisation des progrès.
- Des incertitudes persistent sur la fiabilité de la migration des données, ainsi que sur une régression liée à Salesforce et sur dautres éléments data nécessitant une expertise technique.
- Les livraisons fréquentes et non alignées avec le rythme de test prévu entraînent une surcharge, des tests répétés et un manque de visibilité sur l’état réel de la version.
- L’équipe doit clarifier les points bloquants, les solutions possibles et les estimations avant de définir une nouvelle date de mise en production.
## Décisions
- La mise en production prévue lundi est annulée.
- Aucune nouvelle date de déploiement ne sera fixée avant clarification des blocages, évaluation des solutions et obtention destimations fiables.
## Actions
- [ ] Organiser un point technique avec Abiba pour clarifier les problèmes liés à la data et les points critiques — Échéance : demain matin
- [ ] Préparer un email détaillant les blocages critiques et le soumettre à l’équipe pour validation avant envoi — Responsable : non identifié
- [ ] Évaluer avec The Mind la faisabilité, le coût et le délai dune intervention de lIBO sur la migration — Échéance : à partir du point prévu demain
- [ ] Informer Mohamed des raisons du report après clarification avec Abiba — Responsable : non identifié
- [ ] Obtenir des estimations sur la durée nécessaire pour résoudre les problèmes restants — Responsable : The Mind
## Blocages / Risques
- Risque de perte ou de non-synchronisation des données pour les utilisateurs passant dune version Firebase à AWS tout en utilisant plusieurs appareils, dont certains non mis à jour.
- Régression Salesforce encore en cours dinvestigation, sans retour disponible au moment de la réunion.
- Fiabilité de la migration des données non confirmée à 100 %.
- Les solutions actuellement suggérées, notamment lacceptation dune perte de données ou dune fiabilité insuffisante, ne sont pas acceptables.
- Le rythme des livraisons perturbe les tests et empêche de disposer du recul nécessaire pour estimer les délais.
## À suivre
- Retour dAbiba sur les problématiques data et la migration.
- Retour sur la régression Salesforce.
- Vérification auprès de The Mind et de lIBO de la possibilité de bloquer le retour vers lancienne version ou de forcer la mise à jour.
- Clarification du traitement des utilisateurs qui se reconnecteront après la période de 90 jours.
- Définition dune nouvelle échéance après résolution ou mitigation des blocages.
@@ -0,0 +1,40 @@
---
type: meeting
date: 2026-09-10
source: MeetMic
status: inbox
duration: 17m
meetmic_id: B6A3C0A2-EC0E-4373-A44E-313D8AE6B832
---
# Daily Meeting TFO vs Zemind
## Résumé
- Une nouvelle build dédiée au test de la migration des données doit être envoyée après validation QA, suivie dune build complète prévue le lendemain, considérée comme release candidate.
- Quatre sujets techniques restent à arbitrer : retry de suivi de la dernière activité, Firebase auth lockout, message demandant la mise à jour des appareils et contrôle de version dans Contentful.
- Le Firebase auth lockout pourrait être ajouté côté backend avant le go live, mais sa faisabilité nest estimée qu’à 95 %. Sans lockout, les appareils non mis à jour resteraient utilisables, mais la progression ne serait pas synchronisée.
- L’équipe a vérifié le fonctionnement attendu de lenvironnement web de production, du bucket S3 de livraison et de la preview distribution. Un déploiement réel doit encore valider ce workflow.
- Le déploiement de production doit notamment permettre de tester la fonctionnalité de réinitialisation du mot de passe. Abdullah a également demandé un accès à Firebase app distribution pour tester sur Android.
## Décisions
Aucune.
## Actions
- [ ] Envoyer la liste des quatre sujets nécessitant une décision — Échéance : rapidement, avant la prochaine build
- [ ] Donner un retour sur les sujets à implémenter afin de permettre leur intégration dans la build suivante — Échéance : fin de journée
- [ ] Vérifier la configuration du pipeline, pousser la build web vers la branche principale et tester le déploiement via le bucket S3 — Échéance : après la réunion
- [ ] Déployer une build de production pour valider le workflow et tester la réinitialisation du mot de passe — Échéance : fin de journée
- [ ] Ajouter Abdullah à Firebase app distribution pour les tests Android
## Blocages / Risques
- Le délai restant est limité à environ un jour et demi ; limplémentation et la validation des quatre sujets pourraient empêcher le traitement de certains bugs P3 ou P4.
- Le fonctionnement du système de version existant dans Contentful ne peut pas être vérifié actuellement.
- Le Firebase auth lockout nest pas encore confirmé avec certitude.
- Le workflow de déploiement de production et de preview distribution na pas encore été testé avec une vraie build de production.
## À suivre
- Arbitrer les quatre sujets techniques et confirmer ceux à intégrer.
- Valider la build de migration, puis la release candidate prévue le lendemain.
- Confirmer le déploiement web de production et le bon fonctionnement du workflow.
- Décider ultérieurement de la gestion du go live après la soumission des applications.
- Poursuivre les échanges et refaire un point le lendemain.
@@ -0,0 +1,38 @@
---
type: meeting
date: 2026-09-10
source: MeetMic
status: inbox
duration: 7m
meetmic_id: 89C10424-0F99-40F7-ACB1-4E67F47447AE
---
# Direct ONFR : Réponse sur le feed de JWP
## Résumé
- Un deuxième feed de Corus, actuellement inutilisé, pourrait être envoyé vers JW Player pour produire des enregistrements incluant les fichiers de sous-titrage en direct.
- Le même ingest point et la même URL seraient utilisés afin de ne pas modifier le flux existant.
- Un test sera réalisé avec Corus et JW Player pour vérifier la réception du feed et des sous-titrages.
- Les ingest points inutilisés doivent être nettoyés; certains ne peuvent toutefois pas être supprimés directement.
- Les informations concernant la facturation restent contradictoires : JW Player indique que ladresse active entraîne des frais, tandis que les données disponibles indiquent que le flux ne serait pas écouté.
## Décisions
- Utiliser le deuxième feed de Corus pour un test denvoi vers JW Player.
- Conserver les deux ingest points de référence indiqués dans le document PDF et demander à JW Player de supprimer ceux qui ne peuvent pas l’être directement.
- Ne pas modifier le flux actuellement en place.
## Actions
- [ ] Confirmer lingest point et transmettre lURL à Corus — Responsable : non précisé
- [ ] Contacter Corus, notamment Chris Sandinot, pour modifier ladresse du deuxième stream — Responsable : non précisé
- [ ] Réaliser le test de réception du feed et des sous-titrages avec Corus et JW Player — Responsable : non précisé
- [ ] Envoyer les adresses des flux « info.org 24-7 » et « info.org événement spécial » dans un format texte facilement copiable — Responsable : non précisé
- [ ] Informer Jean-Claude lorsque la mise en place sera terminée — Responsable : Ravi
- [ ] Envoyer un courriel de mise à jour et corriger le document concerné — Responsable : non précisé
## Blocages / Risques
- La facturation de JW Player nest pas clarifiée : elle dépendrait soit de lexistence de ladresse, soit de lutilisation effective du flux.
- Certains ingest points ne peuvent pas être supprimés malgré une demande de suppression.
## À suivre
- Clarifier les conditions et les frais appliqués par JW Player.
- Vérifier les résultats du test denvoi du deuxième feed et la présence des sous-titrages dans lenregistrement.