# Intégrer MSSanté dans un logiciel : opérateurs, LPS, API et bonnes pratiques > Ce qu'un éditeur ou une DSI doit savoir pour intégrer la messagerie sécurisée de santé : acteurs de l'espace de confiance, API LPS, authentification Pro Santé Connect, archives IHE XDM, messagerie patient et calendrier. Auteur: Ala Ben Aicha Page de référence: https://alabenaicha.me/fr/insights/mssante-messaging-integration Mise à jour: 2026-10-06 ## Réponse directe MSSanté est un espace de confiance de messageries sécurisées de santé : des opérateurs agréés par l'ANS fournissent les boîtes aux lettres, et les logiciels métier (LPS, DPI, DUI) s'y connectent. Depuis le référentiel #2, l'intégration standard passe par l'API LPS : IMAP et SMTP avec STARTTLS, authentification Pro Santé Connect pour les boîtes personnelles et organisationnelles, certificat ORG AUTH\_CLI pour les boîtes applicatives. Un document de santé part dans une archive IHE XDM contenant du CDA, accompagnée de son PDF, avec des en-têtes MSSanté dédiés. ## MSSanté, en clair MSSanté n'est pas un logiciel unique. C'est un ensemble de règles qui permet à des centaines de messageries d'échanger entre elles des données de santé chiffrées, en réservant l'accès aux professionnels habilités par la loi (article L.1110-4 du code de la santé publique). Selon la [page MSSanté de l'ANS](https://esante.gouv.fr/offres-services/mssante), l'espace compte plus de 800 000 boîtes aux lettres, plus de 300 opérateurs et plus de 28 millions de messages émis en mai 2025. Trois types de boîtes coexistent : * **Nominative (personnelle)** : celle d'un professionnel identifié par son RPPS. * **Organisationnelle** : partagée par une équipe ou un service, sous la responsabilité d'une personne désignée. * **Applicative** : utilisée directement par un logiciel pour des envois automatisés, et parfois pour l'intégration automatique de documents reçus. L'usage de MSSanté n'est pas obligatoire, mais sécuriser les échanges de données de santé l'est. Les patients disposent aussi d'une boîte MSSanté dans Mon espace santé, avec des usages limités. ## Qui fait quoi | Acteur | Rôle | Ce que l'éditeur doit en retenir | | -------------------------------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | ANS | Gestionnaire de l'espace de confiance : référentiels, liste blanche des domaines, Annuaire Santé | Publie les exigences que votre logiciel devra prouver | | Opérateur MSSanté | Fournit les boîtes et achemine les messages ; peut être un établissement, un industriel ou un organisme public | Expose l'API LPS ; vous ne choisissez pas l'opérateur de vos clients | | Opérateur développeur / acheteur | Le premier fournit les briques (connecteur MSSanté), le second les achète | Fréquent dans les établissements de santé | | Mailiz | Offre MSSanté opérée par l'ANS pour les professionnels habilités | Abandonne ses interfaces historiques au profit de l'API LPS | | Éditeur de LPS / DUI | Client de messagerie intégré au logiciel métier | Soumis au référentiel #2 | | Annuaire Santé | Publie les adresses MSSanté des professionnels | Source de recherche des destinataires | | Mon espace santé | Opérateur des boîtes usagers en `patient.mssante.fr` | Adresse construite à partir de l'INS | | Pro Santé Connect | Fournisseur d'identité des professionnels | Fournit le jeton présenté à l'API LPS | ## Référentiel #1 et référentiel #2 Le référentiel #1 s'adresse aux opérateurs et existe depuis 2014. Sa version 1.5, publiée en avril 2022, impose aux opérateurs l'API LPS. Le dispositif d'encadrement de ce référentiel est en révision : la [doctrine MSSanté de l'ANS](https://esante.gouv.fr/doctrine/mssante) annonce une concertation publique au deuxième trimestre 2026 et un arrêté d'adoption au quatrième trimestre 2026. Le [référentiel #2 Clients de messageries v1.0](https://industriels.esante.gouv.fr/sites/default/files/media/document/ANS_MSS_Ref2_Clients_de_messageries_MSSant%C3%A9_v1.0_20230131.pdf) du 31 janvier 2023 s'adresse aux éditeurs. Il distingue deux familles de clients : * ceux qui accèdent uniquement à des boîtes applicatives, sans forcément afficher les messages à un utilisateur (un SIL qui envoie ses comptes rendus, par exemple) ; * ceux qui donnent accès à des boîtes personnelles ou organisationnelles et proposent donc une interface de lecture et d'envoi. Les exigences applicables diffèrent selon la famille ; le tableau de synthèse du chapitre 6 du référentiel est la bonne liste à reprendre dans votre backlog. Les interfaces propriétaires d'un opérateur restent autorisées, mais elles vous lient à cet opérateur. ## L'API LPS : IMAP, SMTP et deux points d'entrée | Point d'entrée | Boîtes | Authentification | Protocoles | | -------------- | ---------------------------------- | ------------------------------------------------------------------------------ | -------------------------------------- | | PSC | Personnelles et organisationnelles | SASL `XOAUTH2` avec un access token PSC | SMTP port 587, IMAP port 143, STARTTLS | | Certificat | Applicatives | mTLS avec un certificat ORG AUTH\_CLI, puis `PLAIN` avec l'adresse de la boîte | Idem | Chaque opérateur publie une autoconfiguration au format Thunderbird à l'adresse `https://autoconfig./mail/config-v1.1.xml`, qui décrit les deux points d'entrée. Votre client doit l'interroger à partir de l'adresse de la boîte plutôt que de figer des noms d'hôtes. Pour une boîte personnelle, la séquence est : ouvrir la session TLS avec STARTTLS, envoyer `AUTHENTICATE XOAUTH2` en IMAP ou `AUTH XOAUTH2` en SMTP avec une chaîne encodée en base64, attendre la validation de l'opérateur, puis envoyer les commandes. La chaîne contient l'adresse de la boîte et l'access token PSC : ```js // Synthetic values: build the SASL XOAUTH2 initial response for the API LPS const mailbox = 'jane.doe@hopital-exemple.mssante.fr'; const pscAccessToken = ''; const xoauth2 = Buffer.from( `user=${mailbox}\x01auth=Bearer ${pscAccessToken}\x01\x01`, 'utf8' ).toString('base64'); // IMAP: A1 AUTHENTICATE XOAUTH2 // SMTP: AUTH XOAUTH2 ``` Le référentiel précise qu'un serveur LPS intermédiaire est nécessaire, y compris pour un client lourd : chaque poste ne peut pas être enregistré individuellement comme client PSC. C'est ce serveur qui conduit le flux OIDC (redirection ou CIBA, qui valide l'authentification sur le téléphone portant la e-CPS) et transmet le jeton. Le détail du flux est dans l'article sur [l'intégration Pro Santé Connect](https://alabenaicha.me/fr/insights/pro-sante-connect-integration). Point d'attention : un access token PSC vit deux minutes. Prévoyez un jeton frais à chaque ouverture de session IMAP ou SMTP, et testez avec votre opérateur le comportement d'une session IMAP déjà ouverte lorsque le jeton expire ; il n'est pas décrit de la même façon partout. Pour une boîte applicative, le certificat ORG AUTH\_CLI de l'IGC-Santé doit porter l'identifiant national de la structure détentrice dans le champ OU du DN. ## Envoyer un document de santé : IHE XDM, CDA et PDF Un message qui transporte un document de santé doit, selon l'exigence ECO.2.1.1 : * ne concerner qu'un seul usager ; * contenir une archive ZIP au format IHE XDM avec un ou plusieurs documents CDA R2 de niveau 1 ou 3, conformes au volet d'échange de documents du CI-SIS ; * contenir les mêmes documents au format PDF/A-1, générés à partir du CDA, pour une lecture sans logiciel métier. Le destinataire identifie le patient par la métadonnée `patientId` (matricule INS) du fichier `METADATA.XML` de l'archive, pas par l'objet du message. L'objet commence par le préfixe `XDM/1.0/DDM+`, que le LPS du destinataire doit masquer à l'affichage. Trois en-têtes SMTP sont attendus : ```text From: DOE Jane To: dr.roe@cabinet-exemple.mssante.fr Subject: XDM/1.0/DDM+CR d'examens biologiques DOE Jane 01/01/1970 X-MSS-CODECDA: 11502-2 X-MSS-INS: O X-MSS-NIL: REF-PRODUIT-EXEMPLE ``` `X-MSS-CODECDA` reprend le code du document CDA (multivalué s'il y en a plusieurs), `X-MSS-INS` vaut `O` si l'archive contient une INS qualifiée et `N` sinon, et `X-MSS-NIL` porte la référence produit déclarée sur la plateforme Convergence, sur tous les messages. Les deux premiers ne sont posés que si une archive XDM est jointe. Les contraintes de structure du CDA lui-même sont celles du CI-SIS ; si vous convertissez ces documents vers FHIR, l'article [C-CDA vers FHIR](https://alabenaicha.me/fr/insights/c-cda-to-fhir-document-exchange) couvre les pièges de mapping, et [FR Core, INS et CI-SIS](https://alabenaicha.me/fr/insights/fhir-fr-core-ins-cisis) le volet identité. ## La messagerie patient de Mon espace santé À la création de Mon espace santé, chaque usager reçoit une adresse construite sur son matricule INS (15 caractères) : `@patient.mssante.fr`. Il n'existe pas d'annuaire des boîtes usagers. Conséquences pratiques : * l'adresse ne peut être construite qu'à partir d'une INS au statut qualifiée ; * un patient peut s'être opposé à Mon espace santé ou l'avoir fermé ; l'envoi peut donc échouer légitimement ; * un usager ne peut pas engager la conversation, sauf pour envoyer une ordonnance à une officine ; il peut en revanche répondre, sous conditions ; * votre LPS doit distinguer visuellement les messages de patients et afficher nom de naissance, premier prénom et matricule INS de l'usager (ECO.3.1.1 et ECO.3.1.2). ## Trouver les destinataires : l'Annuaire Santé L'[Annuaire Santé](https://esante.gouv.fr/offres-services/annuaire-sante/acceder-aux-donnees) publie les adresses MSSanté des professionnels, hors liste rouge. Trois accès coexistent : une interface LDAP dédiée aux données MSSanté, des extractions de fichiers en libre accès (dont la correspondance MSSanté) et une API FHIR. Pour un carnet d'adresses intégré au LPS, les extractions ou l'API FHIR évite d'interroger le LDAP à chaque frappe. ## Ségur et calendrier La doctrine de l'ANS prévoit la généralisation de l'interopérabilité des LPS et DUI avec tous les opérateurs selon le calendrier des couloirs du Ségur vague 2, et l'arrêt par Mailiz de ses interfaces historiques au profit de l'API LPS. La [page éditeurs de Mailiz](https://mailiz.mssante.fr/ensavoirplus) confirme que les interfaces DST IMAP/SMTP et web services seront décommissionnées. Si votre logiciel s'appuie encore sur elles, la migration vers l'API LPS est à planifier maintenant. ## Checklist d'intégration * Famille de client identifiée (boîtes applicatives seules, ou boîtes personnelles et organisationnelles) et exigences du référentiel #2 reprises dans le backlog. * Raccordement Pro Santé Connect obtenu et serveur LPS intermédiaire en place. * Autoconfiguration lue à partir du domaine de la boîte, sans hôte codé en dur. * Certificat ORG AUTH\_CLI commandé sur l'IGC-Santé pour les boîtes applicatives, avec l'identifiant de la structure dans l'OU. * Production d'archives IHE XDM et de PDF/A-1 cohérents, un seul patient par message. * En-têtes `X-MSS-CODECDA`, `X-MSS-INS` et `X-MSS-NIL` posés, préfixe d'objet masqué à la réception. * Intégration automatique au dossier patient basée sur l'INS de `METADATA.XML`, avec une file de rapprochement pour les identités non qualifiées. * Messages patients distingués à l'écran, adresses usagers construites uniquement depuis une INS qualifiée. * Tests réalisés en recette avec au moins deux opérateurs différents. ## Pièges fréquents | Piège | Conséquence | | ----------------------------------------------- | ---------------------------------------------------------- | | Rapprochement du patient sur l'objet du message | Document classé dans le mauvais dossier | | Plusieurs patients dans un même message | Non conforme ; intégration impossible côté destinataire | | PDF généré indépendamment du CDA | Deux versions divergentes du même compte rendu | | Jeton PSC réutilisé au-delà de sa durée de vie | Échec d'authentification aléatoire à la reconnexion | | Boîtes MSSanté utilisées comme archive | Boîtes saturées ; le dossier patient doit rester la source | Les boîtes MSSanté contiennent des données de santé, et les briques que vous hébergez (serveur LPS intermédiaire, file d'intégration) aussi : la question de l'[hébergement HDS](https://alabenaicha.me/fr/insights/hds-health-data-hosting-france) se pose dès la conception. Si vous préparez une migration vers l'API LPS ou l'intégration de documents CDA reçus par MSSanté, je propose un accompagnement en [interopérabilité e-santé](https://alabenaicha.me/fr/services/digital-health-interoperability).