Un rapport publié par le Cyber Monitoring Centre (CMC) britannique, en partenariat avec l’assureur-analyste Parametrix, vient de mettre un chiffre précis sur une angoisse que beaucoup de directeurs informatiques évitaient d’affronter : que se passerait-il si un seul fournisseur de cloud tombait en panne pendant 24 heures ? Réponse : entre 650 millions et 1 milliard de livres sterling de pertes directes pour l’économie britannique, rien que pour cette journée. Le document, intitulé “The Cost of Downtime: UK Exposure to Cloud Infrastructure Failure”, date du 9 juillet 2026, mais sa diffusion continue d’alimenter la presse spécialisée trois mois plus tard, avec de nouvelles reprises chez Computer Weekly et TechTarget jusqu’au 24 septembre. Le sujet colle d’autant mieux à l’actualité que Google Cloud a subi une nouvelle coupure réseau le 1er septembre dans sa zone us-central1-b, touchant 15 services, et que Cloudflare a dû corriger le 25 septembre une faille de fuite de données entre conteneurs de clients différents. Pour la France et le reste de l’Europe, où les mêmes trois hyperscalers dominent le marché, le message dépasse largement les frontières britanniques.

Un rapport qui chiffre enfin le risque de concentration cloud

Le CMC est un organisme indépendant financé par l’industrie britannique de l’assurance et de la cybersécurité, créé pour classifier objectivement la gravité des incidents numériques majeurs. Son partenariat avec Parametrix, spécialiste de la modélisation du risque d’interruption cloud, donne au document un poids inhabituel : il ne s’agit pas d’une estimation vague mais d’un travail de cartographie économique, région par région, fournisseur par fournisseur.

Le constat de départ tient en une phrase reprise par Parametrix dans son résumé public : “Cloud risk is concentrated in a few cloud providers: Around 80% of all UK organisations are dependent on AWS, Azure and GCP.” (Parametrix, rapport CMC, 2026). Autrement dit, quatre entreprises britanniques sur cinq dépendent d’un même trio de fournisseurs pour faire tourner tout ou partie de leurs opérations critiques. Le rapport distingue soigneusement deux façons de compter cette dépendance, et c’est là que les chiffres deviennent intéressants pour un lecteur habitué aux études d’impact économique.

80 % du FTSE 100 : un chiffre qui cache deux réalités

Pris sans pondération, seuls 11 % des entreprises britanniques sont classées comme “totalement dépendantes du cloud” pour leurs fonctions critiques. Un chiffre presque rassurant, si on le lit seul. Mais dès qu’on pondère cet échantillon par le chiffre d’affaires généré, la part grimpe à 64 % de l’économie britannique pertinente. Et quand l’analyse se concentre sur le FTSE 100, l’indice des cent plus grandes capitalisations cotées à Londres, la proportion dépasse 80 %.

Ce grand écart entre 11 % et 80 % raconte une histoire simple : ce ne sont pas les petites structures qui portent le risque systémique, ce sont les géants boursiers. Plus une entreprise est grande, plus elle a industrialisé sa migration cloud, et plus elle a fini par concentrer ses charges critiques chez un ou deux fournisseurs pour simplifier ses opérations et négocier de meilleurs tarifs. Le rapport ajoute une précision géographique frappante : au sein même du FTSE 100, l’exposition se répartit presque à parts égales entre les régions cloud situées au Royaume-Uni ou en Irlande d’un côté, et des régions situées ailleurs (Europe continentale, côte est des États-Unis) de l’autre. Une panne n’a donc pas besoin de toucher le sol britannique pour paralyser une entreprise britannique.

Combien coûterait une panne selon sa durée et sa région

Le CMC et Parametrix ont modélisé plusieurs scénarios en croisant deux variables : la région cloud touchée et la durée de l’interruption. Ils ont retenu deux zones AWS comme cas d’école, parce qu’elles concentrent l’essentiel de l’exposition britannique : eu-west-1 à Dublin, la porte d’entrée européenne d’AWS, et us-east-1 en Virginie du Nord, la région historique et la plus densément utilisée au monde.

