Plusieurs textes dont la loi SREN, le Data Act et la directive NIS 2 imposent directement de nouvelles obligations aux prestataires SaaS, qui les contraignent à revoir certaines pratiques et leurs modèles de contrats.

Les services d’informatique en nuage (ou « cloud ») se sont imposés comme un outil majeur de la transformation numérique. Ainsi, près de la moitié des entreprises européennes ont acheté des services cloud en 2023, et 95% de ces acheteurs de services cloud ont souscrit au moins à un service SaaS (« Software as a Service »)¹.

Les législateurs français et européens cherchent non seulement à encadrer la sécurité de ces services et des données traitées, mais aussi à limiter les déséquilibres concurrentiels sur le marché du cloud. Des obligations ont ainsi récemment été imposées aux prestataires SaaS par plusieurs textes, qui les contraignent à revoir certaines pratiques et leurs modèles de contrats.

 

Les points clés à retenir

• Le Data Act et la loi SREN structurent les conditions de changement de fournisseur, en encadrant les frais associés et en introduisant des obligations d’interopérabilité et de portabilité des services cloud.
• Les prestataires SaaS doivent assurer une transparence accrue sur la localisation et la protection des données.
• La loi SREN introduit des exigences spécifiques en France, notamment en matière environnementale et de souveraineté.
• La directive NIS 2 durcit les obligations de cybersécurité (gestion des risques, notification d’incidents).
• Les manquements exposent à des sanctions financières significatives, en plus des exigences contractuelles sectorielles (ex. DORA).

 

1. Les obligations et contraintes visant à renforcer la concurrence et la souveraineté des données

Le règlement européen 2023/2854 du 13 décembre 2023 (le Règlement sur les Données ou « Data Act ») et la loi française n° 2024-449 du 21 mai 2024 visant à sécuriser et à réguler l’espace numérique (la « Loi SREN ») imposent de nouvelles règles respectivement aux « fournisseurs de services de traitement de données » et aux « fournisseurs de services d’informatique en nuage ». Curieusement, ces notions sont définies de façon identique, et le Data Act prévoit expressément que cette définition couvre les services SaaS².

À noter que les obligations issues de la loi SREN ne concernent que les prestataires cloud établis en France ou hors de l’UE (pour respecter le principe européen de libre circulation des services)³.

1.1 Les règles visant à favoriser la concurrence sur le marché du cloud

Le Data Act et la loi SREN cherchent notamment à favoriser la concurrence sur le marché cloud, brigué par quelques prestataires dominants (présents sur toutes les couches du marché du cloud, y compris la couche SaaS) et dont les pratiques peuvent rendre leurs clients captifs⁴.

Ces textes encadrent ainsi les frais de changement de fournisseur (y compris en cas de recours simultané à plusieurs prestataires), et notamment les frais de transfert de données. Le Data Act prévoit que les frais de changement de fournisseur ne peuvent dépasser les coûts directement liés au processus de changement jusqu’au 12 janvier 2027, puis interdit complètement ces frais à compter de cette date⁵. Pour sa part, la loi SREN prévoit que, jusqu’au 12 janvier 2027, la facturation de frais de changement de fournisseur devra respecter un montant maximal de tarification fixé par arrêté⁶.

[note de l’APP] L’Arcep a officiellement transmis au Gouvernement sa proposition de fixer le montant maximal à 0 €⁷ pour les frais de transfert de données, anticipant ainsi l’interdiction totale prévue par le Data Act au 12 janvier 2027.

De plus, tant le Data Act (à partir du 12 septembre 2025) que la loi SREN (entre sa promulgation et le 12 janvier 2027) impose des obligations d’interopérabilité et de portabilité des données, en particulier via la mise à disposition par les prestataires cloud d’interfaces dédiées. Il est prévu que des spécifications d’interopérabilité seront publiées respectivement via un acte délégué de la Commission Européenne et par l’Arcep en France⁸.

[note de l’APP] L’Arcep a publié le 25 septembre 2025 une recommandation officielle relative à l’interopérabilité et à la portabilité des services cloud⁹, précisant les modalités d’application de ces obligations pour les prestataires.

Les prestataires cloud doivent en outre fournir à leurs clients, y compris dans leurs contrats et à travers leurs sites Internet, des informations sur les frais de changement de fournisseur¹⁰. Le Data Act impose des obligations d’information complémentaires significatives, et notamment des clauses contractuelles sur le changement de fournisseur et l’interopérabilité¹¹. Des clauses types reprenant ces éléments seront élaborées au niveau européen mais ne seront pas obligatoires¹².

La loi SREN comprend en outre plusieurs interdictions additionnelles, visant également à limiter les déséquilibres concurrentiels¹³. Ainsi, les prestataires cloud ne peuvent établir d’avoirs ayant une durée indéterminée (des durées acceptables seront fixées par décret et ne pourront dans tous les cas dépasser un an) ou assortis d’une condition d’exclusivité. Il est également interdit aux prestataires cloud de subordonner la vente d’un produit ou service à la souscription à un service cloud lorsque cela constitue une pratique commerciale déloyale¹⁴.

1.2 Les règles relatives aux transferts et à la souveraineté des données

Le Data Act et la loi SREN (jusqu’au 12 janvier 2027 pour cette dernière), afin de permettre aux clients de prendre une décision éclairée quant au choix de leurs prestataires, imposent aux prestataires cloud de publier sur leur site internet les juridictions dans lesquelles les données des services cloud pourraient être traitées ainsi qu’une description des mesures prises pour empêcher l’accès par des autorités publiques hors de l’UE à des données personnelles en conflit avec le droit applicable. Un changement contractuel additionnel est requis à cet égard, puisque les prestataires doivent lister les URL concernées dans les contrats avec leurs clients¹⁵.

De plus, la loi SREN incorpore dans la loi française les exigences qui figuraient dans les circulaires relatives à la doctrine « cloud au centre »¹⁶. Elle prévoit ainsi que les administrations et opérateurs de l’Etat, lorsqu’ils utilisent un service cloud qui traite des données d’une sensibilité particulière et dont la violation est susceptible de porter atteinte à certains droits ou intérêts, doivent s’assurer que ce service respecte des critères de sécurité et protection des données notamment pour éviter tout accès par des autorités étrangères¹⁷. Un projet de décret, notifié à la Commission européenne le 24 janvier 2025, impose le recours à un prestataire qualifié par l’Anssi (ou ayant une certification européenne équivalente). Le référentiel de qualification applicable sera très vraisemblablement du référentiel « SecNumCloud » visé dans les circulaires.

1.3 Une spécificité française : la fourniture d’information environnementale

Un autre ajout dans la loi SREN par rapport au Data Act est à noter : les prestataires cloud seront tenus de publier des « informations sur l’empreinte environnementale de leurs services, notamment en matière d’empreinte carbone, de consommation d’eau et de consommation d’énergie ». Les délais et modalités d’application de cette obligation seront précisées par décret¹⁸.

 

2. Le renforcement des obligations de cybersécurité

La directive (UE) 2022/2555 du 14 décembre 2022 (la « directive NIS 2 ») accroît pour sa part les obligations de cybersécurité applicables aux prestataires SaaS par rapport à la directive « NIS 1 »¹⁹.

2.1 Champ d’application

La directive NIS 2 s’applique aux fournisseurs de services d’informatique en nuage (ces services comprenant entre autres « les logiciels services (SaaS) »)²⁰, essentiellement lorsqu’ils constituent des grandes ou des moyennes entreprises au sens du droit européen²¹. Ces entités seront, selon les règles prévues à l’article 3 de la directive, des entités « essentielles » ou « importantes ».

2.2 Obligations des prestataires SaaS au titre de la directive NIS 2

Les obligations des entités soumises à la directive NIS 2 doivent notamment être fixées dans les textes de transposition adoptées par les États membres. Bien que la transposition devait avoir lieu au plus tard le 17 octobre 2024²², l’adoption de la loi de transposition française est toujours attendue²³.

L’état d’avancement de la transposition en droit français

Le projet de loi de transposition a été voté au Sénat en mars 2025 (Rapport Sénat n° 393 (2024-2025) du 4 mars 2025) et a été examiné à l’Assemblée nationale en septembre 2025, avec une adoption attendue début 2026 (Ornisec, « Directive NIS 2 : vers une cybersécurité renforcée en Europe – Point de situation », juin 2025). En mai 2025, la Commission européenne a envoyé un avis motivé à la France pour défaut de notification de la transposition complète (Commission européenne, page de suivi de la transposition NIS 2 pour la France, mise à jour du 7 mai 2025), soulignant le retard pris par rapport à l’échéance du 17 octobre 2024.

Le mécanisme de guichet unique applicable aux fournisseurs de services numériques

La détermination de la loi de transposition applicable sera particulièrement importante pour les fournisseurs de services numériques, y compris les prestataires SaaS, pour lesquels la directive prévoit un mécanisme de « guichet unique ». Contrairement aux autres entités soumises à ce texte, qui peuvent relever de la compétence de plusieurs États membres²⁴, les fournisseurs de services numériques relèvent uniquement de la compétence de l’État membre dans lequel les fournisseurs ont leur établissement principal dans l’Union²⁵. La notion d’établissement principal a une signification particulière dans le cadre de la directive NIS 2, puisqu’elle est définie essentiellement en lien avec les mesures ou opérations en matière de cybersécurité²⁶.

L’obligation d’enregistrement auprès de l’autorité compétente

Les prestataires de services numériques seront notamment soumis à une obligation de déclaration auprès de l’État membre dans lequel se situe leur établissement principal. Bien que la directive prévoie que la première déclaration devait être effectuée au plus tard le 17 janvier 2025²⁷, les délais et modalités de déclaration seront en pratique fixées par les lois de transposition²⁸.

Les obligations européennes directement applicables : gestion des risques

Certaines obligations applicables aux prestataires SaaS sont pour leur part fixées au niveau européen (et non au niveau des lois de transposition). Ainsi, les mesures de gestion des risques en matière de cybersécurité devant être mises en œuvre par les fournisseurs de services numériques²⁹ sont définies dans le règlement d’exécution (UE) 2024/2690, qui est directement applicable dans tous les États membres de l’Union européenne depuis le 6 novembre 2024.

