Hébergement des données de santé: le guide complet 2026
23 juin 2026 · 19 min
Un lundi matin, votre équipe RH reçoit un email banal en apparence. Un salarié y joint un arrêt de travail, détaille une pathologie, mentionne un traitement. Dans la foulée, votre service client transfère ce message dans Outlook, votre agent IA le résume, puis votre CRM enregistre automatiquement le motif d'absence pour “mieux suivre la relation”. Techniquement, tout fonctionne. Juridiquement, vous venez peut-être d'ouvrir un problème sérieux.
C'est exactement comme ça que beaucoup de PME et ETI croisent le sujet de l’hébergement des données de santé. Pas via un dossier patient. Pas via une clinique. Via un workflow métier ordinaire branché sur HubSpot, Salesforce, Pipedrive, Gmail, Outlook, Odoo ou un outil RH. Le point de bascule, ce n'est pas votre secteur d'activité. C'est la présence d'une donnée de santé à caractère personnel dans un flux externalisé.
Le piège, c'est de croire que “ce n'est pas médical, donc ce n'est pas HDS”. Faux réflexe. Dès qu'une information de santé se retrouve stockée, transmise ou exploitée chez un tiers, vous devez regarder l'architecture réelle, pas l'étiquette commerciale du projet. Un agent IA qui trie des emails, enrichit un ticket ou alimente un CRM peut devenir un maillon critique de votre chaîne de conformité.
Si vous explorez déjà l'automatisation des opérations, des ventes ou du support, les retours d'expérience publiés sur le blog IA pour PME et ETI de Revolve montrent une réalité simple. L'IA s'intègre partout. Donc le risque de faire circuler des données sensibles partout augmente aussi.
Vos outils métiers ne deviennent pas conformes parce que votre intention n'est pas médicale.
Table des matières
- Introduction Le Jour où l'IA Rencontre le Secret Médical
- Les 3 Solutions d'Hébergement pour vos Données de Santé
- Choisir le Bon Partenaire HDS au-delà de la Certification
- Le Défi Spécifique des Agents IA face aux Données de Santé
- Plan d'Action pour un Projet IA Conforme et Performant
- Conclusion et Questions Fréquentes
Introduction Le Jour où l'IA Rencontre le Secret Médical
Le vrai sujet n'est pas “faut-il utiliser l'IA ?”. Le vrai sujet, c'est “où passent les données quand vous l'utilisez ?”. Pour une PME, la réponse est souvent embarrassante. Les emails partent dans une messagerie cloud, les pièces jointes finissent dans un dossier partagé, les résumés alimentent un CRM, puis un agent IA ajoute une couche d'automatisation.
À partir du moment où un arrêt maladie, une allergie, une incapacité, un compte-rendu médical ou une mention de traitement circule dans ce flux, vous n'êtes plus sur un simple sujet d'optimisation opérationnelle. Vous êtes sur un sujet de gouvernance, de sous-traitance et d’hébergement des données de santé.
Le RGPD fixe le cadre général
Le RGPD est votre socle. Pensez-le comme le code général de construction. Il impose les principes de base pour toutes les données personnelles. Licéité, minimisation, sécurité, confidentialité, durée de conservation, responsabilité du responsable de traitement.
Pour un dirigeant, ça veut dire une chose très concrète. Vous devez savoir quelles données vous collectez, pourquoi, dans quel outil, avec quel prestataire, et avec quelles garanties.
L'erreur fréquente consiste à limiter la notion de donnée de santé au dossier médical hospitalier. C'est trop étroit. Dans la pratique métier, une donnée de santé peut apparaître dans :
- Un email RH qui mentionne un arrêt de travail ou une pathologie
- Un ticket support où un client explique une allergie ou un handicap
- Un champ CRM renseigné par un commercial après un échange téléphonique
- Une pièce jointe envoyée dans Outlook, Gmail ou un portail documentaire
La certification HDS ajoute une couche non négociable
Là où le RGPD encadre tout le trafic, la certification HDS fonctionne comme une autorisation spécialisée pour l’hébergement externalisé des données de santé. En France, elle est obligatoire pour tout hébergeur externe de données de santé, dans le cadre du décret n°2018‑137. Elle est délivrée pour 3 ans après des audits stricts, sur une base alignée avec des normes comme l'ISO 27001, selon la présentation de l'Inserm sur le SNDS et le cadre HDS. Le même cadre rappelle que le SNDS regroupe les informations de plus de 65 millions de personnes, ce qui donne l'échelle du sujet.
Ce point change tout pour les PME. Si vos données de santé sont hébergées chez un tiers, vous ne pouvez pas traiter ce prestataire comme un simple fournisseur SaaS de plus. Il devient un maillon réglementaire.
Règle simple : si vous externalisez l'hébergement, vérifiez d'abord le cadre HDS. Vérifiez l'outil ensuite.
Deux confusions coûtent cher en pratique :
Confondre sécurité et conformité
Un outil peut être bien sécurisé sans couvrir vos obligations HDS.Confondre usage interne et externalisation
L'hébergement interne ne relève pas de la même logique que l'hébergement chez un sous-traitant externe.Confondre anonymisation théorique et réalité opérationnelle
Tant qu'une donnée reste rattachable à une personne dans votre flux métier, vous devez raisonner comme si le risque était plein et entier.
Les 3 Solutions d'Hébergement pour vos Données de Santé
Vous avez trois routes possibles. Aucune n'est parfaite. En revanche, une d'entre elles est souvent la moins mauvaise pour une PME ou une ETI qui veut avancer sans se piéger.
L'hébergement interne
L'option interne séduit les dirigeants qui veulent garder la main. Serveurs maîtrisés, équipes maison, politique d'accès décidée en interne, intégrations au plus près du SI. Sur le papier, c'est rassurant.
En réalité, c'est un choix lourd. Vous gardez l'autonomie, mais vous gardez aussi la charge de sécurité, de segmentation, de journalisation, d'exploitation, de supervision, de gestion des incidents et de cohérence documentaire. Si votre équipe IT est déjà tendue par Microsoft 365, l'ERP, le réseau, les postes et la cybersécurité, ajouter une brique sensible n'a rien d'anodin.
L'hébergement interne peut rester pertinent si vous avez une maturité forte, un besoin de contrôle exceptionnel, ou des contraintes d'intégration très serrées. Pour beaucoup de PME, ce n'est pas le point de départ le plus réaliste.
Le cloud certifié HDS
C'est aujourd'hui l'option la plus pragmatique dans beaucoup de projets. Vous déléguez à un hébergeur certifié une partie lourde du sujet, à condition de choisir un prestataire dont le périmètre est réellement adapté à votre cas d'usage.
Le cadre HDS impose aux hébergeurs des mesures techniques et organisationnelles strictes. Le chiffrement des données au repos et en transit, le contrôle d'accès selon le moindre privilège, l'authentification forte, la journalisation détaillée, le cloisonnement réseau et la gestion des incidents font partie des exigences décrites dans l'analyse de Sewan sur l'hébergement des données de santé.
Pour une PME, le bénéfice est clair. Vous réduisez votre exposition juridique et vous accélérez votre mise en ordre, à condition de ne pas croire que la certification du fournisseur couvre toute votre architecture. Elle couvre son périmètre. Pas vos erreurs de design.
Le cloud de confiance
Le cloud de confiance répond à une logique de souveraineté et de maîtrise renforcée. Pour certains projets très sensibles, il peut être pertinent. Mais il ne faut pas l'acheter comme un slogan.
Si votre besoin principal consiste à faire transiter des données de santé dans des agents IA, des workflows documentaires et des systèmes métiers variés, le bon choix dépend surtout de la façon dont vous isolez les traitements sensibles. Beaucoup d'entreprises cherchent une réponse absolue dans le label. Elles devraient chercher une réponse opérationnelle dans l'architecture.
Voici une vue simple pour décider.
| Critère | On-Premise (Interne) | Cloud Certifié HDS | Cloud de Confiance (SecNumCloud + HDS) |
|---|---|---|---|
| Contrôle | Très élevé | Élevé sur le périmètre contractuel | Élevé avec focus souveraineté |
| Vitesse de déploiement | Souvent plus lente | Souvent la plus pragmatique | Variable, souvent plus exigeante |
| Charge de conformité pour vos équipes | Très forte | Partagée avec le prestataire | Forte sur la gouvernance et le design |
| Souplesse d'intégration IA | Dépend fortement de vos compétences internes | Bonne si le partenaire maîtrise les architectures modernes | Bonne mais parfois plus rigide |
| Risque de mauvaise interprétation | Sous-estimé en interne | Sous-estimé si on se repose trop sur le certificat | Sous-estimé si on pense que le label règle tout |
Quelques recommandations nettes :
- Évitez l'interne par réflexe de contrôle si votre DSI n'a pas déjà un niveau élevé de discipline sécurité.
- Choisissez le cloud HDS si vous voulez lancer vite sans improviser la conformité.
- Réservez le cloud de confiance aux cas où la souveraineté, la politique de risque ou les exigences client le justifient réellement.
Le bon hébergement des données de santé n'est pas celui qui paraît prestigieux. C'est celui que votre équipe peut gouverner proprement dans la durée.
Choisir le Bon Partenaire HDS au-delà de la Certification
Le marché pousse une illusion confortable. “Nous sommes certifiés HDS, donc vous êtes tranquilles.” Non. Vous êtes tranquilles seulement si le périmètre certifié, le contrat, l'exploitation et l'architecture couvrent votre usage réel.
Le périmètre réel compte plus que le logo
Un hébergeur peut être sérieux et malgré tout être mauvais pour votre projet. Pourquoi ? Parce qu'un projet d'IA ne ressemble pas à un simple archivage, ni à une infrastructure passive. Il implique des flux, des API, des logs, des accès applicatifs, parfois des traitements temporaires, parfois des sous-traitants supplémentaires.
Beaucoup de PME découvrent tardivement que la complexité administrative HDS ralentit le MVP IA, et qu'elles dépendent de prestataires certifiés sans visibilité claire sur les coûts additionnels de mise en conformité. Ce point est bien résumé par l'article de SDV sur les obligations HDS.
Le fournisseur le moins cher est souvent le plus coûteux si vous devez bricoler autour de ses limites.
La checklist de due diligence
Quand vous évaluez un partenaire HDS, posez ces questions sans détour :
Quel périmètre exact est certifié ?
Activités couvertes, environnements concernés, data centres inclus, services exclus.Quels sous-traitants interviennent ?
Cloud, réseau, supervision, support, sauvegarde, exploitation. Vous devez voir la chaîne, pas seulement le premier maillon.Le partenaire sait-il gérer des flux IA ?
Pas une démo marketing. Des cas où des données sensibles passent entre messagerie, API, moteur d'orchestration et outil métier.Comment fonctionne la réversibilité ?
Si vous partez, comment récupérez-vous vos données, vos journaux, vos configurations et vos preuves d'audit ?Que disent les clauses de responsabilité ?
Regardez les exclusions, les limites de responsabilité, les engagements sur l'incident, la coopération en cas de contrôle.Quel niveau de support avez-vous réellement ?
Une conformité théorique sans réactivité opérationnelle ne sert à rien le jour d'un incident.
Si votre prestataire répond bien aux questions techniques mais mal aux questions contractuelles, vous n'avez pas un partenaire. Vous avez un risque documenté.
Mon avis est simple. Pour un projet mêlant IA et données sensibles, choisissez un partenaire qui comprend à la fois l'hébergement, les flux applicatifs et la discipline documentaire. S'il ne parle que d'infrastructure, il vous laissera seul au moment où l'architecture métier deviendra le vrai problème.
Le Défi Spécifique des Agents IA face aux Données de Santé
C'est ici que beaucoup d'entreprises se trompent. Elles pensent que HDS concerne les logiciels médicaux, les hôpitaux ou les dossiers patients. Puis elles déploient un agent IA dans un environnement “non médical” et laissent passer des données de santé dedans.
Le faux confort des outils non médicaux
Prenons un cas très banal. Un prospect écrit à votre équipe commerciale pour demander un aménagement de service lié à un handicap ou à un traitement. L'email arrive dans Outlook ou Gmail, un agent IA le résume, classe l'intention, crée une fiche dans HubSpot ou Salesforce, et envoie une alerte au bon commercial.
Le système final n'est pas médical. Pourtant, la chaîne a manipulé une donnée de santé.
La réglementation HDS reste floue sur les agents IA qui traitent temporairement des données de santé dans des environnements non certifiés, notamment pour des finalités de support ou administratives. L'article L.1111-8 se concentre sur l'hébergement pour des activités de soin, ce qui laisse une incertitude pour les PME qui connectent un environnement HDS à des plateformes SaaS généralistes, comme le rappelle la page de l'ANS sur l'hébergement des données de santé.
Le risque n'est donc pas seulement juridique. Il est architectural. Votre flux peut “contaminer” des outils qui n'ont jamais été pensés pour ce niveau d'exigence.
Une architecture à risque et une architecture défendable
Voici le mauvais schéma :
- Email entrant avec information médicale
- Analyse par un agent IA généraliste
- Envoi du résumé complet dans un CRM non HDS
- Stockage, reporting, partage interne
Voici un schéma plus défendable :
- Email entrant
- Qualification dans une zone de traitement isolée
- Détection de contenu sensible
- Filtrage, pseudonymisation ou séparation du contenu sensible
- Seules les informations strictement nécessaires descendent vers le CRM
Cette logique vaut aussi pour les projets d'automatisation documentaire. Si vous regardez comment certaines entreprises structurent déjà des traitements automatisés, les approches décrites dans cet article sur l'automatisation des factures montrent bien qu'un workflow efficace dépend d'abord du découpage propre des étapes et des données, pas seulement du modèle IA choisi.
Le problème n'est pas l'agent IA. Le problème, c'est l'endroit où il voit la donnée, ce qu'il en fait, et où il la renvoie.
Mon conseil est tranché. Dès qu'un agent peut croiser des données de santé, traitez-le comme un composant sensible. Même si sa mission commerciale ou administrative paraît anodine.
Plan d'Action pour un Projet IA Conforme et Performant
L'erreur classique d'un projet IA en PME ou ETI est simple. L'équipe branche un agent sur les outils existants, le métier valide un premier gain de productivité, puis quelqu'un découvre qu'un arrêt maladie, un compte-rendu médical ou une mention d'inaptitude a circulé dans un environnement mal cadré. À partir de là, le projet ralentit, les arbitrages juridiques arrivent en urgence, et la confiance interne tombe.
Évitez ce scénario. Un projet propre commence par les flux, les données et les responsabilités. Le choix du modèle vient après.
1. Cartographier les flux réels et repérer les points de contact sensibles
Prenez les flux réels, pas la version théorique du schéma PowerPoint. Regardez qui reçoit quoi, dans quel outil, avec quelles pièces jointes, quelles API, quels exports, quels historiques et quels logs. Ouvrez la boîte noire. Gmail, Outlook, SharePoint, CRM, ERP, SIRH, support, automatisations no-code, connecteurs IA.
Le point de vigilance pour les PME et ETI est souvent là. Vous n'êtes pas un établissement de santé, mais vous captez tout de même de la donnée de santé par accident. Un email client avec une pièce jointe médicale. Une note RH sur une incapacité. Un ticket support qui mentionne un traitement. Un champ libre dans le CRM rempli par un commercial. C'est exactement le type de situation qui fait dérailler un projet IA mal préparé.
Classez ensuite chaque étape du flux selon sa fonction réelle :
- stockage
- transit
- lecture par un modèle
- enrichissement
- résumé
- routage
- archivage
- journalisation
Une donnée exposée pendant quelques secondes à un composant mal choisi reste une donnée exposée.
2. Qualifier les données avant le premier sprint
Vous devez décider, noir sur blanc, ce qui relève de la donnée de santé, ce qui peut le devenir selon le contexte, et ce qui peut circuler dans le flux cible sans risque particulier. Sans cette qualification, le POC crée souvent une dette de conformité dès le départ.
Utilisez une grille simple et exploitable :
Certainement sensibles
Arrêts de travail, diagnostics, traitements, comptes-rendus médicaux, mentions nominatives d'incapacité, d'allergie ou de handicap.Potentiellement sensibles
Emails entrants, notes commerciales, commentaires RH, formulaires ouverts, verbatims de support, pièces jointes non structurées.Acceptables dans le flux cible
Données strictement opérationnelles, minimisées, sans information de santé identifiable ni inférence évidente sur l'état d'une personne.
Mon conseil est direct. Faites cette qualification avant d'acheter un outil, avant de connecter un agent, avant de lancer une démo. Si vous voulez cadrer l'exploration correctement, traitez la phase de test comme un exercice de risque et de valeur métier. Ce point est détaillé dans ce guide sur le POC IA pour cadrer un projet avant industrialisation.
3. Concevoir une architecture séparée, pas un bricolage autour du CRM
Votre objectif n'est pas de rendre tout le SI HDS. Votre objectif est de contenir le traitement sensible dans un périmètre maîtrisé, puis de ne laisser sortir que ce qui est utile au métier.
As noted earlier ne suffit pas ici. Il faut une décision d'architecture. Si un agent IA peut lire, résumer, classer ou rediriger un contenu contenant potentiellement des données de santé, placez-le dans une zone isolée, avec des accès limités, une traçabilité exploitable, un cloisonnement réseau sérieux et des règles strictes sur ce qui peut redescendre dans les outils métiers.
Concrètement, imposez ces choix :
Une zone dédiée pour l'ingestion sensible
Les emails, documents et formulaires à risque arrivent d'abord dans un environnement séparé.Une détection précoce du contenu de santé
Le filtrage doit intervenir avant l'envoi vers le CRM, le support ou les outils d'automatisation.Une logique de minimisation
Le métier reçoit la donnée utile à l'action, pas l'intégralité du contenu source.Des droits d'accès serrés
Seules les personnes et les services qui ont une raison opérationnelle claire accèdent à cette zone.Une journalisation exploitable
Vous devez pouvoir reconstituer qui a accédé à quoi, quand, et pour quelle opération.
Le mauvais réflexe consiste à demander au CRM ou à l'outil d'emailing de gérer après coup un problème créé en amont. Le bon réflexe consiste à empêcher la donnée sensible d'y entrer sous sa forme brute.
4. Verrouiller les contrats et préparer l'exploitation
Beaucoup de projets se fragilisent ici. La démonstration fonctionne. L'intégration avance. Puis personne ne sait clairement qui héberge, qui sous-traite, qui supprime, qui notifie en cas d'incident, ni comment récupérer les données en fin de contrat.
Réglez ces points avant la mise en production :
Définir le périmètre exact du service IA
Ce que l'agent lit, ce qu'il produit, ce qu'il conserve, ce qu'il ne doit jamais voir.Lister tous les acteurs impliqués
Éditeur SaaS, intégrateur, hébergeur, sous-traitants techniques, briques d'IA tierces.Exiger des clauses précises
Sous-traitance, notification d'incident, réversibilité, suppression, journalisation, coopération en cas de contrôle.Préparer l'exploitation courante
Runbook, gestion des accès, revue des journaux, procédure d'escalade, contrôle des changements de configuration.Valider la sortie vers les outils métiers
Aucun flux vers le CRM, l'ERP ou le support sans règle de minimisation validée.
Gardez cette ligne directrice. Une IA performante n'a pas besoin de tout voir. Elle doit voir uniquement ce qui est nécessaire pour produire une action utile, dans un cadre techniquement défendable et contractuellement clair.
Conclusion et Questions Fréquentes
Le sujet n'est pas seulement réglementaire. Il est stratégique. Une entreprise qui traite sérieusement l’hébergement des données de santé construit quelque chose de plus précieux qu'une conformité minimale. Elle construit une capacité à automatiser durablement, sans remettre en cause son modèle à chaque nouveau workflow.
Les dirigeants qui avancent bien sur ces sujets prennent une décision simple. Ils arrêtent d'opposer vitesse et conformité. Ils conçoivent l'architecture pour obtenir les deux. Le coût réel vient rarement de la précaution initiale. Il vient des projets lancés trop vite, branchés sur les mauvais outils, puis repris en urgence quand les zones grises apparaissent.
Si vous déployez des agents IA dans des fonctions commerciales, administratives, RH ou support, partez d'un principe ferme. Toute donnée de santé accidentellement captée doit être traitée comme un signal d'architecture, pas comme une exception métier.
FAQ
Les données issues de wearables sont-elles des données de santé ?
Elles peuvent l'être, selon leur nature, leur contexte d'usage et leur rattachement à une personne. Une donnée issue d'une montre connectée n'est pas anodine par défaut dès lors qu'elle révèle un état de santé ou alimente une décision liée à la santé. La bonne approche consiste à qualifier le cas d'usage concrètement, pas à raisonner par catégorie de gadget.
Mon prestataire de paie, qui gère les arrêts maladie, doit-il être HDS ?
S'il y a hébergement externalisé de données de santé à caractère personnel, la question HDS doit être posée sérieusement. Ne vous contentez pas d'un “nous sommes conformes RGPD”. Regardez la nature exacte des données, le rôle du prestataire et le périmètre technique réel du service.
Puis-je utiliser des modèles d'IA américains pour traiter des données de santé hébergées en France ?
Ce n'est pas une question de nationalité du modèle uniquement. C'est une question de flux, d'hébergement, de sous-traitance, d'accès, de journalisation, de garanties contractuelles et d'architecture globale. Si le modèle ou son service fait sortir la donnée sensible d'un cadre adapté, vous créez un risque. Tant que ce point n'est pas traité noir sur blanc, considérez la réponse comme non sécurisée.
Revolve aide les PME et ETI françaises à concevoir des agents IA réellement industrialisables, intégrés à leurs outils métier et déployés rapidement, sans bricolage ni POC qui restent au placard. Si vous devez automatiser des emails, des documents, un CRM ou des opérations tout en cadrant proprement les flux sensibles, demandez un audit sur Revolve.