Scénario de panneRégion cloudDuréePertes directes estimées
Interruption courteAWS eu-west-1 (Dublin)12 heures402 M£
Interruption majeureAWS eu-west-1 (Dublin)24 heures≈ 1 Md£
Interruption prolongéeAWS eu-west-1 (Dublin)48 heures1,7 Md£
Interruption majeureAWS us-east-1 (Virginie)24 heures647 M£
Fourchette générale (région majeure UK/Irlande/Europe/côte est US)AWS ou Azure24 heures650 M£ à 1 Md£

Ces montants restent des pertes directes, hors effets en cascade. Le rapport insiste sur ce point : les répercussions sur les fournisseurs, les clients finaux et les secteurs interdépendants comme la logistique ou la distribution pourraient largement dépasser ces bornes. Computer Weekly résume ainsi la portée de l’étude : “Whether arising from a cyber attack or another form of disruption, a 24-hour outage affecting major Amazon Web Services (AWS) or Microsoft Azure cloud regions in the UK, Ireland, Europe or the eastern US could trigger major economic disruption across the UK, causing direct revenue losses of between £650m and £1bn.” (Computer Weekly, juillet 2026).

Dublin et Virginie : les deux points de rupture de l’économie britannique

Le rapport identifie deux points d’agrégation particulièrement sensibles, là où un grand nombre d’entreprises se retrouvent sans le savoir sur la même infrastructure physique. Autour de la région us-east-1 en Virginie, environ 20 000 entreprises britanniques sont exposées, représentant ensemble 857 milliards de livres de chiffre d’affaires, soit environ 12 % de l’économie du pays. Autour d’eu-west-1 à Dublin, ce sont environ 30 000 entreprises pour 801 milliards de livres de revenus cumulés.

The Register a résumé la mécanique en une phrase : “Its European AWS cloud region (eu-west-1) in Dublin and its primary US cloud region (us-east-1) in Northern Virginia are identified as the largest aggregation points where failures could trigger widespread economic disruption for Brit businesses.” (The Register, juillet 2026). Ce n’est donc pas la taille du fournisseur qui inquiète le CMC, mais la concentration géographique à l’intérieur même de ce fournisseur. Deux data centers, ou deux clusters de data centers, portent à eux seuls une part disproportionnée du PIB britannique.

Point de concentrationEntreprises exposéesChiffre d’affaires cumulé exposéPart de l’économie UK
AWS us-east-1 (Virginie du Nord)≈ 20 000857 Md£≈ 12 %
AWS eu-west-1 (Dublin)≈ 30 000801 Md£non chiffrée séparément
Ensemble des organisations UK dépendantes d’AWS, Azure ou GCP> 80 % des organisations FTSE 10064 % de l’économie pertinente (pondéré par le CA)–
FTSE 100 dépendant du cloud pour ses fonctions critiques> 80 entreprises sur 100–50/50 entre régions UK/Irlande et régions tierces

Un précédent déjà bien documenté : les pannes cloud coûtent cher partout

Le CMC ne part pas d’une hypothèse abstraite. Les grandes coupures cloud de ces dernières années ont chacune démontré la mécanique de la contagion. La panne AWS de décembre 2021 avait mis à l’arrêt des dizaines de plateformes qui n’avaient pourtant aucun lien apparent entre elles, simplement parce qu’elles partageaient la même région ou les mêmes services managés en coulisses. Plus récemment, la panne Google Cloud du 1er septembre 2026 dans la zone us-central1-b a montré comment une dégradation réseau isolée peut couper 15 services en même temps, de Compute Engine à BigQuery, en passant par Kubernetes Engine. Trois semaines plus tôt, une autre coupure GCP dans la région us-west1 avait touché plus de 20 produits pendant près de quatre heures. Ce ne sont pas des scénarios de laboratoire, ce sont des événements qui se sont réellement produits en l’espace d’un mois.