D’autres obligations devront être étudiées tant au niveau des textes européens que des lois de transposition : les prestataires cloud sont soumis à l’obligation de notification des incidents importants auprès de l’autorité compétente et le cas échéant des destinataires des services prévue à l’article 23 de la directive NIS 2 (telle qu’elle sera transposée par les États membres), étant précisé que le règlement d’exécution susmentionné définit les cas dans lesquels un incident relatif à un service cloud est considéré comme important.

 

Un nouvel environnement normatif structurant pour les prestataires SaaS

Les prestataires SaaS doivent mettre en œuvre les modifications techniques et contractuelles requises pour éviter des sanctions significatives (par exemple jusqu’à 3% du chiffre d’affaires mondial pour certains manquements à la loi SREN, jusqu’à 10 millions d’euros d’amende ou 2% du chiffre d’affaires mondial en cas de manquements des entités essentielles à certaines dispositions de NIS 2, etc.). Ces contraintes leur étant directement applicables sont bien sûr sans préjudice des obligations pouvant leur être imposées contractuellement par leurs clients en vertu de nouvelles règlementations sectorielles les concernant (par exemple Dora³⁰).

 

Notes

[1] Eurostat, « Cloud computing – statistics on the use by enterprises ». ︎

[2] Considérant 81 du Data Act. ︎

[3] Article 35 de la loi SREN. ︎

[4] Étude d’impact de la loi SREN. ︎

[5] Article 29 du Data Act. ︎

[6] Article 27 de la loi SREN. ︎

[7] Décision n° 2025-0340 du 20 février 2025 de l’Arcep. ︎

[8] Articles 30, 34 et 35 du Data Act, articles 28 et 29 de la loi SREN. ︎

[9] Recommandation de l’Arcep du 25 septembre 2025 relative à l’interopérabilité et à la portabilité des services d’informatique en nuage. ︎

[10] Article 27 de la loi SREN, articles 25, 29.4 et 29.6 du Data Act. ︎

[11] Articles 25 et 26 du Data Act. ︎

[12] Article 41 du Data Act ; voir aussi la FAQ de la Commission sur le Data Act. ︎

[13] Basées sur l’avis de l’Autorité de la concurrence du 29 juin 2023 dédié au marché cloud. ︎

[14] Nouvel article L. 442-12 du Code de commerce, créé par l’article 26 de la loi SREN. ︎

[15] Article 28 du Data Act et article 33 I de la loi SREN. ︎

[16] Circulaire n° 6282-SG du 5 juillet 2021 et circulaire n° 6404/SG du 31 mai 2023. ︎

[17] Article 31 de la loi SREN. ︎

[18] Article 33 II de la loi SREN. ︎

[19] Les règles prévues pour les « fournisseurs de services numériques » par le Règlement d’exécution 2018/151 étaient en particulier moins développées. ︎

[20] Annexe I section 8 et considérant 33. ︎

[21] Article 2.1 de la directive, qui fait référence à la recommandation 2003/361/CE du 3 mai 2003. Voir notamment les dispositions de la recommandation, ainsi que le considérant 16 de la directive, sur les entreprises partenaires et liées à prendre en compte pour le calcul des seuils. A noter également les articles 2.2 b) à f) ou 2.3 sur les autres entités pouvant être soumises à NIS 2. ︎

[22] Article 41. ︎

[23] La France n’est pas le seul pays concerné, par exemple le projet de loi de transposition n° 8364 étant également toujours en suspens au Luxembourg. ︎

[24] Article 26.1 et considérant 113. ︎

[25] Article 26.1 b). Voir également les règles pour les prestataires étrangers à l’article 26.3. ︎

[26] Article 26.2 et considérant 114. ︎

[27] Article 27.2. ︎

[28] Par exemple, la loi de transposition belge du 26 avril 2024 prévoyait une date limite d’enregistrement au 18 décembre 2024. ︎

[29] Article 21. ︎

[30] A noter toutefois que pour certains prestataires TIC critiques Dora leur sera applicable directement. ︎

Le SBOM (Software Bill of Materials) s’impose comme un outil de référence pour comprendre ce qui compose réellement un logiciel livré, déployé et maintenu. Là où l’on raisonnait historiquement en “produit” (une application, un service SaaS, un composant embarqué), l’industrialisation du développement a déplacé l’attention vers l’assemblage : dépendances open source, bibliothèques tierces, services externes, images conteneurisées, paquets système et dépendances transitives.

Concrètement, cela signifie qu’un logiciel est exposé non seulement à travers ce que l’on développe soi-même, mais aussi à travers tout ce que l’on y ajoute. Le SBOM donne une visibilité structurée sur cet assemblage, au service de trois objectifs : cybersécurité, conformité, maîtrise des actifs immatériels. Les textes européens récents n’imposent pas toujours “le SBOM” en tant que tel, mais renforcent les exigences de traçabilité et de gestion des risques qui en font un outil de premier plan.

 

Les points clés à retenir sur le SBOM

• Le SBOM est un inventaire structuré des composants intégrés dans un logiciel.
• Il facilite l’identification des vulnérabilités (ex. CVE) et la priorisation des correctifs.
• Il soutient la gestion des risques liés à la chaîne d’approvisionnement, notamment au regard de NIS 2.
• Il contribue à la documentation technique et à la gestion des vulnérabilités attendues par le Cyber Resilience Act.
• Il sécurise les enjeux de licences open source, de due diligence et d’engagements contractuels.
• Sa valeur augmente lorsqu’il est intégré à une stratégie de preuve (dépôt, horodatage) et, le cas échéant, de continuité (entiercement).

 

Le SBOM : définition, périmètre et enjeux techniques

Le SBOM s’inscrit dans une logique de transparence et de maîtrise de la chaîne d’approvisionnement logicielle. Pour en comprendre la portée, il convient d’en préciser la définition, les standards applicables et les implications techniques concrètes.

Définition opérationnelle du SBOM

Un SBOM peut être défini comme un enregistrement formalisé des composants utilisés pour construire un logiciel et des relations de dépendance associées. Cette définition est notamment consacrée dans les travaux américains liés à l’Executive Order 14028 et dans la doctrine de référence portée par NIST et NTIA.

Concrètement, un SBOM liste des éléments identifiables : nom du paquet, éditeur/projet, version, empreintes, licences déclarées, identifiants standards et parfois informations de provenance. Il peut couvrir plusieurs couches : dépendances applicatives (ex. npm, Maven, PyPI), dépendances système (paquets OS), et composants de déploiement (images, conteneurs). Ce degré de précision ne relève pas d’un simple formalisme documentaire : elle conditionne la capacité à répondre à une alerte de sécurité, à documenter une conformité, ou à démontrer une maîtrise de sa chaîne logicielle.

Formats et standards : SPDX, CycloneDX, et ce qu’ils changent

Le SBOM n’est pas un fichier “maison” : l’intérêt est précisément de s’appuyer sur des standards interprétables par des outils et par des tiers. Les formats les plus fréquents sont SPDX et CycloneDX, auxquels s’ajoutent des variantes ou profils selon les secteurs et les outils d’analyse.

Un choix de format n’est pas neutre. Il conditionne :

• Le niveau de détail sur les dépendances transitives,
• La capacité à exprimer des métadonnées de sécurité (hash, provenance),
• L’interopérabilité avec les outils de scan de vulnérabilités,
• La facilité d’échange avec un client, un auditeur ou une autorité.

Dans une logique de gouvernance, l’enjeu consiste moins à “produire un SBOM” qu’à produire un SBOM exploitable, cohérent avec le cycle de vie du logiciel et intégrable dans les processus de sécurité et de conformité.

Ce que le SBOM révèle vraiment : dépendances transitives, héritage et dette technique

La valeur d’un SBOM tient largement à sa capacité à exposer les dépendances transitives : composants intégrés indirectement, parfois inconnus des équipes produit, mais présents dans l’artefact livré. C’est souvent à ce niveau que se nichent les risques : versions obsolètes, bibliothèques non maintenues, modules qui tirent eux-mêmes des dépendances vulnérables.

Le SBOM permet également d’objectiver une dette de dépendances : accumulation de versions anciennes, multiplication de bibliothèques redondantes, ou dépendance forte à un composant unique. Pour une direction technique, cela nourrit une trajectoire de maintenance. Pour une direction juridique ou conformité, cela permet d’identifier les dépendances associées à des licences à obligations de réciprocité, ou de vérifier que les obligations de notices sont respectées. Le SBOM devient ainsi un point d’entrée commun entre RSSI, CTO, DSI, juristes et acheteurs.

 

SBOM et exigences réglementaires européennes : vers une obligation indirecte

Il est utile de clarifier un point : le droit de l’Union ne dit pas toujours “vous devez produire un SBOM”. En revanche, plusieurs textes structurants imposent des obligations de gestion des risques, de maîtrise de la chaîne d’approvisionnement, de documentation et de traitement des vulnérabilités. Dans ce cadre, le SBOM s’insère comme un mécanisme de preuve et d’exécution des politiques internes.

Cette approche est cohérente avec la logique européenne : fixer des objectifs et des exigences (gérer le risque, réduire l’exposition, tracer les composants, traiter les vulnérabilités), tout en laissant les organisations choisir les outils et démarches pour y parvenir. Le SBOM n’est donc pas une case à cocher ; il s’analyse comme un instrument de gouvernance aligné sur des obligations déjà présentes, dont l’intensité varie selon le secteur, le produit et le niveau de risque.

Directive NIS 2 : gestion des risques et chaîne d’approvisionnement

La directive NIS 2 (directive (UE) 2022/2555) renforce les mesures de gestion des risques de cybersécurité attendues des entités concernées. Elle vise notamment la gestion des risques liés à la chaîne d’approvisionnement et la sécurisation des systèmes au travers d’une approche par les risques.

Dans une organisation soumise à NIS 2 (directement ou via exigences contractuelles), la question devient : comment démontrer que l’on connaît ses composants, que l’on sait repérer une exposition, et que l’on sait remédier ?

Le SBOM apporte une réponse méthodologique :

• cartographie,
• corrélation avec les vulnérabilités,
• priorisation,
• traçabilité de la remédiation.

Les guides de mise en œuvre et l’écosystème de conformité autour de NIS 2 soulignent l’importance de mesures opérationnelles et vérifiables, ce que permet un SBOM maintenu dans le temps.

Cyber Resilience Act : documentation technique et gestion des vulnérabilités

