Plusieurs ESMS, une seule équipe IT, un seul outil. C'est le pari de l'ITSM mutualisé — et il est de plus en plus tenu dans le secteur médico-social. Que ce soit au sein d'un GCSMS, d'un GTSMS, d'un SIP-ESMS ou d'un groupement informel, la mutualisation du support IT permet à des établissements qui n'ont pas les moyens d'une DSI complète d'accéder à un niveau de service professionnel. Encore faut-il choisir le bon outil — et anticiper les enjeux de gouvernance et de conformité que cette organisation soulève.
ITSM mutualisé en ESMS : comment plusieurs établissements partagent un seul support IT
GCSMS, GTSMS, SIP-ESMS, grappe Ségur : la mutualisation du SI médico-social s'accélère. Voici comment structurer un ITSM partagé entre plusieurs ESMS — et les écueils à anticiper.
Un ITSM mutualisé n'est pas juste un outil partagé entre plusieurs établissements. C'est une organisation, une gouvernance, et des règles claires sur qui décide, qui paie et qui est responsable des données. Sans ce cadre, la mutualisation technique crée autant de problèmes qu'elle n'en résout.
Pourquoi la mutualisation du support IT s'accélère dans les ESMS
La plupart des ESMS n'ont pas les moyens de financer une DSI complète. Un EHPAD de 80 résidents, un SSIAD de 15 salariés ou un IME géré par une petite association ne peuvent généralement pas recruter un DSI, un responsable cybersécurité et un technicien informatique en interne. La mutualisation est donc une réponse structurelle à cette contrainte — et elle s'est considérablement accélérée depuis 2023.
Les formes de mutualisation IT dans le secteur médico-social
GCSMS / GCSM
Le Groupement de Coopération Sociale et Médico-Sociale permet à des structures de droit public et privé de coopérer. Il peut porter une DSI partagée, mutualiser les outils et les compétences SI entre membres.
GTSMS
Le Groupement Territorial Social et Médico-Social (réforme en cours) vise à mutualiser les fonctions support des ESMS publics à l'échelle d'un territoire, dont les SI et le numérique.
SIP-ESMS
Porté par l'URIOPSS ARA, le Service Informatique Partagé pour les ESMS est une association loi 1901 permettant à des petites structures de bénéficier d'une DSI partagée professionnelle — avec l'appui d'Isi-DSI.
Grappe ESMS Numérique
Plusieurs structures s'agrègent autour d'un projet commun pour accéder aux financements du programme ESMS Numérique. Les dossiers portés en groupement ont un meilleur taux de succès et sécurisent le déploiement.
Ce que la mutualisation IT change concrètement pour les ESMS membres
Pour les établissements qui rejoignent un dispositif de SI mutualisé, les bénéfices sont immédiats et mesurables. En effet, une étude récente sur les organisations multi-sites indique que la gestion IT décentralisée génère des coûts cachés supérieurs de 30 % à une approche unifiée. Dans le secteur médico-social, ce chiffre est souvent encore plus élevé compte tenu de la dispersion géographique des établissements et de la faiblesse des équipes IT internes.
- Accès à des compétences inaccessibles seul : cybersécurité, gestion de projet SI, expertise HospiConnect, conformité HDS — des profils impossibles à recruter à temps plein dans une petite structure.
- Réduction des coûts par mutualisation : licences logicielles, infrastructure, support — le coût par établissement diminue à mesure que le nombre de membres augmente.
- Continuité de service améliorée : une équipe mutualisée assure la permanence du support même en cas d'absence d'un technicien — contrairement à un technicien unique en interne.
- Meilleure posture cyber : les ESMS mutualisés peuvent accéder à des diagnostics cyber, exercices de crise et accompagnements CaRE plus facilement que des structures isolées.
Les 5 défis d'un ITSM mutualisé entre ESMS
Mutualiser le support IT entre plusieurs ESMS n'est pas qu'une question technique. C'est un projet organisationnel et juridique — avec des écueils bien identifiés que les groupements qui se lancent trop vite découvrent à leurs dépens.
1. La gouvernance : qui décide quoi ?
Dans un ITSM mutualisé, les décisions sur les outils, les priorités et les SLA concernent plusieurs établissements avec des intérêts parfois divergents. Il faut donc définir dès le départ : qui valide les choix technologiques, qui arbitre les priorités de support entre établissements, qui peut modifier les paramètres de l'outil et selon quelle procédure. Sans gouvernance formalisée, les conflits entre membres sont inévitables.
2. La répartition des coûts
Comment répartir le coût de l'ITSM entre les membres ? À parts égales ? Au prorata du nombre d'utilisateurs ? Du nombre de tickets traités ? De la taille de l'établissement ? Chaque clé de répartition a ses avantages et ses inconvénients. L'essentiel est qu'elle soit définie contractuellement dès le départ — et que son évolution soit prévue en cas d'entrée ou de sortie d'un membre.
3. La séparation des données entre membres
C'est le point le plus critique juridiquement. Dans un outil ITSM mutualisé, les tickets, les inventaires et les journaux d'audit de chaque établissement doivent être strictement isolés des autres membres — même si tous partagent la même instance applicative. Un technicien de l'établissement A ne doit pas pouvoir accéder aux données de l'établissement B. Cette exigence doit être vérifiée techniquement avant tout déploiement.
Point RGPD critique : dans un GCS de moyens, la convention constitutive doit définir explicitement, activité par activité, qui est responsable de traitement, co-responsable ou sous-traitant. Pour un SI mutualisé, cette qualification détermine les obligations de chaque membre en cas d'incident ou de contrôle CNIL. Un DPO mutualisé peut être désigné — mais son périmètre doit être clairement délimité dans la convention.
4. Les SLA différenciés par établissement
Tous les établissements n'ont pas les mêmes besoins ni la même criticité. Un EHPAD avec des équipements médicaux connectés a des exigences de délai de résolution différentes d'un ESAT ou d'un foyer de vie. Un bon ITSM mutualisé doit permettre de définir des niveaux de service (SLA) par établissement — et de mesurer leur respect en temps réel. Sans cette granularité, les membres les plus exigeants seront insatisfaits et les membres les moins critiques surpayeront.
5. L'hébergement conforme HDS pour tous les membres
Dès lors que des données de santé transitent dans le système mutualisé — tickets liés à des accès DUI, journaux d'audit d'habilitations, incidents sur des équipements médicaux — l'hébergeur doit être certifié HDS. Cette certification doit couvrir l'ensemble des membres du groupement, pas seulement le porteur. Par ailleurs, dans le cadre de la réforme GTSMS, la question de l'exemption HDS pour les groupements publics fait actuellement débat — mais la prudence s'impose en attendant les textes définitifs.
Ce qu'un ITSM mutualisé doit permettre techniquement
Avant de choisir un outil pour un groupement ESMS, voici les fonctionnalités qui ne sont pas optionnelles dans un contexte mutualisé.
Chaque ESMS membre doit avoir son espace étanche — tickets, inventaire, utilisateurs, SLA. Un technicien ne voit que les données des établissements auxquels il est rattaché.
La DSI mutualisée a besoin d'une vue globale pour piloter l'activité. Chaque directeur d'établissement membre a besoin de voir uniquement les indicateurs de son site. Les deux niveaux de lecture doivent coexister.
Chaque établissement doit pouvoir avoir ses propres engagements de service — délai de prise en charge, délai de résolution, plages horaires de support. Et leur suivi doit être automatique.
Un technicien référent multi-sites peut accéder à plusieurs établissements. Un correspondant IT local ne voit que son site. La granularité des droits doit s'adapter à l'organisation réelle du groupement.
Les journaux d'audit doivent être exportables établissement par établissement — pour permettre à chaque membre de justifier sa conformité RGPD indépendamment des autres.
Comment Isi-APP structure l'ITSM mutualisé entre ESMS
Isi-APP est pensé pour les organisations multi-entités depuis sa conception — pas par adaptation. C'est précisément la raison pour laquelle il est utilisé dans plusieurs dispositifs de mutualisation SI dans le secteur médico-social, dont le SIP-ESMS porté avec Isi-DSI.
Multi-entités natif avec cloisonnement garanti
Chaque ESMS membre dispose de son espace étanche dans la même instance Isi-APP : tickets, inventaire de parc, utilisateurs, habilitations, journaux d'audit. Les droits d'accès sont configurables à la granularité du profil et du périmètre. Un administrateur du groupement a une vue consolidée ; un référent local ne voit que son établissement.
Tableaux de bord consolidés et par établissement
La DSI mutualisée dispose d'un tableau de bord global — volume de tickets, délais de résolution, charge par technicien, répartition par site. Chaque directeur d'ESMS membre accède à un reporting limité à son périmètre. En conséquence, le pilotage de la DSI mutualisée et le suivi par chaque membre sont disponibles sans export ni retraitement manuel.
L'exemple du SIP-ESMS : une DSI partagée opérationnelle
Le SIP-ESMS, porté par l'URIOPSS ARA en partenariat avec Isi-DSI, est un exemple concret de ce que la mutualisation SI peut produire dans le médico-social. Plusieurs petites structures associatives bénéficient d'une DSI partagée professionnelle — avec une équipe dédiée, des outils mutualisés et un accompagnement adapté à chaque niveau de maturité. Pour ces structures, l'accès à Isi-APP dans ce cadre mutualisé représente un saut qualitatif inaccessible à l'échelle d'un seul établissement.
Ce qu'un ITSM mutualisé bien structuré apporte au groupement
FAQ : ITSM mutualisé ESMS
QFaut-il créer un GCSMS pour mutualiser son ITSM ?
Non — le GCSMS est une forme juridique parmi d'autres. Une simple convention de coopération entre établissements peut suffire pour partager un outil ITSM. En revanche, dès lors que des données de santé transitent dans l'outil partagé, la question de la responsabilité de traitement RGPD doit être formalisée — quelle que soit la forme juridique retenue.
QComment répartir le coût d'un ITSM mutualisé entre les membres ?
Plusieurs clés de répartition sont possibles : au prorata du nombre d'utilisateurs, du nombre de tickets traités, de la taille de l'établissement ou à parts égales. La clé la plus courante dans les groupements ESMS est le prorata du nombre d'utilisateurs actifs — elle est simple à calculer et évolue naturellement avec la taille de chaque membre. Elle doit être inscrite dans la convention de coopération avec une procédure de révision annuelle.
QUn ESMS peut-il quitter un dispositif de SI mutualisé sans perdre ses données ?
Oui — à condition que cette sortie soit prévue contractuellement. La convention de coopération doit prévoir les modalités d'export des données de l'établissement sortant, le délai de conservation par le groupement et la procédure de suppression. Dans Isi-APP, les données de chaque établissement sont cloisonnées et exportables indépendamment — ce qui facilite les entrées et les sorties de membres sans disruption pour le reste du groupement.
QLe SIP-ESMS est-il accessible à tous les ESMS ?
Le SIP-ESMS est principalement accessible aux structures des régions couvertes par les URIOPSS partenaires (ARA, PACA, Occitanie). Pour les ESMS d'autres régions, des dispositifs similaires peuvent exister via les GRADeS ou les URIOPSS locales. Contactez Isi-DSI pour vérifier les dispositifs disponibles dans votre territoire et votre éligibilité à un accompagnement mutualisé.
Sur le même sujet
Ressources complémentaires — Blog Isi-DSI
Isi-APP est édité par Isi-DSI, partenaire du SIP-ESMS et spécialiste de la DSI partagée pour les établissements médico-sociaux.
Vous souhaitez mutualiser votre support IT avec d'autres ESMS ?
Nos experts font le point sur votre situation, votre territoire et les dispositifs disponibles — SIP-ESMS, groupement, convention de coopération — pour trouver la formule adaptée.
Prendre RDV →