Recherche effectué dans :

Filtre actif, cliquez pour en enlever un tag :

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (5 notes) :

Qu'est-ce que je dois faire signer à mes clients pour être autorisé à analyser leurs données confidentielles avec un LLM ? #llm, #rgpd, #droit, #security, #cloud-act, #secret-industriel, #selfhosting, #cloud-provider

Dernièrement, un ami m'a demandé : « qu'est-ce que je dois faire signer à mes clients pour être autorisé légalement à analyser leurs données confidentielles à l'aide d'un LLM, en fonction des types d'hébergement qui s'offrent à moi ? ».

Il travaille dans une entreprise sous-traitante industrielle. Contrairement à ma note du mois de juin, cette fois il ne s'agit pas de Données de santé (DDS), ni de PII, mais de secrets industriels. D'après ce que j'ai compris, le sujet est surtout contractuel.

Pour la suite de cette note, j'appelle Verdier Industries (nom fictif) l'entreprise de mon ami, afin d'incarner mes propos.

Dans cette note, je veux être très pratique : je souhaite générer des exemples de documents légaux à faire signer aux clients de Verdier Industries en fonction des options suivantes :

  • a. LLM en SaaS hors UE
  • b. LLM en SaaS en Europe hors France
  • c. LLM en SaaS en France
  • d. LLM installé sur une machine virtuelle avec GPU, louée chez Scaleway, OVH, etc.
  • e. LLM installé sur un serveur physique dans ses locaux

Idéalement, je souhaite pouvoir facilement comparer ces documents légaux et analyser l'impact que cela aura sur la relation commerciale.
Lesquels risquent de faire peur à ses clients ou au contraire de les rassurer.

Avant d'entrer dans le détail, une précision sur le terme « accès à un LLM ». Si je simplifie, un LLM s'utilise de deux façons très différentes :

  • via une interface de chat, dans un navigateur ou une application : c'est le cas de ChatGPT, Claude, Le Chat (Mistral AI), etc. Une personne écrit un message, le modèle répond. Ces noms désignent des interfaces de chat, pas le modèle qui est derrière. Les modèles portent d'autres noms.
  • via une API : une sorte de porte d'entrée technique qui permet à un logiciel d'envoyer des demandes au modèle automatiquement, sans qu'un humain tape dans une fenêtre de chat. Quelques exemples de modèles connus au mois de septembre 2026 : GPT-5.6 Sol, Claude Sonnet 5, DeepSeek 4.1 Flash.

Dans cette note, je ne traite que du second cas, l'accès par API.
La raison : c'est le modèle LLM qui est très difficile à héberger soi-même, pas l'interface de chat.
Un LLM a besoin de serveurs puissants, équipés de GPU coûteux. Une fois qu'on dispose d'un accès au modèle, héberger une interface de chat comme Open WebUI ou LibreChat est plutôt facile, car ces services fonctionnent sur des machines modestes.

Autrement dit, les cinq options ci-dessous décrivent surtout où et comment on accède au modèle, pas comment on l'affiche à l'écran.

Une dernière précision : cette note traite uniquement des questions légales. Je compte publier une autre note pour tout ce qui concerne les estimations de coût d'hébergement pour chacune de ces options.

Je détaille les cinq options d'accès à un LLM

J'ai fait le choix de découper les offres commerciales réellement disponibles pour chacune de ces options par localisation du traitement des données, et non pas par juridiction du fournisseur.

J'ai indiqué la juridiction du fournisseur dans le tableau de synthèse en fin de section. Je tiens à préciser que cette question de juridiction n'est pas anecdotique pour les clients.

Solutions SaaS

Un service SaaS, ici, veut dire que le modèle est fourni et exécuté par un tiers : les données de Verdier Industries et de ses clients partent chez le fournisseur, qui renvoie une réponse. Contrairement aux solutions IaaS, Verdier Industries n'a donc pas besoin d'un administrateur système, interne ou externe, pour gérer le serveur qui fait tourner le modèle, ni pour s'occuper du modèle.

LLM en SaaS hors UE (a)

Lieu de traitement des données : hors de l'Union européenne.

Les offres les plus courantes en API directe chez des producteurs de LLM sont :

On trouve aussi des AI providers comme Deepinfra ou Together AI.

LLM en SaaS en Europe hors France (b)

Lieu de traitement des données : dans l'UE, mais le fournisseur n'est pas français.

Côté américain, l'endpoint européen d'OpenAI traite les données en Irlande (Dublin). Attention, le contrat reste conclu avec une entité américaine : OpenAI reste donc soumis au Cloud Act.

On y trouve aussi des acteurs européens comme :

mais ces deux acteurs offrent un accès seulement à des modèles peu puissants.

LLM en SaaS en France (c)

Lieu de traitement des données : en France.

Les offres portées par une entité française sont :

En septembre 2026, Mistral AI et OVHcloud ne proposent que des modèles très peu puissants, bien loin derrière GLM-5.2 ou DeepSeek V4 Flash 0731 proposé par Scaleway.

Les acteurs américains peuvent aussi traiter dans des data centers en France, à condition de choisir explicitement un déploiement mono-région :

Pour tous ces acteurs, le contrat reste conclu avec une entité américaine : ils restent donc soumis au Cloud Act.

Solutions IaaS en France (d)

Une machine virtuelle avec GPU louée, c'est de l'IaaS : seule l'infrastructure est louée, le modèle LLM est installé et administré par un informaticien administrateur système de Verdier Industries. Le fournisseur n'a donc pas accès à l'OS de la machine virtuelle, donc pas aux données traitées.

Nuance : sur une machine virtuelle, l'hébergeur contrôle l'hyperviseur et pourrait en théorie accéder à la mémoire de la VM, ce qui n'est pas le cas sur un serveur bare metal.