Le Cyber Resilience Act (règlement (UE) 2024/2847) établit des exigences de cybersécurité pour les produits comportant des éléments numériques, avec une attention particulière portée à la sécurité dès la conception et à la gestion des vulnérabilités sur la durée de support.

Dans cette logique, le SBOM constitue un support naturel de documentation : il décrit les composants intégrés et facilite l’analyse d’exposition lorsqu’une vulnérabilité est divulguée. Il contribue également à la gestion des mises à jour et à la transparence attendue par les utilisateurs et les clients professionnels, notamment lorsque des périodes de support et des correctifs doivent être organisés et documentés. L’enjeu n’est pas seulement technique : c’est une question de responsabilité produit, de capacité à gérer les alertes et à démontrer que l’on maîtrise son assemblage logiciel.

DORA : supervision des prestataires TIC et auditabilité

Le règlement DORA (règlement (UE) 2022/2554) organise la résilience opérationnelle numérique du secteur financier, notamment au travers d’exigences encadrant la relation avec les prestataires TIC et les dispositions contractuelles.

Même si DORA ne prescrit pas explicitement “un SBOM”, la dynamique de conformité pousse à renforcer la visibilité sur les dépendances et sur les composants qui soutiennent des fonctions sensibles. Pour un prestataire TIC travaillant avec des entités financières, fournir un SBOM (ou un équivalent structuré) devient un signal de maturité : capacité à documenter l’architecture logicielle, à qualifier des dépendances, à accélérer une analyse en cas d’incident, et à soutenir des démarches d’auditabilité. Dans les négociations contractuelles, cette transparence peut être déterminante pour démontrer l’alignement opérationnel entre engagements de sécurité et réalité technique.

 

SBOM et propriété intellectuelle : un outil de maîtrise des actifs logiciels

Au-delà de la cybersécurité, le SBOM constitue un outil de pilotage des droits et actifs logiciels : il distingue les développements internes des composants tiers et open source, et permet d’identifier les obligations juridiques associées (licences, redistribution, documentation).

Gouverner les licences open source : de la conformité à la sécurisation contractuelle

L’intégration de composants open source est devenue une norme. Le risque ne réside pas dans l’open source en soi, mais dans l’absence de gouvernance : méconnaissance des licences, dépendances introduites sans validation, obligations de notices non respectées, ou incompatibilités entre licences et modèle de distribution.

Le SBOM permet d’identifier et d’agréger les informations de licence par composant. Il soutient une politique interne : validation des dépendances, règles d’acceptation (ex. interdiction de certaines licences dans certains produits), gestion des obligations de redistribution, et documentation destinée aux clients. Dans le cadre d’appels d’offres ou de contrats B2B, la capacité à produire un SBOM et une synthèse de conformité open source permet également de limiter les frictions : la discussion ne porte plus sur des déclarations générales, mais sur une cartographie vérifiable.

Due diligence technologique : de l’inventaire à l’évaluation du risque

Lors d’une due diligence (acquisition, partenariat structurant, levée de fonds, transfert d’actifs), le SBOM apporte un niveau d’objectivation rarement atteint par une simple revue documentaire. Il aide à répondre à des questions centrales :

• dépendance à quelques briques tierces,
• présence de composants non maintenus,
• exposition potentielle à des vulnérabilités connues,
• alignement des licences avec la stratégie de commercialisation.

Il permet aussi de mieux qualifier la valeur d’un actif logiciel : un produit dont la chaîne de dépendances est maîtrisée, mise à jour, et documentée est plus facile à maintenir, à intégrer et à auditer. À l’inverse, l’absence de visibilité sur les composants introduit une incertitude technique et juridique qui se traduit souvent en renégociations, garanties renforcées, ou mécanismes d’ajustement de prix.

Dans le cadre de ces audits, certains acteurs spécialisés en due diligence technologique, comme notre partenaire Vaultinum, proposent des dispositifs permettant de générer un SBOM, accompagné d’un rapport explicatif au format PDF destiné aux parties prenantes non techniques (direction générale, investisseurs, juristes, conseils).

SBOM, preuve et titularité : articuler traçabilité technique et stratégie probatoire

Le SBOM distingue ce qui relève des composants internes et ce qui relève de composants externes. Cette distinction est utile pour piloter la titularité, la réutilisation et la stratégie de protection. Toutefois, le SBOM ne remplace pas une stratégie probatoire : il décrit, mais ne confère pas une preuve d’antériorité ou de paternité sur les développements internes.

Dans une logique de protection des actifs numériques, il est pertinent d’articuler SBOM et dispositifs probatoires : dépôt et horodatage de versions significatives, dépôts de documentation technique associée, et conservation des éléments permettant de démontrer une chronologie de développement. C’est typiquement dans ce type d’articulation qu’un tiers de confiance, comme l’Agence pour la Protection des Programmes, intervient : sécuriser la preuve des actifs logiciels (code source, documentation, versions) et soutenir la gouvernance interne lors d’un audit, d’un contentieux ou d’une négociation.

 

Contrats, achats, et exigences clients : le SBOM comme clause de transparence

À mesure que les exigences de cybersécurité et de conformité s’intensifient dans les entreprises, le SBOM tend à quitter la seule sphère technique pour devenir un objet contractuel.

Le SBOM comme exigence client dans les contrats B2B

Côté clients, le SBOM peut être demandé pour : vérifier l’absence de composants interdits, qualifier les risques liés à la software supply chain, ou organiser des procédures de notification en cas de vulnérabilité affectant un composant intégré.

Dans certains secteurs très surveillés et soumis à une réglementation contraignante (finance, santé, défense, infrastructures critiques), le SBOM permet d’objectiver la composition logicielle du produit livré et d’encadrer les obligations de transparence.

Encadrer clairement l’usage du SBOM dans le contrat

Côté fournisseurs, le SBOM doit faire l’objet d’un encadrement précis : déterminer quels livrables sont concernés, à quelle fréquence il est mis à jour, quel périmètre il couvre (produit, module, image conteneurisée) et dans quelles conditions il peut être utilisé ou communiqué (confidentialité, non-divulgation, responsabilité).

Sans cet encadrement, le SBOM peut être perçu à tort comme une garantie d’absence de vulnérabilités. Or, il s’agit d’un inventaire destiné à faciliter la gestion des risques, non d’une assurance contre ceux-ci.

 

SBOM et offre APP : un inventaire technique et un rapport explicatif

Au-delà de la production d’un inventaire technique, la valeur du SBOM réside dans sa capacité à être compris, exploité et intégré dans une stratégie de gouvernance des actifs logiciels. C’est précisément sur ce point que se distingue l’approche de l’APP.

Une génération de SBOM intégrée aux dépôts

L’Agence pour la Protection des Programmes propose désormais, en option dans le cadre de ses dépôts (standards, vérifiés et contrôlés), une prestation de génération de SBOM.

Cette offre permet aux éditeurs de logiciels et à leurs clients d’obtenir :

• un fichier SBOM au format JSON, conforme aux standards du marché ;
• un rapport complémentaire au format PDF pour rendre le livrable exploitable et compréhensible pour tous.

Le SBOM ainsi généré s’inscrit dans une logique de sécurisation et de réassurance : il accompagne le dépôt horodaté du code source et contribue à renforcer la valorisation de l’actif logiciel.

Un rapport PDF explicatif à destination des parties prenantes non techniques

La principale valeur ajoutée de l’offre APP réside dans la production d’un rapport explicatif au format PDF, conçu pour être lisible par des interlocuteurs non techniques (direction générale, investisseurs, juristes, partenaires commerciaux).

Contrairement à certaines solutions concurrentes, parfois gratuites mais compréhensibles uniquement par les équipes IT, l’APP fournit un document synthétique présentant :

• Les composants logiciels utilisés,
• Les licences associées,
• Les CVE (failles de vulnérabilité).

Ce document permet au client d’obtenir une vision claire et sécurisée de la composition de son code, et peut servir à faire valoir la qualité de l’actif auprès de tiers clients ou partenaires.

Modalités pratiques et transmission sécurisée

Les deux livrables — SBOM en JSON et rapport explicatif en PDF — peuvent être transmis par voie électronique. Leur poids, après compression, demeure inférieur à 1 Mo, ce qui facilite leur envoi sécurisé par courriel dans le cadre d’un audit, d’une négociation contractuelle ou d’une opération stratégique.

L’offre SBOM s’inscrit en complément des dispositifs historiques de l’APP :

• dépôt probatoire horodaté des versions de code et de documentation ;
• entiercement logiciel, notamment en contexte B2B ou SaaS, pour organiser la continuité d’activité si le fournisseur n’est plus en mesure d’assurer la maintenance ou l’accès, en cohérence avec les engagements contractuels.

Le SBOM ne constitue pas en soi un mécanisme probatoire. Il complète un dispositif global de protection, de traçabilité et de valorisation des actifs logiciels.

Pour toute information complémentaire sur l’option SBOM intégrée aux dépôts vérifiés et contrôlés, contactez les équipes de l’APP afin d’étudier votre situation et vos besoins spécifiques.

La bonne gestion des demandes d’exercice du droit d’accès aux données personnelles constitue une obligation essentielle pour toute entité soumise au RGPD et à la loi Informatique et Libertés. Ces entités, qu’elles soient publiques et privées et quelle que soit leur taille (entreprise, ministère, administration, association, etc.) doivent répondre efficacement et dans les délais aux demandes des personnes concernées par le traitement de leurs données à caractère personnel.

Face à l’augmentation des contrôles de la CNIL et des contentieux judiciaires sur ce sujet, il est crucial de comprendre les spécificités du droit d’accès, d’anticiper les difficultés pratiques et de mettre en place des procédures adaptées pour répondre aux demandes dans le respect de la réglementation.

Pourtant, certains aspects de la réglementation soulèvent dans la pratique de nombreuses questions pratiques et juridiques, tant sur le périmètre des informations à communiquer que sur les modalités de réponse et les limites à respecter. Cette FAQ vise à accompagner concrètement les professionnels dans la gestion conforme et sécurisée de ces droits, pour vous aider à sécuriser les pratiques et à limiter l’exposition au risque de sanction.

 

Périmètre du DSAR

1. En cas de demande d’accès aux emails, que doit-on communiquer ?