Le rapport CMC ne cite pas de coût précis pour ces incidents individuels, faute de données publiques suffisamment fines, mais il s’appuie sur leur récurrence pour justifier sa méthode de modélisation. La logique est actuarielle : un événement rare mais catastrophique se budgète comme un sinistre assurable, pas comme une anomalie qu’on peut ignorer.

Pourquoi les entreprises se sont autant concentrées sur trois fournisseurs

La concentration cloud ne relève pas d’un aveuglement collectif. Elle répond à une logique économique implacable. Migrer vers un hyperscaler unique permet de négocier des remises de volume, de mutualiser les compétences internes autour d’un seul écosystème d’outils, et de réduire la charge de certification de sécurité à un seul fournisseur plutôt qu’à trois ou quatre. Les équipes DevOps forment leurs ingénieurs sur une seule pile technique, ce qui accélère le recrutement et réduit les coûts de formation.

Le problème, souligne implicitement le rapport, c’est que cette rationalité individuelle produit un risque collectif. Chaque directeur financier a raison de vouloir baisser sa facture cloud en signant un contrat pluriannuel avec un seul fournisseur. Mais quand des dizaines de milliers d’entreprises font le même calcul et choisissent la même région pour des raisons de latence ou de conformité, elles créent, sans concertation, un point de défaillance commun. C’est exactement la définition d’un risque systémique : personne n’a l’intention de le créer, mais tout le monde y contribue.

La réponse européenne : souveraineté plutôt que simple résilience

Le rapport britannique pose une question de résilience opérationnelle : que se passe-t-il si l’infrastructure tombe en panne ? Sur le continent, le débat ajoute une dimension supplémentaire, celle du contrôle juridique et politique des données. La France a par exemple construit sa propre grille d’exigence avec la qualification SecNumCloud, que l’ANSSI a récemment étendue à un troisième acteur, OVHcloud, pour son offre de cloud public. L’Union européenne, de son côté, avance sur le Cloud and AI Development Act (CADA), qui vise à réduire la dépendance stratégique de l’Europe envers des fournisseurs non-européens en fixant des paliers de souveraineté numérique.

Le projet Gaia-X poursuit un objectif encore différent : il ne cherche pas à remplacer AWS, Azure ou Google Cloud, mais à garantir l’interopérabilité et la portabilité des données entre fournisseurs de confiance, pour éviter l’enfermement technique. Une étude publiée début septembre par ISG et relayée par Businesswire confirme que les entreprises françaises placent désormais la souveraineté des données au cœur de leurs choix d’architecture hybride, en particulier pour les charges liées à l’intelligence artificielle. Cette tendance se traduit aussi par des mouvements industriels concrets : l’éditeur américain Nutanix a annoncé fin septembre le rachat de la société française Ryax Technologies, spécialisée dans l’orchestration de charges d’IA sur infrastructures hybrides, un signal que le marché européen du cloud privé et hybride continue de s’organiser face aux trois hyperscalers américains.

DORA : l’Europe encadre déjà les fournisseurs cloud critiques

Contrairement au Royaume-Uni, qui découvre l’ampleur du problème via un rapport d’assureur, l’Union européenne dispose depuis peu d’un cadre réglementaire contraignant sur ce terrain précis : le règlement sur la résilience opérationnelle numérique, plus connu sous son acronyme DORA. Ce texte impose aux entités financières européennes de cartographier leurs dépendances envers les prestataires informatiques tiers, de tester leur capacité à résister à des scénarios de panne sévères mais plausibles, et surtout d’accepter la supervision directe de certains fournisseurs jugés critiques, y compris les grands hyperscalers, par les autorités européennes.

Ce système de désignation des prestataires tiers critiques ressemble beaucoup à la logique que le CMC appelle de ses vœux pour le Royaume-Uni : rendre visible, mesurable et gouvernable une dépendance qui, jusqu’ici, restait cachée dans les contrats commerciaux de chaque entreprise prise isolément. Le Royaume-Uni possède son propre régime de résilience opérationnelle, porté conjointement par la Banque d’Angleterre, la Prudential Regulation Authority et la Financial Conduct Authority, mais ce régime cible surtout les entités financières individuelles plutôt que la concentration cloud à l’échelle du pays.

