Stratégies de sauvegarde entre On-Prem et Cloud : décision coût-bénéfice pour les DSI

La discussion sur les stratégies de sauvegarde entre On-Prem et Cloud ne devient concrète dans de nombreuses entreprises que lorsqu’il y a un incident : ransomware, panne de stockage, données supprimées par erreur ou un audit avec des questions gênantes. Pour les CIOs et les directions IT, la sauvegarde n’est pas une discipline purement technique, mais une décision coût‑bénéfice ayant un impact direct sur la capacité opérationnelle, les risques de responsabilité, la capacité de livraison et le pouvoir de négociation vis‑à‑vis des providers.

Quand on dit aujourd’hui « Cloud », on entend souvent automatiquement « moins d’effort ». Dans la pratique, l’effort se déplace : loin de l’achat de matériel et de la rotation des supports, vers la classification des données, les contrôles réseau et d’identité, le suivi des coûts récurrents, la planification d’un exit et — décisif — la capacité de RESTauration fiable. Cet article propose une logique décisionnelle structurée que vous pouvez traiter comme un sujet de management et de gouvernance : avec des options claires, des blocs de coûts, des risques, des responsabilités et des preuves auditables.

Stratégies de sauvegarde entre On-Prem et Cloud en pratique

Les sauvegardes sont bonnes lorsqu’elles permettent une RESTauration vérifiable. Tout le RESTe relève de l’archivage ou de la conservation des données — les deux importants, mais pas équivalents à la Business Continuity. La clé est de traduire les exigences en RTO et RPO :

• RTO (Recovery Time Objective) : À quelle vitesse un service doit‑il être opérationnel pour que l’activité ne souffre pas de manière inacceptable ?
• RPO (Recovery Point Objective) : Quelle quantité de perte de données (fenêtre temporelle) est acceptable au maximum, mesurée depuis la dernière sauvegarde cohérente ?

Ces deux indicateurs déterminent l’architecture plus fortement que le choix d’un produit. Un RTO de 24 heures permet d’autres procédures (p. ex. bandes hors site) qu’un RTO de 2 heures (p. ex. réplication basée sur des snapshots plus pipelines de RESTauration rapides). Dans les audits, c’est précisément cette traçabilité qui est centrale : pourquoi une méthode est‑elle « appropriée » et comment son respect est‑il vérifié régulièrement ?

Cadre décisionnel pour les CIOs : résoudre clairement trois conflits d’objectifs

La plupart des organisations échouent non pas sur la « technique », mais sur des conflits d’objectifs non explicitement tranchés. Pour une décision coût‑bénéfice robuste, vous devriez résoudre et documenter trois champs de tension :

1) Sécurité vs. opérabilité (réalité du ransomware)

Les acteurs de ransomware ciblent spécifiquement les sauvegardes, les comptes admin et les catalogues de sauvegarde. De « bonnes » sauvegardes nécessitent donc non seulement le chiffrement, mais aussi un protection contre la manipulation (immutable, WORM) et une séparation des identités (comptes/clefs séparés, parcours admin distincts). Toute simplification en exploitation peut ouvrir une surface d’attaque.

2) Prévisibilité des coûts vs. élasticité

On-Prem est typiquement axé sur le capital et le cycle de vie (CapEx + amortissement, maintenance, électricité/espace). Le Cloud est basé sur l’usage (OpEx), mais comporte des composants variables : classe de stockage, requêtes API, indexation, egress (flux de données), réplication inter‑régions. La prévisibilité des coûts est réalisable, mais seulement avec de la gouvernance (budgets, tags, quotas, rapports).

3) Conformité / résidence des données vs. exploitation

Les exigences réglementaires (p. ex. conservation, traçabilité, contrôle d’accès) entrent souvent en conflit avec une pratique de sauvegarde « simple ». La résidence des données ne se réduit pas à « choisir une région », mais implique aussi : qui a accès ? Où sont les clés ? Quels sous‑traitants sont impliqués ? Comment un exit est‑il démontré ? Ces questions doivent être coordonnées entre l’approvisionnement, la sécurité et l’exploitation.

