Architecture d’un hébergement mutualisé par secteur : santé, éducation

Faut-il héberger un site vitrine associatif et un portail patient sur la même infrastructure parce qu’ils partagent le même thème WordPress ? La question s’est posée concrètement en réorganisant l’hébergement d’un parc mêlant des clients du secteur médical, éducatif et associatif, initialement mutualisés sans distinction particulière sur les mêmes serveurs, faute d’avoir anticipé les implications réglementaires propres à chaque secteur.

Ce texte décrit l’architecture retenue pour séparer ces environnements sans dupliquer intégralement l’infrastructure, et les critères qui ont guidé le découpage entre ce qui pouvait rester mutualisé et ce qui devait être isolé.

Pourquoi le mélange initial posait problème

Le parc reposait initialement sur un socle commun : mêmes serveurs mutualisés, même politique de sauvegarde, mêmes règles de pare-feu appliquées uniformément à l’ensemble des sites. Cette approche fonctionnait tant qu’aucun site ne traitait de données particulièrement sensibles. Un client du secteur médical a changé la donne en demandant un hébergement conforme aux exigences applicables aux données de santé, incompatible avec une infrastructure partagée sans distinction avec un site vitrine associatif classique.

Séparer uniquement ce client aurait été possible, mais un second client du secteur éducatif, gérant des données concernant des mineurs, a soulevé une exigence comparable peu après. Il devenait clair qu’une approche structurelle par secteur, plutôt qu’un traitement au cas par cas, serait plus soutenable dans la durée.

Le découpage retenu : trois périmètres, un socle technique partagé

infrastructure d'agence
 |
 +-- périmètre santé (isolé)
 |     - serveur dédié, chiffrement renforcé
 |     - accès restreint, journalisation exhaustive
 |
 +-- périmètre éducation (isolé)
 |     - serveur dédié, rétention de données encadrée
 |     - anonymisation systématique des environnements de test
 |
 +-- périmètre général (mutualisé)
       - sites vitrines, associatifs, e-commerce standard
       - infrastructure mutualisée classique

Chaque périmètre isolé dispose de son propre serveur, de sa propre politique de sauvegarde et de ses propres règles d’accès, sans partage de ressources avec les deux autres périmètres. Le socle technique — outillage de déploiement, scripts de provisionnement, conventions de nommage — reste commun aux trois périmètres, ce qui évite de tripler la charge d’outillage tout en respectant l’isolation réglementaire exigée.

Ce que l’isolation change concrètement au quotidien

Concrètement, un développeur qui intervient sur le périmètre santé ne dispose pas des mêmes accès que sur le périmètre général : les clés SSH sont distinctes, la journalisation des connexions est plus exhaustive, et toute extraction de données passe par une procédure documentée plutôt que par un accès direct à la base de données de production. Sur le périmètre éducation, l’accent a davantage porté sur l’anonymisation systématique des environnements de test, pour qu’aucune donnée réelle concernant un mineur ne circule en dehors de la production.

Un effet secondaire positif : des audits externes facilités

L’isolation par secteur a simplifié les audits de sécurité externes commandés par certains clients réglementés. Auditer un périmètre clairement délimité, avec un inventaire précis des accès et des flux, prend beaucoup moins de temps que d’auditer un parc mutualisé où il faut d’abord démontrer qu’un site tiers n’a aucune incidence sur le périmètre concerné.

• Documentation d’architecture spécifique à chaque périmètre isolé, tenue à jour en continu
• Registre des accès distinct par périmètre, avec revue trimestrielle
• Procédure d’extraction de données formalisée pour les périmètres réglementés

Le coût de cette organisation

Cette architecture n’est pas gratuite : elle mobilise davantage de serveurs, davantage de temps d’administration système, et impose une discipline de séparation stricte, y compris quand la tentation de simplifier temporairement est grande. Sur un parc de taille modeste, ce coût peut ne pas se justifier ; il devient pertinent dès qu’un client réglementé impose des exigences incompatibles avec une infrastructure partagée.

En résumé

Isoler l’hébergement par secteur réglementaire plutôt que de tout mélanger a demandé un investissement initial conséquent, mais il a évité de traiter chaque nouvelle exigence client comme une exception ponctuelle. Le socle technique commun garde l’agence efficace, l’isolation garde chaque client conforme à ses propres obligations.