La continuité des activités passe d'abord par la portabilité

La planification de la continuité des activités repose en grande partie sur une hypothèse tacite : celle que l’infrastructure sur laquelle le plan s’appuie fonctionnera correctement. Les systèmes de sauvegarde seront accessibles. Les procédures de reprise fonctionneront comme prévu. Le fournisseur dont les services constituent le chemin critique sera disponible, ou au moins capable de se rétablir dans le délai spécifié par le plan.

Cette hypothèse est mise à l’épreuve chaque fois qu’un fournisseur majeur subit une panne, une défaillance régionale ou une interruption de service qui se répercute en cascade sur les charges de travail qui en dépendent. Et quand ça ne marche pas, ça a tendance à échouer d’une manière bien précise. Pas parce que le plan était mauvais, mais parce que l’architecture n’a pas pu l’exécuter.

La différence entre avoir un plan et en avoir un qui marche

Point clé : la plupart des entreprises ont des stratégies de continuité documentées et ont confiance en elles. Mais les données sur les résultats réels de la reprise racontent une autre histoire.

D’après le rapport Veeam Data Trust and Resilience Report 2026, qui s’appuie sur les témoignages de plus de 900 responsables informatiques, de sécurité et de gestion des risques à travers le monde, 90 % des entreprises se disent confiantes dans leur capacité à se remettre d’un cyberincident dans les délais fixés par leurs objectifs de temps de reprise (RTO). Seuls 69 % affirment que ces RTO sont parfaitement alignés sur les objectifs de continuité d’activité. 

C’est dans cet écart, entre la confiance dans le plan et l’adéquation entre ce plan et les besoins réels de l’entreprise, que se situent la plupart des échecs en matière de continuité.

Les enjeux financiers de cet écart ne sont pas abstraits. Une étude de Cisco estime le coût moyen d’une panne informatique à 15 000 dollars par minute pour les grandes entreprises. Une panne d’une heure coûte plus d’un demi-million de dollars, sans compter l’impact sur la réputation, les pénalités liées aux SLA avec les clients ou les conséquences réglementaires. 

D’après l’analyse annuelle des pannes 2026 de l’Uptime Institute, 57 % des personnes interrogées indiquent que leur dernière panne majeure a coûté plus de 100 000 dollars, et une sur cinq a dépassé le million de dollars. Pour la plupart des entreprises, le coût d’une panne n’est pas un risque théorique. C’est une dépense récurrente.

Pourquoi l’architecture est la variable de continuité que la plupart des plans sous-estiment

Point clé : les objectifs de temps de reprise échouent non pas à cause d’une mauvaise planification, mais parce que l’architecture sous-jacente ne permet pas d’exécuter le plan. La portabilité est la propriété architecturale qui rend crédibles les engagements en matière de continuité.

Lorsqu’une panne touche un seul fournisseur de cloud, les entreprises qui se remettent le plus vite ont toutes un point commun : leurs charges de travail ne dépendaient pas entièrement de ce fournisseur pour fonctionner. Elles disposaient de la flexibilité architecturale nécessaire pour contourner la panne, se redémarrer dans un autre environnement ou effectuer un basculement qui ne dépendait pas de la remise en ligne du système défaillant.

Les entreprises qui peinent à s’en sortir partagent une autre caractéristique : leur plan de reprise exigeait que le fournisseur participe à sa propre reprise. Restaurer à partir de sauvegardes stockées dans l’infrastructure du même fournisseur. Reconstruire des environnements à l’aide des outils de provisionnement de ce fournisseur. Attendre que l’incident du fournisseur soit résolu avant même que le processus de reprise puisse commencer.

C’est ça, le fossé de la portabilité dans la pratique, et c’est très répandu. D’après le rapport Flexera 2026 sur l’état du cloud, 78 % des entreprises citent la portabilité des charges de travail comme l’une de leurs trois principales priorités en matière de cloud. Seules 22 % ont mis en place une architecture véritablement indépendante du fournisseur. C’est dans cet écart entre l’aspiration et la réalité que se situent la plupart des échecs en matière de RTO. Les entreprises savent que la portabilité est importante. Mais la plupart ne l’ont pas mise en place.

