Structurer le plan de site d’une plateforme santé ne se résume pas à aligner des pages dans un menu. L’architecture de l’information conditionne la circulation des données entre professionnels, patients et systèmes tiers. Avec l’entrée en vigueur progressive du règlement européen sur l’espace européen des données de santé (EHDS) à partir de mars 2027, puis les échanges transfrontaliers prévus dès mars 2029, la conception d’une arborescence adaptée devient un prérequis technique autant qu’éditorial.
Interopérabilité et plan de site : pourquoi l’arborescence conditionne les échanges de données
La plupart des guides sur la création de sites médicaux abordent le plan de site comme un exercice éditorial. On classe les pages par spécialité, on ajoute un formulaire de contact, puis on passe au design. Cette approche omet un paramètre structurant : l’interopérabilité impose une organisation fonctionnelle des contenus.
Une plateforme qui échange des documents avec Mon espace santé est évaluée sur plusieurs axes, dont l’urbanisation, la sécurité, l’éthique et la conformité RGPD. Cela signifie que le plan de site doit distinguer nettement les espaces publics (informations générales, présentation des soins), les comptes professionnels, les parcours patients et les fonctions d’échange de documents.
Un exemple concret de cette logique appliquée à la cartographie d’une plateforme est visible sur le site Irist Santé, où les rubriques reflètent une segmentation par type d’utilisateur et par fonction plutôt qu’une simple hiérarchie éditoriale.
Construire le sitemap autour de données structurées (standards FHIR, DICOM) plutôt que de PDF ou formulaires propriétaires prépare aussi la plateforme aux obligations de l’EHDS. Les retours terrain divergent sur le niveau de maturité réel des plateformes existantes face à ces exigences, mais la direction réglementaire est claire.
MSSanté dans le plan de site : une rubrique fonctionnelle, pas une page de contact
Intégrer la messagerie sécurisée de santé (MSSanté) dans l’arborescence d’une plateforme mérite une réflexion spécifique. Les recommandations récentes prévoient des interfaces standardisées, l’envoi de documents de santé structurés conformes au CI-SIS, l’intégration automatique des messages reçus dans le dossier patient et l’utilisation de l’Annuaire Santé pour sélectionner les destinataires.
MSSanté ne peut pas être réduite à un simple lien dans le pied de page. Le plan de site devrait lui consacrer une section fonctionnelle distincte, avec au minimum :
- Un espace d’envoi et de réception de documents structurés, accessible depuis le tableau de bord professionnel
- Un système de sélection des destinataires connecté à l’Annuaire Santé, pour éviter les erreurs d’adressage
- Un mécanisme d’archivage automatique qui classe les échanges dans le dossier patient correspondant
Traiter MSSanté comme une brique isolée, cachée dans une sous-page « contact », revient à perdre la traçabilité des échanges et à compliquer la coordination des soins entre professionnels.
Accessibilité RGAA et architecture de l’information en santé
Une plateforme santé s’adresse à des utilisateurs dont les capacités varient considérablement : personnes âgées, patients en situation de handicap, aidants peu familiers du numérique. Le Référentiel Général d’Amélioration de l’Accessibilité (RGAA) impose des critères qui influencent directement la structure du plan de site.
L’accessibilité se joue dès la hiérarchie des pages, pas au moment de l’audit final. Un menu de navigation trop profond (plus de trois niveaux) pénalise les utilisateurs de lecteurs d’écran. Des intitulés de rubriques ambigus (« Mes services », « Mon espace ») compliquent la navigation pour les personnes ayant des troubles cognitifs.
Les obligations varient selon la taille de la structure et son statut, mais les plateformes qui traitent des données de santé sont soumises à un niveau d’exigence élevé. Plusieurs points méritent une attention particulière lors de la conception du sitemap :
- Chaque page doit avoir un titre unique et descriptif, lisible hors contexte par une technologie d’assistance
- Les parcours patients (prise de rendez-vous, consultation de résultats, messagerie) doivent être atteignables en un nombre limité de clics depuis la page d’accueil
- Les documents téléchargeables (ordonnances, comptes rendus) gagnent à être regroupés dans une section dédiée plutôt que dispersés dans plusieurs rubriques
Prévoir ces contraintes dès la phase de conception du plan de site évite des refontes coûteuses une fois la plateforme en production.
Données structurées et standards FHIR : ce que le sitemap doit anticiper
Le règlement EHDS pousse les plateformes santé vers un modèle où les données sont réutilisables et interopérables par défaut. Cela ne concerne pas uniquement les bases de données internes : le plan de site lui-même doit refléter cette logique.
Organiser les contenus autour de ressources FHIR (Fast Healthcare Interoperability Resources) signifie, par exemple, que la rubrique « Dossier patient » ne contient pas simplement des PDF scannés. Elle expose des données structurées consultables par d’autres systèmes autorisés. Le plan de site doit donc prévoir des URL stables pour chaque type de ressource, plutôt que des chemins dynamiques qui changent à chaque mise à jour du logiciel.
Une URL stable par type de ressource facilite l’indexation et l’interopérabilité. Les parcours de soins, les documents de coordination, les résultats d’examens : chacun de ces éléments gagne à occuper une place identifiable dans l’arborescence.
Gestion des droits d’accès dans l’arborescence
Le plan de site d’une plateforme santé n’est pas entièrement public. Certaines sections ne sont visibles que par les professionnels authentifiés, d’autres par les patients connectés. Cette segmentation des droits d’accès doit être pensée dès la conception de l’arborescence, et non ajoutée après coup par des filtres techniques.
Prévoir un sitemap XML distinct pour les moteurs de recherche (pages publiques uniquement) et une cartographie interne complète pour la gestion des processus constitue une bonne pratique. Confondre sitemap public et cartographie fonctionnelle interne génère des failles de sécurité et des problèmes d’indexation.
L’architecture d’une plateforme santé se construit à l’intersection de contraintes rarement réunies ailleurs : réglementation sur les données personnelles, exigences d’accessibilité, interopérabilité technique entre systèmes, coordination entre professionnels aux profils variés. Le plan de site n’est pas un livrable secondaire à produire en fin de projet. C’est le socle sur lequel repose la capacité de la plateforme à remplir sa fonction première : faire circuler la bonne information vers le bon utilisateur, au bon moment.
