## SOURCE: 20 Work/Projects/2026/Boukili/2026-09-10 - Boukili.md Modified: 2026-09-11 15:31 --- 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 l’application et d’absence 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 d’autres é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 d’estimations 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 d’une intervention de l’IBO 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 d’une version Firebase à AWS tout en utilisant plusieurs appareils, dont certains non mis à jour. - Régression Salesforce encore en cours d’investigation, 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 l’acceptation d’une perte de données ou d’une 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 d’Abiba sur les problématiques data et la migration. - Retour sur la régression Salesforce. - Vérification auprès de The Mind et de l’IBO de la possibilité de bloquer le retour vers l’ancienne 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 d’une nouvelle échéance après résolution ou mitigation des blocages. --- ## SOURCE: 20 Work/Meetings/TFO/Produits Numériques (Transversal)/2026-09-11 - Produit Numérique.md Modified: 2026-09-11 15:31 --- type: meeting date: 2026-09-11 source: MeetMic status: inbox duration: 21m meetmic_id: 90081927-2438-4E69-ACC6-544E679F739F --- # Recording ## Résumé - La soumission ne peut pas être sécurisée dans le délai initial, car plusieurs problèmes doivent encore être corrigés et testés correctement. - Les principaux sujets abordés sont la migration des utilisateurs sur UAT, la fiabilité du champ de dernière activité, la migration forcée des utilisateurs multi-appareils et les tests Salesforce. - L’équipe de développement prévoit de terminer les corrections restantes, d’effectuer une régression complète, puis de fournir une version stable. La livraison est envisagée entre le vendredi 18 et le mercredi 23, sous réserve de confirmation. - Les livraisons seront mieux contrôlées afin d’éviter plusieurs versions successives et de permettre à l’équipe de test de planifier ses validations. ## Décisions - Le code sera gelé une fois les problèmes actuellement identifiés corrigés et validés. - Les travaux de phase 2 seront réalisés sur une branche distincte et ne seront pas intégrés à la phase 1 pendant la validation. - Une livraison ne sera effectuée que lorsque l’équipe de développement aura terminé ses tests et confirmé que l’équipe de réception est prête. ## Actions - [ ] Investiguer le problème de migration observé sur UAT et fournir une version stable après un nouveau cycle de tests — Responsable : équipe de développement - [ ] Mettre en place un mécanisme de retry pour fiabiliser la remontée de la dernière activité et examiner un indicateur de visibilité réservé aux tests — Responsable : équipe de développement - [ ] Organiser un échange avec Habiba afin de définir une solution robuste et suffisamment visible pour valider la dernière activité — Responsable : équipes concernées - [ ] Étudier avec l’agence actuelle la possibilité de déconnecter tous les utilisateurs et d’afficher un message d’obligation de mise à jour, notamment via Contentful — Responsable : Amadou et équipe concernée - [ ] Vérifier l’avancement des tests Salesforce avec Nicolas et Mark, puis communiquer une mise à jour — Responsable : équipe concernée - [ ] Confirmer par e-mail les dates de livraison jugées réalistes — Responsable : équipe de développement — Échéance : dans l’après-midi - [ ] Corriger les problèmes restants, effectuer une régression complète et préparer une build stable avant livraison — Responsable : équipe de développement — Échéance : entre le vendredi 18 et le mercredi 23, selon confirmation ## Blocages / Risques - Le temps disponible pour tester est insuffisant pour garantir une version solide avant soumission. - La migration fonctionne sur test/staging mais présente encore un problème non identifié sur UAT. - Le champ de dernière activité n’est pas jugé suffisamment fiable, notamment en cas d’échec réseau. - La stratégie de migration forcée des utilisateurs multi-appareils reste à définir et constitue un point critique pour la soumission. - Les tests Salesforce n’ont pas abouti et un problème de transfert de données entre parties de Salesforce est en cours d’analyse. - L’équipe de développement est en avance sur l’équipe de test, qui dispose encore d’un backlog de tickets à valider. ## À suivre - Confirmer la stratégie retenue pour la migration forcée et la communication aux utilisateurs. - Confirmer la date de livraison et le déclenchement du freeze. - Valider la disponibilité de l’équipe de réception avant chaque livraison. - Suivre les résultats des tests et de la régression complète avant la soumission. --- ## SOURCE: 20 Work/Meetings/Team Meetings/2026/2026-09-10 - Reunion equipe.md Modified: 2026-09-11 15:31 --- type: meeting date: 2026-09-10 source: MeetMic status: inbox duration: 37m meetmic_id: 005E7E46-E0E4-41D6-82ED-4B799F82EF5D --- # Reunion equipe ## Résumé - La réunion a principalement porté sur la préparation de la rencontre avec Francis, prévue mardi 15 à 15 h, dans la salle Gisèle Chrétien. Chaque personne présentera brièvement ses projets, leur état d’avancement, leurs impacts et leurs dépendances. - La présentation des projets a été réorganisée : la documentation départementale sera rattachée à la partie plateforme plutôt qu’aux données, la gouvernance des données sera présentée comme une pratique transversale, et le projet sera nommé « projet Données FMC ». - Les principaux sujets data abordés sont Data Booking V3, Data Hub, Data OTT, l’intégration d’Umami et le monitoring des flux de synchronisation avec Mogador. Umami est encore au stade de mise en place des trackers, tandis que son intégration au Data Warehouse n’est pas prévue pour le prochain trimestre. - L’équipe a discuté de la gestion des demandes SEO, du fonctionnement des tickets Jira et du processus à appliquer pour les fichiers ZIP liés à Idéllo. - Plusieurs livraisons et migrations présentent des enjeux de calendrier, notamment OTT, Boukili et une livraison TFO prévue avant le 16 ou le 17. ## Décisions - La documentation départementale sera présentée dans la partie plateforme, et non dans la partie données. - La gouvernance des données sera présentée comme une pratique continue visant notamment une source de vérité unique dans Power BI, et non comme un projet autonome. - Le projet sera désigné comme « projet Données FMC » plutôt que comme un « nouveau gabarit FMC ». - Pour les fichiers ZIP destinés à Idéllo, chaque cours et chaque fichier ZIP devra faire l’objet d’un ticket Jira distinct. Les demandes ne seront pas traitées depuis des tickets fermés. - Le traitement des demandes liées aux fichiers ZIP d’Idéllo ne commencera pas avant le 12 octobre. - Le Snowflake de JW Player demeure la source de référence pour les données OTT pour le moment. ## Actions - [ ] Préparer la présentation des projets pour la rencontre avec Francis — Responsable : équipe — Échéance : mardi 15 - [ ] Corriger et finaliser le document de présentation, notamment les catégories de projets — Responsable : non précisé — Échéance : avant mardi 15 - [ ] Poursuivre la mise en place des trackers Umami avec le fournisseur — Responsable : Jean-Claude — Échéance : non précisée - [ ] Analyser les flux de synchronisation avec Mogador et mettre en place des alertes en cas d’échec — Responsable : Mohamed Slimane — Échéance : non précisée - [ ] Continuer à renseigner et mettre à jour les tickets Jira avant de commencer le traitement et lors de leur fermeture — Responsable : équipe — Échéance : non précisée - [ ] Créer les tickets Jira nécessaires pour chaque cours et chaque fichier ZIP destiné à Idéllo — Responsable : Jason / demandeurs concernés — Échéance : à partir du 12 octobre - [ ] Recompiler les fichiers ZIP reçus, puis les transmettre à Ellen Chalent pour leur mise en ligne — Responsable : équipe — Échéance : non précisée - [ ] Clarifier avec Julie et Carole le calendrier de livraison et de validation d’OTT — Responsable : non précisé — Échéance : non précisée - [ ] Effectuer des tests de régression ciblés sur la livraison TFO liée au live et au carousel — Responsable : Ajar — Échéance : avant le 16 ou le 17 - [ ] Organiser un échange sur les recommandations de service tracking pour MAMI — Responsable : Rabiba et Amandou — Échéance : non précisée ## Blocages / Risques - La livraison OTT risque de ne pas être prête à temps en raison de régressions constatées. Une livraison le week-end pourrait être nécessaire pour viser la mise en ligne avant le 14 septembre, en vue de l’émission live du 17. - La migration de Boukili pourrait nécessiter deux pipelines de données en parallèle, pour Firestore et AWS, ainsi qu’une logique de fusion et de déduplication. - Les utilisateurs disposant de plusieurs devices risquent de perdre leur progression si certains devices continuent d’écrire dans Firestore après la migration. Une réponse de l’équipe concernée est attendue. - La capacité QA constitue un goulot d’étranglement, une seule personne étant affectée à quatre sites. Un QA permanent supplémentaire ou un renfort ponctuel sont envisagés. - Les absences prochaines d’Ajar, Jean-Claude et Joël pourraient ralentir l’équipe pendant quelques jours. - L’investissement à long terme dans OTT et JW Player reste incertain, le contrat JW Player arrivant à échéance dans un an. ## À suivre - Tenir la rencontre avec Francis et recueillir ses éventuelles questions sur les projets, les priorités et les besoins QA. - Suivre la réponse du fournisseur concernant les régressions et le calendrier de livraison OTT. - Clarifier le scénario de migration multi-device de Boukili avec Carole et l’équipe concernée. - Suivre l’analyse du document FMC et les éléments pouvant être automatisés. - Suivre l’intégration future des données Umami au Data Warehouse. - Contrôler la mise en œuvre systématique du processus de tickets Jira pour Idéllo à partir du 12 octobre. --- ## SOURCE: 20 Work/Projects/2026/OTT/2026-09-10 - Direct ONFR - Réponse sur le feed de JWP.md Modified: 2026-09-11 15:36 --- 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 l’adresse 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 d’envoi 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 l’ingest point et transmettre l’URL à Corus — Responsable : non précisé - [ ] Contacter Corus, notamment Chris Sandinot, pour modifier l’adresse 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 n’est pas clarifiée : elle dépendrait soit de l’existence de l’adresse, soit de l’utilisation 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 d’envoi du deuxième feed et la présence des sous-titrages dans l’enregistrement. ---