Options en comparaison : On-Prem, Cloud, Hybrid — et quand chaque variante est pertinente

Sauvegarde On-Prem : contrôle, mais charge opérationnelle complète

Les sauvegardes On-Prem (référentiel de sauvegarde local, éventuellement second centre de données ou bande) offrent un contrôle maximal des chemins de données et des latences. Forces typiques :

• Faible latence de RESTauration sur le réseau local, en particulier pour de grands volumes de données (images de VM, serveurs de fichiers).
• Maîtrise claire des données (contrôle physique, gestion des clés interne, chemin d’accès propre).
• Profil de coûts souvent prévisible, lorsque le cycle de vie et la planification de capacité sont matures.

Faiblesses typiques, qui posent problème en pratique :

• Externalisation coûteuse : manipulation des supports, transport, stockage, site secondaire, ou réplication via WAN.
• Mise à l’échelle nécessite des investissements préalables ; les pics de capacité sont onéreux.
• Risque de ransomware : si les serveurs de sauvegarde et le stockage se trouvent dans le même domaine d’identité et de réseau, la sauvegarde est souvent « compromise avec ».

Sauvegarde Cloud : offsite par défaut, mais nouveaux enjeux de coûts et de contrôle

Les sauvegardes cloud (Object Storage, services de sauvegarde cloud ou dépôts de sauvegarde propres dans le cloud) sont très attractives pour l’externalisation. Forces :

• Séparation physique du centre de données propre, utile en cas de panne de site.
• Mise à l’échelle sans délai ; le stockage augmente selon les besoins.
• Options immuables (p. ex. Object-Lock / mécanismes WORM) sont souvent techniquement réalisables.

Faiblesses et pièges typiques :

• Coûts et temps de RESTauration : les gros RESTores peuvent devenir coûteux et lents à cause de la bande passante et des frais d’egress.
• Gouvernance plus complexe : Identity & Access Management (IAM), gestion des clés, journalisation, rôles des fournisseurs, séparation des locataires.
• Risque de sortie : la RESTitution des données et le changement de pRESTataire doivent être planifiés et testés de manière réaliste.

Sauvegarde hybride : standard en pratique, mais seulement avec des règles claires

Dans de nombreux environnements, l’hybride (local rapide + cloud/offsite robuste) est le meilleur compromis. Schéma typique : sauvegardes locales rapides (pour la RESTauration opérationnelle), plus externalisation cloud avec immutabilité (pour sinistres et ransomware). Le bénéfice n’existe toutefois que si vous décidez clairement :

• Quelles charges de travail peuvent être sauvegardées uniquement localement (p. ex. latence, classification des données) ?
• Quelles doivent obligatoirement être offsite/immutables (p. ex. données ERP/production critiques) ?
• Comment éviter que le même chemin d’administration ne puisse détruire à la fois la production et la sauvegarde ?

Calcul coûts-bénéfices rigoureux : quels blocs de coûts les DSI (CIOs) négligent souvent

Une décision solide nécessite un modèle de coûts qui reflète la réalité – pas seulement « prix du stockage par To ». Une répartition pratique consiste à distinguer coûts directs, indirects et coûts liés aux risques/conséquences.

Coûts directs (visibles dans le budget)

• Stockage : On-Prem (disque/bande/stockage objet), Cloud (classe de stockage, réplication).
• Logiciel de sauvegarde/Abonnements : licences, agents, métriques de capacité.
• Réseau : connectivité WAN, VPN/Direct Connect, le cas échéant seconde liaison.
• Capacité de calcul pour RESTauration/validation : environnements de test, redémarrage dans le Cloud, fenêtres de RESTauration.

Coûts indirects (personnel, temps, processus)

