Développement sur mesure vs éditeur de SIH : quand choisir quoi ?
24/02/2026
Quand un hôpital public a un besoin informatique, la première question est souvent : faut-il acheter une solution éditeur ou développer sur mesure ?
La réponse n'est pas binaire. Aucun hôpital ne fonctionne à 100% sur un progiciel éditeur, et aucun n'a intérêt à tout développer en interne. La réalité, c'est un modèle hybride où l'éditeur de SIH couvre le socle (DPI, GAP, pharmacie), et le développement sur mesure comble les besoins spécifiques que le progiciel ne couvre pas.
Ce guide aide les DSI hospitaliers à identifier quand le progiciel éditeur est la bonne réponse, quand le développement sur mesure est nécessaire, et comment les deux coexistent dans une architecture hospitalière cohérente.
Le paysage des éditeurs de SIH en France
Avant de parler de sur mesure, il faut comprendre ce que couvrent les éditeurs. En France, 15 éditeurs détiennent 83% du marché des systèmes d'information hospitaliers (étude Sesam-Vitale 2022). Les principaux :
| Éditeur | DPI | Positionnement | Référencement Ségur V2 |
|---|---|---|---|
| Dedalus | DxCare → Care4U | Leader européen. 39 hôpitaux AP-HP, 75 000 utilisateurs | En cours |
| Maincare | M-CrossWay | 130+ établissements dont 7 CHU/CHR. Stratégie multi-entités GHT | Oui |
| Softway Medical | Hopital Manager | "Best in KLAS" 2025. Seul éditeur français avec continuité ville-hôpital | Oui |
| Berger-Levrault | Expert Santé | Fort sur la gestion administrative (SIGEMS). Plus orienté cliniques privées | Oui |
| Numih France | Sillage | GIP public (fusion Mipih + SIB). 100+ établissements. Gouvernance hospitalière | Oui |
| OpenXtrem (Softway) | MediBoard | Open source. 60+ établissements. Modèle modulaire | Partiel |
Ces éditeurs couvrent le socle fonctionnel standard : dossier patient, prescription, planification, gestion administrative, pharmacie, bloc opératoire.
Le budget informatique des hôpitaux ne représente que 2% des dépenses totales (jusqu'à 5,4% pour les centres de lutte contre le cancer). C'est peu, et ça oblige à faire des choix.
Ce que les éditeurs de SIH couvrent bien
Les progiciels éditeur sont la bonne réponse pour :
- Le DPI (Dossier Patient Informatisé) : c'est le cœur du SIH. Aucun hôpital n'a intérêt à développer un DPI en interne. Les éditeurs ont des décennies de retour d'expérience, le référencement Ségur, et la maintenance réglementaire incluse.
- La GAP (Gestion Administrative du Patient) : admissions, mouvements, sorties, facturation T2A.
- Le circuit du médicament : prescription, dispensation, traçabilité.
- Le bloc opératoire : planification, feuilles d'anesthésie, comptes-rendus.
- La conformité Ségur : les éditeurs référencés prennent en charge l'intégration des 5 services socles (INS, MSSanté, Pro Santé Connect, DMP, Mon espace santé) et reçoivent directement le financement SONS.
Pour ces fonctions standard, le progiciel éditeur est plus économique, plus rapide à déployer, et plus facile à maintenir qu'un développement interne.
Les limites documentées des progiciels SIH
Mais les progiciels ne couvrent pas tout. Les retours du terrain sont sans ambiguïté :
Les modules métier spécialisés sont souvent inadaptés
Le cas le plus documenté est celui des urgences. Selon DSIH, les DSI hospitaliers "n'arrivent pas à basculer les urgentistes sur les modules urgences des DPI, souvent mal adaptés aux besoins cliniques". Des outils spécialisés comme Terminal Urgences ont réussi là où les modules standard ont échoué, parce qu'ils ont été conçus avec les praticiens, pas en parallèle.
L'interopérabilité reste un point faible
Il n'existe pas d'interopérabilité totale entre les SIH. Un médecin ne peut pas travailler dans l'hôpital A de la même manière que dans l'hôpital B du même territoire. Certains éditeurs refusent de communiquer leurs spécifications d'interface pour bloquer la concurrence.
La BI n'est pas le cœur de métier des éditeurs DPI
Le PMSI a plus de 30 ans d'historique et reste problématique pour refléter fidèlement les populations de patients. Les plateformes de BI hospitalières (Maincare M-DATA, Magellan, outils Elap) se développent en parallèle du SIH principal, parce que les besoins analytiques dépassent ce que le DPI propose en standard.
Le coût d'un DPI complet est considérable
Pour donner un ordre de grandeur : le déploiement d'Orbis (Dedalus) à l'AP-HP a coûté 130 millions d'euros sur 11 ans (2008-2019) pour 39 hôpitaux et 75 000 utilisateurs. Le coût de licence seul représentait 25 millions d'euros, avec un coût de fonctionnement annuel de 7,5 millions d'euros. Et l'audit interne a montré des problèmes de performance et un surcoût de +40 minutes de saisie par jour et par utilisateur.
Quand le développement sur mesure est la bonne réponse
Le développement sur mesure devient nécessaire quand le besoin sort du périmètre standard des éditeurs. Voici les cas d'usage les plus fréquents :
1. Tableaux de bord et BI hospitalière
Les besoins analytiques des directions médicales, des DIM, et des directions qualité vont au-delà de ce que proposent les modules standard. Exemples :
- Tableau de bord de suivi d'activité chirurgicale en temps réel (c'est exactement ce que Bob le développeur a développé avec CareSentinel pour l'AP-HP)
- Pilotage PMSI avec machine learning prédictif
- Indicateurs qualité IQSS et préparation certification HAS
- Consolidation multi-sites pour les GHT
2. Portails patients
La pré-admission dématérialisée, le suivi en temps réel pour les familles (maternité, chirurgie), le télésuivi post-hospitalisation — ces fonctionnalités sont rarement couvertes correctement par les DPI standard. Les portails patients nécessitent une UX adaptée au grand public, pas aux professionnels de santé.
3. Outils métiers départementaux
Chaque service hospitalier a des workflows spécifiques que le DPI généraliste ne couvre pas :
- Coordination des soins palliatifs
- Suivi de cohortes en recherche clinique (e-CRF)
- Gestion des flux aux urgences (triage, orientation)
- Outils de pharmacovigilance spécialisés
4. Connecteurs d'interopérabilité
Quand il faut interfacer le DPI avec un système tiers (logiciel de recherche, outil d'un prestataire externe, base nationale), un développement spécifique est souvent nécessaire. C'est le rôle des connecteurs FHIR/HL7 et des middlewares d'intégration.
5. Outils de pilotage et reporting réglementaire
Reporting CAQES, indicateurs Hop'EN, préparation audits HAS, suivi des contrats de bon usage — autant de besoins qui nécessitent des outils adaptés aux spécificités de chaque établissement.
Comparaison : éditeur SIH vs développement sur mesure
| Critère | Éditeur SIH | Développement sur mesure |
|---|---|---|
| Couverture fonctionnelle standard | Large (DPI, GAP, pharmacie, bloc) | Ciblée sur un besoin précis |
| Adaptation au workflow spécifique | Paramétrable mais limité | Conçu pour le besoin exact |
| Conformité Ségur | Intégrée (référencement éditeur) | Possible via PFI ou référencement propre |
| Délai de déploiement | 12-24 mois (DPI complet) | 3-6 mois (application métier) |
| Coût initial | Élevé (licence + déploiement) | Variable (adapté au périmètre) |
| Coût de maintenance | Inclus dans le contrat éditeur | À charge du commanditaire |
| Interopérabilité | Dépend de l'éditeur | Contrôle total (FHIR, HL7) |
| Vendor lock-in | Élevé (formats propriétaires) | Faible (code source propriété du client) |
| Adoption utilisateur | Variable (outil généraliste) | Élevée si co-conçu avec les praticiens |
| Pérennité | Dépend de l'éditeur et du marché | Dépend de la maintenance |
L'approche hybride : comment ça fonctionne en pratique
La réalité dans les hôpitaux français est déjà hybride. Un SIH typique se compose de :
┌─────────────────────────────────────────────────────┐
│ SERVICES NATIONAUX │
│ INS · MSSanté · DMP · Mon espace santé │
└────────────────────────┬────────────────────────────┘
│
┌────┴────┐
│ PFI │ ← Plateforme d'Intermédiation
└────┬────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌───┴───┐ ┌────┴────┐ ┌─────┴─────┐
│ DPI │ │ BI │ │ PORTAIL │
│Éditeur│ │ Custom │ │ PATIENT │
│ SIH │ │Dashboard│ │ Custom │
└───┬───┘ └─────────┘ └───────────┘
│
├── GAP (éditeur)
├── Pharmacie (éditeur)
├── Bloc opératoire (éditeur)
└── Modules départementaux (mixte)
Le DPI éditeur gère le socle clinique et administratif. La PFI (Plateforme d'Intermédiation) fait le lien avec les services nationaux — elle peut être portée par le DPI lui-même, par un EAI (Enterprise Application Integration), ou par un composant dédié. Les applications sur mesure (BI, portails patients, outils métiers) s'interfacent avec le DPI via des standards ouverts (FHIR, HL7).
C'est dans cette couche d'applications complémentaires que le développement sur mesure apporte le plus de valeur.
La PFI : le chaînon manquant
La PFI est un composant clé du Ségur du numérique. Elle permet à des applications qui ne sont pas elles-mêmes référencées Ségur de communiquer avec les services nationaux (DMP, MSSanté, Mon espace santé). Lifen, leader du marché, traite plus de 2,3 millions de comptes-rendus médicaux par mois avec un taux d'intégration DMP de 98,5%.
Pour un hôpital qui développe des applications sur mesure, la PFI est le moyen de rester conforme au Ségur sans passer par le processus complet de référencement ANS.
Arbre de décision
Pour chaque besoin, posez-vous ces questions dans l'ordre :
1. Ce besoin est-il couvert par mon DPI actuel ? → Si oui : utilisez le module existant (même imparfait, le coût de maintenance séparé n'en vaut pas la peine)
2. Un module complémentaire de mon éditeur SIH le couvre-t-il ? → Si oui : évaluez le coût et l'adéquation. L'avantage est l'intégration native avec le DPI.
3. Un logiciel spécialisé du marché le couvre-t-il ? → Si oui : évaluez le coût d'intégration avec votre SIH. Si l'intégration est simple (API, FHIR), c'est souvent la meilleure option.
4. Le besoin est-il trop spécifique pour un produit standard ? → C'est le territoire du développement sur mesure. Le besoin est propre à votre établissement, à votre organisation, à vos workflows. Aucun éditeur ne le couvrira parce que le marché est trop petit pour justifier un produit.
Les risques du sur mesure en milieu hospitalier (et comment les gérer)
Le développement sur mesure n'est pas sans risque. 70% des projets IT hospitaliers qui échouent présentent des défauts de cadrage ou de gouvernance dès le départ (DREES).
Risque 1 : la maintenance à long terme
Un logiciel éditeur inclut la maintenance dans le contrat. Un développement sur mesure ne se maintient pas tout seul. Il faut budgéter :
- Les mises à jour de sécurité
- L'évolution réglementaire (Ségur, RGPD, NIS2)
- Les montées de version techniques (frameworks, OS, navigateurs)
Comment le gérer : prévoir un contrat de maintenance dès le départ. Bob le développeur propose un accompagnement continu après la mise en production.
Risque 2 : la conformité réglementaire
Une application sur mesure qui traite des données de santé doit être hébergée sur une infrastructure certifiée HDS, respecter le RGPD santé, et s'intégrer avec les services du Ségur via la PFI.
Comment le gérer : choisir un prestataire qui maîtrise ces contraintes dès la conception.
Risque 3 : le silotage
Une application sur mesure mal intégrée devient un silo de données. Les informations ne circulent pas vers le DPI, les professionnels saisissent deux fois, l'adoption chute.
Comment le gérer : imposer l'interopérabilité FHIR/HL7 dès le cahier des charges. Pas d'intégration propriétaire.
Comment Bob le développeur intervient dans ce contexte
Bob le développeur est une agence de développement sur mesure qui intervient en complément des éditeurs de SIH, pas à leur place. L'agence ne développe pas de DPI. Elle développe les applications métiers complémentaires que le DPI ne couvre pas :
- Tableaux de bord BI : CareSentinel pour l'AP-HP — suivi d'activité chirurgicale en temps réel avec machine learning
- Portails patients : pré-admission, suivi pour les familles, télésuivi post-hospitalisation
- Connecteurs d'interopérabilité : intégration FHIR/HL7 entre le DPI et des systèmes tiers
- Outils métiers spécifiques : applications adaptées aux workflows de chaque service
L'agence a été fondée en 2017 par des entrepreneurs issus de la télémédecine. Elle travaille directement avec l'AP-HP et l'ATIH, facture via Chorus Pro, et connaît les processus de marchés publics.
Pour discuter d'un projet de développement complémentaire à votre SIH, prenez rendez-vous.
Conclusion
La question n'est pas "développement sur mesure OU éditeur de SIH". C'est "quel développement sur mesure, EN PLUS de l'éditeur de SIH". Tous les hôpitaux ont un DPI éditeur. La plupart ont aussi des besoins spécifiques que ce DPI ne couvre pas.
L'enjeu pour un DSI est d'identifier ces besoins, de choisir le bon type de prestataire, et de s'assurer que l'application sur mesure s'intègre proprement dans l'architecture existante via les standards d'interopérabilité.
Pour approfondir : comment choisir un prestataire de développement e-santé, Ségur du numérique Vague 2, interopérabilité FHIR en France, développement pour les institutions de santé publiques.
Sources : Sesam-Vitale — Étude de marché 2022, DSIH — Panorama des éditeurs, AP-HP — Orbis 11 ans, ANS — Ségur hôpital. Dernière mise à jour : mars 2026.