Les cyberattaques se multiplient et leurs conséquences dépassent désormais largement les systèmes informatiques. Début octobre 2026, une cyberattaque touchant des systèmes de réfrigération du fabricant Danfoss a perturbé plusieurs centaines de supermarchés français, entraînant la destruction de marchandises et d’importantes pertes financières. Pour la seule enseigne Intermarché, les pertes ont été évaluées à plusieurs dizaines de millions d’euros, illustrant les conséquences économiques qu’une attaque informatique peut entraîner sur les activités des entreprises (1).

Les attaques ayant visé Octave en 2024 et Harvest en 2025 peuvent également illustrer les risques liés à cette dépendance aux fournisseurs de logiciels.

Ces incidents rappellent à quel point une cyberattaque peut compromettre directement l’activité d’une entreprise. Lorsqu’elle touche un éditeur de logiciels ou un prestataire informatique, ses conséquences peuvent notamment se répercuter sur l’ensemble de ses clients, parfois privés d’outils indispensables à leur activité.

Face à ces risques de dépendance, la directive européenne NIS 2 renforce les exigences en matière de continuité d’activité et de sécurité de la chaîne d’approvisionnement, invitant les organisations concernées à mieux anticiper les conséquences d’une défaillance de leurs prestataires technologiques.

Dans ce contexte, l’entiercement logiciel peut constituer l’un des moyens de répondre aux exigences de résilience portées par NIS 2, en contribuant à anticiper certaines situations de défaillance d’un fournisseur et à préserver, sous conditions, l’accès aux éléments nécessaires à l’utilisation et à la maintenance d’un logiciel.

Les points clés à retenir sur l’entiercement logiciel et la continuité d’activité

• Une cyberattaque contre un fournisseur de logiciels peut perturber l’activité de nombreux clients.
• La dépendance aux prestataires de logiciel représente un risque à intégrer dans les stratégies de continuité d’activité.
• La directive NIS 2 renforce les exigences relatives à la gestion des risques cyber et à la sécurité des fournisseurs.
• L’entiercement logiciel permet d’organiser la conservation des éléments techniques d’un logiciel auprès d’un tiers de confiance. Il complète les mesures de cybersécurité et les plans de continuité d’activité, sans s’y substituer.

 

1. Cyberattaques : quand la défaillance d’un fournisseur de logiciel affecte ses clients

La dépendance des entreprises aux solutions logicielles crée de nouveaux risques opérationnels. Lorsqu’un fournisseur subit une cyberattaque, les conséquences peuvent dépasser son propre système d’information et toucher directement les activités de ses clients. Plusieurs incidents récents illustrent les effets de cette interdépendance.

Octave et Harvest : deux exemples de cyberattaques aux conséquences étendues

En août 2024, Octave, fournisseur de solutions informatiques notamment utilisées dans le secteur de la distribution du livre, a subi une cyberattaque ayant perturbé les services de plusieurs de ses clients, dépendant de ses outils pour leurs opérations quotidiennes. (2)

Quelques mois plus tard, le 27 février 2025, Harvest, éditeur de logiciels destinés aux professionnels du patrimoine et de la finance, a été victime d’une attaque par rançongiciel. L’incident a entraîné des interruptions de services pour ses utilisateurs, avant une remise en fonctionnement progressive au cours du mois de mars. (3)

Ces événements mettent en évidence un risque commun : la compromission d’un fournisseur peut provoquer une interruption d’activité chez ses clients, même lorsque leurs propres systèmes d’information n’ont pas été directement attaqués.

Une dépendance logicielle à intégrer dans la gestion des risques

De nombreuses organisations s’appuient sur des logiciels métiers pour gérer leurs opérations, leurs données et leurs relations clients. Cette dépendance est particulièrement marquée lorsque les solutions sont fournies en mode SaaS (Software as a Service) et que leur fonctionnement repose sur des infrastructures administrées par un prestataire.

Une indisponibilité prolongée peut alors compromettre l’accès aux applications, retarder certaines opérations ou empêcher l’exécution d’obligations contractuelles.

La gestion des risques cyber ne peut donc se limiter à la protection des infrastructures internes. Elle doit également intégrer les conséquences d’une interruption chez un fournisseur.

Une question se pose alors : comment une organisation peut-elle maintenir ses activités lorsqu’un prestataire logiciel ne peut plus assurer son service ou sa maintenance ?

 

