L’histoire est celle d’une entreprise française engagée dans un litige commercial avec un concurrent local, à l’étranger. Les autorités du pays décident de lancer un audit et l’entreprise, soucieuse d’être irréprochable, accepte de transmettre des données financières ainsi que des informations sur ses procédés de fabrication. 

Résultat : L’entreprise écope malgré tout d’une surtaxe, puis perd la majorité de ses clients au profit du concurrent qui l’avait dénoncée. Entre-temps, elle a livré des informations économiques précieuses qui, elles, ne pourront jamais être reprises.

Ce cas m’a conduite à m’interroger sur une dimension de la conformité dont nous ne parlons pas suffisamment à mon goût. Nous la considérons généralement comme un moyen de réduire les risques, de protéger l’entreprise et d’établir la confiance. 

Mais que se passe-t-il lorsque les outils de la conformité (l’audit, l’inspection, la certification) cessent d'être des garde-fous pour devenir des armes de guerre économique ?

Derrière la procédure, le rapport de force

L’audit nous paraît neutre parce que son vocabulaire l’est. On parle de référentiel, de preuves, d’écarts, de mesures correctives. Tout semble relever d’une méthode objective dont la conclusion découlerait naturellement des faits observés. 

Pourtant, une procédure de contrôle ne se déroule jamais en dehors du contexte politique et économique dans lequel elle a été décidée.

La DGSI le dit sans détour : ces audits, « généralement demandés par les autorités gouvernementales dans le cadre de procédures réglementaires, peuvent également résulter de demandes d'entreprises concurrentes ». 

Ce que je comprends par là : la procédure officielle peut être détournée pour capter du savoir-faire, ralentir un rival, ou le forcer à s'exposer. 

Puisque c’est l’autorité qui audite, qui détermine les informations qu’elle souhaite obtenir, le pouvoir se trouve de l’autre côté et le rapport des forces est déséquilibré. 

Les deux autres exemples rapportés par la DGSI illustrent précisément ce risque : un audit lié à une licence d'exportation fait traîner les délais jusqu'à mettre une usine en rupture d'approvisionnement, et dans l’autre cas, une inspection de conformité débouche sur des exigences de modification suffisamment lourdes pour déstabiliser l’entreprise concernée.

Les informations qu'un audit permet d'obtenir sont considérables : la chaîne logistique complète, le détail des procédés industriels, l'identité des détenteurs du savoir-faire, l'architecture d'un système, parfois l'accès au code source. 

Ainsi, retarder une licence, suspendre une livraison, s’inspirer des procédés, prendre le marché, imposer des modifications coûteuses deviennent une réalité dans le rapport de forces économiques et industriels.

Dans chacune de ces situations, la coopération de l’entreprise ne suffit pas à la protéger. Cela ne signifie évidemment pas qu’il faudrait refuser tout audit ou soupçonner toute certification d’être une manœuvre hostile. Cela signifie simplement qu’un outil technique peut aussi avoir une fonction politique, et qu’il serait imprudent de l’oublier.

Les cas concrets

Sans nous attarder sur les exemples bien connus d'Alstom ou BNP Paribas sur les ingérences étrangères qui vont même au-delà des simples procédures d’audit, il y a un bon nombre de cas concrets à connaître.

L’affaire Micron, en Chine, constitue probablement l’exemple le plus clair de ce glissement.

En mars 2023, l’autorité chinoise du cyberespace ouvre une revue de cybersécurité sur les produits du fabricant américain de mémoires. Deux mois plus tard, elle annonce que ces produits présentent de graves problèmes susceptibles de menacer la chaîne d’approvisionnement des infrastructures critiques du pays. Les opérateurs concernés reçoivent donc l’ordre de ne plus les acheter.

Le régulateur ne publie pas d’éléments techniques suffisamment précis pour permettre d’évaluer la nature des vulnérabilités constatées. 

La décision intervient par ailleurs dans un contexte de fortes tensions autour des semi-conducteurs, alors que les États-Unis ont déjà renforcé leurs restrictions sur l’exportation de technologies avancées vers la Chine. 

