Authentification dans les soins de santé

• Quoi : avec le service fédéral d'authentification FAS, les citoyens s'authentifient au moyen de clés numériques, chacune liée à un niveau de fiabilité^[1][2].

• Comment : l'IDP eHealth s'appuie sur FAS, ne propose par application que des méthodes de connexion du niveau minimal requis et laisse ensuite l'utilisateur choisir une identité, comme une qualité professionnelle ^[3].

• Logiciels : une connexion de système à système avec les services de base de la plate-forme eHealth exige un certificat eHealth^[4], et l'échange de tokens via IAM eXchange est réservé aux Trusted Platforms ^[5].

• État : selon itsme, près de 68 % des connexions FAS passaient par itsme en 2023^[6] ; depuis le 14 octobre 2025, l'application MyGov.be est aussi une clé numérique^[7], que l'IDP eHealth accepte ^[3].

• Planification : eIDAS 2.0 oblige les États membres à fournir un portefeuille européen d'identité dans les 24 mois suivant certains actes d'exécution^[8] ; les parties privées qui doivent appliquer une authentification forte, y compris dans les soins de santé, l'acceptent sur demande au plus tard 36 mois après ces actes, à l'exception des micro et petites entreprises^[8].

• Hôpital : le single sign-on d'un logiciel propre vers une application web eHealth ne fonctionne pas avec des tokens basés sur un certificat d'établissement^[9].

• Plus grande incertitude : quelles clés l'IDP eHealth propose aujourd'hui : la spécification d'octobre 2025 cite itsme comme seul partenaire privé, et Smart-ID est disponible dans FAS depuis mars 2026 ^[3][10].

L'authentification consiste à établir qui se connecte ; dans les soins de santé belges, elle intervient dans trois situations : un citoyen ou un patient qui ouvre une application web ou mobile, un prestataire de soins qui utilise une application web ou son propre logiciel, et un logiciel qui appelle un service sans intervention humaine (machine à machine). Cette page en donne une vue d'ensemble ; les détails techniques figurent sur les sous-pages.

Pour les personnes, la base est le Federal Authentication Service (FAS) : les citoyens s'y authentifient au moyen de clés numériques afin que les pouvoirs publics sachent qui demande l'accès à leurs applications^[1]. FAS est l'un des services de Common Secure Access Management (CSAM)^[2], un ensemble de conventions et de règles relatives à la gestion des identités et des accès dans l'e-Government^[11]. Selon CSAM, diverses institutions de soins de santé font notamment appel à CSAM pour l'accès à leurs services en ligne^[11].

Une clé numérique est un moyen de connexion, tel que l'eID ou une application, et chaque clé est associée à un niveau de garantie (Level of Assurance)^[2]. Le cadre FAS applique sans dérogation au contexte belge les niveaux de garantie du règlement eIDAS^[2]. FAS authentifie uniquement des personnes physiques ; une personne qui agit au nom d'une entreprise le fait au moyen de rôles et de mandats de personnes physiques^[2].

La Plate-forme eHealth y superpose son propre service d'identité I.AM : l'eHealth IDP (identity provider pour les applications web) s'appuie sur BOSA FAS pour l'authentification des utilisateurs^[3], tout comme I.AM Connect dans IAM eXchange^[5]. Après l'authentification, I.AM applique les règles d'accès de l'application et accorde ou refuse l'accès^[12]. La structure de la famille I.AM est présentée sur I.AM (Identity & Access Management), les certificats destinés aux systèmes sur Certificats eHealth et les autres services gratuits sur Services de base de la plate-forme eHealth.

Clés numériques et leur niveau

FAS et l'eHealth IDP utilisent les trois mêmes niveaux (faible, substantiel, élevé), mais les listes de clés proposées diffèrent^[1][3].

Selon itsme, itsme était en 2020 la méthode de connexion la plus utilisée pour les services eHealth^[14] et, en 2023, près de 68% de toutes les authentifications FAS passaient selon itsme par itsme, 16% par l'eID et 16% par d'autres méthodes^[6] ; il s'agit de chiffres fournis par le prestataire lui-même. En janvier 2019, la Plate-forme eHealth proposait, selon un manuel de l'INAMI, trois méthodes de connexion : eID, itsme et nom d'utilisateur et mot de passe avec un code TOTP^[15]. Cette application TOTP devait alors être préalablement enregistrée sur le portail fédéral (CSAM, Mijn digitale sleutels), au moyen d'une connexion unique avec l'eID^[15]. La procédure de reconnaissance des clés privées telles qu'itsme est décrite sur CSAM.