La question se pose souvent car en principe, le droit d’accès porte sur les données et non sur un document. Or, la Cour de cassation a pu préciser que le contenu du courriel est considéré comme une donnée personnelle dès lors qu’il permet d’identifier, directement ou indirectement, un individu (Cass. Soc., 18 juin 2025, n° 23-19.022, P). Il peut donc être important de le communiquer.

Dans le cas d’une demande exercée par un collaborateur, il peut être nécessaire de communiquer les courriels dans lesquels il est mentionné, mais dont il n’est ni l’émetteur ni le destinataire.  Le travail de collecte peut être fastidieux et l’employeur doit trouver un équilibre entre satisfaire le droit d’accès du salarié et respecter les droits et libertés des autres salariés, notamment le secret des correspondances. Pour cela, la CNIL recommande de procéder en deux temps :

1. S’assurer que les moyens à mettre en œuvre pour identifier les courriels demandés n’entraînent pas d’atteinte disproportionnée aux droits des salariés de l’organisme. Lorsque l’identification des courriels suppose la mise en œuvre de moyens particulièrement intrusifs (ex. scan de l’ensemble des messageries des salariés), le demandeur est invité à préciser sa demande. Si ce dernier s’y oppose, l’employeur devra répondre au droit d’accès pour les données contenues dans des courriels ne nécessitant pas de tels moyens intrusifs.

Si le demandeur précise sa demande et que cela permet d’identifier les courriels demandés sans atteinte disproportionnée au secret de la correspondance, il faut procéder à la deuxième étape.

2. Étudier le contenu des courriels et l’éventuelle atteinte aux droits des tiers du fait de leur communication, au regard du secret de la correspondance et de la vie privée de l’émetteur et des destinataires. L’analyse est menée au cas par cas, selon la nature des informations (ex. enquête disciplinaire, etc.).

La jurisprudence récente tend à durcir les obligations incombant à l’employeur, ce dernier ne pouvant rejeter en bloc une demande sans justifier des motifs de son refus, sans analyser les demandes au cas par cas. De son côté, les tribunaux opèrent un contrôle de proportionnalité sur le terrain du droit de la preuve et peuvent enjoindre les entreprises à communiquer une partie des documents nécessaire au litige en occultant les éléments sensibles.

 

2. Le droit d’accès porte-il également sur les métadonnées associées aux données à caractère personnel ?

La CNIL considère que, lorsqu’une personne concernée souhaite exercer son droit d’accès à des courriels, le responsable du traitement doit fournir tant les métadonnées (horodatage, destinataires, etc.) que les données personnelles contenues dans les courriels.

Dans cette hypothèse, le plus aisé est d’envoyer une copie des courriels. L’envoi d’un tableau contenant les métadonnées et les données personnelles contenues dans les différents courriels est également une solution.

 

3. Lorsqu’un salarié de plus de 20 ans d’ancienneté au sein d’une société demande une copie de ses emails, cela représente plusieurs millions de documents. Traiter sa demande est techniquement irréalisable… Comment faire ?

Si la demande est trop large ou imprécise, notamment lorsque le responsable du traitement traite une grande quantité de données sur la personne concernée, il peut être demandé des précisions afin d’y répondre efficacement. Il est alors recommandé demander à la personne de préciser sur quelles données ou quelles opérations de traitement sa demande porte.

Ainsi, dans le cas d’un salarié qui dispose d’une longue ancienneté, il est possible de demander de préciser la période, les mots-clés, ou les types de documents dont la copie est sollicitée.

La demande doit coïncider avec la durée de conservation des données, à savoir tant les durées de conservation qui résulterait d’obligations légales, que celles mises en place par la société. En effet, le responsable du traitement n’est pas tenu de fournir des courriels ou documents qui ne sont plus conservés conformément à sa politique de conservation ou aux obligations légales applicables. Il est donc recommandé d’informer le salarié de la période de conservation des courriels et de préciser que seuls les documents encore disponibles dans les systèmes de l’entreprise pourront être communiqués.

 

4.Hormis les emails, doit on communiquer tous les documents que nous détenons sur la personne, notamment les documents dans lesquels on peut retrouver les données personnelles de la personne (contrat de travail, notes internes, etc.) ?

Oui, tous les documents contenant des données personnelles concernant la personne doivent être communiqués, y compris son contrat de travail et les éventuels avenants, des notes internes le concernant, ses évaluations, ses emails, etc. dans le respect des limitations exposées par le RGPD. À ce titre, il convient de veiller à ne pas porter atteinte aux droits et libertés des tiers, tels que le secret des affaires, la vie privée d’autres salariés, ou un droit de propriété intellectuelle (par exemple le droit d’auteur, lorsqu’il protège le logiciel) et de respecter les exceptions légales applicables (demande est infondée ou excessive).

Avant toute communication, il est recommandé d’analyser chaque document pour occulter, si nécessaire, les informations susceptibles de porter atteinte aux droits d’autrui.

 

 

La qualité de l’information

5. Peut-on, en réponse à une demande d’information sur les données personnelles, se limiter à préciser la finalité principale et orienter la personne vers la politique de confidentialité pour le reste ?

Le RGPD pose un principe selon lequel plusieurs catégories d’informations sur les modalités de traitement des données personnelles sont à fournir à la personne concernée qui en fait la demande, notamment les finalités du traitement, les catégories de données concernées, les destinataires, la durée de conservation, les droits de la personne, outre le droit de réclamation auprès d’une autorité de contrôle, la source des données (si elles n’ont pas été collectées auprès de la personne concernée), et l’existence d’une prise de décision automatisée le cas échéant.

Il est possible de renvoyer à la politique de confidentialité pour fournir ces informations, à condition que celle-ci soit suffisamment détaillée et couvre l’ensemble des éléments requis. Si la politique de confidentialité n’est pas assez précise ou exhaustive, il convient de compléter la réponse pour garantir la conformité. Le Comité européen de la protection des données (CEPD) recommande d’adapter le contenu et le niveau de détail de la réponse en fonction de la demande formulée par la personne concernée.

 

6. Si le destinataire des données personnelles est un ou plusieurs sous-traitants, faut-il donner le nom et coordonnées de tous ces prestataires ?

L’article 15 du RGPD relatif au droit d’accès de la personne concernée prévoit que cette dernière doit être informée sur « les destinataires ou catégories de destinataires auxquels les données ont été ou seront communiquées ». Le RGPD n’exige pas expressément que les noms et coordonnées de tous les sous-traitants soient communiqués à la personne concernée par le traitement de ses données. Toutefois, le guide européen en la matière prévoit que, en application du principe d’équité, il convient de fournir les informations « les plus significatives sur les destinataires », ce qui comprend de « désigner nommément les destinataires afin que les personnes puissent savoir exactement qui détient leurs données personnelles » (G29, Lignes directrices sur la transparence au sens du règlement (UE) 2016/679, 2018).

Si le responsable du traitement choisit de se borner à communiquer les catégories de destinataires, les informations fournies doivent être les plus spécifiques possible sur le type de destinataire, notamment les activités de traitement concernées, le secteur et sous-secteur du destinataire, ainsi que son emplacement.

Si le destinataire est situé dans un pays tiers à l’Union européenne, il faut également informer la personne sur le pays tiers concerné, les garanties pertinentes prises pour garantir la protection des données personnelles, telle qu’une décision d’adéquation, ainsi que les moyens d’obtenir une copie de ces informations ou de connaître l’endroit où elles ont été mises à disposition.

 

 

Délai de réponse

7. Dans quels cas le délai d’un mois peut être augmenté jusqu’à 2 mois ?

Une demande doit être traitée « dans les meilleurs délais et, en tout état de cause, dans un délai d’un mois à compter de la réception de la demande ». Ce délai peut être prolongé de deux mois au maximum compte tenu de la complexité et du nombre de demandes, à condition que la personne concernée ait été informée des raisons de ce retard dans un délai d’un mois à compter de la réception de la demande.

Cette dérogation ne doit pas être utilisée de manière excessive.  Il faut apprécier au cas par cas les demandes susceptibles d’être considéré comme complexes. Les facteurs pertinents sont notamment la quantité de données traitées par l’organisme, la manière dont elles sont stockées (par exemple des données difficiles à récupérer, car traitées par différentes unités de l’organisme), la nécessité d’occulter des informations (par exemple des informations concernant des tiers ou qui constituent des secrets d’affaires), ou encore lorsque des travaux supplémentaires sont nécessaires pour rendre les informations intelligibles.

Le simple fait qu’une demande nécessite un effort important de traitement ne la rend pas « complexe » au sens du RGPD. De même, le fait qu’une grande entreprise reçoive un grand nombre de demandes ne justifie pas automatiquement une prolongation. Toutefois, si un grand nombre de demandes sont soudainement reçues (par exemple société visée par un « bad buzz »), cela peut constituer une raison légitime de prolonger le délai.

 

Vérification d’identité de la personne

8. A réception de demandes d’accès par email, nous demandons souvent une pièce d’identité pour confirmer l’identité, en précisant la raison pour laquelle ce justificatif est demandé. Généralement notre mail reste sans réponse. Que faire dans ce cas ?

En cas de doute raisonnable et sans justificatif d’identité, il n’est pas recommandé de répondre à la demande. En effet, communiquer des données personnelles à un tiers non autorisé risquerait de causer une violation de données personnelles susceptible d’engager la responsabilité de l’organisme.

Dès lors, sans réponse à la demande de justificatif d’identité, et sous réserve qu’un tel justificatif soit requis pour traiter la demande, cette dernière peut être considérée comme non recevable et le traitement suspendu. Il est recommandé de conserver la preuve de la demande de justificatif restée sans retour.

 

9. Pour un mineur, la demande de droit d’accès doit-elle être faite par les deux parents ou un seul suffit ?

Un seul parent titulaire de l’autorité parentale peut exercer le droit d’accès au nom du mineur. Il n’est pas nécessaire que les deux parents participent à la demande.

Cela étant dit, la CNIL considère que les mineurs peuvent exercer directement leurs droits sur leurs données personnelles lorsque cette démarche peut être regardée comme un « acte courant », notamment si elle correspond à l’intérêt supérieur de l’enfant. En ce sens, la CNIL estime que les mineurs doivent pouvoir exercer directement les droits relatifs à leurs données personnelles sur les réseaux sociaux, les plateformes de jeux et de partage de vidéos.

 