• Charges d’exploitation : patching, monitoring, gestion de capacité, rotation des supports, résolution des incidents.
• Gestion des changements : nouvelles applications, nouvelles sources de données, nouvelles politiques, nouveaux rôles d’accès.
• Effort d’audit et de preuve : journaux, rapports, preuves de RESTauration, documentation.

Coûts de risque et conséquences (pertinent pour le CIO, souvent hors budget IT)

• Arrêt de production (chiffre d’affaires, pénalités contractuelles, retard de livraison).
• Perte de données (reconstruction, reprise de travail, conséquences juridiques).
• Atteinte à la réputation et escalade jusqu’au conseil d’administration/instances de supervision.
• Pouvoir de négociation en cas de ransomware : sans sauvegarde propre et isolée démontrable, la pression augmente considérablement.

Pour la décision coûts/bénéfices, un format accepté par le comité des risques est conseillé : « Kosten pro erreichter RTO/RPO-Klasse » plus « REST-Risiko » (quels scénarios RESTent critiques malgré la sauvegarde ?).

Gouvernance et responsabilités : qui décide quoi – et qui signe ?

La sauvegarde est une tâche transversale. Si les responsabilités ne sont pas claires, se crée une situation dangereuse : exploitée techniquement, mais non légitimée sur le plan métier. Il est recommandé d’avoir une répartition claire :

• Service Owner (Fach/IT) : définit la criticité métier, le RTO/RPO acceptable, la classification des données.
• IT-Betrieb : met en œuvre les procédures, exploite le monitoring, réalise les tests de RESTauration, maintient les runbooks.
• Security : définit les contrôles minimaux (immutabilité, MFA, segmentation, gestion des clés, journalisation), examine les surfaces d’attaque.
• Compliance/Datenschutz : vérifie la conservation, les accès, les politiques de suppression, la résidence des données, les aspects liés aux pays tiers.
• CIO/IT-Leitung : décide du niveau cible, du cadre budgétaire, du risque résiduel acceptable, de la stratégie fournisseur.

Pour les audits, il ne suffit pas que « quelqu’un » s’en occupe : il faut un modèle opérationnel traçable : politiques, exceptions, cycles de revue et tests fondés sur des preuves.

Perspective d’audit : quelles preuves vous faut-il en pratique

Qu’il s’agisse de la révision interne, d’un auditeur externe ou d’un questionnaire client : des points de contrôle typiques reviennent régulièrement. Si vous les couvrez systématiquement, la sauvegarde passe de l’intuition à une capacité démontrable.

Preuves demandées presque systématiquement

• Politique de sauvegarde : périmètre, fréquence, conservation, responsabilités, chiffrement, hors site.
• Inventaire système / cartographie des données : quels systèmes sont sauvegardés, lesquels ne le sont pas, et pourquoi ?
• Tests de RESTauration : journaux, résultats, écarts, mesures (incl. retest).
• Concept d’accès et de clés : qui peut supprimer les sauvegardes, qui peut effectuer une RESTauration, comment cela est consigné ?
• Résilience face aux ransomwares : parts immutables/air-gapped, identités séparées, accès d’urgence.
• Plan de sortie (pour le Cloud) : RESTitution des données, délais, hypothèses de coûts, étapes techniques.

Positionnement réglementaire (sans énumération d’articles)

Indépendamment du cadre réglementaire concret (spécifique au secteur, exigences clients, gouvernance interne), tout se ramène aux mêmes principes fondamentaux : disponibilité, intégrité, confidentialité, traçabilité et contrôles appropriés. Il est essentiel que vous justifiiez ce qui est « approprié » par votre besoin de protection : les systèmes critiques se voient attribuer des objectifs RTO/RPO plus stricts, une isolation renforcée et des tests plus fréquents.

Garde-fous techniques qui simplifient les décisions

Le choix concret des produits est secondaire si les garde-fous sont en place. Les mécanismes suivants sont particulièrement pertinents pour l’exploitation :

Immutabilité et Air-Gap : deux mécanismes de protection distincts

