Rajouter une information détaillée sur les créneaux disponibles quotidiennement

[Frédéric Camblor]

Avec l'ouverture aux 18+ sans comorbidités au 31/05, le front de vitemadose va devoir un peu évoluer.

Une plus grande partie de la population va chercher à se faire vacciner sans restrictions (pour info, on a 26 millions de plus de 50 ans en France, et 26 millions de personnes agés de 18 à 50 ans, source: Pyramide des ages de l'INSEE)

Compte tenu de l'afflux massif de nouvelles personnes éligibles, la question qui va devenir importante va sûrement être celle du "quand" par rapport à l'emploi du temps qu'un actif peut avoir (par rapport à un senior).

Nous aimerions en tous cas faire évoluer le front dans ce sens en présentant le nombre de créneaux disponibles dans les jours à venir, toute plateforme confondue.
Il est aussi à l'étude (mais dans un second temps à priori) le fait de pouvoir matcher des créneaux en fonction d'horaires de disponibilités (ou de non disponibilité) du visiteur sur l'application web/mobile.
On se dirigerait vers un design comme celui-ci (photo non contractuelle :-D) :

Pour pouvoir afficher ces données (et les filtrer si des créneaux horaires devaient être rentrés) nous avons besoin d'un second niveau de détail : celui des horaires des créneaux disponibles au sein d'un jour précis.

C'est pourquoi nous aurions besoin que le back évolue pour générer de nouveaux fichiers pour chaque département :

• 75/2021-05-21.json
• pas de 75/2021-05-22.json car aucun créneau dispo pour ce jour dans le 75
• pas de 75/2021-05-23.json car aucun créneau dispo pour ce jour dans le 75
• pas de 75/2021-05-24.json car aucun créneau dispo pour ce jour dans le 75
• 75/2021-05-25.json
• 75/2021-05-26.json
• etc...

Ces fichiers auraient cette structure (c'est une proposition) :

// 75/2021-05-21.json
{
  "date": "2021-05-21",
  "codeDepartement": "75",
  "timezone": "Europe/Paris",
  "lieux": [{
    "id": "doctolib47754pid26256",
    "creneaux": [
      {"debut":"2021-05-21T09:30:00+0200", "tags": ["preco18_55"]},
      {"debut":"2021-05-21T09:35:00+0200", "tags": ["preco18_55"]},
      {"debut":"2021-05-21T09:40:00+0200", "tags": ["preco18_55"]},
    ]
  }, {
    "id": "doctolib49375pid27190",
    "creneaux": [
      {"debut":"2021-05-21T16:42:00+0200", "tags": []},
    ]
  }]
}

Plusieurs questions que je me pose vis à vis de ce format :

1. Êtes-vous en mesure de fournir l'heure de début des créneaux pour chaque plateforme actuellement supportée ?
2. Je me demande s'il ne serait pas bon de "rappeler" quelques infos supplémentaires sur le lieu (nom + adresse + geoloc + tel + type lieu + vaccins supportés) afin de pallier au cas où on récupèrerait le fichier JSON quelques minutes après le fichier centres par département ... et qu'un nouveau centre soit alors apparu entretemps (la source de vérité des infos affichés du lieu serait basé sur ce nouveau fichier plutôt que sur le fichier centres)
3. Le champ tags serait rempli de la manière suivante (pour le moment) : si créneau de vaccin de type ARNm, alors le tag preco18_55 est ajouté, sinon il est omis. Cela permet d'éviter d'avoir à coder la règle "quand on sélectionne le filtre 18-55, c'est qu'on ne veut que les centres à ARNm" 3 fois sur les 3 fronts. Ne vous inquiétez pas, nous éviterons d'aller trop loin dans la substitution aux règles d'éligibilité, mais il s'agit ici d'un "quickwin" qui ne coûte pas cher à implémenter pour le moment
4. Je ne sais pas s'il faut mettre les tags au niveau de chaque appointment, ou directement au niveau du Lieu de vaccination : est-il possible d'avoir des centres de vaccination qui font à la fois de l'ARNm et de l'adeno vaccin ? Si ce n'est pas le cas, alors on peut tout à fait remonter l'info au niveau du lieu pour éviter de la dupliquer sur chaque appointment
5. L'affichage de la timezone en plus de l'heure "localisée avec le bon timezone offset" semblent redondants, mais je préfère donner les moyens aux fronts de corriger un bug de timezone si besoin était (à noter que pour les collectivités d'outremer, on aurait 2 timezones différentes qui seraient concernées, ce qui semblerait encourager à splitter les collectivités d'outremer en 2 "départements" différents au sens des données)

Afin d'être en mesure de savoir s'il est nécessaire d'aller chercher un fichier de jour particulier ou pas (quand il n'existe pas, si on peut éviter un aller/retour inutile sur une 404 c'est toujours ça de gagné) il faudrait enrichir un peu le fichier des centres par département pour lister les jours disposant de créneaux :

// 75.json
{
  "centres_disponibles": [...],
  "centres_indisponibles": [...],
  "creneaux_quotidiens": [{
      "date": "2021-05-21", 
      "total": 4, 
      "url": "./75/2021-05-21.json", 
      "countByTag": [{ "tag": "preco18_55", "total": 3 }]
  }, {
      "date": "2021-05-25", 
      "total": 2, 
      "url": "./75/2021-05-25.json", 
      "countByTag": [{ "tag": "preco18_55", "total": 0 }]
  }, {
      "date": "2021-05-26", 
      "total": 25, 
      "url": "./75/2021-05-26.json", 
      "countByTag": [{ "tag": "preco18_55", "total": 15 }]
  }, ....
  ]
}

Plusieurs questions que je me pose vis à vis de cet enrichissement :

1. Le champ url permet d'éviter de "hardcoder" (coté front) le chemin vers les fichiers de jours. C'est vraiment du nice to have (si vous voulez pas vous embêter avec ça pas de soucis)
2. Le countByTag est important car il nous permettra d'afficher les valeurs du calendrier sans avoir besoin de requêter tous les fichiers de ce dernier

N'hésitez pas si vous trouvez que j'ai dit de grosses bêtises ou si mes demandes sont trop farfelues, on peut itérer sur les structures des fichiers.

[David Libeau]

Je me doutais bien que la demande de notification à seulement certains horaires allait arrivée vite. Ma demande #392, c'était pour ça à la base. Heureux de voir que c'est maintenant à l'étude.

[Frédéric Camblor]

Suite à l'implémentation coté front, j'ai plusieurs remarques à faire sur ma proposition de format initial (dans la description).

Tout d'abord, les propositions d'évolution de format du <code departement>.json ne sont pas suffisantes pour être en mesure d'afficher toutes les infos : étant donné qu'on a un filtre de distance, il faut pouvoir filtrer les lieux qui matchent (ou non) avec ce critère de distance.
Or, si on ne possède pas des statistiques de créneaux par lieu, il sera impossible d'afficher/rafraîchir les chiffres en fonction de la distance sélectionnée, rapportée à la commune sélectionnée.

Rajouter les statistiques par lieu+jour rajoutant un volume assez conséquent au <code departement>.json, pour des données qui ne seront pas utilisées par les applications mobile actuelles, j'aurais tendance à privilégier d'externaliser ces données statistiques de haut niveau dans un JSON à part, qu'on pourrait nommer 75/creneaux-quotidiens.json

De plus, concernant la partie détaillée, @Floby craignait que remonter toutes les tranches horaires de toutes les plateformes sur les X prochains jours allait :

• représenter un trop gros volume de données
• être problématique vis à vis des plateformes (on "dump" tous leurs créneaux de résa...)

Dans un premier temps, on va partir sur le fait d'aggréger les créneaux par heure (plutôt que d'avoir un détail jusqu'à la minute).
En stockant ça sous la forme d'un array de 24 valeurs (1 valeur par heure), ça fait gagner énormément de place dans le JSON, et rend la production d'une version "détaillée" des créneaux quotidiens obsolète (tant qu'on n'a pas besoin d'un niveau de précision du créneau "à la minute")

On n'aurait donc qu'à produire 1 et 1 seul nouveau fichier par département : le 75/creneaux-quotidiens.json

Le contenu de ce 75/creneaux-quotidiens.json aurait alors cette forme :

{
  "creneaux_quotidiens": [{
    "date": "2021-05-21",
    "total": 9, // sum(creneaux_par_lieu.creneaux_par_tag[tag='all'].creneaux)
    "creneaux_par_lieu": [{
      "lieu": "doctolib271065pid186147",
      "creneaux_par_tag": [{ 
        "tag": "all", 
        "creneaux": 8 // attention: ça ne signifie pas qu'il y a 8-3-4=1 créneau "sans tag", car certains créneaux peuvent avoir plusieurs tags différents (on pourrait avoir 1 créneau avec preco18_55+preco16_18)
        "creneaux_par_heure": [0,0,0,0,0,0,0,0,2,0,3,0,0,1,0,1,1,0,0,0,0,0,0,0] // 2 créneaux sur [8h-9h], 3 créneaux sur [10h-11h], 1 créneau sur [13h-14h], 1 créneau sur [15h-16h], 1 créneau sur [16h-17h]
      }, { 
        "tag": "preco18_55", 
        "creneaux": 3, 
        "creneaux_par_heure": [0,0,0,0,0,0,0,0,1,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0] 
      }, { 
        "tag": "preco16_18", 
        "creneaux": 4, 
        "creneaux_par_heure": [0,0,0,0,0,0,0,0,2,0,0,0,0,1,0,0,1,0,0,0,0,0,0,0] // sur la plage [8h-9h], on a 1 créneau qui est à la fois preco18_55 et preco16_18
      }]
    }, {
      "lieu": "doctolib243183pid164885",
      "creneaux_par_tag": [{
        "tag": "all", 
        "creneaux": 1, 
        "creneaux_par_heure": [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0]
      }]
    }, {
      // ...
    }]
  }]
}

[David Libeau]

être problématique vis à vis des plateformes (on "dump" tous leurs créneaux de résa...)

Comme dit précédement, ce dump est déjà en place, au moins pour Doctolib (qui représente 80% des données récoltées), pour le comptage. Il n'y a aucune requête à faire en plus pour détailler les créneaux.

[Sacha Guilhaumou]

Maiia est intégré, Keldoc aussi @fcamblor @Floby

[Sacha Guilhaumou]

Back is readyy