Sauvegarde et restauration cloud : bâtir une stratégie de cyber-résilience

SECTION 1

Pourquoi la sauvegarde cloud est devenue un enjeu de cyber-résilience

La sauvegarde dans le cloud consiste à conserver des copies de ses données et de ses applications sur une infrastructure distante, pour les garder disponibles même en cas de défaillance du système d'origine. C'est l'un des tout premiers usages du cloud, mais son rôle a profondément changé : en 2026, la sauvegarde n'est plus une simple assurance contre la panne de disque, c'est une brique centrale de la cyber-résilience de l'entreprise, au même titre que la détection d'intrusion ou la gestion des identités.

La raison est simple : les attaquants l'ont compris avant beaucoup de défenseurs. La majorité des campagnes de rançongiciel ciblent désormais explicitement les dépôts de sauvegarde, suppression des snapshots, chiffrement des dépôts, révocation des accès, afin de priver la victime de toute alternative au paiement. Une stratégie de sauvegarde conçue pour résister à un sinistre matériel, mais pas à un adversaire actif disposant de comptes d'administration compromis, ne protège plus grand-chose.

La question posée aux directions techniques a donc changé de nature : elle n'est plus « sauvegardez-vous vos données ? » mais « pouvez-vous prouver que vous savez les restaurer, dans un délai défini, après un incident majeur ? ». Ce déplacement du regard, de la copie vers la reprise prouvée, structure toutes les bonnes pratiques actuelles et tout le reste de cet article.

SECTION 2

Sauvegarde cloud : définition, fonctionnement et modèles BaaS

Une sauvegarde cloud est une copie de fichiers, de bases de données ou de systèmes complets conservée sur une infrastructure distante, hors du site de production. Parce qu'elle est physiquement et logiquement séparée de l'environnement d'origine, elle résiste aux incidents locaux, panne matérielle, sinistre, erreur humaine, qui condamnent une sauvegarde stockée au même endroit que les données qu'elle protège.

La fréquence se calibre sur le rythme de changement des données : snapshots horaires, voire réplication continue, pour une base transactionnelle ; sauvegardes quotidiennes pour les documents et les configurations ; copies hebdomadaires pour l'archivage froid. Des politiques de rétention automatisées suppriment les copies expirées, ce qui maîtrise les coûts de stockage sans intervention manuelle.

Le type de copie compte autant que la fréquence : la sauvegarde complète offre la restauration la plus simple, l'incrémentale ne transfère que les blocs modifiés depuis la dernière copie, et les snapshots cohérents au niveau applicatif garantissent que les bases de données sont capturées dans un état exploitable au moment précis de la copie.

### Du script artisanal aux plateformes BaaS managées

L'époque du script de copie nocturne vers un bucket est révolue. Les hyperscalers proposent des services managés, AWS Backup, Azure Backup, Google Cloud Backup and DR, qui centralisent politiques, chiffrement, rétention et supervision pour l'ensemble des ressources d'un compte. À leurs côtés, des plateformes spécialisées comme Veeam, Rubrik ou Cohesity couvrent les environnements hybrides et multi-cloud, et ajoutent des capacités de détection d'anomalies et de reprise orchestrée. Le modèle Backup as a Service (BaaS) facture à l'usage, volume protégé, durée de rétention, bande passante, et supprime tout investissement dans une infrastructure de sauvegarde dédiée.

SECTION 3

RPO, RTO et règle 3-2-1-1-0 : dimensionner sa stratégie de sauvegarde

Deux indicateurs structurent toute stratégie sérieuse. Le RPO (Recovery Point Objective) définit la perte de données maximale acceptable : un RPO d'une heure impose des sauvegardes au moins horaires. Le RTO (Recovery Time Objective) fixe la durée maximale d'indisponibilité tolérée avant la remise en service. Ces deux objectifs se négocient avec les métiers, car ce sont eux qui savent ce qu'une heure de données perdues ou un jour d'arrêt coûte réellement.

### Classer les données par criticité métier

Appliquer les mêmes objectifs à tout le système d'information est le premier anti-pattern à éviter : c'est soit hors de prix, soit dangereusement insuffisant. La bonne pratique consiste à classer les données en quelques niveaux de criticité, transactionnel critique, opérationnel, archivage réglementaire, puis à attribuer à chaque classe son RPO, son RTO et son budget propres. Ce classement guide ensuite le choix des fréquences, des classes de stockage et des mécanismes de restauration. Dans la plupart des organisations, moins de 20 % des données justifient un RPO inférieur à l'heure : concentrer l'investissement sur ce périmètre libère du budget pour fiabiliser tout le reste.

La règle de référence a elle aussi évolué : au classique 3-2-1 (trois copies des données, sur deux supports différents, dont une copie hors site) s'est ajouté le 3-2-1-1-0, une copie supplémentaire immuable ou hors ligne, et zéro erreur constatée lors des tests de restauration. Ces deux derniers chiffres font toute la différence face aux menaces actuelles : sans copie inaltérable et sans vérification régulière, les trois premières copies peuvent être chiffrées ou corrompues en même temps que la production.

SECTION 4

Immutabilité et air gap : protéger les sauvegardes des rançongiciels

Une sauvegarde accessible en écriture depuis le réseau de production est une cible, pas une protection. Les attaquants qui obtiennent des privilèges d'administration cherchent systématiquement à neutraliser les sauvegardes avant de déclencher le chiffrement des données de production : c'est ce scénario, et non plus la panne de disque, qui dimensionne les architectures modernes. Les chiffres publiés par les éditeurs de sécurité sont sans ambiguïté : dans plus de deux tiers des attaques récentes, les dépôts de sauvegarde ont été visés avant les systèmes de production.