Il n’est donc guère surprenant qu’elle ait été largement interprétée comme une mesure de rétorsion, même si le motif officiellement invoqué reste celui de la cybersécurité. Ici, une préoccupation de sécurité réelle sert une stratégie économique plus large : la décision a mis en jeu la moitié du marché chinois de Micron, soit environ 12,5 % de son chiffre d'affaires mondial.

La Chine a déjà suscité des inquiétudes en 2015, quand elle a voulu imposer aux prestataires des services dans le secteur bancaire des règles de contrôle très intrusives qui suggèrent de laisser tout le savoir-faire à la frontière d’entrée. La démarche a été suspendue la même année suite à d’importantes pressions diplomatiques.

Un rapide détour par nos voisins britanniques, nous montre le cas de Huawei. 

À partir de 2010, l’entreprise chinoise se soumet à des contrôles britanniques pendant près d’une décennie. Le GCHQ (Government Communications Headquarters) puis le NCSC (National Cybersecurity Center) examinent les équipements de l’entreprise, son code source et ses pratiques d’ingénierie. En juillet 2020, les services britanniques ne sont pas convaincus et sous la pression américaine, Huawei est retiré du réseau 5G britannique. 

Les outils construits par la France

La France n'est pas démunie, elle possède plusieurs moyens réglementaires défensifs  :

La loi de blocage de 1968, longtemps quasi inappliquée, a été réformée en 2022 (décret n° 2022-207). Elle interdit de transmettre à une autorité étrangère des informations sensibles d'ordre économique, commercial, industriel, financier ou technique touchant aux intérêts essentiels de la France. Depuis avril 2022, un guichet unique, le SISSE (Service de l'information stratégique et de la sécurité économiques, rattaché à la DGE), rend un avis sous un mois pour dire ce qui peut être transmis ou non (sources : economie.gouv.fr, DGE, DGSI).

À ce bouclier judiciaire s'est ajouté un bouclier d'infrastructure. La doctrine cloud au centre, définie par circulaire en 2021 et actualisée en 2023, impose aux administrations d'héberger leurs projets numériques sur les clouds internes de l'État ou sur des offres commerciales qualifiées. 

Pour les données d'une sensibilité particulière, l'offre retenue doit être qualifiée SecNumCloud, ou disposer d'une qualification européenne équivalente, et être immunisée contre tout accès non autorisé par des autorités publiques d'États tiers. 

Cette qualification va au-delà des mesures techniques en couvrant le contrôle juridique de l’entreprise, son personnel, la localisation de ses activités et les législations auxquelles le service peut être soumis.

SecNumCloud constitue en ce sens un outil défensif. Il permet à l’État de définir les conditions dans lesquelles certaines données sensibles peuvent être confiées à un prestataire, au lieu d’accepter que le marché ou des puissances étrangères définissent seuls le niveau de risque que nous devrions tolérer.

La France a ensuite défendu l’introduction de critères comparables dans le projet européen de certification des services cloud, EUCS, notamment pour son niveau le plus élevé.  Ces critères de souveraineté n'ont jamais fait consensus entre États membres. Le schéma reste en attente depuis. 

Plusieurs États membres et organisations représentant des intérêts industriels européens et étrangers se sont opposés à ces critères, qu’ils jugeaient protectionnistes et étrangers à une certification supposée rester purement technique. À l’inverse, plusieurs entreprises européennes ont demandé leur maintien, précisément parce qu’elles considéraient que la sécurité d’un cloud ne pouvait être séparée du droit auquel il est exposé.

Les États-Unis, eux, n'hésitent pas : leur programme FedRAMP conditionne depuis des années l'accès des services cloud au marché fédéral à une certification qu'ils contrôlent.

Ce débat en dit beaucoup de notre difficulté collective. Au moment même où nous cherchions à définir les conditions de confiance applicables à notre propre marché, nous avons hésité à assumer qu’une certification puisse aussi traduire un choix de souveraineté. Pour reprendre l’image de l’arme, nous avons commencé par la limer nous-mêmes. La réalité est que nous n’avons pas su nous doter des garde-fous nécessaires face aux outils de conformité des pays extra-européens. 

Leur fonctionnalité est défensive, ce sont des remparts. Contrairement aux FCPA et OFAC qui sont des instruments de projection : ils vont chercher l'entreprise étrangère chez elle. 

De la conformité subie à la réciprocité