Sur site, un serveur dans les locaux de Verdier Industries (e)

Le serveur est dans les locaux de Verdier Industries : aucun tiers n'intervient, ni pour la machine, ni pour le modèle.

L'informaticien administrateur système de Verdier Industries doit prendre en charge l'installation, sur ce serveur, de logiciels comme vLLM, Ollama ou llama.cpp permettant d'instancier des LLM.

À ce coût matériel, DeepSeek V4 Flash me dit qu'il faut ajouter la facture d'électricité : un serveur 8x H100 ou H200 consomme de l'ordre de 10 kW au niveau informatique et 14 kW au niveau de l'installation, refroidissement inclus, soit de l'ordre de 15 000 à 30 000 € par an à pleine charge selon le prix du kWh.

Concrètement, un tel serveur ne peut pas être placé dans une pièce de bureaux : il faut une alimentation électrique dédiée, un refroidissement dimensionné et une pièce isolée acoustiquement.

Tableau de synthèse

Option Fournisseur Pays de l'entité Datacenter Résidence UE Exposition CLOUD Act
SaaS hors UE OpenAI États-Unis États-Unis Non Oui
SaaS hors UE Anthropic États-Unis États-Unis Non Oui
SaaS hors UE Google États-Unis États-Unis Non Oui
SaaS hors UE Deepinfra États-Unis États-Unis Non Oui
SaaS hors UE Together AI États-Unis États-Unis Non Oui
SaaS Europe hors France OpenAI États-Unis UE (Irlande) Oui Oui
SaaS Europe hors France IONOS Allemagne UE Oui Non
SaaS Europe hors France STACKIT Allemagne UE Oui Non
SaaS en France Mistral AI France France Oui Non
SaaS en France Scaleway France France Oui Non
SaaS en France OVHcloud France France Oui Non
SaaS en France AWS États-Unis France Oui Oui
SaaS en France Microsoft États-Unis France Oui Oui
SaaS en France Google États-Unis France Oui Oui
SaaS en France Together AI États-Unis France Oui Oui
IaaS Scaleway France France Oui Non
IaaS OVHcloud France France Oui Non
IaaS Outscale France France Oui Non
IaaS Cloud Temple France France Oui Non
IaaS Together AI États-Unis France Oui Oui
IaaS AWS États-Unis France Oui Oui
IaaS Microsoft États-Unis France Oui Oui
IaaS Google États-Unis France Oui Oui
Sur site — Auto-hébergé Locaux de Verdier Industries Oui Non

Les 6 situations contractuelles

À partir de toutes les options d'hébergement d'un LLM listées précédemment, voici la liste de toutes les situations contractuelles.
Le classement va du plus simple à opérer (SaaS hors UE) au plus difficile (serveur sur site).

Cas Option Exposition des données à un tiers Transfert hors UE Cloud Act
1 (a) SaaS hors UE Oui Oui Oui
2 (b/c) SaaS datacenter en UE ou FR, entité US oui Non Oui
3 (b/c) SaaS datacenter en UE ou FR, entité UE oui Non Non
4 (d) IaaS US avec datacenter en FR non Non Oui
5 (d) IaaS FR avec data center en FR non Non Non
6 (e) sur site aucun tiers Non Non

Liste des démarches administratives à effectuer pour chaque situation contractuelle

Je pars de la situation suivante : Verdier Industries a déjà 50 clients sous contrat, il décide de réaliser les démarches légales auprès de ses clients afin d'être autorisé à envoyer des données confidentielles de ses clients à son LLM à travers la solution qu'il a retenue. Quels sont les documents à produire, envoyer au client, faire signer, etc.

Hypothèse générale : les contrats clients interdisent la divulgation des données confidentielles à un tiers sans accord écrit. Un avenant signé est donc nécessaire.

J'ai dressé la liste des étapes de ces procédures administratives avec l'aide de DeepSeek V4.1 Flash.

Cas 1 - SaaS hors UE

Procédure pas à pas :

  1. Verdier Industries demande à son fournisseur (par exemple OpenAI) les documents suivants et les rassemble :
    • son accord de confidentialité ;
    • son engagement de non-entraînement et de rétention zéro ;
    • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
    • ses CCT (Clauses Contractuelles Types), si données personnelles ;
    • la liste de ses sous-traitants ultérieurs ;
    • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017, 27018, 27701 et 42001, SecNumCloud ou HDS.
  2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
    • article 1 : autorisation de divulgation des données à un tiers ;
    • article 2 : confidentialité ;
    • article 3 : acceptation du risque Cloud Act ;
    • article 4, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD) et annexe des CCT.
  3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
  4. Verdier Industries envoie le dossier à chaque client.
  5. Le client signe l'avenant et le renvoie.
  6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Selon ce que prévoit le contrat client pour le RGPD :

  • Si le contrat contient une autorisation générale, par exemple : « Le client autorise Verdier Industries à recourir à des sous-traitants ultérieurs. Verdier Industries informe le client par écrit au moins 30 jours à l'avance, et le client peut s'opposer à cette modification. » Alors, pour le RGPD, Verdier envoie une simple notification, et si le client ne s'oppose pas dans les 30 jours, le nouveau sous-traitant est accepté, sans signature.
  • Si le contrat contient une autorisation spécifique, par exemple : « Verdier Industries ne peut confier les données à un sous-traitant ultérieur qu'après accord écrit préalable du client. » Alors Verdier doit faire signer l'avenant pour le RGPD aussi.
  • Dans les deux cas, ces clauses ne couvrent ni les secrets industriels ni le risque Cloud Act : pour ces deux points, l'avenant doit être signé.

Cas 2 - SaaS datacenter en UE ou FR, entité US

