Conformité des éditeurs de logiciels : les 5 réglementations à maîtriser

Pourquoi le secteur « Éditeurs de logiciels » est concerné

La densité réglementaire tient à la nature même du produit logiciel. Une fonctionnalité d’IA déclenche l’AI Act. L’hébergement et le traitement des données clients déclenchent le RGPD (sous-traitance) et le Data Act (portabilité, changement de fournisseur). La mise sur le marché du logiciel déclenche le CRA (sécurité dès la conception, correctifs, notification des vulnérabilités). Le statut de fournisseur de services numériques ou de gestion de services TIC déclenche NIS2 au-delà du seuil de taille.

Pour un éditeur qui compte des banques ou des assureurs parmi ses clients, une sixième couche s’ajoute : DORA, non pas directement, mais par voie contractuelle. Les entités financières doivent en effet encadrer leurs prestataires TIC critiques par des clauses spécifiques, et peuvent, pour les plus systémiques, faire l’objet d’une supervision directe.

Le risque, pour un éditeur, est de traiter ces textes séparément et de dupliquer les efforts. La stratégie payante consiste à identifier leur socle commun — sécurité de l’information, documentation, gestion des vulnérabilités, journalisation — puis à décliner les spécificités de chacun.

RGPD — l’éditeur comme sous-traitant

L’éditeur qui héberge ou traite les données personnelles de ses clients agit comme sous-traitant au sens du RGPD. Il doit offrir des garanties suffisantes, formaliser un contrat de sous-traitance (article 28) et encadrer les transferts hors Union européenne.

S’il détermine lui-même des finalités — analytics produit, prospection, entraînement de modèles sur les données clients — il devient responsable de traitement pour ces opérations et cumule alors les deux rôles.

Obligations clés

• DPA conforme à l’article 28 avec chaque client.
• Traitement des données sur seule instruction documentée.
• Encadrement des sous-traitants ultérieurs (hébergeur, sous-traitants).
• Encadrement des transferts hors UE (clauses contractuelles types).

AI Act — l’éditeur comme fournisseur d’IA

Dès qu’un système d’IA est intégré au produit et mis sur le marché sous la marque de l’éditeur, celui-ci est fournisseur et supporte les obligations les plus lourdes du texte : documentation technique (annexe IV), système de gestion des risques et de la qualité, transparence, évaluation de conformité et marquage.

L’intensité dépend du niveau de risque : un chatbot relève du risque limité, tandis qu’un module de scoring de personnes bascule en haut risque. Les modèles d’IA à usage général intégrés déclenchent des obligations de documentation propres.

Obligations clés

• Classification du système par niveau de risque.
• Documentation technique et système qualité.
• Transparence et supervision humaine.
• Surveillance après mise sur le marché (post-market).

NIS2 — l’éditeur comme fournisseur numérique

Au-delà du seuil « entité moyenne » (≥ 50 salariés ou > 10 M€), l’éditeur fournissant des services numériques ou de gestion de services TIC relève des entités importantes de NIS2 : mesures de gestion des risques cyber, notification des incidents, sécurité de la chaîne d’approvisionnement et responsabilité de la direction.

En deçà du seuil, l’exigence retombe fréquemment par ricochet, via les clauses des clients eux-mêmes soumis à NIS2.

Obligations clés

• Mesures techniques et organisationnelles de gestion des risques (art. 21).
• Notification des incidents significatifs (alerte précoce puis rapport).
• Sécurisation de la chaîne d’approvisionnement logicielle.
• Validation et suivi du dispositif par la direction.

Data Act — accès aux données et portabilité

Le Data Act (règlement UE 2023/2854) impose aux services de traitement de données (cloud, SaaS, PaaS, IaaS) de faciliter le changement de fournisseur, la portabilité et l’interopérabilité, et interdit certaines clauses contractuelles abusives sur le partage de données.

Pour les éditeurs de produits connectés, il ouvre en outre un droit d’accès des utilisateurs aux données générées par le produit et son service associé.

Obligations clés

• Mécanismes de portabilité et d’export des données.
• Suppression progressive des frais de changement de fournisseur.
• Révision des clauses abusives sur le partage de données.
• Information des utilisateurs sur les données générées et leurs droits.

CRA — sécurité des produits à éléments numériques

