Chaîne d'approvisionnement

Pourquoi la chaîne d'approvisionnement change la donne

Une entité essentielle ou importante au sens de NIS2 ne maîtrise jamais seule son niveau de risque. Elle délègue une part croissante de son système d'information à des prestataires : hébergeur cloud, éditeur de logiciel métier, infogéreur, mainteneur d'automates industriels. Chacun de ces tiers devient un point d'entrée potentiel vers le système d'information de l'entité, sans que celle-ci en garde toujours une visibilité directe.

L'article 21 de la directive NIS2 rend cette réalité explicite : la sécurité de la chaîne d'approvisionnement figure parmi les dix mesures minimales que doit couvrir la politique de gestion des risques. Le référentiel ReCyF, qui décline ces obligations en droit français, ne se contente pas de demander « sécurisez vos fournisseurs » — il exige une démarche traçable : identification des fournisseurs critiques, évaluation de leur niveau de sécurité, clauses contractuelles adaptées, et réexamen périodique.

Les incidents majeurs des dernières années — compromission de SolarWinds en 2020, exploitation de la vulnérabilité Kaseya VSA en 2021, faille MOVEit Transfer en 2023 — partagent un point commun : l'attaquant n'a pas visé directement les victimes finales. Il a compromis un fournisseur commun à des centaines, parfois des milliers d'organisations, et a propagé l'accès en aval. C'est ce risque de propagation par ricochet que la réglementation cherche à réduire.

Le périmètre de « fournisseur TIC » est plus large qu'il n'y paraît au premier abord. Il couvre le matériel, le logiciel, les services managés, le cloud, la téléphonie et les réseaux, la maintenance à distance et l'intégration de systèmes. Chaque catégorie appelle une vigilance différente : un éditeur de logiciel injecte du code dans votre système d'information en continu via ses mises à jour automatiques ; un hébergeur cloud détient vos donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, en clair ou chiffrées selon la configuration retenue ; un prestataire de maintenance à distance dispose souvent d'un accès VPNVPNRéseauxRéseau privé virtuel qui chiffre le trafic entre deux points sur un réseau public. Il crée un tunnel sécurisé permettant d'accéder à des ressources distantes comme si on était sur le réseau local.Voir dans le glossaire permanent, plus difficile à surveiller qu'un accès ponctuel et tracé.

L'obligation de sécuriser la chaîne d'approvisionnement ne se limite pas aux fournisseurs directs (rang 1). NIS2 attend une visibilité sur les sous-traitants de vos prestataires (rang 2, rang 3) dès lors qu'ils ont un accès significatif à vos données ou à votre système d'information. C'est un changement de posture : la responsabilité contractuelle s'arrête à votre fournisseur direct, la responsabilité réglementaire non.

Cartographie des fournisseurs critiques

Avant toute clause contractuelle, il faut savoir qui sont vos fournisseurs critiques. La cartographie répond à quatre questions pour chaque prestataire TIC :

• Quel accès a-t-il ? — accès réseau, accès aux données, droits d'administration, présence physique dans les locaux.
• Quelle est la criticité du service rendu ? — un arrêt du service compromet-il une fonction essentielle de l'entité ?
• Quelle est sa substituabilité ? — combien de temps faudrait-il pour changer de fournisseur, et à quel coût opérationnel ?
• Quelle est sa propre exposition ? — a-t-il lui-même des sous-traitants critiques, une dépendance à un cloud unique, un historique d'incidents ?

Cette cartographie doit être formalisée dans un registre, pas conservée dans la tête du RSSI. Un registre exploitable consignepromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, pour chaque fournisseur : sa raison sociale, le service rendu, sa catégorie (cloud, éditeur, MSP/MSSP, matériel-télécom), son niveau d'accès, la date de dernière évaluation, le résultat obtenu et le plan d'action associé. Sa tenue à jour ne relève pas du seul RSSI : les acheteurs et les responsables métier doivent y contribuer, faute de quoi de nouveaux fournisseurs entrent en service sans jamais apparaître dans le registre.