2. NIS 2 : anticiper les risques fournisseurs pour renforcer la continuité d’activité

La multiplication des cyberattaques visant les prestataires numériques souligne la nécessité d’intégrer les dépendances technologiques dans les stratégies de cybersécurité. Une interruption chez un fournisseur peut compromettre le fonctionnement de plusieurs organisations, indépendamment de la sécurité de leurs propres infrastructures.

C’est notamment pour répondre à ces risques que la directive européenne NIS 2 (4) renforce les exigences en matière de gestion des risques cyber, en accordant une attention particulière à la continuité d’activité et à la sécurité de la chaîne d’approvisionnement.

La continuité d’activité, une exigence de la directive NIS 2

La directive NIS 2 vise à renforcer le niveau de cybersécurité des organisations relevant de son champ d’application et leur capacité à faire face aux incidents susceptibles de perturber leurs activités.

Son article 21(4) prévoit notamment la mise en œuvre de mesures techniques, opérationnelles et organisationnelles adaptées aux risques identifiés.

Parmi ces mesures figurent la continuité d’activité, la gestion des sauvegardes, la reprise après sinistre et la gestion de crise.

L’objectif est de permettre aux organisations concernées de mieux anticiper les interruptions, d’en limiter les conséquences et de préparer la reprise de leurs opérations.

Cette démarche suppose notamment d’identifier les logiciels indispensables au fonctionnement de l’entreprise et d’évaluer les conséquences de leur indisponibilité prolongée.

La sécurité des fournisseurs, un enjeu majeur de NIS 2

Au-delà des mesures de sécurité internes, la directive accorde une attention particulière à la sécurité de la chaîne d’approvisionnement, c’est-à-dire aux risques associés aux fournisseurs et prestataires dont dépend une organisation.

L’article 21, paragraphe 2, point d), de la directive NIS 2 (5) prévoit expressément la prise en compte des aspects de sécurité concernant les relations avec les fournisseurs et prestataires directs.

Une cyberattaque affectant un éditeur de logiciels peut ainsi devenir un risque opérationnel pour ses clients, même lorsque ces derniers disposent de mesures de cybersécurité adaptées.

La gestion des risques doit donc intégrer les dépendances technologiques et les scénarios de défaillance des fournisseurs.

Pour les organisations concernées par NIS 2, cela implique notamment de s’interroger sur leur capacité à maintenir leurs activités lorsqu’un prestataire ne peut plus assurer la disponibilité ou la maintenance d’un logiciel.

 

3. L’entiercement logiciel : un dispositif pour anticiper la défaillance d’un fournisseur

Face aux risques de dépendance technologique, les organisations peuvent mettre en place différents dispositifs destinés à préserver leur continuité d’activité. Parmi eux, l’entiercement logiciel permet d’anticiper certaines situations dans lesquelles un fournisseur ne serait plus en mesure d’assurer ses engagements.

En organisant contractuellement l’accès aux éléments techniques d’un logiciel, il contribue à limiter les conséquences d’une défaillance prolongée.

Organiser un accès aux éléments nécessaires à la maintenance du logiciel

L’entiercement logiciel consiste, pour un éditeur ou fournisseur, à confier à un tiers de confiance des éléments techniques relatifs à sa solution, au bénéfice d’un ou plusieurs clients désignés.

Ces éléments peuvent comprendre le code source, la documentation technique, les dépendances logicielles et les informations nécessaires à l’installation, à la configuration ou à la maintenance.

Un contrat définit les conditions dans lesquelles le bénéficiaire peut demander l’accès aux éléments déposés : cessation d’activité du fournisseur, arrêt de la maintenance ou encore panne bloquante ou indisponibilité prolongée du logiciel, notamment à la suite d’une cyberattaque, lorsque ces situations ont été expressément prévues au contrat et que les conditions d’accès sont réunies.

L’objectif est de permettre au client, dans les conditions contractuelles définies, de poursuivre l’utilisation et de faire assurer la maintenance du logiciel, notamment par ses propres équipes ou un prestataire tiers.

Un dispositif complémentaire aux mesures de cybersécurité

Dans le contexte d’une cyberattaque, l’entiercement présente un intérêt particulier lorsqu’un incident entraîne une incapacité durable du fournisseur à remplir ses engagements.