Le Cyber Resilience Act (règlement UE 2024/2847) impose aux fabricants de produits à éléments numériques — dont les logiciels — la sécurité dès la conception et par défaut, la gestion des vulnérabilités, la fourniture de correctifs pendant la période de support et la notification des vulnérabilités activement exploitées.

Il aboutit à un marquage CE cybersécurité conditionnant la mise sur le marché européen. Des régimes particuliers existent pour l’open source non commercial.

Obligations clés

• Sécurité « by design » et « by default ».
• Processus de gestion et de divulgation des vulnérabilités.
• Nomenclature des composants logiciels (SBOM).
• Notification des vulnérabilités exploitées et des incidents graves.

Vue comparée des réglementations

Comment ces réglementations s’articulent

Ces cinq textes se recoupent massivement sur la sécurité et la documentation. Un même investissement d’ingénierie — développement sécurisé, journalisation, gestion des vulnérabilités, cartographie des composants — sert simultanément le RGPD (article 32, sécurité), le CRA (exigences essentielles) et NIS2 (mesures de gestion des risques). De même, la documentation technique de l’AI Act et les registres du RGPD partagent une bonne partie de leur matière.

La démarche gagnante est donc de bâtir un socle unique de conformité produit — politique de sécurité, SBOM, PSIRT (gestion des vulnérabilités), registre des traitements et des systèmes d’IA — puis de décliner les obligations spécifiques : marquage AI Act, notification CRA à l’ENISA, clauses de portabilité Data Act. Traiter chaque texte isolément revient à refaire cinq fois la même cartographie.

Calendrier d’application

• 1RGPD. En vigueur depuis mai 2018.
• 2DORA. Applicable depuis le 17 janvier 2025 (impacte l’éditeur via ses clients financiers).
• 3AI Act. Interdictions depuis février 2025 ; GPAI depuis août 2025 ; haut risque à partir d’août 2026.
• 4Data Act. Obligations majoritaires applicables depuis le 12 septembre 2025.
• 5CRA. Entré en vigueur fin 2024 ; obligations de notification puis exigences complètes à horizon 2026-2027.
• 6NIS2. Transposition en droit français en cours de finalisation ; anticiper les obligations dès maintenant.

Sanctions encourues

Les plafonds varient selon les textes mais sont tous dissuasifs. RGPD : jusqu’à 20 M€ ou 4 % du CA mondial. AI Act : jusqu’à 35 M€ ou 7 %. CRA : jusqu’à 15 M€ ou 2,5 %. NIS2 : jusqu’à 10 M€ ou 2 % pour les entités importantes, avec responsabilité personnelle possible des dirigeants. Data Act : sanctions fixées par chaque État membre, avec un alignement possible sur les plafonds RGPD.

Pour un éditeur, le risque financier se double d’un risque commercial : un défaut de conformité NIS2 ou CRA peut devenir bloquant dans les appels d’offres, et un incident non maîtrisé se propage en cascade à toute la base de clients.

Feuille de route de mise en conformité

• 1Cartographier le produit. Recenser les données traitées, les composants logiciels (SBOM), les briques d’IA et les dépendances tierces.
• 2Bâtir le socle sécurité. Formaliser une politique de sécurité, la gestion des vulnérabilités (PSIRT) et la journalisation, qui servent RGPD, CRA et NIS2.
• 3Documenter par texte. Produire les livrables spécifiques : DPA type, documentation technique AI Act, mesures NIS2, clauses de portabilité Data Act, déclaration de conformité CRA.
• 4Organiser la notification. Mettre en place des procédures d’incident distinctes mais coordonnées (violation RGPD sous 72 h, incident NIS2, vulnérabilité CRA à l’ENISA).
• 5Piloter et auditer. Impliquer la direction, désigner DPO et RSSI (internes ou externalisés) et instaurer une revue périodique.

Comment Data Comply One accompagne le secteur

Data Comply One centralise le RGPD, l’AI Act, NIS2 et DORA sur une seule plateforme, avec un DPO et un RSSI externalisés. Pour un éditeur, cela évite de multiplier les prestataires et de refaire cinq fois la même cartographie : un socle commun, des livrables prêts à l’audit et un suivi des échéances.

DCO édite par ailleurs une bibliothèque de modèles documentaires (registres, DPA, documentation AI Act, procédures d’incident) directement mobilisables par les éditeurs pour accélérer leur mise en conformité.

Questions fréquentes