Conformités
ARCEP vs HDS : divergence ou convergence des exigences de réversibilité ?
A l’heure où l’hébergement dans le cloud est en pleine croissance, deux normes se croisent : la recommandation relative à l’interopérabilité et à la portabilité des services d’informatique en nuage publiée le 25 septembre 2025 et l’exigence 27 présente dans le référentiel de certification Hébergeur de données de santé dans sa dernière et récente version du 16 mai 2024.
L’objectif de l’Arcep est de faciliter le changement de fournisseur cloud et ainsi de renforcer la capacité de choix des utilisateurs tandis que l’objectif du référentiel HDS est d’assurer une restitution des données de santé en fin de contrat de manière sécurisée.
.webp)
Contexte et enjeux de la comparaison entre la recommandation de l’ARCEP et le référentiel HDS
L’ARCEP vient de publier une recommandation relative à l’interopérabilité et à la portabilité des services d’informatique en nuage le 25 septembre 2025. Elle s’inscrit dans le prolongement du règlement européen sur les données (« Data Act ») et de la loi SREN.
Rappelons que ce règlement, applicable depuis le 12 septembre 2025, vise à éliminer les obstacles au bon fonctionnement du marché intérieur des données. Il met notamment à la charge des fournisseurs des services de traitement de données la mise en œuvre de mesures techniques, organisationnelles et contractuelles destinées à faciliter le changement de fournisseur ou l’utilisation simultanée de services de plusieurs fournisseurs.
Certaines mesures issues de ce règlement ont été introduites en droit français par la loi SREN promulguée le 21 mai 2024. Cette loi vise aussi la levée de barrières techniques et tarifaires au changement de fournisseur de services cloud ou à l’utilisation de multi-cloud.
Dans ce contexte, l’Arcep a organisé une consultation publique du 14 octobre au 16 décembre 2024 sur un document exposant sa compréhension des pratiques et outils actuels en matière de portabilité et d’interopérabilité, ainsi que sur les besoins de transparence et d’harmonisation et a par la suite décidé qu’il était pertinent de définir des bonnes pratiques à destination de l’ensemble des fournisseurs de services cloud puisque l’Arcep a constaté que les acteurs concernés vont devoir se mettre en conformité à d’éventuelles règles contraignantes qui pourraient se superposer à d’éventuels actes d’exécution de la Commission européenne.
Ce document pourrait alimenter les réflexions futures de la Commission européenne notamment concernant l’édiction de spécifications communes d’interopérabilité dans le cadre de la mise en œuvre du règlement sur les données.
La recommandation adoptée par l’Arcep le 25 septembre 2025 définit de bonnes pratiques afin de renforcer la transparence sur le degré de portabilité et d’interopérabilité des services d’informatique en nuage et de favoriser la mise à disposition d’API stables et documentées.
Il convient de rappeler la définition de deux notions techniques incontournables afin de comprendre la recommandation de l’Arcep.
Selon l’ouvrage « Le droit du numérique, une approche par les risques » d’Arnaud Latil, « en matière de contrats informatiques, les clauses de réversibilité visent à organiser les modalités de retour des données auprès du client d’un prestataire de services informatiques ».
Pour l’Agence pour la protection des programmes, une clause de réversibilité est une disposition contractuelle qui organise la restitution ou le transfert des données, logiciels ou infrastructure critiques en cas de fin de contrat, de faillite du prestataire ou de tout autre événement mettant fin à la collaboration.
Cette clause garantit au client la possibilité de récupérer ses données ou d’utiliser des outils essentiels à la continuité de ses activités.
En synthèse, la réversibilité permet à une entreprise ou un client de récupérer toutes ses données lors de la cession du contrat avec un prestataire. La réversibilité concerne la restitution des données, elle peut être vue comme une composante de la portabilité qui implique en plus le transfert des données vers le nouveau fournisseur dans un format exploitable et utilisable.
L’Arcep utilise le terme de portabilité dans sa recommandation plutôt que de réversibilité puisque son objectif principal est de faciliter le changement de fournisseur de services cloud. La différence est ténue : le droit à la portabilité tel que défini à l’article 20 du RGPD impliquant un choix pour la personne concernée à récupérer les données personnelles fournies à une plateforme, afin de les conserver pour un usage personnel ou pour les transmettre à un tiers de son choix.
Dans le cadre de la réversibilité des données hébergées, cette opération nécessite souvent le recours à des API pour assurer la gestion efficace de la réversibilité des données. En effet, les API permettent de transférer des données de manière structurée et sécurisée.
Selon Philippe Le Tourneau, dans son ouvrage « Contrats du numérique », une interface de programmation (Programming Interface ou Application Programming Interface – API) « permet à deux programmes ou logiciels d’interagir entre eux, en se connectant pour échanger des données. Une interface de programmation est en principe ouverte et proposée par le propriétaire du programme. Elle permet à un logiciel d’utiliser les services et fonctionnalités d’un autre logiciel ».
La CNIL définit également une API (Application Programming Interface ou « interface de programmation d’application ») comme étant une interface logicielle qui permet de « connecter » un logiciel ou un service à un autre logiciel ou service afin d’échanger des données et des fonctionnalités. Il s’agit donc d’un ensemble de définitions et de protocoles permettant à deux applications ou systèmes informatiques de communiquer entre eux.
Dans l’analyse qui suit, nous mettons en perspective la recommandation de l’Arcep avec le référentiel Hébergeur de données de santé : la recommandation de l’ARCEP rejoint en effet l’objectif du référentiel de certification Hébergeur de données de santé (HDS) s’agissant de la réversibilité pour garantir la restitution des données de santé.
Le référentiel de certification, dans sa dernière et récente version du 16 mai 2024, complète les exigences de l’article R.1111-11 du code de la santé publique en vigueur portant sur ce que doit contenir la clause de réversibilité de tout contrat d’hébergement de données de santé dans un objectif de faciliter le passage d’un hébergeur à un autre.
Ainsi, la réversibilité figure à l’exigence 27 et comporte les conditions suivantes :
« Conformément aux 12° à 14° de l’article R.1111-11 du CSP, une clause relative à la réversibilité doit en présenter les modalités à la fin de la prestation ou en cas d’arrêt anticipé de la prestation quel qu’en soit le motif, avec a minima :
• L’engagement de restitution de la totalité des informations confiées au titre de la prestation ;
• L’engagement de destruction de toute copie de ces informations à l’issue de la restitution ;
• Les modalités de calcul des coûts et délais pour la restitution des copies ;
• Les formats de restitution, lisibles et exploitables à des fins de portabilité des données de santé, et le cas échéant les modalités permettant le déplacement des machines virtuelles/conteneurs. »
Mise en perspective des deux normes
Afin de mettre en perspective le référentiel de certification des hébergeurs de données de santé avec la recommandation de l’Arcep, plusieurs approches sont à réaliser :
La portée normative des normes.
Tout d’abord, ces deux normes n’ont pas la même portée normative. En effet, le référentiel de certification HDS doit être respecté alors que la recommandation de l’Arcep est dépourvue de toute portée normative puisqu’elle met en œuvre des bonnes pratiques à destination de l’ensemble des fournisseurs de service cloud.
Les objectifs recherchés.
De plus, les objectifs poursuivis ne sont pas identiques puisque le référentiel HDS fixe les critères à respecter par le candidat à la certification HDS tandis que la recommandation de l’Arcep vise à faciliter le changement de fournisseur de services cloud, à fluidifier le marché des services cloud et ainsi à renforcer la capacité de choix des utilisateurs.
Le périmètre d’application.
Le référentiel HDS est plus précis dans son périmètre d’application en se focalisant uniquement sur les données de santé à caractère personnel. La recommandation de l’Arcep implique un plus grand nombre d’acteurs puisqu’il a vocation à concerner tous les services cloud en France.
Le format.
Ensuite, il est possible de constater un lien commun entre ces deux normes puisque d’une part, le référentiel HDS prévoit que les données doivent être restituées dans des formats de restitution lisibles et exploitables à des fins de portabilité des données de santé. Toutefois, le cas échéant, les modalités devront permettre le déplacement des machines virtuelles/conteneurs.
D’une autre part, la recommandation de l’Arcep souhaite une publication des informations requises dans un format libre et lisible par un ordinateur. Par exemple, les informations peuvent être présentes sur une page web ou un document PDF et le fichier peut correspondre à un modèle qui figure en annexe.
Les coûts.
Concernant les modalités de calcul des coûts, le référentiel HDS ne prévoit pas d’obligation de gratuité. Quant à elle, l’Arcep préconise d’imposer la non-facturation des frais de migration.
En effet, dans le cadre d’un changement de fournisseur, l’Arcep a transmis au Gouvernement une proposition de montant maximal de tarification pour les frais de transfert de données, ce montant serait fixé à 0€. Les travaux se poursuivent concernant la rédaction des projets de lignes directrices sur les coûts.
Les délais.
Ces deux normes évoquent également la question des délais. Le référentiel HDS n’est pas très précis sur ce point puisqu’il indique seulement que la clause relative à la réversibilité doit présenter les modalités concernant les délais pour la restitution des copies.
La recommandation de l’Arcep ne mentionne pas également de délais par rapport au changement de fournisseur mais précise qu’il serait pertinent que les fournisseurs informent leurs utilisateurs douze mois au minimum avant l’exécution de mises à jour sans rétrocompatibilité de leurs API.
Les exigences de transparence.
Puis, la recommandation de l’Arcep est très précise concernant les exigences de transparence, contrairement au référentiel HDS qui indique uniquement qu’il doit y avoir une formalisation du respect des exigences dans le contrat entre l’hébergeur et son client.
Lors de la consultation publique, les contributeurs ont reconnu qu’une plus grande transparence sur le degré d’interopérabilité et de portabilité des services cloud serait bénéfique.
En outre, les acteurs ont majoritairement reconnu l’intérêt de rendre disponibles des informations comparables permettant aux clients potentiels d’effectuer un choix éclairé de leur fournisseur de service mais une réserve se forme si l’harmonisation est trop stricte concernant le format de diffusion de ces informations.
En effet, cela est susceptible de générer des lourdeurs excessives surtout pour des fournisseurs de petite taille. Ainsi, pour faciliter la comparaison entre les services cloud, l’autorité estime pertinent que ces informations soient accessibles et présentées selon un ordonnancement uniforme.
L’Autorité considère que le contenu du code de conduite SWIPO pourrait être une référence pertinente pour déterminer les informations qui devraient être rendues disponibles aux clients et clients potentiels afin de leur permettre d’exercer leur liberté de choix.
En effet, ce code de conduite est intéressant puisqu’il fournit un ensemble de préconisations en matière de transparence destinées à faciliter la portabilité des données et le changement de fournisseur.
Par conséquent, l’Arcep recommande aux fournisseurs de services cloud de publier les informations en étant assorties de leur index. Les fournisseurs sont donc invités à publier onze catégories d’informations concernant les modalités de migration et d’interopérabilité de leur service, notamment concernant leurs procédures, la migration, les outils de supervision, les formats, la description, etc...
Le procédé.
Enfin, concernant le procédé, il n’y a pas de précisions dans le référentiel de certification HDS. Cependant, il est possible d’avoir recours à la recommandation publiée par l’Arcep qui souhaite une mise à disposition d’API stables et documentées.
L’Arcep estime qu’il serait approprié que les fournisseurs informent leurs utilisateurs douze mois au minimum avant l’exécution de mises à jour sans rétrocompatibilité de leurs API, sauf lorsque les obligations légales applicables ou les exigences du fournisseur en matière de sécurité et de protection de la propriété intellectuelle imposent exceptionnellement une mise à jour rapide, les clients devraient donc être informés le plus rapidement possible, et adoptent la spécification OpenAPI ou des spécifications équivalentes pour la description ou documentation de leurs API.
Il s’agit d’une volonté assumée d’empêcher les fournisseurs de rendre les migrations compliquées de façon volontaire puisqu’ils ne pourront pas modifier leurs API de façon imprévue.
Conclusion
La recommandation publiée par l’Arcep préconise des contraintes fortes concernant la portabilité. Cependant ce n’est qu’une recommandation, qui n’a pas de portée normative.
Aussi, la recommandation de l’ARCEP pourra utilement être prise en compte sur les points non traités par l’article R1111-11 et de l’exigence 27 du référentiel de certification afin d’apporter encore plus de transparence et d’efficacité à la réversibilité sans pour autant que cela soit une obligation pour les hébergeurs de données de santé, comme d’ailleurs pour tous les hébergeurs.
Autres articles qui peuvent vous intéresser
Contrats
6/1/2025
13 min de lecture
Logiciel & révision unilatérale du prix : entre liberté contractuelle et encadrement juridique
À travers cet article, nous souhaitons vous faire part de plusieurs retours d’expérience susceptibles de vous aider à prévenir l’émergence de litiges et, par conséquent, à sécuriser vos relations commerciales.
Nous n’évoquerons pas les relations entre commerçants, régies par le Code de Commerce. Nous nous concentrerons sur une situation particulière, bien que relativement courante, à savoir les relations commerciales entre un éditeur de logiciel et un client professionnel.
Conformités
20/1/2025
12 min de lecture
Règlement EHDS : Espace européen des données de santé
Depuis de nombreuses années, le Conseil Européen appelle les États membres à renforcer la mise en œuvre de leurs stratégies en matière de santé numérique. Dans ce contexte, la Commission européenne a présenté, le 3 mai 2022, une proposition de règlement pour établir l’Espace européen des données de santé (EHDS).
Le projet de règlement a été adopté par les États membres le 22 mars 2024, puis par le Parlement européen le 24 avril 2024. La publication du texte au journal officiel est attendue pour l'automne 2024, et son entrée en application est variable selon les dispositions concernées (entre 2 ans et 10 ans).
Conformités
12/2/2025
8 min de lecture
RGPD vs IA : Les défis de la protection des données personnelles dans la mise en place des SIA
À l'heure où les premières dispositions du règlement sur l'intelligence artificielle entrent en vigueur, la mise en conformité des systèmes d’IA s’impose comme un enjeu incontournable.
L'intelligence artificielle (IA) est définie par le Règlement (UE) 2024/1689 du Parlement européen et du Conseil du 13 juin 2024 comme suit : « Un système conçu pour fonctionner avec des éléments d'autonomie et capable, pour un ensemble donné d'objectifs définis par l'homme, de générer des résultats tels que du contenu, des prédictions, des recommandations ou des décisions influençant les environnements avec lesquels il interagit. » Le règlement distingue entre les systèmes d'intelligence artificielle (SIA) et les modèles d'IA à usage général.
Les SIA sont des applications d'IA conçues pour des tâches ou des domaines spécifiques, comme les systèmes d’aide au diagnostic médical. En revanche, les modèles d'IA à usage général sont des systèmes polyvalents, capables d'être utilisés dans une variété de contextes et pour diverses applications. Par exemple, un modèle de traitement du langage naturel peut être adapté pour réaliser de la traduction automatique.
L'intelligence artificielle soulève des questions complexes, en particulier dans le domaine de la protection des données personnelles. En effet, les systèmes d'intelligence artificielle fonctionnent en utilisant une quantité importante voire massives de données, justifiant l'instauration d'un cadre rigoureux encadrant leur utilisation et leur traitement, en veillant au respect des droits fondamentaux des individus, dont le respect de la vie privée.
Les enjeux sont multiples : comment garantir que les algorithmes ne compromettent pas la confidentialité des individus ? Comment s’assurer que l’analyse de données exercée par les systèmes d’IA reste éthique et conforme aux principes de transparence, d’équité et de responsabilité ?
Pour faire face à ces enjeux, qui ne sont pas les mêmes en phase de conception et en phase de déploiement, les autorités de protection des données, telles que la CNIL en France et le CEPD au niveau européen, doivent constamment réévaluer et ajuster leurs doctrines pour éclairer les acteurs de terrain sur les démarches de conformité à réaliser en intégrant les évolutions technologiques. Nous faisons ici un tour d’horizon des récentes évolutions dece cadre doctrinale et/ou réglementaire relatif à l’IA et au RGPD.
