Azais Khalsi

La cybersécurité de la chaîne d’approvisionnement est devenue l’un des points les plus sensibles du droit européen du numérique. L’idée de départ est simple, mais juridiquement redoutable : une organisation peut avoir sécurisé son périmètre interne, tout en restant gravement vulnérable par ses dépendances techniques, logicielles, cloud, infogérées ou open source. Les attaques dites supply chain déplacent donc la question de la responsabilité. Le risque n’est plus seulement celui d’une défaillance du système principal, mais celui d’une compromission propagée par un fournisseur, un prestataire, un composant logiciel ou un environnement de maintenance. NIS2 a pleinement intégré cette mutation en faisant de la sécurité de la chaîne d’approvisionnement une obligation juridique explicite. (EUR-Lex)

Le texte central est ici l’article 21 §2 d) de la directive NIS2. Il impose, parmi les mesures minimales de gestion des risques, 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 directs ou prestataires de services. Cette formulation est capitale pour deux raisons. D’abord, elle montre que la chaîne d’approvisionnement n’est plus un sujet périphérique de “bonne pratique” technique, mais une obligation réglementaire formelle. Ensuite, elle insiste explicitement sur les relations entre l’entité régulée et ses fournisseurs directs ou prestataires, ce qui veut dire que la cybersécurité supply chain devient aussi une question de gouvernance contractuelle, de sélection, d’audit, de suivi et de preuve. (EUR-Lex)

Il faut immédiatement éviter un malentendu. NIS2 ne crée pas une responsabilité automatique et générale du fournisseur pour toute compromission affectant un client. Le mécanisme est plus subtil. La directive impose d’abord aux entités essentielles et entités importantes de tenir compte du risque fournisseur dans leur propre dispositif de conformité. En d’autres termes, le droit européen ne dit pas seulement au fournisseur “soyez sûr” ; il dit aussi à l’entité assujettie “vous devez gouverner juridiquement et opérationnellement le risque né de vos dépendances”. La responsabilité devient donc partagée mais non symétrique : le fournisseur peut être à l’origine du risque, mais l’entité régulée demeure tenue de démontrer qu’elle l’a identifié, évalué, encadré et surveillé. (EUR-Lex)

C’est précisément là que la logique de NIS2 rejoint la transformation générale du droit européen de la cybersécurité : on passe d’un droit de la protection interne à un droit de la résilience écosystémique. La sécurité ne se mesure plus seulement à la robustesse du système central, mais à la robustesse de ses dépendances. Cela implique une extension de la diligence juridique : questionnaires fournisseurs, clauses de sécurité, exigences d’escalade incident, auditabilité, gestion des vulnérabilités, information sur les sous-traitants critiques, maîtrise des mises à jour, parfois même stratégie de dépendance et de substituabilité. Cette lecture est une inférence juridique, mais elle est directement soutenue par la structure de l’article 21 et par l’économie générale de NIS2. (EUR-Lex)

Le Cyber Resilience Act ajoute une strate complémentaire. Là où NIS2 agit surtout au niveau de la gouvernance des entités et de la gestion du risque cyber, le CRA agit au niveau des produits comportant des éléments numériques. Le CRA est entré en vigueur le 10 décembre 2024. La Commission européenne indique que ses obligations principales s’appliqueront à partir du 11 décembre 2027, tandis que les obligations de notification liées aux vulnérabilités exploitées et incidents sévères s’appliqueront dès le 11 septembre 2026. Le règlement impose notamment que les produits numériques soient conçus, développés et maintenus avec un niveau approprié de cybersécurité, y compris sur la durée de vie du produit. (Stratégie numérique européenne)

L’articulation entre NIS2 et CRA est essentielle pour la chaîne d’approvisionnement. NIS2 regarde l’entité régulée et sa gouvernance du risque fournisseur. Le CRA regarde davantage le fabricant ou l’acteur mettant sur le marché un produit numérique, en lui imposant des exigences de sécurité dès la conception, de gestion des vulnérabilités et d’information. Autrement dit, NIS2 gouverne la relation de dépendance ; le CRA gouverne davantage la qualité cyber du produit ou composant. Les deux textes convergent vers une même idée : la sécurité de la supply chain ne peut plus être abandonnée à la pure liberté contractuelle ou à la simple confiance technique. (EUR-Lex)

Juridiquement, la responsabilité dans les attaques supply chain peut se déployer sur plusieurs plans.

