Externalisation des sauvegardes : cloud, infrastructure dédiée ou souveraine ?

Dernière mise à jour : Juin 2026
Temps de lecture : 8 minutes
Sources : textes NIS2 et DORA, guides ANSSI

Externaliser ses sauvegardes ne se résume ni à un prix au téraoctet ni à un lieu de stockage. Le bon modèle dépend de ce qu'il faut restaurer et en combien de temps, de qui peut modifier ou supprimer les copies, de la manière dont le service est exploité, de la possibilité d'en sortir et des contrôles réellement mis en œuvre.

Cette page compare trois modèles de fourniture : le cloud mutualisé, l'infrastructure dédiée ou privée, et l'offre localisée avec des critères vérifiables. Pour les fondamentaux (périmètre, rétention, restauration, choix du prestataire), reportez-vous à notre guide de la sauvegarde externalisée.

Aucune de ces architectures ne suffit, à elle seule, à démontrer une conformité NIS2, DORA, RGPD ou HDS. Ce qui compte est la cohérence entre l'analyse de risque, les objectifs de reprise et les mesures appliquées puis testées.

Points clés :

  • Cloud mutualisé, infrastructure dédiée et offre localisée peuvent chacun faire partie d'une stratégie de sauvegarde résiliente, selon le périmètre et les risques.
  • Les critères décisifs sont les accès aux copies, la séparation des environnements, la protection contre l'altération, la restauration testée, la localisation réelle et la réversibilité.
  • Les objectifs RPO et RTO doivent être définis service par service, contractualisés puis validés par des tests représentatifs.
  • La localisation du stockage ne renseigne pas, à elle seule, sur les lieux de traitement, les accès d'administration ou les sous-traitants.

Comparatif rapide selon six critères

Ce tableau ne classe aucun modèle comme conforme ou non conforme. Il indique, pour chaque critère, ce qu'il faut vérifier auprès du prestataire ou dans votre propre architecture.

Critère
Cloud mutualisé
Infrastructure dédiée ou privée
Offre localisée avec critères vérifiables
Accès et séparation des environnements
Séparation logique entre clients ; comptes d'administration et accès privés à vérifier
Séparation physique ou logique selon la conception ; administrateurs et accès distants à vérifier
Selon l'architecture réelle ; mêmes vérifications que pour les autres modèles
Localisation, traitement et sous-traitance
Régions choisies au contrat ; support et sous-traitants à vérifier
Site connu ; accès des mainteneurs et prestataires à vérifier
Localisation annoncée ; traitement, administration, sous-traitants et droit applicable à vérifier
Protection contre l'altération et immuabilité
Immuabilité ou verrouillage selon le service ; paramétrage effectif à vérifier
Immuabilité, déconnexion ou air-gap possibles selon la conception
Mécanismes et périmètre à documenter selon l'offre
Restauration et tests
Dépend du volume, de la bande passante et des options de restauration
Restauration locale possible ; capacité à dimensionner et à tester
Dépend du lien réseau et des moyens de restauration prévus
Exploitation et dépendances
Service opéré ; dépendance au fournisseur et à la connectivité
Matériel et exploitation à assurer, en interne ou par un prestataire
Exploitation par le prestataire ; dépendances à identifier
Réversibilité et clauses contractuelles
Conditions de sortie, formats et frais de récupération à vérifier
Propriété du matériel et des données ; sortie à prévoir au contrat
Engagements de réversibilité et d'audit à vérifier

Quand un cloud mutualisé peut convenir

Un service de sauvegarde en cloud mutualisé, opéré par un grand fournisseur ou par un acteur européen, peut convenir lorsque les besoins sont standardisés, que les volumes évoluent, qu'une réplication distante est recherchée ou que l'organisation préfère un service opéré à une infrastructure à maintenir.