Des sauvegardes immuables sont techniquement protégées contre toute modification/suppression ultérieure (similaire à WORM). Cela protège fortement contre le « l’administrateur qui supprime tout », mais pas nécessairement contre tous les scénarios (p. ex. mauvaise configuration avant le verrouillage, gestion des clés compromise, ou manipulation du catalogue). Un Air-Gap signifie une séparation opérationnelle : les sauvegardes ne sont temporairement ou définitivement pas accessibles depuis le réseau de production. L’Air-Gap peut être réalisé physiquement (bande), logiquement (réseau/compte séparé) ou organisationnellement (rôles séparés, identifiants séparés). Dans la pratique, les combinaisons sont les plus efficaces.

Chiffrement : au repos, en transit et maîtrise des clés

« Chiffré » n’a pas de valeur sans contexte. Vérifiez trois niveaux : chiffrement de transport (en transit), chiffrement de stockage (au repos) et gestion des clés (qui contrôle les clés, comment sont gérés la rotation et l’accès d’urgence). Pour la conformité, la journalisation des accès aux clés et le principe des quatre yeux pour les actions particulièrement critiques comptent également.

Réseau et identité : la partie sous-estimée des sauvegardes cloud

De nombreux désastres de RESTauration ne sont pas des problèmes de données mais des problèmes réseau et d’identité : routes manquantes, ports bloqués, identifiants expirés, rôles incorrects. Lorsque la sauvegarde est destinée au cloud, la RESTauration doit être testée incluant les chemins réseau nécessaires, les dépendances DNS et les rôles IAM. Sinon, vous ne testez que « copier des données », pas « RESTaurer le service ».

Matrice de décision : quelles charges de travail doivent être sauvegardées où

Une matrice adaptée au DSI ne se base pas sur la technologie, mais sur les caractéristiques des workloads. Utilisez les critères suivants comme modèle standardisé :

• Criticité : impact sur le chiffre d’affaires/la sécurité/la réputation en cas d’indisponibilité
• Taux de modification des données : influence l’objectif RPO et le volume de transfert
• Volume de données : influence le temps de RESTauration et les coûts d’egress
• Dépendances : base de données + fichiers + configuration + secrets doivent être cohérents ensemble
• Conformité : conservation, obligations de suppression, résidence des données, journaux d’accès
• Modèle de menace : cible pour l’immutabilité/Air-Gap, voies d’administration séparées

Affectations typiques (point de départ, pas un dogme) :

• Tier-1 (critique) : options de RESTauration rapides locales + copie immuable hors site + exercices de RESTauration réguliers
• Tier-2 (important) : local ou cloud, selon le volume de données ; offsite obligatoire, immutabilité recommandée
• Tier-3 (de soutien) : sauvegarde rentable, RTO/RPO plus longs, mais capacité de RESTauration démontrable

Tests de RESTauration comme instrument de pilotage : comment atteindre « 0 » dans 3-2-1-1-0

La règle connue 3-2-1 (trois copies, deux supports, un hors site) est aujourd’hui souvent étendue en 3-2-1-1-0 : en plus une copie immuable/hors ligne et 0 erreur dans des tests de RESTauration vérifiés. La composante « 0 » est la partie pertinente pour la direction : vous n’avez pas besoin de sauvegardes parfaites, mais d’un processus qui détecte les erreurs, les priorise et les corrige.

Ce que les tests de RESTauration doivent couvrir en pratique

• RESTauration de fichiers (cas opérationnels) : fichiers individuels, permissions/ACL, états de version
• RESTauration d’application : base de données + données applicatives cohérentes, ordre de démarrage, états de configuration
• RESTauration système : VM/serveur, capacité de démarrage, pilotes, réseau
• Scénario de sinistre : redémarrage depuis hors site/Cloud incluant IAM, réseau, DNS, secrets

Important pour l’auditabilité : chaque test doit comporter date, périmètre, résultat, écarts, référence de ticket et re-test. Cela rend la sauvegarde « vérifiable » plutôt que « affirmée ».

