Votre SaaS peut-il perdre vos données ?

Votre équipe déploie une migration à 9 h 12. Elle se termine sans erreur, mais une table de liaison a été vidée. Les comptes existent encore. Les factures aussi. Seulement, plus rien ne les relie. À 9 h 20, les premiers clients ouvrent le support. Votre développeur répond que la base est répliquée et sauvegardée. La question n'est pourtant pas de savoir si une sauvegarde existe. La question est : que peut-on restaurer, à quelle heure, et en combien de temps ?

J'ai vécu une situation très proche dans une startup. Un intervenant externe pensait travailler sur la base de staging lorsqu'il a lancé une manipulation destructive sur la production. Nous avons passé plusieurs semaines à tenter de reconstruire les données à partir des logs. Nous avons finalement dû abandonner : une partie des données était définitivement perdue.

Le cloud réduit le risque matériel. Il ne décide pas quelles données votre entreprise peut perdre.

Une sauvegarde ne protège votre SaaS que si vous avez déjà prouvé que vous pouvez la restaurer. Avant ce test, vous avez une promesse dans une console d'administration, pas un plan de reprise.

Quand j'audite ce risque, je ne m'arrête pas à « les backups sont activés ». Je demande quand la dernière restauration a été testée et combien de temps elle a pris. Sans réponse précise, la case verte du fournisseur ne prouve pas grand-chose.

Comprendre comment les données disparaissent

Quand on parle de perte de données, on imagine souvent un serveur qui brûle. C'est spectaculaire, donc facile à anticiper. Les incidents ordinaires sont moins visibles.

Un administrateur peut lancer une commande sur la mauvaise base. Une migration peut appliquer une règle erronée. Un bug peut écraser un champ à chaque sauvegarde. Dans tous ces cas, l'infrastructure fonctionne. Elle exécute fidèlement une mauvaise opération.

La réplication peut justement donner un faux sentiment de sécurité. Elle maintient plusieurs copies disponibles, mais elle propage aussi les changements. Une suppression valide peut atteindre les réplicas aussi proprement qu'une nouvelle commande client. Designing Data-Intensive Applications revient longuement sur ce compromis entre disponibilité et propagation des écritures. C'est le sujet de son chapitre sur la réplication.

La réplication protège surtout contre la panne d'une machine. Elle ne remonte pas le temps après une erreur métier.

Sauvegarder répond à un autre besoin. Une sauvegarde conserve un état antérieur. Si elle s'exécute chaque nuit sans autre mécanisme, un incident juste avant la sauvegarde suivante peut exposer presque une journée de nouvelles données.

La restauration remet cette copie en service. Il faut récupérer les données, redémarrer la base, vérifier son intégrité et reconnecter l'application. C'est à ce moment qu'apparaissent les archives corrompues, les identifiants manquants ou la procédure devenue obsolète.

Les transactions ajoutent une autre protection : elles empêchent qu'une opération complexe reste à moitié exécutée. Elles évitent par exemple de créer une facture sans enregistrer le paiement associé. Mais une transaction ne sait pas que vous avez supprimé la mauvaise ligne. Elle peut valider une erreur humaine de façon parfaitement cohérente.

Réplication, sauvegarde, restauration et transactions ne sont donc pas quatre noms pour la même sécurité. Chacune couvre un risque différent.

Mesurer ce que l'incident coûterait

Pour sortir du vague, il faut répondre à deux questions. Combien de données pouvons-nous perdre sans mettre l'entreprise en difficulté ? Combien de temps pouvons-nous rester sans service avant que la situation devienne critique ?

Le RPO, Recovery Point Objective, mesure la quantité de données que vous acceptez de perdre. Si votre RPO est d'une heure, votre dispositif doit permettre de revenir à un état vieux d'une heure au maximum.

Le RTO, Recovery Time Objective, mesure le délai acceptable avant le retour du service. Un RTO de quatre heures signifie que la reprise doit être terminée dans cette fenêtre.

Google Cloud résume ces métriques en langage business : combien de données pouvez-vous perdre, et combien de temps pouvez-vous attendre avant de reprendre l'activité. Sa documentation rappelle aussi qu'un RPO et un RTO plus courts coûtent généralement plus cher. C'est un choix économique autant que technique.

Prenons un SaaS qui reçoit cinquante commandes par heure. Un RPO de quatre heures n'est pas une ligne dans un document d'architecture. Ce sont potentiellement deux cents commandes à reconstituer, vérifier ou rembourser. Le bon objectif dépend de la valeur des données et des engagements pris envers les clients.

Le même raisonnement vaut pour l'indisponibilité. Quatre heures sans service n'ont pas le même impact sur un outil interne utilisé deux fois par semaine et sur une plateforme qui encaisse des paiements toute la journée. L'architecture vient après cette discussion, pas avant.

Construire une protection proportionnée

Une startup early-stage n'a pas besoin de copier toute son infrastructure dans trois régions. Ce serait cher et probablement inutile. Elle doit cependant savoir ce qu'elle ne peut pas recréer.

Le piège consiste à protéger tout de la même manière. Un avatar peut être renvoyé par son propriétaire. Une préférence d'interface peut être recalculée. Un paiement, un consentement ou un document contractuel demande une autre discipline.

