Une instance par établissement

La décision commence par l’exploitation

Pour une plateforme destinée à plusieurs établissements, la séparation des données est un choix architectural fondamental. Une base commune avec un identifiant par organisation est une possibilité ; des bases ou des instances séparées en sont d’autres. Le choix dépend des exigences, de l’exploitation et des moyens disponibles.

Chez Schulmittag nous utilisons une instance et une base de données par établissement. Cela rend concrète l’attribution des données et de l’exploitation : quel établissement est concerné, quelle version utilise-t-il et comment restaurer ses données ?

Ce qu’apporte la séparation

Une base séparée réduit certaines possibilités de réunir accidentellement les données de plusieurs établissements dans une requête courante. Elle peut aussi faciliter la planification des modifications et des restaurations par établissement.

Ce n’est toutefois pas une frontière de sécurité absolue. Les accès administrateurs partagés, l’infrastructure, les outils de déploiement et les sauvegardes mal configurées peuvent affecter plusieurs instances. La responsabilité ne s’arrête donc pas à la création d’une seconde base.

Une base commune n’est pas non plus automatiquement peu sûre. PostgreSQL propose par exemple Row-Level Security, qui restreint l’accès aux lignes par des règles. Il faut tenir compte des rôles privilégiés et de la configuration. La comparaison consiste à demander quel modèle nous pouvons exploiter de façon fiable et compréhensible pour nos besoins.

Les questions derrière l’architecture

Une école ou une commune doit savoir où se trouvent ses données, qui peut y accéder et comment reprendre son activité après un incident. Cela exige des réponses concrètes : responsabilités, autorisations vérifiées, sauvegardes et procédure de restauration réellement testée.

OWASP décrit l’isolation entre organisations comme une tâche portant sur plusieurs couches. À la base de données s’ajoutent notamment l’authentification, les autorisations, les fichiers et les caches. Un schéma d’architecture ne répond pas à lui seul à ces questions.

Le coût de cette décision

De nombreuses instances augmentent le travail de déploiement, de mise à jour et de surveillance. L’automatisation aide, mais exige elle-même des processus compréhensibles et une gestion des erreurs. Notre outil ouvert fleetdeck s’inscrit dans ce travail de déploiement logiciel.

Pour moi, cela montre comment théorie et pratique vont ensemble. Un modèle de séparation est un bon point de départ. Sa solidité se révèle aussi lors des mises à jour, des tests d’autorisations et des restaurations. C’est là que notre décision doit faire ses preuves.