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.

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é.

Oui. Même si le logiciel « technique » est unique, chaque nom commercial correspond à un NIL distinct, et nécessite donc une demande de conformité CNDA propre.

Si votre Solution a été référencée en vague 1, en renseignant le numéro de référencement vague 1 dans la candidature vague 2 les preuves déjà validées en vague 1 et reprises dans le REM vague 2 sont automatiquement retirées du périmètre de dépôt. Elles sont invisibilisées dans Convergence.

Point d'attention : si la candidature Vague 2 porte sur des profils différents de la Vague 1, alors les preuves du périmètre Vague 1 sont demandées pour ces profils.​

Non, il n’existe pas d’équivalence automatique des certificats CNDA. Si la solution a été déclarée dès l’origine au CNDA avec ses déclinaisons, l’homologation peut couvrir l’ensemble.
En revanche, chaque nom commercial distinct nécessite un NIL distinct, et donc une démarche CNDA propre, même si l’architecture est identique. Si l’architecture diffère, une nouvelle demande de conformité CNDA est obligatoire.

Il n'est possible de se baser que sur une seule Solution racine de la vague 2. Il vous appartient de choisir la solution racine qui vous paraît la plus pertinente. Pour ce faire, vous pouvez :

• Consulter la matrice d’équivalence Va2 du SONS sur lequel vous candidatez afin d’identifier, parmi les SONS sur lesquels votre Solution est candidate ou déjà référencée, le SONS ayant le plus d’exigences en commun. 
• Choisir la solution racine ayant le plus de composants en commun (composants additionnels et composant Proxy e-santé).
• Vous référer au calendrier réglementaire des SONS concernés. En effet, si la solution racine choisie n’a pas encore obtenu son référencement, elle devra l’obtenir avant le jalon Date 2 (dépôt dossier complet de preuves) de la dernière solution à référencer.

Attention la version de la solution racine doit être inférieure ou égale celle de la solution candidate.

Oui. Les dénominations commerciales déclarées lors du référencement sont transmises à l’Assurance Maladie et associées au numéro de référencement. C’est bien le nom commercial utilisé par le professionnel qui apparaît.