Un nouveau guide stratégique pour la cyberrésilience dans un environnement multicloud hybride

Griff ShelleyResponsable marketing produit III | F5

Colin ClausetResponsable senior du marketing produit | F5

Mark MengerArchitecte de solutions | F5

En 2025, plusieurs incidents majeurs touchant les infrastructures cloud et Internet ont rappelé aux équipes du monde entier que les interruptions sont inévitables et qu’elles trouvent souvent leur origine au-delà du périmètre d’un fournisseur ou d’une structure organisationnelle en particulier. Lorsqu’une grande région cloud tombe en panne ou qu’une plateforme mondiale de gestion du trafic connaît un dysfonctionnement, les applications qui en dépendent cessent de fonctionner simultanément et à grande échelle, quel que soit le nombre de 9 figurant dans le SLA.

Ces événements mettent en évidence une inadéquation structurelle : de nombreuses entreprises continuent de se préparer aux défaillances en misant sur une reprise réactive, alors que les systèmes distribués modernes tombent rapidement en panne, à l’échelle mondiale et au-delà des périmètres de responsabilité d’une seule équipe. La question n’est plus de savoir que faire en cas de perturbation ; mais plutôt comment l’architecture réagit, s’adapte et s’améliore pendant et après une panne ?

Ce que signifie la résilience dans un environnement multicloud hybride

Traditionnellement, les stratégies de résilience visaient avant tout un retour à la normale : plans de reprise après sinistre, sites secondaires et objectifs de temps de reprise et de point de reprise (RTO/RPO). Cette approche partait du principe que les défaillances étaient locales, que les dépendances étaient connues et que les périmètres de contrôle étaient clairement définis. Les environnements multicloud hybrides remettent en cause ces hypothèses : l’identité, le routage, le stockage et la distribution des données sont souvent gérés par des tiers et, en cas de défaillance, les répercussions sont immédiates et mondiales.

Une approche « antifragile » de la cyberrésilience redéfinit la résilience comme une capacité qui s’améliore sous l’effet du stress. Elle consiste à anticiper les perturbations, à en limiter le rayon d’impact, à s’adapter en temps réel et à exploiter les données télémétriques issues de conditions anormales afin d’affiner l’architecture, de sorte que des événements similaires ultérieurs aient moins de conséquences, voire aucune. La réussite se mesure à la faible incidence d’une perturbation sur le système, à la rapidité avec laquelle celui-ci s’adapte pendant qu’elle se produit et à la manière dont les architectures évoluent en conséquence.

Cette approche produit des résultats très concrets : des périmètres d’impact plus restreints et maîtrisés ; une disponibilité accrue lorsque les dépendances se dégradent ; un rétablissement plus rapide grâce à des systèmes préparés en amont pour s’adapter ; des réponses automatisées aux situations anormales ; et une confiance renforcée dans les services externes, car la résilience est intégrée dès la conception plutôt que déléguée. En définitive, une approche antifragile de la cyberrésilience élargit le champ du rétablissement : il ne s’agit plus seulement de « rebondir », mais de « rebondir, apprendre vite et devenir plus robuste », faisant ainsi des perturbations un moteur de progrès architectural plutôt qu’une charge opérationnelle.

Pourquoi les stratégies réactives et cloisonnées échouent

Quatre tendances fragilisent les stratégies traditionnelles dans les environnements multicloud hybrides. Tout d’abord, il faut comprendre que les défaillances des dépendances externes ont une portée globale. Les pannes des services d’identité ou de routage perturbent tous les services qui en dépendent simultanément. En outre, dans de nombreuses architectures, l’isolation des défaillances n’a pas évolué au même rythme : les connexions intercloud ne disposent donc pas de mécanismes de cloisonnement permettant de circonscrire les défaillances et d’éviter qu’elles ne perturbent les services parallèles.

En outre, dans de nombreux environnements, les pratiques de résilience sont fragmentées. La reprise après sinistre, la gestion du trafic, la gestion des identités et la gouvernance des données fonctionnent en silos, alors que les pannes ne respectent pas ces cloisonnements.

Enfin, n’oubliez pas que la reprise est réactive. Les équipes rétablissent le service, mais ne préviennent pas toujours (ou ne peuvent pas toujours prévenir) la récurrence des incidents sur le plan structurel.