Toutefois, une cyberattaque ne déclenche pas automatiquement l’accès aux éléments entiercés. Celui-ci dépend des conditions prévues au contrat.

De même, la disponibilité du code source ne suffit pas nécessairement à remettre un service en fonctionnement. La reprise peut nécessiter des infrastructures, des données sauvegardées, des compétences techniques et un environnement d’exploitation adapté.

L’efficacité du dispositif repose donc sur plusieurs précautions : définir précisément les événements ouvrant droit à l’accès, prévoir des mises à jour régulières du dépôt et s’assurer que les éléments conservés permettent une exploitation effective du logiciel.

L’entiercement ne constitue pas une obligation imposée par NIS 2, mais peut contribuer à une stratégie plus large de continuité d’activité et de maîtrise des risques fournisseurs.

L’APP, tiers de confiance au service de la continuité logicielle

L’Agence pour la Protection des Programmes (APP) accompagne les éditeurs et leurs clients dans la mise en place de dispositifs d’entiercement adaptés à leurs besoins.

En assurant la conservation des éléments déposés et en encadrant contractuellement les conditions de leur accès, l’APP contribue à sécuriser les relations entre fournisseurs et utilisateurs de logiciels.

Selon les besoins, différents niveaux de dépôt permettent également de renforcer les vérifications portant sur les éléments confiés.

Pour les organisations dépendantes de solutions logicielles indispensables à leur activité, l’entiercement constitue ainsi un levier de préparation à la défaillance d’un fournisseur, à intégrer aux côtés des sauvegardes, des plans de reprise et des autres mesures de résilience.

 

Anticiper les défaillances pour mieux préserver la continuité d’activité

Les cyberattaques visant les fournisseurs de logiciels rappellent que la résilience d’une organisation dépend également de celle de ses partenaires technologiques.

En renforçant les exigences relatives à la continuité d’activité et à la sécurité de la chaîne d’approvisionnement, NIS 2 encourage les organisations à mieux identifier et anticiper leurs dépendances technologiques.

Dans cette démarche, l’entiercement logiciel proposé par l’APP contribue à organiser, en amont, les conditions d’accès aux éléments nécessaires à la poursuite de l’utilisation et de la maintenance d’un logiciel en cas de défaillance du fournisseur.

Un dispositif complémentaire pour renforcer la maîtrise des risques et mieux préparer les organisations aux conséquences d’une interruption prolongée de leurs services numériques.

 

Sources

1. Cyberattaque des systèmes frigorifiques (2026) :
   Associated Press – French cybersecurity authority warns attack may be ongoing as stores scramble to restock.
2. Cyberattaque Octave (2024) :
   LeMagIT – Les clients d’Octave victimes des effets d’une cyberattaque.
3. Cyberattaque Harvest (2025) :
   ANACOFI – Cyberattaque Harvest.
4. Directive NIS 2 :
   Directive (UE) 2022/2555, article 21.
5. Directive NIS 2 :
   Directive (UE) 2022/2555 du Parlement européen et du Conseil du 14 décembre 2022, article 21, § 2, d).

Cyberattaque Danfoss (2026) :
Le Parisien – Cyberattaque contre les réfrigérateurs : le patron des magasins U fait un premier bilan.

Alors que la directive NIS2 n’est pas encore transposée dans l’ensemble des États membres, la Commission européenne a publié, le 20 janvier 2026, une proposition de directive visant à la modifier. Explications.

Les cyberattaques se multiplient et touchent désormais des organisations de toute taille, publiques comme privées, tandis que le cadre réglementaire de cybersécurité devient toujours plus dense, technique… et instable. C’est dans ce contexte que la Commission européenne a publié, le 20 janvier 2026, une proposition de directive^[1] visant à modifier la directive (UE) 2022/2555, dite directive « NIS2 », dans le cadre de la révision du règlement (UE) 2019/881 relatif à la cybersécurité (Cybersecurity Act 2).

La démarche peut surprendre : la directive NIS2 n’est pas encore transposée dans l’ensemble des États membres — y compris en France — que sa révision est déjà engagée. Pour la Commission européenne, cette modification se justifie par les difficultés d’application rencontrées par les entités concernées, notamment l’incertitude entourant le champ d’application du texte, ou encore la complexité des obligations de notification d’incident. La proposition ne comporte que cinq articles. Elle n’en amorce pas moins plusieurs évolutions majeures du régime NIS2.

 