Lis le guide pour standardiser la mise à disposition des applications sur AWS, Azure et GCP.

Quand la continuité devient une obligation de conformité

Point clé : pour les entités financières et les opérateurs d’infrastructures critiques dans l’UE, la portabilité vis-à-vis des fournisseurs n’est plus seulement une bonne pratique. La loi sur la résilience opérationnelle numérique (Digital Operational Resilience Act) fait de la gestion et de la démonstration du risque de concentration une obligation légale.

Les arguments commerciaux en faveur de la portabilité ont toujours été clairs. Les arguments réglementaires deviennent désormais explicites.

La loi européenne sur la résilience opérationnelle numérique (DORA) impose aux entités financières de gérer activement le risque de concentration lié aux fournisseurs tiers critiques, y compris les hyperscalers du cloud. Les organisations soumises à la DORA ne peuvent pas se contenter de s’appuyer sur les SLA d’un seul fournisseur pour garantir leur continuité. Elles doivent démontrer qu’elles ont évalué le risque de concentration des fournisseurs, qu’elles comprennent les implications d’une défaillance d’un fournisseur sur leurs opérations, et qu’elles ont pris des mesures pour gérer cette dépendance.

La DORA s’applique actuellement aux entités financières opérant dans l’UE, mais elle représente une orientation réglementaire qui se généralise. L’Autorité de conduite financière (FCA) du Royaume-Uni a publié des exigences similaires en matière de résilience opérationnelle. La directive NIS2 étend les obligations de résilience à un ensemble plus large d’opérateurs d’infrastructures critiques à travers l’UE. La tendance est claire : les régulateurs considèrent la concentration des fournisseurs de cloud comme un risque systémique, et les organisations soumises à ces cadres réglementaires ne peuvent plus considérer la portabilité comme une simple préférence architecturale facultative.

Pour les responsables de la gestion des actifs informatiques (ITMM) dans les secteurs réglementés, ça change complètement la donne en matière de portabilité. La question n’est plus de savoir si une architecture plus portable serait bénéfique sur le plan opérationnel. Il s’agit plutôt de déterminer si l’architecture actuelle respecte les obligations de conformité, et quels sont les risques si ce n’est pas le cas.

À quoi ressemble réellement la portabilité dans la pratique ?

Point clé à retenir : la portabilité, ce n’est pas faire tourner des charges de travail identiques chez tous les fournisseurs en même temps. C’est s’assurer que la couche de livraison est découplée de l’infrastructure de n’importe quel fournisseur, pour que la continuité ne dépende pas de la disponibilité ou de la coopération d’un seul fournisseur.

On croit souvent à tort que la portabilité implique de tout faire tourner partout et tout le temps. C’est coûteux, complexe et inutile pour la plupart des charges de travail. Ce dont la continuité a réellement besoin est plus ciblé : la capacité de déplacer les charges de travail critiques quand la décision est prise, sans que la migration soit bloquée par des dépendances architecturales vis-à-vis des services propriétaires d’un seul fournisseur.

Cette distinction est importante, car elle détermine où va l’investissement. La portabilité au niveau de la couche de livraison (comment les environnements sont définis, comment les applications se connectent à leurs dépendances, comment les pipelines sont structurés) est réalisable sans réécrire les applications ni abandonner les services spécifiques à un fournisseur lorsqu’ils offrent un réel avantage. Ça implique de faire des choix réfléchis : déterminer quels services créent des dépendances récupérables et lesquels créent des sorties qui coûtent plus cher que ce que le service vaut.

En pratique, les organisations qui mettent en œuvre avec succès des plans de continuité ont généralement pris trois décisions dès le départ : une infrastructure définie par code plutôt qu’assemblée manuellement dans les consoles des fournisseurs ; un provisionnement des environnements découplé des outils spécifiques aux fournisseurs ; et des pipelines de déploiement basés sur des normes ouvertes plutôt que sur des abstractions propriétaires. Aucune de ces décisions n’empêche d’utiliser les services spécifiques aux fournisseurs lorsqu’ils apportent une valeur ajoutée. Toutes préservent la capacité de partir quand rester devient intenable.