ll y a 2 400 ans, Thucydide met en scène le dialogue de Mélos. Athènes veut soumettre la petite île de Mélos, qui invoque le droit et la justice. La réponse des Athéniens est restée célèbre : « les forts font ce qu'ils peuvent et les faibles subissent ce qu'ils doivent ». 

L’idée est de ne pas dévaloriser l’utilité de la conformité et du droit, ou remettre en question l’ouverture des marchés. Mais de rappeler qu'être en règle ne garantit pas d'être protégé. Le droit ne se défend pas tout seul : il ne protège réellement que si une puissance publique est prête à le faire respecter.

Tant que l’asymétrie des moyens de pression existe, l’acteur le plus agressif gardera son avantage. Si l’accès à un marché étranger suppose de communiquer du code source ou d’ouvrir ses usines, nous devons pouvoir exiger des garanties comparables. 

Il est temps d'adjoindre un principe que l'Union européenne et ses États membres ont commencé à établir depuis peu, mais hésitent encore à assumer pleinement : la réciprocité de leur cadre réglementaire face aux instruments juridiques offensifs des pays tiers.

— Darya KHENDRIK, Compliance Manager chez Clever Cloud - RSMI (Responsable de Système de Management Intégré), DPO

Sources

• DGSI — Audits étrangers, vecteurs de déstabilisation et d’ingérence
• Cyberspace Administration of China — décision Micron du 21 mai 2023
• USITO — suspension des règles bancaires chinoises « secure and controllable »
• NCSC — analyse des sanctions américaines de mai 2020 concernant Huawei
• NCSC — avis sur les fournisseurs à haut risque
• ANSSI — référentiel SecNumCloud 3.2
• ITI — prise de position du 11 avril 2024 sur le retrait des critères de souveraineté d’EUCS
• FedRAMP — conditions d’accès des services cloud au marché fédéral
• EUR-Lex — instrument international sur les marchés publics, règlement 2022/1031
• EUR-Lex — règlement 2022/2560 sur les subventions étrangères
• EUR-Lex — instrument anti-coercition, règlement 2023/2675

Cet article distingue trois choses souvent confondues : ce que la certification garantit, ce qu'elle laisse de côté, et les points à contrôler avant de confier des données de santé à un prestataire.

Certification HDS et conformité HDS : deux notions distinctes

La certification est un statut délivré à l'hébergeur après audit. La conformité, elle, est une obligation qui reste partagée entre l'hébergeur et son client. Confondre les deux conduit à une fausse sécurité : croire qu'externaliser chez un prestataire certifié suffit à couvrir l'ensemble de ses propres obligations.

Ce que porte l'hébergeur certifié

La certification est délivrée par un organisme accrédité, à l'issue d'un audit portant sur les six activités du référentiel HDS. Elle atteste que l'hébergeur maintient un niveau de sécurité défini pour héberger, exploiter et sauvegarder des données de santé à caractère personnel.

Ce qui reste à la charge du client

Utiliser un hébergeur certifié ne rend pas le client lui-même certifié. La certification demeure celle de l'hébergeur ; le client est mis en conformité sur le seul volet hébergement. Ses obligations applicatives et ses obligations au titre du RGPD restent les siennes. À cela s'ajoute une exigence propre au référentiel : l'hébergement de données de santé suppose la signature d'un contrat spécifique entre le client et l'hébergeur, qui formalise la répartition des responsabilités.

Ce que la certification atteste, et ce qu'elle ne couvre pas

Le périmètre des 6 activités : une certification partielle laisse des zones non couvertes

Le référentiel HDS distingue six activités, de la mise à disposition des sites physiques jusqu'à la sauvegarde externalisée, en passant par l'administration et l'exploitation du système d'information. Une offre peut n'être certifiée que sur une partie de ce périmètre, souvent les seules couches d'infrastructure. Dans ce cas, l'administration-exploitation ou la sauvegarde restent hors du champ certifié, et l'écart devient une charge de conformité pour le client. Vérifier l'étendue exacte de la certification, activité par activité, est donc un préalable, pas un détail.

La frontière entre sécurité de l'hébergement et souveraineté juridique