Les points clés à retenir

• Une révision anticipée de NIS 2 : la Commission européenne propose de modifier la directive alors que sa transposition reste inachevée dans plusieurs États membres, dont la France.
• Un champ d’application clarifié et élargi : la proposition vise à faciliter l’identification des entités concernées et à intégrer de nouvelles catégories d’acteurs.
• Des obligations renforcées en cas de ransomware : les organisations devront transmettre des informations plus détaillées sur les attaques, notamment sur les éventuels paiements de rançon.
• Une simplification des démarches de conformité : le texte prévoit une harmonisation des exigences documentaires, une reconnaissance des certifications et un rôle accru de l’ENISA.
• Une anticipation des menaces quantiques : les États membres sont encouragés à préparer leur transition vers la cryptographie post-quantique pour renforcer la protection des données sensibles.

 

1- Le champ d’application NIS2 précisé et étendu à de nouveaux acteurs

En pratique, la principale difficulté d’application de la directive NIS2 tient à la détermination des entités concernées, et notamment à l’identification des organisations susceptibles d’être qualifiées d’« entités essentielles » ou d’« entités importantes ». Ces qualifications reposent en effet aujourd’hui sur un faisceau de critères (taille, secteur d’activité, criticité), dont l’interprétation demeure incertaine. Consciente de cette difficulté, l’Agence nationale de la sécurité des systèmes d’information (Anssi), autorité nationale compétente désignée pour la mise en œuvre de la directive NIS2 en France, propose par ailleurs un questionnaire d’auto-évaluation afin d’accompagner les organisations dans cette démarche de qualification^[2].

Dans cette optique de simplification et de réduction des coûts de conformité, le projet introduit une nouvelle catégorie d’acteurs, les « small mid-cap enterprises »^[3]. Ces entreprises, dès lors qu’elles exercent une activité relevant d’un secteur figurant à l’annexe I de la directive NIS2, seraient automatiquement qualifiées d’entités importantes. La Commission cherche ainsi à réduire les incertitudes d’interprétation qui ont conduit de nombreuses organisations à réaliser des analyses juridiques lourdes pour déterminer leur statut.

Par ailleurs, la proposition étend explicitement le champ d’application de la directive à plusieurs catégories d’acteurs indépendamment de leur taille. Seraient ainsi inclus les fournisseurs de portefeuilles européens d’identité numérique^[4], qualifiés d’entités essentielles, ainsi que les services dits « European Business Wallets ». Entreraient également dans le périmètre les exploitants d’infrastructures sous-marines de transmission de données, y compris lorsque l’entité exploitante ne répond pas, par ailleurs, aux critères classiques d’assujettissement. Ces ajouts confirment une évolution de NIS2 : la criticité d’une entité se détermine désormais davantage par son impact sur la continuité des services numériques que par sa taille.

 

2- Attaque par ransomware: une obligation d’information renforcée

Les attaques par ransomware comptent parmi les incidents les plus fréquents, notamment dans des secteurs sensibles comme la santé. La proposition de directive modifie l’article 23 de la directive NIS2 pour y ajouter une obligation renforcée d’information pesant sur les organismes en cas d’attaque par ransomware. Les organismes devront indiquer dans leur notification initiale si une attaque par ransomware a été détectée, son vecteur d’intrusion et les mesures d’atténuation mises en œuvre. Le nouveau paragraphe 13 est quant à lui plus sensible. Sur demande du CSIRT^[5], l’entité devra indiquer si une rançon a été exigée, identifier son auteur lorsqu’il est connu, et préciser si un paiement a été effectué, ainsi que, le cas échéant, son montant, ses modalités et l’identité du destinataire ou du bénéficiaire final.

La notification d’incident évolue ainsi vers un véritable outil d’investigation administrative : les autorités ne cherchent plus seulement à être informées de l’attaque, mais également à en comprendre les mécanismes et les modalités de financement, avec pour objectif le démantèlement des groupes criminels.

 

3- Une logique de simplification administrative pour l’écosystème concerné et accroissement du rôle de l’ENISA

