JORF n°0147 du 27 juin 2023

Article 1

Article 1

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Périmètre de la recommandation pour le partage sécurisé de données via API

Résumé Cette recommandation explique comment partager des données personnelles de manière sécurisée via des API, en respectant les lois et en définissant les rôles des personnes impliquées.

Périmètre de la recommandation

La présente recommandation vise à identifier les cas dans lesquels l'utilisation d'une API est préconisée afin de partager de manière sécurisée des données à caractère personnel ou des informations issues de leur anonymisation, et à diffuser certaines bonnes pratiques concernant leur mise en œuvre et leur utilisation. Est ici entendue par « partage de données » la faculté offerte, à certains réutilisateurs identifiés ou bien au public, de récupérer des données détenues par un organisme, ou la faculté des détenteurs de données de transmettre celles-ci à des fins de réutilisation par des tiers, lorsque cela est autorisé ou demandé par la réglementation. La présente recommandation ne présente pas de caractère obligatoire, sauf lorsqu'elle rappelle les exigences découlant du règlement général sur la protection des données (RGPD) et de la loi du 6 janvier 1978 modifiée (ci-après loi « informatique et libertés »). Cependant, le respect de ces recommandations est de nature à contribuer grandement au respect par les acteurs de leurs obligations, en particulier l'obligation de protection des données dès la conception et de protection des données par défaut prévue à l'article 25 du RGPD.
Cette recommandation identifie les acteurs les plus à même de mettre en œuvre les différentes catégories de mesures nécessaires vis-à-vis de leur rôle fonctionnel, sans préjuger de leur qualification juridique. En pratique, cette qualification juridique devra être déterminée pour chaque cas particulier sur la base des critères définis par le RGPD, afin de déterminer les responsabilités et les obligations qui en résultent (voir les précisions fournies plus bas à ce sujet). Les bonnes pratiques retenues par la CNIL sont ainsi ventilées entre les détenteurs de données, les gestionnaires d'API et les réutilisateurs. Une définition de ces trois rôles est proposée en annexe I et les paragraphes suivants détaillent les modalités de leur coordination.
En outre, les mesures précisées ne visent pas l'exhaustivité, mais ciblent les points d'attention techniques les plus importants dans la mise en œuvre d'un partage de données par voie d'API. Certaines règles et bonnes pratiques sectorielles applicables aux partages de données par voie d'API devraient également être prises en compte le cas échéant, telles que le référentiel général de sécurité (RGS) (1) dans le cas d'un partage de données impliquant une administration, ou encore les autres recommandations de la CNIL (2).
La Commission souligne que les capacités techniques liées à chacun de ces trois rôles peuvent grandement varier en pratique. Par ailleurs, plusieurs rôles peuvent être tenus par le même organisme. Cela sera le cas, par exemple, lorsque le détenteur de données développe lui-même une API : il est alors également gestionnaire d'API, et toutes les recommandations visant le détenteur de données et le gestionnaire d'API s'appliqueront alors à cet organisme. A contrario, plusieurs organismes peuvent avoir le même rôle. Cette situation est courante pour le rôle de réutilisateur de données ; toutefois, elle peut également exister pour les autres rôles.
Le rôle de gestionnaire d'API peut être tenu par plusieurs organismes lorsque la gestion et le développement des outils techniques sur lesquels repose le partage sont répartis entre différents intervenants. Il arrive également que seul un des trois rôles existe à un certain stade du traitement. En particulier, lorsqu'un gestionnaire d'API développe un outil technique « sur étagère », c'est à dire dans la perspective de le mettre à disposition d'autres organismes, la présente recommandation devrait être prise en compte bien que ni le détenteur de données, ni les réutilisateurs ne soient encore identifiés.
Enfin, le partage peut schématiquement être séquencé afin que chacune de ses étapes principales corresponde à l'organisation proposée.
L'annexe II présente plusieurs cas d'usages fréquemment observés, dans lesquels les rôles de chacun sont identifiés et expliqués.

Vous pouvez consulter l'intégralité du texte avec ses images à partir de l'extrait du Journal officiel électronique authentifié accessible en bas de page

Figure 1. - Schéma relationnel entre les trois rôles de détenteur de données, de gestionnaire d'API et de réutilisateur