Points à contrôler :

  • l'accès au service par des chemins privés ou restreints, et pas uniquement par internet public ;
  • les identités capables de modifier ou de supprimer les copies, l'authentification forte et la séparation des comptes d'administration ;
  • la journalisation des opérations sensibles et sa conservation ;
  • le chiffrement et la gestion des clés ;
  • les politiques d'immuabilité ou de verrouillage de la rétention, et leur paramétrage effectif ;
  • une restauration testée sur un périmètre représentatif, avec la bande passante réellement disponible ;
  • les conditions de sortie et les dépendances vis-à-vis du fournisseur.

Un cloud mutualisé peut porter une copie externalisée parmi d'autres ou constituer le cœur de la stratégie. Dans les deux cas, c'est l'analyse de risque et les résultats des tests qui justifient le choix, pas le modèle lui-même.

Quand une infrastructure dédiée ou privée peut se justifier

Une infrastructure dédiée, installée chez le client ou hébergée chez un tiers, peut se justifier lorsque des contraintes particulières pèsent sur la reprise :

  • des exigences de performance ou des volumes qui rendent une restauration à distance trop longue ;
  • un besoin de restauration locale, indépendante de la connectivité externe ;
  • une politique de sauvegarde ou une architecture qui doit être personnalisée ;
  • une segmentation de l'exploitation, avec des comptes et des réseaux séparés de la production ;
  • des charges critiques pour lesquelles l'organisation veut maîtriser le matériel et ses conditions d'accès.

Ce modèle n'est ni la seule option acceptable ni systématiquement préférable. Il suppose de dimensionner le matériel, d'en assurer l'exploitation, en interne ou par un prestataire, et de tester régulièrement la restauration.

La protection des copies repose sur les mêmes questions que pour le cloud : qui peut les modifier, comment elles sont isolées et comment elles sont restaurées. Pour distinguer les mécanismes d'isolation, voir notre article sur l'air-gap et l'isolation réseau, et pour la protection contre l'effacement, celui sur la sauvegarde immuable et le WORM.

Évaluer une exigence de localisation ou de souveraineté

Une offre présentée comme « localisée en France » ou « souveraine » peut répondre à un besoin réel, à condition de préciser ce que recouvre le terme. Cinq points sont à distinguer :

  • Localisation en France ou dans l'Union européenne : où se trouvent les centres de données retenus, y compris pour les copies secondaires.
  • Lieux de stockage et de traitement : où les données sont stockées, mais aussi où elles sont traitées lors de la sauvegarde, de la restauration ou de l'indexation.
  • Accès d'administration et sous-traitants : qui peut accéder aux systèmes et aux données, depuis quels pays, et quels sous-traitants interviennent.
  • Droit applicable : le droit du contrat et les législations auxquelles le fournisseur et ses sous-traitants peuvent être soumis.
  • Gouvernance et réversibilité : qui décide des évolutions du service, et comment récupérer les données pour quitter le service.

Ces éléments se vérifient dans le contrat, les annexes de sécurité et la liste des sous-traitants. Une localisation du stockage en France ne dit rien, à elle seule, des accès distants ni du droit applicable aux intervenants.

Pour des données de santé, l'article L.1111-8 du Code de la santé publique encadre leur hébergement pour le compte de tiers. La vérification porte alors à la fois sur l'hébergeur et sur le périmètre des prestations couvertes par un certificat HDS valide.

Vérifier la capacité de restauration avant de choisir

Le modèle d'hébergement compte moins que la capacité à restaurer ce qui est critique dans un délai acceptable. Avant de choisir, il faut pouvoir répondre aux questions suivantes :

  • Périmètre : quels systèmes, applications, données et dépendances (annuaire, réseau, configurations) sont couverts.
  • Objectifs RPO et RTO : quelle perte de données et quelle durée d'interruption sont acceptables pour chaque service.
  • Volume et bande passante : quelle quantité de données rapatrier, par quel lien, avec quel débit réellement disponible en situation de crise.
  • Procédures : qui déclenche la restauration, dans quel ordre, et avec quels accès si l'environnement principal est compromis.
  • Dépendances : ce qui doit fonctionner avant que les sauvegardes soient utilisables (identités, réseau, consoles, licences).
  • Tests et preuves : des tests représentatifs, datés, avec les durées mesurées et les écarts constatés.