Le premier est le plan réglementaire. Une entité NIS2 qui ne prend pas en compte ses dépendances critiques, n’encadre pas ses prestataires, ou ne documente pas ses choix fournisseurs, s’expose à une critique de non-conformité, même si l’incident initial est né chez un tiers. Le raisonnement est ici proche de celui qu’on observe déjà en matière de protection des données ou de conformité anticorruption : l’externalisation n’externalise pas la responsabilité de gouvernance. (EUR-Lex)

Le deuxième est le plan contractuel. En cas d’attaque supply chain, une part majeure du contentieux potentiel se joue dans le contrat : engagements de sécurité, garanties, SLA, audits, obligations de notification, limites de responsabilité, exclusions, sous-traitance en cascade, obligations de patching, support de sécurité, coopération en réponse à incident. NIS2 n’écrit pas ces clauses à la place des parties, mais elle modifie fortement le standard de diligence attendu. Une clause très faible ou silencieuse peut devenir juridiquement difficile à défendre dans un environnement où le droit positif exige explicitement la prise en compte de la chaîne d’approvisionnement. Cette conclusion est une inférence, mais elle découle logiquement de l’opposabilité croissante des standards cyber. (EUR-Lex)

Le troisième est le plan délictuel ou quasi-délictuel, selon les ordres juridiques. Si un fournisseur a commis une faute de sécurité caractérisée, ou a induit ses clients en erreur sur son niveau de sécurité, une responsabilité extra-contractuelle peut être discutée. Mais ce terrain est souvent plus difficile à établir, car il suppose de démontrer faute, causalité, dommage et parfois prévisibilité. Dans les grandes attaques supply chain, la difficulté n’est pas seulement de trouver un “responsable moral”, mais de transformer cette intuition en chaîne juridique probante.

C’est ici qu’il faut être rigoureux sur SolarWinds. Parler de “jurisprudence SolarWinds” est possible seulement à condition de préciser qu’il ne s’agit pas d’une jurisprudence européenne de responsabilité supply chain au sens classique, mais surtout d’un contentieux américain en droit boursier et des disclosures cyber. En 2024, un juge fédéral a rejeté l’essentiel de l’action de la SEC contre SolarWinds, ne laissant survivre qu’une partie très limitée du dossier liée à une déclaration sur le site de l’entreprise ; puis, en novembre 2025, la SEC a finalement demandé le rejet avec préjudice de l’affaire restante. Cela signifie que SolarWinds n’a pas produit, à ce stade, un grand précédent judiciaire établissant une responsabilité générale du fournisseur pour attaque supply chain. Le cas est néanmoins précieux, car il révèle autre chose : le risque contentieux lié aux déclarations de sécurité, à la gouvernance cyber et à la communication sur le niveau réel de protection. (SEC)

La leçon SolarWinds n’est donc pas “un fournisseur est automatiquement responsable lorsqu’il devient le vecteur d’une compromission massive”. La leçon est plus fine : lorsqu’un fournisseur occupe une place systémique dans la chaîne logicielle, sa gouvernance de sécurité, sa documentation, sa communication et ses processus internes deviennent eux-mêmes des objets de contrôle juridique. Cela intéresse directement l’Europe, même si l’affaire est américaine, car NIS2 et le CRA poussent justement dans cette direction : transformer la sécurité fournisseur en sujet de gouvernance démontrable et non plus en simple promesse commerciale. Cette lecture est une inférence comparative solidement appuyée par la trajectoire réglementaire européenne et par le contentieux SolarWinds. (SEC)

Le cas XZ Utils va dans une autre direction, peut-être encore plus instructive pour le droit européen. Ici, nous ne sommes pas face à une grande entreprise cotée dont la plateforme est compromise, mais face à une attaque de longue haleine sur un composant open source, conduite par infiltration progressive de la chaîne de confiance du projet. CISA a décrit l’affaire comme une compromission de chaîne d’approvisionnement affectant la bibliothèque de compression XZ Utils, avec insertion d’une porte dérobée dans les versions 5.6.0 et 5.6.1, avant que l’incident ne soit rapidement détecté et contenu. CISA a ensuite souligné que cette affaire mettait en lumière la fragilité structurelle de l’écosystème open source et la nécessité d’un écosystème plus soutenable. (CISA)

