Bâtir des environnements cloud résilients dès le premier jour

La résilience coûte moins cher à concevoir qu’à rajouter après coup. Cette phrase sonne comme un lieu commun de consultant, jusqu’à ce qu’on ait vu la facture de l’alternative — et en 2026, les régulateurs européens ont commencé à l’envoyer.

En octobre 2025, une panne chez un grand fournisseur cloud a mis hors service des pans entiers d’internet. Parmi les organisations touchées figuraient des banques de détail dont les clients ont simplement constaté, ce matin-là, que leur banque ne fonctionnait pas. Ce qui a rendu l’épisode marquant n’est pas la panne elle-même — il y en a — mais sa lecture réglementaire. Selon les règles européennes, un établissement ne peut pas qualifier la défaillance de son fournisseur cloud d’événement externe échappant à son contrôle. L’obligation de continuité pèse sur l’établissement.

C’est un déplacement notable de la responsabilité, et il s’est opéré discrètement. Pendant une décennie, migrer vers le cloud a été implicitement compris comme un transfert du risque opérationnel vers un acteur mieux armé pour le porter. La réglementation dit désormais autre chose : vous pouvez déléguer l’exploitation, vous conservez la responsabilité.

Le règlement sur la résilience opérationnelle numérique s’applique aux entités financières européennes depuis janvier 2025. Au cours de 2026, l’accent est passé de l’accompagnement à la supervision : les régulateurs attendent désormais que la résilience soit intégrée aux opérations quotidiennes, et non décrite dans des documents de politique. Sa portée dépasse largement les banques — prestataires de paiement, assureurs, gestionnaires d’actifs, plateformes de négociation et prestataires de services sur crypto-actifs sont concernés, et les fournisseurs technologiques hors UE sont saisis à travers les clients qu’ils servent.

En novembre 2025, les autorités européennes de surveillance ont publié une première liste de dix-neuf prestataires tiers de services TIC désignés comme critiques, incluant les trois plateformes cloud hyperscale ainsi que de grands fournisseurs de données, de logiciels et de télécommunications. Ces prestataires font désormais l’objet d’une supervision directe. Pour tous les autres, la conséquence pratique est l’obligation de documenter leur dépendance et d’évaluer le risque de concentration qu’elle engendre.

Deux dispositions méritent une attention particulière. L’une impose d’évaluer le risque de concentration et de pouvoir quitter un prestataire sans perturbation excessive. L’autre exige que les contrats couvrant des fonctions critiques comportent des clauses de sortie et de transition réellement praticables. Lues ensemble, elles fixent une exigence que beaucoup trouveront inconfortable : un droit de sortie que personne ne saurait exercer est exactement ce que les superviseurs vont sonder.

La plupart des organisations savent nommer leur fournisseur cloud principal. Bien moins savent décrire leur exposition réelle, car la concentration se dissimule au second niveau. Une entreprise peut répartir ses propres charges sur deux fournisseurs et se croire diversifiée — alors qu’une douzaine de ses prestataires SaaS critiques reposent tous sur la même plateforme, souvent dans la même région.

C’est l’exposition que je rencontre le plus souvent en examinant un patrimoine cloud, et elle est rarement délibérée. Elle s’accumule : un outil de paie ici, une plateforme de trésorerie là, un fournisseur d’identité, un service de signature électronique. Chacun acheté séparément, chacun parfaitement raisonnable isolément, et collectivement un point de défaillance unique qui ne figure sur aucun schéma d’architecture.

Concevoir la résilience dès le départ relève surtout de décisions : où réside l’état, comment les services se dégradent, ce qui est sans état, comment bascule l’identité, où sont conservées les sauvegardes. Ces décisions coûtent peu tant qu’elles restent des décisions. Elles deviennent coûteuses une fois transformées en implémentations contenant des données.

Le tableau réglementaire le confirme. Une étude de Deloitte relevait qu’environ la moitié seulement des établissements espéraient une conformité complète fin 2025, une part substantielle repoussant son objectif à 2026. Plus frappant encore : lors de l’exercice à blanc des autorités de surveillance, seules 6,5 % de près d’un millier d’entités ont passé l’ensemble des contrôles qualité sur leur registre d’information. L’écart n’est pas un problème d’intention. C’est que documenter la résilience suppose de savoir, sur son propre patrimoine, des choses que la plupart des organisations n’ont jamais eu à consigner.

Les trois questions qui révèlent la vérité

Quand je veux évaluer rapidement si un environnement cloud est réellement résilient, je pose trois questions. Comment ce service se comporte-t-il lorsque sa base de données est indisponible — échoue-t-il bruyamment, se dégrade-t-il proprement, ou se corrompt-il silencieusement ? Quand a-t-on effectué pour la dernière fois une restauration complète depuis une sauvegarde, jusqu’à un environnement fonctionnel ? Et s’il fallait déplacer cette charge chez un autre fournisseur, qui le ferait, avec quelle procédure, dans quel délai ?

De bonnes fondations n’ont rien d’exotique. Ce sont quelques principes appliqués avec constance, idéalement avant la première charge de production.

Si DORA ne vous concerne pas directement, il vous atteindra probablement de façon indirecte. Les entités financières sont désormais contractuellement tenues de répercuter les exigences de résilience sur leurs fournisseurs : toute entreprise technologique servant une banque ou un assureur européen rencontrera donc ces attentes par la voie des achats plutôt que par celle de la réglementation.

Il existe aussi un argument purement commercial. Les organisations que je vois emporter des contrats grands comptes sont de plus en plus celles qui répondent vite et preuves à l’appui aux questions de résilience. Pouvoir produire une cartographie des dépendances, un temps de reprise testé et une trajectoire de sortie documentée est devenu un atout commercial, et pas seulement un artefact de conformité.

Personne ne reconstruit un patrimoine en un trimestre. Mais la séquence qui permet de regagner du terrain le plus vite est assez constante.

L’adoption du cloud a apporté vitesse, élasticité et portée, et bien peu d’organisations reviendraient en arrière. Ce qu’elle n’a pas fait, c’est supprimer le risque opérationnel : elle l’a déplacé, et ce déplacement est resté un temps invisible. La réglementation l’a rendu visible, ce qui est inconfortable à court terme et utile à long terme.

Le travail n’a rien de spectaculaire. Cartographies de dépendances, tests de restauration, procédures de sortie et un indicateur trimestriel présenté au conseil. C’est pourtant ce qui sépare une organisation qui traverse un incident de celle qui traverse une crise — et cet écart se décide généralement des mois avant la mauvaise nuit.

À propos de l’auteur

Loick Moukouri

Fondateur d’Auvantyx

Loick Moukouri est le fondateur d’Auvantyx. Son parcours associe la comptabilité et la finance à la cybersécurité, au cloud et aux technologies numériques. Il pilote la vision du cabinet, son offre de services et son réseau de spécialistes afin d’aider les organisations à transformer leurs priorités métier en décisions technologiques, sécuritaires et de gestion des risques concrètes.

Contact contact@auvantyx.com