vault backup: 2026-09-11 11:07:40

2026-09-11 11:07:40 -04:00
parent 1ea0f3eac2
commit 1e87c0e572
2 changed files with 2786 additions and 0 deletions
@@ -0,0 +1,889 @@
 **[0:00 - 0:03]** Ciao, ciao.
 **[0:19 - 0:30]** Il ne reste que 4 rencontres encore, juste 4.
 **[0:46 - 0:53]** Abiba, je ne sais pas si tu as eu le temps de prendre connaissance des notes Gemini, je suis désolée.
 **[0:53 - 1:00]** C'est beaucoup de questions, j'ai pas pu, malheureusement j'ai joué en blagona, mais pas de soucis.
 **[1:00 - 1:09]** Pas de soucis, on a eu la rencontre avec The Mind, ils nous ont remonté 4 points pour lesquels ils nous ont suggéré des approches, bref.
 **[1:21 - 1:28]** C'est pour le champ Last Activity Ads.
 **[1:28 - 1:39]** En fait, on lui avait demandé, on leur avait demandé au début, tu te rappelles Carole, d'ajouter ce champ là pour pouvoir connaître si un utilisateur est actif sur un certain temps.
 **[1:39 - 1:51]** C'était ça le premier besoin et le besoin essentiel, c'était donc pour la partie data de pouvoir faire de l'ingestion dans le Data Warehouse de façon incrémentale.
 **[1:09 - 1:21]** Et on voulait repasser sur le point qui nous concernait sur la data pour que tu réexpliques la problématique et les derniers échanges qu'on a eu avec un jour, je crois que c'était négatant.
 **[1:51 - 1:52]** Qu'est-ce que ça veut dire ?
 **[1:52 - 2:17]** Au lieu de par exemple, chaque jour, chaque déclenchement de pipeline, je ramène tous les students avec toutes leurs activités, une gamification et tout, et ça se compte par des centaines de plusieurs centaines de milliers de students et quand on multiplie ça par le nombre d'activités qu'ils font, ça va être énormément de données à ingester à chaque fois si on fait un full load.
 **[2:17 - 2:26]** Donc ce qui serait bien, c'est de faire une ingestion incrémentale sur la base du champ Last Activity Ads.
 **[2:26 - 2:39]** Ça veut dire si un student fait une activité, c'est là qu'on le ramène dans le Data Warehouse et on update les activités qu'il a fait, donc les tables feed-in, gamification, etc.
 **[2:39 - 2:48]** Maintenant, on lui avait posé la question : est-ce qu'il y a moyen que ce champ-là ne soit pas mis à jour de façon silencieuse ?
 **[2:48 - 2:54]** Ça veut dire qu'on n'ait aucun moyen de savoir que ce champ-là n'a pas été mis à jour correctement ?
 **[2:54 - 3:08]** Parce que le default dans le statement, c'est la création de la table que Frank m'a communiqué, il est defaulté à une date précise qui est le Now.
 **[3:08 - 3:14]** Donc le Now, ça peut être la date de migration de cet utilisateur, la date du login.
 **[3:14 - 3:33]** Si jamais un student fait une activité quelconque au niveau du compte de cet utilisateur et que la date de cette dernière activité n'est pas remontée dans le champ Last Activity Ads, Moi, j'ai pas moyen d'aller le récupérer.
 **[3:33 - 3:45]** Il sera pas, il remontera pas dans les students que je vais remonter pour aller récupérer dans le Data Warehouse parce que le champ Last Activity Ads n'aura pas changé.
 **[3:45 - 3:47]** Je sais pas si je me suis bien expliqué.
 **[3:47 - 3:49]** J'ai essayé d'être...
 **[3:49 - 3:52]** Je te réponds comme des détails.
 **[3:52 - 3:55]** Je sais pas si je me suis bien expliqué.
 **[3:55 - 4:02]** J'ai essayé de faire un petit peu de décision.
 **[4:02 - 4:04]** Je sais pas si je me suis bien expliqué.
 **[4:04 - 4:07]** J'ai essayé de faire un petit peu de décision.
 **[4:07 - 4:12]** J'ai essayé de faire un petit peu de décision.
 **[4:12 - 4:12]** J'ai essayé de faire un petit peu de décision.
 **[4:12 - 4:14]** J'ai essayé de faire un petit peu de décision.
 **[4:14 - 4:16]** J'ai essayé de faire un petit peu de décision.
 **[4:16 - 4:16]** J'ai essayé de faire un petit peu de décision.
 **[4:20 - 4:28]** En gros, ils ont proposé, enfin, un jour a proposé une approche, mais pour laquelle il y aurait ce qu'ils appellent l'échec silencieux.
 **[4:28 - 4:31]** Au fait, ce n'est pas une approche.
 **[4:31 - 4:34]** Ma crainte, c'était justement cet échec silencieux.
 **[4:34 - 4:38]** Ça veut dire qu'on ne soit pas au courant qu'il y a eu un échec.
 **[4:38 - 4:42]** Je vais regarder Last Activity Act, le champ, je vais le regarder, je vais voir une date.
 **[4:43 - 4:54]** Mais je n'ai pas moyen de savoir si cette date correspond vraiment à la date de la dernière activité de l'utilisateur au domaine de ses élèves, de ses students.
 **[4:54 - 4:56]** C'était ça ma crainte.
 **[4:56 - 5:05]** Il a parlé de best effort, ça veut dire qu'il va faire de son mieux, mais il ne peut pas garantir que ce champ ne soit pas mis à jour.
 **[5:05 - 5:09]** Ça veut dire qu'il y aura justement un fail qui est silencieux.
 **[5:10 - 5:23]** Mais si je ne peux pas faire confiance à ce champ, je ne peux pas baser mon data warehouse, les données du data warehouse sur la base de ce champ là, pour l'incrémental, pour le load incrémental.
 **[5:23 - 5:30]** J'ai besoin de savoir si je peux faire confiance à ce champ.
 **[5:30 - 5:35]** Donc il n'y a pas de décision.
 **[5:35 - 5:37]** Donc techniquement, il n'y a pas de décision.
 **[5:37 - 5:39]** Ça veut dire de nous dire quelle est la solution.
 **[5:40 - 5:48]** Alors Abiba a envoyé un mail par la suite pour demander s'il n'y a pas eu un autre mécanisme de repli plus robuste, etc.
 **[5:48 - 5:50]** On n'a pas eu encore de retour.
 **[5:50 - 5:52]** Donc on en est là.
 **[5:52 - 5:55]** Oui, donc pour nous, il n'y a pas de décision à prendre de notre côté.
 **[5:55 - 6:00]** Parce que c'est eux qui doivent nous revenir avec nos mécanismes en ce moment.
 **[6:01 - 6:03]** A priori, ils doivent chercher s'il y a une solution.
 **[6:03 - 6:06]** Je pense qu'il devrait y avoir une solution.
 **[6:06 - 6:09]** Je ne sais pas, ils peuvent faire un log d'erreur, des réessais.
 **[6:09 - 6:18]** Ils peuvent ajouter une métadonnée par rapport à l'échec ou à la réussite de cette activité.
 **[6:20 - 6:22]** Donc s'ils peuvent nous ajouter ça, ça serait bien.
 **[6:22 - 6:30]** Sinon, on fera avec le full load, avec tout ce que ça implique derrière notre côté pour Azure.
 **[6:31 - 6:38]** Un pipeline qui ramène un full load, pardon, de plusieurs centaines de milliers de students à chaque fois, tous les jours.
 **[6:38 - 6:40]** Ça veut dire coût, de notre côté.
 **[6:40 - 6:45]** Donc on devrait juste être OK par rapport à ça, que ça soit documenté.
 **[6:45 - 6:52]** OK.
 **[6:52 - 6:55]** Euh...
 **[7:00 - 7:02]** On va attendre.
 **[7:02 - 7:03]** C'est tout ce qu'on peut faire.
 **[7:03 - 7:15]** On va attendre.
 **[7:30 - 7:40]** On va attendre.
 **[7:40 - 7:47]** Oui, ce que j'ai compris, c'est que pour les gens qui ont migré, ça va être la date du premier login.
 **[7:47 - 7:48]** C'est ça le défaut.
 **[7:48 - 7:57]** Puis par la suite, il doit y avoir un mécanisme qui met à jour ce champ là pour qu'il soit mis à jour avec chaque activité d'utilisateur.
 **[7:57 - 8:03]** Il dit que ça va pinguer chaque heure pour récupérer s'il y a une activité.
 **[8:03 - 8:09]** Le deuxième cas, ça sera les utilisateurs qui seront forcés par la suite de migrer.
 **[8:09 - 8:17]** Ces utilisateurs, le défaut va être le Last updated ad qui est dans le Firebase, dans la base de données Firebase.
 **[8:17 - 8:19]** Donc, ils vont utiliser ça.
 **[8:23 - 8:31]** Pour les utilisateurs, les nouveaux utilisateurs, ça va être un défaut à la date de création de compte parce que c'est défaut à Now.
 **[8:19 - 8:23]** Ils ne vont pas utiliser la date de migration forcée, ce qui fait du sens.
 **[8:31 - 8:38]** La date à laquelle l'utilisateur a généré une création de compte.
 **[8:38 - 8:44]** Le souci se pose pour la mise à jour de ce champ là, pour les activités.
 **[8:44 - 8:49]** L'idée, c'est qu'on doit être capable de faire confiance à ce champ pour baser nos données.
 **[8:49 - 8:59]** Parce que s'il n'est pas mis à jour, je ne peux pas ramener les données correspondant, si jamais il y a une donnée assez glissée, sans qu'il soit mis à jour.
 **[8:59 - 9:05]** Et on aura dans le Data Rechafs, un fail financier aussi.
 **[9:05 - 9:07]** Donc ça va être comme un parallèle.
 **[9:15 - 9:27]** Et j'imagine qu'on n'a pas un estimé de temps par rapport à...
 **[9:27 - 9:29]** En courant, ok.
 **[9:29 - 9:30]** Bon, c'est la fin.
 **[9:30 - 9:30]** Ok.
 **[9:30 - 9:35]** Est-ce qu'on a besoin de repasser sur les autres points ?
 **[9:35 - 9:39]** J'ai tout mis dans l'ordre du jour là.
 **[9:39 - 9:47]** Mais c'était essentiellement le point d'Abiba qu'on voulait revoir tous ensemble pour être sûr d'avoir bien le scénario, enfin, d'impact et tout en tête.
 **[9:47 - 9:49]** Abiba ?
 **[9:49 - 9:56]** Oui, c'est juste par rapport à la partie multi-device.
 **[9:56 - 10:03]** Je ne suis pas sûr ce qui a été décidé parce que ça impacte aussi la gestion du pipeline de données derrière.
 **[10:03 - 10:06]** Pas de décisions prises encore pour le moment.
 **[10:06 - 10:08]** Tout ce qu'on sait, c'est que...
 **[10:08 - 10:14]** On va communiquer avec les conseils scolaires pour s'assurer qu'ils ne bloquent pas les autres updates.
 **[10:14 - 10:16]** C'est ce qu'on va demander.
 **[10:16 - 10:19]** Mais en termes de résolution de leur côté, il n'y en a pas.
 **[10:19 - 10:24]** Je vais quand même...
 **[10:24 - 10:26]** Spéculer une idée.
 **[10:26 - 10:27]** Bah, spéculer une idée.
 **[10:27 - 10:28]** Je vais quand même avancer une idée.
 **[10:28 - 10:30]** Je ne sais pas si elle est faisable ou pas.
 **[10:30 - 10:43]** Mais si on doit impliquer l'IBO pour que l'IBO fasse quelque chose dans l'application actuelle, qu'ils forceraient par exemple une mise à jour ou bien qu'ils demandent...
 **[10:43 - 10:44]** Ils demandent...
 **[10:44 - 10:44]** Ils demandent...
 **[10:44 - 10:45]** Ils demandent...
 **[10:45 - 10:45]** Ils demandent...
 **[10:45 - 10:45]** Ils demandent...
 **[10:45 - 10:46]** Ils demandent...
 **[10:46 - 10:47]** Ils demandent...
 **[10:47 - 10:48]** Ils demandent...
 **[10:48 - 10:49]** Une bannière...
 **[10:49 - 10:50]** Quelque soit l'alpha...
 **[10:50 - 10:51]** La solution là...
 **[10:51 - 10:52]** C'est quelque chose qu'on va étudier aussi.
 **[10:52 - 10:53]** Si c'est faisable...
 **[10:53 - 10:54]** Tant mieux.
 **[10:54 - 10:55]** Si c'est pas faisable...
 **[10:55 - 10:57]** On est de retour à la...
 **[10:57 - 10:58]** Case départ un peu.
 **[10:58 - 10:59]** Une bannière...
 **[10:59 - 11:13]** Ça veut dire que l'utilisateur aura toujours la possibilité d'ignorer la bannière à aller faire des activités dans l'app.
 **[11:13 - 11:15]** C'est un risque à prendre.
 **[11:15 - 11:18]** Je sais pas ce que je voudrais.
 **[11:18 - 11:20]** Mais là comme je l'ai dit, c'est juste une idée.
 **[11:20 - 11:24]** Maintenant, s'ils sont capables de forcer la mise à jour, tant mieux.
 **[11:24 - 11:26]** Mais il faudrait que The Mind nous dise...
 **[11:26 - 11:28]** Qu'est-ce que l'IBO pourrait faire...
 **[11:28 - 11:30]** Pour simplifier et...
 **[11:30 - 11:32]** Aider à une solution.
 **[11:32 - 11:35]** Mais ça, ça va être dans la cour de The Mind.
 **[11:35 - 11:37]** C'est une discussion qu'on va devoir avoir.
 **[11:37 - 11:42]** Il a mentionné dans son courrier...
 **[11:42 - 11:44]** Pour répondre à cette problématique...
 **[11:44 - 11:47]** Il peut à les gens bloquer les apps dans les...
 **[11:47 - 11:49]** L'emmigré.
 **[11:49 - 11:52]** Mais le souci là, c'est que l'utilisateur...
 **[11:52 - 11:54]** Il va avoir un message d'erreur de login.
 **[11:54 - 11:56]** Même s'il rentre ses bons...
 **[11:56 - 12:01]** Il va avoir une erreur de login.
 **[12:01 - 12:03]** Donc ça aussi, c'est un impact sur les utilisateurs.
 **[12:03 - 12:06]** Si on opte pour cette option là.
 **[12:06 - 12:09]** Alors, si on fait cette option là.
 **[12:09 - 12:11]** Et que disons qu'il y a un utilisateur qui est bloqué.
 **[12:11 - 12:14]** Qui est dans la blacklist, on va dire.
 **[12:14 - 12:18]** Que cet utilisateur contacte Asma.
 **[12:18 - 12:21]** Asma serait capable de demander à l'utilisateur de faire la mise à jour.
 **[12:21 - 12:25]** Et de débloquer cet utilisateur de la liste.
 **[12:25 - 12:28]** Je ne sais pas si elle a cette possibilité là aujourd'hui.
 **[12:28 - 12:29]** Ou pas.
 **[12:34 - 12:35]** pas.
 **[12:35 - 12:39]** Donc je pense que tout ça c'est des points qu'il faut qu'on soulève avec Demi.
 **[12:39 - 12:56]** Aussi un dernier point que je mettais, c'est juste que historiquement pour migrer sur V1 à V2, il y a eu 80% d'utilisateurs qui n'ont pas migré.
 **[12:56 - 13:04]** Donc il faut juste savoir qu'on a migré uniquement 20% ces utilisateurs qui ont migré volontairement à la V2.
 **[13:04 - 13:06]** D'accord?
 **[13:06 - 13:24]** Donc si le même scénario se présente avec cette migration V2, V3, on risque de se retrouver à la fin au lieu des 20-30% qu'ils ont mentionné, on risque de se retrouver avec plus de 82% d'utilisateurs qui ont migré.
 **[13:24 - 13:24]** D'accord?
 **[13:24 - 13:28]** Donc c'est plus 20-30% comme ils ont dit, ça peut être plus.
 **[13:28 - 13:37]** Maintenant je dis ça, je dis rien, si on va force migrer 80% pourquoi ne pas force migrer 100% ?
 **[13:37 - 13:47]** Ça sera juste 90 jours peut-être de grâce à donner à Zemind pour qu'ils testent leur nouvelle app.
 **[13:47 - 13:52]** Mais c'est quoi le bénéfice pour vous ?
 **[13:54 - 13:58]** Ok.
 **[13:58 - 14:04]** Une question, est-ce qu'il y a un moment donné, est-ce qu'on peut faire, je ne sais pas si on fait des cross-checks là ?
 **[14:04 - 14:23]** Par exemple, une fois qu'on a mis en plan 2 ou 3 mois comme ça, on regarde la base de l'une de Superbase, on post-checks avec la base de l'une de Superbase, juste pour voir la différence qui n'a pas été migrée, et on prend des actions possibles de ce genre-là, via des mécanismes infolettres, tout comme ça.
 **[14:23 - 14:25]** C'est faisable ça ?
 **[14:25 - 14:25]** Oui.
 **[14:34 - 14:36]** Ok.
 **[14:36 - 14:40]** Ok.
 **[14:40 - 14:42]** Ok.
 **[14:42 - 14:48]** Ok.
 **[15:04 - 15:38]** Pour la fois, on va rencontrer demain, Julie, moi, Carole et eux, juste côté exécutif là on va dire.
 **[15:38 - 15:45]** Alors on va leur dire qu'on n'est pas à l'aise d'aller en prod lundi.
 **[15:45 - 15:50]** Donc on peut déjà dire qu'il n'y aura pas de go pour ce lundi.
 **[15:50 - 15:58]** On va aussi discuter de l'approche par rapport à qu'est-ce que l'IBO peut faire, selon eux.
 **[16:00 - 16:06]** Par la suite, on contactera l'IBO pour voir s'ils seront capables de le faire, s'il y a une solution.
 **[16:06 - 16:10]** S'ils ne sont pas disponibles ou bien qu'il n'y a pas de solution, bah...
 **[16:10 - 16:20]** Jusqu'on en rediscute, mais à l'état actuel, c'est un no-go et il n'y a pas de nouvelle date jusqu'à la preuve de contrat.
 **[16:20 - 16:22]** Donc on va voir s'ils sont capables.
 **[16:22 - 16:24]** Et donc on va voir s'ils sont capables.
 **[16:24 - 16:26]** Et donc on va voir s'ils sont capables.
 **[16:26 - 16:32]** Oui, mais une question, en fait l'option que si l'IBO devrait intervenir, c'est les applications.
 **[16:32 - 16:36]** Est-ce que ça, ça n'aura pas le risque d'éviter là d'être retiré ?
 **[16:36 - 16:40]** Par exemple, je ne sais pas si c'est juste des modifs dans le back-end là.
 **[16:40 - 16:46]** Non, je crois que ça devrait aller parce que Jean-Claude, ce qu'il avait demandé comme exception, c'était jusqu'au 30 octobre.
 **[16:46 - 16:50]** Donc je pense qu'on peut faire des mises à jour tranquillement jusqu'au 30 octobre.
 **[16:50 - 16:51]** Tout.
 **[16:59 - 17:01]** Okay.
 **[17:04 - 17:10]** En fait, il y avait une question que vous voulez poser à l'époque, à toi qui est plus familière vous donner là.
 **[17:10 - 17:32]** Est-ce qu'il y a moyen de savoir le nombre, les comptes, par exemple, si tu as ta plusieurs devices, Android, iPad, l'OF, le Chromebook, par exemple, et que tu utilises le même email, est-ce qu'il y a moyen dans les données, dans Firebase, de savoir les différents device que tu utilises avec un seul MM, avec un même compte ?
 **[17:32 - 17:33]** Non.
 **[17:34 - 17:36]** Mais il n'y a pas ces données dans Firebase, malheureusement.
 **[17:36 - 17:45]** Et il n'y a pas aussi les données de savoir combien d'utilisateurs utilisent iPhone, comme ça, selon les types d'appareils ?
 **[17:45 - 17:50]** Il y a la même question que tout à l'heure, c'est ça ?
 **[17:50 - 17:51]** Non, non, c'est très peu différent.
 **[17:51 - 17:58]** Celui-là, c'est juste, par exemple, le nombre d'utilisateurs qui utilisent iPhone, le nombre d'utilisateurs qui utilisent iPad ou Android.
 **[17:58 - 17:58]** Non.
 **[17:58 - 18:03]** Donc, on n'a pas de distinction par device.
 **[18:04 - 18:13]** On peut avoir une estimation approximative, mais celle-là, on peut l'avoir de Google Analytics.
 **[18:13 - 18:18]** Donc, ça sera comme un échantillon de données qui ne sera pas à 100%...
 **[18:18 - 18:20]** fiable.
 **[13:52 - 13:54]** Ah vraiment.
 **[18:20 - 18:21]** Exactement.
 **[18:21 - 18:24]** Mais ça peut me donner une idée sur les utilisateurs.
 **[18:33 - 18:34]** Merci.
 **[18:34 - 18:36]** Et Google Analytics, c'est un site qui est très important.
 **[18:36 - 18:38]** Et Google Analytics, c'est un site qui est très important.
 **[18:38 - 18:39]** Et Google Analytics, c'est un site qui est très important.
 **[18:39 - 18:41]** Et Google Analytics, c'est un site qui est très important.
 **[18:41 - 18:42]** Et Google Analytics, c'est un site qui est très important.
 **[18:42 - 18:43]** Et Google Analytics, c'est un site qui est très important.
 **[18:32 - 18:33]** Ça marche.
 **[18:43 - 18:44]** Et Google Analytics, c'est un site qui est très important.
 **[18:44 - 18:45]** Et Google Analytics, c'est un site qui est très important.
 **[18:47 - 18:49]** Et Google Analytics, c'est un site qui est très important.
 **[18:46 - 18:47]** Et Google Analytics, c'est un site qui est très important.
 **[18:49 - 18:50]** Et Google Analytics, c'est un site qui est très important.
 **[18:50 - 18:52]** Et Google Analytics, c'est un site qui est très important.
 **[18:52 - 19:01]** Ça marche.
 **[19:01 - 19:01]** Merci.
 **[19:05 - 19:12]** Si on résume en soi, pour le point numéro 1, il n'y a pas de décision à prendre de notre côté.
 **[19:12 - 19:13]** C'est purement de leur côté.
 **[19:13 - 19:17]** Donc je pense que là, Jacob, il faudrait qu'il clarifie ce côté-là.
 **[18:45 - 18:46]** Et Google Analytics, c'est un site qui est très important.
 **[19:17 - 19:22]** Côté numéro 2, je n'ai pas la liste devant moi là, donc je regarde.
 **[19:22 - 19:29]** C'est dans l'invitation, mais c'est sur la blacklist contentful.
 **[19:38 - 19:44]** Donc, avant même d'aller de l'avant, je pense que ça, c'est le point qui va toucher l'IBO.
 **[19:36 - 19:38]** Ça, c'est obligatoire cette solution.
 **[19:44 - 19:48]** Donc, on en parlera demain.
 **[19:48 - 19:52]** Attends, je vais sur mon calendrier là.
 **[19:52 - 19:57]** Nouveau numéro 3.
 **[19:59 - 20:00]** Oui, oui, oui, oui.
 **[20:00 - 20:03]** Nouveau numéro 3, c'est quoi?
 **[19:30 - 19:36]** Ouais, ça, encore comme je dis, il faut qu'il y ait une solution pour débloquer la blacklist là.
 **[20:05 - 20:05]** Oui, Asp.
 **[18:24 - 18:32]** Donc, on peut aller sur Google Analytics, je peux ressortir, voir ce que je peux poster par rapport au device utilisé.
 **[20:03 - 20:05]** FireBase Arts.
 **[20:06 - 20:09]** Vas-y, vas-y.
 **[20:09 - 20:11]** Non, c'est juste que je...
 **[20:11 - 20:13]** Je ne sais pas si on a pris une décision par rapport à ça.
 **[20:13 - 20:22]** Après 90 jours.
 **[20:22 - 20:25]** Après 90 jours, moi, j'ai pas envie de payer plus ce JABO pour FireBase.
 **[20:46 - 20:53]** Et le numéro 4 qui propose d'afficher un message aux utilisateurs lors de la première connexion.
 **[20:43 - 20:46]** option.
 **[20:53 - 20:54]** Pourquoi pas?
 **[20:54 - 20:56]** Moi je dirais pourquoi pas.
 **[20:56 - 20:58]** Il n'y a rien à perdre.
 **[20:58 - 21:11]** Le numéro 3, ça parle des 90 jours ou en général quand un utilisateur a migré?
 **[20:27 - 20:39]** Le numéro 3 pourrait être fixé par l'IBO si l'IBO accepte de faire quelque chose.
 **[21:11 - 21:13]** Je vais chercher là.
 **[21:16 - 21:21]** Hmm...
 **[21:54 - 22:24]** C'est juste une autre option aussi.
 **[22:24 - 22:35]** C'est une option, mais Amado avait mentionné aussi, peut-être, peut-être, dans les conseils scolaires, les gens n'ont pas la main sur les devices aussi.
 **[22:35 - 22:41]** Donc, ce n'est pas tout le monde qui peut mettre à jour les appareils qu'ils ont, en fait.
 **[22:41 - 22:46]** Donc, ça nécessite de faire des communications avec les conseils scolaires.
 **[22:46 - 22:53]** Si les enseignants sont nos plus grands utilisateurs, on leur a bien pu mettre à jour, peut-être.
 **[23:03 - 23:18]** Est-ce que, Amadou, si on choisissait cette option, on pourrait faire partir des communications dès maintenant au conseil scolaire en disant que leur application doit être bloquée quoi qu'il arrive et qu'il faut qu'il les mette à jour ?
 **[23:18 - 23:18]** Enfin, je ne sais pas.
 **[23:18 - 23:19]** Oui.
 **[23:19 - 23:20]** Oui.
 **[23:20 - 23:27]** Parce que si on va vers l'option du verrouillage de l'authentification de notre ailleurs bail, j'ai l'impression...
 **[23:27 - 23:27]** Ça va être pire.
 **[23:27 - 23:36]** Mais peut-être que je n'ai pas l'éventail des impacts très clairs dans ma tête, mais j'ai l'impression que ce serait une solution justement pour ce cas de multidivice.
 **[23:41 - 23:43]** Je pense qu'on peut...
 **[23:43 - 23:44]** Vas-y, Abibha.
 **[23:44 - 23:56]** Ça peut être, je pense, frustrant pour l'élève ou l'enseignant d'aller sur l'app de l'école, ou sur le divorce de l'école, essayer de se connecter, voir un échec à chaque fois.
 **[23:56 - 24:00]** Il n'a pas de message pour dire qu'il faut qu'il réunisse.
 **[24:00 - 24:02]** Je pense que c'est un peu frustrant.
 **[24:02 - 24:04]** Moi, je me mets à la place de...
 **[24:13 - 24:18]** Je pense que si on fait une bonne campagne de...
 **[24:04 - 24:13]** Alors, je suis d'accord, mais par exemple, là, pour ceux qui ont fait des rentrées scolaires, on a tous reçu des communications de comment ça allait se passer, là.
 **[20:05 - 20:06]** Oui.
 **[21:24 - 21:31]** De moins, c'est juste plait.
 **[24:18 - 24:27]** Mais dès maintenant, quoi, en leur disant, enfin, voilà ce qui va se passer, là, dans 10 jours, c'est normal que vous soyez bloqués, c'est normal.
 **[24:27 - 24:31]** Un, vous pouvez appeler notre service client pour qu'il vous accompagne.
 **[24:33 - 24:39]** Parce que là, j'ai du mal à entrevoir une alternative à ce truc-là.
 **[24:39 - 24:41]** Et d'un autre ?
 **[24:41 - 25:14]** Oui, enfin, juste en revenant sur ce qu'il disait au débat, par exemple, la frustration, là, c'est vrai qu'il peut y avoir des frustrations, mais aussi, si Libéon peut faire quelque chose, par exemple, la personne vient, nous, on a bloqué son appareil, la personne vient, il s'authentifie, sur son appareil, donc l'autorification, là-bas, vérifié dans Firebase, le mot de identifiant est correct, le mot de passe est correct, juste afficher un message gentil pour le dire, il est temps de mettre votre application à jour.
 **[24:31 - 24:33]** Deux, voici la méthode...
 **[25:14 - 25:27]** Il n'y a rien de grave, c'est pas un message de réponse à afficher, c'est juste dire, on a renouvelé Bokili, un message qui est sympa, en fait, il faut juste démigrer, en fait, de renouveler, de mettre en jour l'aide d'appareil.
 **[24:33 - 24:33]** Enfin, je ne sais pas.
 **[25:28 - 25:32]** Oui, c'est vrai, au lieu d'une erreur login, oui, c'est un message.
 **[25:38 - 25:39]** Oui, c'est ça.
 **[25:47 - 25:55]** En parlant de scolaire, moi je dois aller chercher les petites.
 **[25:55 - 25:59]** Je vais devoir m'excuser.
 **[25:32 - 25:38]** Oui, mais ça, c'est si Libéon est capable de le faire.
 **[26:01 - 26:07]** C'est déjà du travail.
 **[25:59 - 26:01]** Combien de petites?
 **[26:17 - 26:21]** A priori, c'est presque sûr, il n'y a pas de beau pour l'un.
 **[26:21 - 26:29]** Suite des aventures, on vous fera signe de ce qui se passe, ce qui a été décidé dans les prochains jours.
 **[25:39 - 25:47]** C'est pour ça que je disais que 3, Libéon pourrait potentiellement le fixer, mais reste à voir, qu'est-ce qui va se passer ?
 **[26:29 - 26:32]** Merci à tous.
 **[26:32 - 26:33]** Merci.
 **[0:00 - 0:00]** Tchau.
 **[0:15 - 0:20]** Hello tout le monde, tiens, comment on se revoit ?
 **[0:20 - 0:25]** C'est la huitième fois que j'avais promis qu'on se verrait huit fois par jour, on y arrive.
 **[0:25 - 0:33]** Alors, qui c'est qui est ?
 **[0:34 - 0:38]** C'est Marc.
 **[0:38 - 0:41]** Et Simon, tout le monde est là.
 **[0:44 - 0:50]** Abiba, je ne sais pas si tu as eu le temps de prendre connaissance des notes Gemini, je suis désolée.
 **[26:33 - 26:35]** Merci, salut.
 **[0:50 - 0:57]** C'est beaucoup de lecture, je n'ai pas pu, malheureusement, j'ai vu en diagonale, mais pas de souci.
 **[0:57 - 1:06]** Pas de souci, on a eu la rencontre avec The Mind, ils nous ont remonté quatre points pour lesquels ils nous ont suggéré des approches, bref.
 **[1:19 - 1:19]** Oui.
 **[26:07 - 26:16]** Ok, il y aura la conversation avec Zemay demain, on vous tient au courant.
 **[1:23 - 1:26]** C'est pour le champ Last Activity Act.
 **[1:07 - 1:19]** Et on voulait repasser sur le point qui nous concernait sur la data pour que tu réexpliques la problématique et les derniers échanges qu'on a eus avec Anju, je crois que c'était où Jacob, je m'en suis dit.
 **[1:26 - 1:36]** En fait, on leur avait demandé au début, tu te rappelles Carole, d'ajouter ce champ-là pour pouvoir connaître si un utilisateur est actif sur un certain temps.
 **[1:39 - 1:48]** Et le besoin essentiel, c'était nous pour la partie data, de pouvoir faire de l'ingestion dans le Data Warehouse de façon incrémentale.
 **[1:36 - 1:39]** C'était ça le premier besoin.
 **[1:59 - 2:05]** Et ça se compte par des centaines de, plusieurs centaines de milliers de students.
 **[1:50 - 1:59]** Au lieu de, par exemple, chaque jour, chaque déclenchement de pipeline, je ramène tous les students avec toutes leurs activités, reading, gamification et tout.
 **[0:33 - 0:34]** Je crois qu'il y en a un qui a répondu non.
 **[2:23 - 2:35]** Ça veut dire si un student fait une activité, c'est là qu'on le ramène dans le Data Warehouse et on update les activités qu'il a faites, donc les tables reading, gamification, etc.
 **[2:15 - 2:23]** Donc, ce qui serait bien, c'est de faire une ingestion incrémentale sur la base de Last Activity Act.
 **[2:46 - 3:05]** Ça veut dire qu'on n'ait aucun moyen de savoir que ce champ-là n'a pas été mis à jour correctement parce que le default dans le SQL Statement qui fait la création de la table que Franck m'a communiqué, il est defaulté à une date précise qui est le Now.
 **[3:05 - 3:11]** Donc, le Now, ça peut être la date de migration de cet utilisateur, la date du login.
 **[3:31 - 3:42]** Il ne remontera pas dans les students que je vais remonter pour aller récupérer dans le Data Warehouse parce que le champ Last Activity Act n'aura pas changé.
 **[3:11 - 3:31]** Si jamais un student fait une activité quelconque au niveau du compte de cet utilisateur et que la date de cette dernière activité n'est pas remontée dans le champ Last Activity Act, moi, je n'ai pas moyen d'aller le récupérer.
 **[3:42 - 3:45]** Je ne sais pas si je me suis bien expliquée.
 **[3:45 - 3:49]** J'ai essayé d'être… J'ai donné beaucoup de détails.
 **[3:49 - 3:58]** Merci.
 **[4:03 - 4:06]** All right.
 **[4:09 - 4:26]** En gros, ils ont proposé, enfin, Andrew a proposé une approche, mais pour lesquelles il y aurait ce qu'ils appellent l'échec silencieux.
 **[2:37 - 2:46]** Maintenant, on lui avait posé la question, est-ce qu'il y a moyen que ce champ-là ne soit pas mis à jour de façon silencieuse ?
 **[1:48 - 1:50]** Qu'est-ce que ça veut dire ?
 **[4:29 - 4:32]** Ma crainte, c'était justement cet échec silencieux.
 **[4:26 - 4:29]** Au fait, ce n'est pas une approche.
 **[2:05 - 2:14]** Et quand on multiplie ça par le nombre d'activités qu'ils font, ça va être énormément de données à ingester à chaque fois si on fait un food load.
 **[4:39 - 4:52]** Je vais le regarder, je vais voir une date, mais je n'ai pas moyen de savoir si cette date correspond vraiment à la date de la dernière activité de l'utilisateur ou de l'un de ses élèves, de ses students.
 **[4:52 - 4:53]** C'était ça ma crainte.
 **[4:32 - 4:36]** Ça veut dire qu'on ne soit pas au courant qu'il y a eu un échec.
 **[5:03 - 5:07]** Ça veut dire qu'il y aura justement un fail qui est silencieux.
 **[5:08 - 5:20]** Si je ne peux pas faire confiance à ce champ, je ne peux pas baser mon data warehouse, les données du data warehouse sur la base de ce champ-là, pour l'incrémental, pour le load incrémental.
 **[4:53 - 5:03]** Il a parlé de best effort, ça veut dire qu'il va faire de son mieux, mais il ne peut pas garantir que ce champ ne soit pas mis à jour.
 **[5:32 - 5:50]** alors abiba renvoyer un mail par la suite pour demander s'il n'y a pas eu un autre mécanisme de repli plus plus robuste etc on n'a pas eu encore de retour donc on en est là on
 **[5:59 - 6:01]** A priori, ils doivent chercher s'il y a une solution.
 **[5:20 - 5:27]** J'ai besoin de savoir si je peux faire confiance à ce champ.
 **[6:03 - 6:04]** Je ne sais pas.
 **[6:04 - 6:07]** Ils peuvent faire un log d'erreur, des réessais.
 **[6:16 - 6:20]** Donc, s'ils peuvent nous ajouter ça, ça serait bien.
 **[6:20 - 6:27]** Sinon, on fera avec le full load, avec tout ce que ça implique derrière notre côté pour Azure.
 **[6:28 - 6:36]** Un pipeline qui ramène un full load de plusieurs centaines de milliers de students à chaque fois tous les jours.
 **[6:36 - 6:38]** Ça veut dire coût de notre côté.
 **[4:36 - 4:38]** Je vais regarder Last Activity Act, le champ.
 **[6:38 - 6:42]** Donc, on devrait juste être OK par rapport à ça, que ça soit documenté.
 **[7:14 - 7:28]** Abiba, juste une question, en fait, dans le message, en fait, ils disent que le champ Use Alask Activity Ads, André vous mentionne que la clause Default Now initialise cette valeur à l'instant présent pour les nouveaux utilisateurs.
 **[7:33 - 7:36]** Ou bien c'est les gens qu'on a migré ?
 **[7:36 - 7:38]** Tiens, Abiba.
 **[6:07 - 6:16]** Ils peuvent ajouter une métadonnée par rapport à l'échec ou à la réussite de cette activité.
 **[7:44 - 7:45]** C'est ça le default.
 **[7:45 - 7:54]** Puis par la suite, il doit y avoir un mécanisme qui met à jour ce champ-là pour qu'il soit mis à jour avec chaque activité de l'utilisateur.
 **[8:00 - 8:06]** Le deuxième cas, ça sera les utilisateurs qui seront forcés par la suite de migrer.
 **[8:07 - 8:14]** Ces utilisateurs, le default va être le Last Updated Ad qui est dans la base de données Firebase.
 **[7:38 - 7:44]** Oui, ce que j'ai compris, c'est que pour les gens qui ont migré, ça va être la date du premier login.
 **[7:54 - 8:00]** Il dit que ça va pinguer chaque heure pour récupérer s'il y a eu une activité.
 **[8:16 - 8:20]** Ils ne vont pas utiliser la date de migration forcée, ce qui fait du sens.
 **[8:14 - 8:16]** Donc, ils vont utiliser ça.
 **[8:35 - 8:41]** Le souci se pose pour la mise à jour de ce champ-là, pour les activités.
 **[8:41 - 8:46]** L'idée, c'est qu'on doit être capable de faire confiance à ce champ pour baser nos données.
 **[8:46 - 8:56]** Parce que s'il n'est pas mis à jour, je ne peux pas ramener les données correspondantes si jamais il y a une donnée qui s'est glissée sans qu'il soit mis à jour.
 **[8:56 - 9:02]** Et on aura dans le Data Warehouse comme un fail financier aussi.
 **[8:28 - 8:35]** Ça veut dire la date à laquelle l'utilisateur a généré une création de compte.
 **[9:02 - 9:03]** Donc, ça va être comme un parallèle.
 **[9:10 - 9:18]** Là, je suis en train de rocher la tête, mais je dois carberer un PA l'Omega 3, je pense, de servir de fatigue.
 **[7:28 - 7:33]** Quand on dit les nouveaux utilisateurs, c'est les gens qui viennent pour la première fois sur le bouquet, c'est ça ?
 **[9:32 - 9:44]** J'ai tout mis dans l'ordre du jour, là, mais c'était essentiellement le point d'Abiba qu'on voulait revoir tous ensemble pour être sûr d'avoir bien le scénario, enfin, d'impacter tout en tête.
 **[9:49 - 9:53]** Oui, c'est juste par rapport à la partie multi-device.
 **[9:30 - 9:32]** Est-ce qu'on a besoin de repasser sur les autres points ?
 **[8:20 - 8:28]** Pour les nouveaux utilisateurs, ça va être un default à la date de création de compte parce que c'est default à Now.
 **[6:01 - 6:03]** Je pense qu'il devrait y avoir une solution.
 **[10:58 - 11:08]** Une bannière, ça veut dire que l'utilisateur aura toujours la possibilité d'ignorer la bannière et aller faire des activités dans l'app.
 **[12:02 - 12:04]** Il faut juste peut-être faire des sens.
 **[11:45 - 11:55]** Mais le souci, là, c'est que l'utilisateur, il va avoir un message d'erreur de login, même s'il rentre ses bons credentials.
 **[12:38 - 12:41]** Et aussi un dernier point, et je me suis fait que j'ai promis.
 **[11:55 - 11:57]** Il va avoir une erreur de login.
 **[12:51 - 12:55]** Donc, il faut juste savoir qu'on a migré uniquement 20%.
 **[11:57 - 12:02]** Donc, ça aussi, c'est un impact sur les utilisateurs si on opte pour cette option-là.
 **[13:00 - 13:01]** D'accord ?
 **[12:41 - 12:51]** C'est juste que historiquement, pour la migration V1 à la V2, il y a eu 80% d'utilisateurs qui n'ont pas migré.
 **[11:36 - 11:45]** Il a mentionné dans son courriel, pour répondre à cette problématique, qu'il peut, genre, bloquer les apps dans les non-migrés.
 **[12:55 - 13:00]** C'est les utilisateurs qui ont migré volontairement à la V2.
 **[13:19 - 13:20]** D'accord ?
 **[13:24 - 13:27]** Maintenant, je dis ça, je ne dis rien.
 **[13:01 - 13:19]** Donc, si le même scénario se présente avec cette migration V2-V3, on risque de se retrouver à la fin, au lieu des 20-30% qu'ils ont mentionnés, on risque de se retrouver avec plus de 80% d'utilisateurs non migrés.
 **[13:20 - 13:24]** Donc, c'est plus 20-30%, comme ils ont dit, ça peut être plus.
 **[13:33 - 13:43]** Ça sera juste 90 jours de grâce à donner à The Mind pour qu'ils testent leur nouvelle app.
 **[13:43 - 13:48]** C'est quoi le bénéfice pour nous ?
 **[9:53 - 10:00]** Je ne suis pas sûre ce qui a été décidé parce que ça impacte aussi la gestion du pipeline de données de RIR.
 **[14:19 - 14:21]** Oui, c'est...
 **[14:56 - 15:13]** Donc pour ton info Abiba, dans la précédente rencontre on a dit qu'on n'est pas confortable pour un go lundi, quoi qu'il arrive, sachant qu'en plus ils doivent nous livrer quelque chose ce soir et potentiellement demain, sachant qu'Ajar en plus elle est en vacances la semaine prochaine.
 **[14:17 - 14:19]** C'est faisable ça?
 **[16:21 - 16:23]** Oui, Amadou, une question.
 **[15:17 - 15:21]** Ok, merci pour l'info.
 **[16:35 - 16:38]** Ok.
 **[16:31 - 16:35]** Par exemple, je ne sais pas si c'est juste des modifs dans le back-end qu'ils font.
 **[16:43 - 16:48]** - Okay, so much message.
 **[16:23 - 16:31]** En fait, l'option que si l'IBO devrait intervenir sur les applications, est-ce que ça n'engendre pas le risque qu'on éviter là d'être retiré?
 **[16:59 - 17:05]** il y avait aussi une autre question que vous voulez te poser, Abiba, comme toi tu es plus familière aux données là.
 **[17:05 - 17:26]** Est-ce qu'il y a moyen de savoir les nombres, les comptes, par exemple, si toi tu as plusieurs devices là, Android, iPad, le web, un Chromebook par exemple, et que tu utilises le même email, est-ce qu'il y a moyen dans les données dans Firebase de savoir en fait les différents devices que tu utilises avec un seul, avec un même compte ?
 **[13:54 - 14:17]** Une question, est-ce qu'à un moment donné, est-ce qu'on peut faire, je ne sais pas si on fait des cross-check là, par exemple, une fois qu'à un moment donné, par exemple dans deux ou trois mois comme ça, on regarde la base de l'Unify Base, on cross-check ça avec la base de l'Unify Base, juste pour voir la différence qui n'a pas été migrée, et on prend des actions possibles de ces gens-là, via d'autres mécanismes, infolettres, etc.
 **[17:36 - 17:38]** C'est là le type d'appareil ?
 **[17:31 - 17:36]** Et il n'y a pas aussi les données de savoir combien d'utilisateurs utilisent iPhone, tout comme ça ?
 **[15:13 - 15:17]** Bref, il y a beaucoup de trous dans la raquette qui fait que quoi qu'il arrive on n'est pas confortable pour lundi.
 **[17:26 - 17:31]** Non, il n'y a pas cette donnée dans Firebase malheureusement.
 **[17:38 - 17:43]** C'est la même question que tout à l'heure, c'est ça ?
 **[17:43 - 17:45]** Non, non, c'est un peu différent.
 **[18:07 - 18:15]** Donc ça sera comme un échantillon de données qui ne sera pas à 100% rétile, exactement.
 **[18:15 - 18:16]** Exactement.
 **[17:52 - 17:58]** Non, donc on n'a pas de distinction par device.
 **[18:16 - 18:20]** Mais ça peut me donner une idée sur les utilisateurs.
 **[18:20 - 18:26]** Donc on peut aller sur Google Analytics, je peux vous sortir, voir ce que je peux sortir par rapport au device utilisé.
 **[17:58 - 18:07]** On peut avoir une estimation approximative, mais c'est là on peut l'avoir de Google Analytics.
 **[18:34 - 18:38]** Normalement, ils traquent tout, mais je vais voir ce qu'on a en termes de données, je te reviens par rapport à ça.
 **[18:33 - 18:34]** Le web peut-être ?
 **[13:27 - 13:33]** Si on va force migrer 80%, pourquoi ne pas force migrer 100% ?
 **[18:26 - 18:33]** Et Google Analytics traque aussi le device de Apple ou bien c'est juste le device de Google ?
 **[17:45 - 17:52]** Celui-là c'est juste par exemple le nombre d'utilisateurs qui utilisent iPhone, le nombre d'utilisateurs qui utilisent iPad ou Android.
 **[18:52 - 18:55]** Ça marche, merci.
 **[18:43 - 18:52]** Oui, parce que ça n'a pas été fait, le site n'a pas été fait sur le user ID, ça a été fait justement sur le pool de visite.
 **[18:38 - 18:43]** Mais juste gardez en tête que ça va juste être comme une tendance.
 **[21:20 - 21:29]** Oui, parce qu'à la fin, ça dit que ce verrouillage s'activera lors de la première authentification avec Superbase, suivant la migration.
 **[19:58 - 19:59]** Bouillage le temps.
 **[21:17 - 21:20]** Je pense que c'est quand un utilisateur a migré.
 **[20:56 - 21:05]** Le numéro 3, ça parle des 90 jours ou en général quand un utilisateur a migré ?
 **[21:48 - 21:49]** C'était notre option aussi.
 **[21:53 - 22:00]** Je pense que c'est l'option que Jacob a proposée dans son courriel, là où ça va générer une erreur de login, je pense.
 **[21:31 - 21:46]** Oui, et ça aussi, ça permet de fermer les autres devices, si tu as le même conseil des autres, dès que tu as migré dans Superbase, on bloque ce device pour ne pas que tu soumets tes données dans Firebase.
 **[22:04 - 22:05]** C'est quoi l'impact ?
 **[22:11 - 22:16]** Le fait de fermer les autres appareils, tu veux dire ?
 **[22:26 - 22:32]** Donc, ce n'est pas tout le monde qui peut mettre à jour les appareils qu'ils ont, en fait.
 **[22:18 - 22:26]** C'est une option, mais Amado avait mentionné aussi, peut-être, par exemple, dans les conseils scolaires, les gens n'ont pas la main sur les devices aussi.
 **[22:16 - 22:18]** Oui, pourquoi on ne veut pas ?
 **[22:32 - 22:41]** Donc, ça nécessite peut-être de faire des communications avec les conseils scolaires si les enseignants sont nos plus grands utilisateurs.
 **[22:41 - 22:45]** pour leur dire de mettre à jour peut-être des appareils.
 **[21:29 - 21:31]** Donc, c'est indépendant des 90 jours.
 **[23:34 - 25:24]** ça peut être je pense genre frustrant pour l'élève ou l'enseignant d'aller sur l'app de exemple de l'école ou sur le divas de l'école et c'est de se connecter voir un login un échec à chaque fois il n'a pas de message pour dire que il faut qu'il réinitier je pense que c'est un peu frustrant là moi je me mets à la place de alors je suis d'accord mais par exemple là pour ceux qui ont fait des rentrées scolaires on a tous reçu des communications de comment ça allait se passer là je pense que si on fait une bonne campagne de mais dès maintenant quoi en leur disant voilà ce qui va se passer là dans dix jours c'est normal que vous soyez bloqué c'est normal 1 vous pouvez appeler notre service client pour qu'ils vous accompagnent deux voici la méthode pas je sais pas parce que là j'ai du mal entrevoir une alternative à ce truc là abdoulaye oui en fait juste en revenant sur ce qu'il y avait pas par exemple la frustration là c'est vrai qu'il peut y avoir des frustrations mais aussi si l'IBO peut faire quelque chose par exemple la personne vient nous on a bloqué son appareil la personne vient 60 60 s'authentifie sur son appareil donc l'authentification la valeur vérifiée dans firebase ben l'identifier correct mot de passe est correct ben juste afficher un message gentil pour lui dire il est temps de mettre votre application à jour il n'y a rien de grave c'est pas un message d'erreur qu'on va afficher c'est juste dire bouclier voilà on a renouvelé bouclier un message qui est sympa en fait pour le juste démigrer en fait de renouveler de mettre à jour l'air appareil oui c'est vrai au lieu d'une erreur login c'est juste un message en fait
 **[22:52 - 23:30]** mais est-ce que Amadou si on choisissait cette option on pourrait faire partir des communications dès maintenant au conseil scolaire en disant que leurs applications vont être bloquées quoi qu'il arrive et qu'il faut qu'ils les mettent à jour enfin je sais pas parce que si on va avec l'option du verrouillage de l'authentification d'un fireball j'ai l'impression mais peut-être que j'ai pas l'éventail des impacts très clairs dans ma tête mais j'ai l'impression que ce serait une solution justement pour ce cas de multi device je pense
 **[19:18 - 19:23]** C'est dans l'invitation, mais c'est sur la blacklist Contentful.
 **[25:30 - 25:31]** - I like this as a silly bit of a problem.
 **[26:12 - 26:19]** Donc, suite des aventures, on vous fera signe de ce qui se passe, ce qui a été décidé dans les prochains jours.
 **[25:52 - 26:12]** Ok, bon, il y aura la conversation avec Zemay demain, on vous tient au courant, mais a priori, c'est presque sûr, il n'y a pas de go pour lundi.
 **[26:24 - 26:25]** Merci, salut.
 **[26:23 - 26:24]** Merci.
 **[26:22 - 26:23]** Merci à tous.
 **[22:00 - 22:04]** Et pourquoi on ne veut pas aller avec ça ?
 **[26:28 - 26:29]** Thank you.
 **[26:25 - 26:26]** Bye.