Citoyens et patients

L'application mobile Masanté est uniquement accessible par une authentification forte avec CSAM-FAS, telle qu'itsme^[16]. Pour accélérer l'accès sur l'appareil, l'application impose un code PIN et/ou la biométrie^[16]. Lors de la première utilisation, l'utilisateur reçoit un message de consentement standard du service de base IAM de la Plate-forme eHealth, car l'application demande des données en son nom^[16].

D'autres applications destinées aux citoyens utilisent également ces clés. Certaines fonctions Metahub sont accessibles aux patients sous forme d'application web avec eID, itsme ou TOTP^[17] (voir Accès du patient et portails patients). L'eHealthBox (boîte aux lettres électronique sécurisée) est accessible sous forme d'application web avec eID, itsme ou TOTP^[18]. L'accès à My eBox, utilisée pour l'invitation au dépistage organisé du cancer du col de l'utérus, passe par la plate-forme CSAM^[19] (voir Dépistage organisé (numérique)). Aucune source primaire n'a été trouvée sur la manière dont les portails patients des hubs assurent la connexion.

Prestataires de soins

Après l'authentification, l'eHealth IDP recherche dans les sources authentiques eHealth des identités supplémentaires de l'utilisateur, telles qu'une qualité professionnelle, parmi lesquelles l'utilisateur choisit pour chaque application^[3]. L'IDP connaît cinq profils : Citizen, Quality (professionnel), Organization, Mandate et Parent^[3] ; le profil Quality identifie l'utilisateur comme professionnel, par exemple comme médecin^[3]. Pour eLys, la source mentionne CSAM pour la connexion et CoBRHA pour l'attribution du rôle^[20].

Chaque application placée derrière l'eHealth IDP reçoit un niveau de sécurité minimal, et l'IDP ne propose que les méthodes de connexion qui atteignent ce minimum^[3]. Si une deuxième application exige un niveau supérieur au cours de la même session de navigation, l'utilisateur doit se reconnecter avec une méthode de ce niveau^[3]. Aucune liste publique des applications eHealth et de leur niveau minimal n'a été trouvée.

Exemples d'applications web destinées aux prestataires de soins :