Les environnements multicloud hybrides actuels exigent une résilience qui ne soit ni réactive ni cloisonnée, et qui ne dépende pas du bon fonctionnement continu de fournisseurs tiers.

Cinq pratiques pour rendre les stratégies de cyberrésilience antifragiles

Une approche antifragile de la cyberrésilience repose sur un ensemble de pratiques d’ingénierie pouvant être intégrées à tous les niveaux d’une pile technologique, afin que les systèmes se comportent de manière prévisible sous contrainte :

• Maîtrise du rayon d’impact. Définissez clairement les périmètres de confiance et de défaillance afin qu’une panne touchant une région, un cloud ou une dépendance ne puisse pas se propager sans contrôle.
• Diversification des dépendances. Créez des solutions de remplacement viables pour les services critiques. La redondance va au-delà de la simple duplication pour devenir une flexibilité maîtrisée qui empêche un fournisseur unique de dicter le comportement du système.
• Adaptation pilotée par des politiques. Remplacez les configurations statiques par des politiques qui s’adaptent à l’état actuel, en particulier pour le routage, l’authentification et la confiance.
• Adaptation progressive. Mettez en œuvre de petites évolutions architecturales observables qui renforcent la résilience sans déstabiliser le système.
• Gouvernance éclairée par l’observation et automatisation à l’exécution. Utilisez la télémétrie pour orienter les décisions et automatiser les réponses, afin que l’adaptation commence avant que les incidents ne s’aggravent.

À qui incombe la cyberrésilience ? (Indice : à tout le monde)

Dans le cadre de la fourniture d’applications dans des environnements hybrides et multicloud, aucune fonction — qu’il s’agisse de la sécurité, du réseau, des opérations cloud ou du fournisseur — ne peut garantir à elle seule la résilience. Une véritable résilience nécessite un modèle opérationnel coordonné qui harmonise les responsabilités internes avec les dépendances externes et réduit les ambiguïtés lors des incidents.

Cela contribue également au respect de cadres réglementaires tels que le règlement de l’UE sur la résilience opérationnelle numérique (DORA), qui impose aux établissements financiers d’assurer leur résilience opérationnelle numérique, ainsi qu’à l’alignement sur la norme ISO/IEC 27001), norme mondialement reconnue pour les systèmes de management de la sécurité de l’information. Tous deux mettent l’accent sur l’apprentissage, l’évolution et la démonstration de la bonne santé opérationnelle. DORA incite explicitement les établissements à aller au-delà de la disponibilité pour viser une amélioration continue (« apprendre et évoluer ») après les interruptions de service, en associant la résilience à la gouvernance et à l’automatisation plutôt qu’à la seule reprise.

Cinq niveaux d’une architecture d’entreprise antifragile

Pour déployer ces pratiques à grande échelle, nous recommandons d’adopter un cadre conceptuel commun : l’architecture à cinq niveaux. Chaque niveau constitue à la fois une couche technologique et un domaine de responsabilité au sein duquel la résilience peut émerger ou, au contraire, faire défaut.

Le premier niveau est global et régit le contrôle externe ainsi que les périmètres de confiance, grâce à la maîtrise du rayon d’impact et à un routage piloté par des politiques. Ensuite, le niveau site de l’architecture définit les zones régionales d’exécution et d’isolation au moyen de la diversification des dépendances et de domaines de basculement. Le niveau plateforme assure l’exécution des traitements et des données, tout en permettant l’automatisation à l’exécution et la mobilité des charges de travail, tandis que le niveau application fournit la logique métier et l’expérience utilisateur afin de permettre une adaptation progressive et une dégradation maîtrisée.

Enfin, la couche de gestion centralise l’observabilité, la gouvernance et l’orchestration afin de permettre l’évolution des politiques en fonction des données de télémétrie.

Mettre en pratique les différents niveaux

Chaque niveau et chaque pratique semblent excellents en théorie, mais pour tirer le meilleur parti d’une stratégie de résilience antifragile, vous devez comprendre précisément comment ils fonctionnent ensemble pour créer une architecture antifragile.

À l’échelle globale, le contrôle du rayon d’impact et le routage basé sur des politiques permettent de circonscrire les défaillances à l’échelle du système avant qu’elles ne se propagent, réduisant ainsi leur impact sur l’ensemble de vos systèmes connectés.

Au niveau du site, la diversification des dépendances et la mise en place de domaines de basculement vous permettent d’isoler les perturbations et d’assurer la continuité grâce à des zones d’exécution alternatives.