Les données sont traitées dans l'UE, mais le fournisseur est une entité américaine : il reste soumis au Cloud Act. Comme il n'y a pas de transfert hors UE, les CCT ne sont pas nécessaires.

Procédure pas à pas :

  1. Verdier Industries demande à son fournisseur (par exemple l'endpoint européen d'OpenAI) les documents suivants et les rassemble :
    • son accord de confidentialité ;
    • son engagement de non-entraînement et de rétention zéro ;
    • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
    • la liste de ses sous-traitants ultérieurs ;
    • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017, 27018, 27701 et 42001.
  2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
    • article 1 : autorisation de divulgation des données à un tiers ;
    • article 2 : confidentialité ;
    • article 3 : acceptation du risque Cloud Act ;
    • article 4, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD).
  3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
  4. Verdier Industries envoie le dossier à chaque client.
  5. Le client signe l'avenant et le renvoie.
  6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Pour le RGPD :

  • Si le contrat contient une autorisation générale de sous-traitance : une notification avec droit d'opposition suffit, sans signature.
  • S'il exige un accord écrit au cas par cas : l'avenant doit être signé.
  • Dans les deux cas, la confidentialité des secrets industriels et le risque Cloud Act imposent une signature.

Cas 3 - SaaS datacenter en UE ou FR, entité UE

Les données sont traitées dans l'UE par une entité européenne : ni transfert hors UE, ni exposition au Cloud Act.

Procédure pas à pas :

  1. Verdier Industries demande à son fournisseur (par exemple Scaleway) les documents suivants et les rassemble :
    • son accord de confidentialité ;
    • son engagement de non-entraînement et de rétention zéro ;
    • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
    • la liste de ses sous-traitants ultérieurs ;
    • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017, 27018, 27701 et 42001, SecNumCloud ou HDS.
  2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
    • article 1 : autorisation de divulgation des données à un tiers ;
    • article 2 : confidentialité ;
    • article 3, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD).
  3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
  4. Verdier Industries envoie le dossier à chaque client.
  5. Le client signe l'avenant et le renvoie.
  6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Pour le RGPD :

  • Si le contrat contient une autorisation générale de sous-traitance : une notification avec droit d'opposition suffit, sans signature.
  • S'il exige un accord écrit au cas par cas : l'avenant doit être signé.
  • Dans les deux cas, la confidentialité des secrets industriels impose une signature.

Cas 4 - IaaS US avec datacenter en FR

L'infrastructure est louée chez un hébergeur américain. L'hébergeur n'accède pas au contenu des données, mais il reste soumis au Cloud Act.

Procédure pas à pas :

  1. Verdier Industries demande à son hébergeur (par exemple AWS) les documents suivants et les rassemble :
    • son accord de confidentialité ;
    • son engagement de non-accès au contenu des données hébergées : mémoire vive, volumes de stockage et snapshots des machines virtuelles, sauf demande écrite de Verdier Industries ou réquisition d'une autorité judiciaire ou administrative compétente ;
    • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
    • la liste de ses sous-traitants ultérieurs ;
    • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017 et 27018.
  2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
    • article 1 : autorisation d'héberger les données sur une infrastructure tierce ;
    • article 2 : Verdier Industries garantit que l'hébergeur n'a pas accès au contenu des données, son accès étant limité à l'infrastructure nécessaire à l'hébergement, hors réquisition d'une autorité judiciaire ou administrative compétente ;
    • article 3 : acceptation du risque Cloud Act ;
    • article 4, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD).
  3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
  4. Verdier Industries envoie le dossier à chaque client.
  5. Le client signe l'avenant et le renvoie.
  6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Pour le RGPD :

  • Si le contrat contient une autorisation générale de sous-traitance : une notification avec droit d'opposition suffit, sans signature.
  • S'il exige un accord écrit au cas par cas : l'avenant doit être signé.
  • Dans les deux cas, la confidentialité des secrets industriels et le risque Cloud Act imposent une signature.

L'engagement de non-accès demandé à l'hébergeur peut être rédigé ainsi :

L'hébergeur s'engage à ne pas accéder au contenu des données hébergées, en particulier à la mémoire vive, aux volumes de stockage et aux snapshots des machines virtuelles, sauf demande écrite de Verdier Industries ou réquisition d'une autorité judiciaire ou administrative compétente. En cas de réquisition, l'hébergeur en informe Verdier Industries dans les meilleurs délais, sauf si la loi lui interdit de le faire.

Cas 5 - IaaS FR avec data center en FR

L'infrastructure est louée chez un hébergeur français ou européen : ni transfert hors UE, ni exposition au Cloud Act.

Procédure pas à pas :

  1. Verdier Industries demande à son hébergeur (par exemple Scaleway) les documents suivants et les rassemble :
    • son accord de confidentialité ;
    • son engagement de non-accès au contenu des données hébergées : mémoire vive, volumes de stockage et snapshots des machines virtuelles, sauf demande écrite de Verdier Industries ou réquisition d'une autorité judiciaire ou administrative compétente ;
    • son DPA (Data Processing Agreement, accord de traitement des données), si données personnelles ;
    • la liste de ses sous-traitants ultérieurs ;
    • ses certifications et attestations de sécurité : SOC 2 Type II (attestation) et ISO/IEC 27001 (certification), et le cas échéant ISO/IEC 27017 et 27018, SecNumCloud ou HDS.
  2. Verdier Industries rédige un avenant type au contrat client, structuré en articles :
    • article 1 : autorisation d'héberger les données sur une infrastructure tierce ;
    • article 2 : Verdier Industries garantit que l'hébergeur n'a pas accès au contenu des données, son accès étant limité à l'infrastructure nécessaire à l'hébergement, hors réquisition d'une autorité judiciaire ou administrative compétente ;
    • article 3, si données personnelles : autorisation de sous-traitance (article 28.2 du RGPD).
  3. Verdier Industries joint à l'avenant les documents obtenus à l'étape 1.
  4. Verdier Industries envoie le dossier à chaque client.
  5. Le client signe l'avenant et le renvoie.
  6. Verdier Industries archive l'avenant signé et ses pièces jointes par client.

