Système d'alerte de disponibilité de RDV

[hzba1]

Cette issue a pour but de centraliser les idées remontées dans le groupe de travail:

Pré-requis:

• Pas de données personnelles ou identifiables stockées côté serveur
• Traitement effectué côté client
• Compatibilité multi-plateforme

Idées:

• PWA avec Push Notification
  • PRO: Interropérabilité, paramètres stockées côté navigateur
  • CON: Portée limitée sur navigateur mobile à cause des politiques de Power Saving
• Extension XPI pour Firefox/Chrome
  • PRO: Adhésion importante, pris en main assez rapide
  • CON: Adaptée aux navigateurs "desktop" majoritairement
• Flux RSS
  • PRO: Format universel et interopératable, peut servir de sources aux autres intégrations, et peut être adapté sur Mobile
  • CON: Nécessite une interface, ou un client RSS.

A vos claviers.

[Toomaaa]

Il y a un protocole de notifications push qui est devenu presque un standard, tout du moins sur les navigateurs les plus communs :
https://caniuse.com/push-api

De la doc : https://developers.google.com/web/fundamentals/push-notifications

L'utilisateur doit autoriser les notifications dans son browser. Côté serveur on ne garde qu'un ID, donc pas de données personnelles. Lorsqu'une notification est pushée cela appelle un service worker côté browser, même si le site en question n'est pas ouvert.

Du coup on a le "PRO" de la première solution mais pas le "CON" car c'est spécialement fait pour fonctionner même si le site n'est pas ouvert.

[hzba1]

Web Push API semble être une bonne alternative mais peut être compliqué à mettre en place à une large échelle car cela nécessite une connexion "persistante" et donc d'une infrastructure pour encaisser les "subscribers".

Si nous avons 150k visites par jour, prenons 10% d'abonnements, cela fait 15k connexions actives en permanence. Soit une moyenne de 250 requêtes/seconde pour un équilibrage parfait, ce qui est rarement le cas.

[Toomaaa]

Non pas besoin de connexion persistantes avec ce protocole (où alors j'ai mal compris).
Je remets le résumé que j'ai fait sur Telegram :

• Il faut appeler en front une méthode pour demander l'autorisation à l'utilisateur
• A l'acceptation, ça stocke un fichier .js (le service worker) dans le client
• Côté serveur, on récupère 2-3 datas par subscriber (une URL à appeler + des clés), qu'on stocke (on peut les stocker par département du coup)
• Quand on veut envoyer une notif, on appelle un endpoint API push avec les subscribers qu'on veut notifier (donc on peut les prévenir par département)
• Les browsers vont requêter l'API Push quand ils sont online (je n'arrive pas à voir la fréquence de polling par contre, mais c'est fait pour être assez réactif)
• Quand ils détectent une nouvelle notification, ils exécutent le service worker (le fichier .js stocké), qui permet d'effectuer si on veut de l'analytics ou autres tâches en background et de poper la notification

[hzba1]

Il semble qu'il soit possible de choisir le délai de vérification côté client: https://w3c.github.io/push-api/#subscription-refreshes

[Toomaaa]

Il semble qu'il soit possible de choisir le délai de vérification côté client: https://w3c.github.io/push-api/#subscription-refreshes

Non, il s'agit du renouvellement de la souscription, au cas où celle-ci est expirée.
Le client ne s'adresse pas au serveur pour poller ses push, il s'adresse à l'API, il n'y a pas de connexion directe entre VMD et le client

[DavidLibeau]

Je suis d'avis qu'il faut prioriser l'ouverture des données (utiliser un format libre ou standard), ce qui permettra de pourvoir interfacer avec d'autres systèmes permettant les notifications ou même l'automatisation.
Comme ce sont des données calendaires, il existe aussi le format ICS (que j'ai notamment utilisé pour AgendaDeMinistre) et tout ce qui est CalDAV ou Web Calendar Access Protocol. A voir si c'est pertinent ici.

[V0lantis]

Cette issue a pour but de centraliser les idées remontées dans le groupe de travail:

Pré-requis:

• Pas de données personnelles ou identifiables stockées côté serveur
• Traitement effectué côté client
• Compatibilité multi-plateforme

Je crains que ces prérequis soient trop contraignants pour une facilitée d'utilisations d'une majorité de personnes.
Ne pouvons pas faire des prérequis moins contraignants ?

Exemple : base de données avec expirations de données, E.g. auto-suppression de la donnée au bout de 15 jours.
Ainsi, on peut stocker l'adresse mail (pour une durée temporaire). À mon humble avis, ça faciliterait grandement les choses...

Bien évidemment, ça vient avec un bouton "Unsuscribe" sur chaque mail + un moyen de le faire également au travers de la plate-forme web vitemadose

[Maijin]

Pour info covidlist est de nouveau ouvert https://github.com/hostolab/covidliste

[V0lantis]

Pour info covidlist est de nouveau ouvert https://github.com/hostolab/covidliste

C'est pas exactement pareil je dirais. L'objectif serait d'informer automatiquement lors d'ouvertures de nouveaux créneaux

[Maijin]

oui oui j'ai bien compris - mais comme c'etait l'un des probleme (y en a d'autres) qui ont lancés cette discussion je voulais passer l'info 😉

[rozierguillaume]

Pour info on avait plutôt prévu d’implémenter les alertes dans les apps mobiles (ça nous permettrait de ne collecter qu’un identifiant anonyme).

Personnellement je ne suis pas fermé à l’idée de collecter les mails pour envoyer des alertes (on le fait déjà pour la newsletter après tout).

[DavidLibeau]

Il faudra garder en tête la définition de données de santé "les informations relatives à une personne physique collectées lors de son inscription en vue de bénéficier de services de soins de santé" https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante, même si je ne sais pas trop si cela s'applique ici.

[V0lantis]

Il faudra garder en tête la définition de données de santé "les informations relatives à une personne physique collectées lors de son inscription en vue de bénéficier de services de soins de santé" https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante, même si je ne sais pas trop si cela s'applique ici.

Ce n'est pas vraiment en vue de bénéficier de services de soins de santé, mais pour bénéficier d'informations relatives aux disponibilités de centre de vaccination. La différence est subtile. Par exemple, je peux très bien à titre personnelle me renseigner sur les disponibilités d'un centre du nord pas de calais sans pour autant avoir quelconque intention de m'y faire vaccinée.

[fcamblor]

Sur l'API PUSH, on a un moyen de détecter un "plaisantin" qui viendrait s'inscrire des millions de fois aux abonnements et mettrait à genoux le système de notifications ?

Un truc basé sur l'IP serait suffisant (mais pour ça, il faudrait stocker l'IP, et c'est mal)

J'ai du mal à voir comment on pourrait stocker une référence unique qui soit à la fois :

• mis à dispo par l'appelant à l'API (donc un appelant malicieux pourrait faire n'importe quoi)
• sans données personnelles