L’automatisation de l’exécution et la mobilité des charges de travail permettent de s’adapter rapidement à toute perturbation au niveau de la plateforme. Grâce aux réponses automatisées, votre système peut réagir immédiatement aux pannes, tandis que la mobilité des charges de travail permet de déployer vos applications dans plusieurs environnements afin d’assurer la continuité.

Au niveau de la couche applicative, l’adaptation progressive et la dégradation contrôlée permettent d’absorber les perturbations afin d’éviter une dégradation totale de l’expérience utilisateur. Vous pouvez ainsi résister à une défaillance partielle tout en limitant au minimum son impact sur vos utilisateurs finaux.

Les impératifs de la couche de gestion comprennent des politiques fondées sur la télémétrie, qui résultent de la conversion des événements opérationnels en améliorations de la gouvernance et des politiques. Tirer les enseignements des perturbations crée une boucle de rétroaction qui vous permet d’affiner les politiques à partir des données historiques, afin de renforcer continuellement votre posture antifragile.

Ensemble, les niveaux et les pratiques font des perturbations un moteur de progrès architectural plutôt qu’un éternel bouton de réinitialisation.

Vers quoi cette idée évolue

Cet article de blog n’est qu’un élément d’un ensemble d’articles, d’architectures et de démonstrations qui présenteront les modèles, les modes de défaillance, les indicateurs et les notes de mise en œuvre couvrant les cinq niveaux d’une stratégie de cyberrésilience antifragile.

Nous vous recommandons de choisir une pratique dans la liste ci-dessus et de l’explorer comme objectif de sprint ou objectif trimestriel. Gardez à l’esprit qu’une stratégie de cyberrésilience antifragile ne se met pas en place d’un seul coup : elle se construit progressivement, grâce à de petits changements mesurables. Commencez dès maintenant, apprenez vite et faites de la prochaine panne l’occasion pour votre architecture de prouver qu’elle gagne en robustesse.

N’hésitez pas à consulter notre présentation de la solution pour en savoir plus sur la cyberrésilience sous l’angle de l’antifragilité.

Si vous souhaitez approfondir la manière dont vous pouvez commencer à adopter une approche antifragile dans votre stratégie de cyberrésilience, consultez ce livre blanc sur l’architecture.

À propos des auteurs

Griff ShelleyResponsable marketing produit III | F5

Griff Shelley est responsable marketing produit chez F5, spécialisé dans les solutions matérielles, logicielles et SaaS de mise à disposition d’applications. Passionné par les technologies innovantes et leur contribution à la réussite des clients, Griff pilote des projets de mise sur le marché dans les domaines de la mise à disposition d’applications à l’échelle mondiale et locale, des services cloud et des infrastructures de trafic de données pour l’IA.

Autres articles de Griff Shelley

Colin ClausetResponsable senior du marketing produit | F5

Colin Clauset est Senior Product Marketing Manager chez F5, où il est spécialisé dans les solutions SaaS de mise à disposition d’applications. Il pilote la stratégie de mise sur le marché de projets et de services de mise à disposition d’applications distribuées, avec un intérêt particulier pour la manière dont la technologie peut simplifier les processus complexes afin de mieux répondre aux besoins des professionnels de l’informatique. Fort de son expérience dans le conseil avant de rejoindre F5, Colin aborde les problématiques des clients en privilégiant des solutions globales qui vont au-delà des produits pris individuellement.

Autres articles de Colin Clauset

Mark MengerArchitecte de solutions | F5

Mark Menger est architecte de solutions chez F5, où il est spécialisé dans les partenariats technologiques liés à l’IA et à la sécurité. Il dirige le développement de l’architecture de référence de F5 pour l’IA, contribuant ainsi à faire progresser des solutions d’IA sécurisées et évolutives. Fort de son expérience en tant qu’architecte de solutions globales et ingénieur solutions, Mark a participé à l’élaboration de l’architecture cloud sécurisée de F5 et au codéveloppement de son architecture distribuée à quatre niveaux. Coauteur de Solving IT Complexity, il met son expertise au service de la résolution des défis informatiques. Auparavant, il a occupé des postes de développeur d’applications et d’architecte d’entreprise, en se concentrant sur les applications modernes, l’automatisation et l’accélération de la création de valeur issue des investissements dans l’IA.

Autres articles de Mark Menger