Dépendances supply chain : l’angle mort à cartographier

Un ransomware ne “casse” pas toujours vos systèmes. Il casse parfois votre capacité à opérer. Et, en 2025, c’est souvent la même histoire : l’incident démarre chez un tiers (éditeur, infogérant, transporteur, prestataire de paie, sous-traitant métier), puis se propage en onde de choc jusqu’à vous.

La plupart des entreprises pensent connaître leur supply chain… parce qu’elles connaissent leurs fournisseurs directs. Le problème, c’est l’invisible : les prestataires de vos prestataires, les dépendances techniques enfouies (API, certificats, DNS, services cloud), et les “petits” fournisseurs qui font tenir un processus critique. Cet angle mort coûte cher, surtout quand il se transforme en arrêt d’activité, en retards de livraison, ou en incapacité à soigner, payer, expédier.

Ce billet s’inscrit dans notre série « Intelligence artificielle dans la cybersécurité ». Mon point de vue est simple : cartographier les dépendances sans IA est devenu trop lent. Et protéger la chaîne d’approvisionnement sans visibilité en continu, c’est accepter de piloter à l’aveugle.

Les cyberattaques “temporaires” peuvent arrêter le business

Une idée revient souvent dans les échanges entre praticiens : une cyberattaque crée souvent des dégâts réparables — on restaure, on reconstruit, on redémarre. Mais l’impact économique et opérationnel, lui, est bien réel quand une dépendance indispensable saute.

Le monde l’a observé sur des infrastructures critiques : une perturbation cyber peut être contenue, corrigée, parfois plus vite qu’un dommage physique. Pour une entreprise, la conclusion utile n’est pas “le cyber est moins grave”. C’est plutôt : le cyber déplace le champ de bataille vers les dépendances. Là où votre continuité d’activité est la plus fragile.

Une entreprise ne tombe pas toujours parce qu’elle est attaquée. Elle tombe parce qu’un maillon dont elle dépend l’est.

Le mythe du “fournisseur non critique”

J’ai vu des organisations classer “non critique” un prestataire parce qu’il ne touche pas au cœur du SI. Puis découvrir, le jour J, que ce prestataire gère :

• un flux d’approvisionnement indispensable (commande, transport, entrepôt),
• un service de confiance (certificat, authentification, signature),
• une brique d’intégration (API, ETL, EDI),
• ou une fonction réglementaire (archivage, facturation, paie).

L’incident n’est pas toujours spectaculaire. Il est juste paralysant.

Dépendances : l’attaque qui vise le “monde réel”

Quand une armée dépend de sous-traitants logistiques, son exposition augmente. Côté entreprise, c’est identique : plus vous externalisez, plus votre surface d’attaque se déporte. Et ce déplacement est souvent sous-estimé.

Le scénario le plus instructif est celui de la restauration ou de l’approvisionnement : vous pouvez avoir un SI “propre”, mais si la livraison s’arrête, l’activité s’arrête.

L’exemple qui fait mal : la dépendance cachée

Prenons un cas volontairement banal. Une chaîne de restauration peut survivre à un incident sur un équipement local. Mais si un attaquant bloque le fournisseur d’un ingrédient clé, ou le système de commande central, la production s’interrompt.

Transposé au B2B, c’est encore plus brutal : un cabinet médical qui ne peut plus transmettre des feuilles de soins, un industriel qui ne peut plus recevoir de composants, un hôpital qui ne peut plus être livré en repas par son prestataire. Dans certains secteurs, la continuité devient une question de sécurité des personnes.

Le risque 2026 : l’extorsion “en cascade”

Aujourd’hui, l’extorsion vise surtout l’entité attaquée. Mais l’économie de la cybercriminalité évolue vite. Une stratégie très plausible consiste à :

1. attaquer un fournisseur unique (logiciel, traitement, logistique),
2. créer une pénurie ou un arrêt de service,
3. faire payer l’écosystème qui dépend de ce fournisseur.

Pourquoi ? Parce que votre coût d’arrêt peut dépasser celui du fournisseur. Si vous perdez 500 000 € par jour d’interruption, la pression est immédiate.

Cartographier vos dépendances : ce qu’il faut faire (vraiment)

La bonne approche n’est pas “faire un inventaire fournisseurs”. C’est cartographier les dépendances opérationnelles et techniques et relier chaque dépendance à un impact business mesurable.

1) Partir des processus critiques, pas de l’organigramme

Commencez par 5 à 10 processus : prendre une commande, produire, expédier, facturer, encaisser, payer les salariés, servir un patient, etc. Pour chacun, posez deux questions simples :

• Qu’est-ce qui doit fonctionner pour que ce processus tienne ?
• Qu’est-ce qui nous arrête en moins de 24h ?

Vous allez faire remonter des dépendances inattendues : un service de messagerie, un DNS, un outil d’authentification, un prestataire d’impression d’étiquettes, une passerelle EDI.

2) Construire une “carte de dépendances” exploitable

Une carte utile relie : processus → applications → données → identités → fournisseurs → sous-traitants → infrastructures.

Concrètement, visez un format lisible par le COMEX et actionnable par les équipes :

• dépendance
• rôle exact
• propriétaire interne
• fournisseur (et sous-traitants connus)
• point de rupture (ce qui casse)
• RTO/RPO attendus (temps et perte de données acceptables)
• plan B (dégradé, alternative, stock, second fournisseur)