Pour le RGPD :

  • Si le contrat contient une autorisation générale de sous-traitance : une notification avec droit d'opposition suffit, sans signature.
  • S'il exige un accord écrit au cas par cas : l'avenant doit être signé.
  • Dans les deux cas, la confidentialité des secrets industriels impose une signature.

L'engagement de non-accès demandé à l'hébergeur peut être rédigé ainsi :

L'hébergeur s'engage à ne pas accéder au contenu des données hébergées, en particulier à la mémoire vive, aux volumes de stockage et aux snapshots des machines virtuelles, sauf demande écrite de Verdier Industries ou réquisition d'une autorité judiciaire ou administrative compétente. En cas de réquisition, l'hébergeur en informe Verdier Industries dans les meilleurs délais, sauf si la loi lui interdit de le faire.

Cas 6 - Hébergement sur site

Le serveur est dans les locaux de Verdier Industries : aucun tiers n'intervient.

  • Aucun document à obtenir d'un tiers.
  • Aucun avenant à faire signer : les données ne quittent pas les locaux et ne sont divulguées à personne.
  • Pour rassurer le client, Verdier Industries peut l'informer que le traitement se fait en interne, sans sous-traitant ultérieur.

Liste des différences entre les situations contractuelles

Différences entre cas 2 et cas 1

  • Les données restent dans l'UE : les CCT ne sont plus nécessaires.
  • Le reste est identique, notamment le risque Cloud Act.

Différences entre cas 3 et cas 2

  • Le fournisseur est une entité européenne : plus de risque Cloud Act.
  • L'article 3 de l'avenant (acceptation du risque Cloud Act) disparaît.
  • Le reste est identique.

Différences entre cas 4 et cas 3

  • Le fournisseur ne traite plus les données : l'hébergeur n'accède pas au contenu, et l'avenant le garantit (article 2).
  • L'engagement de non-entraînement et de rétention zéro disparaît.
  • L'article 1 de l'avenant devient une autorisation d'héberger, et non plus une autorisation de divulgation.
  • Le risque Cloud Act réapparaît, car l'hébergeur est américain.

Différences entre cas 5 et cas 3

  • Le fournisseur ne traite plus les données : l'hébergeur n'accède pas au contenu, et l'avenant le garantit (article 2).
  • L'engagement de non-entraînement et de rétention zéro disparaît, remplacé par un engagement de non-accès au contenu.
  • L'article 1 de l'avenant devient une autorisation d'héberger, et non plus une autorisation de divulgation.
  • Les certifications attendues sont allégées : plus de 27701 ni 42001, qui n'ont plus de sens quand le fournisseur ne traite pas les données.
  • Le reste est identique : ni transfert hors UE, ni risque Cloud Act.

Différences entre cas 5 et cas 4

  • L'hébergeur est français ou européen : plus de risque Cloud Act.
  • L'article 3 de l'avenant (acceptation du risque Cloud Act) disparaît.
  • Le reste est identique.

Différences entre cas 6 et cas 5

  • Aucun tiers n'intervient : plus de documents à obtenir ni d'avenant à signer.
  • Il ne reste qu'une information au client, sans sous-traitant ultérieur.

Ce que je retiens

En travaillant cette note, je m'attendais, naïvement, à ce que le cas 5 — un LLM installé sur une machine virtuelle avec GPU louée chez un hébergeur français, dans un data center français — soit indolore contractuellement, c'est-à-dire qu'il n'exige aucun avenant aux contrats clients, mais ce n'est pas le cas.

En réalité, l'infrastructure reste louée à un tiers. Les contrats clients interdisent la divulgation des données confidentielles à un tiers sans accord écrit, et même si l'hébergeur n'accède pas au contenu, le fait de lui confier l'infrastructure qui porte les données déclenche quand même la signature.

Gagner en souveraineté réduit le nombre d'articles et la gravité du risque, mais ne ramène pas le travail contractuel à zéro.

Mon regard de praticien de terrain

Comme dans ma note du mois de juin sur les données de santé, je termine cette note avec un sentiment partagé.
Je suis un praticien de terrain : j'administre les serveurs, je gère les données de mes propres mains. En lisant tout cet édifice contractuel, je sais qu'il s'agit d'une convention humaine — ce que l'on nomme le constructivisme juridique, il me semble — souvent assez éloignée de la logique et de la pratique du terrain.

C'est un exercice d'analyse que j'aime beaucoup, mais qui m'est difficile. Il me crée une dissonance cognitive. D'un côté, je pense en praticien : je vois ce qu'on pourrait faire techniquement, concrètement, physiquement, pour renforcer la sécurité des données. De l'autre, ces protections juridiques sanctionnent devant un juge, mais ne protègent pas la donnée physiquement. C'est une protection par la sanction, pas une protection réelle. Ma culture hacker est de protéger pour de vrai, pas par le droit. Je crois que c'est là la source de ma dissonance, et parfois de mon énervement.

J'y trouve régulièrement de l'incohérence, parfois une forme d'hypocrisie, un peu comme un jeu de théâtre. Je ne dis pas que cela ne sert à rien — sans doute que ce cadre protège. Peut-être que mon regard de praticien me rend trop sensible à ce qui sépare la théorie juridique du terrain.

Certification HDS : ce que j'ai appris en creusant pour un ami #vibe-coding, #hébergeur-de-données-de-santé, #données-de-santé, #selfhosting, #rgpd

