Plateforme mutualisée : ce qui sépare votre école des autres clients
Sur une plateforme mutualisée, un réglage de l’éditeur tient vos dossiers à l’écart de ceux des autres écoles. Aucun contrat ne le montre. Voici ce qu’une DSI peut demander pour le vérifier.
Le 24 septembre 2026, Cloudflare a publié le compte rendu d’une faille de son service de conteneurs. Sur ses serveurs, les disques de plusieurs clients puisaient dans une même réserve de stockage. Une option de configuration dispensait d’effacer un bloc de disque avant de le confier à un autre client. Ce client pouvait donc lire ce que le précédent avait laissé.
Le chercheur qui l’a signalée le 4 septembre a trouvé des restes de données sur 18 emplacements testés sur 24, et sur 20 serveurs sur 22. BleepingComputer reprend les mêmes chiffres. Parmi ces restes figuraient des répertoires, des pages de base de données et des bases SQLite entières. Cloudflare dit n’avoir trouvé aucune trace d’exploitation, et un attaquant ne pouvait pas choisir sa victime.
La correction a consisté à retirer l’option. Les clients n’ont rien eu à changer. Ils ne choisissent pas non plus la machine qui les héberge, précise Cloudflare. Leur isolement tenait à une ligne de configuration chez le fournisseur.
La DSI d’une école pose la même question à chaque éditeur : un autre établissement peut-il voir nos données ? Sur un outil mutualisé, la réponse dépend de réglages qu’elle ne voit pas.
Un contrat promet que vos données restent à part. Seule l’architecture permet de le constater. Demandez à votre éditeur laquelle des deux il vous offre.
Ce qu’une plateforme mutualisée partage entre ses clients
Une plateforme mutualisée sert plusieurs clients avec les mêmes ressources. Le partage ne se décide pas d’un bloc. Microsoft le décrit comme un curseur, réglé couche par couche. AWS distingue de même trois modèles : chaque client a ses ressources, tous les partagent, ou un mélange des deux. Quatre couches comptent pour une école :
- L’application. Le même logiciel, sur les mêmes serveurs, répond à toutes les écoles clientes.
- La base de données. Une seule base peut porter les dossiers de toutes les écoles, une ligne à côté de l’autre.
- Le stockage. Les fichiers et les disques puisent dans une réserve commune, comme chez Cloudflare.
- Le calcul. Les traitements de plusieurs clients tournent sur les mêmes machines.
Quand les écoles partagent la base, ce qui les sépare tient dans le code. Selon la documentation d’architecture de Microsoft , l’éditeur s’appuie alors sur son application et sur un identifiant de client, inscrit dans la base, pour tenir les données de chacun à part. Chaque requête doit filtrer sur cet identifiant. Une seule requête qui l’oublie renvoie les lignes d’une autre école.
L’ANSSI emploie la même grille pour l’hébergement. Son guide de juillet 2024 appelle publique une offre « mutualisée pour l’ensemble des clients de l’offreur ». Il appelle privée une offre dont le processeur, le réseau et le stockage sont physiquement dédiés à un seul client.
L’isolement tient à un réglage, pas à une clause
Une faille entre clients ne demande pas de forcer une porte. En 2022, Wiz, une société de sécurité du cloud, attribuait ces failles à des frontières mal construites , souvent combinées à des erreurs anodines dans les interfaces. Chez Cloudflare, la frontière tenait à une option de stockage. Dans une base partagée, elle tient au filtre de chaque requête.
Ces réglages vivent chez l’éditeur. Le client ne les voit pas, et il ne choisit pas la machine qui l’héberge. Wiz relevait aussi que le secteur n’avait aucune norme de transparence sur l’isolement : certains éditeurs le décrivaient en détail, d’autres n’en disaient presque rien.
L’ANSSI tire de la mutualisation un risque précis. Son guide demande d’inclure dans l’analyse de risques « la mutualisation des infrastructures avec d’autres clients ». Pour les systèmes sensibles, il préconise une infrastructure dédiée, qui empêche un attaquant de passer de l’environnement d’un client à celui d’un autre. L’exemple de mutualisation qu’il donne, des clients qui stockent leurs données sur une même ressource de stockage physique, est la situation que Cloudflare a décrite deux ans plus tard. L’agence ajoute que les attaquants visent ces infrastructures parce qu’elles concentrent les données de nombreux clients, administrées avec les mêmes outils.
Ce guide vise les systèmes de l’État à diffusion restreinte et les opérateurs d’importance vitale ou de services essentiels, pas une école privée. Sa grille sert quand même à une DSI qui confie des dossiers d’étudiants à un éditeur. En février 2025, l’ANSSI recommandait d’ailleurs des offres cloisonnées entre clients pour les activités sensibles.
Ce que le contrat en dit
Le contrat de sous-traitance encadre le traitement : les instructions, les sous-traitants, les audits. L’article sur ce qu’une IA voit de vos dossiers détaille ce que le RGPD y impose. Ce contrat dit rarement comment les écoles clientes sont séparées entre elles. Une clause peut promettre la confidentialité sans dire si votre base est partagée, ni si un disque est effacé avant de passer à un autre client.
La CNIL ne fixe pas de règle sur ce point. Sa fiche sur le cloud , mise à jour en mars 2024, demande notamment d’écrire dans le contrat la répartition des responsabilités de sécurité, d’auditer régulièrement le fournisseur et de refuser toute clause qui lui donnerait accès aux données sans votre autorisation. De ces leviers, seul l’audit vérifie quelque chose. Encore faut-il savoir quoi auditer.
Une plateforme par école rend l’isolement vérifiable
Une plateforme dédiée change la nature de la question. Quand chaque école a son application et sa base, aucune requête ne peut mélanger deux établissements, puisqu’ils ne partagent aucune table. Selon Microsoft , un déploiement par client réduit le risque de fuite accidentelle. La séparation devient un fait d’architecture qu’un auditeur constate, au lieu d’un filtre à relire dans tout le code.
Ce choix a un coût, que la même documentation résume : cent clients coûtent environ cent fois un client, et chaque mise à jour doit atteindre chaque instance. Une école demande donc aussi à quel rythme la sienne reçoit les correctifs. Une plateforme dédiée qu’on oublie de mettre à jour protège mal.
Il ne règle pas tout. Sous l’application, l’hébergeur peut encore partager ses serveurs et ses disques entre ses clients, et la faille de Cloudflare se logeait à ce niveau. La question descend alors d’un cran, vers l’hébergeur, et elle se pose dans les mêmes termes.
Subrequest a fait ce choix : chaque école a sa propre plateforme, et aucune donnée ne passe d’un établissement à un autre. Les questions qui suivent valent pour nous comme pour tout autre éditeur.
Les questions à poser à un éditeur
Chaque question appelle deux réponses possibles. La première tient en une phrase de plaquette ou de contrat. La seconde se montre.
Microsoft conseille de tester le modèle d’isolement, quel qu’il soit, pour vérifier que les données d’un client ne fuient pas vers un autre. Un éditeur qui a mené ce test peut en donner la date.
La cinquième question rejoint celle de la traçabilité. L’affaire de la DGFiP montre ce qu’un journal doit contenir pour dire qui a lu quoi, y compris chez l’éditeur.
Un contrat promet l’isolement, l’architecture le démontre
Sur une plateforme mutualisée, ce qui sépare votre école des autres clients est un réglage de l’éditeur, que le contrat ne montre pas. Une plateforme par école rend cette séparation vérifiable. Le 24 septembre 2026, Cloudflare a révélé qu’une seule option de stockage laissait lire des restes de disque d’autres clients, sur 18 emplacements testés sur 24.
Si vous comparez des éditeurs sur la séparation de vos données, prenez rendez-vous pour en parler avec nous.