Modalités de réponse

10. En réponse à une demande d’accès, quels formats et moyens sont autorisés pour une transmission sécurisée des données ? Peut-on utiliser un canal de communication différent de celui employé par le demandeur ?

Dans la mesure du possible, le responsable du traitement doit permettre un accès à distance aux données personnelles idéalement via une fonctionnalité de téléchargement dans un format électronique courant et lisible (fichier PDF, XLX, etc.). Le format choisi doit garantir l’intelligibilité et l’accessibilité des informations.

En l’absence d’accès autonome, la transmission peut être électronique (avec des mesures de sécurité appropriées telles que cryptage ou mot de passe) ou non (par exemple un courrier recommandé, remis contre signature). L’envoi d’une clé USB par courrier recommandée est également possible.

Il est recommandé de répondre par le même canal de communication que celui utilisé par la personne mais l’utilisation d’un autre canal n’est pas contraire au RGPD.  Enfin, il est conseillé de confirmer par écrit la réception de la demande et d’indiquer le délai de traitement.

 

 

Traçabilité

11. Combien de temps doit-on garder copie des demandes traitées, notamment pour démontrer la conformité en cas de contrôle de la CNIL ?

La Loi Informatiques et Libertés et le RGPD ne prévoient pas de durée de conservation à cette fin. Pour ménager la capacité à démontrer le respect du RGPD, il est recommandé de conserver une trace de la gestion des demandes d’accès pendant une durée de cinq ans suivant la date de la réponse ou le dernier événement suivant celle-ci, le cas échéant.

 

 

Limites au DSAR

12. Quelles sont les limites du droit d’accès ? Quels sont les scénarios les plus courants ?

Les principales limites au droit d’accès tiennent à la possibilité de refuser de répondre aux demandes manifestement abusives ou excessive (demandes trop nombreuses, répétitives à des intervalles rapprochés, ou systématiques). Néanmoins, le responsable du traitement doit motiver sa décision et informer le demandeur des recours possibles.

Attention, le fait que la demande ne soit pas motivée (absence de justification) ne permet nullement de refuser d’y répondre.

Ainsi, une demande de droit d’accès formulée par un ancien salarié ayant engagé un contentieux prud’homal et qui porte sur la communication des motifs de son licenciement disciplinaire ne peut pas, en soi, être considéré comme abusif ou sans objet. À cet égard, la CNIL considère que les valeurs de classement annuel ou de potentiel de carrière sont communicables lorsqu’elles ont servi à prendre une décision concernant le salarié. L’employeur n’est pas tenu de les communiquer lorsqu’elles sont encore prévisionnelles, au jour de la demande.

Par ailleurs, le droit d’accès ne doit pas porter atteinte aux droits des tiers (secret des affaires, propriété intellectuelle, droits des tiers au respect de leur vie privée, sécurité publique, etc.). Par exemple, un salarié ne peut pas accéder aux données d’un autre salarié lorsqu’il existe un risque qu’une telle communication porte atteinte à sa vie privée ou au secret de ses correspondances.

Enfin, si aucune donnée n’est détenue sur la personne, le responsable doit tout de même répondre dans un délai d’un mois pour en informer le demandeur.

 

 

Risque de sanction

13. Concernant les contrôles CNIL, avez-vous des références de sanction du non-respect à une demande d’accès ?

La CNIL contrôle l’effectivité du respect du droit d’accès et rend régulièrement des décisions de sanction à ce sujet. En 2025, la CNIL a rendu publiques cinq décisions comportant des sanctions prononcées pour ce motif à l’encontre d’organismes de divers secteurs (e-commerce, immobilier, bancaire, santé, etc.). L’une des amendes prononcées notamment manquement pour non-respect du droit d’accès, s’élève à 150 millions d’euros (Délibération SAN-2025-005 du 1 septembre 2025).

 

A propos des auteures

Elisabeth Marrache et Gabrielle Pierre-Lenfant sont avocates au barreau de Paris et respectivement associée et collaboratrice du cabinet Addleshaw Goddard. Elles possèdent une expertise en propriété intellectuelle, nouvelles technologies et données personnelles.

Au cœur de la stratégie européenne cyber, la Directive dite NIS 2 s’inscrit dans une volonté du législateur de fixer des normes et des standards permettant d’assurer un niveau de cybersécurité élevé, uniforme et renforcé, au sein de l’Union européenne, pour un plus grand nombre d’acteurs et leur chaîne d’approvisionnement. 

 

Points clés à retenir de cet article : 

• La transposition de NIS 2 en droit national accuse des retards dans plusieurs États, dont la France. 

• La France a choisi d’intégrer trois directives européennes, NIS 2, « REC » (sur la résilience des entités critiques) et « DORA » (Directive qui accompagne le Règlement DORA, sur la résilience numérique des entités financières), dans un projet de loi plus large sur la résilience des infrastructures critiques et la cybersécurité. 

• Les éditeurs de logiciels ont été intégrés dans le champ d’application de NIS 2. 

• Les États membres doivent définir une stratégie nationale de cybersécurité imposant aux entités concernées une approche par les risques incluant la sécurité des systèmes, la détection et remédiation des incidents ainsi que la gestion des risques liés à la chaîne d’approvisionnement. 

• La sensibilisation et la formation, notamment des dirigeants, deviennent obligatoires. 

• Le non-respect de la directive NIS 2 expose les entités à de lourdes sanctions financières pouvant aller jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial. 

• Les entreprises doivent agir dès maintenant : évaluer leurs besoins, mettre en place de bonnes pratiques, et intégrer la gestion du risque cyber dans leur stratégie. 

 

Les apports de NIS et sa mise en œuvre 

La Directive européenne dite NIS 2 a été adoptée le 14 décembre 2022 et, comme toute directive, doit être transposée en droit national, par chaque Etat membre de l’Union européenne (UE), la date-butoir pour la transposition en droit national ayant été fixée au 17 octobre 2024. Or, un an après, nombreux sont les Etats membres qui n’ont pas encore adopté leur cadre national transposant la Directive NIS 2. C’est le cas de la France, mais aussi de l’Allemagne, de l’Espagne et de quelques autres.  

 La France a fait le choix d’élaborer un projet de loi visant à transposer trois directives européennes : NIS 2, « REC » (sur la résilience des entités critiques) et « DORA » (Directive qui accompagne le Règlement DORA, sur la résilience numérique des entités financières). Ce projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité a été voté par le Sénat le 12 mars 2025. Amendé et adopté, le 10 septembre 2025, par la Commission spéciale en charge de l’examen de ce texte à l’Assemblée nationale (1), il doit à présent être examiné et voté en séance publique à l’Assemblée nationale.  

 Parmi les amendements adoptés par la Commission spéciale, il apparaît utile de mentionner l’intégration des éditeurs de logiciels dans le champ d’application de NIS 2 (article 8 : « Sont des entités essentielles : […] 6°) Les fournisseurs de services de système de noms de domaine et les éditeurs de logiciels ; […] »).(2)

 Il est également à noter que le 17 octobre 2024, la Commission européenne a publié un règlement d’exécution relatif aux entités et réseaux critiques (3), qui vient préciser certaines exigences techniques et méthodologiques prévues par la Directive NIS 2. Ce règlement d’exécution porte notamment sur les mesures de gestion du risque de cybersécurité et les cas dans lesquels un incident doit être considéré comme significatif et devant être signalé aux autorités nationales.  

 La Directive NIS 2 abroge la directive NIS (Network and Information Security) de 2016, qui avait défini un régime européen de la cybersécurité. Elle élargit considérablement son champ d’application en y intégrant une variété de nouveaux secteurs d’activités, incluant notamment les télécommunications, les plateformes de réseaux sociaux, la gestion des eaux usées, le spatial, ou encore les administrations et collectivités. 

 NIS 2 poursuit un triple objectif : accroitre le niveau de cyber-résilience d’acteurs tous secteurs d’activités confondus ; réduire les incohérences au sein de l’Union européenne pour les secteurs d’activités déjà couverts à date par la directive NIS ; et favoriser le partage de l’information et des connaissances, ainsi que la capacité collective de préparation et de réponse aux attaques. 

 NIS 2 distingue les entités définies comme « essentielles » (opérateurs des noms de domaines, fournisseurs cloud, administrations publiques, organismes de gestion des eaux usées…), et celles qualifiées d’« importantes » (moteurs de recherche, réseaux sociaux, services postaux…), la première catégorie étant soumise à des obligations renforcées. 

Les États membres doivent adopter une stratégie nationale afin d’atteindre et de maintenir un niveau élevé de sécurité dans les secteurs et activités couverts par NIS 2. Ils doivent notamment s’assurer que les entités concernées mettent en œuvre les mesures assurant la sécurité de leurs réseaux et systèmes d’information, ainsi que leur environnement physique (en cohérence avec la directive dite « REC »), selon une approche par les risques appliquée à la cybersécurité. 

 Cette démarche doit nécessairement inclure la détection et la remédiation des incidents et vulnérabilités ; et la prise en compte des risques associés à la chaîne d’approvisionnement (sous-traitants, fournisseurs).

 

Une nécessaire sensibilisation et formation des équipes aux enjeux de cybersécurité 

Quels que soient leur taille et leur secteur d’activité, les entités, publiques et privées, entreprises ont conscience des risques majeurs que représentent les cyber-attaques, vols de données, rançongiciels, etc. : risques financiers bien sûr, mais aussi risques en termes d’image et de réputation, vis-à-vis de leurs clients et de leurs prestataires. 

Face à une menace cyber systémique, les entreprises doivent se protéger et former leurs équipes. La formation des collaborateurs à la cybersécurité est en effet cruciale dans la prévention des risques (en sensibilisant les collaborateurs aux menaces, cyberattaques) et en cas d’incident de sécurité, pour réagir et y remédier efficacement. 

