Intégrer Pro Santé Connect : obligations, périmètre et méthode pour une medtech
Pro Santé Connect n’est pas obligatoire pour tout logiciel qui traite des données de santé. En revanche, il devient une obligation ou une dépendance structurante dès lors qu’un produit relève d’un service numérique en santé national, territorial, fortement intégré à cet écosystème, ou qu’il se raccorde à un service qui impose une authentification professionnelle sectorielle.
Le mauvais départ consiste à demander « CPS ou e-CPS ? ». Le bon départ est de cartographier les acteurs, les flux et les services cibles : professionnel, patient, organisation, application, serveur ; accès à une IHM, appel applicatif, consultation ou alimentation d’un service socle. Cette analyse détermine si Pro Santé Connect (PSC) est obligatoire, simplement requis par un raccordement, ou hors périmètre.
Vous avez déjà qualifié le besoin PSC et vous préparez la recette ? Lisez le guide pratique Cartes CPS de test, e-CPS BAS et kits intégrateurs : préparer une recette Pro Santé Connect. Il détaille les cartes CPx de test, l’e-CPS de Bac à Sable, EDIT et les certificats logiciels de test.
Ce qu’est Pro Santé Connect
Pro Santé Connect est le fournisseur d’identité de référence pour les professionnels des secteurs sanitaire, social et médico-social. Il s’appuie sur le standard OpenID Connect et permet à un professionnel de s’authentifier avec un moyen d’identification électronique tel qu’une carte CPx ou une e-CPS.
PSC ne constitue pas un annuaire des patients, un mécanisme d’authentification usager ni un certificat serveur. Son rôle est d’établir une identité professionnelle sectorielle fiable et de transmettre, via les jetons OpenID Connect, les informations nécessaires au fournisseur de service pour ouvrir ou rattacher la session applicative.
Pour une équipe produit, PSC est donc à traiter comme une brique d’identité fédérée : redirection vers le fournisseur d’identité, retour de l’autorisation, validation des jetons, gestion de session, rapprochement du professionnel avec le compte local et contrôle des droits applicatifs.
Dans quels cas PSC est-il obligatoire ?
L’ANS indique que Pro Santé Connect est obligatoire depuis le 1er janvier 2023 pour les services numériques en santé nationaux, territoriaux ainsi que pour les services locaux fortement intégrés aux services nationaux ou territoriaux.
Cette règle ne permet pas de conclure qu’un produit est exempté uniquement parce qu’il est édité par une startup, hébergé en SaaS ou déployé dans un établissement. La qualification dépend de la fonction réelle du service, de son articulation avec l’écosystème de santé numérique, des exigences de ses services cibles et des conditions de déploiement ou de financement.
Matrice de qualification initiale
| Situation | Positionnement PSC | Analyse à mener |
|---|---|---|
| Service numérique en santé national | Obligatoire | Référentiel PSC et règles du service concerné |
| Service numérique en santé territorial | Obligatoire | Référentiel PSC et conditions de raccordement |
| Service local fortement intégré à un service national ou territorial | Obligatoire | Niveau d’intégration, cas d’usage et obligations du service cible |
| Produit se raccordant à un téléservice ou service socle protégé | Dépend du service cible ; PSC est fréquemment une condition d’accès du professionnel | Documentation de raccordement, règles d’habilitation, certificats et environnement de test |
| Client MSSanté avec BAL personnelle ou organisationnelle | PSC requis pour l’authentification du professionnel dans l’API LPS | Jeton PSC, XOAUTH2, choix de BAL et recette de bout en bout |
| Client MSSanté utilisant une BAL applicative | PSC ne couvre pas l’authentification de la BAL applicative | Certificat IGC Santé ORG AUTH_CLI et exigences MSSanté |
| Application locale sans intégration forte à des services nationaux/territoriaux | Pas obligatoirement requis du seul fait qu’elle traite des données de santé | Référentiel applicable, contrats, politique d’identité et analyse de risque |
| Connexion d’un patient ou d’un usager | PSC hors périmètre | Mécanisme d’identité usager approprié au cas d’usage |
La matrice sert à démarrer le cadrage ; elle ne remplace pas l’analyse du référentiel applicable ni la vérification des règles du service auquel vous souhaitez vous raccorder.
Afin d’être sur de votre/vos obligation(s) il est recommandé de répondre à ce questionnaire en ligne https://gnius.esante.gouv.fr/fr/reglementation/diagnostics-reglementation
PSC, certificats et identité : trois mécanismes à ne pas mélanger
Beaucoup de retards viennent d’une confusion entre identité professionnelle, identité patient et authentification applicative.
| Acteur ou besoin | Mécanisme principal | Exemple |
|---|---|---|
| Professionnel de santé ou du médico-social qui ouvre une session | Pro Santé Connect | Connexion d’un médecin à un SaaS de télésurveillance |
| Usager ou patient | Mécanisme d’identité usager du parcours concerné | Accès d’un patient à son espace ou à Mon espace santé |
| Serveur, application ou organisation qui appelle un service | Certificat IGC Santé ou autre mécanisme imposé par le service cible | Appel technique vers INSi ou flux applicatif MSSanté |
| Identité patient dans un flux de santé | INS, lorsqu’elle est requise par le cas d’usage | Construction d’une adresse patient MSSanté avec une INS qualifiée |
PSC authentifie une personne physique professionnelle. Un certificat logiciel peut authentifier une organisation ou une application, sécuriser une connexion technique ou être utilisé dans un mécanisme de signature selon son type. Les deux mécanismes peuvent coexister dans le même parcours.
Exemple : un médecin se connecte à votre application par PSC ; votre serveur appelle ensuite un téléservice avec les certificats et autorisations attendus par ce téléservice. Concevoir PSC ne dispense donc pas de traiter les certificats, les habilitations et les règles propres aux appels applicatifs.
Cas fréquent : PSC dans une intégration MSSanté
L’intégration MSSanté illustre bien la différence entre authentification professionnelle et authentification applicative.
Pour les BAL personnelles (PER) et organisationnelles (ORG), le professionnel s’authentifie avec PSC. Le jeton d’accès PSC est ensuite présenté à l’opérateur MSSanté au travers du mécanisme SASL XOAUTH2. Pour les BAL applicatives (APP), utilisées notamment pour les envois machine-à-machine, l’authentification repose sur un certificat logiciel IGC Santé ORG AUTH_CLI présenté dans le cadre TLS.
PSC est donc une dépendance directe du client MSS lorsque le produit manipule des BAL PER ou ORG. Mais cela ne suffit pas à rendre l’envoi conforme : le produit doit aussi rechercher l’adresse du destinataire dans l’Annuaire Santé, appliquer les règles de sélection de BAL, gérer les contraintes INS pour les destinataires usagers et construire les documents au format attendu.
Pour le détail de cette chaîne, consultez Envoyer des messages avec MS Santé : pourquoi l’Annuaire FHIR fait partie de l’intégration.
Ce que l’intégration implique techniquement
Une intégration PSC ne se limite pas à ajouter un bouton « Se connecter avec Pro Santé Connect ». Elle doit produire une chaîne d’identité cohérente et exploitable en sécurité.
1. Cadrer les parcours et les droits
Avant toute configuration OIDC, formalisez :
- les catégories de professionnels admis ;
- les données métier accessibles après authentification ;
- les règles de création, rapprochement et désactivation des comptes locaux ;
- les rôles et autorisations applicatives, qui ne doivent pas être déduits aveuglément de l’identité PSC ;
- les cas multi-exercice, multi-structure ou multi-rôle ;
- les scénarios d’erreur, de déconnexion et de session expirée ;
- les exigences de preuve, de journalisation et d’audit.
Le jeton PSC établit une identité ; il ne remplace pas votre modèle d’autorisation métier. Une même personne peut avoir plusieurs contextes d’exercice et des droits différents selon l’organisation ou le dossier traité.
2. Concevoir le flux OpenID Connect
Côté application, prévoyez au minimum :
- la redirection vers l’autorité PSC ;
- la validation stricte du retour d’autorisation et de l’état de session ;
- la vérification de la signature, de l’émetteur, de l’audience, de l’expiration et des contraintes de nonce des jetons ;
- l’extraction et la persistance maîtrisée des attributs nécessaires ;
- une session applicative séparée de la durée de vie du jeton ;
- la révocation ou le renouvellement des sessions selon les règles applicables ;
- une journalisation qui permette d’auditer l’accès sans exposer inutilement des données sensibles.
Ne liez pas votre modèle de données à une représentation fragile ou non versionnée des claims. Isolez le mapping PSC dans un composant d’identité, versionnez les règles de rapprochement et testez les évolutions de profil avant leur déploiement.
3. Gérer le rapprochement de comptes
Le rapprochement entre l’identité PSC et un compte déjà présent est un risque fonctionnel majeur. Le produit doit pouvoir répondre de façon déterministe à des cas tels que :
- première connexion d’un professionnel ;
- professionnel déjà connu sous un autre identifiant ;
- évolution ou coexistence d’identifiants ;
- changement de structure ou de situation d’exercice ;
- compte local désactivé, suspendu ou en attente de validation ;
- homonymie ou rapprochement ambigu.
La bonne approche est de formaliser une politique explicite : clé de correspondance, traitement des identifiants secondaires, validation manuelle lorsque nécessaire, conservation de l’historique et règles d’autorisation par contexte.
4. Préparer la recette dès le backlog initial
Une intégration PSC ne peut pas être recettée correctement avec un unique compte « happy path ». Il faut des identités de test, des profils représentatifs, des scénarios de connexion et des moyens d’authentification adaptés.
Les supports disponibles comprennent notamment les cartes CPx de test, les kits intégrateurs, l’e-CPS de Bac à Sable, les identités fictives EDIT et les certificats logiciels de test. L’article Cartes CPS de test, e-CPS BAS et kits intégrateurs explique comment les choisir et les commander/configurer.
La checklist avant le premier sprint
- Le service est qualifié : PSC obligatoire, condition de raccordement, recommandé ou hors périmètre.
- Les textes, référentiels et règles de raccordement applicables sont identifiés et datés.
- Les professionnels, usagers, organisations, applications et serveurs à authentifier sont distingués.
- Les parcours professionnels et leurs droits sont formalisés.
- La politique de création et de rapprochement de comptes locaux est documentée.
- Le flux OIDC, les URLs de retour, les secrets, certificats et mécanismes de rotation sont définis.
- Les règles de journalisation et de conservation des traces sont définies avec les parties sécurité et conformité.
- Les identités de test, les cartes CPx ou e-CPS BAS et l’organisation EDIT sont planifiées.
- Les dépendances avec INS, MSSanté, Annuaire Santé, DMP / Mon espace santé et les autres services socles sont inscrites au backlog.
- Les critères d’acceptation et les scénarios de recette sont écrits avant le développement.
Les erreurs qui coûtent du temps
- Déclarer PSC obligatoire pour toute medtech. L’obligation dépend du périmètre réel du service et des raccordements visés.
- Traiter PSC comme un simple bouton de connexion. Le rapprochement de compte, les droits, les contextes d’exercice et les traces sont tout aussi structurants.
- Confondre PSC et certificat logiciel. L’un authentifie le professionnel, l’autre peut authentifier l’application, le serveur ou l’organisation.
- Prévoir les moyens de test à la fin. Sans identités, e-CPS BAS, cartes CPx ou certificats, le développement peut être terminé sans possibilité de recette fiable.
- Déduire les droits métier exclusivement des claims PSC. L’identité ne remplace pas une politique d’autorisation explicite et administrable.
- Oublier les autres socles. PSC règle l’identité professionnelle ; il ne remplace ni l’INS, ni l’Annuaire Santé, ni la conformité MSSanté, ni les certificats requis par les services cibles.
Conclusion : qualifier avant de configurer
Pour une medtech, la bonne séquence est la suivante : qualifier le périmètre réglementaire et les raccordements, identifier les acteurs et les flux, concevoir le modèle identité/autorisation, puis préparer les environnements et moyens de recette avant de développer.
PSC devient alors un composant maîtrisé de l’architecture, plutôt qu’un sujet de conformité découvert trop tard au moment de raccorder un service ou de préparer un déploiement hospitalier.
Vous avez déterminé que PSC entre dans votre périmètre ? Passez à l’étape suivante avec le guide Cartes CPS de test, e-CPS BAS et kits intégrateurs : préparer une recette Pro Santé Connect.
FAQ
Pro Santé Connect est-il obligatoire pour toute application de santé ?
Non. PSC ne devient pas obligatoire du seul fait qu’une application traite des données de santé. Il concerne l’identification des professionnels du sanitaire, du social et du médico-social. L’ANS indique qu’il est obligatoire depuis le 1er janvier 2023 pour les services numériques en santé nationaux, territoriaux et les services locaux qui y sont fortement intégrés. Pour les autres produits, il faut qualifier les raccordements, le référentiel applicable et les exigences contractuelles ou de financement.
Pro Santé Connect est-il destiné aux patients ?
Non. PSC est destiné à l’identification des professionnels des secteurs sanitaire, social et médico-social. L’authentification des patients et usagers relève d’autres mécanismes, à choisir selon le service, le parcours et les règles applicables.
Quelle est la différence entre PSC et un certificat IGC Santé ?
PSC authentifie une personne physique professionnelle. Un certificat IGC Santé peut, selon son type, authentifier une application, un serveur ou une organisation, sécuriser un échange applicatif ou participer à un mécanisme de signature. Les deux peuvent intervenir dans une même architecture.
PSC est-il nécessaire pour intégrer MSSanté ?
Oui pour les BAL personnelles et organisationnelles utilisées via l’API LPS : le professionnel est authentifié avec PSC et le jeton est utilisé dans le mécanisme XOAUTH2. Pour une BAL applicative, l’authentification repose sur un certificat ORG AUTH_CLI et non sur PSC.
Comment tester une intégration Pro Santé Connect ?
La recette repose sur des identités représentatives, des scénarios de connexion et des moyens de test adaptés : e-CPS BAS, identités EDIT, cartes CPx de test ou kits intégrateurs et, lorsque des flux serveur sont concernés, certificats logiciels de test. Consultez le guide Cartes CPS de test, e-CPS BAS et kits intégrateurs.
Sources officielles
- ANS – Pro Santé Connect : https://esante.gouv.fr/produits-services/pro-sante-connect
- ANS – Doctrine Pro Santé Connect et IGC Santé : https://esante.gouv.fr/doctrine/pro-sante-connect-igc-sante
- ANS – Référentiel Pro Santé Connect : https://esante.gouv.fr/ens/offre/pro-sante-connect
- ANS – Socle technique CPS : https://esante.gouv.fr/produits-services/socle-technique-cps