Début mars 2026, des installations AWS au Moyen-Orient ont subi un impact physique majeur : incendie, coupures d’alimentation, indisponibilité sévère de plusieurs zones dans la région. Le type d’incident qu’on lit dans une dépêche, qu’on partage sur LinkedIn, et qu’on oublie rapidement parce qu’on n’est pas dans la région concernée.
Mais le vrai sujet n’est pas technique. Et il concerne toutes les organisations qui ont migré une partie significative de leur infrastructure vers le cloud, quelle que soit leur géographie.
La question que cet incident pose vraiment
Qui gouverne réellement le risque de dépendance cloud dans votre organisation ?
Trop souvent, personne ne le gouverne vraiment. Le sujet est traité comme une question d’architecture, délégué aux équipes infrastructure, encadré par des SLA contractuels avec l’hyperscaler, et considéré comme réglé. Jusqu’au moment où une région devient indisponible pendant 36 heures et que personne autour de la table de crise n’a de réponse claire à des questions pourtant simples.
Quel niveau de dépendance à un fournisseur avions-nous accepté ? Quels scénarios d’indisponibilité avions-nous explicitement validés ? Quel niveau d’interruption l’activité peut-elle réellement supporter ? Qui a arbitré entre le coût, la complexité et la résilience ? Et surtout, qui porte la responsabilité si une zone cloud disparaît pendant deux jours ?
Ce ne sont pas des questions techniques. Ce sont des questions de gouvernance.
Le cloud déplace les responsabilités, il ne les supprime pas
Voilà l’illusion dans laquelle beaucoup d’organisations se sont installées confortablement. En choisissant un hyperscaler réputé, avec des certifications solides et un historique de disponibilité impressionnant, on a l’impression d’avoir externalisé le risque. En réalité, on a externalisé l’infrastructure. Le risque, lui, reste dans le bilan de l’entreprise.
Une gouvernance mature du risque cloud ne se résume pas à choisir AWS, Azure ou GCP et négocier un bon contrat. Elle suppose d’inscrire la dépendance cloud dans la cartographie des risques de l’entreprise, au même titre qu’un risque fournisseur critique. De relier les choix d’architecture aux enjeux métier réels, pas seulement aux contraintes techniques. De challenger régulièrement le PRA et le PCA sur des scénarios extrêmes mais plausibles, pas seulement sur des coupures de quelques minutes. D’encadrer l’infogérance avec des exigences de résilience réellement testées, pas seulement déclarées dans un document contractuel. Et de porter ces arbitrages au bon niveau : DSI, direction générale, direction des risques, sans les déléguer silencieusement à des équipes techniques qui n’ont pas vocation à trancher seules
L’angle mort de la gouvernance cloud
Une panne cloud, même sévère, se gère. La véritable fragilité n’est pas la panne elle-même, mais de réaliser au moment le plus critique que personne dans l’organisation n’avait réellement arbitré le niveau de dépendance acceptable. Que le PRA existe sur le papier mais n’a jamais été testé sur un scénario de perte totale d’une région. Que les équipes métier pensaient que l’infrastructure était redondée, et que les équipes techniques pensaient que le métier avait accepté le risque résiduel.
La résilience cloud déborde largement du périmètre de l’infrastructure. Elle relève de la gouvernance, de la responsabilité et de la continuité d’activité. L’incident AWS au Moyen-Orient ne changera probablement rien pour la plupart des organisations qui l’ont lu en diagonale. Il aurait dû être le déclencheur d’une conversation au bon niveau.
Dans votre organisation, le scénario « perte d’une région cloud pendant 48 heures » est-il traité comme un sujet technique ou comme un sujet de gouvernance ?
Basom Consulting accompagne les directions générales et DSI dans la structuration de leur gouvernance cloud. Si vous souhaitez évaluer votre niveau de maturité sur ce sujet, prenez contact avec nos équipes.
