L’habilitation EDC PSC de l’éditeur du proxy n’est à réaliser qu’une seule fois par l’éditeur du proxy tiers, y compris lorsque ce proxy est utilisé par plusieurs solutions logicielles ou partagé entre plusieurs éditeurs.

Concernant le référencement « Opérateur Proxy », l’entité devant réaliser ce parcours dépend de l’organisation retenue en production :

1. Si l’éditeur du proxy tiers opère lui-même le proxy en mode SaaS, alors c’est à lui de réaliser le parcours de référencement « Opérateur Proxy » dans le cadre de l’Espace de Confiance Pro Santé Connect.
2. Si l’éditeur du logiciel métier (DUI, LPS, etc.) opère une instance dédiée du proxy en mode SaaS, alors c’est à l’éditeur du logiciel métier de réaliser le parcours de référencement « Opérateur Proxy » pour l’instance qu’il exploite.

Non. Pour accéder à l’environnement de test de l’API Pro Santé Connect de l’INSi dans le cadre du PMT, il n’est pas nécessaire d’avoir préalablement obtenu une homologation du téléservice INSi via d'autres APIs (carte CPS, e-CPS ou certificat).

Toutefois, une expérience préalable sur les autres modes d’accès à l’INSi peut constituer un avantage. Elle permet notamment de mieux maîtriser les attendus du téléservice et peut, dans certains cas, faciliter ou accélérer les démarches d’homologation ultérieures, notamment dans le cadre d’une homologation en extension de périmètre.

Le prérequis de maturité technique (PMT) se situe en amont des tests PASSI

Ce test d’accrochage permet de valider concrètement un test d’authentification PSC via l’API PSC, afin de démontrer l’accès aux services socles. Il constitue ainsi un moyen de sécuriser la suite du parcours et des développements en confirmant la capacité d’accès au DMP via Pro Santé Connect.
Il n’est pas obligatoire lors de l’accès à l’espace de test du CNDA, mais il relève des bonnes pratiques recommandées.

Nous vous conseillons de voir le replay du webinaire du 4 juin 2026 sur "l'architecture logicielle" qui traite de cette question de test d'accrochage : https://esante.gouv.fr/webinaires/segur-vague-2-architecture-des-solutions-homologation-cnda-et-pro-sante-connect

Pour voir un exemple de test d'accrochage sur un environnement potsman vous pouvez regarder cette vidéo :  https://www.youtube.com/watch?v=1XMThUSO_Po

N.B. Attention lors de vos tests d'accrochage au CNDA il faudra utiliser directement le couple LPS et proxy et non un environnement postman

Des travaux de convergence sont prévus dans le cadre du développement du portefeuille européen d’identité numérique (European Digital Identity Wallet). Ce dispositif a notamment vocation à favoriser l’interopérabilité et la fédération des mécanismes d’identification et d’authentification à l’échelle européenne.

Chaque solution logicielle métier dispose de son propre certificat. Ainsi, un certificat est associé à chaque composant principal (LPS) et au proxy partagé. C'est ce certificat qui est utilisé dans le cadre des échanges avec Pro Santé Connect et les services tiers concernés.

Une candidature « Éditeur de solution logicielle » doit être déposée pour chaque composant principal (LPS). Par ailleurs, une candidature unique doit être déposée pour le Proxy e-santé partagé.

Ainsi, le cas d’une architecture comportant deux composants principaux et un Proxy e-santé partagé, trois candidatures doivent être déposées au total : deux candidatures « Éditeur de solution logicielle » et une candidature « Éditeur de Proxy e-santé ».

Le Proxy e-Santé est utilisé pour sécuriser et standardiser les échanges entre le logiciel métier (Composant Principal LPS) et les API Pro Santé Connectées (DMP, INSi, Ordonnance Numérique, etc.).

Il gère les mécanismes d’authentification et de sécurité (mTLS, OAuth2, OpenID), facilite l’intégration technique, et permet de mutualiser certains développements.

Même si cela ajoute de la complexité, le Proxy e-Santé est obligatoire pour répondre aux exigences réglementaires et garantir la conformité des accès.​

Il s'agit du cas d'un Proxy e-Santé tiers qui embarque des Composants Additionnels Non Autonomes (ou logiciels EAI).​

Dans le parcours Ségur, l'éditeur de la Solution Logicielle déclare qu'il utilise un Proxy e-Santé tiers et des Composants Additionnels Non Autonomes.​

Dans le parcours d'habilitation EDC PSC, l'éditeur ELU déclare qu'il utilise un Proxy e-Santé tiers.

Dans le parcours d'homologation au CNDA, l'éditeur de la Solution Logicielle déclare qu'il utilise des Composants Additionnels Non Autonomes (EAI) intégrés au Proxy e-Santé et celui-ci bénéficiera d'un plan de test adapté.