Pour les soins à distance, la réglementation impose elle-même des exigences. Sauf en cas de téléphone, la technologie utilisée pour une téléconsultation doit authentifier le prestataire de soins et le patient au moyen d'un dispositif FAS ou d'un système propre au fournisseur qui satisfait à des conditions cumulatives^[25] : enregistrement unique de l'identité avec un dispositif FAS atteignant au moins le niveau fixé par le Comité de gestion de la Plate-forme eHealth^[25], conditions du niveau substantiel du règlement d'exécution (UE) 2015/1502 et, pour le dispositif propre et son activation, conditions du niveau faible^[25] (voir Téléconsultation (consultation à distance)). Pour la télésurveillance de l'insuffisance cardiaque, les prestataires de soins et le patient s'authentifient au moyen d'un dispositif intégré dans FAS ou d'un système propre au fournisseur, sous réserve de conditions cumulatives^[26] (voir Télésurveillance et orientation thérapeutique en cas d'insuffisance cardiaque chronique).

Logiciels et machine à machine

Un certificat eHealth permet à un prestataire de soins ou à une organisation de s'authentifier comme prestataire de soins ou établissement reconnu, et il est requis dès qu'un logiciel veut accéder aux services de base eHealth par une connexion de système à système^[4]. Le STS (Security Token Service) de la Plate-forme eHealth délivre des tokens SAML : Holder-of-Key pour les utilisateurs finaux et Sender-Vouches pour les prestataires de services, selon le document « eHealth-IAM Overview » de 2013^[27].

Deux transitions entre ces univers sont décrites :

• D'un logiciel propre à une application web (SSO du client « lourd » au client « léger ») : un utilisateur qui possède un token de session STS dans son logiciel peut le réutiliser pour se connecter à l'eHealth IDP ou à I.AM Connect^[9]. À cette fin, le logiciel demande un bearer token valable au maximum 10 minutes^[9]. Cela ne fonctionne pas avec les tokens STS fondés sur un certificat eHealth d'un établissement ou d'une organisation^[9].

• De REST à SOAP (IAM eXchange) : IAM eXchange délivre des tokens de session SAML Holder-of-Key qui confirment qu'un client possède un profil eHealth valide, afin que les applications REST et OIDC puissent appeler les services SOAP existants^[5]. Les clients techniques (flux client credentials) ne peuvent pas échanger de tokens ; cette fonction est réservée aux Trusted Platforms^[5]. Comme la plate-forme agit au nom de l'utilisateur final, celui-ci doit d'abord donner son consentement^[5]. Le JWT délivré par I.AM Connect après la conversion contient le profil actif de l'utilisateur^[9].

L'engagement relatif à I.AM Connect Token Exchange qualifie les tokens échangés de credentials secondaires représentant une délégation des droits de l'utilisateur final et devant bénéficier de la protection maximale^[28]. Un token échangé ne peut jamais conférer davantage de droits que le token original^[28]. L'envoi de données non pseudonymisées à un service destinataire qui exige une pseudonymisation par token exchange constitue, selon l'engagement, une violation de données^[28] ; les cas concernés sont décrits sur I.AM (Identity & Access Management) et UHMEP / prescription de renvoi électronique.

MyGov.be et le portefeuille européen d'identité numérique

MyGov.be est une application des autorités fédérales : selon le Conseil des ministres du 1 septembre 2023, le SPF BOSA gère le programme de développement, et l'application devient la mise en œuvre belge du portefeuille numérique européen^[29]. L'un des cinq volets stratégiques est une identité numérique mobile, dotée de fonctions d'identification, d'authentification et de signature ou de cachet électronique^[29]. Depuis le 14 octobre 2025, l'application peut aussi servir de clé numérique pour se connecter aux services publics en ligne^[7] ; elle est activée avec l'eID et un lecteur de carte ou avec un compte itsme actif^[7]. La version 1.4 de la spécification eHealth IDP (14 octobre 2025) a ajouté MyGov comme méthode de connexion^[3].

Une présentation d'avril 2026 sur l'e-santé en Belgique décrit MyGov.be comme le portefeuille belge d'identité numérique, conforme à eIDAS 2.0, avec une authentification fondée sur le Registre national, un accès à l'eBox des citoyens et la conservation de documents numériques juridiquement valables avec vérification hors ligne^[30]. Selon cette présentation, les certificats de vaccination COVID, la carte isi+ des enfants, les actes de naissance et de mariage ainsi que le statut social (MyBEnefits) peuvent notamment déjà être chargés dans l'application^[30]. Pour les soins de santé, l'intention est de charger dans l'application, à l'appui de l'EHDS, la carte européenne d'assurance maladie (EHIC) et les prescriptions électroniques via Recip-e, puis de les transmettre à la pharmacie au moyen d'un code QR^[30]. Lors du lancement, The Brussels Times annonçait que l'EHIC serait intégrée à l'application d'ici 2026^[31] ; sa réalisation n'est pas confirmée.

Le cadre européen découle du règlement eIDAS. Chaque État membre doit fournir au moins un portefeuille européen d'identité numérique dans les 24 mois suivant l'entrée en vigueur des actes d'exécution visés^[8]. Les services publics qui exigent une identification électronique doivent également accepter ce portefeuille^[8]. Les parties privées tenues d'appliquer une authentification forte des utilisateurs, notamment dans les soins de santé, l'acceptent à la demande volontaire de l'utilisateur au plus tard 36 mois après les actes d'exécution, à l'exception des microentreprises et des petites entreprises^[8]. Les considérants citent le secteur de la santé comme exemple dans lequel l'authentification hors ligne est importante, notamment afin de pouvoir se fier aux prescriptions électroniques figurant sur des codes QR^[8].

Le règlement EHDS s'appuie sur ce cadre (voir Utilisation primaire des données de santé électroniques (EHDS)). Les citoyens peuvent s'identifier auprès des services d'accès au moyen de tout dispositif d'identification reconnu au titre d'eIDAS^[32], et les services d'accès destinés aux professionnels de santé ne sont accessibles qu'avec un dispositif reconnu au titre d'eIDAS ou un dispositif conforme aux spécifications communes de l'article 36^[32]. Le règlement d'exécution (UE) 2026/2099 précise l'échange transfrontalier via MyHealth@EU : lorsqu'un prestataire de soins demande un tel échange à la requête en ligne du patient, il identifie et authentifie ce patient au moyen d'un dispositif eIDAS d'abord d'un niveau au moins substantiel, puis, à partir du 26 mars 2030, d'un niveau élevé^[33]. Selon le même règlement d'exécution, à partir du 26 mars 2029, un professionnel de santé qui demande un échange transfrontalier doit accepter les attributs de santé présentés par le patient au moyen d'un portefeuille européen d'identité numérique^[33]. La position belge en matière d'identification transfrontalière est qu'un prestataire ou établissement de soins s'authentifie avec un dispositif eIDAS de niveau substantiel, y compris les EUDI wallets^[34].

• Deux voies de connexion : un hôpital connecte un logiciel de système à système au moyen d'un certificat eHealth^[4], tandis que les personnes se connectent aux applications web par FAS^[3]. Ce choix a des conséquences : le single sign-on d'un logiciel propre vers une application web eHealth ne fonctionne pas avec des tokens fondés sur un certificat d'établissement^[9]. La manière dont les DPI authentifient en pratique leurs utilisateurs individuels auprès des services eHealth n'a pas été trouvée : les spécifications décrivent les flux techniques, et non les pratiques propres à chaque secteur.

• Token exchange : toute partie qui conçoit des applications REST appelant des services SOAP au nom de l'utilisateur doit avoir le statut de Trusted Platform^[5] et assumer les obligations de l'engagement, notamment la pseudonymisation lorsque le service destinataire l'exige^[28].

• Niveau minimal : les collaborateurs qui utilisent des applications web ont besoin d'une clé correspondant au niveau de cette application^[3] ; une application exigeant un niveau supérieur au cours de la même session impose une nouvelle connexion^[3].

• Dépendance envers FAS : l'application Masanté et l'eHealth IDP s'appuient sur FAS^[16][3] ; une panne ou une modification d'une clé FAS affecte donc également les applications de soins (interprétation).

• Portails patients et portefeuille de l'UE : les parties privées du secteur des soins tenues d'appliquer une authentification forte devront accepter le portefeuille européen à la demande de l'utilisateur^[8] ; la question de savoir si et quand cette obligation s'appliquera au portail patients d'un hôpital dépend des actes d'exécution et de la mise en œuvre nationale (interprétation).

Recommandation : consignez, pour chaque connexion, si elle repose sur une connexion personnelle ou sur un certificat d'établissement, et suivez l'évolution de la spécification eHealth IDP pour les nouvelles clés (Smart-ID, MyGov.be) et pour l'acceptation du portefeuille européen.

1. Smart-ID : la spécification eHealth IDP (v1.4, 14 octobre 2025) présente itsme comme le seul partenaire privé reconnu^[3], tandis que Smart-ID est disponible comme clé FAS depuis le 16 mars 2026 selon ITdaily^[10]. La spécification est probablement obsolète ; il n'a pas été vérifié si l'eHealth IDP propose Smart-ID.

2. Niveau de MyGov.be : le SPF BOSA attribue à MyGov.be le niveau élevé avec code PIN et le niveau substantiel avec biométrie^[1], tandis que la spécification eHealth IDP mentionne uniquement le niveau élevé^[3].

3. Chiffres d'utilisation : les chiffres relatifs à l'utilisation des clés proviennent d'itsme elle-même^[6][14] ; aucune source de BOSA, indépendante d'itsme, n'a été trouvée.

4. Fin du code par token : seul un blog secondaire de décembre 2023 annonce la date du 31 janvier 2024^[13] ; aucune confirmation ultérieure n'a été trouvée.

5. Clés absentes de la spécification IDP : aucune information n'a été trouvée sur le point de savoir si l'eHealth IDP propose les clés eIDAS d'autres États membres ou un code de sécurité par SMS ou courriel ; FAS les connaît^[1].

6. MyGov.be comme portefeuille de l'UE : la présentation d'avril 2026 décrit MyGov.be comme conforme à eIDAS 2.0^[30], mais aucune notification formelle comme portefeuille européen ni aucun calendrier daté pour les documents de santé n'ont été trouvés^[30].

7. Délais eIDAS 2.0 : les délais de 24 et 36 mois courent à compter des actes d'exécution^[8] ; les actes servant de référence sont indiqués sur le règlement eIDAS.