Ouverture expérimentale en "Saas"

[victormours]

Objectif

Ouvrir des accès à des agents de l’université de Toulouse pour essayer un fonctionnement “Saas” de RDV Service Public pour des petites structures, et évaluer la viabilité de ce modèle.

Mise en place

Opérations faciles (sans dev)

Créer ces nouvelles ressources :

• Un nouveau territoire “Université de Toulouse”
• Un nouveau service (nom à trouver) dans lequel mettre tous les agents, ou plusieurs services ?
• Une nouvelle organisation pour l’université

Développements nécessaires

• changer le texte de prise de rdv côté usager pour que ça affiche “Prenez rdv” à la place de “Prenez rdv avec votre mairie” (voir https://rdv.anct.gouv.fr/prendre_rdv?departement=MA&public_link_organisation_id=36 )
• Déplacer la landing page destinée aux mairie vers une autre adresse (typiquement rdv.anct.gouv.fr/mairies), et mettre sur la page d’accueil une landing générique : Ça permet d’éviter que les usagers/agents de l’université voient une landing orientée mairie, qui n’a rien à voir avec leur domaine. Voir : https://github.com/betagouv/rdv-solidarites.fr/issues/3759
• Pouvoir activer ou désactiver les services au niveau de chaque territoire, voire même avoir des définitions de service par territoire (probablement ajouter une colonne service.territory_id). On pourrait utiliser cette liste uniquement pour la création d’agent, ce qui éviterait des problème sur les agents multi-territoire (même si ça n’arrive quasiment que pour les admins betagouv). Ça éviterait que les agents de mairie voient les services de l’université dans les services proposés pour créer un agent. Ça serait utile pour le serveur historique aussi. Voir https://github.com/betagouv/rdv-solidarites.fr/issues/3757
• Arrêter de partager la liste des usagers inter-territoires via le dédoublonnage (pour éviter de donner accès à trop de données personnelles) https://github.com/betagouv/rdv-solidarites.fr/issues/3758
• Nouvelle verticale “rdv_service_public” (au sens de la colonne organisations.verticale)

Possibilités non retenues

Avoir un autre serveur/nom de domaine avec le logo RDV Service Public : c’est pas compréhensible d’avoir le même logo pour deux bases de données différentes

Amélioration possible

On pourrait même rendre la notion de service complètement optionnelle : ça pourrait être facultatif pour un agent de faire partie d’un service, et ça serait une fonctionnalité avancée pour les organisations qui veulent avoir une gestion plus fine de la confidentialité des données.

[ousmanedev]

Quelques notes:

1 - Instance Rdv Mairie VS Instance RDV Solidarites

Je comprends que nous envisageons ouvrir les accès pour l'université de Toulouse sur l'instance rdv-mairie. Pourquoi ce choix au lieu de l'instance rdv-solidarités, qui jusque là semble être plus générique ?

2 - Problème de devs customs pour chaque verticale

Je pense qu'il y a un pattern/smell qui se dégage toutes les fois, au moment d'introduire une nouvelle verticale.

• Changer des textes selon la verticale / le nom de domaine
• Afficher/ Cacher des champs de formulaire selon la verticale / le nom de domaine
• Changer le logo, le nom ou d'autres éléments génériques selon la verticale / le nom de domaine

Je pense que nous devrions introduire la notion de thème de Verticale (ou peut-être même de thème d'organisation, si on veut aller plus loin). Le thème de la verticale configurable depuis le SuperAdmin, représentera un ensemble de données (textes, images, fonctionnalités) propres à une verticale ; déterminant comment RDV Service Public se présente à l'usager.

Dans l'idéal, nous serions en mesure d'introduire une nouvelle verticale avec presque/ ou pas de dev:

• Ajouter le territoire depuis le SuperAdmin
• Ajouter l'organisation depuis le SuperAdmin
• Configurer le thème lié au territoire depuis le SuperAdmin

Cette suggestion s'inscrit beaucoup plus dans une logique long terme et aussi de refacto fucture ; ce n'est pas forcément à prendre en compte dans le cadre de cette expérimentation. Pour en garder une trace, j'ai créé cette issue: https://github.com/betagouv/rdv-solidarites.fr/issues/3761

[victormours]

Je comprends que nous envisageons ouvrir les accès pour l'université de Toulouse sur l'instance rdv-mairie. Pourquoi ce choix au lieu de l'instance rdv-solidarités, qui jusque là semble être plus générique ?

Plusieurs raisons :

• répartition de charge : l'instance existante a déjà beaucoup de traffic et de données, et on s'attend à ce que les verticales existantes en ajoute encore plus, donc on préfère en ajouter sur la nouvelle instance qui n'a pas encore trop de données.
• séparation des données : même si on fait de notre mieux pour séparer les données, on a potentiellement des données plus sensibles sur le médico social, et en sécurité supplémentaire on préfère les séparer des données de cette expérimentation en les ayant sur une autre instance
• notre système de gestion des verticales dans le code est agnostique de l'instance, ce qui permet de faire qu'il n'y a pas vraiment d'instance "plus générique" de l'autre. Dans la pratique, on a plus de verticales différentes sur l'instance historique, mais c'est plus parce qu'on n'avait pas encore fait l'effort de créer une nouvelle instance que pour des vraies raisons métier.

2 - Problème de devs customs pour chaque verticale

A titre perso, je pense que l'approche de gestion des verticales qui marchera le mieux à long terme serait un fonctionnement en marque blanche (ça semble bien correspondre aux besoin des deux nouveaux ministères avec lesquels on discute en ce moment), ce qui implique des changements de textes mineurs, qui sont aujourd'hui matérialisé par certains attributs de la classe Domain (#search_banner_template_name par exemple serait le template qui permettrait de faire les changements demandés ici). J'ai l'espoir que ces développement soient assez légers, et qu'on ouvre des nouvelles verticales suffisamment rarement pour que ça soit ok que ça passe par un peu de dev (pour le moment on en est à une nouvelle verticale tous les 6 mois). C'est des choses assez critiques pour que ça soit un tout petit peu dangereux de laisser trainer ça dans un champs de super admin modifiable à la main sans historique du pourquoi des modifications