Un Groupement Hospitalier de Territoire n’est pas une entreprise. Il n’a pas de profit à optimiser, pas d’actionnaire à satisfaire, pas de stratégie de croissance externe à financer. Ce qu’il a, en revanche, c’est une obligation légale de convergence de ses systèmes d’information, des contraintes réglementaires parmi les plus complexes du secteur public français, et des budgets informatiques structurellement insuffisants face à l’ambition affichée.
Dans ce contexte, choisir ou rénover son ERP n’est pas un projet ordinaire. C’est un exercice qui engage la DSI de l’établissement support sur 5 à 8 ans, mobilise des équipes projets en mode dégradé pendant plusieurs années, et détermine la capacité du GHT à produire des données financières fiables pour piloter ses 5 à 15 établissements membres.
Ce guide s’adresse aux DSI et DAF de GHT. Il cartographie les acteurs du marché, explique les contraintes réglementaires non négociables, et propose une feuille de route réaliste pour un GHT qui engage ou anticipe un projet ERP.
Les GHT en 2026 : mutualisation forcée et contraintes budgétaires
Qu’est-ce qu’un GHT et pourquoi la DSI en est au coeur ?
La loi de modernisation du système de santé du 26 janvier 2016 a créé les Groupements Hospitaliers de Territoire pour obliger les établissements publics de santé d’un même territoire à coopérer autour d’un projet médical partagé. En 2026, la France compte 136 GHT regroupant 898 établissements publics de santé (Ministère de la Santé, carte des GHT 2024), coordonnés par 136 établissements support, dont 32 CHU-CHR.
Chaque GHT couvre un territoire de 100 000 à 2 millions d’habitants et regroupe entre 2 et 20 établissements. Sa gouvernance repose sur un établissement support — généralement le plus grand hôpital du territoire — qui exerce, au nom de l’ensemble des membres, quatre fonctions mutualisées définies par la loi :
- La définition et la mise en oeuvre de la stratégie médicale partagée
- La formation initiale et continue des professionnels
- La gestion et la conduite des activités de soins de suite et de réadaptation
- La mise en place d’un système d’information convergent et interopérable
C’est cette quatrième mission qui place la DSI de l’établissement support au coeur du projet GHT. Elle est responsable devant la loi — article L6132-3 du Code de la santé publique — de la convergence informatique de l’ensemble des membres. Ce n’est pas une recommandation, c’est une obligation légale.
L’obligation de convergence SI entre établissements du même GHT
Dans la pratique, cette obligation de convergence est loin d’être accomplie. Dix ans après la loi, la grande majorité des GHT gèrent encore des parcs applicatifs hétérogènes : chaque établissement membre a son propre système de gestion administrative des patients, sa propre solution RH, parfois son propre logiciel comptable. La convergence, quand elle a eu lieu, s’est souvent limitée aux fonctions de gestion administrative du patient (GAP), laissant de côté les fonctions financières et RH.
La raison est simple : la convergence informatique coûte cher, prend du temps, et génère des résistances humaines fortes. Un établissement de 300 agents qui doit abandonner son ERP maîtrisé pour adopter celui de l’établissement support vit une disruption organisationnelle significative. Les projets s’étirent, les budgets débordent, et les DSI se retrouvent à gérer en parallèle l’ancien et le nouveau système pendant des années.
Le contexte budgétaire : EPRD, PGFP et la pression sur les coûts de gestion
Le budget informatique des hôpitaux publics français représente en moyenne 1,7 % de leurs charges d’exploitation selon l’Atlas SIH / DGOS, alors que le niveau recommandé pour piloter efficacement un SIH de qualité se situe à 3 %. Cet écart structurel — moitié du budget recommandé — explique en partie pourquoi les projets ERP hospitaliers sont si difficiles : ils demandent des investissements significatifs dans des organisations qui n’ont pas l’habitude de financer leur informatique à la hauteur de son rôle.
Pour financer leurs projets SI, les GHT s’appuient sur plusieurs mécanismes :
- L’EPRD (État Prévisionnel des Recettes et Dépenses) : le document budgétaire annuel des établissements publics de santé. Toute dépense informatique d’investissement significative doit y figurer et être validée par l’ARS.
- Le PGFP (Plan Global de Financement Pluriannuel) : la projection financière à 5 ans minimum, obligatoire pour les EPS. C’est dans ce document que se planifient les grands projets ERP.
- HOP’EN et HOP’EN 2 : le programme national de transition numérique des établissements de santé a mobilisé 420 millions d’euros dans le cadre du Grand Plan d’Investissement (Ministère de la Santé, programme HOP’EN). HOP’EN 2, lancé à l’été 2024, prolonge ce soutien avec une ambition renforcée sur la convergence SI des GHT.
Spécificités comptables et réglementaires que l’ERP doit couvrir
Nomenclature M21 et instruction M21
La comptabilité des établissements publics de santé obéit à l’instruction budgétaire et comptable M21, dont la dernière mise à jour substantielle date d’un arrêté du 18 décembre 2024 (collectivites-locales.gouv.fr, instruction M21), applicable à compter du 1er janvier 2025.
La M21 est distincte du plan comptable général (PCG) utilisé par les entreprises privées. Ses spécificités :
- Plan de comptes propre aux EPS, avec une structure qui intègre les recettes T2A (tarification à l’activité) et les dotations MIGAC/DAF
- Nomenclature budgétaire spécifique : les dépenses sont classées en titres (titres 1 à 4) et en groupes fonctionnels
- Comptabilité d’engagement obligatoire : les engagements de dépenses sont enregistrés avant le service fait
- Compte financier annuel avec une présentation réglementée, contrôlée par la Chambre Régionale des Comptes
Un ERP généraliste configuré pour le PCG n’est pas utilisable tel quel dans un EPS. Il doit soit proposer nativement la M21, soit avoir été paramétré de façon certifiée pour la respecter.
EPRD / PGFP / CREA : les outils de pilotage financier hospitalier
Au-delà de la comptabilité courante, l’ERP doit alimenter trois outils de pilotage financier réglementaires :
- L’EPRD : préparé par la direction financière et soumis au vote du conseil de surveillance puis à l’approbation de l’ARS. L’ERP doit produire les états d’EPRD dans le format réglementé.
- Le PGFP : document pluriannuel sur 5 ans minimum. L’ERP doit fournir les données financières historiques et la capacité de modéliser des scénarios prospectifs.
- Le CREA (Compte de Résultat Analytique par activité) : outil de contrôle de gestion qui permet d’analyser les coûts et recettes par pôle, service ou activité. Dans un GHT, produire un CREA consolidé multi-établissements est l’un des défis ERP les plus complexes.
Paie publique : grilles indiciaires, NBI, contractuels
La paie dans un EPS n’est pas une paie de droit privé. Elle obéit aux règles de la Fonction Publique Hospitalière (FPH) : grilles indiciaires par corps et grade, New Bonus Indiciaire (NBI) pour certains emplois, gestion des contractuels avec des règles spécifiques, prime de service, prime multi-établissements pour les agents qui travaillent sur plusieurs sites du GHT.
L’ERP ou le SIRH interfacé doit gérer nativement ces spécificités FPH. Un module paie conçu pour le secteur privé, même fortement paramétré, ne peut pas les couvrir sans risque de non-conformité aux décrets de la FPH.
Marchés publics : MAPA, AO et accord-cadre
Tout achat public au-delà de certains seuils est soumis au Code de la commande publique : Marché à Procédure Adaptée (MAPA) pour les montants inférieurs aux seuils européens, Appel d’Offres (AO) ou accord-cadre pour les montants supérieurs. L’ERP doit s’interfacer avec le profil acheteur de l’établissement (plateforme e-marchés publics) ou intégrer un module achats public complet.
Dans un GHT, la centralisation des achats est l’un des gains attendus de la mutualisation. L’établissement support qui pilote les achats pour l’ensemble des membres a besoin d’un ERP capable de gérer des marchés multi-attributaires avec des notifications de service fait dans chaque établissement.
Interopérabilité avec le DPI et les systèmes SIH
L’ERP hospitalier n’est pas isolé. Il doit s’interfacer avec :
- Le DPI (Dossier Patient Informatisé) : l’ERP reçoit les données d’activité médicale (actes, séjours, consultations) pour calculer les recettes de la T2A et de la tarification médicosociale
- L’outil de facturation : les factures patients sont produites à partir des données croisées du DPI et de l’ERP administratif-financier
- Chorus Pro : la plateforme de facturation électronique de l’État. Les établissements publics de santé sont tenus de transmettre leurs factures aux assureurs complémentaires et organismes payeurs via des flux structurés, avec une obligation renforcée depuis 2024
Ces interfaces doivent être certifiées selon les standards d’interopérabilité de l’Agence du Numérique en Santé (ANS) : HL7 FHIR, IHE XDS/PIX, INS (Identifiant National de Santé).
Le marché ERP des hôpitaux publics : qui sont les acteurs en France ?
Numih France (ex-MiPih) et la suite dh
Le principal acteur national du SIH public est Numih France, groupement d’intérêt public créé en mai 2025 par la fusion de MiPih (Midi Picardie Informatique Hospitalière) et de SIB. Cette fusion crée un acteur de référence pour le numérique hospitalier souverain, avec une clientèle composée exclusivement d’établissements publics de santé.
Numih France édite la suite dh (pour “digital hospitalier”), qui couvre l’ensemble des fonctions de gestion administrative et financière d’un EPS (Numih France, suite dh) :
- dh patient : gestion administrative du patient (GAP), successeur de “Pastel” — l’un des logiciels GAP les plus déployés dans les hôpitaux publics français
- dh appro finance : gestion économique et financière (comptabilité M21, achats publics, facturation)
- dh performance : contrôle de gestion, EPRD, PGFP, CREA analytique
- dh RH : gestion des ressources humaines FPH et paie publique
L’atout différenciant de Numih France est sa connaissance native des contraintes du secteur public hospitalier : la suite dh est construite autour de la M21, de la FPH et des référentiels ANS, sans paramétrage complexe. Son modèle GIP (groupement d’intérêt public) garantit une gouvernance par les établissements membres eux-mêmes — les hôpitaux sont à la fois clients et actionnaires.
Sopra HR Software pour la paie FPH
Sopra HR Software, filiale de Sopra Steria, est un acteur significatif pour la gestion RH et la paie dans le secteur public et parapublic français. Sa suite HR 4YOU (Sopra HR Software) propose des modules adaptés aux contraintes de la Fonction Publique Hospitalière. Plusieurs établissements publics de santé l’utilisent en remplacement ou en complément de leur solution comptable, en particulier lorsqu’ils souhaitent découpler le SIRH de l’ERP financier.
Oracle PeopleSoft dans les grands CHU
Oracle PeopleSoft est présent dans certains CHU-CHR, notamment pour les fonctions RH et finances. Sa profondeur fonctionnelle et sa capacité à gérer des structures complexes multi-entités en font une option pour les très grandes organisations. Ses inconvénients sont significatifs : coût de licence et de maintenance élevé, complexité d’implémentation, et une trajectoire produit qui interroge les DSI depuis l’annonce d’Oracle de migrer progressivement ses clients vers Oracle Cloud.
SAP dans les GHT : rare mais présent
SAP est peu implanté dans les hôpitaux publics français, contrairement à l’Allemagne où SAP IS-H (Industry Solution for Healthcare) est un standard de fait. Les implantations SAP dans des EPS français sont marginales et concernent principalement des fonctions financières dans de très grands CHU. La complexité d’implémentation, le coût de possession et l’absence de paramétrage M21 natif dans les solutions standard SAP expliquent ce faible taux de pénétration.
Les éditeurs régionaux et spécialisés
Plusieurs éditeurs régionaux occupent des niches dans le marché hospitalier public : gestion des stocks pharmaceutiques, logistique hospitalière, gestion des blocs opératoires. Ces solutions s’interfacent avec l’ERP central mais ne le remplacent pas. Le DSI d’un GHT doit souvent composer avec un écosystème de 15 à 30 applicatifs gravitant autour d’un coeur ERP.
La convergence SI dans un GHT : qui hérite de quel système ?
L’établissement support impose-t-il son ERP aux membres ?
C’est la question politique centrale de tout projet de convergence SI dans un GHT. La loi dit que l’établissement support est responsable de la mise en place d’un SI convergent. Elle ne dit pas que les membres doivent adopter la solution de l’établissement support.
En pratique, trois configurations coexistent :
Configuration 1 — Convergence par adoption du système de l’établissement support. C’est le scénario le plus fréquent et le moins coûteux en apparence : les membres abandonnent leur système pour adopter celui de l’établissement support. Il présuppose que le système de l’établissement support est techniquement et fonctionnellement capable de gérer les membres. Ce n’est pas toujours le cas, en particulier pour les fonctions RH où les conventions collectives et les grilles de paie peuvent différer.
Configuration 2 — Refondation sur une nouvelle solution commune. L’établissement support et les membres partent ensemble sur un nouveau système, choisi après un appel d’offres commun. C’est le scénario le plus sain sur le plan de la gouvernance mais le plus coûteux et le plus risqué. Il exige que tous les établissements soient d’accord sur les fonctionnalités cibles, ce qui nécessite un travail d’harmonisation des processus métier avant même de choisir l’outil.
Configuration 3 — Convergence partielle par interopérabilité. Les établissements conservent leurs solutions locales mais les interconnectent via des couches d’échange standardisées (HL7 FHIR, Web Services). Cette approche pragmatique est souvent retenue en attendant la refondation complète. Elle ne résout pas les problèmes de qualité de données et de consolidation financière.
Le rôle de l’ANS et les référentiels HOP’EN
L’Agence du Numérique en Santé (ANS) joue un rôle de standardisation essentiel. Elle publie les référentiels d’interopérabilité auxquels les éditeurs de SIH doivent se conformer pour que leurs produits puissent communiquer. Elle gère notamment :
- Le Référentiel National d’Interopérabilité (RNI) et les profils IHE
- La gestion de l’INS (Identifiant National de Santé), obligatoire depuis 2021 pour tous les documents médicaux
- La certification des hébergeurs de données de santé (HDS)
Pour un GHT qui évalue un ERP, la conformité ANS et la présence sur la liste des éditeurs certifiés HDS sont des prérequis, pas des options.
Feuille de route type pour un GHT qui refond son ERP
Phase 1 — État des lieux (3 à 6 mois)
Avant de choisir une solution, le GHT doit produire une cartographie exhaustive :
- Inventaire de tous les applicatifs de chaque établissement membre (ERP financier, GAP, SIRH, gestion des stocks, etc.)
- Cartographie des interfaces existantes entre ces systèmes
- Évaluation du niveau de dette technique de chaque système (fin de vie éditeur ? sous-version non maintenue ?)
- Identification des processus métier qui divergent entre établissements (comptabilité, achats, RH)
Ce travail prend du temps et est souvent sous-estimé. La qualité de l’état des lieux conditionne directement la qualité des spécifications du futur système.
Phase 2 — Définition du système cible et gouvernance (4 à 8 mois)
La définition du système cible passe par un Schéma Directeur des Systèmes d’Information (SDSI) à l’échelle du GHT. Ce document :
- Fixe l’architecture cible (ERP centralisé ? Fédéré ? Hybride ?)
- Définit le périmètre fonctionnel couvert par l’ERP (GAP + finances + RH ? ou seulement finances et RH ?)
- Planifie le déploiement par établissement et par module
- Fixe le budget sur 5 ans intégrant licences, implémentation, formation et maintenance
La gouvernance du projet est critique : un comité de pilotage inter-établissements, avec des représentants des directions financières, RH et médicales de chaque membre, doit valider chaque étape. Sans gouvernance formalisée, le projet dérivera.
Phase 3 — Déploiement par vagues (18 à 36 mois)
Le déploiement dans un GHT suit toujours la même logique : l’établissement support en premier, puis les membres par ordre de complexité croissante.
Chaque déploiement établissement suit les phases classiques d’un projet ERP :
- Atelier de paramétrage (fit-to-standard ou fit-to-template)
- Reprise des données historiques (balance comptable, référentiel agents RH)
- Tests utilisateurs, recette, formation
- Bascule en production (go-live), généralement au 1er janvier pour les fonctions financières
Pour les GHT de taille moyenne (5 à 10 établissements), la durée totale du déploiement dépasse rarement 30 mois si les décisions de gouvernance sont prises rapidement.
Phase 4 — Consolidation et reporting de groupe (post go-live)
Une fois les établissements basculés, le travail de consolidation commence : produire des états financiers consolidés à l’échelle du GHT, un EPRD de groupe, un CREA consolidé. Ce chantier est souvent plus long et plus difficile que prévu car il révèle des divergences de pratiques comptables entre établissements qui n’avaient jamais été confrontées.
5 points de vigilance spécifiques aux projets ERP en GHT
1. La gouvernance politique avant la technique. Un projet ERP dans un GHT échoue rarement pour des raisons techniques. Il échoue quand les directeurs d’établissements membres n’ont pas été suffisamment associés à la décision initiale et s’y opposent en cours de projet. Investir dans la gouvernance inter-établissements avant le choix de l’outil est un prérequis.
2. La reprise des données historiques M21. Migrer les historiques comptables d’un EPS d’un ancien système vers un nouveau est un chantier considérable. Les balances de comptes M21 sur 10 ans, les engagements en cours, les marchés ouverts — tout doit être repris sans erreur. Les projets qui minimisent ce chantier en phase d’estimation dévissent leur planning en phase d’exécution.
3. La gestion des agents multi-sites. Dans un GHT, un agent peut être affecté à plusieurs établissements. L’ERP RH doit gérer les paies fractionnées inter-établissements sans créer de doublons dans les fichiers de paie. Ce scénario, simple en apparence, est un point de complexité technique important.
4. La continuité de service lors de la bascule. Un hôpital ne peut pas s’arrêter pendant un go-live. Les processus critiques — paie des agents, facturation des séjours, achats urgents — doivent rester opérationnels pendant la phase de bascule. Planifier les go-lives en dehors des périodes de clôture comptable et des pics d’activité médicale est impératif.
5. La formation dans un contexte de turn-over élevé. Les hôpitaux publics connaissent un fort turn-over sur certaines fonctions administratives et soignantes. Le plan de formation doit prévoir des dispositifs de formation continue, pas seulement une formation initiale au go-live.
Ressources utiles pour aller plus loin
- Agence du Numérique en Santé (ANS) : référentiels d’interopérabilité, certification HDS, programme HOP’EN
- ATIH (Agence Technique de l’Information sur l’Hospitalisation) : nomenclatures T2A, PMSI, outils de contrôle de gestion hospitalière
- Fédération Hospitalière de France (FHF) : documentation M21, guides pratiques EPRD/PGFP, retours d’expérience GHT
- ANAP (Agence Nationale d’Appui à la Performance) : outils de benchmarking SI, accompagnement méthodologique des projets SIH
Pour structurer votre appel d’offres ERP, notre guide des 50 questions à poser aux prestataires ERP liste les critères clés à inclure dans tout RFP — y compris les questions spécifiques à la conformité M21 et aux interfaces ANS. Si votre contexte est plus large, notre comparatif ERP santé privée (cliniques, EHPAD) permet de mesurer les différences de contraintes entre secteur public hospitalier et secteur privé.