Pour les données importantes, une simple sauvegarde nocturne peut laisser un trou trop large. La restauration à un instant précis permet de viser la minute qui précède l'erreur, au lieu de revenir à la veille. Ce mécanisme est souvent proposé par les bases managées sous le nom de point-in-time recovery ou PITR. Le détail d'implémentation importe peu au fondateur. Il doit connaître la fenêtre disponible et avoir vérifié que son équipe sait s'en servir.

Activer l'option reste le début du travail. Le seul test crédible consiste à restaurer.

Un exercice de restauration répond à des questions très concrètes :

• la sauvegarde est-elle lisible ?
• les bons accès sont-ils encore disponibles ?
• combien de temps prend la récupération avec le volume actuel ?
• l'application redémarre-t-elle sur les données restaurées ?
• les comptes, paiements et permissions sont-ils cohérents ?
• qui décide du moment exact auquel revenir ?

AWS recommande d'intégrer ces tests à la stratégie de continuité, notamment parce qu'une sauvegarde peut être corrompue et ne révéler le problème qu'au moment de la récupération. Le résultat doit respecter les objectifs RPO et RTO.

Le premier exercice sera rarement élégant. Tant mieux. Vous découvrirez la commande qui manque ou le secret stocké sur l'ordinateur d'un ancien développeur. Mieux vaut le voir un mardi matin que pendant un incident client.

Décider avant l'incident

Un fondateur n'a pas besoin de connaître le fonctionnement interne de sa base. Il doit obtenir des réponses précises à ces questions :

1. Quelles données sont sauvegardées, et lesquelles ne le sont pas ?
2. Où les copies sont-elles stockées ?
3. À quelle fréquence sont-elles créées ?
4. Combien de temps sont-elles conservées ?
5. Peut-on revenir juste avant une suppression accidentelle ?
6. Quand avons-nous effectué la dernière restauration complète ?
7. Combien de temps a-t-elle pris ?
8. Qui possède les accès si le responsable habituel est absent ?
9. Comment vérifions-nous les données après la reprise ?
10. Nos engagements clients sont-ils compatibles avec ce délai ?

Une réponse comme « c'est géré par notre hébergeur » mérite une question de plus. Quel service, avec quelle rétention, quel délai et quel test ? L'hébergeur fournit des mécanismes. Votre entreprise choisit la protection adaptée à son produit.

Tous les SaaS n'ont pas besoin d'un plan de reprise multi-région. Un produit en validation, sans client payant et avec peu de données, peut commencer avec des sauvegardes managées, une rétention correcte et un exercice manuel documenté.

Le niveau supérieur devient pertinent avec les premiers contrats B2B, les paiements ou des données impossibles à demander une seconde fois. À ce stade, le sujet doit apparaître dans la roadmap technique.

Je préfère un plan simple testé tous les trimestres à une architecture sophistiquée que personne n'ose restaurer. La fiabilité vient moins du nombre de copies que de la capacité de l'équipe à reprendre proprement le service.

Ce qu'il faut retenir

• La réplication améliore la disponibilité, mais peut propager une suppression ou une modification erronée.
• Une sauvegarde n'est utile que si l'équipe sait la restaurer dans un délai acceptable.
• Le RPO mesure la quantité de données acceptable à perdre. Le RTO mesure le temps acceptable avant la reprise.
• Les transactions évitent certaines incohérences. Elles n'annulent pas une opération erronée déjà validée.
• Une stratégie modeste et testée protège mieux qu'un dispositif ambitieux jamais exercé.

Questions fréquentes

Une base de données managée est-elle automatiquement sauvegardée ?

Beaucoup de services managés proposent des sauvegardes automatiques, mais leur fréquence, leur rétention et leurs options de restauration dépendent du service et de sa configuration. Vérifiez ces paramètres et réalisez une restauration de test avant de considérer le risque comme traité.

La réplication remplace-t-elle une sauvegarde ?

Non. La réplication conserve une autre copie disponible et reçoit les changements de la base principale. Si une suppression légitime mais accidentelle est propagée, le réplica peut la reproduire. Une sauvegarde historique ou un mécanisme PITR permet de revenir avant l'erreur.

À quelle fréquence faut-il tester une restauration ?

La fréquence dépend du rythme de changement et du risque métier. Pour un petit SaaS payant, je retiendrais un test trimestriel, puis un nouveau test après une migration majeure ou un changement d'infrastructure.

Conclusion

Revenons à la migration de 9 h 12. Une équipe préparée ne se contente pas d'annoncer qu'elle a des sauvegardes. Elle sait quelle minute viser, qui lance la reprise, combien de temps elle prendra et comment vérifier les comptes après restauration.

C'est moins rassurant qu'une case verte dans un dashboard. C'est aussi beaucoup plus utile.

Si vous ne savez pas combien de données votre SaaS peut perdre aujourd'hui, ce risque mérite une place dans votre prochain audit technique. Et si la base doit être sécurisée avant les prochains clients B2B, je peux vous aider à cadrer puis construire un SaaS fiable et reprenable.

Parlons-en sur un appel de 30 minutes.