3) Classer par “impact d’arrêt”, pas par “budget fournisseur”

Le piège fréquent : classer critique = cher. Alors que critique = arrêt d’activité ou risque juridique ou risque patient/usager.

Je recommande une matrice simple à 4 niveaux, basée sur :

• arrêt < 4h
• arrêt < 24h
• arrêt < 72h
• arrêt > 72h

Chaque dépendance doit tomber dans une case, avec une justification.

Où l’IA change la donne : visibilité en continu et priorisation

La cartographie “à la main” se périme vite : nouveaux SaaS, nouvelles API, fusions-acquisitions, projets métiers. L’IA apporte de la valeur sur deux axes très concrets : détecter ce qui a changé et prioriser ce qui compte.

Découvrir automatiquement les dépendances techniques

Les organisations disposent déjà de signaux : logs, flux réseau, inventaires cloud, tickets ITSM, configurations CI/CD. Les approches IA (dont le machine learning) savent :

• regrouper des événements et identifier des services réellement utilisés,
• repérer des dépendances “de fait” (un domaine, une API, un certificat),
• détecter des nouveaux échanges réseau anormaux (shadow IT, intégrations non déclarées).

Résultat attendu : moins de trous dans la raquette, et une carte qui vit.

Détecter plus tôt le risque fournisseur (et pas seulement l’incident)

L’IA est aussi utile pour l’alerte “faible”, avant l’arrêt :

• augmentation progressive des erreurs d’API,
• délais de traitement qui s’allongent,
• pics d’authentifications échouées,
• changements de certificats ou de configurations,
• comportements inhabituels sur comptes de service.

Ce sont souvent des précurseurs d’incident, pas des preuves. Mais c’est suffisant pour activer une vérification, basculer en mode dégradé, ou ouvrir un canal de crise avec le fournisseur.

Prioriser les actions de résilience avec une logique business

La promesse la plus réaliste de l’IA n’est pas “tout prévoir”. C’est :

• relier un signal technique à un processus critique,
• estimer l’impact probable,
• recommander l’action la plus rentable (ex. bascule, limitation de fonctionnalités, segmentation, blocage d’accès, rotation de secrets).

La cybersécurité efficace, c’est une liste courte d’actions prioritaires — pas un catalogue de contrôles.

Plan d’action en 30 jours : réduire l’angle mort supply chain

Voici ce qui marche bien pour lancer une démarche sans créer une usine à gaz.

Semaine 1 : cadrage et “top 10 dépendances”

• Identifiez 5 processus critiques.
• Pour chacun, listez les 2 dépendances externes qui vous arrêtent le plus vite.
• Nommez un responsable interne par dépendance (métier + IT).

Livrable : une page par processus, lisible.

Semaine 2 : test de rupture (table-top) et RTO réalistes

• Simulez un scénario : “le fournisseur X est indisponible 72h”.
• Mesurez : qui décide ? quand ? comment bascule-t-on ?
• Fixez un RTO/RPO réaliste, pas théorique.

Semaine 3 : exigences fournisseurs et preuves minimales

Sans tomber dans le questionnaire de 200 lignes, demandez des preuves simples :

• sauvegardes testées et fréquence,
• MFA et gestion des accès privilégiés,
• gestion des vulnérabilités et délais de correction,
• plan de réponse à incident (contacts, délais de notification),
• clauses de continuité (SLA, mode dégradé, réversibilité).

Semaine 4 : instrumentation + alertes orientées dépendances

• Branchez des métriques sur les flux critiques (API, EDI, authentification, DNS).
• Définissez 5 alertes “business” (ex. taux d’échec commande, latence paiement, indisponibilité identité).
• Lancez un pilote IA (ou des règles intelligentes) pour détecter les dérives, pas seulement les pannes.

FAQ opérationnelle (celle que tout le monde se pose)

“On a déjà un plan PCA/PRA, ça suffit ?”

Non, pas si votre PCA/PRA suppose que vous êtes la seule victime. Une dépendance supply chain impose un PCA orienté écosystème : fournisseur indisponible, réversibilité, alternative, stock, mode dégradé.

“Quel est le meilleur indicateur pour savoir si on est prêt ?”

Un indicateur simple : le temps nécessaire pour basculer en mode dégradé sur vos 5 dépendances externes les plus critiques. Si vous ne pouvez pas le mesurer, vous n’êtes pas prêt.

“L’IA remplace les audits fournisseurs ?”

Non. Elle complète. L’audit vérifie une posture à un instant T. L’IA sert à surveiller la réalité opérationnelle et les signaux faibles entre deux audits.

Une résilience supply chain pilotée par l’IA, ou une résilience sur papier

La dépendance est le vrai sujet : pas parce qu’elle est honteuse, mais parce qu’elle est inévitable. Les entreprises modernes sont des réseaux. Et un réseau se sécurise par visibilité, priorisation, et plans de dégradation clairs.

Si vous ne deviez retenir qu’une idée : votre risque cyber ne s’arrête pas à vos frontières. Il se cache dans vos flux, vos prestataires et leurs propres dépendances — et il évolue chaque semaine.

Vous avez déjà la plupart des données nécessaires pour voir cet angle mort. La question est plutôt : quand est-ce que vous mettez en place une cartographie vivante, enrichie par l’IA, et reliée à vos processus critiques ?