Un ami, professionnel libéral de santé, a vibe codé une application de gestion pour ses patients actuellement hébergée sur Supabase. Il souhaite migrer vers un Hébergeur de Données de Santé — il a notamment vu que Scaleway propose des services certifiés HDS — et m'a demandé si je connaissais un développeur pour l'accompagner dans ce projet.

J'ai croisé la notion de HDS pour la première fois en 2016, chez Tech-Angels. Depuis, j'ai suivi le sujet de loin sans jamais creuser.

Je profite de sa demande pour étudier le sujet en profondeur avant de lui répondre, et publier une note de ce que j'aurai appris.

Hébergeur de Données de Santé, c'est quoi ?

Toute personne physique ou morale qui héberge des données de santé à caractère personnel recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi médico-social pour le compte de personnes physiques ou morales à l'origine de la production ou du recueil de ces données ou pour le compte du patient lui-même, doit être agréée ou certifiée à cet effet.

Wikipedia

Texte de loi : article L.1111-8 du Code de la santé publique

Qu'est-ce qu'une donnée de santé (DDS) ?

Avant d'aller plus loin, j'ai eu besoin de comprendre précisément ce qu'est une "donnée de santé".

La CNIL distingue trois catégories (source) :

  • Les données de santé par nature : antécédents médicaux, diagnostics, traitements, résultats d'examens, ordonnances, comptes-rendus d'hospitalisation.
  • Les données qui deviennent des données de santé par croisement : le poids ou le nombre de pas seuls ne le sont pas, mais croisés avec d'autres mesures (tension artérielle, apports caloriques), ils le deviennent.
  • Les données qui deviennent des données de santé par leur usage : un rendez-vous chez un médecin, à lui seul, n'est pas une donnée de santé — mais le motif de la consultation, si.

Concrètement, dans l'application de mon ami, cela inclut probablement les noms des patients, leurs comptes-rendus, leurs ordonnances, les notes de suivi, et potentiellement les créneaux de rendez-vous liés à des actes de soins. Ce n'est pas seulement la « base médicale » au sens strict — c'est tout ce qui, relié à une personne identifiée, révèle qu'elle a reçu ou consulté pour des soins.

Un document médical sans identifiant, est-ce encore une donnée de santé ?

Une question qui m'est tout de suite venue à l'esprit : un document médical sans identifiant — pas de nom, pas de numéro de patient — est-ce encore une donnée de santé ?

La réponse dépend de la possibilité de ré-identification. Si le document est véritablement anonymisé, qu'il n'existe aucun moyen raisonnable de le relier à une personne, alors ce n'est plus une donnée de santé à caractère personnel — ça sort du périmètre du RGPD et du HDS.
Mais en pratique, c'est très difficile de le rendre vraiment anonyme. Un diagnostic rare, une date de traitement, ou un hôpital spécifique croisés avec d'autres sources, peuvent permettre de ré-identifier la personne.

La CNIL considère qu'une donnée est « personnelle » dès qu'il existe des « moyens raisonnablement susceptibles » de ré-identification.
Je pense qu'une bonne méthode pour estimer si c'est une DDS ou non, est de se mettre dans la peau d'un détective privé : si on me donnait ce document et tous les indices disponibles (date, hôpital, pathologie rare…), est-ce que je pourrais remonter à la personne ? Si la réponse est oui, c'est une donnée de santé. La question n'est donc pas « y a-t-il un nom dans le document ? » mais « quelqu'un, avec les moyens raisonnables, pourrait-il retrouver à qui ça appartient ? ».

Quels liens entre PII et DDS ?

Pour faire le lien avec les PII : toute Données de santé (DDS) est une PII, mais l'inverse n'est pas vrai. Un nom, une adresse email ou une adresse IP sont des PII parce qu'ils permettent d'identifier une personne.
Une donnée de santé est une PII qui révèle en plus quelque chose sur l'état de santé de cette personne. La distinction importe parce que le régime juridique n'est pas le même : les DDS sont soumises au RGPD comme les PII, mais avec des protections supplémentaires — secret médical, consentement explicite, obligation d'hébergement certifié HDS.

Qui est le "responsable de traitement" ?

Pour comprendre à qui s'applique la certification HDS, j'ai eu besoin de creuser la notion de "responsable de traitement" au sens du RGPD. Je croise ce terme régulièrement, je pense le comprendre dans les grandes lignes, mais j'ai voulu comprendre précisément où se situent les frontières.

D'après ce que j'ai compris, le responsable de traitement est la personne morale (ou la personne physique en entreprise individuelle) qui décide quoi faire avec les données personnelles. C'est elle qui détermine pourquoi on collecte les données et comment on les traite. Ce n'est pas l'individu (le médecin, l'infirmière) — c'est la structure juridique qui a la relation de soin avec le patient.

Concrètement :

Situation Responsable de traitement Pourquoi ?
Médecin salarié à l'hôpital L'hôpital (personne morale) C'est l'hôpital qui a la relation avec le patient, pas le médecin individuellement
Médecin dans un cabinet en SARL La SARL (personne morale) C'est la SARL qui signe les contrats et est responsable en cas de fuite
Médecin libéral en entreprise individuelle Le médecin (personne physique) Il n'y a pas de structure intermédiaire
Cabinet médical Le cabinet (personne morale) Le cabinet détermine les règles de gestion du système d'information
Doctolib Non — c'est un sous-traitant Doctolib est un moyen de communication entre le médecin et le patient, comme un téléphone amélioré
Scaleway Non — c'est un hébergeur Scaleway fournit l'infrastructure, il ne traite pas les données pour ses propres fins
Un développeur freelance qui maintient le serveur Non — c'est un sous-traitant Il administre l'infrastructure pour le compte du responsable de traitement