A cet égard, l’article 20 de la directive NIS 2 impose une formation spécialisée en cybersécurité pour les organes de direction. Cette formation est cruciale pour que les membres de la Direction puissent prendre des décisions éclairées d’investissement et superviser efficacement les stratégies de cybersécurité. Il est également prévu que les entreprises adoptent des mesures de sécurité comprenant des formations permettant aux collaborateurs de comprendre et d’évaluer les risques de cybersécurité ainsi que leurs impacts sur l’organisation (cartographie des risques). 

 De plus, en cas de non-respect des dispositions de la directive NIS 2, les sanctions peuvent atteindre des montants élevés (jusqu’à 7 millions d’euros ou 2% du CA mondial, pour les entités importantes et 10 millions d’euros ou 1,4% du CA mondial pour les entités essentielles ; le montant le plus élevé étant retenu). 

 Les entités ne doivent donc pas attendre la transposition de la Directive NIS 2 en droit national, et peuvent d’ores et déjà recenser leurs besoins d’investissement, adopter les bonnes pratiques et se former. Ces nouvelles dispositions s’inscrivent pleinement dans une démarche de gestion des risques, primordiale pour les entités ainsi que pour l’ensemble des organismes tiers appartenant à la chaîne d’approvisionnement. Cette gestion du risque cyber doit également permettre d’intégrer les innovations, notamment liées à l’intelligence artificielle (IA) ainsi que la constante évolution des cyber-attaques. 

 

À propos des auteures 

Cet article a été rédigé par Garance Mathias, Avocate Associée, et Eva Aspe, Responsable Affaires publiques chez Mathias Avocats. 

Fondé il y a plus de 20 ans par Maître Garance Mathias, après une expérience au sein de cabinets d’envergure internationale, Mathias Avocats accompagne ses clients en conseil comme en contentieux. Le cabinet est spécialisé en droit du numérique (négociation de contrats complexes), cybersécurité, protection des données et conformité (RGPD, etc.), ainsi qu’en affaires publiques, avec une expertise particulière dans l’analyse des textes européens et la veille réglementaire. 

 

L’Open Data est un mouvement issu du monde anglosaxon et permet, comme son nom l’indique, l’ouverture mais aussi la réutilisation de certaines données rendues publiques.

Cette pratique s’est accélérée ces dernières années notamment avec l’essor de l’Intelligence Artificielle qui brasse des quantités astronomiques de données publiques. Bon nombre d’entreprises l’utilisent aujourd’hui via notamment le data scrapping (dit « moissonage » en français) pour alimenter leurs services.

Si l’Open Data présente incontestablement des avantages pour la transparence et l’innovation de nos sociétés, cela ne se fait pas sans danger. En effet, qui dit données « ouvertes », dit risque qu’elles soient détournées, transformées, ou utilisées à mauvais escient.

La cybersécurité, qui est au cœur des préoccupations actuelles, a-t-elle un rôle à jouer dans ce cas ?

Dans une première partie, nous présenterons le cadre juridique de l’Open Data et les propres limites qu’il pose. Puis nous évoquerons dans une seconde partie les enjeux croissants de la cybersécurité et de la protection des données, en mettant l’accent sur les obligations nouvelles imposées aux responsables de traitements et la régulation progressive des pratiques telles que le data scraping, qui illustre les tensions entre libre accès à l’information et mise en jeu des responsabilités.

 

Cadre juridique de l’Open Data – Un droit pour les citoyens, une obligations pour les entités publiques

 

L’Open data désigne deux droits distincts :

 

• Un droit d’accès : Le droit concédé aux citoyens d’accéder à certains documents administratifs produits par les services publics (administrations, collectivités locales…).
• Un droit de réutilisation : le droit de réutiliser des informations du secteur public

 

Si ce mouvement est réalisé sur la base du volontariat dans le secteur privé, il s’agit d’une obligation légale dans le secteur public.

 

Dans le secteur public, la Loi du 17 juillet 1978 (n°78-753) a prévu pour la première fois un droit général d’accès aux documents administratifs. Ce droit d’accès sera complété par un droit de réutilisation à partir de 2005 (Ordonnance n°2005-650 du 6 juin 2005).

Une étape marquante à cette évolution réglementaire est la transformation profonde de nos sociétés avec l’avènement d’Internet et des nouvelles technologies.

En 2016, la loi Lemaire (Loi n° 2016-1321 du 7 octobre 2016 pour une République numérique) érige l’Open Data comme un principe clé de la gestion publique et introduit le principe du libre accès des documents administratifs.

Aujourd’hui, la majorité des obligations liées à l’Open Data sont consignées dans le Code des Relations entre le Public et l’Administration. L’autorité compétente sur les questions d’Open Data est la Commission d’accès aux documents administratifs (CADA), crée en 1978.

 

Ce droit à la transparence se trouve cependant limité par la loi dans plusieurs situations, notamment lorsque cela porte atteinte à la sécurité nationale, à la vie privée, ou encore aux droits de propriété intellectuelle.

 

 

Open Data confronté à la Cybersécurité : toujours plus de protection pour les données

 

Les préoccupations liées à la cybersécurité explosent ces dernières années, proportionnellement aux nombres de cyberattaques, toujours plus nombreuses et importantes.

L’un des premiers textes européens à imposer une obligation de cybersécurité générale est le règlement UE n°2016/679 dit « RGPD », qui impose, à l’article 32, à tout « responsable de traitement de données » (Data controller) de mettre en place des mesures de sécurité proportionnelles aux risques estimés.

 

D’autres règlements et directives européennes, spécifiques à certains secteurs, viennent également renforcer les obligations en matière de cybersécurité, comme la Directive NIS 2 (Network and Information Security), 2022/255 du 14 décembre 2022, ou encore le règlement DORA UE 2022/2554 pour le secteur de la finance.

 

Ces législations mènent à la multiplication des obligations de cybersécurité à la charge des entités qui manipuleraient des données, soit en tant que « fournisseurs de données » ou de « réutilisateurs ».

 

La CNIL a dans ce contexte publié en juin 2024 plusieurs fiches pratiques à destination de ces organismes, du secteur privé majoritairement, pour les inciter à penser à la protection des données personnelles qui seraient impliquées dans le cadre de l’Open Data.

Le data scraping, technique d’extraction automatique des données publiquement accessibles sur Internet, est également indirectement visé par la législation. L’appréhension de son cadre juridique se heurte à des incertitudes liées à la définition de certaines notions de bordures, telles que celle de « système de traitement automatisé de données », dont la loi Godfrain ne donne pas de définition précise.

En cas de data scrapping, des lois existantes peuvent mener à engager la responsabilité des utilisateurs de ses données, notamment l’article 323-3 du Code pénal, qui sanctionne l’extraction frauduleuse de données, ou encore l’article 226-19 pour collecte déloyale. Il sera également possible dans certains cas de rechercher la responsabilité contractuelle de ces utilisateurs, puisque ce data scrapping ne doit pas contrevenir aux fameuses « CGU » (conditions générales d’utilisation) établies par l’éditeur d’un site web.

 

En conclusion, l’Open Data, symbole d’une nouvelle ère de transparence et de démocratisation de l’accès à l’information, ne saurait être considéré comme un espace de totale liberté. Si les données ouvertes constituent un levier puissant d’innovation, leur utilisation soulève des problématiques juridiques et sécuritaires majeures, en particulier dans un contexte où la frontière entre données publiques et données personnelles peut rapidement s’estomper.

Le développement des technologies d’extraction automatique, tel que le data scraping, et l’émergence d’usages intensifs par l’IA imposent une vigilance accrue. Le droit doit donc continuer à s’adapter pour répondre à ces nouvelles pratiques, tout en garantissant un équilibre entre libre accès à l’information et protection des droits fondamentaux.

Dans ce paysage mouvant, les acteurs publics comme privés ont tout intérêt à intégrer une démarche de conformité, en s’appuyant sur les recommandations des autorités compétentes telles que la CNIL, et en anticipant les évolutions réglementaires. La sécurisation des données ouvertes devient alors non seulement une nécessité juridique, mais également un impératif éthique et stratégique.

Entré en vigueur en janvier 2023, le Digital Operational Resilience Act (DORA) constitue une avancée majeure dans le cadre réglementaire européen applicable aux institutions financières. Cette réglementation vise à renforcer leur résilience face aux risques numériques, en imposant des exigences spécifiques aux établissements financiers ainsi qu’à leurs prestataires de services numériques. Avec une mise en conformité obligatoire depuis janvier 2025, les acteurs concernés doivent adapter leurs infrastructures et leurs pratiques afin de répondre à ces nouvelles obligations. Ces évolutions influencent directement leur organisation interne, leur gouvernance ainsi que leurs relations avec leurs fournisseurs.

 

Objectifs et champ d’application de DORA

L’objectif principal de DORA est d’harmoniser la gestion des risques technologiques dans l’ensemble du secteur financier de l’Union européenne. Son champ d’application est vaste, incluant notamment les banques, compagnies d’assurance, établissements de paiement, plateformes de financement participatif, ainsi que leurs prestataires de services numériques.

Cette réglementation introduit également un encadrement plus strict des prestataires technologiques, tels que les fournisseurs de services cloud ou de technologies financières, qui jouent un rôle essentiel dans la continuité des activités des institutions financières. En tant que texte réglementaire spécialisé , le règlement DORA prévaut sur la directive NIS2 lorsqu’il est question de résilience numérique dans le secteur financier. Cela souligne l’importance accordée à la stabilité financière face aux menaces croissantes en matière de cybersécurité.

 

Principaux axes de mise en conformité avec DORA

Le cadre réglementaire du DORA repose sur cinq piliers destinés à structurer les efforts de mise en conformité des organisations concernées :

1. Gestion des risques TIC

Les entreprises doivent établir une stratégie de gestion des risques numériques. Cela implique d’identifier les vulnérabilités, de mettre en place des protocoles de sauvegarde des données, de développer des plans de continuité des activités et d’organiser des sessions de formation pour les collaborateurs. Ces dispositions visent à assurer une meilleure préparation face aux perturbations que pourrait engendrer une cyberattaque.

2. Gestion des incidents

DORA impose l’adoption de protocoles stricts pour la gestion des incidents liés aux technologies de l’information et de la communication (TIC). Les entreprises doivent notamment mettre en place des mécanismes de détection en amont, définir des procédures de réponse rapide et surtout, signaler les incidents majeurs aux autorités compétentes de leur juridiction. Il est par ailleurs demandé aux entités concernées par DORA de mettre en place une documentation systématique et un protocole de communication de crise qui seront  essentiels pour assurer une réaction coordonnée et limiter l’impact des incidents.

3. Tests de résilience