Les objectifs et le périmètre de restauration doivent être contractualisés, puis validés par des tests représentatifs. Un délai annoncé sans rapport de test récent reste une hypothèse. Dans un scénario de rançongiciel, les sauvegardes elles-mêmes peuvent être visées : notre guide sur la protection des sauvegardes face aux ransomwares détaille les points d'attention.

Pour relier ces objectifs à l'architecture de reprise, voir comment choisir une architecture de backup pour votre PRA.

Ce que le contrat doit permettre de vérifier

Le contrat et ses annexes doivent permettre de vérifier, selon le cas :

  • les services couverts, les périmètres sauvegardés et les exclusions ;
  • la répartition des responsabilités entre le client et le prestataire ;
  • les lieux de fourniture du service et de traitement des données ;
  • la liste des sous-traitants et les conditions de leur remplacement ;
  • les mesures de sécurité, dont la gestion des accès et la protection des copies ;
  • les engagements de continuité et les objectifs de restauration ;
  • la notification et la gestion des incidents ;
  • la fréquence, le périmètre et les comptes rendus des tests ;
  • les modalités d'accès aux données et aux sauvegardes, y compris en situation de crise ;
  • la réversibilité : formats, délais, assistance et coûts de sortie ;
  • les droits d'audit et de contrôle, lorsqu'ils sont requis.

Pour les entités financières soumises à DORA, l'article 30 du règlement (UE) 2022/2554 précise les clauses attendues dans les contrats de services TIC, notamment sur les lieux de fourniture et de traitement, l'accès aux données et les stratégies de sortie. Pour les autres organisations, ces mêmes points constituent une base de négociation utile.

Le lien avec votre PRA

Cette page aide à comparer les modèles de fourniture et d'hébergement d'une sauvegarde externalisée. Le comparatif PRA cité plus haut traite l'autre volet : identifier les applications critiques, fixer leurs objectifs RPO et RTO et organiser la reprise dans le bon ordre.

Les deux décisions se nourrissent. Un objectif de reprise court sur une application volumineuse peut orienter vers une capacité de restauration locale ; un besoin de copie distante peut orienter vers un service externalisé. L'une ne se décide pas sans l'autre.

Ressources pour aller plus loin
sur le Backup VYTALX

Fiche technique Backup managé

Description détaillée des fonctionnalités, des modes de sauvegarde,
des options de restauration, de la sécurité et des scénarios d’usage.
Télécharger la fiche technique

Checklist de revue
de votre dispositif de sauvegarde

Une liste structurée de points à vérifier sur votre environnement actuel :
périmètre couvert, fréquences, rétention, tests de restauration.
Télécharger la check-list backup

Questions fréquentes

Conclusion

Cloud mutualisé, infrastructure dédiée ou offre localisée : chaque modèle peut se justifier, et aucun ne garantit à lui seul la conformité ni la reprise. Le choix se fonde sur l'analyse de risque, le périmètre à protéger, les accès aux copies, la restauration testée, la localisation réelle et la réversibilité.

Ces critères se vérifient dans l'architecture, le contrat et les rapports de test. C'est sur eux qu'il faut comparer les offres.

Pour passer en revue vos contraintes de restauration, de localisation et de contrat, planifiez un échange de 30 minutes avec un expert VYTALX.
Revoir votre architecture
de sauvegarde avec VYTALX
Un entretien dédié pour passer en revue vos workloads, vos contraintes 

(sites, bande passante, RPO/RTO) et confronter votre dispositif actuel 

aux capacités de notre plateforme de Backup managé.
Planifier une revue technique Backup