Si une Solution Logicielle fait appel à plusieurs téléservices (INSi, DMP, Ordonnance Numérique, MSSanté, etc.), elle doit disposer d’une architecture conforme aux exigences de l’Espace de Confiance Pro Santé Connect (EDC PSC), comprenant au minimum un composant principal (LPS) et un Proxy e-Santé.

Chaque composant de cette architecture doit être déclaré et faire l’objet des habilitations EDC PSC appropriées. L’éditeur de chaque composant est responsable de sa conformité et de sa sécurité, ainsi que de celles des composants intégrés ou interfacés avec celui-ci, conformément aux exigences de Pro Santé Connect et du CNDA.

Par ailleurs, si une même solution consomme plusieurs téléservices, elle suit un parcours d’habilitation EDC PSC unique pour son architecture déclarée, mais doit obtenir autant d’homologations CNDA que de téléservices concernés. Par exemple, une solution utilisant l’INS, le DMP et l’Ordonnance Numérique devra disposer d’une architecture habilitée EDC PSC et réaliser les homologations CNDA correspondantes pour chacun de ces téléservices.

Conformément au DSR, vous devez transmettre l’attestation d’homologation délivrée par le CNDA.

À défaut, il est possible de déposer au plus tard au jalon de la Date 2 de votre couloir (date de dépôt du dossier complet de preuves de conformité) un justificatif attestant du dépôt complet du dossier d’homologation auprès du CNDA pour l’homologation concernée.

Ce justificatif peut par exemple prendre la forme d’une copie d’écran de votre espace personnel CNDA montrant l’état d’avancement ou le pré-examen du dossier.

Image

L’utilisation d’un composant tiers déjà homologué par le CNDA ne dispense pas systématiquement de réaliser une demande dans le cadre de la mise en conformité de votre solution logicielle. Dans la majorité des cas, une démarche reste nécessaire, cela dépend du type de composant tiers et de son mode d’intégration.

Afin de clarifier les règles applicables, plusieurs situations doivent être distinguées :

Premier cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel non autonome

Un composant additionnel non autonome est appelé au CNDA "application EAI" dans le cas du DMP ou "moteur à IHM" masquée dans le cas de l'INSi.

Dans ce cas :

• Chaque application EAI ou chaque moteur à IHM masquée doit passer une homologation au CNDA.
• Chaque composant principal d'une solution logicielle qui intègre une application EAI / moteur à IHM masquée doit passer une homologation au CNDA.

A noter que l'homologation est complète mais plus rapide car les applications EAI/moteur à IHM masquée ont déjà validé une partie des tests à repasser.

Deuxième cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel autonome

Un composant additionnel autonome est une application (tierce) à part entière avec des IHM autonomes et visibles. Au CNDA, il s'agit d'une application autonome. Le composant principal d'une solution logicielle PS s'interface avec l'application autonome (tierce) via un appel contextuel. L'opérateur de la solution logicielle PS peut opérer une instance dédiée de la solution autonome (tierce) ou peut utiliser une instance mutualisée opérée par l'éditeur de la solution autonome tierce.

Dans ce cas :

• Chacune de ces applications autonomes tierces doit passer une homologation au CNDA.
• Dans le cas du composant principal de la solution logicielle PS :
  • Si l'opérateur du composant principal de la solution logicielle PS opère aussi une instance dédiée de l'application autonome (tierce) alors le composant principal de la solution logicielle PS doit passer une homologation d'interfaçage avec l'application autonome (tierce) dans le cadre de la conformité DMP.
  • Pour l’INSi et l’Ordonnance Numérique les éditeurs intégrant des composants tierces (moteur coté CNDA) doivent déposer une demande de conformité en mode apparent.
    • Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » et/ou « Ordonnance Numérique » en mode IHM apparente, l’éditeur n’a pas à constituer de dossier de preuves de tests, il peut passer directement à l’étape d’examen de conformité indiquée à l’Article 5.3 : Etape d’examen.
      Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » en mode IHM masquée (ou semi masquée), l’éditeur doit réaliser toute les phases de la procédure de conformité.

En vague 2 RIS et DRIMbox, la démarche d'homologation de la solution auprès du CNDA est obligatoire, qu'elle utilise des composants additionnels ou non pour l'intégration des services INS, ApCV ou DMP.

Comme précisé dans le DSR-IMG-DB-Va2 (page 39), pour obtenir l’autorisation d’accès aux espaces de tests du CNDA, il faut compléter le formulaire administratif et renseigner la partie « Prérequis de maturité technique » sur le guichet Éditeur EDC PSC, à la fois pour le Proxy Manager et pour les composants principaux de la Solution Logicielle. 

Vous pouvez vous référer au processus d'accès aux environnements de tests.

Pour toute question relative à Pro Santé Connect (PSC) ou sur l'espace de confiance PSC, veuillez-vous référer à la FAQ dédié.