- Renault (2017) : l\'arrêt de plusieurs usines lors de l\'épidémie WannaCry a révélé que des systèmes de contrôle industriel présumés isolés étaient connectés au réseau d\'entreprise — une dépendance non documentée qui a rendu impossible la continuité de la production.
- La cartographie des dépendances IT est un exercice distinct de la cartographie des systèmes : elle identifie non pas seulement les systèmes existants mais les relations de dépendance entre eux et entre eux et les processus métier.
- Les dépendances cachées — processus supposés manualisables mais entièrement automatisés, systèmes secondaires critiques, dépendances cloud non documentées — sont les sources les plus fréquentes de surprises lors des incidents.
- La dépendance aux services cloud crée une catégorie de vulnérabilité spécifique : l\'indisponibilité d\'un seul prestataire cloud peut paralyser des dizaines de processus métier apparemment indépendants.
- Les systèmes legacy non documentés constituent une zone de dépendance particulièrement risquée : ils sont souvent critiques pour des processus que les équipes actuelles ne connaissent pas bien, et leur restauration en cas de panne est difficile.
- L\'exercice de cartographie des dépendances révèle systématiquement des points de défaillance unique (SPOF) qui méritent une attention prioritaire dans la stratégie de résilience.
La dépendance réelle d\'une organisation à ses systèmes informatiques est l\'une des dimensions les plus sous-estimées de son exposition au risque. En conditions normales, les systèmes fonctionnent, les processus métier s\'exécutent, et personne n\'a besoin de connaître précisément quels systèmes sous-tendent quels processus. C\'est au moment d\'un incident que cette ignorance se révèle coûteuse.
La cartographie des dépendances IT — l\'identification précise des relations de dépendance entre les systèmes et entre les systèmes et les processus métier — est l\'une des contributions les plus précieuses que la direction IT puisse apporter à la résilience organisationnelle. C\'est également l\'un des exercices les plus difficiles à réaliser, parce qu\'il révèle des lacunes que beaucoup d\'acteurs préfèrent ne pas voir.
Les catégories de dépendances cachées
La première catégorie de dépendances cachées concerne les processus supposés manualisables. Dans beaucoup d\'organisations, les plans de continuité supposent que certains processus peuvent être réalisés manuellement en cas d\'indisponibilité des systèmes. En pratique, ces processus ont été entièrement automatisés au fil du temps, et les procédures manuelles n\'ont jamais été documentées ou n\'ont pas été mises à jour depuis leur automatisation. Lorsqu\'un incident force le recours à ces procédures manuelles, les équipes découvrent qu\'elles n\'existent pas ou ne sont plus opérables.
La deuxième catégorie concerne les systèmes secondaires qui conditionnent le fonctionnement de processus critiques. Un système de gestion des commandes peut dépendre d\'un service d\'authentification, lui-même dépendant d\'un annuaire, lui-même hébergé sur une infrastructure partagée. Si l\'annuaire tombe, tout s\'arrête — mais si cette chaîne de dépendance n\'est pas documentée, l\'équipe de reprise ne saura pas immédiatement où chercher la cause de la défaillance.
En mai 2017, British Airways a connu une panne informatique massive causée par une erreur humaine lors d\'une intervention sur l\'alimentation électrique d\'un data center. La panne a paralysé l\'ensemble des opérations pendant plusieurs jours — annulations de vols, impossibilité de check-in, pertes de données de réservation. L\'enquête a révélé que la dépendance de l\'ensemble des opérations à ce centre de données unique n\'avait pas été anticipée dans les plans de continuité. Un point de défaillance unique non documenté avait rendu le plan de bascule vers un site secondaire inefficace, parce que la synchronisation des données entre les deux sites n\'était pas complète. Le coût pour British Airways a été estimé à plus de 80 millions de livres en compensations, pertes de revenus et remédiation.
La dépendance aux services cloud : une nouvelle catégorie de risque
L\'adoption massive des services cloud a créé une nouvelle catégorie de dépendance qui n\'est pas toujours bien intégrée dans les plans de continuité. Beaucoup d\'organisations ont migré de nombreux services vers des plateformes cloud sans analyser l\'impact de l\'indisponibilité de ces plateformes sur leur continuité d\'activité. Un prestataire cloud qui connaît une panne peut paralyser simultanément des dizaines de processus métier apparemment indépendants — réservation, paiement, communication client, gestion interne — qui reposent tous sur la même plateforme.
La concentration sur quelques grands prestataires cloud crée également une vulnérabilité systémique. Lorsqu\'AWS, Microsoft Azure ou Google Cloud connaissent une panne régionale, des milliers d\'organisations sont simultanément affectées. Cette simultanéité crée des problèmes de prioritisation des ressources de reprise et peut prolonger les délais de restauration au-delà de ce que prévoient les plans de continuité.
La méthode de cartographie des dépendances
La cartographie des dépendances IT commence par l\'identification des processus métier critiques — ceux dont l\'interruption a les conséquences les plus importantes sur la capacité de l\'organisation à opérer et à répondre à ses obligations. Pour chacun de ces processus, on identifie les systèmes qui le supportent, puis les dépendances de ces systèmes envers d\'autres systèmes, d\'autres services ou d\'autres organisations. Cette analyse en couches révèle progressivement la structure réelle des dépendances — souvent beaucoup plus complexe que ce que les équipes imaginaient.
La violation Capital One de 2019 (mauvaise configuration AWS) a révélé une dépendance critique non documentée : la configuration de sécurité du rôle IAM compromis donnait accès à des buckets S3 contenant des données de 100 millions de clients sans que cette étendue d\'accès soit visible dans les politiques de sécurité documentées. La dépendance entre les droits accordés aux services AWS et l\'étendue des données accessibles n\'avait pas été cartographiée lors de la migration vers le cloud. Un exercice de cartographie des permissions effectives dans l\'environnement cloud aurait révélé ce risque avant qu\'il ne soit exploité. Capital One a payé 80 millions de dollars d\'amende et investi massivement dans la révision de sa gouvernance cloud.
L\'impact de NotPetya sur Maersk en 2017 a révélé une dépendance critique à un contrôleur de domaine situé en Ukraine qui avait été détruit par le malware. Ce contrôleur de domaine unique, qui gérait l\'authentification pour l\'ensemble du réseau mondial de Maersk, était un point de défaillance unique non documenté dans les plans de continuité. Sa destruction a rendu impossible toute authentification dans le réseau de l\'entreprise — bloquant l\'accès aux systèmes par les 80 000 employés. Maersk a finalement pu reconstituer l\'annuaire grâce à une copie de sauvegarde découverte sur un poste de travail en Afrique du Sud qui était resté hors ligne lors de l\'attaque — un heureux hasard qui a sauvé l\'opération de reprise.
En février 2022, Toyota a été contraint d\'arrêter la production dans l\'ensemble de ses 28 usines japonaises pendant une journée — une perte de 13 000 véhicules — à la suite d\'une cyberattaque contre son fournisseur de pièces Kojima Industries. La dépendance de Toyota à ce fournisseur unique pour la réception des données de commandes de pièces a été révélée comme un point de défaillance critique dans sa chaîne d\'approvisionnement. Toyota avait des plans de continuité pour ses propres systèmes mais pas pour la défaillance d\'un fournisseur clé. Cet incident a conduit Toyota à réviser son programme de résilience de la chaîne d\'approvisionnement pour inclure des plans de continuité pour les fournisseurs critiques et des alternatives en cas de défaillance.