Supply chain TIC : quels fournisseurs peuvent réellement arrêter votre SI ?

Une organisation peut avoir des dizaines de fournisseurs technologiques sans savoir lesquels constituent réellement un point de rupture pour son système d’information.

Un inventaire contractuel répond à une question simple : avec qui travaillons-nous ?

Une analyse de supply chain cyber doit répondre à une question beaucoup plus difficile :

si ce fournisseur disparaît, est compromis ou devient inutilisable demain, quels services cessent réellement de fonctionner ?

En février 2026, le groupe de coopération NIS, avec la Commission européenne et l’ENISA, a publié l’EU ICT Supply Chain Security Toolbox. Le document propose une approche commune pour identifier, évaluer et réduire les risques de cybersécurité liés aux chaînes d’approvisionnement TIC. Il insiste notamment sur l’évaluation des fournisseurs critiques, les stratégies multifournisseurs et la réduction des dépendances à des fournisseurs à haut risque.1

Le changement de perspective est important : la question n’est plus seulement de connaître ses fournisseurs, mais de connaître les dépendances qui relient ces fournisseurs au fonctionnement réel du SI.

Un fournisseur important n’est pas forcément un fournisseur critique

Une entreprise peut dépenser plusieurs millions d’euros par an auprès d’un prestataire sans que sa disparition provoque immédiatement l’arrêt d’une activité critique.

À l’inverse, un service relativement peu coûteux peut constituer un point de dépendance majeur.

Quelques exemples :

• un fournisseur DNS utilisé par toutes les applications exposées sur Internet ;
• une solution IAM commune à plusieurs centaines d’applications ;
• un service de certificats utilisé par l’ensemble des API ;
• un CDN placé devant plusieurs plateformes critiques ;
• un hyperviseur ou une technologie de virtualisation utilisée dans plusieurs datacenters ;
• une bibliothèque ou un composant logiciel intégré dans de nombreux produits.

La criticité fournisseur ne peut donc pas être déduite uniquement du montant du contrat, du nombre de licences ou de la taille du prestataire.

Elle dépend surtout de sa position dans l’architecture du SI.

La bonne unité d’analyse est la chaîne de dépendances

Une représentation opérationnelle peut prendre la forme suivante :

processus métier → service → application → composant technique → fournisseur → dépendance fournisseur → alternative.

Cette chaîne permet de répondre à plusieurs questions : quel processus métier dépend du fournisseur ? quels composants techniques reposent sur lui ? cette dépendance est-elle directe ou indirecte ? existe-t-il une solution alternative ? combien de temps faudrait-il pour basculer ? l’alternative utilise-t-elle elle-même la même technologie ou le même sous-traitant ?

La dernière question est particulièrement importante.

Deux fournisseurs différents ne signifient pas nécessairement deux chaînes d’approvisionnement différentes.

Le multifournisseur peut donner une fausse impression de résilience

Le toolbox européen met notamment en avant les stratégies multi-vendor comme moyen de réduire certaines dépendances.1

Mais une architecture multifournisseur n’est réellement résiliente que si les chaînes sous-jacentes sont suffisamment indépendantes.

Prenons trois applications : la première est hébergée chez un fournisseur cloud A, la deuxième chez un fournisseur B, la troisième dans un datacenter interne.

Sur le papier, l’organisation dispose donc de trois architectures différentes.

Mais les trois utilisent le même fournisseur IAM, le même service DNS, le même CDN pour leurs services publics et la même technologie de sauvegarde.

La diversité visible au niveau de l’hébergement masque alors plusieurs points de concentration communs.

Une cartographie de supply chain doit donc pouvoir remonter au-delà du fournisseur principal.

Cas construit : cinq applications, trois clouds, un seul point de rupture

Imaginons une entreprise disposant de cinq applications critiques.

Deux sont hébergées sur un cloud public, une autre utilise un deuxième fournisseur cloud, les deux dernières sont hébergées en interne.

La DSI considère l’architecture comme correctement diversifiée.

Une analyse plus détaillée révèle pourtant que les cinq applications utilisent le même fournisseur d’identité.

Ce fournisseur gère l’authentification des utilisateurs, les comptes administrateurs, certains mécanismes de fédération et l’accès à plusieurs consoles techniques.

Une panne généralisée du service n’arrête pas nécessairement les serveurs. Les applications continuent à fonctionner techniquement, mais les utilisateurs ne peuvent plus s’authentifier.

L’impact métier peut donc être quasiment identique à une panne complète.

La dépendance déterminante n’était pas le cloud. C’était l’identité.