La proposition de directive vise explicitement à réduire la charge administrative pesant sur les entités essentielles et importantes ainsi que sur leurs sous-traitants. D’une part, la Commission européenne entend encadrer les exigences documentaires imposées aux sous-traitants, aujourd’hui confrontés à une multiplication de questionnaires de sécurité et d’exigences contractuelles hétérogènes, en annonçant la publication de lignes directrices précisant un niveau approprié de détails et de format des demandes d’informations. D’autre part, afin d’éviter la répétition de démarches de conformité pour les groupes opérant dans plusieurs États membres, le texte introduit un mécanisme fondé sur la reconnaissance d’une certification, permettant aux entités concernées de ne plus avoir à justifier séparément leur conformité auprès de chaque autorité nationale compétente. Par ces deux leviers (harmonisation des exigences et reconnaissance mutuelle fondée sur la certification), la Commission cherche à alléger la pression normative globale sur les organisations soumises à la directive NIS2 comme sur leurs sous-traitants.

Enfin, dans la même logique d’harmonisation, la Commission prévoit d’élargir les compétences de l’ENISA, l’Agence de l’Union européenne pour la cybersécurité. Le nouvel article 37a lui confierait notamment la capacité d’analyser les risques cyber transfrontaliers affectant les entités essentielles et importantes, d’établir des rapports d’évaluation et d’élaborer des lignes directrices sur cette base. L’objectif est de renforcer la coordination européenne afin de permettre une réaction plus rapide et cohérente face aux incidents affectant plusieurs États membres.

 

4- Dans la continuité de l’Anssi : le développement d’une cryptographie résistante aux menaces quantiques

Selon la Commission européenne, les attaques dites HNDL (« Harvest now – decrypt later »), consistant à collecter aujourd’hui des données chiffrées afin de pouvoir les déchiffrer ultérieurement, ainsi que les perspectives d’attaques liées au développement de l’informatique quantique, justifient d’engager dès à présent la transition vers une cryptographie post-quantique (Post-Quantum Cryptography – PQC).

La proposition de directive invite ainsi les États membres à intégrer, au sein de leur stratégie nationale de cybersécurité, des politiques de migration vers la PQC. Il s’agit d’anticiper un risque futur mais crédible, susceptible d’affecter des données sensibles, notamment industrielles, financières ou de santé.

Concrètement, ces politiques devraient s’accompagner d’outils permettant d’évaluer l’exposition des actifs cryptographiques aux capacités futures des ordinateurs quantiques. Elles impliqueraient également l’élaboration de plans de migration, la conduite d’expérimentations et le déploiement progressif de solutions de cryptographie post-quantique au sein des applications et des réseaux.

Ces orientations doivent s’articuler avec les travaux européens existants, en particulier la feuille de route coordonnée adoptée en juin 2025 par le groupe de coopération NIS, qui fixe un calendrier indicatif de transition : migration des cas d’usage critiques à l’horizon 2030, puis des usages de sensibilité moyenne ou faible d’ici 2035.

Cette approche rejoint les recommandations déjà formulées par l’Anssi^[6], laquelle préconise, pour les systèmes destinés à protéger durablement des informations — notamment au-delà de 2030 — la définition d’une stratégie de transition progressive et, lorsque cela est pertinent, le recours à des mécanismes hybrides intégrant des briques post-quantiques.

La proposition confirme ainsi une évolution de la politique européenne de cybersécurité : au-delà de la gestion des incidents actuels, elle intègre la préparation aux menaces futures.

En conclusion, au-delà d’un simple ajustement technique, cette initiative révèle une tension désormais classique du droit de la cybersécurité : concilier un niveau élevé d’exigence en matière de sécurité avec la capacité des organisations à appliquer la norme en pratique.

L’initiative est louable, et vise clairement à corriger certaines lourdeurs administratives de NIS2, mais son calendrier interroge, alors même que la directive n’est pas encore transposée dans plusieurs États membres, dont la France. Dans l’intervalle, les acteurs devront continuer à se conformer au cadre actuel tout en anticipant ses évolutions. Plus que jamais, l’enjeu sera d’adopter une lecture pragmatique des textes afin que la conformité ne devienne pas un frein à leurs activités.

 

Sources

1. Commission européenne, Proposition de directive du Parlement européen et du Conseil modifiant la directive (UE) 2022/2555 en ce qui concerne des mesures de simplification et l’alignement avec la proposition de règlement relatif à la cybersécurité (Cybersecurity Act 2), 20 janvier 2026.
2. Anssi, Simulateur NIS 2 : questionnaire d’auto-évaluation.
3. Commission européenne, Commission Recommendation (EU) 2025/1099 of 21 May 2025 on the definition of small mid-cap enterprises.
4. « European Digital Identity Wallets », tels que définis dans le règlement (UE) n° 910/2014.
5. Computer Security Incident Response Team, l’équipe chargée de la gestion et de la coordination des incidents de cybersécurité ; en France, le CSIRT national est le CERT-FR, opéré par l’Anssi.
6. Anssi, Avis sur la migration vers la cryptographie post-quantique.

 