### Object lock et stockage WORM : rendre la copie inaltérable

L'immutabilité répond directement à cette menace. Les fonctions de verrouillage des stockages objet, S3 Object Lock chez AWS, stockage immuable chez Azure et Google Cloud, appliquent un régime WORM (write once, read many) qui interdit toute modification ou suppression pendant une durée définie, y compris par un administrateur dont le compte serait compromis. Cette copie inaltérable est devenue le standard de survie face aux rançongiciels, et un prérequis courant des assureurs cyber.

L'air gap logique complète le dispositif : compte cloud dédié aux sauvegardes, identifiants et annuaire distincts, flux de réplication unidirectionnel. Le chiffrement systématique, en transit et au repos, avec des clés gérées séparément des données, et l'authentification multifacteur sur les consoles de sauvegarde ferment les dernières portes. Enfin, les plateformes récentes embarquent une détection d'anomalies assistée par IA qui repère un taux de chiffrement inhabituel dans les nouvelles sauvegardes : c'est souvent le signal le plus précoce d'une attaque en cours.

@cite:securite-cloud-defis-et-solutions

SECTION 5

Restauration : tester, automatiser et prouver la capacité de reprise

La restauration est le seul moment de vérité d'une stratégie de sauvegarde, et c'est précisément là que les organisations échouent. Les études sur les victimes de rançongiciel convergent : une majorité d'entre elles ne récupèrent qu'une partie de leurs données alors qu'elles disposaient de sauvegardes, et l'écart entre le délai de reprise estimé et le délai réellement constaté se compte souvent en jours. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.

### Automatiser les tests de restauration

La parade est connue : tester, régulièrement et automatiquement. Les plateformes modernes savent restaurer chaque sauvegarde dans un environnement isolé, démarrer le système, vérifier son intégrité applicative, la base répond, l'application sert des requêtes, puis détruire l'environnement, sans intervention humaine. Ce test continu transforme le « zéro erreur » de la règle 3-2-1-1-0 en métrique mesurable et auditable plutôt qu'en vœu pieux, et alimente des tableaux de bord que dirigeants et auditeurs peuvent consulter. Des exercices de reprise grandeur nature, les « game days »,complètent ces tests techniques en entraînant aussi les équipes, les procédures d'escalade et la communication de crise.

Pour les incidents majeurs, la pratique de la clean room s'est imposée : restaurer dans un environnement vierge et isolé, y analyser les copies pour identifier le point de restauration sain, antérieur à l'intrusion, qui précède souvent le chiffrement de plusieurs semaines, puis reconstruire par étapes en réintégrant les services validés. Restaurer aveuglément la sauvegarde la plus récente revient trop souvent à réinstaller la porte dérobée de l'attaquant.

@cite:gestion-de-la-reponse-a-incident

SECTION 6

Conformité DORA, NIS2 et maîtrise des coûts de sauvegarde

Le régulateur européen a acté que l'incident majeur finira par arriver. Le règlement DORA, applicable au secteur financier depuis janvier 2025, et la directive NIS2, déployée dans les secteurs critiques, exigent des entités concernées qu'elles prouvent, et non qu'elles affirment, leur capacité à restaurer leurs opérations dans un délai défini, tests à l'appui.

### Ce que ces textes changent concrètement

Dans la pratique, cela impose des objectifs de reprise documentés par service critique, des sauvegardes logiquement et physiquement isolées du système d'information principal, des tests de restauration périodiques dont les résultats sont auditables, et une notification rapide des incidents significatifs. Pour beaucoup d'organisations, la conformité est ainsi devenue le principal moteur budgétaire de la modernisation des sauvegardes, un levier à utiliser plutôt qu'une contrainte à subir.

### Optimiser les coûts : tiering, cycle de vie et frais de sortie

La résilience n'oblige pas à l'explosion des coûts. Les politiques de cycle de vie déplacent automatiquement les copies anciennes vers des classes de stockage froides, nettement moins chères ; la déduplication et la compression réduisent les volumes transférés et stockés ; et les frais de sortie (egress) doivent être intégrés au calcul dès la conception, car une restauration massive depuis un stockage d'archive peut coûter plus cher que plusieurs années de rétention. Le bon arbitrage se fait par classe de données, jamais globalement.

@cite:ia-et-resilience-it

SECTION 7

L'approche Adservio : une restauration éprouvée plutôt qu'une promesse

Chez Adservio, nous considérons qu'une sauvegarde n'a de valeur que si la restauration a été éprouvée. Trop d'organisations planifient des copies régulières sans jamais vérifier leur capacité à reconstruire un système le jour d'un incident : c'est précisément ce test, répété et automatisé, que nous plaçons au cœur de la démarche.

Notre accompagnement commence par une cartographie des données réellement critiques et de leurs objectifs de reprise, se poursuit par la mise en place d'une architecture 3-2-1-1-0 avec copies immuables, air gap logique et tests de restauration automatisés, et se conclut par un transfert de compétences aux équipes internes. L'objectif : que la capacité de reprise devienne une propriété mesurable et durable de votre système d'information, et non une ligne d'un plan de reprise d'activité jamais exercé. Cette démarche s'appuie sur nos expertises cloud, SRE et observabilité, et s'adapte aussi bien aux environnements entièrement cloud qu'aux architectures hybrides.

FAQ

Questions fréquentes