Les institutions financières doivent régulièrement tester leurs infrastructures afin d’évaluer leur capacité à faire face à des menaces de cybersécurité. Ces évaluations incluent des tests de pénétration (pentests), des simulations d’attaques et des exercices de reprise d’activité post incident. Ces dispositifs permettent d’identifier d’éventuelles faiblesses et d’améliorer la résilience globale des systèmes.

4. Partage d’informations

Afin de renforcer la coopération entre les différents acteurs du secteur financier, DORA recommande le partage d’informations sur les menaces futures et les vulnérabilités identifiées. Cet échange d’informations contribue à sensibiliser l’ensemble du secteur aux risques numériques et à limiter leur propagation.

5. Encadrement des tiers TIC

Les relations avec les fournisseurs de services TIC sont soumises à des obligations strictes, notamment :

• Répertorier les contrats en place pour identifier les services critiques et les mettre à jour avec les obligations de DORA ;
• Intégration de clauses contractuelles relatives à DORA et notamment traitant des audits, de la continuité des services et des conditions de réversibilité en cas de résiliation
• Mise en place d’un suivi des prestataires et de leurs sous-traitants pour valider leur conformité à tout instant.

Ces mesures visent à garantir une conformité tout au long de la chaîne de sous-traitance.

 

Conseils pratiques pour la mise en conformité

Afin de se mettre en conformité avec DORA, les institutions financières et leurs fournisseurs doivent prendre des mesures adaptées, parmi lesquelles :

• Analyse des contrats existants pour évaluer leur conformité avec les exigences de DORA ;
• Mise à jour des contrats via l’ajout de clauses spécifiques sur la sécurité des données, les audits et la continuité des services ;
• Collaboration nécessaire avec les prestataires afin de s’assurer qu’ils disposent des ressources et des procédures nécessaires pour se conformer aux nouvelles règles ;
• Organisation régulière de simulations pour tester les dispositifs de gestion des incidents et les plans de reprise d’activité.

Mise en place d’une documentation complète et à jour des process.

 

Conséquences pour les investisseurs

Le règlement DORA instaure des standards de résilience opérationnelle qui influencent directement la gouvernance des institutions financières. Les investisseurs doivent donc porter une attention particulière aux mesures prises par les entreprises pour se conformer à ces nouvelles exigences.

Ils doivent notamment examiner les aspects suivants :

• Gestion des risques : l’entreprise dispose-t-elle de dispositifs efficaces pour détecter et limiter les menaces cyber ?
• Relations fournisseurs : les contrats incluent-ils des clauses conformes aux obligations de DORA ? Les prestataires font-ils l’objet d’un suivi régulier ?
• Résilience : l’entité concernée réalise-t-elle régulièrement des tests pour valider la robustesse de sa protection contre les cyberattaques ?
• Sécurité des données : les mécanismes en place garantissent-ils la protection, la disponibilité et l’intégrité des données sensibles ?

 

Un livre blanc sur les clauses contractuelles DORA pour les entreprises TIC publié par l’APP, présente le règlement DORA et son impact sur les organisations. Il détaille les exigences de gestion des fournisseurs tiers et les actions concrètes pour assurer la conformité. Conçu comme un guide pratique, il aide à anticiper les défis de gouvernance liés à cette réglementation.

 

Conclusion

L’adoption du règlement européen DORA marque une évolution significative dans le paysage réglementaire européen en matière de résilience numérique. Pour les institutions financières et leurs fournisseurs TIC, il est impératif de mettre en place une approche structurée afin de répondre aux nouvelles obligations. En garantissant une meilleure résilience face aux risques numériques, ces efforts renforcent la stabilité du secteur financier. Pour les investisseurs, le respect des exigences du DORA constitue un indicateur de fiabilité et de pérennité, leur permettant d’établir des partenariats plus sûrs et durables.

Depuis plus de quarante ans, l’Agence pour la Protection des Programmes (APP) est un acteur majeur et reconnu dans la défense des droits des auteurs et éditeurs d’œuvres numériques. Spécialisée dans la protection des logiciels et des données, l’APP a toujours placé la sécurité au cœur de ses systèmes informatiques.

La certification ISO 27001 constitue une garantie supplémentaire en matière de protection des données, dans un contexte où les cybermenaces ne cessent de croître. Cet article se propose d’explorer l’engagement de l’APP en matière de sécurité des données et l’importance de la norme ISO 27001 dans cette démarche.

Les points clés à retenir de cet article

• La certification ISO 27001 atteste de la mise en place d’un système de management de la sécurité de l’information (SMSI) conforme à un standard international reconnu.
• La sécurité des données constitue une priorité historique de l’APP, en cohérence avec sa mission de tiers de confiance en matière de protection des actifs numériques.
• La norme repose sur une approche structurée fondée sur l’analyse des risques, la mise en œuvre de contrôles adaptés et l’amélioration continue.
• Les mesures déployées couvrent l’ensemble du cycle de vie des données : dépôt, conservation, communication et entiercement.
• La certification renforce la résilience de l’APP face aux cybermenaces et consolide la confiance de ses membres et partenaires.

La sécurité des données : une priorité historique

La protection des données constitue un élément central des activités de l’APP. Cette exigence s’appuie à la fois sur son expérience dans la protection des actifs numériques et sur les dispositifs techniques mis en œuvre pour garantir la fiabilité des services proposés.

Une expertise à la croisée du juridique et de la technique

En tant que tiers de confiance spécialisé dans les sujets de propriété intellectuelle et de nouvelles technologies, l’expertise de l’APP associe depuis toujours la rigueur juridique à une connaissance fine des enjeux techniques.

Ainsi, dès ses débuts, l’Agence pour la Protection des Programmes s’est engagée à garantir la protection des données qui lui sont confiées, que ce soit dans le cadre de la protection de logiciels ou des droits d’auteur. La certification ISO 27001 constitue une preuve de cet engagement.

Le cadre sécuritaire mis en place par l’APP repose sur trois principes fondamentaux de la sécurité de l’information : la disponibilité, l’intégrité et la confidentialité des données. Ces principes structurent l’ensemble des pratiques de l’organisation.

Ainsi, qu’il s’agisse de la conservation des dépôts qui lui sont confiés ou de la communication de ces données avec les parties prenantes dans le cadre d’opérations d’entiercement, l’APP veille à ce que les standards de sécurité les plus élevés soient respectés.

Horodatage et valeur probatoire des dépôts

Au-delà des mesures techniques et organisationnelles, la sécurité des données participe plus largement à la construction d’une confiance numérique durable. Cette confiance repose notamment sur la capacité à démontrer l’intégrité et l’antériorité des actifs déposés.

À ce titre, les mécanismes d’horodatage électronique apportent cette garantie en associant de manière fiable une date et une heure à un contenu numérique. Ils permettent d’attester qu’un fichier existait à un instant donné et qu’il n’a pas été altéré depuis.

Dans le cadre des missions de l’APP, l’horodatage contribue ainsi à renforcer la valeur probatoire des dépôts et à sécuriser les échanges, en cohérence avec les exigences croissantes en matière de traçabilité et de preuve dans l’environnement numérique.

ISO 27001 : un standard international de sécurité

La norme ISO 27001 est une norme internationale qui définit des exigences pour les systèmes de management de la sécurité de l’information (SMSI). Pour obtenir cette certification, l’APP a mis en place un cadre de gestion rigoureux visant à protéger les informations sensibles contre les accès non autorisés, les altérations ou les pertes.

Les principes clés de la norme ISO 27001

La norme ISO 27001 s’appuie sur plusieurs principes majeurs :

• Évaluation des risques : la norme impose d’identifier les risques potentiels liés à la sécurité des données et d’en évaluer la probabilité ainsi que l’impact.
• Mise en œuvre de contrôles de sécurité : une fois les risques évalués, des mesures sont mises en place pour minimiser ou éliminer ces risques.
• Amélioration continue : une révision constante des politiques et des pratiques de sécurité est imposée afin de s’adapter aux nouvelles menaces.

Un cadre structuré de sécurité de l’information

Ce pilotage s’appuie sur un référentiel qui couvre des sujets variés, afin de traiter la sécurité comme un ensemble cohérent. La norme s’intéresse notamment à l’organisation, aux procédures et aux contrôles techniques.

Cette norme repose sur un cadre couvrant différents aspects de la sécurité de l’information, notamment :

• l’organisation des politiques de sécurité ;
• la gestion des ressources humaines ;
• la gestion des actifs informationnels ;
• le contrôle des accès ;
• la cryptographie ;
• la sécurité physique et environnementale ;
• la gestion des incidents.

La norme ISO 27001 traduit ainsi un engagement à suivre un processus structuré et transparent en matière de sécurité des systèmes d’information.

L’APP et la certification ISO 27001 : un choix logique et nécessaire

Pour l’APP, l’obtention de la certification ISO 27001 s’inscrit dans la continuité de sa démarche de sécurisation des données.

La mise en place d’une infrastructure sécurisée au fil des années, combinée à une vigilance constante pour protéger les données critiques qui lui sont confiées par ses membres, a conduit à la reconnaissance de ces efforts par cette norme internationale.

L’adoption de la norme ISO 27001 permet à l’APP de garantir une plus grande résilience face aux cybermenaces. En suivant ce cadre, l’APP est capable de :

• minimiser les risques liés à la sécurité de l’information en identifiant et en analysant les vulnérabilités potentielles ;
• fournir un cadre structuré pour la gestion des informations, garantissant que les processus internes répondent aux standards les plus élevés ;
• sensibiliser davantage le personnel aux enjeux de sécurité, en les formant régulièrement aux bonnes pratiques et en les rendant conscients des menaces.

Les actions mises en œuvre par l’APP pour minimiser les risques cybers

La norme impose non seulement la mise en place de mesures de sécurité techniques, mais aussi une révision régulière des politiques de sécurité. Elle met également l’accent sur la nécessité de sensibiliser le personnel aux risques liés à la cybersécurité, la sécurité d’une organisation reposant aussi sur la vigilance de chacun.

Dans cette logique, plusieurs actions sont mises en place afin de sécuriser les données et de tester régulièrement le dispositif. Ces actions couvrent à la fois la prévention, la détection et la continuité.

Parmi les actions concrètes mises en œuvre par l’APP dans le cadre de la norme ISO 27001, on retrouve :