Cette distinction est cruciale pour comprendre la certification HDS. La loi dit que l'hébergement doit être certifié quand il est fait "pour le compte de" un responsable de traitement. Si tu es toi-même le responsable de traitement, tu n'héberges pas pour un tiers — tu héberges pour toi-même alors pas besoin de certification HDS (mais tu restes soumis au RGPD).

C'est pour ça qu'un médecin qui gère son propre dossier patient n'a pas besoin de HDS, mais qu'un hébergeur qui stocke les données pour le compte de ce médecin doit être certifié.

Un cas limite : les services médicaux numériques

Le cas des services médicaux numériques comme Poppins — "le dispositif médical numérique à domicile pour les enfants dyslexiques" — est compliqué. Qui est le responsable de traitement ?

La réponse dépend de qui décide quoi faire avec les données :

  • Si Poppins décide quelles données collecter et comment les utiliser (recherche, amélioration du produit) alors Poppins est responsable de traitement
  • Si l'orthophoniste décide quelles données utiliser pour le suivi du patient alors l'orthophoniste est responsable de traitement
  • Si les deux ont un rôle de décision → co-responsabilité (article 26 RGPD)

Où est la documentation officielle HDS ?

La documentation officielle est trouvable sur le site https://esante.gouv.fr/ => "Produits et services" => "HDS" => "Les référentiels de la procédure de certification".

La documentation HDS est nommée "référentiel de certifications HDS", elle est disponible au format PDF à cette adresse https://esante.gouv.fr/sites/default/files/media_entity/documents/referentiel_certification_hds---fr--v2.pdf.
Je n'ai pas trouvé de version HTML de ce document.

D'après ce que j'ai compris, ce sont des personnes de l'Agence du Numérique en Santé (ANS) qui ont rédigé les 29 pages du référentiel de certifications HDS.

Ce référentiel a été officialisé dans le Journal Officiel le 16 mai 2024 https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000049537692 par un ministre délégué à la santé. Ce document remplace la version précédente de 2018.

Et voici le communiqué de presse de l'ANS : Publication au Journal Officiel du référentiel de certification HDS : souveraineté des données et améliorations du référentiel.

Je suis ravi de lire la section Focus sur l’ajout d’exigences relatives à la souveraineté des données qui indique :

L’hébergement physique des données de santé doit être réalisé exclusivement sur le territoire d’un pays situé au sein de l’Espace Economique Européen.

source

🙂

Les 6 activités du référentiel HDS

Est considérée comme une activité d'hébergement de données de santé à caractère personnel sur support numérique ... des activités suivantes :

    1. La mise à disposition et le maintien en condition opérationnelle de sites physiques permettant d'héberger l'infrastructure matérielle du système d'information utilisé pour le traitement des données de santé ;
    1. La mise à disposition et le maintien en condition opérationnelle de l'infrastructure matérielle du système d'information utilisé pour le traitement de données de santé ;
    1. La mise à disposition et le maintien en condition opérationnelle de l'infrastructure virtuelle du système d'information utilisé pour le traitement des données de santé ;
    1. La mise à disposition et le maintien en condition opérationnelle de la plateforme d'hébergement d'applications du système d'information ;
    1. L'administration et l'exploitation du système d'information contenant les données de santé ;
    1. La sauvegarde des données de santé

page 6

Cette liste, reformulée en activités concrètes :

# Activité
1 Gestion des sites physiques : datacenters, baies serveurs, climatisation, alimentation électrique, sécurité des locaux
2 Gestion de l'infrastructure matérielle : serveurs physiques, stockage, câblage réseau, commutation
3 Gestion de l'infrastructure virtuelle : machines virtuelles, réseaux virtuels, stockage virtuel, hyperviseurs
4 Gestion de la plateforme applicative : bases de données managées, conteneurs, serveurs d'application
5 Gestion des sauvegardes : sauvegardes automatisées, stockage hors site, restauration
6 Administration et exploitation du SI : supervision, mises à jour, gestion des accès, support technique, astreinte

Il y a un point important que j'ai mis du temps à saisir : l'obligation de certification ne s'applique qu'à l'hébergement de données de santé pour un tiers qui est responsable de traitement.
Par conséquent, un professionnel de santé qui auto-héberge ses propres données n'a pas besoin de certification HDS pour les activités de cette liste qu'il administre lui-même.

Un exemple concret

Imaginons un cabinet de médecin, qui développe une application web qui contient des données de santé. Cette application est à destination de ses utilisateurs finaux, ses patients.

L'application web est codée en JavaScript avec PostgreSQL pour la persistance des données.

Pour le déploiement, le développeur employé directement par le cabinet de médecin fait le choix de déployer le tout sur une Virtual machine Scaleway.

D'après la version du 18 juin 2026 de la page "L’hébergement des données de santé et la certification HDS" de la documentation Scaleway, voici la liste des services certifiés HDS :

Les composants de fondations les plus importants sont bien certifiés. Je note au passage que l'offre "Managed Database for PostgreSQL and MySQL" n'est pas certifiée pour le moment.
Ceci n'est pas grave dans mon exemple si je déploie directement une image Docker de PostgreSQL directement sur la Virtual machine. Les sauvegardes peuvent être déposées dans Scaleway Object Storage qui lui est certifié.

Le cabinet de médecin devra souscrire un plan de support niveau Business à 250 € par mois pour pouvoir ensuite signer un contrat HDS :

Ensuite, Scaleway remettra au cabinet de médecin (son client) un document de garantie HDS, conformément au chapitre 8 du référentiel :

Voici à quoi pourrait ressembler ce document : "Exemple fictif d'une garantie de certification HDS de Scaleway".

Ensuite, les DevOps salariés directement du cabinet de santé déploient, maintiennent, administrent l'application sur les Virtual machine de Scaleway sans que le cabinet de médecin n'ait besoin de certification HDS car il n'est pas un hébergeur de données parce qu'il ne vend pas son service à d'autres professionnels. Seuls les patients directs utilisent son service.