Listes de contrôle pratiques et modèles (utilisables en audit)

Checklist 1 : risques de sauvegarde Cloud avant mise en production

• Le RTO/RPO par service est-il approuvé et documenté ?
• Existe-t-il des identités séparées pour la sauvegarde (compte/mandant/abonnement séparé) et les droits d’administration sont-ils minimisés ?
• Les mécanismes d’immutabilité sont-ils activés et protégés contre les erreurs de configuration (p. ex. verrouillage de gouvernance, rôle séparé) ?
• La gestion des clés est-elle définie (rotation, accès d’urgence, journalisation) ?
• Les coûts de RESTauration (egress, compute temporaire) ont-ils été pris en compte dans le modèle budgétaire ?
• Existe-t-il un plan de sortie avec étapes techniques et hypothèses de temps/coûts ?
• Y a‑t‑il un monitoring des échecs de sauvegarde, des dérives de politiques de rétention et de l’état d’immutabilité ?

Checklist 2 : risques de sauvegarde On-Prem avant mise en production

• Le hors site est-il configuré de manière à couvrir la défaillance d’un site et la compromission de domaine ?
• Y a‑t‑il une segmentation réseau (réseau de sauvegarde) et des parcours administrateurs séparés ?
• Les sauvegardes sont‑elles protégées contre la suppression/la manipulation (WORM/immuables ou médias hors ligne) ?
• La planification de capacité, incluant la croissance et la rétention, est‑elle robuste (pas de « réduction silencieuse » de la rétention) ?

Modèle : Minimal-Backup-Policy (structure du contenu)

La structure suivante a fait ses preuves pour maintenir une politique courte mais vérifiable :

• Périmètre et définitions (Backup vs. Archiv, RTO/RPO, Offsite, immutable)
• Classification des services (modèle par tiers) et responsabilités
• Fréquences de sauvegarde, conservation, médias/cibles (On-Prem/Cloud)
• Contrôles de sécurité (MFA, rôles, clés, segmentation, journalisation)
• Tests de RESTauration (fréquence, périmètre, preuves, escalade)
• Processus d’exceptions (approbation, durée, mesures compensatoires)
• Cycle de revue (p. ex. semestriel) et reporting à la direction IT/comité des risques

Artefacts concrets et copiables (politiques & étapes de vérification)

Les blocs source suivants sont volontairement génériques afin de servir de point de départ pour les standards internes. Ils ne remplacent aucune configuration détaillée, mais aident à formuler des documents aptes à l’audit.

# Exemple : Exigences de contrôle des sauvegardes (standard court)
# Objet : contrôles minimaux pour tous les services critiques (Tier-1)

- Il existe au minimum deux rôles administratifs :
  (1) Backup-Operator (gestion des RESTaurations / gestion des jobs)
  (2) Backup-Security-Admin (rétention/immutabilité/modifications de la politique)

- Les sauvegardes sont transmises chiffrées et stockées chiffrées.
  Gestion des clés : documentée, rotation régulière, accès consignés.

- Au moins une copie est protégée contre la suppression/la manipulation (immutable ou hors ligne).

- Tests de RESTauration :
  - mensuel : RESTauration par échantillonnage de fichiers/bases de données
  - trimestriel : RESTauration d'application dans un environnement de test isolé
  - annuel : scénario de sinistre depuis Offsite incluant réseau/IAM

- Traçabilité :
  - chaque test crée un ticket avec résultat, écarts, mesures, rétest.

# Exemple : Catalogue de questions d'audit (extrait)

1) Quels systèmes ne sont PAS dans le périmètre de sauvegarde ? Qui a approuvé le risque résiduel ?
2) Comment est-il empêché qu'un compte Domain-Admin compromis supprime les sauvegardes ?
3) Où est documentée la dernière RESTauration réussie d'un service Tier-1 ?
4) Comment l'application des durées de rétention est-elle garantie techniquement ?
5) À quoi ressemble le plan de sortie du cloud (récupération des données, coûts, délais) ?

