Sauvegarde et reprise après sinistre : le risque existentiel que votre startup ne teste jamais

Un matin, un ingénieur lance une commande de nettoyage sur ce qu’il croit être la base de staging. C’était la production. Trois ans de données clients, effacés en deux secondes. La question qui suit n’est pas « avez-vous des sauvegardes ? » — presque tout le monde en a. La vraie question, celle qui fait blanchir un fondateur, c’est : « quelqu’un a-t-il déjà restauré à partir de ces sauvegardes ? »

Dans l’immense majorité des startups, la réponse est non. Et un backup qu’on n’a jamais restauré n’est pas une sauvegarde : c’est une hypothèse.

Le problème : « avoir des backups » et « pouvoir se remettre d’un sinistre » sont deux choses différentes

Quand vous ouvrez la console de votre hébergeur managé — Supabase, RDS, Scaleway, un Postgres géré chez OVH — vous voyez une case « sauvegardes automatiques activées ». Un point vert. Vous cochez mentalement la ligne et passez à autre chose. C’est exactement là que se niche le piège.

Ce point vert vous dit qu’une copie existe quelque part. Il ne vous dit rien de trois choses qui décident réellement de votre survie le jour du sinistre :

Combien de données vous perdez. C’est le RPO (Recovery Point Objective). Si votre dernier snapshot date de 24 heures, un incident aujourd’hui à 18h vous fait perdre tout ce qui s’est passé depuis minuit. Pour une startup B2B avec 40 clients qui ont saisi des données toute la journée, c’est une journée de travail de vos clients partie en fumée — et un email de honte à écrire à chacun d’eux.

Combien de temps vous êtes à l’arrêt. C’est le RTO (Recovery Time Objective). Restaurer une base de 200 Go depuis un snapshot froid, reconfigurer les connexions, revalider l’intégrité, remonter le service : ça peut prendre 20 minutes ou 8 heures selon comment c’est câblé. Pendant ce temps, votre produit est down, votre support explose, et si vous avez signé un SLA, le compteur de pénalités tourne.

Si la restauration fonctionne vraiment. Un snapshot corrompu, une sauvegarde qui excluait silencieusement une table depuis six mois, un fichier de dump chiffré dont personne ne retrouve la clé : ces scénarios sont banals. Ils ne se révèlent que le jour où vous essayez de restaurer — c’est-à-dire le pire jour possible pour les découvrir.

La plupart des startups optimisent la première case (le point vert) et ignorent les trois suivantes. Résultat : elles paient pour une assurance dont elles n’ont jamais lu les clauses.

Pourquoi ce n’est pas qu’une question technique

On classe le backup dans la catégorie « hygiène ops » — une corvée d’ingénieur, invisible, sans valeur perçue. C’est une erreur de lecture. La perte de données est l’un des rares incidents techniques qui peut littéralement tuer une entreprise, pas juste dégrader son expérience.

Pensez à ce que vos données sont pour votre business. Dans un SaaS, elles ne sont pas un sous-produit du service : elles sont le service. Le client vous confie ses factures, son pipeline commercial, ses dossiers RH, son historique. Le jour où vous les perdez, vous ne perdez pas une fonctionnalité — vous perdez la confiance, qui est le seul actif qui vous permettait de vendre à des entreprises plus grosses et plus prudentes que vous.

Il y a aussi une dimension réglementaire souvent oubliée. Le RGPD impose une obligation de disponibilité et de résilience des traitements (article 32). Une perte de données par absence de sauvegarde fiable n’est pas seulement un incident commercial : c’est un manquement documentable. Et sur un marché B2B français, dès que vous adressez des clients grands comptes, leur questionnaire sécurité demande votre politique de sauvegarde, votre RPO/RTO, et parfois la preuve du dernier test de restauration. Répondre « on a les backups automatiques du cloud » ferme des deals.

Enfin, il y a le signal de due diligence. Lors d’une levée en série A, l’audit technique regarde comment vous traitez les scénarios catastrophe. Une équipe qui a un RPO documenté, un runbook de restauration et une trace du dernier test réussi envoie un message clair : ces gens pensent en termes de risque, pas seulement de features. Une équipe qui hausse les épaules envoie l’inverse.

L’erreur symétrique : sur-ingénierie de la résilience

Le réflexe inverse est tout aussi coûteux. Un fondateur technique lit un article sur l’architecture de Netflix, découvre le multi-région, le failover automatique, le chaos engineering, et décide de bâtir une infrastructure capable de survivre à la disparition d’un datacenter entier. Pour une startup avec 30 clients et 14 mois de runway.

