vault backup: 2026-09-17 22:26:18

2026-09-17 22:26:18 -04:00
parent 157d28dec4
commit 65fd81dfbc
5 changed files with 1709 additions and 1781 deletions
@@ -45,7 +45,11 @@ SORT file.name ASC

 Feedback given, coaching moments, observations.

- 
+- Feedback du CTO : je n'ai pas encore suffisamment de leaders autonomes dans mon équipe sur lesquels je peux m'appuyer.
+- Je suis trop souvent invité ou impliqué dans leurs rencontres et je finis par intervenir directement dans leurs problèmes.
+- Exemple OTT/Search : l'owner aurait dû challenger le fournisseur, investiguer les options et lever le risque lui-même. Mon intervention aurait dû arriver seulement au moment où une escalade de gestion était nécessaire.
+- Le problème n'est donc pas seulement ce que fait mon équipe : **mon propre comportement peut entretenir leur dépendance envers moi**.
+- Mon rôle doit davantage devenir : définir les attentes, donner l'ownership, demander des comptes, arbitrer et coacher — plutôt que résoudre.

 ---

@@ -53,7 +57,9 @@ Feedback given, coaching moments, observations.

 Important project changes only.

- 
+- Constat portefeuille : **13 projets actifs + 9 à venir**.
+- Ce volume ne permet pas une planification crédible avec la capacité actuelle.
+- Besoin de revoir les priorités, les échéanciers et ce qui doit réellement rester actif.

 ---

@@ -61,15 +67,24 @@ Important project changes only.

 ### What surprised me today?

- 
+- Le feedback sur le manque de leaders dans mon équipe était plus profond que simplement « ils doivent prendre plus d'initiative ».
+- Je contribue moi-même au problème lorsque je participe à leurs rencontres, réponds aux problèmes trop rapidement ou prends le relais lorsqu'une situation devient difficile.

 ### What did I learn today?

- 
+- Déléguer un projet ne veut pas seulement dire donner les tâches. Il faut aussi laisser à la personne la responsabilité d'investiguer, de proposer des solutions, de gérer les intervenants et de lever les risques.
+- Être capable de résoudre un problème rapidement ne veut pas dire que je dois le résoudre.
+- Avoir de la visibilité sur un projet ne nécessite pas nécessairement d'être présent dans ses rencontres.
+- La planification doit partir de la capacité disponible, pas de la liste des demandes.
+- Je dois accepter qu'un projet puisse être reporté ou refusé plutôt que de surcharger constamment l'équipe.

 ### What would I do differently next time?

- 
+- Avant d'entrer dans une rencontre ou de répondre à un problème, me demander : **« Est-ce réellement à moi d'intervenir? »**
+- Lorsqu'un employé m'apporte un problème, éviter de donner immédiatement la solution même lorsque je la connais.
+- Demander plutôt : **Qu'as-tu vérifié? Quelle est ton hypothèse? Qu'est-ce que tu proposes? De quoi as-tu besoin de moi?**
+- Être beaucoup plus ferme sur les priorités et les échéanciers.
+- Ne pas confondre soutien à mon équipe et prise en charge de leur travail.

 ---

@@ -78,7 +93,11 @@ Important project changes only.
 > Only actions that still belong to me.
 > Everything else should already be in **Twos**, **Jira**, or **Monday**.

- [ ]
+ - Construire mon **90-day management reset**.
+- [ ]  Revoir les 13 projets actifs et déterminer lesquels doivent réellement rester actifs.
+- [ ]  Revoir les 9 projets à venir et identifier ce qui doit être reporté/refusé.
+- [ ]  Définir clairement mes nouvelles règles d'escalade et d'ownership avec l'équipe.
+- [ ]  Revoir la situation Jira/SLA pour comprendre pourquoi l'équipe n'arrive pas à maintenir les opérations en parallèle des projets.

 ---

@@ -1,30 +0,0 @@
---
-type: meeting
-date: 2026-09-15
-source: MeetMic
-status: inbox
-duration: 1m
-meetmic_id: 747BAA3D-05B7-4B74-A22C-D75782052F3B
---
-
-# Recording
-
-## Résumé
- Une anomalie a été constatée sur le projet Single Power concernant la synchronisation ONFR.
- La synchronisation, prévue toutes les 2 h 40, semble se répéter toutes les 2 h ; l’expression de Cron doit être vérifiée.
- Une absence de 4 heures est prévue mardi prochain pour un rendez-vous personnel.
- Il est prévu de compenser cette absence en ajoutant une heure de travail cette semaine à chaque fois concernée.
-
-## Décisions
- L’absence de 4 heures mardi prochain est acceptée.
- La compensation par l’ajout d’une heure de travail cette semaine est retenue.
-
-## Actions
- [ ] Examiner l’anomalie de synchronisation ONFR et vérifier l’expression de Cron — Responsable : non identifié
- [ ] Ajouter une heure de travail cette semaine pour compenser l’absence — Responsable : non identifié
-
-## Blocages / Risques
- Le comportement actuel de la synchronisation ONFR ne correspond pas à la fréquence attendue de 2 h 40.
-
-## À suivre
- Confirmer la cause et la résolution de l’anomalie de synchronisation ONFR.
@@ -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.