La certification atteste la sécurité technique et organisationnelle de l'hébergement. Elle ne dit rien de la question juridique : qui peut être légalement contraint de communiquer les données. Ce sont deux plans différents. Un hébergeur peut satisfaire aux exigences de sécurité du référentiel tout en restant soumis à une législation extra-européenne. La Cour des comptes le formule sans ambiguïté : à ce stade, le référentiel HDS ne comporte pas les exigences de souveraineté propres à la qualification SecNumCloud, en particulier le contrôle capitalistique et la protection contre les législations extraterritoriales. Un hébergeur certifié HDS n'est donc pas automatiquement immunisé contre ces lois.

Certification HDS et lois extraterritoriales (Cloud Act, FISA)

Ce que la réglementation HDS impose réellement

Le cadre s'est resserré début 2026. Le décret n° 2026-209 du 24 mars 2026, publié au Journal officiel le 26 mars et pris en application de l'article 32 de la loi SREN du 21 mai 2024, inscrit dans le code de la santé publique des obligations jusque-là portées par le seul référentiel de certification. Son nouvel article R. 1111-9-1 pose le principe d'un stockage des données de santé réalisé exclusivement sur le territoire d'un État membre de l'Union européenne ou partie à l'accord sur l'Espace économique européen (EEE). Un transfert vers un pays tiers, y compris sous la forme d'un accès distant, demeure possible, mais aux conditions du RGPD : décision d'adéquation de la Commission européenne ou, à défaut, garanties appropriées.

Le texte renforce également le contrat d'hébergement et l'information due au client. L'hébergeur doit y préciser les consultations à distance depuis des pays tiers, les législations extra-européennes susceptibles d'imposer une communication de données au sens de l'article 48 du RGPD, les mesures d'atténuation et les risques résiduels. Il crée enfin une obligation de transparence jusqu'alors absente : publier et tenir à jour une cartographie des transferts hors EEE, des accès distants et des risques d'accès non autorisé par des États tiers.

Ces dispositions structurantes n'entrent toutefois en vigueur que six mois après la publication, soit fin septembre 2026 ; les autres modifications s'appliquent depuis le lendemain du décret.

Ce que la certification HDS ne traite pas

Le risque extraterritorial lui-même. La réglementation oblige l'hébergeur à informer, pas à immuniser. Un hébergeur peut être certifié HDS, stocker en France, et rester atteignable par une loi extra-européenne lorsque sa maison mère y est soumise. La configuration de Microsoft Ireland l'illustre : l'entité dispose de la certification HDS et stocke en France, mais ne peut obtenir la qualification SecNumCloud du fait de son rattachement à un groupe soumis au droit américain. Stocker sur le territoire national est nécessaire, mais ne suffit pas à écarter l'exposition juridique.

Immunité juridique et souveraineté : deux exigences distinctes