C’est le même anti-pattern que monter du Kubernetes avant d’avoir un produit : on résout un problème qu’on n’a pas encore, avec des ressources qu’on n’a pas. Le multi-région double vos coûts d’infrastructure, complexifie chaque déploiement, et introduit des bugs de cohérence de données bien plus probables que le sinistre qu’il prétend prévenir.

La bonne résilience n’est pas la résilience maximale. C’est la résilience proportionnée à ce que le business peut tolérer de perdre. Et cette tolérance, ce n’est pas l’ingénieur qui la fixe seul dans son coin — c’est une décision de fondateur. Combien d’heures de données pouvez-vous perdre sans casser la confiance de vos clients ? Combien de temps pouvez-vous être down avant que ça devienne un problème commercial et non technique ? Ces deux nombres définissent votre RPO et votre RTO cibles, et donc combien vous devez investir. Pas l’inverse.

Ce qu’il faut vraiment faire

Commencez par le test, pas par l’outil. Bloquez deux heures cette semaine et restaurez une de vos sauvegardes dans un environnement séparé. Pas en théorie — vraiment. Vous apprendrez plus en une tentative de restauration qu’en dix articles. Vous découvrirez peut-être que le dump exclut une table, que personne ne sait où sont les clés de chiffrement, ou que ça prend six heures. Mieux vaut le savoir un mardi tranquille qu’un dimanche de crise.

Ensuite, écrivez deux nombres et un document. Le RPO acceptable (combien de temps de données vous acceptez de perdre) et le RTO acceptable (combien de temps d’indisponibilité). Puis un runbook : les étapes précises pour restaurer, écrites pour que quelqu’un qui n’est pas l’auteur du système puisse les suivre à 3h du matin. Ce runbook attaque au passage votre bus factor — l’autre risque humain que personne ne mesure.

Appliquez la règle 3-2-1, version startup pragmatique : au moins deux copies, sur deux supports/comptes différents, dont une hors de votre fournisseur principal. Si tout votre univers vit dans un seul compte cloud, un ransomware, une erreur de facturation qui suspend le compte, ou un accès compromis peut tout emporter d’un coup — sauvegardes incluses. Une copie exportée régulièrement vers un stockage objet séparé (idéalement en écriture seule / immuable) coûte quelques euros par mois et change tout.

Automatisez la vérification, pas seulement la sauvegarde. Une sauvegarde qui échoue silencieusement est pire que pas de sauvegarde, parce qu’elle vous endort. Un simple test de restauration mensuel, même partiel, même automatisé sur un échantillon, avec une alerte s’il échoue, transforme votre hypothèse en garantie.

Et faites attention à ce que « données » ne veut pas dire seulement « base de production ». Vos fichiers uploadés par les clients, vos secrets, votre configuration d’infrastructure (idéalement en Infrastructure as Code, donc versionnée dans git), les données de vos outils SaaS critiques : tout ça fait partie de votre surface de perte.

Selon votre stade

Pre-seed. N’inventez rien. Activez les sauvegardes managées de votre hébergeur, vérifiez leur fréquence, et faites une restauration de test pour confirmer que ça marche. Exportez une copie hebdomadaire hors de votre compte principal. C’est suffisant, et c’est déjà mieux que 80 % de vos pairs.

Seed. Formalisez. Un RPO/RTO écrits, un runbook de restauration testé au moins une fois par trimestre, la règle 3-2-1 appliquée avec une copie immuable hors fournisseur, et une alerte sur les échecs de sauvegarde. C’est aussi le moment où vos premiers clients grands comptes vont vous poser la question dans leur questionnaire sécurité — vous devez pouvoir répondre par écrit.

Série A. Industrialisez ce qui a été validé. Tests de restauration automatisés et réguliers, RPO/RTO différenciés selon la criticité des données, éventuellement un failover sur une seconde région si et seulement si vos SLA le justifient. À ce stade, votre discipline de sauvegarde devient un actif dans l’audit technique de la levée, pas une case à cocher.

Une dernière question

La sauvegarde est l’exemple parfait d’un risque à la fois catastrophique et facile à ignorer, parce qu’il ne se manifeste jamais — jusqu’au jour où il se manifeste une seule fois, et où ce jour suffit. Le point vert dans votre console vous rassure précisément parce qu’il vous dispense de poser la seule question qui compte.

Alors posez-la maintenant, tant que c’est un exercice et pas une crise : si votre base de production disparaissait cet après-midi, combien de temps et combien de données vous coûterait le retour à la normale — et qui, dans votre équipe, saurait faire les gestes ? Si vous ne pouvez pas répondre avec précision, vous ne connaissez pas encore votre exposition. Vous l’espérez seulement.