AgentPublic/cnil huggingface dataset:
175. En second lieu, en ce qui concerne la détermination du montant de l’amende, la formation restreinte rappelle qu’en vertu des dispositions de l’article 20, paragraphe III, de la loi Informatique et Libertés et de l’article 83 du RGPD, la société encourt, au regard des manquements constitués évoqués ci-avant, une sanction financière d’un montant maximum de 20 millions d’euros ou 4% de son chiffre d’affaires mondial total de l'exercice précédent, lequel était de 1,9 milliard d’euros en 2022, le montant le plus élevé étant retenu.
176. Dès lors, au regard de la responsabilité de la société, de ses capacités financières et des critères pertinents de l’article 83, paragraphe 2, du Règlement évoqués ci-avant, la formation restreinte estime qu’une amende de quarante millions d’euros apparaît justifiée.
177. Elle remarque que si ce montant constitue près de 2 % du chiffre d’affaires mondial de la société, il n’en demeure pas moins inférieur au plafond légal de 4 % prévu à l’article 83, paragraphe 5 du RGPD et à l’article 20, paragraphe III, 7°) de la loi Informatique et Libertés.
178. Par ailleurs, la formation restreinte rappelle que le montant de l’amende peut être supérieur au bénéfice généré par le responsable de traitement, dans la mesure où cela serait nécessaire afin d’assurer le caractère dissuasif de la sanction (voir, en ce sens, CE, 1er mars 2021, Société Futura Internationale, n° 437808, pt. 6).
B. Sur la publicité de la décision
179. La société demande à la formation restreinte de ne pas rendre publique sa décision.
180. La formation restreinte considère au contraire que la publicité de la présente décision se justifie au regard de la gravité des manquements en cause, de la portée du traitement et du nombre de personnes concernées. 
181. Elle relève également que cette mesure permettra d’informer les personnes concernées de l’existence du traitement mis en œuvre par la société et du fait que celle-ci a pu traiter leurs données à leur insu, voire en dépit de leur absence de consentement. Cette information leur permettra, le cas échéant, de faire valoir leurs droits Informatique et Libertés auprès de la société. 
182. Enfin, elle estime que cette mesure est proportionnée dès lors que la décision n’identifiera plus nommément la société à l’expiration d’un délai de deux ans à compter de sa publication.
PAR CES MOTIFS
La formation restreinte de la CNIL, après en avoir délibéré, décide de : 
• prononcer une amende administrative à l’encontre de la société X d’un montant de quarante millions d’euros (40 000 000 €) au regard des manquements constitués aux articles 7, 12, 13, 15, 17 et 26 du RGPD ;
• rendre publique, sur le site web de la CNIL et sur le site web de Légifrance, sa délibération, qui ne permettra plus d’identifier nommément la société à l’issue d’une durée de deux ans à compter de sa publication.
Le président
Cette décision est susceptible de faire l’objet d’un recours devant le Conseil d’État dans un délai de deux mois à compter de sa notification.
 Alexandre LINDEN
