Le passage au SaaS
Comprendre le modèle, ses promesses, ses contraintes - pour l'accompagner plutôt que le subir.
Le SaaS
On-premise, IaaS, PaaS, SaaS - la gradation.
Pourquoi
Standardisation, mutualisation, contexte public.
Gestion
D'une intervention directe à une relation de service.
Vigilance
Souveraineté, réversibilité, continuité de service.
Le métier
Ce que ça change pour une équipe applicative.
Modèle
Le SaaS, c'est quoi
Software as a Service - l'application n'est plus hébergée et exploitée en interne, elle est louée à un opérateur
Le SaaS s'inscrit dans une gradation de modèles de délégation. Plus on avance dans cette gradation, moins l'établissement gère directement l'infrastructure et l'application - et plus la relation avec le fournisseur devient contractuelle.
On-premise
Serveurs, OS, middleware, application
Tout est géré en interne
Tout est géré en interne
IaaS
Le matériel est externalisé
OS et application restent internes
OS et application restent internes
PaaS
L'environnement d'exécution aussi
Reste : application et données
Reste : application et données
SaaS
Tout est géré par l'opérateur
Reste : configuration et usage
Reste : configuration et usage
Ce que ça change concrètement
- →Plus de serveur à patcher, plus de montée de version à planifier soi-même - mais plus de main directe sur le comment.
- →Une anomalie ou une évolution passe par un ticket vers l'éditeur ou l'opérateur, pas par une intervention en interne.
- →Le calendrier des mises à jour est décidé par l'éditeur, pas par la DSI.
- →La relation devient contractuelle : SLA, engagements de service, clauses de réversibilité.
Contexte
Pourquoi ce mouvement s'accélère
Une tendance de fond, pas une mode - et des raisons qui tiennent la route
Le passage au SaaS n'est pas propre à l'ESR - c'est une tendance de fond de l'ensemble du secteur public et privé. Plusieurs raisons convergent, et elles sont légitimes.
Les bénéfices mis en avant
- →Standardisation et mutualisation - un éditeur qui opère une même application pour des dizaines d'établissements industrialise ce qu'une DSI seule ne peut pas rentabiliser.
- →Réduction de la charge d'infrastructure - moins de serveurs, moins d'exploitation système, moins de sécurisation à assumer en interne.
- →Accès à des versions à jour - sécurité, conformité, nouvelles fonctionnalités sans projet de montée de version porté en interne.
- →Contexte budgétaire et RH publics - les compétences pointues d'administration système sont rares et chères à maintenir en interne.
Dans l'ESR
Ce mouvement est porté en partie par l'AMUE elle-même : des applications historiquement déployées et administrées localement par chaque DSI évoluent vers des versions SaaS opérées de manière mutualisée - SIFAC vers SIFAC+ en est un exemple, remplaçant le modèle où chaque université exploitait sa propre instance.
Ce que tu connais déjà via un éditeur de logiciel
La logique d'un éditeur qui opère une plateforme mutualisée pour plusieurs clients plutôt que de livrer un logiciel que chacun installe chez soi - c'est le sens dans lequel évolue une bonne partie du logiciel métier, public compris.
Organisation
Ce qui change dans la gestion au quotidien
Le changement le plus concret n'est pas technique - il est organisationnel
Le mode d'action de l'équipe applicative se déplace. Elle garde la connaissance du métier et de l'usage, mais une partie de la capacité d'intervention directe passe à l'opérateur.
Avant - on-premise
comprendre → diagnostiquer → agir
Avec le SaaS
comprendre → qualifier → transmettre → suivre
Ce que ça signifie pour un projet SaaS
- →Le rôle de la DSI se déplace vers le paramétrage, la qualification des demandes et le suivi de service, plutôt que l'intervention technique directe.
- →La qualité de la remontée d'incident devient un savoir-faire à part entière : un ticket bien qualifié se traite plus vite qu'un ticket vague.
- →Le suivi des engagements contractuels (SLA, disponibilité, délais de traitement) devient une compétence de pilotage à développer.
- →L'interface entre l'opérateur, les métiers et les utilisateurs devient une des valeurs ajoutées principales de l'équipe applicative.
On-premise vs SaaS - comparaison rapide
| Point | On-premise | SaaS |
|---|---|---|
| Hébergement | Interne, maîtrisé localement | Externe, chez l'opérateur |
| Incident | Intervention directe par la DSI | Ticket vers l'éditeur / opérateur |
| Évolutions | Calendrier décidé localement | Calendrier décidé par l'éditeur |
| Compétence clé | Administration système, exploitation | Qualification, pilotage de service, contrat |
| Risque principal | Charge d'exploitation, obsolescence | Dépendance, réversibilité, souveraineté des données |
Risques
Les points de vigilance côté université
Le SaaS n'est pas neutre pour un établissement public
Certains enjeux sont spécifiques à un établissement public et ne se délèguent pas avec l'application - ils restent entièrement du ressort de l'université.
Ce qui mérite d'être anticipé
- !Souveraineté et hébergement des données - où sont hébergées les données (étudiants, RH, recherche) ? Un hébergement hors UE, ou chez un prestataire non qualifié, peut poser un problème de conformité RGPD et de politique de sécurité (PSSI-E).
- !Réversibilité contractuelle - que devient-on si l'éditeur cesse le service ou augmente ses tarifs ? La clause de réversibilité (récupération des données, format d'export) doit être anticipée dès le contrat.
- !Continuité de service public - une application de scolarité ou de paie ne peut pas s'arrêter. Le SLA doit être compatible avec cette obligation.
- !Marchés publics - la bascule vers un opérateur SaaS suit les mêmes règles de commande publique que tout achat significatif : procédures, délais, mise en concurrence.
- !Dépendance à l'éditeur - le calendrier d'évolution et de fin de vie de l'application n'est plus maîtrisé par l'université.
Regard
Ce que ça change pour le métier applicatif
Au-delà du contrat et de la technique - une manière de pratiquer le métier qui évolue
Une expertise qui s'était construite sur la capacité à comprendre un système et à intervenir dessus directement se retrouve, avec le SaaS, davantage centrée sur la qualification, la médiation et le suivi. Ce n'est pas un métier au rabais - c'est un métier différent, qui demande d'autres compétences : formalisation du besoin, négociation avec l'opérateur, pilotage de la relation de service.
Un point à observer plutôt qu'à trancher
Le sujet n'est pas vraiment de savoir si le SaaS est une bonne ou une mauvaise chose - c'est une évolution de fond, probablement logique pour une bonne partie des applications. La vraie question, pour une équipe applicative, est plutôt : quelles nouvelles compétences et quels nouveaux rôles se construisent quand une partie des tâches techniques disparaît ? C'est un sujet à observer avec attention en arrivant dans une DSI en pleine transition sur ce point.
Le regard sur le SaaS
Le SaaS déplace la valeur ajoutée de l'équipe applicative : moins d'intervention technique directe, plus de qualification, de pilotage de service et de médiation entre opérateur et métiers.
Les enjeux de souveraineté, de réversibilité et de continuité de service public restent, eux, entièrement du ressort de l'université - ils ne se délèguent pas avec l'application.
Ce n'est pas une question de bon ou de mauvais modèle, mais de savoir ce que ce déplacement de rôle construit - ou non - comme nouvelles compétences pour les équipes.
Le SaaS - gradation
Pourquoi - industrialisation
Gestion - relation de service
Vigilance - souveraineté
Le métier - nouveaux rôles