Esquisses de spécifications¶

Plan posé par Frédéric, mail "Module de rendez-vous", 5 juin 2016

• définir un type de rendez-vous/événement ex: Réunion d'information Petite Enfance
• pouvoir y ajouter des dates/heures ex: 15/1/2016, 19h00; 22/1/2016, 19h00
• définir nombre de places ex: 50

• ajouter aux dates/heures deux durées, pour transformer l'événement unique en plage horaire (d'une durée A, tenant n occurences de durée B).
• ajouter à ces places la possibilité de répétition, ça pourrait commencer très simple, avec uniquement un "répéter toutes les semaines", qui me semble correspondre au truc le plus utile.
• ajouter la possibilité d'exceptions
• et des détails genre date limite de prise de rendez-vous, date limite d'annulation, etc.

Voilà pour le côté backoffice.

Pour le frontoffice, c'est simple, il ne doit pas y en avoir, la prise de rendez-vous se fait dans w.c.s. et en première étape il y a tout ce qu'il faut déjà.

Restent les API pour combiner les deux, il me semble qu'on peut juste avoir :

• <type>/datetimes/ (GET)
  → {'data': [{'id': '...', 'text': '15/1/2016, 19h00'}]}

C'est utilisé pour remplir une liste

• <type>/fillslot/<id>/ (POST)

Ça enregistre le payload (même si ça n'a pas d'importance pour le début) et ça retire une place.

Si jamais il n'y avait plus de place, ça retourne une erreur, que w.c.s. peut traiter. (pour par exemple envoyer dans un statut "File d'attente").

Et voilà.

Juste derrière, on devra ajouter la possibilité de récupérer la liste des rendez-vous pris, pour affichage dans Combo, et à la même occasion avoir pour ceux-ci une URL d'annulation.

Au-delà de ça, quand il s'agira de rendez-vous et plus seulement de quelques événements, il faudra voir côté w.c.s. pour avoir un widget de sélection date/heure adapté (genre présentant les slots disponibles dans une vue type agenda hebdomadaire).

À partir de là, il n'y a plus vraiment de plan, ça dépendra nettement des besoins. Envoi de rappels à l'usager, vue "calendrier" dans le backoffice de w.c.s. (avec les filtres comme sur le listing de
demandes), backoffice côté Chrono pour avoir une vue sur le remplissage des slots, etc.

Demandes exprimées¶

Compréhension de la demande de Blois¶

Spécifications mentionnées dans CCTP de Blois + compléments oraux par S. Briaud le 16/12/15

• applicables à n lieux ( = services) avec déclaration d'heures d'ouvertures (déclinable suivant calendrier, définir durée de ce calendrier)
• au sein de chaque service, n agents possibles en parallèle (capacité à déclarer par tranches horaires, inférieurs à heures d'ouverture)
• au sein de chaque service, n types de RV possibles (passeport, CI, extrait d'actes, ...) chacun associé à une durée d'entretien
• possible de demander plusieurs créneaux (n membres d'une famille pour n passeports)
• pouvoir répartir n créneaux sur même tranche horaire en mobilisant n agents (toute la famille passe en même temps)
• choisir un RV sur n proposés à compter du premier libre (limite ?, ne pas accepter de RV au-delà de 3 mois, par exemple ; pê simplement sur base calendrier déclaré par service)
• créneau aussitôt bloqué pour autres usagers
• créneau doit être modifiable (annulation, reprise) par usager, évitera RV non honorés
• créneau peut être modifié par l'administration (une matinée annulée, un agent malade, ...)
• prévoir notifications (courriel et/ou SMS ?) à l'usager (confirmation après enregistrement, rappel à J-2, rappel le matin, ...)
• prévoir visualisation et édition du calendrier / jour pour agents

• choisir un besoin (demande passeport, par exemple) > système doit pouvoir appliquer n besoins à 1 service (limite accepté pas de gestion d'un calendrier répartis sur n lieux, si mairies de quartier, considérés comme services différents, l'usager a d'abord en tête le lieu où il veut aller)
• obligation de laisser au moins un moyen de contact ? (si annulation de RV)

• modification à posteriori du calendrier de RV par administration, AMA : on ne gère pas les alertes, informations des usagers hors logiciel, mais pê pas trèc compliqué en fait, puisque déjà notifications
• si modification par usager : prévoir interdiction si trop proche dans le temps du RV réservé ?

Inscription à des activités¶

Il peut être question d'activités ponctuelles ou récurrentes.
Une activité comporte généralement une liste principale et une liste d'attente.
Pour une activité récurrente il est nécessaire de pouvoir définir un délais de réservation (je ne peux pas réserver moins de 48 heures à l'avance).

Il est possible de s'inscrire à plusieurs activités depuis un même formulaire.
La soumission d'une demande de réservation consomme une place dans le quota disponible (dans certains cas est-il possible que la demande de l'usager ne soit qu'un souhait et que l'agent valide l'application au quota depuis le workflow ?)
Il est possible depuis le workflow de libérer la place (l'agent refuse l'inscription, l'usager annule sa réservation...)

Est-il possible d'afficher le nombre de places restantes à l'usager lors de l'accès au formulaire ?
Est-il possible d'utiliser une condition de sortie de page basée sur le fait qu' une agenda ne dispose plus d'une seule activité disponible ?

Possibilité de fixer des bornes d'age pour une activité, et permettre un filtre côté formulaire sur les activités dans les bornes d'age.

Pê prendre également exemple de Meyzieu¶

Ville de Meyzieu a mis en place fonctionnalités d'inscription à évènements (spectacles, ...) avec gestion de la capacité et liste d'attente, cf. copie de la slide ci-dessous

Solutions existantes¶

à Dreux¶

Dreux utilise la solution Myrdv (https://myrdv2.espacerendezvous.com).
La Ville de Dreux constate de façon non anecdotique que des usagers font des réservations sur plusieurs créneaux, il est constaté une proportion de 20 % de rendez-vous non honorés.
Pour info, la solution myrdv a une fonctionnalité de blacklistage des usagers trop "demandeurs", cette fonctionnalité n'est pas (encore ?) utilisée à Dreux.