Pour les données les plus sensibles (grandes bases de santé, données de mineurs, données d'infractions), la CNIL recommande de recourir soit à un hébergeur soumis exclusivement au droit européen, soit à un prestataire bénéficiant d'une qualification de type SecNumCloud, qui intègre un critère d'immunité aux lois extra-européennes.

Une nuance mérite d'être posée. La qualification apporte l'immunité juridique, mais elle peut coexister avec une dépendance technologique : certaines offres qualifiées reposent sur des composants américains exploités sous licence. La souveraineté ne se déduit donc pas d'un seul label ; elle tient aussi à la structure capitalistique du prestataire et à l'origine de sa technologie.

Cette recommandation vise les traitements les plus sensibles. Recourir à un hébergeur HDS non souverain reste, en dehors de ces cas, autorisé : la CNIL indique qu'aucune sanction n'a été prononcée au seul motif du recours à un hébergeur non souverain. Le bon réflexe n'est pas de trancher par principe, mais d'évaluer le risque au regard de la sensibilité des données traitées.

Vérifier la conformité réelle d'un hébergeur

Validité du certificat et accréditation

Un certificat expiré, en cours de renouvellement, ou délivré par un organisme non accrédité n'offre pas la garantie attendue. Deux vérifications simples : le certificat est-il en cours de validité, et l'organisme qui l'a délivré est-il accrédité COFRAC pour le référentiel HDS. Le statut d'un hébergeur est par ailleurs consultable au registre officiel des hébergeurs certifiés tenu par l'Agence du numérique en santé.

Localisation du stockage et des opérations

Le stockage en France est nécessaire, mais ne referme pas à lui seul le risque. Un accès distant, pour l'administration ou l'exploitation, depuis un pays tiers rouvre l'exposition même lorsque les données restent stockées sur le territoire. La bonne question à poser au fournisseur porte donc sur les deux plans : où sont stockées les données, et depuis quel pays, par quelles équipes, la plateforme est-elle administrée.

Réversibilité et transparence des transferts

L'absence de réversibilité crée une dépendance technique qui peut empêcher une mise en conformité ultérieure, par exemple une migration imposée vers une solution souveraine. Sur la transparence, la cartographie des transferts hors EEE que la réglementation rend obligatoire constitue un point de contrôle direct : son absence est un signal d'alerte.

Ces points peuvent se contrôler de façon structurée, à l'aide de notre grille des dix points à vérifier sur la souveraineté d'un hébergeur HDS. 

Le positionnement de Clever Cloud

Clever Cloud est certifié HDS sur l'intégralité du périmètre du référentiel. Sur le volet extraterritorial, notre garantie ne repose pas sur une qualification SecNumCloud détenue en propre, mais sur la voie du statut juridique : capital et siège français, aucune filiale aux États-Unis, hébergement et opérations réalisés en France, et engagement de ne transférer aucune donnée de santé hors de l'Espace économique européen. Cette configuration place l'entreprise sous la seule application du droit européen.

FAQ

La certification HDS protège-t-elle du Cloud Act ?

Non. La certification atteste la sécurité de l'hébergement des données de santé. Elle n'a pas pour objet l'immunité face aux lois extraterritoriales. Un hébergeur certifié peut rester soumis à une législation extra-européenne selon sa structure capitalistique.

Un hébergeur certifié HDS peut-il être soumis au droit américain ?

Oui, lorsque sa maison mère relève du droit américain. Une entité peut détenir la certification HDS et stocker en France tout en restant atteignable par le Cloud Act ou le FISA.

Les données de santé doivent-elles obligatoirement être stockées en France ?

Non. Le référentiel HDS et le décret n° 2026-209 du 24 mars 2026 imposent un stockage exclusivement au sein de l'Espace économique européen (l'Union européenne, plus la Norvège, l'Islande et le Liechtenstein) et non sur le seul territoire français. Cette règle est codifiée à l'article R. 1111-9-1 du code de la santé publique. Un accès distant depuis un pays tiers reste possible, mais aux conditions du chapitre V du RGPD (décision d'adéquation ou garanties appropriées), et il doit être porté à la connaissance du client dans le contrat d'hébergement. Un hébergement situé en France relève donc d'un engagement contractuel du prestataire, non d'une obligation réglementaire.

Être hébergé chez un prestataire certifié me rend-il « conforme HDS » ?

Non. La certification reste celle de l'hébergeur. Le client est mis en conformité sur le seul volet hébergement ; ses obligations applicatives et RGPD demeurent, de même que la signature d'un contrat d'hébergement spécifique.

HDS et SecNumCloud : quelle différence ?

La certification HDS est obligatoire pour héberger des données de santé et atteste la sécurité de cet hébergement. La qualification SecNumCloud, délivrée par l'ANSSI, est volontaire et intègre notamment un critère d'immunité aux lois extra-européennes. Le référentiel HDS ne comporte pas, à ce jour, les exigences de souveraineté propres à SecNumCloud.

« Certifié HDS » se lit comme une case à cocher : un hébergeur l'est, ou il ne l'est pas. La réalité est moins binaire. Deux hébergeurs également certifiés peuvent diverger sur trois points qui pèsent lourd dès qu'il s'agit de données de santé : l'étendue réelle de leur certification, leur exposition au droit d'un pays tiers, et la part d'exploitation qu'ils laissent à leur client. Choisir un cloud HDS tient donc moins à la vérification d'un label qu'à trois questions précises, à poser avant de signer.

L'hébergement de données de santé (HDS) est un cadre réglementaire français. Il impose à tout acteur qui héberge, exploite ou sauvegarde des données de santé pour le compte d'un tiers de recourir à un hébergeur certifié HDS. L'obligation découle de l'article L.1111-8 du Code de la santé publique. La certification, délivrée par un organisme accrédité indépendant, atteste qu'un hébergeur satisfait aux exigences du référentiel HDS sur un périmètre donné. C'est ce périmètre, précisément, qui mérite d'être regardé de près.

Ce que la certification HDS couvre

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

Une donnée de santé est toute information qui permet d'identifier une personne et de renseigner sur son état de santé, physique ou mental. Le RGPD (articles 4 et 9) la classe parmi les catégories particulières de données, soumises à une protection renforcée. Cela recouvre les dossiers médicaux, les résultats d'examens, les prescriptions, mais aussi des informations moins évidentes : une allergie renseignée dans un logiciel de cantine scolaire est une donnée de santé.

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

La certification HDS ne recouvre pas un bloc unique. Le référentiel distingue six activités : la mise à disposition et le maintien en conditions opérationnelles et de sécurité des sites physiques, de l'infrastructure matérielle, de l'infrastructure virtuelle, de la plateforme d'hébergement applicative, puis l'administration et l'exploitation du système d'information et la sauvegarde des données de santé. Un hébergeur peut être certifié sur l'ensemble de ces activités, ou sur une partie seulement. Une offre certifiée uniquement sur les couches d'infrastructure laisse l'administration, l'exploitation et la sauvegarde à organiser ailleurs, et donc à contractualiser avec un tiers ou à assumer en interne. Le périmètre exact d'un certificat se vérifie dans l'annuaire des hébergeurs certifiés de l'ANS.

Trois critères pour choisir un cloud HDS

Un hébergeur HDS se juge sur trois axes. Aucun ne suffit seul, et aucun hébergeur n'est le meilleur sur les trois à la fois : c'est l'alignement avec le projet qui décide.

Le périmètre de certification

Sur combien des six activités l'hébergeur est-il certifié ? Une certification partielle reste parfaitement valable, mais la part non couverte, souvent l'administration, l'exploitation ou la sauvegarde, revient alors au client ou à un tiers qu'il faut identifier et piloter. Le certificat le précise, et l'annuaire de l'ANS permet de le recouper.

L'exposition aux lois extraterritoriales

C'est le critère le plus souvent confondu avec le précédent. La certification HDS atteste d'un niveau de sécurité et de conformité ; elle ne dit rien de l'exposition au Cloud Act ou au FISA, ces lois américaines qui autorisent les autorités des États-Unis à demander l'accès aux données détenues par un fournisseur relevant du droit américain, quel que soit le lieu de stockage. Un hébergeur peut donc être certifié HDS, installer ses serveurs en France, et rester soumis à ce droit par son capital ou par sa maison mère. Ce qui tranche, ce n'est pas la localisation des données, mais le régime juridique de l'opérateur.

Le dossier de la Plateforme des données de santé, l'ex-Health Data Hub, l'illustre. Ses données ont été hébergées sur une infrastructure certifiée HDS et installée en France, mais opérée par un acteur soumis au droit américain. Saisi de recours, le Conseil d'État a, le 20 mars 2026 (n° 503159 et 504171), rejeté les demandes d'annulation d'une autorisation encadrée et limitée dans le temps, tout en reconnaissant qu'un accès des autorités américaines à certaines données ne pouvait être exclu. En parallèle, sous les exigences de la loi SREN, l'État a engagé la migration de la plateforme vers un hébergement souverain français. Certification HDS et immunité aux législations extraterritoriales sont deux garanties distinctes, et ce dossier montre qu'elles ne se recouvrent pas.

Le modèle d'exploitation

Une fois l'hébergeur choisi, que reste-t-il à exploiter ? Un hébergeur d'infrastructure (IaaS) fournit les ressources, et le client configure, sécurise et maintient les couches qui tournent au-dessus. Une plateforme managée prend en charge une partie de ces couches : chiffrement, isolation, sauvegardes, supervision, mises à jour. Les deux modèles répondent à des besoins différents. Une équipe qui veut maîtriser sa propre pile technique est à l'aise avec de l'infrastructure ; un éditeur de logiciel de santé qui préfère livrer son application et déléguer l'exploitation pour réduire ce qu'il doit maintenir en conformité trouve son compte dans une plateforme managée. Le choix dépend des compétences internes disponibles et du temps que l'équipe peut réellement consacrer à l'exploitation.

Les périmètres de certification évoluent et se vérifient au cas par cas dans l'annuaire de l'ANS. Ce tableau ne désigne pas un « meilleur » hébergeur dans l'absolu : il montre où chaque modèle est solide, et sur quel critère se joue la décision.

Trois idées reçues sur l'hébergement HDS

« Mon hébergeur est certifié, donc je n'ai plus rien à faire. » Recourir à un hébergeur certifié satisfait bien l'obligation d'hébergement des données de santé, et le contrat HDS en apporte la preuve. Mais cela ne rend pas le client lui-même certifié, et cela ne le décharge pas de ses obligations de responsable de traitement au sens du RGPD : la sécurité de son application, la gestion des accès, l'information des personnes et le respect des durées de conservation restent à sa charge.

« Certifié HDS » veut dire certifié sur tout. C'est la confusion la plus coûteuse, parce qu'elle rend deux offres faussement comparables : la certification peut ne porter que sur une partie des six activités. Deux hébergeurs « certifiés HDS » ne se valent donc pas nécessairement, et l'écart se lit sur leurs certificats respectifs, pas sur leur page d'accueil.

HDS et RGPD, c'est la même chose. Le RGPD est le socle européen de protection des données personnelles. La certification HDS est une exigence française spécifique à l'hébergement des données de santé, qui s'ajoute au RGPD sans s'y substituer. Respecter l'un n'exonère pas de l'autre.

Clever Cloud face à ces trois critères

Appliquée à Clever Cloud, la même grille donne une lecture claire.

Sur le périmètre, Clever Cloud est certifié sur les six activités du référentiel HDS, dans sa version en vigueur, et sur la norme ISO/IEC 27001:2022. La chaîne est couverte de l'infrastructure jusqu'à la sauvegarde. Le certificat, délivré par Bureau Veritas Certification France sous le numéro FR094504, est public et valable jusqu'au 19 décembre 2027.

Sur l'exposition extraterritoriale, la souveraineté tient ici à des faits vérifiables plutôt qu'à une formule : capital et siège français, aucune filiale aux États-Unis, aucun transfert de données de santé hors de l'Espace économique européen. Il n'existe pas d'attache au droit américain, donc pas d'exposition au Cloud Act ni au FISA à retirer.

Sur le modèle d'exploitation, Clever Cloud opère la plateforme de bout en bout. Le chiffrement, l'isolation, les sauvegardes automatiques, la supervision et les mises à jour sont intégrés, ce qui réduit la surface de configuration et d'exploitation côté client. La couverture HDS reste conditionnée à la signature d'un contrat spécifique, exigence légale du référentiel.

Ce modèle se vérifie sur des projets réels. Madietenligne, plateforme dédiée aux diététiciens, exploitait auparavant une infrastructure autogérée, complétée par Azure pour le stockage de ses fichiers. Elle a migré ses environnements de test et de production vers le PaaS de Clever Cloud en moins de quinze jours afin de simplifier leur exploitation et de s’appuyer sur un environnement d’hébergement certifié HDS. Option Zéro, application de santé publique consacrée à la réduction des addictions et portée par l'association CaPASSCité, y est également hébergée. D'après nos mesures internes et les retours de nos clients, une migration vers la plateforme réduit en moyenne la facture d'hébergement de 30 % et raccourcit le time-to-market, jusqu'à un facteur 8.

Choisir un cloud HDS en connaissance de cause

Choisir un hébergeur HDS revient à confronter une offre à trois questions : sur quel périmètre est-elle certifiée, à quel droit est-elle soumise, et que laisse-t-elle à exploiter. La certification est le point d'entrée, pas le point d'arrivée. Le critère qui pèse le plus varie d'un projet à l'autre : la sensibilité des données fait remonter l'exposition juridique, une équipe réduite fait remonter le modèle d'exploitation. Reste à passer chaque hébergeur pressenti au filtre de ces trois critères, et à retenir celui qui correspond au projet plutôt que celui qui coche le plus de cases.

Un projet d'hébergement de données de santé ?

Contactez nos équipes