DORA, CADA, SecNumCloud, Gaia-X : quatre réponses, quatre objectifs

Ces quatre initiatives se recoupent parfois dans la presse généraliste, ce qui entretient la confusion. Elles répondent pourtant à des questions différentes, et un tableau comparatif aide à clarifier qui fait quoi.

CadrePortée géographiqueQuestion poséeStatut fin septembre 2026
DORA (règlement UE)Union européenne, secteur financierLe fournisseur résiste-t-il à un incident sévère et sait-on le tester ?En application, supervision des tiers critiques en cours
CADA (Cloud and AI Development Act)Union européenne, tous secteursCombien de capacité cloud souveraine l’Europe doit-elle bâtir ?En discussion au niveau européen
SecNumCloud (ANSSI)France, données sensibles publiques et réguléesLe fournisseur est-il à l’abri de toute juridiction étrangère ?3 acteurs qualifiés, dont OVHcloud depuis le 1er septembre
Gaia-XUnion européenne, fédération de fournisseursLes données peuvent-elles circuler entre fournisseurs sans verrouillage ?Déploiement progressif, adoption inégale

Le multicloud, une fausse bonne réponse au risque de concentration

Face à ces chiffres, la première réaction d’un responsable technique consiste à répartir ses charges sur plusieurs fournisseurs. Le rapport CMC met toutefois en garde contre une lecture trop rapide de cette solution. Un déploiement multicloud protège contre la panne d’un seul fournisseur, mais il ne règle pas la question de la juridiction légale à laquelle restent soumises les données, ni celle de la portabilité réelle des charges de travail en cas d’urgence. Une entreprise peut très bien répartir ses serveurs entre AWS et Azure tout en restant, sur le plan juridique, entièrement dépendante du droit américain pour l’accès aux données.

Le multicloud coûte également cher à opérer correctement. Faire cohabiter deux piles techniques différentes multiplie les besoins de compétences internes, complique la gestion des identités et des accès, et augmente la surface d’attaque globale. Beaucoup de directions informatiques choisissent donc un compromis : un fournisseur principal pour l’essentiel des charges, et un second fournisseur, souvent européen, réservé aux données les plus sensibles ou les plus réglementées. C’est précisément la stratégie que documentait l’étude ISG citée plus haut pour les entreprises françaises.

Ce que cela change pour les assureurs et les marchés financiers

Le secteur de l’assurance cyber observe ce dossier avec une attention particulière, puisque c’est lui qui devra couvrir une partie de ces pertes en cas de sinistre réel. La publication du rapport CMC a été suivie de commentaires prudents de la part des assureurs, qui redoutent un phénomène d’agrégation de risque : si toutes leurs polices cyber couvrent des entreprises exposées à la même région AWS ou Azure, un seul incident majeur pourrait déclencher des milliers de sinistres simultanés, menaçant la solvabilité de l’assureur lui-même. C’est le même mécanisme qui inquiète les régulateurs bancaires depuis des années à propos des chambres de compensation financière, transposé cette fois au monde du cloud.

Pour les conseils d’administration des grandes entreprises cotées, le message est plus direct encore : la dépendance cloud devient un sujet de gouvernance à part entière, au même titre que le risque de change ou le risque de crédit fournisseur. Plusieurs cabinets d’audit recommandent désormais d’inclure une ligne dédiée à la concentration cloud dans les rapports annuels de gestion des risques, une pratique encore rare avant 2026.

Cinq prédictions pour les prochains mois

Ce rapport britannique ne restera probablement pas isolé. Voici cinq évolutions probables d’ici la fin de l’année 2026 et le début 2027.

  • D’autres régulateurs nationaux, en Allemagne ou en France, vont commander des études équivalentes pour chiffrer leur propre exposition à AWS, Azure et Google Cloud.
  • Les assureurs cyber vont durcir leurs clauses contractuelles liées à l’agrégation de risque cloud, en plafonnant leur exposition à une région donnée.
  • Le marché européen du cloud souverain et hybride, porté par OVHcloud, Scaleway et des rachats comme celui de Ryax Technologies par Nutanix, va continuer sa progression, sans pour autant faire reculer la part de marché des trois hyperscalers américains à court terme.
  • La Commission européenne va accélérer les discussions autour du CADA, en s’appuyant explicitement sur des données de concentration comme celles publiées par le CMC.
  • Les trois hyperscalers vont pousser commercialement leurs offres d’architecture multi-région comme réponse marketing directe à ce type de rapport, sans nécessairement modifier leur structure de concentration géographique réelle.