• Le chiffrement des données : toutes les informations sensibles sont chiffrées pour garantir qu’elles ne soient accessibles que par des utilisateurs autorisés.
• Le contrôle d’accès strict : un système d’autorisation rigoureux garantit que seules les personnes habilitées peuvent accéder aux données, réduisant ainsi le risque d’erreurs humaines ou de fuites accidentelles.
• La revue périodique des politiques de sécurité : l’APP réalise des audits internes réguliers pour s’assurer que ses politiques sont à jour et conformes aux évolutions technologiques.
• La mise en place de pentests : des tests d’intrusion sont réalisés régulièrement pour identifier les vulnérabilités potentielles et y remédier rapidement.
• La sensibilisation des employés : une formation continue est dispensée à l’ensemble des employés pour leur permettre de rester informés des menaces actuelles et des bonnes pratiques en matière de sécurité.
• Les sauvegardes et la redondance des systèmes : afin de garantir la disponibilité des données en cas d’incident majeur, l’APP met en place des mécanismes de sauvegarde réguliers et des infrastructures redondantes.

Un engagement fort pour la souveraineté des données

Un aspect central de l’engagement de l’APP en matière de sécurité des données réside dans le choix de conserver l’ensemble des informations sur le territoire français.

Cette approche en faveur de la souveraineté des données garantit que les informations ne sont pas soumises à des législations étrangères susceptibles de compromettre leur sécurité ou leur confidentialité.

Cette décision reflète la volonté de l’APP d’offrir à ses membres la plus grande transparence et de maîtriser pleinement l’infrastructure qui protège les données. En combinant une approche technologique pointue avec un cadre juridique fort, l’APP s’assure que les informations sont toujours traitées de manière sécurisée, selon les lois françaises et européennes en vigueur.

ISO 27001 : un engagement durable pour la sécurité des actifs numériques

Depuis plus de quarante ans, l’APP a su anticiper les enjeux liés à la protection des données numériques. Grâce à sa certification ISO 27001, l’Agence pour la Protection des Programmes renforce encore son engagement à garantir la sécurité de l’information à ses clients, tout en limitant les risques cyber.

Cette certification est bien plus qu’un simple label : elle reflète une méthodologie rigoureuse, une gestion proactive des risques et une amélioration continue des processus de sécurité.

En combinant ses compétences technico-juridiques, une infrastructure sécurisée et des contrôles stricts, l’APP continue de jouer un rôle majeur dans la protection des droits numériques en Europe, tout en garantissant que les données qui lui sont confiées sont protégées contre des cybermenaces de plus en plus soutenues.

Au travers des condamnations prononcées par la Cnil et des nombreuses recommandations publiées sur son site (cnil.fr), l’autorité de régulation des données procure de nombreux enseignements sur les éléments à prendre en compte pour sécuriser son système d’information. Voici quelques leçons à tirer de ces sanctions.

En 2022, un tiers des sanctions prononcées par la Commission nationale de l’information et des libertés (Cnil) était en partie fondé sur un manquement à la sécurité des données personnelles. Que ce soit dans le cadre du règlement général sur la protection des données (RGPD) ou avant ce règlement dans celui de la loi informatique et libertés, la sécurité constitue une obligation centrale car le défaut de protections des systèmes d’information ou des sites internet représente une vraie menace pour les données. D’après le panorama des cybermenaces 2022 de l’ENISA (European Union Agency for Cybersecurity), les rançongiciels (ransomware) ont occupé la première place du podium des cybermenaces. Et comme l’a montré le dernier rapport de l’Agence nationale de la sécurité des systèmes d’information (Anssi), les cybercriminels s’investissent de plus en plus dans le vol de données et le chantage à la divulgation. D’où l’attention particulière et la sévérité de la Cnil sur ce sujet afin que les acteurs de traitements veillent à assurer la sécurité et la confidentialité des données qu’ils traitent.

Au-delà de la crainte d’une sanction de la Cnil et d’une atteinte à l’image de son organisation en cas de publicité sur une fuite de donnée, l’obligation de sécurité est une incitation à protéger ses données. Si le respect de cette obligation constitue une contrainte, elle représente aussi un outil puissant de gestion de la sécurité du système d’information. En protégeant les données personnelles de manière proactive par la mise en place de mesures techniques et organisationnelles, les entreprises renforcent la confiance de leurs clients, se prémunissent contre les risques de violations de données et se positionnent comme des acteurs respectueux de la vie privée dans un paysage numérique en constante évolution. La lecture des délibérations de la Cnil mais aussi celle de son Guide de la sécurité des données personnelles éclairent parfaitement sur les précautions élémentaires qui devraient être mises en œuvre de façon systématique.

L’article 32 du RGPD impose que « le responsable du traitement et le sous-traitant mettent en œuvre les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque ». Et le montant des sanctions pécuniaires prévu par le règlement peut s’élever jusqu’à 20 millions d’euros ou dans le cas d’une entreprise jusqu’à 4 % du chiffre d’affaires annuel mondial. Si le nombre de sanctions prononcées par la Cnil dans l’année est très faible (22 en 2022), il devrait fortement augmenter avec la mise en place d’une procédure simplifiée de sanction pour les atteintes fréquemment observées. Surtout, la publicité qui pourrait être faite suite à une fuite de données peut avoir des répercussions très dommageables en termes d’image. Et puis, il y a toujours le risque d’être assigné devant un tribunal, comme OVH qui a été condamné pour avoir manqué à ses obligations contractuelles de sécurité dans le cadre de l’incendie de son datacenter de Strasbourg qui a touché des milliers de clients ainsi que leurs données.

De nombreux aspects sont pris en compte par la Cnil dans ses décisions : absence de robustesse des mots de passe, défaut dans le stockage et la transmission des mots de passe, accès des utilisateurs, évaluation et analyse des mesures techniques, anonymisation des données, contrôle des sous-traitants…). En lien avec les défauts relevés en matière de sécurité des données, l’absence de documentation des violations de données personnelles a également donné lieu à sanction, ce qui souligne la nécessité de formaliser le signalement des incidents de sécurité et les conditions permettant de caractériser ou non l’existence de violations. La Cnil a sanctionné des entreprises qui n’ont pas sensibilisé et formé leurs employés aux bonnes pratiques de sécurité.

1,5 million d’euros d’amende

Voici quelques exemples de décisions de sanctions prononcées par la Cnil pour un manquement à l’obligation de sécurité. Selon les cas et la sensibilité des traitements, le RGPD envisage plusieurs moyens de sécurisation à mettre en œuvre ; le chiffrement des données à caractère personnel étant un des premiers exemples cités. La Cnil a prononcé plusieurs sanctions dans des affaires où les données personnelles sensibles n’étaient pas chiffrées. Par exemple, le 15 avril 2022, elle a condamné la société Dedalus Biologie, qui commercialise des logiciels pour des laboratoires d’analyse médicale, à payer une amende de 1,5 million d’euros, notamment pour des défauts de sécurité ayant conduit à la fuite de données médicales de près de 500 000 personnes. Dans cette affaire, la Cnil a relevé dans sa décision que « l’absence de mise en place de mesures de sécurité protégeant le serveur en cause – notamment l’absence de chiffrement, l’absence d’effacement automatique des données après leur migration, l’absence d’authentification requise depuis Internet pour accéder à la zone publique du serveur et l’utilisation de comptes utilisateurs partagés – a conduit à rendre accessibles lesdites données à des tiers, et ce malgré des alertes préalables à la violation de données à caractère personnel ayant conduit à la divulgation d’un fichier contenant les données médico-administratives de près de 500 000 personnes. »   

La Cnil prête également une attention particulière à l’absence de mesures prises pour éviter les accès non autorisés aux données pouvant résulter d’une mauvaise configuration des paramètres de sécurité, d’une gestion insuffisante des droits d’accès ou d’une absence de mesures de contrôle appropriées. Par exemple, elle a condamné Bouygues Télécom, le 26 décembre 2018, à 250 000 euros d’amende pour avoir laissé la possibilité d’accéder à des contrats et factures de client B&You par la modification d’une adresse URL. L’opérateur responsable de traitement n’a pas assuré la sécurité et la confidentialité des données en faisant le choix de ne pas mettre en œuvre de mesure complémentaire à l’authentification des utilisateurs du site web concerné.

Le 30 novembre 2022, la Cnil a prononcé une sanction de 300 000 euros à l’encontre de la société Free. Elle lui a reproché, entre autres, le manque de robustesse des mots de passe générés lors de la création d’un compte utilisateur sur le site web de la société, et le fait qu’ils soient stockés en clair dans la base de données des abonnés de la société.

La Commission veille aussi à la manière dont les organisations gèrent les incidents de sécurité et en a sanctionné plusieurs qui n’avaient pas pris de mesures concernant duites de données. Les entreprises doivent être préparées à réagir rapidement en cas d’incident, en mettant en place des procédures de gestion des incidents, en notifiant les autorités compétentes et les personnes concernées, et en prenant des mesures correctives pour éviter de nouvelles violations. Dans une affaire qui concernait Slimpay, un établissement de paiement dont l’accès au serveur ne faisait l’objet d’aucune mesure de sécurité : les données d’état civil (civilité, nom, prénom), les adresses postales et électroniques, les numéros de téléphone et des informations bancaires (BIC/IBAN) de plus de 12 millions de personnes ont ainsi été compromises. En plus de l’absence de mesures de sécurité, la Cnil a estimé que la société aurait dû informer toutes les personnes concernées de cette atteinte à leurs données. Elle a donc condamné Slimpay à 180 000 € d’amende pour non-respect de son obligation de sécurité mais aussi le manquement à l’obligation d’information d’une violation de données personnelles aux personnes concernées

Les organisations doivent bien sûr prendre au sérieux le risque légal d’un manquement à l’obligation de sécurité mais surtout le voir comme une opportunité de se préparer à un risque de cyberattaque qui aujourd’hui est loin d’être théorique. Selon le Baromètre Data Breach 2022, animé par le Forum International de la Cybersécurité (FIC) en partenariat avec Almond et Bessé, le nombre de violations de données a presque doublé en un an et demi, touchant plus de 5 millions de personnes en France. Les actes malveillants d’origine externe ont augmenté de 10,6%, tandis que les fuites d’origine interne ont progressé de 11,89%.

Vous êtes cyber-assureur et vous souhaitez connaître les actifs immatériels de votre assuré ?