Points clés
- La dépendance au cloud s'installe progressivement et souvent sans décision explicite de gouvernance — par accumulation de choix opérationnels
- Le shadow IT cloud représente en moyenne 10 à 50 fois plus de services que les services cloud approuvés formellement (McAfee)
- La concentration sur un seul fournisseur cloud est un risque de disponibilité systémique que DORA identifie explicitement
- La cartographie des dépendances cloud est une exigence de base de NIS2 pour les entités essentielles
La dépendance au cloud d'une organisation est souvent bien supérieure à ce que la direction perçoit. Elle s'est constituée progressivement, au fil de décisions opérationnelles individuelles : une équipe marketing qui adopte un outil SaaS pour gérer ses campagnes, une équipe de développement qui ouvre des comptes AWS pour ses environnements de test, une direction des ressources humaines qui migre son SIRH vers une solution cloud sans passer par le processus d'approbation IT. Cette accumulation silencieuse crée une dépendance structurelle qui n'a jamais fait l'objet d'une décision de gouvernance explicite.
L'enjeu pour la direction n'est pas de contrôler chaque adoption de service cloud — ce serait contre-productif — mais de disposer d'une vision suffisamment précise de cette dépendance pour en gérer les risques : disponibilité des services critiques, protection des données sensibles, conformité réglementaire, et options de sortie si un fournisseur change ses conditions ou cesse d'opérer.
Le shadow IT cloud : une réalité difficile à cartographier
Le shadow IT cloud — l'utilisation de services cloud non approuvés par les équipes métiers — est un phénomène universel dans les organisations. Les estimations varient selon les études, mais toutes convergent sur l'ampleur : les équipes utilisent couramment 5 à 10 fois plus de services cloud que ce que la DSI en connaît.
Ces services non approuvés présentent des risques spécifiques : des données sensibles potentiellement hébergées dans des juridictions non conformes aux obligations réglementaires, des accès non révoqués lors des départs de collaborateurs, des intégrations avec d'autres systèmes créant des vecteurs d'exposition non cartographiés. La difficulté est que leur découverte et leur gestion requièrent des outils et des processus que peu d'organisations ont déployés.
La concentration fournisseur comme risque systémique
La majorité des organisations ont concentré leur infrastructure cloud sur un ou deux fournisseurs majeurs (AWS, Microsoft Azure, Google Cloud). Cette concentration offre des avantages (économies d'échelle, intégration native des services) mais crée un risque de concentration : une panne du fournisseur, une augmentation tarifaire unilatérale, une décision réglementaire restreignant son utilisation, ou une compromission de son infrastructure peuvent affecter l'ensemble des systèmes de l'organisation simultanément.
Le règlement DORA identifie explicitement le risque de concentration ICT comme une priorité de supervision : les institutions financières doivent identifier leurs fournisseurs ICT critiques et évaluer leur dépendance à l'égard de chacun. La BCE a annoncé en 2024 des inspections spécifiques sur la gestion du risque de concentration cloud dans les grandes banques européennes.
Gouverner la dépendance cloud
La gouvernance de la dépendance cloud comprend quatre éléments : un inventaire des services cloud utilisés (outils CASB — Cloud Access Security Broker — pour découvrir les services non approuvés), une classification selon la criticité des données et des fonctions hébergées, une évaluation des options de sortie pour les services critiques (réversibilité, coûts de migration, existence d'alternatives), et un plan de continuité qui anticipe l'indisponibilité temporaire ou permanente des services cloud les plus critiques.
Cet inventaire et cette évaluation ne sont pas des exercices uniques — ils doivent être maintenus à jour à mesure que l'utilisation du cloud évolue. Les organisations qui disposent d'une gouvernance cloud mature font de cette mise à jour un processus continu, intégré dans leurs processus de gestion des changements et de gestion des actifs.
Une panne majeure d'AWS dans la région us-east-1 (côte Est américaine) a affecté simultanément des milliers d'organisations qui n'avaient pas déployé d'architecture multi-région. Parmi les services affectés : Netflix, Disney+, Robinhood, Delta Airlines et de nombreuses autres entreprises dont les services numériques étaient entièrement concentrés sur cette région. La panne a duré plusieurs heures. Elle a conduit de nombreuses organisations à revoir leur stratégie de répartition géographique sur AWS et leur niveau de dépendance à un seul datacenter cloud.
Une mise à jour défaillante du logiciel CrowdStrike, déployée sur des systèmes Windows via Microsoft Azure, a causé la panne de 8,5 millions de systèmes Windows dans le monde, affectant des aéroports, des banques, des hôpitaux et des médias dans 85 pays. Bien que la panne soit liée à CrowdStrike (pas directement à Azure), l'incident a mis en évidence le niveau de dépendance systémique aux infrastructures cloud et aux fournisseurs de sécurité partagés. La concentration d'un outil de sécurité sur des millions de systèmes a transformé une erreur logicielle en incident mondial.
LINE, l'une des applications de messagerie les plus utilisées en Asie, a révélé en 2021 que des données personnelles de ses utilisateurs japonais étaient accessibles depuis des serveurs hébergés en Chine, violant potentiellement les réglementations sur la localisation des données. La direction de LINE n'avait pas une vision complète de l'architecture cloud sous-jacente de ses applications — la dépendance à une infrastructure partagée avec ses partenaires techniques n'avait pas été correctement cartographiée. L'incident a conduit à une révision des exigences de localisation des données pour les services numériques grand public au Japon.