Quatre grandes catégories de fournisseurs TIC appellent des grilles d'analyse distinctes. Les hébergeurs cloud concentrent souvent l'essentiel des données et posent la question de la localisation, du chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire et de la réversibilité. Les éditeurs de logiciels injectent du code exécutable dans votre environnement à chaque mise à jour, ce qui justifie une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire particulière à leur cycle de développement sécurisé. Les prestataires de services managés (MSP/MSSP) disposent fréquemment d'accès à privilèges élevés sur plusieurs systèmes clients simultanément, ce qui en fait des cibles de choix pour un attaquant cherchant l'effet de levier. Les fournisseurs de matériel et de télécommunications engagent une dépendance de plus long terme, souvent moins visible au quotidien mais plus coûteuse à corriger en cas de défaillance structurelle.

Due diligence : au-delà du questionnaire déclaratif

La due diligence fournisseur commence avant la signature. Trois erreurs reviennent constamment dans les audits :

1. Le questionnaire auto-déclaré sans vérification — le fournisseur répond « oui » à toutes les cases sans preuve documentaire jointe, et personne ne demande la pièce justificative correspondante.
2. La certification prise pour argent comptant — une certification ISO 27001 couvre un périmètre précis (souvent un site ou une offre spécifique), pas l'ensemble de l'organisation ni tous ses services.
3. L'absence de suivi dans le temps — la due diligence est faite une fois, à la signature, puis jamais revisitée pendant les cinq années du contrat, alors que le périmètre du service et l'infrastructure sous-jacente évoluent.

Une certification ISO 27001 ou un visa de sécurité ANSSI ne garantit pas que le service que vous achetez est dans le périmètre certifié. Demandez systématiquement le certificat d'audit (déclaration d'applicabilité, périmètre exact, date de validité) plutôt que le logo affiché sur la plaquette commerciale. C'est un des points de contrôle les plus fréquemment ratés lors des audits ReCyF.

Pour les fournisseurs critiques, la due diligence doit couvrir la gouvernance sécurité du fournisseur (existe-t-il un RSSI, une politique formalisée ?), son historique d'incidents (a-t-il déjà notifié un incident vous concernant ou concernant d'autres clients ?), sa propre chaîne de sous-traitance, et sa résilience opérationnelle (plan de continuité, tests de restauration effectivement réalisés). La profondeur de l'exercice doit rester proportionnée : un fournisseur à faible risque se contente d'un questionnaire documenté, tandis qu'un fournisseur à accès étendu justifie un audit sur site ou un test d'intrusion ciblé avant la signature.

Des référentiels français comme la qualification SecNumCloud pour l'hébergement, ou le visa de sécurité ANSSI pour certains produits, offrent des repères utiles — mais ils couvrent des périmètres techniques précis et ne dispensent jamais d'une évaluation contractuelle propre au service réellement acheté.

Les clauses contractuelles qui font la différence

Un contrat de service TIC sans clause de sécurité explicite laisse l'entité essentielle sans levier en cas d'incident chez le fournisseur. Les clauses suivantes constituent un socle minimal.

La marge de négociation sur ces clauses dépend fortement du rapport de force : un grand éditeur SaaS impose souvent ses conditions générales sans variante possible, tandis qu'un prestataire local de taille moyenne acceptera plus volontiers des clauses spécifiques. Dans le premier cas, l'analyse de risque doit compenser l'absence de levier contractuel par des mesures internes (chiffrement côté client, cloisonnement des accès, plan de sortie documenté même sans obligation contractuelle réciproque).

Négociez les clauses de sécurité avant de vous engager sur le prix, pas après. Une fois le contrat commercial verrouillé, la marge de négociation sur les clauses de sécurité s'effondre — le fournisseur sait que vous avez déjà arbitré en interne. Introduisez le questionnaire de sécurité et les clauses non négociables dans l'appel d'offres lui-même.

Rang 2 et au-delà : lever le voile sur les sous-traitants

La clause de sous-traitance ultérieure ne suffit pas si elle n'est pas exploitée. Exigez de votre fournisseur direct la liste actualisée de ses propres sous-traitants critiques, avec le même niveau d'information que celui que vous appliquez à vos fournisseurs de rang 1 : nature de l'accès, localisation, criticité. Sans cette exigence, le rang 2 reste une zone d'ombre qui n'apparaît qu'au moment de l'incident — souvent trop tard.