Un détenteur de données est caractérisé par le fait qu'il contrôle des données de manière technique ou organisationnelle. Un gestionnaire d'API est l'organisme en charge d'une partie ou de la totalité des composantes techniques sur lesquelles repose le partage de données. Enfin, le réutilisateur de données est tout organisme envisageant d'accéder ou recevant des données par voie d'API en vue de les exploiter pour son propre compte.
Ces trois rôles permettent de formuler des recommandations à l'intention des acteurs selon leur rôle technique dans le parcours des données, indépendamment de leur qualification juridique au regard du RGPD et des relations contractuelles pouvant exister entre eux, et ont de ce fait été privilégiés par rapport aux rôles habituels de fournisseur et de consommateur d'API (voir annexe I). Toutefois, l'articulation entre ces différents rôles est généralement la suivante :

- Le détenteur de données sera :
- fournisseur d'API, lorsqu'il est également gestionnaire d'API. C'est le cas le plus courant ;
- consommateur d'API, lorsqu'il transmet lui-même les données (ou réalise d'autres actions) via l'API ;
- Le gestionnaire d'API sera :
- fournisseur d'API, dans la majorité des cas ;
- ni fournisseur, ni consommateur lorsque son rôle est lié à la mise en œuvre technique du partage de données mais accessoire au fonctionnement de l'API (c'est le cas d'un site répertoriant l'API pour le compte du détenteur de données, par exemple) ;
- Le réutilisateur sera :
- consommateur d'API, dans la majorité des cas ;
- fournisseur d'API, lorsqu'il est également gestionnaire d'API et reçoit les données des détenteurs par des requêtes en écriture.

Les API présentent une grande variété. La plupart des API ne sont ouvertes qu'à certaines personnes autorisées à accéder aux données (API en accès restreint), tandis que d'autres sont un moyen technique permettant de mettre des données à la disposition du public, et sont accessibles à tous (API ouvertes). Certaines API prévoient des requêtes permettant aux réutilisateurs d'accéder aux données (requêtes en lecture, définies en annexe I), alors que d'autres prévoient des requêtes permettant aux détenteurs de données de partager activement leurs données (requêtes en écriture, également définies en annexe I). Cette recommandation et les trois rôles précédents s'appliquent de façon identique à ces différentes situations.
S'agissant de la qualification juridique des acteurs, il peut être relevé que le détenteur de données sera généralement responsable du traitement de partage, dans la mesure où il aura librement décidé des finalités et des moyens du traitement ou lorsqu'il aura été contraint légalement de le mettre en œuvre ; par voie de conséquence, les recommandations exposées ci-dessous le concerneront pleinement. Il pourra aussi, en cas de détermination conjointe des finalités et moyens du traitement, en être « responsable conjoint » avec un ou plusieurs des autres acteurs, en particulier avec le réutilisateur si celui-ci a, en droit ou en pratique, exercé une influence déterminante sur les objectifs et conditions de mise en œuvre du traitement en cause. Toutefois, la qualification du réutilisateur correspondra souvent, et simplement, à celle de « destinataire » au sens du RGPD, sans préjudice de sa responsabilité à l'égard du traitement qu'il mettra en œuvre pour son propre compte dans la cadre de la réutilisation des données partagées. De son côté, le gestionnaire de l'API agira généralement en tant que sous-traitant, c'est-à-dire pour le compte et sous les instructions du détenteur de données et/ou du réutilisateur. Il n'est toutefois pas exclu que le gestionnaire de l'API mette en œuvre le traitement de partage pour son propre compte, en qualité de responsable de traitement, notamment lorsqu'il agit en tant qu'intermédiaire.
Il ressort de ce qui précède qu'une analyse au cas par cas est indispensable pour définir la qualification juridique des acteurs, et ainsi déterminer sur quel(s) acteur(s), à quel titre et dans quelle mesure, pèse la responsabilité de tenir compte des recommandations, ou obligations le cas échéant, exposées ci-dessous. La présente recommandation formule des « bonnes pratiques fonctionnelles » concernant chacun des trois rôles. Chaque recommandation est attribuée à l'acteur techniquement le plus à même de les mettre en œuvre, sans préjudice de la répartition juridique des responsabilités résultant du RGPD ou d'autres textes réglementaires.