Un plan de continuité d’activité efficace est celui qui ne repose pas sur la capacité du système défaillant à se rétablir tout seul. Mettre en place cette capacité, c’est un choix architectural, pris au niveau de la couche de déploiement, bien avant l’incident qui le mettra à l’épreuve.

Lis le guide de migration pour échapper à la dépendance sans perturbation.

Foire aux questions (FAQ)

En quoi la portabilité diffère-t-elle d’une stratégie multicloud ? 

Une stratégie multicloud, ça veut dire faire tourner des charges de travail chez plusieurs fournisseurs. La portabilité, ça veut dire que ces charges de travail peuvent réellement passer d’un fournisseur à l’autre quand c’est nécessaire. Beaucoup d’organisations ont des déploiements multicloud où certaines charges de travail restent profondément intégrées aux services propriétaires d’un seul fournisseur. C’est de la facturation multicloud sans la résilience multicloud. La portabilité nécessite des choix architecturaux au niveau des charges de travail, pas seulement une diversification des fournisseurs au niveau du portefeuille.

La directive DORA s’applique-t-elle aux organisations hors du secteur financier de l’UE ? 

Pas directement, non. La DORA s’applique spécifiquement aux entités financières opérant dans l’UE, notamment les banques, les assureurs, les sociétés d’investissement et leurs prestataires de services tiers essentiels. Cependant, son cadre de réflexion sur le risque de concentration (identification des dépendances critiques, évaluation de l’impact d’une défaillance d’un fournisseur, démonstration d’une résilience maîtrisée) est de plus en plus adopté par les régulateurs d’autres secteurs et juridictions. Les responsables de la gestion des risques informatiques (ITMM) en dehors du secteur financier de l’UE devraient considérer la DORA comme un indicateur avancé de l’orientation des attentes réglementaires plutôt que comme une obligation immédiate.

Quelle est la différence entre le RTO et la capacité de reprise réelle ? 

L’objectif de temps de reprise (RTO) correspond au délai maximal acceptable pour rétablir un système après une panne, un objectif fixé lors de la planification de la continuité. La capacité de reprise réelle, c’est ce qui se passe lors d’un véritable incident, avec les contraintes architecturales réelles. L’écart entre confiance et alignement mis en évidence dans le rapport Veeam 2026 reflète exactement ça : les organisations pensent pouvoir se rétablir dans les délais de leur RTO, mais une proportion importante reconnaît que ces RTO ne reflètent pas pleinement les besoins réels de l’entreprise. Les causes les plus courantes sont la dépendance vis-à-vis de l’infrastructure du fournisseur défaillant pour la reprise, les modifications de configuration non documentées qui rendent les procédures de reprise documentées imprécises, et les étapes manuelles qui prennent plus de temps en situation d’incident qu’elles ne le faisaient lors des tests.

Comment tester la continuité sans perturber la production ? 

L’approche standard, ce sont les exercices sur table : des simulations structurées de scénarios d’incident qui permettent de vérifier si les hypothèses du plan tiennent la route sans avoir à exécuter la reprise elle-même. Au-delà de ces exercices sur table, le test le plus utile est un exercice de basculement contrôlé dans un environnement hors production qui reproduit suffisamment fidèlement l’architecture de production pour mettre en évidence les vraies contraintes. Les entreprises dont l’infrastructure est définie par du code et qui utilisent un provisionnement d’environnements éphémères peuvent réaliser ces exercices bien plus facilement que celles dont les environnements sont configurés manuellement, car l’environnement de test est reproductible par définition.

À quel moment la portabilité doit-elle devenir un sujet de discussion au niveau du conseil d’administration ? 

Quand la dépendance vis-à-vis de l’infrastructure crée un risque financier ou réglementaire important dont le conseil d’administration ne tient pas compte pour l’instant. Pour la plupart des entreprises, ça veut dire quantifier deux chiffres : le coût d’une panne durant le temps de reprise prévu par le fournisseur en cas d’incident majeur, et le coût estimé de la migration hors du fournisseur principal actuel si la relation devenait intenable. Si l’un ou l’autre de ces chiffres est significatif par rapport à la tolérance au risque de l’entreprise, cette discussion aurait déjà dû avoir lieu depuis longtemps.