La cascade de conformité pose aussi un problème de délai. Un incident détecté chez un sous-traitant de rang 2 doit remonter à votre fournisseur de rang 1, qui doit à son tour vous notifier, avant que vous ne notifiiez l'autorité compétente dans le délai réglementaire. Chaque maillon supplémentaire consomme une part du délai de 24 heures. C'est pourquoi la clause de notification doit fixer un délai resserré au niveau du rang 1 (par exemple 4 à 6 heures), pour laisser une marge de traitement avant l'échéance réglementaire globale.

Concentration du risque : le point aveugle le plus coûteux

La concentration survient quand plusieurs fournisseurs apparemment indépendants s'appuient en réalité sur la même brique technique en amont : même datacenter, même solution d'authentification, même bibliothèque logicielle, même sous-traitant de support. Un incident sur ce point unique se propage alors simultanément à travers plusieurs canaux que vous pensiez distincts.

Ce risque est difficile à détecter parce qu'il ne ressort pas d'un audit fournisseur pris isolément. Il faut le chercher activement :

• Interroger chaque fournisseur critique sur son hébergement effectif (nom du datacenter ou de la zone cloud, pas seulement « cloud public »).
• Identifier les briques logicielles tierces communes à plusieurs prestataires (bibliothèques open source, composants d'authentification, passerelles de paiement).
• Cartographier les dépendances géographiques : plusieurs fournisseurs situés dans une même zone exposée à un risque physique ou géopolitique commun.

Une collectivité territoriale fait appel à trois prestataires distincts pour sa messagerie, son outil de gestion financière et son portail citoyen. Une revue de chaîne d'approvisionnement révèle que les trois solutions s'appuient sur la même API d'authentification tierce, hébergée par un éditeur unique. La compromission de cet éditeur aurait suffi à paralyser les trois services simultanément — un scénario invisible tant que chaque fournisseur était évalué séparément.

Face à cette concentration, deux leviers opérationnels se combinent. La diversification, d'abord, lorsqu'elle est économiquement soutenable : répartir les fonctions critiques entre plusieurs briques technologiques indépendantes réduit la surface d'un incident unique, au prix d'une complexité opérationnelle accrue. À défaut, un plan de continuité qui suppose explicitement l'indisponibilité simultanée de plusieurs services dépendant du même point unique — et non l'indisponibilité isolée d'un seul fournisseur à la fois, hypothèse plus confortable mais irréaliste dès lors qu'une concentration a été identifiée.

Suivi dans la durée

La conformité fournisseur n'est pas un jalon ponctuel. Le référentiel ReCyF attend une réévaluation périodique, proportionnée à la criticité :

• Fournisseurs critiques : revue annuelle a minima, et à chaque changement significatif de périmètre du service.
• Fournisseurs secondaires : revue à échéance contractuelle ou tous les deux à trois ans.
• Tout fournisseur ayant notifié un incident : réévaluation immédiate, indépendamment du calendrier habituel.

D'autres événements doivent déclencher une réévaluation hors calendrier : changement de propriétaire ou d'actionnariat du fournisseur, migration d'infrastructure annoncée, apparition d'une vulnérabilité majeure touchant un composant qu'il utilise, ou simple silence prolongé sur les indicateurs de sécurité habituellement partagés.

Le registre des fournisseurs critiques et les preuves de due diligence associées font partie des pièces demandées lors d'un contrôle ReCyF. Un registre à jour, même imparfait, est toujours mieux perçu qu'une documentation reconstituée dans l'urgence après notification de contrôle.

Checklist opérationnelle

• Cartographie des fournisseurs TIC avec niveau de criticité et d'accès formalisé
• Questionnaire de due diligence avec preuves documentaires exigées, pas de déclaratif seul
• Vérification du périmètre exact des certifications présentées
• Clauses de notification d'incident alignées sur le délai réglementaire de 24h
• Droit d'audit effectif, pas seulement mentionné dans le contrat
• Clause de cascade de conformité vers les sous-traitants de rang 2
• Analyse de concentration sur les briques techniques partagées entre fournisseurs
• Calendrier de réévaluation périodique proportionné à la criticité

La sécurité de la chaîne d'approvisionnement n'élimine pas le risque fournisseur — aucune clause contractuelle ne remplace la sécurité effective d'un tiers. Elle réduit le temps de détection, clarifie les responsabilités en cas d'incident, et évite qu'une dépendance non cartographiée devienne la surprise qui déclenche la crise.