Migration cloud : les erreurs de sauvegarde que personne n’ose vous avouer

Le cloud s’est imposé comme la colonne vertébrale des systèmes d’information, et pourtant, à mesure que les entreprises accélèrent leurs migrations, une série d’erreurs de sauvegarde se répète, discrètement, souvent découverte trop tard, au moment d’un ransomware, d’une suppression accidentelle ou d’une panne chez un prestataire. Derrière les promesses de résilience, les chiffres rappellent une réalité plus rugueuse : la disponibilité ne vaut pas sauvegarde, et l’addition peut exploser quand la gouvernance n’a pas suivi.

La confusion fatale entre disponibilité et sauvegarde

Vous êtes sûr d’être sauvegardé ? Beaucoup d’organisations confondent encore, au moment de migrer, les mécanismes de haute disponibilité avec une véritable stratégie de sauvegarde, et cette confusion coûte cher lorsque survient l’incident qui n’entre dans aucun scénario “standard”. Un service peut être répliqué sur plusieurs zones, disposer d’instantanés, voire d’une tolérance de panne avancée, sans pour autant garantir une restauration fiable après corruption logique, chiffrement malveillant ou erreur humaine. Les grands fournisseurs l’écrivent noir sur blanc dans leurs modèles de responsabilité partagée : ils sécurisent l’infrastructure, mais la protection des données, la conservation et la capacité de restauration restent, en grande partie, du ressort du client.

Les incidents récents l’ont rappelé : la majorité des sinistres ne viennent pas d’un data center en flammes, mais d’actions banales qui se propagent vite. Une mauvaise commande d’administration, une règle d’automatisation mal testée, un compte compromis, et ce sont des volumes entiers qui passent à la trappe, parfois avec des sauvegardes “connectées” et donc vulnérables à l’attaque. Les recommandations internationales convergent pourtant, notamment celles du NIST : appliquer la règle du 3-2-1, conserver au moins une copie hors ligne ou immuable, et tester la restauration comme un exercice de production, pas comme une formalité. Dans la pratique, beaucoup découvrent au pire moment qu’ils avaient surtout acheté de la disponibilité, et très peu de capacité de retour arrière.

Rétention mal réglée, facture et risques explosent

Le piège, c’est la ligne “storage” qui gonfle. Dans le cloud, la sauvegarde ne se paie pas uniquement à l’acte, elle se paie dans la durée, et une rétention mal pensée transforme rapidement une bonne intention en surcoût structurel, ou en prise de risque silencieuse. Trop conserver, c’est payer des téraoctets de versions inutiles, multiplier les frais de requêtes, de transferts, et parfois de restauration, surtout quand des données sont basculées vers des classes d’archivage avec délais de récupération. Conserver trop peu, c’est raccourcir la fenêtre de récupération, et rendre impossible le retour à un état sain lorsque la compromission a commencé des semaines plus tôt, un classique dans les intrusions modernes où l’attaquant se fait discret avant de frapper.

Les assureurs cyber, de plus en plus exigeants, regardent précisément ces paramètres, car une politique de sauvegarde n’a de valeur que si elle est gouvernée : qui peut supprimer une sauvegarde, qui peut modifier la rétention, où sont stockées les clés, et quelles preuves existent sur les tests de restauration. Les contrats et les clauses de service comptent aussi, car une sauvegarde hébergée dans la même logique d’accès que la production, sans segmentation, revient souvent à mettre le double des clés sous le même paillasson. C’est ici que les choix d’architecture rencontrent le juridique, et que la compréhension des engagements de l’hébergeur, des niveaux de service, des responsabilités et des options de réversibilité devient centrale, pour cadrer cela en amont, cliquez sur ce lien maintenant.

Tests de restauration : l’angle mort des plans cloud

Le jour J, tout se joue en heures. Beaucoup d’entreprises pensent avoir un plan de sauvegarde parce qu’elles voient des jobs “verts” dans une console, mais sans tests de restauration réguliers, la sauvegarde n’est qu’une hypothèse. Restaurer, c’est vérifier des dépendances, des versions, des droits, des schémas de base de données, des certificats, des secrets applicatifs, et l’ordre dans lequel on remonte les briques. Dans des environnements cloud modernes, où les microservices, l’infrastructure as code et les composants managés s’imbriquent, la restauration peut échouer non pas sur les données elles-mêmes, mais sur ce qui les rend exploitables : réseau, DNS, IAM, politiques, images, pipelines et paramètres.

Les bonnes pratiques parlent RPO et RTO, deux indicateurs qui doivent être définis service par service, et validés par des tests concrets. Un RPO de 24 heures n’a pas le même sens pour une messagerie que pour un système de facturation, et un RTO “sur le papier” s’écroule si la restauration nécessite des interventions manuelles en chaîne. Les équipes qui s’en sortent organisent des exercices, mesurent le temps réel, documentent les décisions, et automatisent les retours arrière. Elles utilisent aussi des environnements isolés pour tester, afin de ne pas contaminer la production, et elles vérifient l’intégrité des sauvegardes, car des fichiers sauvegardés ne sont pas forcément des fichiers restaurables. Autrement dit : on ne découvre pas un plan de reprise pendant la crise, on l’a répété avant.

IAM, chiffrement, immutabilité : trois détails décisifs

Le ransomware vise vos sauvegardes, pas seulement vos serveurs. Dans le cloud, la surface d’attaque se déplace : moins de machines à patcher, mais plus de permissions, d’API, de clés, et de configurations à surveiller. Un compte d’administration trop large, une clé d’accès qui traîne, et l’attaquant peut supprimer les snapshots, réduire la rétention, ou déclencher des opérations de chiffrement à grande échelle. Les incidents les plus destructeurs exploitent souvent cette faiblesse : des droits excessifs, accordés pour “aller vite” pendant la migration, et jamais révoqués ensuite. La règle est connue, rarement appliquée à la lettre : moindre privilège, séparation des rôles, et journalisation exhaustive avec alertes sur les actions critiques.

Le chiffrement, lui, se joue aussi sur la gestion des clés. Chiffrer “par défaut” ne suffit pas si l’on ne sait pas qui contrôle la clé, comment elle est tournée, et comment on restaure si l’accès au gestionnaire de secrets est interrompu. Les options d’immutabilité, de verrouillage de coffre, ou de conservation WORM, sont devenues un standard de résilience, car elles empêchent la suppression ou l’altération des sauvegardes pendant une période donnée, y compris par un administrateur compromis. Mais ces mécanismes se préparent : ils exigent une architecture, des procédures de dérogation, et une gouvernance, sinon l’entreprise risque de se piéger elle-même, incapable de supprimer des données sensibles conservées trop longtemps. Dans un contexte de RGPD et de durcissement des contrôles, la résilience se construit donc avec une boussole claire : protéger, mais aussi prouver, et savoir effacer quand la loi l’exige.

Avant de migrer, une check-list utile

Réservez du temps pour cadrer la sauvegarde, autant que la migration. Fixez un budget dédié, car la rétention, l’archivage, les tests et l’immutabilité ont un coût récurrent, et cherchez les aides disponibles, notamment via les dispositifs de cybersécurité des régions, des filières et de Bpifrance selon votre profil. Exigez des tests de restauration, et contractualisez-les.