# Exemple : Structure de runbook de RESTauration (sans référence produit)

- Déclencheur/type d'incident (ransomware, défaillance matérielle, erreur d'exploitation, indisponibilité de site)
- Arbre de décision : RESTauration locale vs RESTauration offsite vs redéploiement + RESTauration
- Dépendances : DNS, certificats, secrets, rôles IAM, segments réseau
- Ordre : DB -> middleware -> application -> batch/Jobs -> interfaces
- Validation : consistance des données, droits utilisateurs, états des transactions
- Communication : parties prenantes, calendriers, documentation pour audit/retour d'expérience

Décisions erronées typiques – et comment les éviter

« Nous sommes dans le cloud, donc les sauvegardes sont assurées »

Les SLA cloud ne remplacent pas une stratégie de sauvegarde. De nombreux services de plateforme offrent de la redondance, mais pas nécessairement des RESTaurations point-in-time, une conservation longue durée ni une protection contre les erreurs logiques (mauvaise configuration, suppression, ransomware via des comptes compromis). Clarifiez explicitement : quelles données sont couvertes par les mécanismes du fournisseur, et lesquelles ne le sont pas ?

« Nous avons Offsite, donc nous sommes en sécurité »

Le stockage hors site sans immutabilité et sans identités séparées peut tomber lors d’une attaque tout comme le dépôt sur site. Ce qui compte, c’est la séparation des pouvoirs : qui administre la production ne doit pas pouvoir détruire les sauvegardes automatiquement.

« Nous ne testons la RESTauration qu’une fois par an »

Un test annuel vaut mieux que rien, mais sur le plan opérationnel il est souvent trop rare : changements de personnel, sauts de version, nouvelles dépendances, nouvelles clés – tout cela conduit à des erreurs de RESTauration silencieuses. Un modèle à paliers est plus pertinent : des petits tests fréquents et des exercices de sinistre majeurs plus espacés.

Plan de mise en œuvre recommandé en 6 étapes (réalisable en 90 jours)

Pour les CIO, il est important d’avoir une séquence exécutable qui réduit rapidement les risques tout en établissant la gouvernance.

1. Scope & Tiering : classifier les services, définir les RTO/RPO par niveau (tier), rendre les exceptions soumises à approbation.
2. Architecture cible : décider On-Prem/Cloud/Hybrid par niveau, hors site/immutabilité comme standard minimal pour le Tier-1.
3. Identity & Separation : rôles séparés, MFA, comptes/Subscriptions séparés, journalisation obligatoire.
4. Retention & Kostenmodell : faire respecter la rétention techniquement, inclure les postes de coûts (y compris RESTore/Egress) dans le reporting.
5. Opérationnaliser les tests de RESTauration : calendrier des tests, runbooks, preuves (tickets/rapports), voies d’escalade.
6. Audit-Readiness : finaliser la politique, centraliser les preuves, revues régulières (p. ex. semestrielles) au sein du comité des risques.

Conclusion : la meilleure stratégie de sauvegarde est celle que vous pouvez RESTaurer régulièrement

La décision coût-bénéfice entre On-Prem et le cloud n’est pas une question de croyance, mais une question d’objectifs (RTO/RPO), de modèle de menace (Ransomware), de gouvernance (rôles, contrôles, preuves) et d’un modèle de coûts qui intègre la réalité des RESTaurations et la capacité de sortie. Dans la pratique, l’approche hybride est souvent la plus viable : localement rapide pour l’exploitation quotidienne, cloud/hors site robuste et immuable pour le cas grave. L’essentiel est de traiter les sauvegardes comme un processus répétable avec tests, responsabilités et preuves auditables — ainsi la sauvegarde cesse d’être une « assurance sur papier » pour devenir une résilience opérationnelle concrète.

Les sauvegardes hors site sont également importantes pour ce sujet. Cet article situe clairement ces aspects et montre ce qui compte au quotidien.