Sauvegarde multi-cloud : que signifie réellement « cloud-native » ?

Le problème du « cloud-washing »

Tous les fournisseurs de solutions de sauvegarde de notre marché proposent désormais des solutions de sauvegarde multicloud. Les pages marketing se ressemblent toutes. Les architectures sous-jacentes sont pourtant radicalement différentes, et ces différences finissent par coûter cher au pire moment.

J’ai passé ces dernières années à voir des clients en faire l’amère expérience. Un fournisseur leur vend une « solution de sauvegarde multicloud native du cloud ». Le produit est une appliance virtuelle de taille fixe que le client déploie sur AWS ou Azure, configure en estimant à l’avance la capacité maximale, et pour laquelle il paie, qu’il l’utilise ou non. Ce n’est pas « cloud-native ». Il s’agit de l’ancien modèle de centre de données fonctionnant dans une machine virtuelle hébergée dans le cloud. 

Le terme que j’utilise pour désigner ce phénomène est le « cloud-washing ». Le produit du fournisseur n’a pas vraiment changé. Ce sont ses diapositives qui ont évolué.

Cinq éléments qui font qu’une sauvegarde est réellement native du cloud

Une véritable sauvegarde native du cloud n’est pas un argument marketing. C’est une architecture, et cette architecture a des implications en termes de coût, d’évolutivité et de restauration. Cinq caractéristiques sont essentielles.

Elle s’adapte de manière élastique au cloud. Les nouvelles machines virtuelles sont protégées automatiquement grâce à la découverte via API. Les anciennes machines virtuelles cessent de générer de la charge de sauvegarde lorsqu’elles sont mises hors service. Pas de capacité fixe à estimer. Pas de cycle d’approvisionnement lorsque l’environnement s’agrandit.

Elle utilise les services cloud natifs comme éléments de base. Des instantanés natifs pour les machines virtuelles, l’IAM natif pour l’authentification, le stockage objet natif pour la conservation, les places de marché natives pour la facturation. Il ne s’agit pas d’une couche d’abstraction créée par un fournisseur qui reproduit ce que le cloud fait déjà.

La facturation porte sur ce que vous avez réellement sauvegardé. Un modèle économique de paiement à l’utilisation, facturé en fonction de la capacité source réellement protégée et de la fréquence de sauvegarde. Et non sur la capacité que vous pourriez utiliser un jour.

Elle ne nécessite aucun déploiement d’infrastructure. Pas d’appareils de sauvegarde à provisionner, pas d’agents à installer sur les charges de travail protégées, pas de stockage propriétaire à dimensionner. Le client s’abonne ; le service fonctionne.

Elle transfère les données d’un cloud à l’autre de manière native. Une sauvegarde effectuée sur AWS peut être restaurée sur GCP. La migration des charges de travail s’effectue via le même mécanisme. Les clouds que vous choisissez aujourd’hui et ceux que vous choisirez dans trois ans fonctionnent tous via la même interface de gestion.

Ce que vous coûte réellement une sauvegarde « cloud-washed »

Trois schémas de coût total de possession (TCO) reviennent systématiquement dans les déploiements de type « cloud-washed ». Ils sont suffisamment prévisibles pour que je puisse généralement les identifier en 15 minutes lors de l’examen de la facture d’un client.

Le surprovisionnement est le premier. Le client dimensionne l’appareil de sauvegarde en fonction d’une charge future maximale, fonctionne à 30 % de son utilisation pendant les deux premières années et paie pour les 70 % inutilisés. Avec une solution véritablement native du cloud, vous ne provisionnez pas de capacité. Vous la consommez.

Les coûts cachés du cloud constituent le deuxième. L’appareil de sauvegarde du fournisseur génère un trafic sortant important, un trafic de réplication interrégional ou des appels d’API de niveau de stockage qui apparaissent sur la facture cloud du client, et non sur celle du fournisseur. Le client paie au fournisseur un prix fixe pour le logiciel et verse au fournisseur de cloud un montant imprévisible pour le travail généré par ce logiciel. 

La « taxe de migration » constitue le troisième facteur. Le client souhaite déplacer des charges de travail d’un cloud à un autre. L’outil du fournisseur de sauvegarde ne fonctionne qu’au sein d’un seul cloud. La migration devient alors un projet distinct, avec un outil, un budget et un calendrier spécifiques.

La réalité du multicloud dans les entreprises

L’étude « State of the Cloud » de Flexera suit l’adoption du multicloud depuis des années. Alors que les rapports précédents révélaient que près de neuf organisations sur dix (89 %) utilisaient déjà plusieurs clouds, l’étude de 2025 montre que le marché a évolué vers une norme hybride et multicloud. Les entreprises ont désormais recours en moyenne à 2,4 fournisseurs de cloud public, et 70 % d’entre elles exploitent des environnements hybrides qui s’étendent à la fois au cloud public et au cloud privé, ce qui confirme que le multicloud n’est plus une architecture d’avenir, mais bien le mode de fonctionnement actuel des entreprises.

La plupart des environnements informatiques d’entreprise s’étendent désormais sur au moins deux clouds publics, auxquels s’ajoutent une infrastructure sur site et un portefeuille d’applications SaaS. Une stratégie de sauvegarde qui fonctionne sur AWS mais échoue sur Azure ne correspond pas à la réalité dans laquelle évoluent les clients. Il en va de même pour une stratégie qui couvre l’IaaS mais ignore le SaaS.

