La sauvegarde n'est pas un script. C'est un audit de continuité.

Quand on parle de sauvegarde en entreprise, la conversation s'arrête presque toujours au même endroit : un cron (tâche automatisée), un snapshot (un sauvegarde instantanée), une case cochée sur un audit de conformité. Le sujet est classé, rangé, oublié jusqu'au jour où il se rappel à notre bon souvenir...

J'ai eu l'occasion de concevoir l'architecture de continuité d'une librairie indépendante, éditeur de son propre système de gestion. Ce cas concret illustre bien pourquoi cette vision technique du sujet est incomplète, et parfois dangereuse.

Un système, deux logiques métier

Cette librairie repose sur deux briques distinctes :

• Un site e-commerce, vitrine de vente, qui doit rester disponible et à jour en permanence : stocks, fiches produits, images.
• Un système de gestion interne, propriétaire, qui pilote le métier réel : les commandes fournisseurs et les mises à jours de fiches livres via Dilicom, la facturation via Henrri, la synchronisation avec le site de vente (avec WordPress et WooCommerce). C'est dans cet ERP que vit la donnée qui a de la valeur : le catalogue, les stocks, l'historique client.

Ces deux briques ne partagent ni le même serveur, ni le même hébergeur, ni le même niveau de criticité. Le site tourne sur un VPS OVHCloud. Le système de gestion tourne sur une machine à domicile, volontairement hors du cloud public.

Ce choix n'est pas un détail technique. C'est une décision de gouvernance : ne pas faire dépendre la survie du métier d'un seul prestataire, d'une seule infrastructure, d'un seul point de défaillance.

L'objection qu'on me pose systématiquement

À ce stade, l'objection arrive presque toujours dans les mêmes termes : pourquoi ne pas tout héberger dans le cloud, avec des sauvegardes automatiques gérées par le prestataire ? Ce serait plus simple, moins cher à mettre en place, moins de responsabilité opérationnelle à porter.

L'argument se défend. Il est même juste, pour beaucoup d'organisations dont l'activité ne dépend pas directement de la donnée qu'elles produisent.

Mais pour une librairie dont le catalogue, les stocks et la relation fournisseur constituent l'intégralité de l'actif métier, cet argument inverse le problème. Confier la seule copie de cet actif à un tiers, c'est transformer un risque opérationnel en dépendance stratégique. Le jour où l'accès est coupé, suspendu, ou simplement modifié dans ses conditions, ce n'est plus une panne technique. C'est une rupture de continuité. Même sans Internet, son réseau interne fonctionne, elle peut continuer de travailler.

La question n'est donc pas cloud contre local. Elle est : qui porte le risque, et cette répartition a-t-elle été choisie consciemment, ou subie par défaut ?

Ce que la règle du 3-2-1 signifie réellement

La règle du 3/2/1, c'est trois copies, deux supports différents, une copie hors site, est souvent citée comme une bonne pratique technique. Elle est en réalité un principe d'audit : elle force à documenter où vit chaque copie de la donnée, sous quelle responsabilité, et avec quel délai de restauration.

Dans ce cas précis, chaque environnement génère ses propres sauvegardes quotidiennes, avec une conservation différentielle des documents sur trente jours et une purge maîtrisée des suppressions. Chaque environnement copie ensuite sa sauvegarde vers l'autre serveur, de sorte qu'aucun des deux ne dépend uniquement de lui-même. L'hébergeur ajoute enfin son propre snapshot quotidien, comme garantie externe.

Trois copies, deux environnements physiquement distincts, une copie hors site. La règle est respectée, mais elle a été pensée à partir du risque métier réel, pas plaquée après coup pour cocher une case.

La vraie question n'est pas technique

Dans la plupart des organisations, la sauvegarde est perçue comme un sujet qui appartient à l'IT, voire à un prestataire externe. C'est une erreur de périmètre.

Le dirigeant porte le risque métier si la donnée disparaît. L'architecte porte la stratégie de continuité, c'est-à-dire la répartition consciente de ce risque. L'exploitant porte l'exécution quotidienne. Si l'un de ces rôles est absent, ou s'il n'y a personne pour les relier entre eux, la chaîne casse au moment où on en a le plus besoin.

C'est précisément le rôle d'un audit de continuité : ne pas se demander si la sauvegarde existe, mais si sa conception correspond à la réalité du risque qu'elle est censée couvrir.

Une infrastructure moderne, des API propres, des conteneurs bien orchestrés, tout cela ne vaut rien si la stratégie de sauvegarde n'a pas été pensée comme un composant d'architecture à part entière. Et cette conception-là n'est pas un sujet technique, c'est un sujet de gouvernance.

Je suis Rémi Verschuur et j'accompagne les entreprises pour une performance durable et continue.