Comment choisir un prestataire de développement pour un projet e-santé hospitalier
17/02/2026
Vous êtes DSI d'un hôpital public, responsable SI d'un GHT, ou chef de projet e-santé. Vous avez un besoin de développement : un portail patient, un tableau de bord d'activité, un connecteur d'interopérabilité, ou un outil métier spécifique. Vous devez choisir un prestataire.
Le problème : le marché est opaque. Éditeurs de SIH, grandes ESN, agences spécialisées, freelances — chacun a un positionnement différent et tous ne se valent pas pour un projet hospitalier. Les enjeux réglementaires (HDS, RGPD santé, Ségur du numérique) ajoutent une couche de complexité que les grilles d'évaluation standard ne couvrent pas.
Ce guide donne 8 critères concrets pour évaluer un prestataire de développement dans le contexte spécifique de la e-santé hospitalière en France, et explique quel type de partenaire choisir selon votre besoin.
1. Vérifier l'expertise du domaine santé (pas juste l'expertise technique)
Un bon développeur React ne fait pas automatiquement un bon développeur d'applications hospitalières. Le secteur de la santé a ses propres contraintes :
- Parcours patient : le prestataire doit comprendre les workflows hospitaliers (admission, séjour, sortie), le codage médical (CIM-10, CCAM), et les circuits de soins
- Réglementation : connaissance du Code de la santé publique, des obligations HDS, du RGPD appliqué aux données de santé, et du Ségur du numérique
- Vocabulaire : si votre prestataire ne sait pas ce qu'est un DPI, un PMSI, un GHT ou une PFI, il va passer ses premiers mois à apprendre au lieu de produire
Comment tester : demandez-lui d'expliquer la différence entre la Vague 1 et la Vague 2 du Ségur, ou ce que couvre la certification HDS activité 5. S'il ne sait pas répondre, il n'a pas l'expertise nécessaire.
2. Exiger des références vérifiables en milieu hospitalier
Dans les marchés publics hospitaliers, les références comptent pour 5 à 15% de l'évaluation. Mais au-delà du score, une référence hospitalière démontre que le prestataire :
- Sait travailler dans un environnement contraint (sécurité, disponibilité, confidentialité)
- A déjà intégré des systèmes avec un SIH existant
- Comprend les processus de validation et de mise en production en milieu hospitalier
- A l'habitude des cycles de décision longs du secteur public
Ce qu'il faut demander :
- Nom de l'établissement (les références anonymes ne valent rien en B2G)
- Périmètre de l'intervention
- Durée et résultats mesurables
- Contact d'un référent côté hôpital
Red flag : un prestataire qui n'a aucune référence en santé et aucun client hospitalier. Le risque de découvrir les contraintes du secteur en cours de projet est trop élevé.
3. Vérifier la maîtrise de l'interopérabilité (FHIR, HL7, CI-SIS)
Tout projet hospitalier finit par se poser la question de l'interopérabilité : comment l'application va-t-elle communiquer avec le DPI, le SIH, les services nationaux ?
Le prestataire doit maîtriser :
- HL7 FHIR (Fast Healthcare Interoperability Resources) : le standard cible pour tous les échanges de données de santé en France. Les profils FR Core de l'ANS définissent les spécifications françaises.
- CI-SIS : le Cadre d'Interopérabilité des Systèmes d'Information de Santé, défini par l'ANS. Trois couches : contenu, service, transport.
- Les services socles nationaux : INS, MSSanté, Pro Santé Connect, DMP/Mon espace santé. Toute application qui échange des données de santé doit s'intégrer avec ces services.
Comment tester : demandez au prestataire de décrire comment il intégrerait une application avec le DPI existant de votre établissement. S'il ne mentionne pas FHIR ou HL7, il va développer une intégration propriétaire qui deviendra une dette technique.
4. S'assurer de la conformité HDS et RGPD santé
Les données de santé sont des données sensibles au sens de l'article 9 du RGPD. Leur traitement est soumis à des obligations renforcées.
Ce que le prestataire doit garantir :
- Hébergement HDS : les données de santé doivent être hébergées chez un prestataire certifié HDS. Le prestataire doit préciser quel hébergeur il utilise et pour quelles activités (infrastructure, plateforme, infogérance). Attention : le nouveau référentiel HDS entre en vigueur en mai 2026 avec des exigences renforcées de souveraineté.
- Privacy by design : chiffrement au repos et en transit, contrôle d'accès basé sur les rôles (RBAC), traçabilité des accès, cloisonnement des données
- AIPD : pour les traitements à risque, une Analyse d'Impact relative à la Protection des Données est obligatoire
- Localisation des données : dans l'Espace Économique Européen. Un prestataire qui utilise des services cloud sans région européenne certifiée HDS est hors cadre.
Red flag : un prestataire qui ne connaît pas la différence entre "hébergeur HDS certifié activité 1-2-3" et "hébergeur HDS certifié activité 5". Ou qui propose d'héberger les données sur un cloud non certifié HDS "pour le MVP" avec une migration ultérieure.
5. Évaluer la connaissance du Ségur du numérique
Le Ségur du numérique en santé conditionne une grande partie des projets hospitaliers actuels. Un prestataire qui intervient dans le SI hospitalier doit connaître :
- Les couloirs qui concernent votre établissement (DPI, PFI, RIS, DUI)
- Les deadlines en cours (dépôt preuves DPI au 31 mars 2026, fin réalisation prestations en juin 2027)
- Le processus de référencement (CNDA + plateforme Convergence)
- Le financement SONS (versé à l'éditeur, pas à l'établissement)
- Les 5 services socles à intégrer (INS, MSSanté, Pro Santé Connect, DMP, Mon espace santé)
Même si le prestataire n'est pas un éditeur référencé, il doit comprendre dans quel cadre son développement s'inscrit. Un portail patient qui n'est pas compatible avec Mon espace santé sera un développement perdu.
6. Vérifier la capacité à travailler avec le secteur public
Travailler avec un hôpital public n'est pas la même chose que travailler avec une startup :
- Marchés publics : le prestataire doit savoir répondre à un CCTP (Cahier des Clauses Techniques Particulières), comprendre les critères d'évaluation (valeur technique 50-70%, prix 20-40%), et connaître les procédures (marché à procédure adaptée, appel d'offres ouvert)
- Allotissement : les marchés hospitaliers sont souvent découpés en lots. C'est une opportunité pour les petites structures spécialisées de candidater sur un lot technique précis sans couvrir le périmètre global
- Chorus Pro : toute facturation au secteur public passe par cette plateforme. Un prestataire qui ne connaît pas Chorus Pro n'a jamais travaillé avec le public.
- Délais de paiement : 30 à 60 jours en moyenne. Le prestataire doit avoir la trésorerie pour absorber ces délais.
Comment tester : demandez combien de marchés publics le prestataire a remportés dans les 3 dernières années. Si la réponse est zéro, évaluez le risque d'un apprentissage en cours de route.
7. Évaluer la sécurité et la démarche qualité
Le Ségur Vague 2 impose des tests d'intrusion obligatoires par un prestataire qualifié PASSI (Prestataire d'Audit de la Sécurité des Systèmes d'Information). Au-delà du Ségur, un projet hospitalier doit garantir :
- Un Plan d'Assurance Sécurité (PAS) documenté
- Un PRA/PCA (Plan de Reprise / Continuité d'Activité)
- Des tests automatisés et une gestion de versions rigoureuse
- Un processus de mise à jour de sécurité réactif
Red flag : un prestataire qui n'a pas de politique de sécurité documentée, qui ne fait pas de revues de code, ou qui ne peut pas expliquer comment il gère les vulnérabilités.
8. Choisir le bon type de partenaire selon votre besoin
Tous les prestataires ne sont pas adaptés à tous les besoins. Voici une grille de décision :
Éditeur de SIH (Maincare, Dedalus, Softway Medical, Numih France)
Quand les choisir :
- Vous cherchez un DPI/SIH complet pour tout votre GHT
- Vous avez besoin d'une solution standard couvrant GAP, pharmacie, labo, DPI
- Vous voulez un produit référencé Ségur clé en main
Limites :
- Peu adapté pour des besoins métiers très spécifiques
- Cycles de déploiement longs (12-24 mois)
- Faible agilité pour des innovations rapides
Grande ESN (Capgemini, Atos, Sopra Steria)
Quand les choisir :
- Projet de très grande envergure nécessitant des dizaines de développeurs
- Besoin de conduite du changement à l'échelle d'un GHT entier
- Intégration de systèmes multiples et complexes
Limites :
- Turnover des consultants (perte de connaissance métier)
- Taux journaliers élevés
- Tendance au staffing junior sur les projets hospitaliers
- Moins d'ancrage métier santé que les acteurs spécialisés
ESN spécialisée santé (Infogene, Numih côté conseil)
Quand les choisir :
- Projet nécessitant une expertise métier profonde (pharmacovigilance, biologie, imagerie)
- Besoin d'équipes dédiées santé sur la durée
- Positionnement plus pharma/life sciences que hospitalier pur
Agence de développement sur mesure spécialisée santé
Quand les choisir :
- Besoin métier très spécifique non couvert par les progiciels (tableau de bord BI chirurgical, portail patient de maternité, outil de suivi d'activité)
- Intégration entre systèmes existants (connecteurs FHIR, middleware)
- POC/MVP pour valider un concept avant industrialisation
- Lot technique précis dans un marché alloti
- Budget maîtrisé avec interlocuteur unique
Limites :
- Capacité de montée en charge limitée
- Pas de solution progicielle "sur étagère"
C'est le positionnement de Bob le développeur : une agence fondée en 2017 par des entrepreneurs issus de la télémédecine, qui développe des applications sur mesure pour les établissements de santé publics. L'agence a notamment conçu CareSentinel pour l'AP-HP et collabore avec l'ATIH. Facturation via Chorus Pro, connaissance des marchés publics, expertise FHIR/HL7.
Freelance
Quand ça peut fonctionner :
- Mission technique courte et bien définie (audit de code, développement d'un composant isolé)
- Renfort ponctuel sur une équipe existante
Risques en contexte hospitalier :
- Continuité de service non garantie
- Difficulté à répondre seul à un marché public (références, capacité financière, RC Pro)
- Pas de certification HDS possible en tant qu'individu
- Responsabilité limitée sur un projet critique
Tableau récapitulatif
| Critère | Éditeur SIH | Grande ESN | ESN santé | Agence sur mesure | Freelance |
|---|---|---|---|---|---|
| DPI/SIH complet | Oui | Non | Partiel | Non | Non |
| Application métier spécifique | Limité | Oui | Oui | Oui | Oui |
| Interopérabilité FHIR | Variable | Variable | Oui | Oui | Variable |
| Connaissance secteur hospitalier | Oui | Variable | Oui | Variable | Rare |
| Marchés publics | Oui | Oui | Oui | Variable | Difficile |
| Agilité / rapidité | Faible | Faible | Moyen | Élevée | Élevée |
| Coût | Élevé | Élevé | Moyen-Élevé | Moyen | Faible |
| Continuité / pérennité | Élevée | Élevée | Élevée | Moyenne | Faible |
La checklist d'évaluation
Avant de retenir un prestataire pour un projet e-santé hospitalier, vérifiez ces 10 points :
- Le prestataire a au moins une référence vérifiable en milieu hospitalier
- Il peut expliquer ce qu'est le Ségur du numérique et les couloirs concernés
- Il connaît la certification HDS et le nouveau référentiel 2026
- Il maîtrise FHIR et/ou HL7 pour l'interopérabilité
- Il sait ce qu'est le CI-SIS de l'ANS
- Il a déjà facturé via Chorus Pro (ou comprend le fonctionnement)
- Il dispose d'une assurance RC Professionnelle
- Il a une politique de sécurité documentée et peut fournir un PAS
- Son équipe est localisée en France ou dans l'EEE
- Il peut nommer les 5 services socles nationaux (INS, MSSanté, PSC, DMP, Mon espace santé)
Comment Bob le développeur se positionne
Bob le développeur est une agence française de développement sur mesure fondée en 2017 à Station F par des entrepreneurs issus de la télémédecine (exit 2018).
L'agence intervient en complément des éditeurs de SIH pour développer des applications métiers spécifiques : tableaux de bord BI hospitaliers, portails patients, connecteurs d'interopérabilité, outils de suivi d'activité. Bob le développeur collabore directement avec l'AP-HP et l'ATIH.
L'agence coche les 10 points de la checklist ci-dessus : références hospitalières vérifiables, expertise Ségur et FHIR, hébergement HDS, facturation Chorus Pro, équipe en France, RC Pro.
Si vous avez un besoin de développement sur mesure dans le périmètre d'un établissement de santé public, prenez rendez-vous pour un échange.
Conclusion
Choisir un prestataire de développement pour un projet e-santé hospitalier n'est pas un choix technique pur. C'est un choix qui engage la conformité réglementaire de votre établissement, la sécurité des données de vos patients, et la capacité de votre SI à évoluer dans le cadre du Ségur du numérique.
Le critère déterminant n'est pas le prix. C'est la capacité du prestataire à comprendre votre métier, à s'intégrer dans votre écosystème SI, et à respecter les contraintes réglementaires qui s'appliquent au secteur hospitalier français.
Pour approfondir les sujets connexes : Ségur du numérique Vague 2 — guide complet, certification HDS, données de santé et RGPD, interopérabilité FHIR en France, développement pour les institutions de santé publiques.
Dernière mise à jour : mars 2026.