Le 15 septembre 2026, Amazon Web Services a mis à jour son tableau de bord de disponibilité avec une phrase que peu de clients cloud avaient déjà lue en six ans de service. L’entreprise a écrit ne pas pouvoir restaurer l’accès aux ressources et données hébergées exclusivement dans sa région de Bahreïn. Six mois après des frappes de drones qui ont endommagé ses installations pendant le conflit au Moyen-Orient, le premier fournisseur cloud mondial admet une perte de données définitive. C’est une première pour un hyperscaler de cette taille, et la nouvelle inquiète autant les responsables informatiques du Golfe que ceux d’Europe, où les promesses de résilience multi-zone servent d’argument commercial depuis quinze ans.
Cet article revient sur les faits connus, remonte la chronologie depuis mars 2026, compare l’incident aux grandes pannes qui ont marqué l’histoire du cloud et évalue ce que cela signifie concrètement pour les entreprises qui traitent avec AWS depuis la France ou ailleurs en Europe.
Ce que dit exactement AWS depuis le 15 septembre 2026
La mise à jour du 15 septembre porte sur deux régions distinctes du Moyen-Orient : Bahreïn (me-south-1) et les Émirats arabes unis (me-central-1). Pour Bahreïn, AWS a été net sur son tableau de bord de santé, cité par CNBC et par plusieurs autres médias le même jour.
« Après une évaluation approfondie, nous avons déterminé que nous ne sommes pas en mesure de restaurer l’accès aux ressources et données hébergées exclusivement dans cette région. »
AWS, mise à jour du tableau de bord de santé, 15 septembre 2026
Pour les Émirats, la formulation est presque identique, mais elle s’applique à une seule des trois zones de disponibilité de me-central-1, la région restant globalement fonctionnelle pour le reste de ses capacités. AWS ajoute, dans une phrase reprise par The Register et par HelpNetSecurity, une précision technique qui a fait réagir de nombreux architectes cloud sur les réseaux professionnels.
« Les dégâts causés à notre infrastructure ont touché plusieurs zones de disponibilité et dépassent ce que nos services régionaux et multi-AZ sont conçus pour supporter. »
AWS, tableau de bord de santé, cité par The Register
Cette dernière phrase mérite un temps d’arrêt. La conception multi-AZ d’AWS repose sur l’idée qu’une panne localisée dans une zone de disponibilité ne doit jamais entraîner de perte totale, puisque les données répliquées ailleurs prennent le relais. En admettant que les dégâts dépassent ce que le système est censé encaisser, AWS reconnaît que son modèle de résilience a rencontré un scénario pour lequel il n’avait pas été dimensionné : une attaque militaire touchant plusieurs zones en même temps.
Six mois de silence relatif : la chronologie complète
Mars 2026 : les frappes qui ont tout changé
Le 2 mars 2026, AWS confirme pour la première fois que des frappes de drones ont touché ses installations aux Émirats arabes unis et à Bahreïn dans le cadre du conflit régional en cours. Selon InfoQ, deux installations aux Émirats sont directement frappées, et l’entreprise recommande alors publiquement à ses clients hébergeant des données à Bahreïn de les répliquer d’urgence vers d’autres régions. Le message est sans détour sur son tableau de bord de l’époque, cité par plusieurs rédactions dont Fortune.
« Ces frappes ont causé des dommages structurels, perturbé l’alimentation électrique de notre infrastructure et, dans certains cas, nécessité des opérations de lutte contre l’incendie qui ont provoqué des dégâts des eaux supplémentaires. »
AWS, mise à jour de mars 2026, citée par Fortune
Le tournant du 15 septembre 2026
Pendant six mois, AWS a maintenu ces deux régions en statut dégradé, migrant des charges de travail et remplaçant du matériel là où c’était possible. Le 15 septembre, le discours change de nature : ce n’est plus une panne prolongée, c’est une déclaration de perte permanente. Le quotidien économique en ligne Boursorama, qui republie une dépêche Reuters, résume la bascule en une phrase, tout comme le média québécois Noovo Info, qui cite AWS affirmant avoir « épuisé toutes les options » pour restaurer les données non migrées à Bahreïn. Entre la première alerte de mars et l’aveu de septembre, six mois se sont écoulés sans qu’aucun bilan chiffré ne soit rendu public.
me-south-1 et me-central-1 : ce qui reste, ce qui a disparu
Les deux régions concernées n’ont pas le même statut au 19 septembre 2026. Le tableau ci-dessous synthétise ce que les communications officielles et la presse spécialisée permettent d’établir avec certitude.
| Région AWS | Zones de disponibilité | Statut au 15 septembre 2026 | Cause déclarée |
|---|---|---|---|
| Moyen-Orient (Bahreïn) – me-south-1 | Région entière concernée | Données et ressources exclusives inaccessibles de façon définitive | Frappes de drones, mars 2026 |
| Moyen-Orient (Émirats) – me-central-1 | 1 zone sur 3 perdue | Zone touchée irrécupérable, les deux autres zones opérationnelles | Deux installations directement frappées, mars 2026 |
| Autres régions AWS mondiales | Non concernées | Fonctionnement normal signalé | Sans objet |
Le détail technique compte. AWS ne parle pas d’un simple ralentissement ou d’une bascule de trafic. L’entreprise évoque des données « hébergées exclusivement » dans la zone touchée, ce qui signifie que les clients n’ayant pas activé de réplication vers une autre région n’ont, à ce stade, aucun moyen de récupérer quoi que ce soit. Le message publié dès mars sur le tableau de bord recommandait déjà cette réplication, une manière pour AWS de rappeler que la responsabilité de la continuité d’activité reste, contractuellement, largement du côté du client.
Ce qu’AWS ne dit pas : les zones d’ombre de l’incident
Un an après le début du conflit régional et six mois après les premières frappes, plusieurs informations restent absentes des communications d’AWS. L’entreprise n’a donné aucun chiffre sur le nombre de clients ou d’organisations touchés par la perte définitive de données. Elle n’a pas non plus publié de liste des services précisément affectés, se contentant de parler de « ressources et données » de façon générique. La presse spécialisée, dont CyberSecurityNews, a tenté d’obtenir des précisions supplémentaires sans succès à ce stade.
Aucun régulateur européen n’a, à la date de publication de cet article, pris position publiquement sur ce dossier. Ni l’ANSSI, ni l’ENISA, ni la Commission européenne n’ont émis de communiqué reliant explicitement cet incident aux débats en cours sur la souveraineté numérique du continent. Cette absence de réaction officielle est en soi une donnée : elle montre qu’un événement d’une gravité inédite pour l’industrie cloud peut se produire loin d’Europe sans déclencher immédiatement de réponse réglementaire, alors même que les mêmes fournisseurs opèrent des infrastructures jugées critiques sur le sol européen.
La fin d’un dogme : la haute disponibilité mise à l’épreuve
Depuis le lancement du cloud public, l’argument commercial central des hyperscalers tient en une promesse simple : répartissez vos charges sur plusieurs zones de disponibilité, et aucun sinistre local ne vous fera perdre vos données. Cette architecture a résisté à des pannes électriques, à des erreurs humaines et à des bugs logiciels majeurs. Elle n’avait jamais, jusqu’ici, été testée par une attaque militaire visant simultanément plusieurs installations physiques dans la même zone géographique.
L’aveu d’AWS ne remet pas en cause le principe de la haute disponibilité en tant que tel. Il révèle plutôt une limite que peu d’architectes évoquaient publiquement avant 2026 : la résilience multi-AZ suppose que les zones d’une même région restent suffisamment indépendantes les unes des autres sur le plan physique. Quand un conflit armé frappe plusieurs installations dans un rayon de quelques kilomètres en même temps, cette indépendance s’effondre. Le raisonnement vaut pour Bahreïn et les Émirats, mais il interroge aussi les régions AWS, Azure ou Google Cloud installées dans d’autres zones géopolitiquement sensibles.
Un précédent historique : quand le cloud brûle, gèle ou tombe en panne
Ce n’est pas la première fois qu’un incident majeur frappe une infrastructure cloud mondiale, mais la cause change tout. Le tableau ci-dessous replace l’épisode de Bahreïn dans une série d’incidents qui ont, chacun à leur manière, marqué l’histoire récente du secteur.
| Incident | Date | Cause | Ampleur / durée | Perte de données |
|---|---|---|---|---|
| Panne AWS S3 US-EAST-1 | 28 février 2017 | Commande erronée d’un opérateur | Environ 4 heures d’indisponibilité majeure | Aucune perte permanente confirmée |
| Incendie OVHcloud Strasbourg (SBG2) | 10 mars 2021 | Incendie du site SBG2, 4 salles sur 12 détruites à SBG1 | 27,8 M€ d’avoirs accordés aux clients | Non confirmée publiquement de façon explicite |
| Panne mondiale Fastly | 8 juin 2021 | Bug logiciel latent déclenché par une configuration client | Environ 45 à 60 minutes, sites majeurs indisponibles | Aucune |
| Panne CrowdStrike / Microsoft | 19 juillet 2024 | Mise à jour défectueuse du capteur Falcon sous Windows | Environ 8,5 millions d’appareils Windows touchés | Aucune perte de données signalée |
| Panne mondiale Google Cloud | 12 juin 2025 | Mise à jour de quota invalide déployée mondialement | Environ 3 heures, 13 services cloud touchés | Aucune |
| Perte de données AWS Bahreïn / Émirats | Mars à septembre 2026 | Frappes de drones pendant un conflit armé | 1 région et 1 zone sur 3 déclarées irrécupérables | Confirmée pour les données non répliquées |
Ce classement met en évidence une rupture. Les cinq premiers incidents partagent un point commun : une cause humaine ou logicielle, corrigible en quelques heures, sans destruction physique des installations. Notre couverture de la panne Google Cloud survenue sur us-central1-b illustre bien ce type de scénario réversible. L’épisode de Bahreïn appartient à une autre catégorie, celle où le bâtiment lui-même cesse d’exister en tant qu’infrastructure exploitable. Aucun correctif logiciel ne répare un site frappé par un drone.
OVHcloud Strasbourg, AWS Bahreïn : deux sinistres, deux logiques
La comparaison avec l’incendie d’OVHcloud à Strasbourg revient spontanément dans les échanges entre professionnels du secteur depuis le 15 septembre. Les deux événements partagent la destruction physique d’un site, mais leurs logiques diffèrent sur plusieurs points. OVHcloud avait, selon ses propres communications reprises par Computer Weekly, réagi en quelques jours en mobilisant du matériel de secours stocké à Roubaix et à Gravelines, avec l’objectif de remettre en service la majorité des clients affectés rapidement.
AWS a suivi une trajectoire inverse : six mois de statut dégradé avant l’aveu d’irréversibilité. Cette différence de tempo s’explique en partie par le contexte, un conflit armé actif rend toute intervention sur site nettement plus risquée qu’un sinistre industriel classique. Mais elle souligne aussi une différence de communication. OVHcloud avait publié des mises à jour fréquentes et détaillées dès les premières heures. AWS, de son côté, a distillé l’information par étapes, sans jamais confirmer publiquement un décompte précis des données perdues, ni à Bahreïn ni à Dubaï.
Quatre causes, une même leçon pour les responsables informatiques
En mettant côte à côte les grandes pannes du tableau précédent, un enseignement se dégage pour les décideurs qui arbitrent entre AWS, Azure, Google Cloud, OVHcloud ou d’autres acteurs. Chaque fournisseur a, à un moment donné, révélé un mode de défaillance différent : une commande humaine mal exécutée chez AWS en 2017, un bug logiciel latent chez Fastly, un incendie chez OVHcloud, une mise à jour non validée avant déploiement mondial chez Google Cloud, une attaque physique chez AWS en 2026. Aucun fournisseur, quelle que soit sa taille ou son budget d’investissement, n’a démontré une immunité totale face à l’ensemble de ces scénarios.
La conséquence pratique pour une direction des systèmes d’information n’est pas de choisir un fournisseur « plus sûr » qu’un autre dans l’absolu, mais d’évaluer où chaque charge de travail critique est physiquement hébergée, et si une réplication multi-région ou multi-fournisseur existe réellement, au-delà des cases cochées dans un contrat. Notre analyse de l’ouverture d’une quatrième zone AWS à Londres montre d’ailleurs qu’AWS continue d’investir massivement dans des zones jugées stables, ce qui suggère que l’entreprise distingue déjà, en interne, les régions à risque géopolitique élevé des autres.
Quel impact pour les entreprises qui opèrent depuis l’Europe ?
Aucune source consultée ne permet d’établir une liste d’entreprises européennes directement affectées par la perte de données à Bahreïn ou aux Émirats. AWS n’a pas publié la part de son chiffre d’affaires générée par ces deux régions, ni le nombre d’organisations qui y hébergent des charges de travail. Cette absence de transparence rend tout chiffrage précis du dommage économique impossible à ce stade, et il serait imprudent d’avancer un montant qui ne reposerait sur aucune source vérifiable.
Ce qui est en revanche établi, c’est que de nombreux groupes européens actifs dans l’énergie, la logistique, la banque ou le tourisme opèrent des filiales ou des partenariats dans le Golfe, et utilisent fréquemment les régions cloud les plus proches pour des raisons de latence ou de conformité locale. Pour ces entités, la question n’est plus théorique, elle porte sur la vérification immédiate de leurs propres politiques de réplication vers des régions hors zone de conflit. Le débat rejoint celui, plus large, du niveau d’investissement mondial dans le cloud, où une partie significative des budgets part dans une redondance mal configurée plutôt que dans une résilience réellement testée.
Contrats cloud et clauses de force majeure : qui paie la facture ?
La plupart des contrats de service cloud, y compris ceux d’AWS, incluent des clauses de force majeure qui excluent explicitement les conflits armés, les actes de guerre et les catastrophes naturelles de la garantie de disponibilité. Ces clauses existaient bien avant 2026, mais elles restaient largement théoriques pour la majorité des clients, qui ne les lisaient jamais en détail faute de scénario crédible d’application. L’épisode de Bahreïn leur donne, pour la première fois à cette échelle, un cas d’usage concret.
Concrètement, un client dont les données étaient hébergées exclusivement à Bahreïn et qui n’avait pas activé de réplication vers une autre région dispose de très peu de recours contractuels contre AWS. Les accords de niveau de service standards prévoient des crédits financiers en cas d’indisponibilité, pas d’indemnisation pour destruction physique liée à un conflit. C’est un rappel utile pour toute équipe juridique chargée de négocier des contrats cloud, la clause de force majeure n’est pas un détail administratif, elle définit qui supporte réellement le risque en dernier ressort.
Vers une révision des cartes d’implantation des hyperscalers ?
L’incident relance une question que les fournisseurs cloud préfèrent généralement éviter en public : faut-il continuer à ouvrir des régions dans des zones à risque géopolitique élevé, ou concentrer les nouveaux investissements dans des territoires jugés plus stables ? Le choix n’est pas neutre commercialement, car une présence locale reste un argument fort pour les clients soumis à des contraintes de résidence des données. Notre couverture de l’ouverture du cloud souverain européen d’AWS illustre d’ailleurs la direction inverse prise par l’entreprise sur le continent, avec des investissements présentés comme durables et non exposés au même type de risque.
En Europe, cette tension nourrit aussi le débat sur les alternatives locales. Des acteurs comme OVHcloud, dont la troisième qualification SecNumCloud a été obtenue cette année, mettent en avant une implantation géographique concentrée sur le territoire européen comme argument de stabilité, quand bien même cette concentration présente elle-même d’autres types de risques, comme l’a montré l’incendie de Strasbourg en 2021.
La souveraineté numérique européenne, un débat relancé sans réponse officielle
Le silence des autorités européennes sur ce dossier précis tranche avec l’intensité des débats sur la souveraineté numérique qui animent Bruxelles et Paris depuis plusieurs années. L’ANSSI, l’ENISA et la Commission européenne se sont montrées actives sur des sujets connexes, de la certification cloud à la cryptographie post-quantique, mais aucune n’a pour l’instant pris la parole sur les implications de cet incident précis pour les clients européens d’AWS.
Cette absence peut s’expliquer simplement, l’incident touche des régions hors Union européenne, et aucune fuite de données personnelles de citoyens européens n’a été signalée à ce jour. Mais elle illustre aussi une limite structurelle du cadre réglementaire actuel, pensé pour encadrer des pannes techniques ou des failles de sécurité, beaucoup moins pour des scénarios de destruction physique d’infrastructure liés à un conflit armé à l’étranger, alors même que les mêmes hyperscalers gèrent des infrastructures jugées critiques sur le sol européen.
Cinq prévisions pour la suite
- Les grandes entreprises actives dans le Golfe vont accélérer l’audit de leurs politiques de réplication multi-région, avec une priorité donnée aux charges de travail critiques encore hébergées exclusivement à Bahreïn ou dans la zone touchée aux Émirats.
- AWS devrait publier, dans les prochains mois, des recommandations techniques plus détaillées sur la réplication inter-régions pour les zones jugées sensibles, sans nécessairement communiquer de chiffres sur l’ampleur exacte de la perte de Bahreïn.
- Les clauses de force majeure des contrats cloud vont faire l’objet d’une attention accrue de la part des directions juridiques et des cabinets de conseil, un mouvement déjà amorcé après l’incendie d’OVHcloud en 2021.
- Les fournisseurs concurrents vont mettre en avant, dans leurs discours commerciaux, la localisation de leurs régions comme critère de différenciation face au risque géopolitique, sans pour autant s’engager sur des garanties contractuelles nouvelles.
- Le débat sur la souveraineté numérique européenne va intégrer, au moins dans les discours publics, la dimension du risque physique et géopolitique des infrastructures situées hors d’Europe, en complément des sujets déjà installés comme le contrôle juridique des données.
Foire aux questions
Qu’est-ce qu’AWS a annoncé exactement le 15 septembre 2026 ?
AWS a mis à jour son tableau de bord de santé pour indiquer qu’elle ne peut plus restaurer l’accès aux données et ressources hébergées exclusivement dans sa région de Bahreïn, ainsi que dans une des trois zones de disponibilité de sa région des Émirats arabes unis. Il s’agit d’une perte de données jugée définitive pour les charges de travail non répliquées ailleurs.
Pourquoi les régions AWS de Bahreïn et des Émirats ont-elles été endommagées ?
Selon les communications d’AWS elles-mêmes, des frappes de drones survenues en mars 2026, dans le cadre du conflit régional au Moyen-Orient, ont causé des dommages structurels, coupé l’alimentation électrique de certaines installations et provoqué des dégâts des eaux liés aux opérations de lutte contre l’incendie.
Les données perdues chez AWS peuvent-elles être récupérées un jour ?
Selon la communication officielle d’AWS, non, pour les données hébergées exclusivement dans les zones déclarées irrécupérables. L’entreprise indique avoir procédé à une évaluation approfondie avant de conclure à l’impossibilité de restaurer l’accès.
Combien de clients sont concernés par cette perte de données AWS ?
AWS n’a communiqué aucun chiffre public sur le nombre de clients ou d’organisations affectés. Aucune source vérifiable ne permet, à ce stade, d’avancer une estimation fiable.
Une entreprise européenne peut-elle être touchée par cet incident ?
Aucune organisation européenne n’a été nommément identifiée dans la presse comme affectée. Des filiales ou partenaires de groupes européens actifs dans le Golfe et hébergeant des données dans ces régions pourraient toutefois être concernés s’ils n’avaient pas mis en place de réplication vers une autre région AWS.
Que dit le contrat AWS en cas de dommages liés à un conflit armé ?
Comme la plupart des contrats de service cloud, les conditions d’AWS incluent des clauses de force majeure qui excluent les conflits armés des garanties de disponibilité standards. Les crédits de service prévus en cas de panne ne couvrent pas la destruction physique d’infrastructure liée à un acte de guerre.
Cet incident est-il comparable à l’incendie d’OVHcloud à Strasbourg en 2021 ?
Les deux événements impliquent une destruction physique de sites, mais leur origine diffère, un conflit armé pour AWS, un incendie industriel pour OVHcloud. La gestion de crise a aussi suivi des rythmes différents, OVHcloud ayant communiqué plus rapidement et plus en détail dans les jours suivant le sinistre.
Comment se protéger d’une perte de données définitive dans le cloud ?
La mesure de fond reste la réplication active des données critiques vers au moins une autre région géographiquement éloignée, idéalement chez un second fournisseur pour les charges de travail les plus sensibles. Vérifier les clauses de force majeure du contrat cloud et tester régulièrement les procédures de reprise d’activité complètent cette approche, plutôt que de se reposer uniquement sur la promesse commerciale de haute disponibilité du fournisseur.