Historique des versions

Version 1

Périmètre de la recommandation

La présente recommandation vise à identifier les cas dans lesquels l'utilisation d'une API est préconisée afin de partager de manière sécurisée des données à caractère personnel ou des informations issues de leur anonymisation, et à diffuser certaines bonnes pratiques concernant leur mise en œuvre et leur utilisation. Est ici entendue par « partage de données » la faculté offerte, à certains réutilisateurs identifiés ou bien au public, de récupérer des données détenues par un organisme, ou la faculté des détenteurs de données de transmettre celles-ci à des fins de réutilisation par des tiers, lorsque cela est autorisé ou demandé par la réglementation. La présente recommandation ne présente pas de caractère obligatoire, sauf lorsqu'elle rappelle les exigences découlant du règlement général sur la protection des données (RGPD) et de la loi du 6 janvier 1978 modifiée (ci-après loi « informatique et libertés »). Cependant, le respect de ces recommandations est de nature à contribuer grandement au respect par les acteurs de leurs obligations, en particulier l'obligation de protection des données dès la conception et de protection des données par défaut prévue à l'article 25 du RGPD.

Cette recommandation identifie les acteurs les plus à même de mettre en œuvre les différentes catégories de mesures nécessaires vis-à-vis de leur rôle fonctionnel, sans préjuger de leur qualification juridique. En pratique, cette qualification juridique devra être déterminée pour chaque cas particulier sur la base des critères définis par le RGPD, afin de déterminer les responsabilités et les obligations qui en résultent (voir les précisions fournies plus bas à ce sujet). Les bonnes pratiques retenues par la CNIL sont ainsi ventilées entre les détenteurs de données, les gestionnaires d'API et les réutilisateurs. Une définition de ces trois rôles est proposée en annexe I et les paragraphes suivants détaillent les modalités de leur coordination.

En outre, les mesures précisées ne visent pas l'exhaustivité, mais ciblent les points d'attention techniques les plus importants dans la mise en œuvre d'un partage de données par voie d'API. Certaines règles et bonnes pratiques sectorielles applicables aux partages de données par voie d'API devraient également être prises en compte le cas échéant, telles que le référentiel général de sécurité (RGS) (1) dans le cas d'un partage de données impliquant une administration, ou encore les autres recommandations de la CNIL (2).

La Commission souligne que les capacités techniques liées à chacun de ces trois rôles peuvent grandement varier en pratique. Par ailleurs, plusieurs rôles peuvent être tenus par le même organisme. Cela sera le cas, par exemple, lorsque le détenteur de données développe lui-même une API : il est alors également gestionnaire d'API, et toutes les recommandations visant le détenteur de données et le gestionnaire d'API s'appliqueront alors à cet organisme. A contrario, plusieurs organismes peuvent avoir le même rôle. Cette situation est courante pour le rôle de réutilisateur de données ; toutefois, elle peut également exister pour les autres rôles.

Le rôle de gestionnaire d'API peut être tenu par plusieurs organismes lorsque la gestion et le développement des outils techniques sur lesquels repose le partage sont répartis entre différents intervenants. Il arrive également que seul un des trois rôles existe à un certain stade du traitement. En particulier, lorsqu'un gestionnaire d'API développe un outil technique « sur étagère », c'est à dire dans la perspective de le mettre à disposition d'autres organismes, la présente recommandation devrait être prise en compte bien que ni le détenteur de données, ni les réutilisateurs ne soient encore identifiés.

Enfin, le partage peut schématiquement être séquencé afin que chacune de ses étapes principales corresponde à l'organisation proposée.

L'annexe II présente plusieurs cas d'usages fréquemment observés, dans lesquels les rôles de chacun sont identifiés et expliqués.

Vous pouvez consulter l'intégralité du texte avec ses images à partir de l'extrait du Journal officiel électronique authentifié accessible en bas de page

Figure 1. - Schéma relationnel entre les trois rôles de détenteur de données, de gestionnaire d'API et de réutilisateur

