La plupart des plateformes SaaS sont multi-tenant : elles servent plusieurs clients depuis une infrastructure commune. Il existe trois grands modèles : base unique mutualisée (tous les clients dans une même base, séparés par un identifiant), base dédiée par client (chaque établissement a sa propre base) et sharded (un mix). La base mutualisée est le standard du marché, économique et sûre quand elle est bien conçue. La base dédiée offre une isolation physique qui simplifie l'export, la suppression en bloc, la sauvegarde et la localisation — ce qui en fait un atout pour le RGPD et la souveraineté. Le choix n'est pas « sûr / pas sûr » mais « quelle garantie pouvez-vous prouver à votre DPO ? ». La bonne question à poser à tout éditeur : « mes données d'anciens sont-elles dans la même base que celles des autres écoles ? ».
D'abord : qu'est-ce que la « multi-location » (multi-tenancy) ?
Presque toutes les plateformes alumni sont des logiciels SaaS multi-tenant : un même service héberge les données de nombreux clients (les « tenants », ici les établissements). C'est ce qui rend le SaaS économique — l'éditeur mutualise l'infrastructure plutôt que d'installer un serveur chez chaque client. La question n'est donc pas « multi-tenant ou pas », mais comment les données de chaque établissement sont rangées et séparées des autres. Les fournisseurs cloud documentent précisément ces modèles ; nous reprenons ici la taxonomie de référence de Microsoft Azure.
Les trois modèles d'architecture, expliqués simplement
| Modèle | Comment ça marche | Isolation | Profil |
|---|---|---|---|
| Base unique mutualisée (single multi-tenant DB) | Toutes les écoles dans la même base, séparées par un tenant ID en colonne. | Logique (assurée par le code) | La plus économique, la plus répandue |
| Base dédiée par client (database-per-tenant) | Chaque école a sa propre base de données, gérées de façon centralisée. | Physique (bases séparées) | Isolation forte, opération plus coûteuse |
| Sharded (hybride) | Plusieurs bases, chacune regroupant un sous-ensemble de clients. | Variable | Le plus flexible à grande échelle |
Aucun de ces modèles n'est « bon » ou « mauvais » dans l'absolu : ils répondent à des arbitrages différents entre coût, simplicité d'exploitation et niveau d'isolation. Ce qui change, c'est ce que vous pouvez garantir et prouver.
Ce que l'architecture change concrètement pour une école
Quatre conséquences très concrètes, qui intéressent directement une DSI et un DPO :
- Isolation. Avec une base dédiée, les données d'une école vivent dans une base distincte : un incident applicatif sur un autre périmètre reste, par construction, à l'extérieur du vôtre. Avec une base mutualisée, l'isolation repose sur la rigueur du cloisonnement applicatif (contrôle d'accès au niveau des lignes, tests).
- Droit à l'effacement (art. 17 du RGPD). Le droit à l'effacement impose de pouvoir supprimer des données dans des délais courts. Sur une base dédiée, supprimer ou anonymiser l'ensemble du périmètre d'un établissement se fait en bloc et de façon vérifiable.
- Export & réversibilité. Récupérer toutes vos données à la fin d'un contrat est plus simple quand elles sont dans une base qui n'est que la vôtre. La réversibilité — ne pas rester prisonnier d'un format propriétaire — se contractualise plus facilement.
- Localisation (résidence des données). Garantir que les données restent hébergées en France ou en Europe est plus direct quand la base d'un établissement est une entité identifiable, pas une fraction d'un grand ensemble partagé.
« Base mutualisée = risque » ? Non, et voici la nuance
Il serait malhonnête de dire qu'une base mutualisée est dangereuse. C'est un standard de l'industrie, utilisé par d'innombrables services que vous employez tous les jours, et il est parfaitement sûr lorsqu'il est correctement conçu : cloisonnement applicatif, contrôle d'accès au niveau des lignes, revues de code et tests. Méfiez-vous de tout argumentaire qui prétendrait le contraire.
La vraie différence est ailleurs : c'est la nature de la garantie d'isolation. Dans une base dédiée, l'isolation est physique — facile à expliquer et à prouver à une commission, un DPO ou une DSI. Dans une base mutualisée, elle est logique — réelle, mais elle dépend de la qualité et de la maintenance du code. Pour un établissement public soumis à des exigences de souveraineté, cette différence de « prouvabilité » pèse souvent dans la décision.
La bonne question à poser à votre éditeur
Vous n'avez pas besoin d'être ingénieur pour trancher. Une seule question fait le tri :
« Les données de mon établissement sont-elles dans la même base de données que celles de vos autres clients ? Et si je pars, pouvez-vous m'exporter puis supprimer l'intégralité de mon périmètre, de façon vérifiable ? »
Posez-la à chaque solution que vous comparez, et notez la précision de la réponse. C'est aussi l'un des critères du guide pour choisir un logiciel alumni, aux côtés de la transparence des prix et de l'hébergement.
L'approche de Terrilink
Terrilink a fait le choix de la base de données dédiée par établissement : chaque école dispose de sa propre base isolée, hébergée en France. Concrètement, vos données d'anciens sont identifiables, exportables intégralement et supprimables en bloc — la souveraineté devient vérifiable, pas seulement déclarative. C'est un parti pris assumé, plus exigeant à opérer, mais cohérent avec les attentes des établissements accrédités. Le détail figure sur la page logiciel alumni pour écoles accréditées, et la dimension conformité dans le guide RGPD.
En résumé
Mutualisée ou dédiée, la question n'est pas de savoir laquelle est « sûre » — les deux peuvent l'être — mais quelle garantie vous pouvez prouver. Si votre établissement est soumis à des exigences de souveraineté, d'accréditation ou de localisation des données, la base dédiée simplifie l'isolation, l'effacement RGPD, l'export et la réversibilité. Dans tous les cas, exigez une réponse claire de votre éditeur sur l'endroit où vivent vos données — et sur votre capacité à les récupérer et les effacer. C'est le réflexe de souveraineté le plus utile, et il ne coûte qu'une question.