Sur le plan juridique, XZ Utils est fascinant parce qu’il montre les limites d’une lecture purement bilatérale fournisseur/client. Dans l’open source, surtout lorsque le projet repose sur peu de mainteneurs, la notion de “fournisseur” devient floue. Qui est responsable ? Le mainteneur ? Le distributeur ? L’intégrateur ? Le fabricant qui embarque la bibliothèque ? L’éditeur qui la redistribue ? Le client final qui l’utilise ? Le droit européen commence à affronter cette difficulté. Le CRA, justement, a dû intégrer des dispositions spécifiques pour tenir compte du rôle particulier de l’open source et éviter un écrasement pur et simple de ses acteurs. Mais l’affaire XZ Utils montre déjà que la chaîne d’approvisionnement moderne ne se limite pas aux prestataires contractuellement identifiés ; elle comprend aussi des dépendances diffuses, communautaires, parfois peu gouvernées. (Stratégie numérique européenne)

La responsabilité juridique, dans ce contexte, devient stratifiée.

Il existe d’abord une responsabilité de qualification et de cartographie : une entité assujettie doit savoir de quoi elle dépend, y compris indirectement sur les couches logicielles sensibles. NIS2 pousse clairement dans ce sens par sa logique supply chain. (EUR-Lex)

Il existe ensuite une responsabilité d’intégration et de sélection : choisir un composant ou un prestataire sans évaluation minimale du risque, sans vision sur la maintenance, les vulnérabilités connues, les mécanismes de correctif ou la criticité fonctionnelle devient de plus en plus difficile à justifier.

Il existe aussi une responsabilité de réaction : lorsqu’une faille ou compromission supply chain est détectée, la rapidité de mitigation, d’escalade, de retrait, de communication et de patching devient elle-même juridiquement significative.

Enfin, il existe une responsabilité de représentation : promettre ou afficher un niveau de sécurité supérieur à ce qui est réellement mis en œuvre peut exposer à un contentieux spécifique, comme l’a montré le dossier SolarWinds sur le terrain américain. (SEC)

Dans ce cadre, l’article 21 §2 d) de NIS2 doit être lu comme une norme de diligence renforcée. Il n’impose pas l’impossible ; il n’exige pas de garantir l’absence absolue de compromission chez tous les fournisseurs. En revanche, il impose d’être capable de démontrer une gestion raisonnable, structurée et proportionnée du risque fournisseur. Cela peut inclure, selon les cas, la segmentation des dépendances critiques, l’analyse des accès privilégiés, la revue des processus de build et de mise à jour, l’évaluation des sous-traitants en cascade, les exigences de notification d’incident, l’encadrement des environnements de maintenance, les SBOM quand ils sont pertinents, et la vérification des processus de gestion des vulnérabilités. Cette liste relève d’une déduction juridique et opérationnelle cohérente avec le texte, même si la directive elle-même reste technologiquement neutre. (EUR-Lex)

Il faut aussi souligner que la responsabilité n’est pas identique selon que l’on parle d’un fournisseur direct, d’un prestataire de service, d’un éditeur logiciel, d’un intégrateur, ou d’un composant open source embarqué indirectement. L’article 21 §2 d) vise explicitement les relations avec les fournisseurs directs et prestataires de services, ce qui donne une prise normative immédiate sur le premier cercle. Mais les incidents modernes montrent que le risque surgit souvent plus loin dans la chaîne. Le vrai défi juridique des prochaines années sera donc d’étendre, sans le déformer, le raisonnement de diligence à des chaînes de dépendance beaucoup plus profondes. C’est probablement l’un des chantiers majeurs de la compliance cyber européenne. (EUR-Lex)

En définitive, trois enseignements se dégagent.

Premièrement, NIS2 fait entrer la chaîne d’approvisionnement dans le cœur dur de la conformité cyber, par l’article 21 §2 d). (EUR-Lex)

Deuxièmement, le CRA complète cette logique en imposant des exigences de sécurité aux produits numériques eux-mêmes, avec entrée en vigueur le 10 décembre 2024, obligations de reporting dès le 11 septembre 2026 et principales obligations à compter du 11 décembre 2027. (Stratégie numérique européenne)

Troisièmement, SolarWinds et XZ Utils ne fournissent pas une jurisprudence simple de responsabilité fournisseur, mais deux leçons distinctes : SolarWinds sur la gouvernance, les déclarations et l’exposition contentieuse du fournisseur systémique ; XZ Utils sur la fragilité juridique et opérationnelle des dépendances open source profondes. (SEC)

La conclusion de fond est claire : dans les attaques supply chain, la question n’est plus seulement “qui a été compromis ?”, mais “qui devait prévoir, cartographier, encadrer, surveiller et documenter cette dépendance ?”. C’est là que se déplace aujourd’hui, sous l’effet de NIS2 et du CRA, la véritable responsabilité juridique de la chaîne d’approvisionnement. (EUR-Lex)