Concevoir une application e-santé ne relève pas du développement web ordinaire. On n’y ajoute pas simplement quelques précautions. En effet, les contraintes réglementaires, l’interopérabilité et les usages réels en établissement déplacent l’essentiel des arbitrages techniques. Un projet qui les ignore produit donc un logiciel conforme sur le papier, mais que personne n’ouvre.
Ce que recouvre le terme e-santé
L’e-santé désigne tous les usages du numérique au service de la santé. On y trouve par exemple la téléconsultation, le dossier patient informatisé ou les objets connectés de suivi. S’y ajoutent les plateformes de coordination entre professionnels. Un logiciel de gestion des séjours hospitaliers comme HPlanner en donne un exemple concret. Longtemps cantonnée à des expérimentations, l’e-santé s’est installée durablement dans les pratiques. Elle répond en effet à des besoins concrets : réduire les délais de prise en charge, fluidifier les échanges entre ville et hôpital, suivre à distance les patients chroniques.
Cette diversité a une conséquence pratique. Il n’existe donc pas d’architecture type. Une plateforme de téléconsultation et un outil de suivi post-opératoire partagent le même cadre réglementaire. En revanche, presque rien ne rapproche leurs contraintes techniques.
L’hébergement des données de santé : la certification HDS
Une application e-santé traite souvent des données personnelles pour le compte d’un tiers. Dès lors, son hébergement doit être certifié HDS. Ce n’est pas une formalité que l’on règle en fin de projet. En effet, la certification HDS conditionne le choix de l’infrastructure, donc l’architecture et les coûts.
Le RGPD s’y ajoute, avec des exigences renforcées sur ces données sensibles. Il impose notamment de minimiser la collecte et de justifier les durées de conservation. Il faut aussi tracer les accès. Cette traçabilité, en particulier, se conçoit dès le modèle de données. La reconstituer après coup est autrement plus lourd.
Dialoguer avec l’existant : l’enjeu de l’interopérabilité
Une application e-santé ne s’installe jamais sur un terrain vierge. Elle arrive dans un écosystème peuplé de logiciels métier, de systèmes hospitaliers et d’annuaires professionnels. C’est pourquoi les standards comptent autant. On retiendra par exemple HL7 FHIR pour les échanges cliniques. Les profils IHE PAM répondent quant à eux à la gestion des séjours. Les référentiels de l’Agence du Numérique en Santé encadrent de leur côté le contexte français.
Adopter ces standards coûte plus cher au démarrage qu’un format maison. Mais un format propriétaire enferme le projet. Chaque nouvelle intégration devient alors un développement spécifique. La dette s’accumule ainsi au rythme des partenariats.
Concevoir pour des professionnels sous contrainte de temps
Les soignants comptent parmi les utilisateurs les plus exigeants. Ils jugent en quelques minutes si un outil leur fait gagner du temps. Leur verdict est sans appel. Un logiciel qui ajoute trois clics à un geste quotidien sera donc contourné, quelle que soit sa qualité technique.
La conception doit donc partir du terrain. Mieux vaut observer les usages réels que les processus théoriques. Il faut ensuite prototyper tôt, puis ajuster avec les équipes soignantes plutôt que pour elles. Les projets qui échouent sont en effet rarement des échecs techniques. Ce sont des outils corrects que personne n’a envie d’ouvrir.
Ce qui distingue un projet e-santé réussi
Trois marqueurs reviennent systématiquement. D’abord, la conformité est traitée dès la conception. Ensuite, l’interopérabilité repose sur des standards reconnus, ce qui préserve l’avenir du projet. Enfin, l’adoption est mesurée comme un objectif à part entière.
Une application e-santé réussie n’est pas seulement conforme. Elle s’insère surtout dans un parcours de soin existant sans l’alourdir. C’est donc un travail d’ajustement au réel autant que d’ingénierie. C’est aussi ce qui rend ces projets exigeants, et intéressants.
Transparence — Cet article a été rédigé avec l’assistance d’un système d’intelligence artificielle, puis relu, corrigé et validé par la rédaction d’Ackwa, qui en assume la responsabilité éditoriale. Information communiquée au titre de l’article 50 du règlement (UE) 2024/1689 sur l’intelligence artificielle.