Il faut distinguer fournisseur, technologie et service

Un même fournisseur peut apparaître plusieurs fois dans une architecture sous des formes différentes.

Un hyperscaler peut fournir infrastructure, stockage, IAM, bases de données, fonctions serverless, observabilité et services d’intelligence artificielle.

La relation application → fournisseur est alors beaucoup trop simplifiée.

Il est plus utile de représenter application → service technologique → fournisseur.

Cela permet de distinguer une dépendance facilement substituable d’une dépendance beaucoup plus profonde.

Une application utilisant une machine virtuelle standard peut parfois être migrée relativement facilement. Une application reposant sur une dizaine de services propriétaires fortement intégrés peut nécessiter plusieurs mois de transformation.

Le fournisseur est le même. La dépendance ne l’est pas.

La substituabilité doit devenir une donnée d’architecture

Le toolbox européen cherche notamment à réduire les dépendances envers certains fournisseurs à haut risque.1

Pour une organisation, cette réflexion conduit naturellement à une notion encore rarement documentée dans les inventaires SI : la substituabilité.

Pour chaque dépendance significative, plusieurs informations deviennent utiles : alternative identifiée, délai de migration, complexité technique, portabilité des données, compétences internes et dépendances communes.

Une dépendance sans alternative réaliste mérite probablement davantage d’attention qu’un fournisseur facilement remplaçable.

Les dépendances indirectes sont souvent les plus difficiles à voir

Une entreprise connaît généralement ses fournisseurs directs. Elle connaît beaucoup moins bien les dépendances de ces fournisseurs.

Un SaaS peut lui-même dépendre d’un hyperscaler, d’un fournisseur CDN, d’une plateforme IAM, d’une infrastructure DNS, d’un prestataire de paiement ou d’une technologie particulière.

Le client ne maîtrise pas nécessairement cette chaîne, mais il peut chercher à en connaître les éléments qui influencent réellement son exposition.

Les conclusions du Conseil de l’Union européenne sur la sécurité des chaînes d’approvisionnement TIC insistaient déjà en 2022 sur les dépendances stratégiques et sur la nécessité de mieux prendre en compte les pratiques de cybersécurité des fournisseurs et de leurs sous-traitants.2

La question devient alors : jusqu’où faut-il cartographier la chaîne ?

La réponse pragmatique est probablement : jusqu’au niveau où une dépendance supplémentaire peut modifier l’analyse du risque.

Tout cartographier n’est pas réaliste

Une grande entreprise peut compter plusieurs milliers de fournisseurs, logiciels et composants.

Chercher immédiatement à documenter toutes les chaînes d’approvisionnement serait probablement contre-productif.

Une démarche progressive peut commencer par les services métier les plus critiques, les applications qui les supportent, leurs dépendances technologiques majeures, les fournisseurs associés, les points communs entre plusieurs applications et les dépendances présentant une faible substituabilité.

L’objectif n’est pas d’obtenir une représentation parfaite de l’écosystème.

Il est d’identifier les concentrations susceptibles de provoquer un impact systémique.

Le risque supply chain devient également géopolitique

La Commission européenne a proposé en janvier 2026 une révision du Cybersecurity Act visant notamment à renforcer la sécurité des chaînes d’approvisionnement TIC et à réduire certains risques associés à des fournisseurs de pays tiers.3

Le risque fournisseur ne se limite donc plus à la disponibilité, la cybersécurité technique ou la solidité financière.

Il peut aussi inclure juridiction, contrôle capitalistique, dépendance technologique, capacité d’un tiers à interrompre un service, exposition à des restrictions commerciales et dépendances stratégiques.

Une cartographie technique devient alors un support de décision beaucoup plus large.

Un exercice simple pour tester sa connaissance de la supply chain

Choisissez cinq services considérés comme critiques.

Pour chacun, essayez de reconstruire : service métier → application → technologies critiques → fournisseurs → dépendances communes → alternatives.

Puis posez quatre questions : existe-t-il un fournisseur présent dans plusieurs chaînes ? existe-t-il une technologie commune cachée derrière plusieurs fournisseurs ? existe-t-il une dépendance sans alternative réaliste ? connaissons-nous le temps nécessaire pour remplacer cette dépendance ?

Si les réponses nécessitent plusieurs jours d’investigation, le principal problème n’est probablement pas l’absence d’un nouveau questionnaire fournisseur.

C’est l’absence d’une vision consolidée des dépendances technologiques du SI.

Et c’est précisément cette vision que la sécurité de la supply chain TIC rend désormais nécessaire.