---
# System prepended metadata

title: Meeting "éligibilité 18+" sur ViteMaDose

---

# Meeting "éligibilité 18+" sur ViteMaDose

## Sujets à aborder
_classés par ordre d'importance, on ne les traitera peut-être pas tous_

MUST HAVE
1. Quelle donnée dans le JSON ? Vaccin **vs** Tranches d'age
2. Que faire saisir à l'utilisateur ? Sa tranche d'age **vs** son type de vaccin **vs** sa "famille" de vaccin (ARNm / Adeno)
3. Quels fronts prévoient d'intégrer le changement du bandeau jour ?
   Comment on s'assure que les fronts sont bien codés de la même façon ?

_(voir la section "Notes préparées" pour des avantages/inconvénients sur chaque option)_

NICE TO HAVE

- Et si on parlait de la carte sur l'écran de résultats ? :-)


## Notes en live

Gael a commencé par expliquer un peu le fonctionnement des scrappers coté Back

1 Scraper pour toutes les plateformes qui interroge 1 "sous"-Scrapper spécifique pour chaque plateforme.

Itérateur = sa responsabilité est de donner l'ensemble des centres d'une plateforme.
Soit "en live", soit pré-calculé pour les plateformes qui mettent du temps à fetcher les centres (Doctolib we're watching you)

Une fois tous les centres identifiés, on récupère les créneaux du centre sur X jours glissants (pagination).


Ce que proposait Florent : 

- Avoir une structure de données homogène en sortie des itérateurs
- Gestion d'une File (consommable une fois pour toute) des stats générées

**Question** : est-ce qu'on investit sur ce refacto vs on attend ?

=> On investit sur le refacto car si on ne le fait pas :
- on n'ira pas spécialement plus vite
- le code sera dégueu pour intégrer les nouveautés sur les JSON


Noé pas forcément super chaud pour la File qui risque de complexifier les choses 
=> à voir

Un [repository de staging](https://gitlab.com/ViteMaDose/vitemadose-staging) a été setup par Florent ce week end, il pourra être utilisé par l'équipe du Back pour développer sur une branche dédiée les changements nécessaires à l'alimentation des créneaux.
=> Ce repository génère des fichiers sur un serveur dédié à part de la prod (qui pourra être consommé en avance de phase par les fronts pour tester)

Une branche dédiée au refacto sera créée sur le repository pour que tout le monde puisse fournir son implémentation de sa plateforme (toutes les plateformes doivent être migrées sur la nouvelle archi intégrant le refacto de Florent)

Un channel Mattermost va être créé pour fluidifier les échanges lors de ce "sprint" coté Back.


**1. Quelle donnée dans le JSON ? Vaccin **vs** Tranches d'age**

=> Tranches d'age

**2. Que faire saisir à l'utilisateur ? Sa tranche d'age **vs** son type de vaccin **vs** sa "famille" de vaccin (ARNm / Adeno)**

=> Sa tranche d'age


**3. Quels fronts prévoient d'intégrer le changement du bandeau jour ?
   Comment on s'assure que les fronts sont bien codés de la même façon ?**

=> Tous les fronts sont chauds. Les données vont être préparées par le Back donc c'est cool on est sûr d'avoir une implémentation homogène.
:warning: le Back devra bien être conscient que changer la valeur d'un tag sera impactant sur les fronts qui vont se baser sur les tags pour matcher les tranches d'age.


Fred a fait une démo [de la version calendrier sur la partie web](https://dev.vitemado.se/disponibilite-generale/) ([PR #233](https://github.com/CovidTrackerFr/vitemadose-front/pull/233)), tout le monde a bien vu la plu-value fonctionnelle de cette feature.

Plusieurs points ont été abordés : 
- la structure de données décrite dans [l'issue de Fred](https://github.com/CovidTrackerFr/vitemadose/issues/519) va sûrement un peu évoluer pour : 
    - Intégrer les lieux avec des créneaux au niveau de chaque jour (pour éviter de devoir charger la liste de tous les jours)
      :warning: Attention à l'overhead que cela peut représenter ... peut-être externaliser le champ `creneaux_quotidiens` dans un JSON à part pour ne pas venir alourdir le JSON des apps mobiles pour rien
    - Actuellement, le fichier JSON par jour n'est pas utilisé (tant qu'on n'a pas besoin de filtrer par créneau horaire, ou qu'on n'affiche pas le détail des créneaux du centre)
      => il n'est pas forcément nécessaire de positionner le champ `url` tant que les créneaux détaillés ne sont pas générés/utilisés (DL va être chagrin)
- Le combo filtre distance + affichage des créneaux est ce qui apporte une plu-value forte  niveau UX
- Le wording sera peut-être à adapter sur le type "Tous" (pour faire apparaître la notion de 55+)
- Le nombre de jours à afficher dans le bandeau : avis plutôt partagés entre 1 semaine et 30j.
  Avoir peu de jour peut générer de la frustration comme on a pu le voir sur les chronodoses ("quand je vais sur Doctolib en direct, je vois plein de créneaux à T+15j alors que sur Vitemadose, les créneaux sur les 10j à venir sont tous vides")
  À l'inverse, avoir une trop grosse plage horaire peut être problématique du point de vu de certaines plateformes qui n'ont pas de cache sur les requêtes trop lointaines (et puis certaines plateformes pourraient voir d'un mauvais oeil qu'on "dump" leur calendrier entier)
  Le **point important** sur ce sujet est que cela soit pilotable par le back (c'est le Back qui génère la liste des jours affichés .. si on souhaite augmenter/diminuer la taille de cette liste, ce sera simple à faire, et centralisé)
- champ `appointment_schedules` plus nécessaire une fois les chronodoses terminées. Florent souhaitait du coup lui faire la peau pour alléger le JSON (et puis aussi pour pas avoir à le gérer dans son refacto :))
  => OK, mais attention à ne pas supprimer le champ pour les vieilles versions d'app mobile (valoriser le champ à un array vide)


## Notes préparées (avant meeting, pour argumentations sur les questions abordées)

1. Quelle donnée dans le JSON ? Vaccin **vs** Tranches d'Age

**Vaccin**
👍 bien plus pérenne coté back
👎 règles par catégories à déporter N fois sur les fronts

**Tranche d'age**
👍 homogénéité assurée sur les front
👍 changement de règle au sein d'une tranche d'age centralisée (ex: si dans 2 semaine les 16-18 sont éligibles Pfizer)
👎 chaque fois qu'une nouvelle tranche d'age apparaîtra, il faudra la prendre en compte coté back

2. Que faire saisir à l'utilisateur ? Sa tranche d'age **vs** son type de vaccin **vs** sa "famille" de vaccin (ARNm / Adeno)

**Tranche d'age**
👍 L'utilisateur ne se trompera pas (normalement...)
👎 On commence à "coder" des règles d'éligibilité, peut être compliqué si elles changent souvent
👎 Attention à ne pas en avoir trop

**Type de vaccin (Pfizer, Moderna, AZ, J&J etc.) **
👍 On ne fait que présenter une info, sans plus de traitement
👎 Les utilisateurs doivent connaître les types de vaccin auxquels ils sont éligibles (tout le monde n'est pas autant au courant que nous de qui à droit à quoi). Pour moi (Fred) ça va à l'encontre de l'objectif de simplification de VMD.

**Famille de vaccin (ARNm, Adeno)**
_J'ai pas trouvé un seul point positif :D_
👎 Adeno quoi ? vous pouvez répéter la question ?
👎 Marche pas avec les 16-18 qui sont juste sur du Pfizer (pas compatible Moderna)