Le coût d’une telle erreur est bien réel. Le rapport 2024 d’IBM « Coût d’une violation de données » a révélé que le coût moyen mondial d’une violation de données s’élevait à 4,88 millions de dollars, soit une hausse de 10 % par rapport à l’année précédente et la plus forte augmentation depuis le début de la pandémie. Cette hausse s’explique en grande partie par les perturbations opérationnelles, la perte d’activité, les coûts liés à la gestion des incidents et la durée prolongée des efforts de rétablissement. L’étude d’IBM a également révélé que les environnements hybrides complexes, combinant cloud, infrastructures sur site et conteneurisées, peuvent rendre la maîtrise des violations plus difficile et plus coûteuse. Les erreurs de configuration du cloud, les identifiants compromis et d’autres failles de sécurité figurent toujours parmi les principaux facteurs contribuant au risque de violation. Les lacunes dans la couverture des sauvegardes, qui laissent aux attaquants la possibilité de chiffrer, détruire ou exfiltrer des données, peuvent considérablement aggraver l’impact opérationnel et financier d’un incident.

Ce que doit inclure une véritable couverture multicloud

Les questions de diagnostic qui fonctionnent réellement

Trois questions, posées dans l’ordre ci-dessous, vous permettront de savoir en 10 minutes si les prétentions « multicloud » d’un fournisseur sont réelles ou purement marketing. 

Demandez tout d’abord ce que vous devez déployer. Si la réponse implique une appliance virtuelle par cloud, un dimensionnement de capacité fixe ou des engagements en téraoctets maximaux, l’architecture est hébergée dans le cloud, et non native du cloud. Une véritable architecture native du cloud signifie qu’aucune infrastructure n’est à déployer.

Demandez ensuite comment fonctionne la tarification. Si la réponse est liée à la capacité que vous réservez à l’avance, le fournisseur vous propose un modèle économique de type « appliance ». Le modèle « pay-as-you-protect » facture les données sources effectivement sauvegardées, et non une estimation du volume maximal futur.

Demandez ensuite comment s’effectue la migration inter-cloud. Demandez-leur de vous présenter un cas concret de sauvegarde d’une charge de travail depuis AWS et de restauration vers GCP. Si la réponse implique une exportation, une réimportation et le recours à des services, la promesse « multicloud » est de celles qui tombent à l’eau lorsque vous en avez réellement besoin.

Ce que signifie réellement « Vos données. Votre cloud. À vous de contrôler. »

Notre fondateur, Simon Taylor, le répète depuis des années, et j’en suis venu à y voir quelque chose de plus concret qu’un simple slogan.

C’est le client qui choisit les clouds. Pas le fournisseur de sauvegarde. Si le client souhaite utiliser AWS pour la production, Azure pour la reprise après sinistre et GCP pour l’analyse, la plateforme de sauvegarde protège ces trois environnements avec les mêmes politiques et le même modèle de restauration. La stratégie cloud du client n’est pas limitée par ce que prend en charge son fournisseur de sauvegarde.

Le contrôle signifie que les données restent dans l’infrastructure du client. Les sauvegardes sont stockées dans les comptes cloud du client. C’est le client qui détient les clés. Le fournisseur ne devient ni un point de défaillance unique, ni un levier de pression unique.

Questions fréquentes sur la sauvegarde multicloud

Pourquoi ne pas simplement utiliser le service de sauvegarde natif de chaque cloud ?

Les services natifs constituent des éléments de base utiles au sein de leur propre cloud. AWS Backup est efficace pour protéger les charges de travail AWS. Il n’est d’aucune utilité pour Azure, GCP, les environnements sur site ou le SaaS. La plupart des environnements d’entreprise couvrent ces quatre types d’infrastructures, et le coût opérationnel lié à la gestion de quatre outils de sauvegarde distincts, avec quatre politiques distinctes, quatre consoles distinctes et quatre modèles de conservation distincts, devient rapidement très élevé. 

Qu’en est-il du coût du trafic sortant lors d’une restauration entre clouds ?

Le trafic sortant est bien réel, et il a son importance. La solution architecturale consiste à conserver les copies de sauvegarde dans le cloud d’origine de la charge de travail et à ne générer de trafic sortant que lors d’une restauration effective vers un autre cloud. La plupart du temps, ce trafic est nul. Le jour où vous avez besoin d’une restauration inter-cloud, le trafic sortant ne représente qu’une infime partie du coût de l’incident.

Comment la sauvegarde multicloud gère-t-elle la conformité et la souveraineté des données ?

Région par région. Les données sauvegardées restent dans la région spécifiée par le client. Si le RGPD exige que les données de l’UE restent dans l’UE, la configuration de la sauvegarde garantit le respect de cette exigence. La conformité est un choix de configuration, et non un engagement du fournisseur qui peut être tenu ou non.

Est-ce réaliste pour les organisations qui ne sont pas encore multi-cloud ?

La plupart des organisations finissent par adopter une architecture multi-cloud, qu’elles l’aient prévu ou non. Les acquisitions s’accompagnent de différents clouds. Les différentes divisions choisissent des fournisseurs différents. La prolifération des solutions SaaS ajoute des charges de travail en dehors de tout cloud choisi. Choisir une plateforme de sauvegarde compatible avec le multi-cloud avant d’en avoir besoin revient moins cher que de remplacer votre fournisseur de sauvegarde lorsque ce besoin se fait sentir.

Ce que je ferais ensuite

Réalisez un audit de votre sauvegarde actuelle. Répertoriez chaque charge de travail, son emplacement d’exécution, ce qui la protège et ce qui se passerait en cas de restauration. Cet exercice révèle généralement deux ou trois charges de travail qui ne sont pas protégées sur le plan fonctionnel. Ce sont ces lacunes que la sauvegarde multicloud est censée combler. Si votre situation correspond à l’une d’entre elles, commencez par là.