Ce que les entreprises françaises et européennes doivent retenir

Le Royaume-Uni n’a rien d’un cas isolé. La structure du marché cloud européen ressemble beaucoup à celle décrite par le CMC : mêmes trois fournisseurs dominants, mêmes régions de référence, mêmes logiques de négociation tarifaire poussant à la concentration. Une entreprise française qui héberge ses applications critiques sur eu-west-1 à Dublin partage exactement le même point de défaillance que ses homologues britanniques identifiées dans le rapport.

La différence tient surtout au calendrier réglementaire. Grâce à DORA, les entités financières européennes ont déjà commencé à cartographier cette dépendance sous la contrainte légale, alors que le Royaume-Uni, post-Brexit, avance sur un rythme distinct via ses propres régulateurs. Pour les secteurs non financiers, en revanche, aucune obligation comparable n’existe encore en Europe, ce qui laisse un angle mort exactement similaire à celui que le rapport CMC vient de documenter outre-Manche.

Questions fréquentes

Qu’est-ce que le Cyber Monitoring Centre ?
Le CMC est un organisme britannique indépendant, financé par le secteur de l’assurance et de la cybersécurité, chargé de classifier la gravité des incidents cyber et numériques majeurs au Royaume-Uni.

Combien coûterait exactement une panne cloud de 24 heures au Royaume-Uni ?
Le rapport CMC-Parametrix estime les pertes directes entre 650 millions et 1 milliard de livres sterling pour une panne de 24 heures touchant une région cloud majeure d’AWS ou d’Azure, hors effets en cascade.

Pourquoi les régions de Dublin et de Virginie sont-elles particulièrement à risque ?
Parce qu’elles concentrent le plus grand nombre d’entreprises britanniques dépendantes d’AWS : environ 30 000 entreprises pour eu-west-1 (Dublin) et 20 000 pour us-east-1 (Virginie), représentant à elles seules plus de 1 600 milliards de livres de chiffre d’affaires cumulé exposé.

Le multicloud résout-il vraiment le problème de concentration ?
Partiellement. Il réduit le risque de panne technique mais ne règle ni la question de la juridiction légale des données ni celle du coût opérationnel supplémentaire lié à la gestion de plusieurs piles techniques.

Quelle différence entre DORA, CADA, SecNumCloud et Gaia-X ?
DORA encadre la résilience des fournisseurs critiques pour le secteur financier européen. Le CADA vise à développer la capacité cloud souveraine de l’UE. SecNumCloud qualifie les fournisseurs pour les données sensibles françaises. Gaia-X promeut l’interopérabilité entre fournisseurs européens de confiance.

Les entreprises françaises sont-elles concernées par ce rapport britannique ?
Indirectement mais fortement. Le marché cloud français repose sur les mêmes trois hyperscalers et les mêmes régions de référence, notamment eu-west-1 à Dublin, ce qui expose les entreprises françaises à un risque de concentration comparable à celui décrit pour le FTSE 100.

Les fournisseurs cloud ont-ils réagi publiquement au rapport ?
Aucune réaction publique vérifiable d’AWS, de Microsoft Azure ou de Google Cloud n’a été recensée à ce jour concernant les conclusions spécifiques de ce rapport.

Ce type de scénario s’est-il déjà produit dans la réalité ?
Pas à l’échelle nationale décrite par le rapport, mais des incidents régionaux ont déjà démontré la mécanique de contagion, comme la panne AWS de décembre 2021 ou les coupures Google Cloud survenues en août et septembre 2026 dans les zones us-west1 et us-central1-b.