# NIS2, DORA et scripts tiers sur vos applications web clients (/fr/blog/nis2-dora-third-party-scripts) Une page de connexion ou de paiement ordinaire charge du code venu d'un gestionnaire de balises, d'un outil d'analyse d'audience, d'un widget de chat, d'un bandeau de consentement et d'un prestataire de paiement. Chacun de ces scripts s'exécute dans le navigateur de votre client avec les mêmes droits que votre propre code : il peut lire la page, la modifier et envoyer des données ailleurs. Quand une équipe sécurité cartographie ses fournisseurs pour NIS2 ou DORA, ces scripts passent facilement sous le radar, parce qu'ils ne touchent jamais vos serveurs. Cet article expose ce que disent les deux textes, ce qu'ils ne disent pas, et quels contrôles permettent de prouver que les scripts tiers sont maîtrisés. Les citations viennent d'EUR-Lex, pour que vous puissiez tout vérifier. *Il s'agit d'une information générale, pas d'un conseil juridique. Savoir si vous êtes concerné, et comment votre droit national transpose NIS2, relève de votre service juridique.* Pour obtenir l'inventaire des scripts qui s'exécutent réellement sur vos pages, [le monitoring CentralCSP](/platform/monitoring) le construit à partir des rapports du navigateur, sans agent. [Le plan Start inclut un essai gratuit de 14 jours](/register). ## Ce que les textes ne disent pas [#ce-que-les-textes-ne-disent-pas] Commençons par là, car beaucoup de contenus d'éditeurs en rajoutent : * **Ni NIS2 ni DORA ne mentionnent la Content Security Policy, les navigateurs ou le JavaScript tiers.** Les deux textes sont neutres sur le plan technologique et fondés sur les risques. * **Aucun n'impose d'outil particulier.** NIS2 demande des mesures « appropriées et proportionnées » au risque ([article 21, paragraphe 1](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022L2555)) ; DORA applique le principe de proportionnalité au risque lié aux prestataires tiers ([article 28, paragraphe 1, point b)](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022R2554)). * **Aucun n'impose un hébergement dans l'UE.** DORA exige que le contrat indique où les données sont traitées et stockées ; NIS2 demande d'évaluer les fournisseurs. Aucun n'interdit un prestataire hors UE. Ce qu'ils exigent, c'est de connaître vos fournisseurs et vos actifs, de gérer le risque qu'ils apportent, et de pouvoir le démontrer. Les scripts tiers sont des fournisseurs et des actifs comme les autres : c'est là qu'interviennent les contrôles décrits plus bas. ## NIS2 : chaîne d'approvisionnement, développement et gestion des actifs [#nis2--chaîne-dapprovisionnement-développement-et-gestion-des-actifs] NIS2 ([directive (UE) 2022/2555](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022L2555)) s'applique aux entités essentielles et importantes des secteurs qu'elle liste, par l'intermédiaire des lois nationales de transposition, que les États membres devaient appliquer à partir du 18 octobre 2024 (article 41). L'article 21, paragraphe 2, liste les mesures minimales. Trois d'entre elles concernent les scripts des applications web : * **d) la sécurité de la chaîne d'approvisionnement**, « y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs ». Le paragraphe 3 ajoute que les entités tiennent compte « des vulnérabilités propres à chaque fournisseur et prestataire de services direct et de la qualité globale des produits et des pratiques de cybersécurité de leurs fournisseurs ». * **e) la sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités.** Ajouter le script d'un fournisseur sur une page en production, c'est une acquisition et une modification de votre système. * **i) la sécurité des ressources humaines, des politiques de contrôle d'accès et la gestion des actifs.** L'article 20, paragraphe 1, impose aux organes de direction d'approuver ces mesures et d'en superviser la mise en œuvre. Pour certains fournisseurs numériques (cloud, centres de données, CDN, services gérés et services de sécurité gérés, places de marché en ligne, moteurs de recherche, réseaux sociaux, services de confiance, DNS et registres de noms de domaine de premier niveau), le [règlement d'exécution (UE) 2024/2690](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R2690) détaille ces mesures. Son annexe exige notamment : * une **politique de sécurité de la chaîne d'approvisionnement** avec des critères de sélection des fournisseurs, dont « les pratiques des fournisseurs et des prestataires de services en matière de cybersécurité » (point 5.1.2) ; * un **annuaire des fournisseurs et des prestataires de services**, avec les points de contact et « une liste des produits TIC, services TIC et processus TIC » fournis par chacun (point 5.2) ; * le **traitement des vulnérabilités** : s'informer sur les vulnérabilités, réaliser des analyses si nécessaire, traiter sans retard injustifié celles jugées critiques (point 6.10) ; * un **inventaire des actifs** « complet, précis, actualisé et cohérent », dont les modifications sont enregistrées « de manière traçable » (point 12.4). Si vous êtes une place de marché en ligne visée par ce règlement, les scripts de votre vitrine ont leur place dans l'annuaire et dans l'inventaire. Si vous êtes une autre entité NIS2, ce règlement ne vous lie pas, mais il donne une lecture utile de ce qu'attend l'article 21. ## DORA : risque lié aux prestataires TIC, registre et clauses contractuelles [#dora--risque-lié-aux-prestataires-tic-registre-et-clauses-contractuelles] DORA ([règlement (UE) 2022/2554](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022R2554)) s'applique aux entités financières de l'UE depuis le 17 janvier 2025. Il définit largement les services TIC : « les services numériques et de données fournis de manière permanente par l'intermédiaire des systèmes de TIC à un ou plusieurs utilisateurs internes ou externes » (article 3, point 21). Un service d'analyse, de chat, de lutte contre la fraude ou de gestion du consentement, sous contrat, dont le script tourne sur vos pages de banque en ligne, en est très probablement un. Quatre articles comptent ici : * **Article 8, identification.** Les entités financières identifient, classent et documentent « les actifs informationnels et les actifs de TIC » qui soutiennent leurs fonctions, « ainsi que leurs rôles et dépendances en ce qui concerne le risque lié aux TIC ». Les scripts de vos applications clients font partie de ce tableau. * **Article 28, paragraphe 1, risque lié aux prestataires.** Ce risque est géré « en tant que partie intégrante du risque lié aux TIC », et les entités financières qui recourent à des services TIC « restent à tout moment pleinement responsables » du respect de leurs obligations. * **Article 28, paragraphe 3, registre d'informations.** Un registre portant sur tous les accords contractuels relatifs à l'utilisation de services TIC fournis par des prestataires tiers. Les modèles du [règlement d'exécution (UE) 2024/2956](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R2956) demandent le pays de stockage des données (B_02.02.0150, exigé quand un service qui soutient une fonction critique ou importante stocke des données) et le pays où elles sont traitées (B_02.02.0160, exigé dès que le service traite des données). * **Article 30, paragraphe 2, clauses contractuelles.** Tout contrat TIC comporte notamment « les lieux, notamment les régions ou les pays, où les services TIC et fonctions visés par le contrat ou la sous-traitance seront fournis et où les données seront traitées, y compris le lieu de stockage », avec information préalable en cas de changement (point b), ainsi que des dispositions sur la protection des données, y compris personnelles (point c). Un éditeur de script qui collecte des données dans le navigateur de vos clients les traite quelque part. DORA veut que ce lieu figure dans le contrat. ## Le trou dans la raquette : les scripts que personne n'a contractés [#le-trou-dans-la-raquette--les-scripts-que-personne-na-contractés] Les registres fournisseurs se construisent à partir des contrats. Les scripts arrivent par d'autres chemins : * **Les scripts de quatrième partie.** Votre gestionnaire de balises ou le script d'un fournisseur en charge d'autres, que vous n'avez jamais choisis. * **Les CDN publics et gratuits.** Une bibliothèque tirée d'un CDN public n'a ni contrat ni interlocuteur, mais elle s'exécute sur votre page. * **Les changements côté marketing.** Un nouveau pixel ajouté par le gestionnaire de balises ne passe pas par les achats. Rien de tout cela n'apparaît dans un registre fondé sur les contrats. Tout cela apparaît dans le navigateur. C'est pourquoi un inventaire construit à partir de ce que chargent réellement les navigateurs est le point de départ pour les deux textes. ## Les contrôles et les preuves qu'ils produisent [#les-contrôles-et-les-preuves-quils-produisent] Le tableau relie des contrôles côté client courants aux dispositions qu'ils aident à démontrer. Cette correspondance est la nôtre, pas celle des régulateurs : les textes fixent des objectifs, pas ces contrôles. | Contrôle | Ce qu'il apporte | Aide à démontrer | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | **Inventaire des scripts par page**, construit à partir du trafic réel | La liste de chaque script et origine exécutés, avec leur date d'apparition | NIS2 art. 21, § 2, i), gestion des actifs ; 2024/2690 point 12.4 ; DORA art. 8 | | **Rattacher chaque script à un fournisseur** et, s'il existe, à un contrat | Les scripts couverts par l'annuaire ou le registre, et ceux qui ne le sont pas | NIS2 art. 21, § 2, d) ; 2024/2690 point 5.2 ; DORA art. 28, § 3 | | **[Content Security Policy](/fr/docs/web-security/policies/content-security-policy)** limitant les origines autorisées à charger des scripts et à recevoir des données | Une liste d'autorisation écrite et appliquée des sources de scripts et de connexions | NIS2 art. 21, § 2, e) | | **Rapports de violation CSP et alertes sur les changements** | Une trace des tentatives de chargement hors liste, et une alerte quand un nouveau script apparaît | NIS2 art. 21, § 2, b), gestion des incidents, et e) ; DORA art. 28, § 1, gestion continue du risque | | **[Subresource Integrity](/fr/blog/subresource-integrity-sri)** sur les fichiers tiers statiques | La preuve qu'un fichier n'a pas changé depuis votre revue | NIS2 art. 21, § 2, d) et e) | | **Surveillance des bibliothèques et des CVE** pour les scripts inventoriés | Les vulnérabilités connues des versions que vous servez | NIS2 art. 21, § 2, e), traitement des vulnérabilités ; 2024/2690 point 6.10 | | **Localisation des données de chaque éditeur de script** | Où chaque éditeur traite les données que collecte son script | DORA art. 30, § 2, b) ; règles de transfert du RGPD | | **Traces de revue** (qui a validé un script, quand, pourquoi) | Des décisions traçables pour un auditeur ou une autorité de contrôle | NIS2 art. 20, § 1, supervision ; 2024/2690 point 12.4.1, traçabilité | Si vous traitez aussi des paiements par carte, ce sont les mêmes contrôles que PCI DSS v4 demande sur les pages de paiement avec les exigences 6.4.3 et 11.6.1. Un seul inventaire peut servir les trois cadres. Le [guide PCI DSS 6.4.3](/fr/blog/pci-dss-6-4-3) couvre ce volet. ## Une démarche concrète [#une-démarche-concrète] 1. **Commencez en report-only.** Déployez un header [Content-Security-Policy-Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only) avec [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) sur vos applications clients. Rien ne casse, et les rapports montrent ce qui se charge. 2. **Construisez l'inventaire à partir des rapports.** Chaque origine et chaque script, par page, avec les [rapports de hash CSP](/fr/docs/web-security/reporting-api/reports/csp-hash) pour identifier chaque script externe, scripts internes compris, par le hash de son contenu. Les scripts inline ne font pas l'objet de rapports de hash : passez-les en revue dans vos propres gabarits. 3. **Rapprochez avec les achats.** Associez chaque script à un fournisseur, et chaque fournisseur à un contrat et à une ligne du registre. Ce qui reste, ce sont vos fournisseurs fantômes. 4. **Décidez script par script :** garder et contractualiser, remplacer, auto-héberger avec SRI, ou supprimer. 5. **Appliquez la politique** une fois l'inventaire stabilisé, et laissez le reporting actif. 6. **Alertez sur les changements** des pages sensibles (connexion, espace client, paiement), et conservez les traces de revue. Votre outil de reporting CSP est lui-même un prestataire TIC. Inscrivez-le au registre avec ses lieux de traitement, et lisez [reporting CSP et hébergement des données dans l'UE](/fr/blog/csp-reporting-eu-data-residency) pour les questions à lui poser. ## La place de CentralCSP [#la-place-de-centralcsp] CentralCSP transforme les rapports du navigateur en inventaire et en preuves : * un [inventaire des scripts](/fr/docs/platform/features/script-inventory) par page à partir des rapports de hash CSP, avec des décisions de revue consignées dans un [registre des changements](/fr/docs/platform/features/pci-dss/justifying-scripts) conservé jusqu'à la suppression du compte ; * un [inventaire des technologies](/fr/docs/platform/features/technologies) qui identifie la bibliothèque et la version derrière chaque script et signale les CVE connues ; * un [constructeur de CSP](/fr/docs/platform/features/builders/csp) qui rédige la politique à partir du trafic réel ; * des [règles d'alerte](/fr/docs/platform/features/alerting) sur les nouveaux scripts, nouvelles origines et changements de hash, vers Slack, Teams, Google Chat, Telegram, e-mail ou webhook ; * pour votre propre registre fournisseurs : données stockées et sauvegardées chez OVHcloud en France, périphérie de collecte limitée à des points de présence européens, et préavis de 30 jours avant tout nouveau sous-traitant. CentralCSP ne vous rend pas conforme à NIS2 ou à DORA, et ne détient pas de certification ISO 27001 ni SOC 2. Il vous donne l'inventaire, les alertes et les traces qui montrent que vos mesures fonctionnent. ## Sources [#sources] * [Directive (UE) 2022/2555 (NIS2)](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022L2555), articles 20, 21 et 41 * [Règlement d'exécution (UE) 2024/2690](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R2690), article 1 et annexe, points 5.1, 5.2, 6.10 et 12.4 * [Règlement (UE) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022R2554), articles 3, 8, 28, 30 et 64 * [Règlement d'exécution (UE) 2024/2956, modèles du registre d'informations](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R2956) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/) ## Articles liés [#articles-liés] * [Reporting CSP et hébergement des données dans l'UE](/fr/blog/csp-reporting-eu-data-residency) * [Rapports CSP, données personnelles et RGPD](/fr/blog/csp-reports-personal-data-gdpr) * [PCI DSS 6.4.3 : gérer les scripts des pages de paiement](/fr/blog/pci-dss-6-4-3) * [Inventaire des scripts](/fr/blog/script-inventory)