Hébergement du backend 

Nous proposons un hébergement en mode SAAS de :

• La gateway et l'ensemble des 17 microservices de l'application
• Le serveur NATS
• La base Mongo
• La base Redis
• Le CMS Headless (Directus ou Wordpress)

Il s'agit de la partie "rose" du Schéma d'architecture.

La configuration des microservices nécessitera l'implication de l'établissement. La version web de l'application sera également disponible à partir du moment où le thème multi sera fournit par l'établissement.

Les connecteurs SI

Les connecteurs SI resteront dans les établissements. Il s'agit de la partie "jaune" du Schéma d'architecture

Les connecteurs qui fournissent les données issues du SI restent dans les établissements et devront respecter les formats d'entrée et sortie attendus. Il faudra ouvrir un accès à ces connecteurs aux serveurs hébergeant le backend. Il faudra également faire attention à la tenue en charge de ces services grâce à des tests de charge.

On peut imaginer une exception pour le connecteur restaurant si et seulement si ce dernier ne s'alimente que des flux du CROUS (peu lié au SI et déployable facilement en SAAS)

L'API CAS devra être accessible au serveurs hébergeant le backend.

Enfin, l'établissement devra ouvrir un accès à son SMTP pour les envois de mails depuis le formulaire de contact.

Mise à disposition des applications clientes

Le mode SAAS inclut la publication sur les stores (une fois le thème fourni) 

L'établissement devra personnaliser le look en créant un thème qui sera ensuite utilisé à la compilation des deux app natives iOs et Android 

L'hébergeur SAAS se chargera de synchroniser la mise à jour du backend et des applications clientes.

Cela implique que l'établissement doit néanmoins se charger de la déclaration des comptes sur les stores Apple (iOs) et Google (Android) et de l'ouverture des accès à l'hébergeur sur ces derniers.

En mode SAAS comme en mode On prem, il faut que lorsqu'une évolution est faite sur le backend, ce dernier devra rester compatible avec (au moins) la version précédente du client afin de laisser le temps aux utilisateurs de mettre à jour leur applications clientes

FAQ

Et si on veut développer et ajouter ou corriger une fonctionnalité ?

Pour cela on passera par le processus de contribution. L'établissement devra partager sa contribution qui sera intégrée au code de l'application.

On ne pourra pas proposer en mode SAAS une contribution qui ne serait pas intégrée au projet et disponible à la communauté.

Et techniquement ?

Le backend est complètement cloisonné et fait l'objet d'un déploiement par établissement avec un dns dédié qui pourra évoluer indépendamment des autres instances SAAS.

Le déploiement se fait pour les établissements SAAS comme pour l'instance de l'Université de Lorraine dans un environnement conteneurisé sous Kubernetes. 

L'hébergeur met à disposition un environnement de test (20 pods max) et un environnement de production (60 pods max).

Qu'en est-il de la compatibilité RGPD ?

Données personnelles stockées : En mode SAAS, les données SI restent hébergées dans les établissements seules les données concernant l'auth et permettant la réauth sont hébergées en SAAS.

Et combien ça coute ?

Les coûts de mise en service s'élèvent à 5040€ HT

Les coûts récurrents s'élèvent ensuite à 12056€ HT par an.

La fréquence des mises à jour se calquera sur celle de l'application de l'université de Lorraine.