Employé vs freelance : une distinction absurde mais légale

Il y a un point que j'ai mis du temps à saisir, et qui me paraît absurde mais qui est juridiquement cohérent.

Un employé (CDD ou CDI) du cabinet de santé qui gère le serveur, fait les mises à jour et les sauvegardes n'a pas besoin de certification HDS. Il fait partie de l'organisation du responsable de traitement — il n'est pas un sous-traitant.

Le même développeur, faisant exactement le même travail (SSH, mises à jour, sauvegardes), mais en freelance vendant 5 heures de prestation, a besoin de la certification HDS pour l'activité 5 (administration et exploitation). Pourquoi ? Parce qu'il est une entité séparée, un sous-traitant au sens RGPD, qui assure une activité d'hébergement pour le compte d'un tiers responsable de traitement.

La distinction ne se fait pas sur la nature du travail, mais sur le statut juridique de la personne qui le fait :

  • Employé du cabinet (CDD/CDI) avec accès SSH → pas de HDS, il fait partie du responsable de traitement
  • Freelance avec accès SSH permanent → HDS requis, il est sous-traitant et assure l'activité 5

Le cas du freelance qui livrerait uniquement du code

Si le freelance se contente de fournir du code — application, scripts d'infrastructure, configs de déploiement — et qu'il push tout dans un repo Git sans jamais avoir accès au serveur, à la base de données ni aux données, alors il n'assure aucune des 6 activités d'hébergement. Il livre un produit (du code), il n'opère pas un service.

Le test légal reste le même : "le fait d'assurer pour le compte du responsable de traitement tout ou partie des activités suivantes." Le verbe clé est "assurer" — c'est-à-dire exécuter, opérer, maintenir en condition opérationnelle. Les 6 activités décrivent des opérations sur l'infrastructure et le système, pas de la production de code.

La frontière se joue sur un point précis : qui appuie sur le bouton "déployer" ?

  • Si c'est un employé du cabinet de santé qui contrôle l'outil de déploiement (par exemple ArgoCD) et déclenche les déploiements → freelance = livreur de code → pas de HDS
  • Si le freelance a accès à cet outil et déclenche lui-même les déploiements → il participe à l'exploitation (activité 5) → HDS requis

Combien coûte une certification HDS pour les activités 4, 5 et 6 ?

J'ai cherché le processus officiel pour obtenir la certification HDS, voici ce que j'ai retenu :

  1. Mettre en place un Système de Management de la Sécurité de l'Information (SMSI) conforme à ISO 27001 (politique de sécurité, analyse de risques, gestion des accès, plan de continuité) — prérequis obligatoire.
  2. Choisir un organisme certificateur accrédité Comité français d'accréditation (Cofrac) (BSI, AFNOR, Bureau Veritas, LRQA…).
  3. Audit sur site en deux volets : conformité ISO 27001, puis exigences HDS spécifiques.
  4. Correction des non-conformités relevées.
  5. Obtention du certificat (valable 3 ans, avec audit de surveillance annuel).

J'ai volontairement laissé de côté le contenu concret du SMSI et de la norme ISO 27001 — je les connais mal. Cette note m'a donné envie d'explorer le sujet en profondeur, mais je le ferai dans une note séparée pour ne pas allonger encore celle-ci.

Les coûts typiques pour une TPE (< 10 personnes) :

Poste Estimation
Mise en place SMSI (conseil externe) 2 000 – 6 000 €
Audit initial COFRAC (ISO 27001 + HDS) 8 000 – 15 000 €
Audits de surveillance annuels (×2) 2 000 – 5 000 €
Sous-total coûts externes 12 000 – 26 000 €
Coût interne du salarié (100 – 200 h à 500 €/j soit ~70 €/h super brut) 7 000 – 14 000 €
Total sur 3 ans 19 000 – 40 000 €

Estimation en temps humain (pour une personne seule, en charge de tout) :

Étape Effort humain estimé Durée calendrier estimée
Mise en place SMSI (rédaction, procédures, analyse de risques, choix des outils) 40 – 100 heures 2 – 4 mois
Choix du certificateur et préparation du dossier 15 – 30 heures 3 – 6 semaines
Audit initial (sur site + préparation) 15 – 30 heures 1 – 2 semaines
Correction des non-conformités 20 – 60 heures 2 – 6 semaines
Obtention du certificat + 1er audit de surveillance 10 – 30 heures 1 – 2 mois
Total (avec SMSI ou maturité existante) 100 – 250 heures 6 – 9 mois
Total (sans SMSI préalable) 200 – 400 heures 12 – 18 mois

Sources

Les fourchettes de coûts et de durées ci-dessus sont des estimations de Fermi calculées par MiMO-V2-Pro, recalibrées pour coller aux données publiées :

  • Legiscope — Certification HDS hébergeur de données de santé 2026 (Dr. Thiébaut Devergranne, 23 mai 2026) : fourchette de 20 000 à 35 000 € sur 3 ans pour une TPE. Durée de 6 à 9 mois si l'organisation dispose déjà d'un SMSI ou d'une maturité ISO 27001 ; 12 à 18 mois sans SMSI préalable (dont 9-12 mois pour la certification ISO 27001 seule).
  • Galeon — Certification HDS en 2026 (21 avril 2026) : « Les audits représentent généralement plusieurs dizaines de milliers d'euros, auxquels s'ajoutent les coûts internes de préparation et de mise en conformité. »

Je pense que des outils de service d'automatisation de conformité du type Oneleet que j'ai testés, peuvent accélérer le processus de mise en place d'un SMSI pour obtenir une certification ISO 27001.

Le risque sécurité du code vibe codé

