La panne cloud que votre clause de force majeure exclut déjà
La panne multirégion la plus susceptible de mettre votre activité totalement à l'arrêt est une action hostile délibérée. C'est aussi, très précisément, le scénario que le contrat de votre fournisseur, son SLA et votre police d'interruption d'activité sont chacun construits pour refuser. Cet écart n'est ni assuré, ni chiffré, et il pèse déjà sur votre bilan.
Ouvrez le contrat cadre de votre fournisseur cloud et cherchez la clause de force majeure. Le contrat client d'AWS place les événements échappant à son contrôle raisonnable hors de ses obligations, et cite la guerre et le terrorisme parmi eux. Cette seule phrase décide tranquillement qui paie quand tout s'effondre en même temps, et ce n'est pas le fournisseur. La panne la plus capable de mettre plusieurs régions à terre dans la même heure, une action hostile délibérée, est précisément la catégorie que le contrat exclut. Lisez votre propre texte : la convention est quasi universelle. Le sinistre à l'impact le plus corrélé est donc celui que votre fournisseur vous a déjà annoncé qu'il ne financera pas.
Le contrat de niveau de service (SLA) ne comble pas cette brèche, et ses propres chiffres le confirment. Le SLA Compute d'AWS verse un crédit de service de 10 % lorsque la disponibilité mensuelle descend sous 99,99 %, de 25 % sous 99 %, et de 100 % seulement sous 95 %, et chaque palier est un avoir sur la facture du service concerné, pas une compensation en numéraire pour l'activité perdue. Faites le calcul. Sur une dépense mensuelle à cinq chiffres, le versement maximal pour une panne catastrophique de plusieurs jours reste un avoir à cinq chiffres, utilisable uniquement chez le fournisseur qui vient de vous faire défaut. Le SLA n'a jamais été une assurance de continuité. C'est une ristourne de qualité de service, et le traiter comme un filet financier est la première erreur de tarification.
Reste l'assurance, et c'est là que la brèche s'élargit plutôt qu'elle ne se referme. Les polices d'interruption d'activité et de cyber-risque comportent, comme standard de marché, des exclusions pour faits de guerre et actions hostiles, et les assureurs les invoquent dès que le sinistre est important. NotPetya, le logiciel malveillant de 2017 qui a paralysé les opérations d'un groupe pharmaceutique multinational et lui a coûté bien au-delà du milliard, est devenu l'affaire de référence : la demande d'indemnisation a été rejetée au titre d'une exclusion pour «acte de guerre», et le contentieux a duré des années. La réponse du marché depuis a été de durcir, pas d'assouplir, le Lloyd's imposant désormais aux polices cyber autonomes d'exclure explicitement les attaques soutenues par un État. Les trois instruments qu'un comité de direction suppose capables d'absorber une panne corrélée, le contrat du fournisseur, le SLA et l'assurance, sont donc chacun conçus pour s'écarter précisément du scénario d'action hostile qui la provoque. Je décris ici la convention générale du marché, pas vos conditions particulières, et vous devez lire les vôtres. Mais si la panne corrélée est la panne non assurée, l'exposition ne disparaît pas pour autant. Elle retombe simplement, en silence, sur vous.
Combien coûte réellement une panne multirégion non assurée ?
Prenez une entreprise réalisant 60 millions d'euros de chiffre d'affaires annuel. Cela représente environ 165 000 € de chiffre d'affaires par jour ouvré. Supposons qu'un événement corrélé mette hors service les régions européennes de son fournisseur principal pendant trois jours, et supposons, comme le permet la rédaction ci-dessus, que le SLA et l'assurance interruption d'activité traitent tous deux la cause comme exclue. Le chiffre d'affaires directement en jeu avoisine les 500 000 €, avant de compter les pénalités contractuelles, l'image de marque, et les clients qui testeront discrètement un concurrent pendant que vous êtes hors ligne. Ces chiffres sont illustratifs, appliquez les vôtres, mais la structure tient : la perte n'est pas plafonnée et elle atterrit intégralement sur votre bilan, parce que les instruments censés l'absorber se sont tous récusés.
Pourquoi la redondance que vous avez payée n'élimine-t-elle pas ce risque ?
Parce que la redondance est calibrée pour l'accident, et qu'une attaque ciblée n'en est pas un. L'architecture multirégion repose sur une hypothèse : les pannes sont indépendantes. La probabilité que deux régions tombent dans la même fenêtre de temps est à peu près le produit de deux petits nombres, donc un nombre bien plus petit encore, ce qui rend une panne totale quasiment improbable. Face aux pannes matérielles, aux coupures de courant, aux erreurs de configuration ou aux intempéries, ce calcul tient. Un adversaire le brise en un seul geste, en choisissant votre région de Francfort et votre région de Dublin dans la même heure, parce qu'il a lu le même schéma d'architecture que vous avez dessiné. Dès lors que la panne est choisie plutôt que tirée au sort, l'indépendance s'annule, et avec elle le confort statistique qui rendait la redondance abordable. L'information qu'un client utilise pour concevoir son basculement est globalement celle qu'un attaquant utilise pour le déjouer, et les fournisseurs publient l'architecture générale par construction, précisément pour que vous puissiez vous organiser autour.
Pourquoi le risque de concentration cloud est-il désormais un enjeu de continuité d'activité ?
Deux évolutions ont fait basculer ce risque de la queue de distribution vers l'horizon de planification. Le parc s'est concentré : les données publiques de Synergy Research Group montrent que les trois plus grands fournisseurs représentent environ deux tiers du chiffre d'affaires mondial de l'infrastructure cloud, ce qui signifie que l'essentiel de la capacité des entreprises réside désormais dans une poignée de parcs, et c'est exactement ce qui transforme un acte hostile isolé en événement corrélé multi-clients. Le cadrage politique a évolué avec : l'administration américaine actuelle présente son plan d'action pour l'IA comme une stratégie destinée à conserver la suprématie technologique américaine, ce qui reclasse de fait les centres de données commerciaux en actifs stratégiques aux yeux de quiconque s'oppose à ce gouvernement. C'est aussi tout l'enjeu du débat européen sur la souveraineté numérique, du label SecNumCloud de l'ANSSI aux initiatives de «cloud de confiance» : la question n'est plus seulement réglementaire, elle est désormais de sécurité nationale. Vous n'avez pas besoin d'un incident nommé pour chiffrer ce risque, la concentration et la logique de ciblage suffisent en elles-mêmes. Les incidents ne font que le rendre concret, et il y a déjà eu des allégations, à traiter avec le scepticisme qu'exige toute déclaration en temps de guerre, visant des infrastructures de données commerciales comme cibles : les Gardiens de la révolution iraniens ont ainsi revendiqué une frappe contre une infrastructure de données d'Amazon à Bahreïn, une déclaration émanant d'une partie au conflit, sans confirmation indépendante rapportée. Même non prouvée, elle indique qu'un acteur considère désormais un centre de données commercial comme une cible militaire légitime. Les bâtiments n'ont pas changé. Ni leurs clôtures, ni leurs contrats, ni leur assurance n'ont changé. Seule la liste des cibles a changé.
Peut-on se préparer à la panne que l'on ne peut pas assurer ?
Vous ne pouvez pas racheter ce risque à l'intérieur d'un seul parc, et vous ne pouvez pas assurer la partie qui compte, donc l'atténuation doit être opérationnelle. Cessez de demander si votre fournisseur est résilient. Cette réponse dépend de la sécurité du site de quelqu'un d'autre et des intentions de quelqu'un d'autre. Posez la question qui vous appartient : que peut encore délivrer cette entreprise à 90 %, 50 % et 10 % de sa capacité, pendant combien de temps, et à quel coût pour les clients et la réputation ? La plupart des plans de continuité sont binaires. En marche ou à l'arrêt. «Basculer vers une autre région» est une hypothèse déguisée en plan. La dégradation progressive est peu coûteuse à spécifier, elle se teste, et elle survit au contact d'une panne corrélée qu'aucun chèque ne peut empêcher.
Décider à l'avance quels services vous sacrifiez en premier, lesquels vous maintenez coûte que coûte, et ce que signifie concrètement «tourner à 10 %» pour la prise de commandes ou la sécurité, relève de la même discipline que la conception de systèmes conçus pour rester maîtrisables sous pression, et cela doit figurer au cœur de votre stratégie technique, pas enterré dans une annexe que personne ne répète. Le multicloud mérite son coût pour la poignée de charges de travail qui doivent absolument survivre, parce qu'il supprime la corrélation liée à un parc unique qu'un attaquant exploite, mais il achète aussi une vraie complexité. Traitez-le comme une assurance ciblée pour ce qui doit survivre, pas comme une reconstruction généralisée.
Le cloud n'est pas le problème, et les fournisseurs ont construit de très bonnes machines pour les modes de panne qu'on leur a demandé de résoudre. La brèche se situe dans votre propre plan : la clause que vous n'avez jamais lue jusqu'au bout, le SLA que vous avez pris pour une couverture, et l'exposition que vous n'avez jamais chiffrée. Découvrez ce que votre clause de force majeure et votre police d'interruption excluent réellement, puis décidez de ce que vous pourrez encore faire tourner quand l'exclusion se produira. C'est un travail à mener avant le prochain projet, pas après la prochaine alerte.
Questions fréquentes
Mon SLA ou mon assurance interruption d'activité indemnisera-t-elle une attaque délibérée contre un centre de données ?
Souvent non. Les clauses de force majeure des fournisseurs cloud citent la guerre et le terrorisme parmi les événements échappant à leurs obligations, et les polices cyber et interruption d'activité comportent des exclusions pour actions hostiles que les assureurs invoquent sur les sinistres importants, comme l'a montré le contentieux NotPetya. Les crédits de service du SLA ne remboursent qu'un pourcentage plafonné de votre facture pour le service concerné, jamais l'activité perdue. Lisez le contrat de votre fournisseur et votre police d'assurance plutôt que de supposer que le scénario le plus dommageable est couvert.
Comment estimer mon exposition non assurée à la concentration cloud ?
Partez du chiffre d'affaires quotidien qui dépend des systèmes concernés, multipliez par une durée de panne réaliste pour un événement corrélé, puis ajoutez les pénalités contractuelles et une estimation raisonnée de l'attrition client et du coût réputationnel. Soustrayez uniquement ce que votre police et votre SLA verseraient réellement au titre d'une cause exclue, ce qui est souvent proche de zéro. Le solde est le montant qui pèse, non chiffré, sur votre bilan.
Comment construire un plan de dégradation progressive face aux pannes cloud ?
Définissez ce que l'entreprise délivre à 90 %, 50 % et 10 % de sa capacité, décidez quels services vous sacrifiez et lesquels vous maintenez coûte que coûte, puis chiffrez les conséquences client et réputationnelles de chaque palier. Ensuite, répétez-le. L'objectif est de transformer une hypothèse binaire (en marche ou à l'arrêt) en décisions testées, exécutables sous pression, puisque c'est le levier d'atténuation que vous maîtrisez quand l'assurance et le SLA s'effacent.
À lire aussi
- La prime de souveraineté : pourquoi les entreprises paient plus cher une IA qu'aucun gouvernement étranger ne pourra couper
- Lunettes connectées au bureau : le voyant ne protège plus personne
- La sécurité de l'IA n'est pas un frein, c'est un fossé
- Security & Trust
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.