À propos de l’auteur

Alexandra Iteanu est avocate au Barreau de Paris et responsable du pôle Data et RGPD du cabinet ITEANU Avocats. Elle est spécialisé dans les domaines du numérique,  de la cybersécurité, de la data  et de l’IA.

Une étude commandée par la DG CNECT de la Commission européenne offre un éclairage sur les orientations politiques et les choix stratégiques en matière de futures réglementations concernant l’économie fondée sur les données. Prospective et bonnes pratiques.

L’économie européenne des données connaît une mutation profonde, portée par l’essor de l’intelligence artificielle générative (IAG) et la nécessité croissante de conformité réglementaire, notamment en termes de protection des données à caractère personnel, de droit d’auteur et du respect des libertés et droits fondamentaux.

Une étude publiée en décembre et commandée par la Commission européenne met en lumière les enjeux juridiques et stratégiques de l’économie fondée sur les données. Il est toujours intéressant, en matière de prospective sur l’évolution du cadre réglementaire européen du numérique, d’examiner avec attention les études commandées par la Commission européenne, notamment par la DG CNECT, car elles offrent un éclairage précieux sur les orientations politiques et les choix stratégiques.

L’étude « sur les frontières des données à venir : l’IA générative, la conformité réglementaire et les dimensions internationales » explore l’évolution de l’économie des données, à travers trois axes : les besoins en données pour l’innovation et le rôle des données synthétiques ; l’utilisation de méthodes automatisées de conformité ; et la conciliation des approches internationales en matière de gouvernance des données.

Les points clés à retenir

• L’économie européenne des données est en transformation sous l’effet de l’intelligence artificielle générative et du renforcement des exigences réglementaires.
• L’Union européenne fait face à un enjeu de souveraineté numérique, notamment en matière d’accès à des données de qualité.
• La Stratégie pour une Union des données vise à faciliter l’accès à des données sectorielles et à encourager l’usage de données synthétiques.
• L’adoption des outils automatisés de conformité réglementaire reste hétérogène entre grandes entreprises et PME.
• La gouvernance des données en Europe repose sur une approche fondée sur les droits fondamentaux.
• Les organisations doivent mettre en place une gouvernance structurée des données intégrant gestion des risques et cybersécurité.

L’économie des données : un enjeu de souveraineté numérique européenne

Les auteurs de l’étude considèrent que, malgré une production scientifique significative, l’Union européenne demeure en retrait par rapport aux États-Unis et à la Chine en matière de développement de modèles fondamentaux et d’investissements. Le principal défi identifié est l’accès à des données de haute qualité, multilingues et sectorielles.

Pour les entreprises européennes d’IAG, les coûts d’acquisition, de traitement et de gestion des données représentent une charge souvent trop élevée, notamment en raison des frais de licence.

Pour soutenir l’innovation et la souveraineté numérique européenne, la Stratégie pour une Union des données (19 novembre 2025) vise à garantir l’accès à des données de qualité et à développer les espaces européens communs de données. Elle encourage également l’usage de données synthétiques, plus respectueuses de la vie privée.

Systèmes automatisés pour la conformité réglementaire : une adoption inégale

L’adoption des outils automatisés de conformité dans des secteurs critiques comme l’énergie, l’agriculture et la santé reste inégale.

Les grandes organisations utilisent des systèmes avancés (ERP, registres digitaux), permettant une traçabilité accrue des données. À l’inverse, les PME utilisent encore des méthodes traditionnelles, ce qui augmente les risques d’erreurs et la charge administrative.

Les obstacles identifiés sont principalement techniques et financiers : coûts élevés et manque d’interopérabilité des outils.

L’incarnation des valeurs européennes dans la gouvernance des données

L’étude analyse plusieurs modèles internationaux de gouvernance des données : approche fondée sur les droits (UE, avec le RGPD), approche de marché (États-Unis), approche étatique (Chine) ou hybride (Japon).