La Commission nationale de l’informatique et des libertés,
Vu le règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données ;
Vu la directive (UE) 2016/680 du Parlement européen et du Conseil du 27 avril 2016 relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel par les autorités compétentes à des fins de prévention et de détection des infractions pénales, d'enquêtes et de poursuites en la matière ou d'exécution de sanctions pénales, et à la libre circulation de ces données ;
Vu la loi no 78-17 du 6 janvier 1978 modifiée relative à l’informatique, aux fichiers et aux libertés, notamment ses articles 10 et 22-1 ;
Vu le décret no 2019-536 du 29 mai 2019 modifié pris pour l’application de la loi du 6 janvier 1978, notamment ses articles 41, 45-1 et 45-2 ;
Après avoir entendu M. Benjamin TOUZANNE, commissaire du Gouvernement, en ses observations ;
Décide :
Article 1er : Les agents de la direction de la protection des droits et des sanctions de la Commission nationale de l’informatique et des libertés (CNIL) ci-après désignés et ceux nommés en application du premier alinéa de l'article 41 du décret n° 2019-536 du 29 mai 2019 modifié, sont habilités à établir un rapport en application du cinquième alinéa de l’article 22-1 de la loi du 6 janvier 1978 modifiée :
Mme Rose-Marie ABEL ;
Mme Madeleine CAZETTES DE SAINT LEGER ;
Mme Virginie CLAUDE-LOONIS ;
Mme Audrey DANEL ;
Mme Rosine DOLBEC ;
M. Antoine DROIN ;
M. Lionel FERREIRA ;
M. Rodolphe GÉNISSEL ;
Mme Marie GAILLARDON ;
Mme Sarah GUILLOU ;
M. Jérémie KOUZMINE ;
Mme Morgane LE HIR ;
Mme Noémie LICHON ;
Mme Isabelle MANTZ ;
Mme Clothilde MAULIN ;
Mme Oriane MAURICE ;
Mme Nina MCEVOY.
Article 2 : La délibération n° HABS-2023-002 du 11 mai 2023 portant habilitation de certains agents de la Commission nationale de l'informatique et des libertés est abrogée.
Article 3 : Les habilitations mentionnées à l’article 1er sont délivrées pour une durée de cinq ans.
Article 4 : La présente décision sera publiée au Journal officiel de la République française.
La Présidente
Marie-Laure DENIS
>>> Consulter l'Extrait du Journal officiel électronique authentifié PDF - 1,6 Mo
La Commission nationale de l'informatique et des libertés,
Vu le règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données) ;
Vu la loi n° 78-17 du 6 janvier 1978 modifiée relative à l’informatique, aux fichiers et aux libertés, notamment son article 8-I-2°-b ;
Après avoir entendu le rapport M. Claude CASTELLUCCIA, commissaire, et les observations de M. Benjamin TOUZANNE, commissaire du Gouvernement,
Formule les observations suivantes :
1. La Commission nationale de l’informatique et des libertés (la Commission) a observé au cours des dernières années une augmentation soutenue des partages de données à caractère personnel entre organismes, qu’ils soient publics ou privés. Cette tendance, expliquée par l’intérêt croissant dans la réutilisation des données pour diverses finalités, est confirmée par le souhait du législateur de renforcer la possibilité de ces échanges entre administrations mais également entre organismes publics et privés.
2. La Commission souligne que ces partages de données à caractère personnel doivent être accompagnés des mesures techniques adaptées pour garantir un niveau de sécurité dès la conception et maintenu dans le temps en adéquation avec les risques, et que les données partagées doivent être limitées au strict minimum. À cet égard, elle considère que le recours aux interfaces de programmation applicatives, communément appelées API en référence à leur nom anglais application programming interface , peut fournir un cadre technique favorable à ces partages dans de nombreux cas, sous réserve du respect de certains principes.
Article 1er
Périmètre de la recommandation
3. 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.
4. 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.
5. 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].
6. 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.
7. 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.
8. Enfin, le partage peut schématiquement être séquencé afin que chacune de ses étapes principales corresponde à l’organisation proposée.
9. 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.
>>> Voir la figure du Schéma relationnel entre les trois rôles de détenteur de données, de gestionnaire d'API et de réutilisateur dans l'Extrait du Journal officiel électronique authentifié PDF - 1,6 Mo
10. 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.
11. 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.
12. 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.
13. 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.
14. 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.
Article 2
Recommandations générales
Sur les motifs justifiant le recours à une API
15. L’utilisation d’API est à favoriser lorsque :
les données sont fréquemment mises à jour, et/ou les réutilisateurs ont besoin d’y accéder régulièrement ; et/ou
leur stockage par le réutilisateur n’est pas utile (utilisation unique ou traitement en continu sans nécessité d'historique) ; et/ou
le ou les réutilisateurs n'ont pas systématiquement besoin d'accéder à l'intégralité des données mais seulement à un sous-ensemble des données non identifiable à l'avance ; et/ou
les méthodes utilisées pour garantir leur sécurité sont susceptibles d’être mises à jour.
16. Dans tous les cas de la liste précédente, la Commission recommande l’utilisation d’une API pour le partage de données à caractère personnel. Elle le recommande d’autant plus si les données sont partagées à de nombreux réutilisateurs, voire mises à disposition du public. Elle déconseille en principe, dans ces cas, le recours à une plateforme de partage de données ou à un service de communication électronique (tels que définis en annexe I). Dans les autres cas, l’utilisation d’une API peut également être pertinente, mais son opportunité doit être évaluée en comparaison avec les autres techniques de partage de données possibles.
17. En effet, la Commission a observé que le niveau de sécurité apporté par les API est généralement plus élevé que celui relatif à ces autres méthodes, notamment en ce qui concerne la sécurité des communications par messagerie électronique ou encore la gouvernance des données une fois que celles-ci ont été partagées par messagerie électronique ou sur une plateforme de partage, ou que ces modes d’échange nécessitaient la transmission de grandes quantités de données, parfois inutilement.
18. Par conséquent, le partage par le biais d’une API permet une meilleure supervision du partage des données, d’une part en contrôlant les accès, le degré de précision des données transmises et, le cas échéant, les finalités d’utilisation des données et, d’autre part, grâce à la mise en place d’une interface d’échange standardisée entre détenteur, gestionnaire et réutilisateur, en permettant la transmission sécurisée d’informations associées à l’échange de données (durée de conservation, gestion de l’exercice des droits et notamment du droit à la portabilité, etc.).
Sur les risques liés à l’utilisation d’une API
19. En facilitant et en automatisant le partage de données, l’utilisation d’API présente toutefois des risques accrus de détournement de finalité, de perte de confidentialité et de contrôle des données ou encore concernant la transparence vis-à-vis des personnes concernées, qu’il est nécessaire de prendre en compte. Les objectifs suivants devraient être considérés comme prioritaires lors de la mise en œuvre de mesures visant à réduire les risques :
la minimisation des données échangées ;
l’exactitude des données source ;
la traçabilité des accès ;
la gouvernance et le respect des droits ;
la sécurité.
20. Les objectifs précédents sont à considérer dans le contexte du partage de données, selon la vraisemblance et la gravité des risques associés. Les facteurs suivants, que la Commission considère comme particulièrement importants dans le cadre d’un partage de données par voie d’API, devraient être pris en compte :
type d’accès à la base de données : en lecture seule ou en écriture ;
délivrance des autorisations et conditions d’accès aux données : si l’accès est soumis à une autorisation, quelles vérifications sont apportées afin de valider ces demandes ?
niveau de sécurité des techniques d’authentification utilisées ;
nature des organismes impliqués dans le partage (maturité technique, gouvernance européenne ou non, capacités opérationnelles, etc.) ;
autres mesures techniques (physiques ou logiques) et organisationnelles prévues pour améliorer le niveau de sécurité du système ;
état des connaissances sur les techniques utilisées et les risques associés ;
catégories de données accessibles par l’API : certaines données sensibles au sens de l’article 9 du RGPD ou encore des données à caractère hautement personnel (tels que des données bancaires ou des données de géolocalisation) sont plus susceptibles de faire l’objet d’attaques ou d’entraîner des conséquences plus graves ;
degré de précision des données et des requêtes : possibilité d’accéder uniquement à certaines informations ciblées.
21. Cette liste de facteurs devrait être considérée par chacun des acteurs concernés par le partage de données, quel que soit leur rôle. Une documentation recensant les choix faits doit être constituée et conservée. Lorsqu’elles ne relèvent pas d’une obligation légale, les recommandations préconisées dans le reste de ce document seront à considérer au cas par cas, selon le niveau de risque déterminé et selon les moyens techniques susceptibles d’être mis en œuvre par l’organisme.
22. Lorsque le traitement de partage mis en œuvre est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes concernées, cette analyse technique devra être intégrée à une analyse plus large, appelée analyse d’impact relative à la protection des données, conformément aux dispositions de l’article 35 du RGPD et aux lignes directrices en la matière[3].
Sur la coordination fonctionnelle des organismes
23. Bien que la présente recommandation préconise des bonnes pratiques correspondant à chacun des rôles fonctionnels précédemment exposés (détenteur de données, gestionnaire d'API et réutilisateur des données), la mise en place d’une gouvernance efficace entre ces trois types d'acteurs représente un enjeu majeur pour le respect des grands principes informatique et libertés .
24. En particulier, et quelle que soit la répartition des responsabilités résultant des qualifications juridiques des acteurs précédemment évoquée, il est recommandé que les organismes concernés par le traitement se coordonnent sur les modalités de mise en œuvre de la présente recommandation. Cette coordination fonctionnelle devrait être formalisée sous la forme d’une documentation, définissant d'une manière générale les rôles et responsabilités de chaque acteur, et précisant les procédures mises en œuvre dans le cadre de cette recommandation afin de s’assurer de leur prise en compte par chacun des acteurs. Cette documentation, qui n’est pas nécessairement spécifique à chaque partage, devrait toutefois être suffisamment précise et complète pour prévoir et encadrer chaque cas d'usage.
Sur l’information des personnes
25. Les organismes impliqués dans le partage de données devraient se coordonner pour fournir une information claire et complète aux personnes, concernant le traitement de mise à disposition de leurs données à caractère personnel. La Commission recommande que les mesures de traçabilité permises par les API, et en particulier la journalisation des accès et des actions, soient utilisées afin de collecter des informations statistiques concernant l’utilisation des données. Ces informations pourront être agrégées grâce à un procédé automatisé dont la précision devrait être adaptée notamment à la gravité des conséquences pour les personnes que pourraient entraîner une utilisation détournée de l'API ou un accès illégitime aux données. Lorsqu’une tentative d’accès illégitime aux données est particulièrement vraisemblable et qu’elle pourrait entraîner des conséquences particulièrement graves, comme cela est le cas pour certaines API accessibles par FranceConnect, les informations fournies à la personne devraient inclure la liste exhaustive des accès aux données sur la période pertinente, ainsi que leur horodatage afin de permettre à la personne concernée d’identifier un accès illégitime, en complément des autres mesures de sécurité mises en œuvre par le responsable de traitement. Dans le cas général, la Commission souligne que la liste des réutilisateurs devra être portée à la connaissance des personnes concernées, lorsqu’elle est connue. Elle considère également comme une bonne
pratique le fait de rendre publics ou de fournir aux personnes, pour chacune des API et éventuellement selon plusieurs niveaux d’information dont le premier serait compréhensible pour le grand public :