Depuis plus de deux décennies, les décideurs politiques, les directeurs d’hôpitaux et les acteurs du secteur de la santé se voient promettre le même horizon : celui d’un espace informatique unifié où les données des patients circulent sans friction entre la médecine de ville, l’hôpital et les applications innovantes. Dans cette vision idyllique, le dossier médical d’un citoyen le suit en temps réel, évitant les surdiagnostics, fluidifiant les urgences et nourrissant la recherche.
Pourtant, la réalité du terrain clinique demeure désespérément archaïque. En 2026, un médecin hospitalier a souvent toutes les peines du monde à consulter le bilan biologique effectué la veille dans un laboratoire de quartier, tandis qu’une startup HealthTech met parfois plusieurs années à connecter son algorithme au Dossier Patient Informatisé (DPI) d’un établissement de santé.
Face à cet échec collectif, l’industrie du logiciel médical avance une excuse commode : la complexité technique et les contraintes réglementaires de confidentialité. C’est un grand mensonge. L’impossibilité de faire dialoguer les systèmes de santé n’est pas un problème d’ingénierie informatique ; c’est le résultat d’une stratégie commerciale délibérée. Dans le secteur de la santé, la donnée du patient a été transformée en une arme de captivité (vendor lock-in) au service de rente de situation historiques.
1. Le grand mensonge de l’obstacle technique
Pour justifier l’isolement des données de santé, les éditeurs de logiciels historiques invoquent systématiquement le principe de précaution : la donnée médicale serait « trop sensible », « trop non structurée » ou « trop complexe » pour être partagée par de simples interfaces applicatives (APIs).
Cette argumentation relève du pur cynisme technique. Sur le plan de l’ingénierie, la modélisation et la sécurisation des flux de données de santé sont des problèmes résolus depuis longtemps :
- Des standards mûrs et universels : La norme HL7 (dans ses versions 2 et 3) régit les échanges hospitaliers depuis les années 1980. Le standard FHIR (Fast Healthcare Interoperability Resources), reposant sur des architectures web modernes (REST, JSON, OAuth2), permet aujourd’tuit de modéliser n’importe quelle entité clinique (un patient, une observation, un traitement, une allergie) avec la même simplicité que les APIs de la finance ou du commerce électronique.
- Le traitement de l’imagerie : Le standard DICOM gère le transfert et l’archivage de l’imagerie médicale à l’échelle mondiale avec une précision absolue depuis plus de trente ans.
- Le chiffrement et la sécurité : Le chiffrement en transit (TLS 1.3) et au repos, couplé à des architectures d’identité décentralisées, garantit un niveau de sécurité bien supérieur aux échanges de fax ou de courriels non sécurisés qui continuent d’irriguer le secteur médical.
Si les systèmes informatiques hospitaliers ne se parlent pas, ce n’est donc pas parce qu’ils ne le peuvent pas. C’est parce que leurs éditeurs n’ont aucun intérêt économique à ce qu’ils se parlent.
2. La stratégie du « Vendor Lock-in » et l’économie du péage
Pour les éditeurs historiques de Dossiers Patients Informatisés (DPI) et de Systèmes d’Information Hospitaliers (SIH), l’interopérabilité native représente une menace existentielle. Un établissement de santé dont les données sont librement accessibles via des formats standardisés peut décider du jour au lendemain de changer de fournisseur d’interface, de remplacer un module RH obsolète ou d’adopter un outil de prescription concurrent.
Pour empêcher cette mobilité et neutraliser la concurrence, les éditeurs ont érigé la donnée en otage à travers deux mécanismes stratégiques :
[ Données du Patient ] ---> (Enfermées dans un format propriétaire)
|
v
[ Startup / Tiers ] -----( Demande d'accès API )-----> [ Éditeur DPI Historique ]
|
(Frais de péage exorbitants + Délais artificiels)
|
v
[ Intégration Bloquée / Abandon ]
Le verrouillage par la donnée propriétaire
En stockant les informations cliniques dans des bases de données relationnelles opaques ou des schémas propriétaires non documentés, l’éditeur rend le coût de migration d’un système à un autre prohibitivement cher. Extraire dix ans d’historique médical lors du changement d’un SIH hospitalier coûte régulièrement des centaines de milliers d’euros en prestations d’ingénierie inverse, une facture payée directement par l’hôpital.
L’économie du péage (Toll-booth Economics)
Sous la pression des régulateurs, les éditeurs ont fini par afficher une façade d’ouverture en proposant des connecteurs ou des APIs. Cependant, ils ont immédiatement monétisé cet accès. Lorsqu’une jeune entreprise innovante souhaite connecter son outil d’aide au diagnostic ou de suivi à distance au DPI d’un hôpital, l’éditeur du DPI exige l’acquittement d’un « droit de connexion » ou d’une prestation de certification.
Facturer de 10 000 à 50 000 euros l’ouverture d’un simple point d’accès API pour chaque établissement constitue une barrière à l’entrée infranchissable pour les nouveaux entrants. L’éditeur historique s’érige ainsi en douanier numérique : il prélève une rente sur l’innovation tierce tout en contrôlant arbitrairement qui a le droit d’entrer dans l’écosystème de l’hôpital.
3. Les conséquences systémiques : rupture de soins et gaspillage public
Cette captivité commerciale ne se traduit pas seulement par des batailles financières d’arrière-garde ; elle a des répercussions directes et graves sur la qualité du système de santé dans son ensemble.
La rupture de la continuité des soins
Lorsqu’un patient passe des urgences à un service de spécialité, ou de l’hôpital à un centre de rééducation, l’absence d’interopérabilité fluide entraîne des pertes d’informations critiques. Des traitements en cours sont interrompus, des allergies ne sont pas transmises et des bilans biologiques ou des examens d’imagerie lourds (radiographies, scanners) sont refaits à l’identique, simplement parce que le praticien ne peut pas accéder aux résultats générés sur le logiciel de l’établissement voisin.
L’asphyxie des startups HealthTech
L’Europe et l’Amérique du Nord regorgent de startups médicales prometteuses qui meurent non pas d’un manque de valeur clinique, mais d’épuisement financier face au mur de l’intégration. Passer 18 mois et consacrer la moitié de sa levée de fonds à négocier des connecteurs spécifiques avec cinq éditeurs de DPI différents draine les ressources qui devaient être allouées à l’amélioration du produit ou à la recherche clinique.
Le gaspillage des deniers publics
Les budgets informatiques des établissements de santé publics sont détournés de leur mission première. Au lieu de financer la modernisation de l’infrastructure ou l’amélioration de l’ergonomie pour les soignants, une part démesurée des dotations numériques est engloutie par le paiement d’interfaces sur-mesure (HL7 engines) et de modules de traduction obsolètes développés par les éditeurs pour relier artificiellement leurs propres logiciels incompatibles.
4. L’illusion de la régulation : le « Compliance Washing » des éditeurs
Conscients du problème, les gouvernements ont multiplié les initiatives législatives pour forcer le secteur à s’ouvrir : le 21st Century Cures Act aux États-Unis, le Ségur de la Santé en France ou le futur Espace Européen des Données de Santé (EHDS). Ces réglementations imposent le recours à des standards ouverts et prévoient des sanctions théoriques contre le « blocage d’informations » (information blocking).
Pourtant, sur le terrain, ces mesures se heurtent à la capacité d’esquive des grands éditeurs, passés maîtres dans l’art du Compliance Washing (ou conformité de façade) :
- Des APIs bridées par conception : Un éditeur se met en conformité avec la loi en ouvrant une API FHIR, mais limite arbitrairement son débit (ex: 5 requêtes par minute) ou ne permet la lecture que d’un sous-ensemble restreint de données, rendant l’interface inutilisable pour des applications temps réel.
- La documentation opaque : Fournir une API techniquement accessible mais accompagnée d’une documentation incomplète, trompeuse ou non mise à jour, obligeant les tiers à payer des journées de conseil auprès de l’éditeur pour comprendre le fonctionnement des champs.
- Les délais administratifs dissuasifs : Accepter le principe de l’intégration, mais imposer un processus de validation technique et de sécurité interne d’une durée de 12 à 18 mois pour chaque demande de connexion.
L’erreur stratégique des régulateurs a été d’obliger légalement les éditeurs à « exposer des normes », sans plafonner les tarifs d’accès ni imposer des niveaux de service (SLA) stricts et audités par des tiers indépendants.
5. Reprendre le contrôle : vers une véritable souveraineté de la donnée de santé
Pour briser la captivité commerciale et libérer l’innovation médicale, les directions informatiques hospitalières et les autorités de santé doivent opérer une rupture philosophique et architecturale majeure.
+-------------------------------------------------------------------------+
| ARCHITECTURE DE SANTÉ DEUX-TIERS |
| |
| [ Couche Applicative ] Logiciel A Logiciel B App HealthTech |
| \ | / |
| \ | / |
| ============================== Standard FHIR / OpenEHR ================ |
| / | \ |
| / | \ |
| [ Couche de Persistance ] [ Socle de Données Central Indépendant ] |
| (Propriété exclusive de l'établissement) |
+-------------------------------------------------------------------------+
1. Séparer la donnée de l’application (Architecture Découplée)
La donnée médicale ne doit plus appartenir au logiciel qui la saisit. Les hôpitaux doivent adopter une architecture deux-tiers où le stockage repose sur une plateforme de données neutre et ouverte (utilisant des standards comme openEHR ou des référentiels FHIR natifs). Les logiciels métiers (DPI, outils de prescription, imagerie) ne deviennent alors que de simples couches d’affichage et d’interaction qui lisent et écrivent dans ce socle commun. Si un hôpital souhaite changer d’éditeur de DPI, il conserve 100 % de sa base de données intacte et réassigne simplement la couche applicative.
2. Imposer l’accès API gratuit et sans condition dans les marchés publics
Les directeurs d’hôpitaux et les acheteurs publics doivent introduire des clauses d’inflexibilité absolue dans leurs appels d’offres :
- Gratuité totale des APIs FHIR en lecture et en écriture pour tout logiciel tiers autorisé par l’établissement.
- Pénalités financières directes à la charge de l’éditeur en cas de latence anormale ou de refus de connexion d’un tiers dans un délai supérieur à 30 jours.
- Restitution sans frais de la totalité de la base de données dans un format standardisé ouvert à la fin du contrat.
3. Sanctionner réellement le blocage d’information
Les autorités de santé doivent cesser de considérer l’interopérabilité comme un sujet de concertation industrielle. L’obstruction au partage de données de santé doit être qualifiée et sanctionnée pour ce qu’elle est : une pratique anticoncurrentielle et un préjudice porté à la continuité des soins.
Tant que les données de santé resteront la propriété de fait des marchands de logiciels, la médecine numérique demeurera un vœu pieux. La véritable révolution HealthTech n’aura pas lieu dans les laboratoires d’IA, mais dans la reprise en main politique et technique du patrimoine d’information des patients par les établissements de soin et les citoyens eux-mêmes.