L’enjeu pour l’Union européenne est de développer une économie des données respectant les droits fondamentaux, tout en favorisant l’innovation et en préservant la souveraineté des données.

Cela implique de renforcer le cadre réglementaire européen et de consolider son rôle de référence internationale, notamment via les décisions d’adéquation et la régulation des flux internationaux de données.

Recommandations et bonnes pratiques

L’analyse de cette étude doit guider les organisations à adopter des pratiques adaptées :

• Mettre en place une gouvernance de la donnée intégrant cybersécurité, IA et conformité.
• Former les équipes aux enjeux de réglementation, cybersécurité et propriété intellectuelle.
• Se faire accompagner pour la mise en conformité (Règlement IA, Data Act, etc.) et la sécurisation des usages.
• Évaluer et documenter les risques liés à l’IA et aux données.
• Réaliser des audits réguliers pour assurer la conformité et adapter les politiques internes.

Il est primordial pour les organisations d’effectuer une veille réglementaire continue et d’adopter une stratégie intégrant une gouvernance responsable des données, afin de renforcer leur résilience dans un environnement numérique en constante évolution.

 

A propos de l’auteure

Eva ASPE est responsable des Affaires publiques et européennes chez Mathias Avocats, avec une expertise en droit du numérique et droit européen et international (IA, data & cybersécurité). Elles est coauteures avec François Gorriez et Garance Mathias de l’ouvrage récemment publié « IA, Cybersécurité, Data : Garantir votre conformité numérique » éditions Lexis Nexis.

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.

A noter que ces exigences documentaires devraient d’ailleurs s’alléger prochainement, la révision de la directive NIS2 proposant une harmonisation des demandes d’informations adressées aux sous-traitants.

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. Pour suivre les évolutions récentes du texte, la Commission européenne a publié début 2026 une proposition de modification de la directive NIS2 visant à en simplifier l’application.

 

À 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.

 

Les points clés à retenir sur l’Open Data et la cybersécurité

• L’Open Data repose sur un double droit : accès aux données publiques et réutilisation des informations.
• Dans le secteur public, il s’agit d’une obligation légale encadrée par le Code des relations entre le public et l’administration.
• L’ouverture des données est limitée par plusieurs impératifs : vie privée, sécurité nationale et propriété intellectuelle.
• Le RGPD (article 32) impose des mesures de sécurité adaptées pour tout traitement de données, y compris en contexte d’Open Data.
• Les réglementations européennes récentes (NIS 2, DORA) renforcent les exigences de gestion des risques cyber.
• Le data scraping illustre les tensions entre libre accès à l’information et respect des cadres juridiques existants.

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

Le cadre juridique de l’Open Data repose sur une construction progressive visant à organiser l’accès et la réutilisation des données publiques.

Les deux droits constitutifs de l’Open Data

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.

L’évolution législative du cadre de l’Open Data

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

L’essor de l’Open Data s’accompagne d’un renforcement des exigences en matière de cybersécurité et de protection des données.

L’augmentation des risques cyber et l’encadrement par le RGPD

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.

Le renforcement du cadre européen et le rôle des autorité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 cas du data scraping et ses risques juridiques

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.

Open Data et cybersécurité : vers un équilibre entre ouverture et protection

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.

À propos de l’auteure

Alexandra Iteanu est avocat au barreau de Paris et fondatrice du cabinet ITEANU. Elle intervient en droit du numérique, notamment en matière de protection des données personnelles, cybersécurité, contrats informatiques et responsabilité des acteurs du digital.

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.

Les points clés à retenir sur le règlement DORA et ses impacts

• Le règlement DORA vise à renforcer la résilience opérationnelle numérique des acteurs du secteur financier au sein de l’Union européenne.
• Il s’applique à un large périmètre incluant les institutions financières ainsi que leurs prestataires de services TIC.
• La mise en conformité repose sur cinq axes : gestion des risques, gestion des incidents, tests de résilience, partage d’informations et encadrement des tiers.
• Les exigences contractuelles sont renforcées, notamment en matière de continuité de service, audits et réversibilité des données.
• Les entreprises doivent structurer une gouvernance intégrant sécurité, documentation et suivi des prestataires.
• Pour les investisseurs, la conformité à DORA constitue un indicateur de maîtrise des risques numériques et de solidité organisationnelle.

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.

 

DORA : un indicateur clé de résilience pour les investisseurs

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.