Ça me fait un peu peur, honnêtement. Mon ami a vibe codé une application qui contient des données de santé. Et payer les frais importants d'une agence de développeur certifiée HDS n'aurait aucun sens dans ce contexte d'une application amateur sur mesure.

Qu'est-ce que je vais répondre à mon ami ?

D'abord, son idée d'hébergement chez Scaleway va coûter cher ! Déjà 250 € par mois rien que pour le plan de support Business.

Pour éviter cela, une solution serait d'auto-héberger l'application chez soi, dans son bureau, sur un petit serveur. Tant qu'on n'héberge pas pour un tiers, il n'y a pas besoin de certification HDS.

Mais il ne pourra pas demander à un développeur freelance d'administrer ce serveur. Dès qu'un freelance intervient sur l'infrastructure (accès SSH, mises à jour, sauvegardes), il assure l'activité 5 du référentiel HDS — et il devrait être certifié ! Et le coût de la certification pour administrer ce serveur, pour une seule instance, sera bien trop élevé.

Autre solution : embaucher un développeur en CDD pour toute intervention. C'est légalement possible sans HDS, mais c'est lourd à gérer et coûteux.

Réflexion sur le Vibe coding : libération ou prolétarisation ?

En tant qu'artisan développeur, je trouve amusant d'observer plusieurs de mes amis vibe coder des applications sur mesure pour leur besoin.

Pour le moment je n'ai pas cherché à savoir s'ils essaient de comprendre le code produit, ou si le code reste une boîte noire dont ils se fichent tant que ça marche. Mais c'est un phénomène socialement intéressant, et je ne sais pas si c'est une bonne nouvelle ou non.

Si le vibe coding reste un outil d'appropriation, si la personne comprend ce qu'elle fait, peut modifier, adapter, expliquer — alors c'est un acte de déprolétarisation : il reprend le contrôle sur ses outils de travail.
Mais si le code reste opaque, s'il ne s'agit que de produire sans comprendre, alors le vibe coding n'est qu'une nouvelle forme de prolétarisation. Le savoir ne passe plus par la machine au sens de Bernard Stiegler — il passe par l'IA, et la personne reste aussi démunie que devant si l'outil disparaît ou change, c'est de la désindividuation au sens de Bernard Stiegler. La personne n'a pas acquis de savoir, elle a acquis un résultat, elle "consomme".

C'est ce qui fait de ces outils des pharmakons : ils peuvent désindividuer autant qu'ils peuvent aider à s'individuer, selon l'usage qu'on en fait.

J'ai développé cette réflexion dans "J'utilise les LLMs comme des amis experts et jamais comme des écrivains fantômes" et dans "Ma lutte contre mon affaiblissement cognitif". En résumé, j'essaie personnellement d'éviter cette prolétarisation : plutôt que de consommer l'IA pour produire des choses, j'essaie de groker — comprendre en profondeur, pas seulement obtenir un résultat.

traitement des données (RGPD) #rgpd

Au sens du RGPD (article 4, point 2), le traitement est une activité, pas un rôle : un ensemble d'opérations effectuées sur des données à caractère personnel. Concrètement, un employé de l'entreprise qui collecte les coordonnées d'un client au téléphone, qui les saisit dans le logiciel, qui les consulte pour préparer une offre, qui les transmet à un sous-traitant, puis qui les efface à la fin du contrat : chacune de ces actions est une opération de traitement.

Il ne faut pas le confondre avec le responsable du traitement, qui est l'entité déterminant les finalités et les moyens de cette activité. Le traitement, c'est ce qui est fait aux données ; le responsable, c'est celui qui décide pourquoi et comment. Concrètement, dans l'exemple ci-dessus : c'est l'entreprise — une personne morale — qui décide de collecter les coordonnées de ses clients pour préparer des offres. La décision est prise par un directeur ou un salarié habilité, mais le responsable du traitement reste l'entreprise, pas la personne qui la représente. L'employé qui saisit, consulte puis efface les données ne fait qu'exécuter : il agit pour le compte de son employeur. En revanche, le prestataire externe auquel l'entreprise confie les données — un hébergeur, un fournisseur de LLM — est un sous-traitant, qui traite pour le compte du responsable.

Source : Règlement (UE) 2016/679, EUR-Lex. Explications vulgarisées : article 4 (monexpertrgpd) et article 4 (gdpr-text).

Voir aussi : responsable de traitement (RGPD) · RGPD · PII

responsable de traitement (RGPD) #rgpd

Au sens du RGPD (article 4, point 7), le responsable du traitement est la personne physique ou morale, l'autorité publique, le service ou l'organisme qui, seul ou conjointement avec d'autres, détermine les finalités et les moyens d'un traitement.

Contrairement au traitement, le responsable est un rôle, pas une activité : c'est celui qui décide pourquoi et comment les données sont traitées.
Concrètement, c'est l'entreprise — une personne morale — qui décide de collecter les coordonnées de ses clients pour préparer des offres.
La décision est prise par un directeur ou un salarié habilité, mais le responsable du traitement reste l'entreprise, pas la personne qui la représente ; dans une entreprise individuelle, c'est la personne elle-même. Il ne faut pas le confondre avec le traitement lui-même, ni avec le sous-traitant, qui traite les données pour son compte.

Autre cas de figure : dans une prestation industrielle, c'est le client qui décide — il est responsable du traitement ; l'entreprise qui exécute la prestation est sous-traitant ; et le fournisseur de LLM auquel elle confie des données est sous-traitant ultérieur.

Source : Règlement (UE) 2016/679, EUR-Lex. Explications vulgarisées : article 4 (monexpertrgpd) et article 4 (gdpr-text).

Voir aussi : traitement des données (RGPD) · RGPD

RGPD #rgpd

Ressources :

Dernière page.