Un détenteur de données est caractérisé par le fait qu'il contrôle des données de manière technique ou organisationnelle. Un gestionnaire d'API est l'organisme en charge d'une partie ou de la totalité des composantes techniques sur lesquelles repose le partage de données. Enfin, le réutilisateur de données est tout organisme envisageant d'accéder ou recevant des données par voie d'API en vue de les exploiter pour son propre compte.

Ces trois rôles permettent de formuler des recommandations à l'intention des acteurs selon leur rôle technique dans le parcours des données, indépendamment de leur qualification juridique au regard du RGPD et des relations contractuelles pouvant exister entre eux, et ont de ce fait été privilégiés par rapport aux rôles habituels de fournisseur et de consommateur d'API (voir annexe I). Toutefois, l'articulation entre ces différents rôles est généralement la suivante :

- Le détenteur de données sera :

- fournisseur d'API, lorsqu'il est également gestionnaire d'API. C'est le cas le plus courant ;

- consommateur d'API, lorsqu'il transmet lui-même les données (ou réalise d'autres actions) via l'API ;

- Le gestionnaire d'API sera :

- fournisseur d'API, dans la majorité des cas ;

- ni fournisseur, ni consommateur lorsque son rôle est lié à la mise en œuvre technique du partage de données mais accessoire au fonctionnement de l'API (c'est le cas d'un site répertoriant l'API pour le compte du détenteur de données, par exemple) ;

- Le réutilisateur sera :

- consommateur d'API, dans la majorité des cas ;

- fournisseur d'API, lorsqu'il est également gestionnaire d'API et reçoit les données des détenteurs par des requêtes en écriture.

Les API présentent une grande variété. La plupart des API ne sont ouvertes qu'à certaines personnes autorisées à accéder aux données (API en accès restreint), tandis que d'autres sont un moyen technique permettant de mettre des données à la disposition du public, et sont accessibles à tous (API ouvertes). Certaines API prévoient des requêtes permettant aux réutilisateurs d'accéder aux données (requêtes en lecture, définies en annexe I), alors que d'autres prévoient des requêtes permettant aux détenteurs de données de partager activement leurs données (requêtes en écriture, également définies en annexe I). Cette recommandation et les trois rôles précédents s'appliquent de façon identique à ces différentes situations.

S'agissant de la qualification juridique des acteurs, il peut être relevé que le détenteur de données sera généralement responsable du traitement de partage, dans la mesure où il aura librement décidé des finalités et des moyens du traitement ou lorsqu'il aura été contraint légalement de le mettre en œuvre ; par voie de conséquence, les recommandations exposées ci-dessous le concerneront pleinement. Il pourra aussi, en cas de détermination conjointe des finalités et moyens du traitement, en être « responsable conjoint » avec un ou plusieurs des autres acteurs, en particulier avec le réutilisateur si celui-ci a, en droit ou en pratique, exercé une influence déterminante sur les objectifs et conditions de mise en œuvre du traitement en cause. Toutefois, la qualification du réutilisateur correspondra souvent, et simplement, à celle de « destinataire » au sens du RGPD, sans préjudice de sa responsabilité à l'égard du traitement qu'il mettra en œuvre pour son propre compte dans la cadre de la réutilisation des données partagées. De son côté, le gestionnaire de l'API agira généralement en tant que sous-traitant, c'est-à-dire pour le compte et sous les instructions du détenteur de données et/ou du réutilisateur. Il n'est toutefois pas exclu que le gestionnaire de l'API mette en œuvre le traitement de partage pour son propre compte, en qualité de responsable de traitement, notamment lorsqu'il agit en tant qu'intermédiaire.

Il ressort de ce qui précède qu'une analyse au cas par cas est indispensable pour définir la qualification juridique des acteurs, et ainsi déterminer sur quel(s) acteur(s), à quel titre et dans quelle mesure, pèse la responsabilité de tenir compte des recommandations, ou obligations le cas échéant, exposées ci-dessous. La présente recommandation formule des « bonnes pratiques fonctionnelles » concernant chacun des trois rôles. Chaque recommandation est attribuée à l'acteur techniquement le plus à même de les mettre en œuvre, sans préjudice de la répartition juridique des responsabilités résultant du RGPD ou d'autres textes réglementaires.