Mon Espace Santé : guide d'intégration pour les éditeurs (2026)

10/05/2026
Mon Espace Santé est devenu en quelques années la brique citoyenne centrale de la santé numérique française. Pour un éditeur de logiciel ou un porteur de projet e-santé, la question n'est plus si il faut s'y connecter, mais comment. Et c'est là que les choses se compliquent : la documentation est éclatée entre l'ANS, la CNAM, le portail industriels et le Ségur, chaque brique a son propre référentiel, et personne ne propose de vue d'ensemble côté développeur.
Chez Bob le développeur, on travaille sur des intégrations Mon Espace Santé pour des éditeurs et des établissements depuis l'ouverture du service. Cet article rassemble ce qu'il faut comprendre avant d'attaquer : les composants techniques, les prérequis non-négociables, le processus de référencement et les pièges qui font perdre des semaines.
L'essentiel en 30 secondes :
- Mon Espace Santé n'est pas une API : c'est un portail citoyen alimenté par plusieurs briques techniques (DMP, MSSanté Citoyen, agenda de santé, catalogue de services).
- Trois prérequis bloquants : référencement Ségur Vague 2, hébergement HDS, identification du patient via l'INS.
- L'alimentation du DMP passe par les API DMP (REST + IHE XDS), la messagerie patient passe par MSSanté Citoyen.
- Pour apparaître dans le catalogue, il faut une convention CNAM et passer la procédure de référencement ANS.
- Compter 6 à 12 mois entre la décision et la mise en production réelle.
Qu'est-ce que Mon Espace Santé (et ce que ce n'est pas)
Mon Espace Santé (MES) est le carnet de santé numérique du citoyen français. Lancé en janvier 2022, il est ouvert par défaut à tous les bénéficiaires d'un régime d'assurance maladie obligatoire, sauf opposition explicite. Au 1er trimestre 2026, plus de 16 millions de profils ont été activés et plus d'un milliard de documents ont été déposés.
Côté utilisateur, MES rassemble quatre fonctionnalités principales : un dossier médical (les anciens documents du DMP), une messagerie sécurisée pour échanger avec les professionnels de santé, un agenda de rendez-vous médicaux et un catalogue de services numériques référencés par l'État.
Ce que MES n'est pas, c'est une API monolithique. Quand on dit "intégrer Mon Espace Santé", on parle en réalité d'intégrer une ou plusieurs des briques sous-jacentes :
| Brique | Opérateur | Rôle |
|---|---|---|
| DMP | CNAM | Stockage et consultation des documents médicaux |
| MSSanté Citoyen | ANS | Messagerie sécurisée patient ↔ professionnel |
| INS | ANS | Identifiant National de Santé |
| Pro Santé Connect | ANS | Authentification du professionnel |
| Catalogue de services | ANS | Référencement de votre service dans le portail MES |
| Agenda de santé | CNAM | Prise de rendez-vous |
C'est la combinaison de ces briques qui produit l'expérience MES côté patient. Côté éditeur, il faut choisir lesquelles s'appliquent à votre cas d'usage et les intégrer une par une.
Trois cas d'usage typiques pour un éditeur
Avant de plonger dans la technique, il faut clarifier ce que vous voulez réellement faire. La plupart des projets éditeurs tombent dans l'une de ces trois catégories :
Cas 1 : alimenter le dossier médical du patient. Vous éditez un logiciel métier (DPI, logiciel de cabinet, application de téléconsultation, dispositif médical) qui produit des documents de santé. Vous voulez les déposer automatiquement dans le DMP du patient pour qu'il les retrouve dans MES. C'est l'usage majoritaire et le plus simple à cadrer.
Cas 2 : échanger avec le patient via la messagerie. Vous voulez envoyer des comptes rendus, des résultats d'examens ou des messages structurés au patient via MSSanté Citoyen. C'est l'extension naturelle du cas 1 et de plus en plus demandé pour la coordination des soins.
Cas 3 : devenir un service tiers référencé. Vous voulez que votre application apparaisse dans le catalogue de services de MES, accessible en un clic depuis le portail. Cela suppose une convention CNAM, un dossier de référencement ANS et une intégration via Pro Santé Connect ou FranceConnect+.
Les trois cas se cumulent très bien : un service de télésurveillance peut alimenter le DMP, échanger via MSSanté Citoyen et figurer au catalogue. Mais chacun ajoute son propre lot d'exigences techniques et administratives.
Les prérequis non-négociables
Quel que soit le cas d'usage, certains prérequis sont bloquants. Pas la peine de commencer à coder tant qu'ils ne sont pas adressés.
Référencement Ségur Vague 2
Pour alimenter le DMP, votre logiciel doit être référencé Ségur dans le couloir applicatif correspondant à votre métier (médecin de ville, hôpital, biologie, imagerie, officine, etc.). Le référencement Ségur garantit que votre logiciel respecte le référentiel d'exigences DSR/DSF et a passé les tests de conformité avec une plateforme tierce (le CNDA pour beaucoup de couloirs).
Le détail des paliers, des deadlines et du financement SONS est traité dans notre guide complet du Ségur Vague 2. En résumé : sans référencement Ségur, vos appels aux API DMP seront rejetés en production.
Hébergement HDS
L'intégralité de votre stack qui touche aux données de santé doit être hébergée chez un Hébergeur de Données de Santé certifié. Cela inclut votre application, votre base de données, vos backups et tous les composants intermédiaires. Notre comparatif des hébergeurs HDS (OVHcloud, AWS, Scaleway, Azure) détaille les options réalistes.
Si vous êtes déjà hébergé hors HDS, prévoyez la migration en amont : c'est plusieurs semaines de travail et un audit complet du périmètre données de santé.
Identification via l'INS
Tout document déposé au DMP doit être qualifié avec l'Identifiant National de Santé (INS) du patient. L'INS, c'est le NIR (numéro de sécurité sociale) du patient associé à cinq traits stricts : nom de naissance, prénoms, sexe, date de naissance, code INSEE du lieu de naissance.
Pour récupérer l'INS d'un patient, il faut interroger le téléservice INSi (INS-intégré) opéré par le GIE SESAM-Vitale. Trois modes d'appel existent :
- Appel par carte Vitale : le mode privilégié, garantit un INS qualifié immédiatement.
- Appel par traits : envoi des traits civils, retour de l'INS si correspondance unique.
- Appel par INS+traits : vérification d'un INS déjà connu.
L'INSi exige un certificat client X.509 et utilise un canal SOAP avec WS-Security. C'est l'un des points qui surprend toujours : pas de REST, pas d'OAuth, du SOAP avec signature XML. Prévoir une journée de mise en route et un wrapper HTTP propre pour ne pas polluer le reste du code.
Authentification professionnelle via Pro Santé Connect
Tout accès en lecture aux données du DMP par un professionnel de santé doit passer par une authentification Pro Santé Connect (PSC). Si vous gérez l'identité de vos utilisateurs en interne, il faut greffer PSC en parallèle pour les actions touchant le DMP. On a publié un guide technique complet sur PSC qui couvre le flow OIDC, les claims RPPS et les pièges classiques.
Alimenter le DMP : les API à connaître
L'alimentation du DMP est le cas d'usage majoritaire. La CNAM expose deux familles d'API selon le profil du déposant.
API REST DMP (logiciels Ségur)
Depuis le passage au Ségur, la CNAM met à disposition une API REST moderne pour les logiciels Ségur référencés. Elle couvre :
- Le dépôt de document (POST avec métadonnées CDA + pièce jointe encodée).
- La mise à jour ou suppression d'un document existant.
- La consultation des documents accessibles au déposant (avec contrôle de matricule INS).
- La liste des bénéficiaires rattachés à un patient (utilisé par les logiciels de coordination).
L'authentification se fait par certificat client (CPS organisationnelle ou certificat logiciel ANS), pas par token OAuth. C'est conçu pour des appels serveur-à-serveur depuis votre backend, pas depuis un navigateur.
Profil IHE XDS.b (établissements et anciennes intégrations)
Pour les établissements et les éditeurs qui ne sont pas (encore) sur les API Ségur REST, l'alimentation du DMP s'appuie sur le profil IHE XDS.b. C'est un standard interopérable mais lourd : SOAP, MTOM/XOP pour les pièces jointes, schémas XDS et metadata complexes.
Si vous démarrez aujourd'hui un projet from scratch, partez sur les API REST Ségur. Le profil XDS.b reste utile pour des intégrations hospitalières existantes ou des passerelles d'établissement.
Format des documents : CDA R2
Tout document déposé au DMP doit être au format CDA R2 (Clinical Document Architecture, niveau 2). C'est un standard HL7 qui définit un en-tête XML structuré (identifiants, auteur, patient, date, type de document) et un corps qui peut contenir du texte structuré, des sections codifiées (LOINC, CIM-10) ou un PDF encapsulé.
Les types de documents (LOINC) vont de la lettre de liaison (34133-9) au compte-rendu d'imagerie (18748-4) en passant par l'ordonnance (57833-6) ou la synthèse médicale (60591-5). Il faut choisir le bon code LOINC et respecter le profil CDA correspondant.
En pratique, on encapsule presque toujours le document métier original (PDF) dans le corps CDA et on remplit l'en-tête avec les métadonnées requises. Une bibliothèque comme dcm4che (Java) ou un wrapper maison sur xml2js (Node) suffit pour générer le CDA. Compter 1 à 2 semaines pour un premier flux fonctionnel.
La messagerie MSSanté Citoyen
MSSanté Citoyen est l'extension grand public du système MSSanté. Côté patient, l'adresse prenom.nom@patient.mssante.fr est créée automatiquement à l'ouverture de Mon Espace Santé. Côté professionnel ou éditeur, l'envoi d'un message au patient passe par un opérateur MSSanté agréé.
Deux options pour intégrer :
- Devenir opérateur MSSanté : long, coûteux, réservé aux gros éditeurs ou aux établissements. Implique l'agrément ANS et l'exploitation d'une infrastructure SMTP sécurisée conforme au référentiel.
- Passer par un opérateur tiers : plus simple, on délègue l'envoi à un opérateur agréé (Mailiz côté MIPIH, MSS d'Apicrypt, opérateurs régionaux GRADeS). L'éditeur appelle une API métier et l'opérateur s'occupe du transport SMTP vers la boîte patient.
Pour 90 % des projets éditeurs, l'option 2 est la bonne. Le code côté éditeur ressemble à n'importe quel envoi d'email transactionnel, avec en plus la qualification INS du destinataire.
Devenir un service tiers du catalogue Mon Espace Santé
Le catalogue MES est la vitrine côté patient. Y figurer, c'est récupérer du trafic qualifié depuis le portail officiel et bénéficier d'un signe de confiance fort. La contrepartie, c'est un processus de référencement strict.
Les étapes :
- Conventionnement avec la CNAM. Vous signez une convention qui définit votre périmètre, vos engagements RGPD, vos modalités de connexion. Compter 2 à 4 mois.
- Dossier de référencement ANS. Vous remplissez un dossier qui couvre la conformité RGPD, l'hébergement HDS, l'authentification (PSC pour les pros, FranceConnect+ pour les patients), l'accessibilité RGAA et la sécurité. L'ANS valide ou demande des compléments.
- Tests de bout en bout. Validation de l'intégration par les équipes ANS sur l'environnement de test (BAS).
- Mise en catalogue. Votre service apparaît dans MES avec une fiche descriptive et un bouton de connexion qui redirige vers vous via FranceConnect+.
Le processus complet prend 6 à 12 mois selon votre niveau de maturité initiale. Anticipez l'audit RGPD : c'est presque toujours là que les dossiers traînent.
Implémentation type : déposer un compte rendu au DMP
Pour fixer les idées, voici le flux concret côté éditeur quand un médecin clique sur "Envoyer au DMP" depuis votre logiciel :
- Récupérer l'INS du patient. Si déjà en base et qualifié, on l'utilise. Sinon, appel INSi par carte Vitale ou par traits.
- Vérifier le consentement DMP. Le patient peut avoir bloqué l'accès à un professionnel ou à une catégorie de documents. La CNAM expose un endpoint de vérification d'accès à appeler avant le dépôt.
- Générer le CDA R2. Wrapper du PDF métier dans un en-tête CDA avec : auteur (RPPS du médecin), patient (INS + traits), date, type LOINC, organisation.
- Authentifier l'appel. Charger le certificat client (CPS organisationnelle ou ANS) et signer la requête HTTPS.
- Appeler l'API de dépôt. POST vers l'endpoint
submitDocumentavec le CDA en multipart. - Tracer et retourner. Logger le résultat (succès, ID document, erreurs) et restituer un statut au médecin.
Sur un projet bien cadré, ce flux représente 3 à 5 semaines de dev pour la première intégration, puis quelques jours par type de document additionnel.
Pièges et retours terrain
Quelques erreurs qu'on voit revenir sur la plupart des projets :
Sous-estimer le passage en production. L'environnement BAS est généreux, la production est stricte. Les certificats sont différents, les volumes sont contrôlés, les rejets sont silencieux. Prévoir une phase de bascule progressive avec un canari par type de document.
Mal qualifier l'INS. Un INS non qualifié (statut "récupéré" et non "validé") ne permet pas d'alimenter le DMP. Beaucoup d'équipes traitent l'INS comme un simple identifiant alors que c'est un objet d'état avec un cycle de qualification précis.
Confondre référencement Ségur et référencement catalogue. Ce sont deux processus indépendants. Vous pouvez être Ségur sans être au catalogue MES, et inversement (rare). Ne mélangez pas les deux dans votre planning.
Ignorer les obligations d'accessibilité. Si vous visez le catalogue, le RGAA est exigé. C'est un sujet à part entière qu'on a couvert dans notre guide accessibilité RGAA/WCAG.
Négliger les retours patient. Quand un patient ouvre une réclamation depuis MES, elle remonte chez l'opérateur du document, donc chez vous. Prévoir un canal de support et une procédure de retrait/correction de document.
FAQ — Mon Espace Santé pour les éditeurs
Faut-il être référencé Ségur pour alimenter le DMP ? Oui, en pratique. Depuis l'arrêt progressif des anciens canaux DMP, l'alimentation passe par les API Ségur, donc par le référencement Ségur de votre logiciel.
Est-ce qu'on peut tester sans certificat ? Non. Même en environnement BAS, les API DMP exigent un certificat client (CPS organisationnelle de test ou certificat logiciel ANS de test). La demande de certificat de test passe par le portail industriels de l'ANS.
Quelle est la différence entre DMP et Mon Espace Santé ? Le DMP est la brique technique de stockage des documents. Mon Espace Santé est l'interface citoyenne qui expose ces documents au patient, plus la messagerie, l'agenda et le catalogue. Côté éditeur, on intègre les briques (DMP, MSSanté), pas MES en tant que tel.
Peut-on alimenter le DMP sans Pro Santé Connect ? Oui pour les flux serveur-à-serveur depuis un logiciel Ségur (le certificat suffit). Non pour les actions de consultation ou de modification réalisées par un professionnel identifié dans votre interface : PSC est requis.
Combien coûte une intégration MES complète ? Pour un éditeur partant de zéro : compter 60 à 120 jours de développement pour les API DMP, 20 à 40 jours pour MSSanté Citoyen, 30 à 60 jours pour le référencement catalogue (incluant la mise en conformité RGAA et RGPD). Le coût total dépend fortement de l'état initial de la stack. Notre guide budget e-santé détaille les fourchettes.
Faut-il un agrément spécifique pour MSSanté Citoyen ? Non si vous passez par un opérateur agréé (Mailiz, Apicrypt, opérateurs régionaux). Oui si vous voulez devenir opérateur MSSanté vous-même, ce qui est rare et coûteux.
FranceConnect+ ou Pro Santé Connect ? PSC pour authentifier des professionnels, FranceConnect+ pour authentifier des citoyens-patients sur votre service tiers. Si votre service est mixte (pro + patient), il faut les deux.
Quels SDK ou bibliothèques utiliser ?
La CNAM fournit des exemples mais pas de SDK officiel maintenu. Les éditeurs partent en général d'une lib HTTP standard et d'un wrapper CDA maison. Pour le SOAP INSi, node-soap ou axis2 (Java) couvrent les besoins.
Aller plus loin
L'intégration Mon Espace Santé n'est pas un sprint, c'est un chantier qui touche votre architecture, votre conformité et votre roadmap produit. Avant d'attaquer le code, prenez le temps de cadrer le périmètre : quelles briques, quels patients, quels types de documents, quelle deadline Ségur.
Si vous portez un projet e-santé qui doit s'intégrer à Mon Espace Santé et que vous cherchez un partenaire technique qui maîtrise déjà le DMP, l'INS, PSC et le Ségur, parlons de votre projet. On vous évitera les pièges qu'on a déjà rencontrés et on cadrera l'intégration en fonction de votre couloir applicatif et de vos contraintes.
