Questions fréquentes

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

Vous ne devez pas faire apparaitre l’identifiant de corrélation dans l’URL, les paramètres d'url ou dans les messages d'erreur, sauf en cas de fonctionnement par Code Flow auquel cas son usage doit être limité (1 fois).

Un résultat de TI Proxy comportant une ligne en N/A est une prise de risque importante de la part de la solution car si un audit démontre qu’en production le N/A est applicable, la solution perdra automatiquement son habilitation au niveau éditeur et le TI sera considéré comme une fausse déclaration.

Un mésusage peut (et doit souvent) déclencher une alerte, mais toutes les alertes ne sont pas des mésusages (exemple : une alerte de saturation de base de données est technique et non liée à un mauvais usage).

Il ne faut jamais citer un document de manière globale. Chaque référence doit être précise. Vous devez systématiquement indiquer le titre du document, le numéro de version, ainsi que le chapitre, la section ou le numéro de page exact traitant de l'exigence. Un référencement imprécis (ex: citer une PSSI de 50 pages sans préciser le paragraphe) entraîne systématiquement un refus de la preuve.

Si vous possédez un PAS, faites une référence précise aux chapitres concernés pour chaque point décrit. Si le PAS répond intégralement à l'exigence, la simple référence dans le template suffit. 

Soyez extrêmement vigilants sur les versions des documents cités.
Lorsque vous référencez un document, indiquez systématiquement les chapitres précis. Ne citez jamais un document de manière globale.