Plan de reprise d’activité SaaS : quel niveau choisir ?

Un plan de reprise d’activité SaaS doit partir de deux décisions métier : combien de temps l’application peut rester indisponible et quelle quantité de données l’entreprise accepte de perdre. Pour une petite équipe, mieux vaut une restauration simple, documentée et testée qu’une infrastructure de secours sophistiquée que personne ne sait exploiter.

La difficulté consiste à choisir le bon niveau de protection : sauvegardes isolées, environnement à reconstruire, secours déjà opérationnel ou architecture répartie. Voici comment arbitrer entre ces options, budgéter l’effort et vérifier que la promesse de reprise tient aussi lorsque le CTO n’est pas disponible.

Que doit couvrir un plan de reprise d’activité SaaS ?

Un plan de reprise d’activité, ou PRA, décrit comment rétablir un service arrêté : données, infrastructure, application, dépendances et responsabilités. Une sauvegarde constitue une ressource du PRA, pas le plan lui-même.

La CNIL distingue la continuité d’activité de la reprise : la première organise la poursuite du travail, éventuellement en mode dégradé ; la seconde rassemble les actions nécessaires au redémarrage. Elle recommande de formaliser ces dispositifs, même sommairement, et de les tester.

Pour un produit SaaS B2B, le périmètre doit inclure les parcours qui permettent réellement aux clients de travailler. Une page de connexion accessible ne signifie pas que les commandes, les documents ou les traitements différés fonctionnent.

Commencez par distinguer les scénarios à couvrir :

• Panne d’un composant : base indisponible, serveur défaillant, stockage inaccessible.
• Perte d’un environnement : région d’hébergement indisponible ou compte cloud devenu inaccessible.
• Erreur logique : suppression accidentelle, import incorrect ou migration ayant altéré les données.
• Compromission : accès administrateur détourné, données chiffrées ou sauvegardes menacées.

Notre recommandation : attribuez une procédure et un objectif à chaque scénario. Une bascule adaptée à une panne matérielle ne doit pas devenir le réflexe automatique face à des données corrompues.

Comment fixer le RPO et le RTO sans surdimensionner ?

Le RTO correspond au délai maximal acceptable pour rétablir le service après son interruption. Le RPO exprime la perte de données acceptable en durée, par exemple les opérations des dernières minutes ou des dernières heures. Ces objectifs doivent être validés avec les responsables métier, puis confrontés aux capacités techniques.

Le cadre AWS Well-Architected sur les objectifs de reprise recommande cette démarche par charge de travail et par impact métier. Il met notamment en garde contre des objectifs arbitraires, irréalistes ou incompatibles avec ceux des dépendances.

Raisonner par parcours, pas seulement par application

Un logiciel peut contenir des fonctions dont les besoins diffèrent fortement. Le tableau suivant propose des hypothèses de cadrage fictives, pas des standards ni des engagements à reprendre dans un contrat.

Pour chaque ligne, demandez qui reconstituerait les données perdues et à partir de quelles preuves. Perdre une heure de brouillons n’a pas le même impact que perdre une heure de validations impossibles à reproduire.

Définir précisément le début et la fin du chronomètre

Pour vos exercices, mesurez le délai depuis l’interruption simulée jusqu’à la validation du parcours métier. Incluez la détection, l’escalade, la décision, la restauration et les contrôles. Mesurer uniquement le redémarrage de la base donne une vision trop étroite de la reprise.

Documentez aussi le périmètre restauré : service complet, lecture seule ou fonctions prioritaires. « Disponible en une heure » reste ambigu si l’utilisateur peut consulter un dossier, mais pas enregistrer une intervention.

Sauvegardes, secours dormant ou actif : comparer les options

La documentation AWS sur les stratégies de reprise distingue quatre grandes approches, de la restauration des sauvegardes à plusieurs sites actifs. Le tableau en reprend le principe ; les indications de contexte constituent des recommandations de cadrage, pas des garanties de performance.

Pour une petite équipe, notre choix par défaut serait une restauration automatisée et éprouvée. Le passage au niveau supérieur doit répondre à un écart mesuré entre le délai obtenu et le délai acceptable, pas à une préférence architecturale.

Avant de financer un second environnement, faites restaurer le premier. Vous saurez si le temps part dans le transfert des données, la reconstruction de l’infrastructure, la récupération des accès ou les validations humaines. Chaque cause appelle un investissement différent.

La réplication ne remplace pas un historique récupérable

AWS précise que la réplication protège contre certains sinistres, mais ne suffit pas face à une corruption ou une destruction des données sans mécanisme permettant de revenir à un état antérieur. C’est pourquoi un environnement répliqué doit rester accompagné de sauvegardes et d’une stratégie de récupération historique.

Avec PostgreSQL, la restauration à un instant donné, ou PITR, repose sur une sauvegarde physique et une séquence continue de journaux de transactions archivés. Elle permet d’arrêter la récupération à un point choisi. Un export logique seul ne constitue pas cette chaîne de restauration.

La décision porte donc aussi sur la profondeur d’historique nécessaire. Posez deux questions : combien de temps une erreur peut-elle rester invisible et jusqu’où faut-il pouvoir remonter ? Une corruption découverte après la fin de la fenêtre de récupération impose une autre stratégie de réparation.

Pour protéger les copies, la CNIL recommande notamment une sauvegarde géographiquement distincte, une copie hors ligne et des tests réguliers de restauration. Elle souligne également le risque de conserver les sauvegardes sur les mêmes systèmes sans isolation.

Dans votre architecture cloud, examinez séparément l’isolation géographique, administrative et technique. Un autre dossier de stockage ne répond pas à toutes ces dimensions. Exigez une démonstration : quels identifiants peuvent supprimer la production, les copies et les clés nécessaires à leur lecture ?

Restaurer un service cohérent, pas uniquement une base

Pour concevoir un PRA exploitable, nous conseillons de classer les composants en trois catégories : les données faisant autorité, les éléments reconstructibles et les dépendances nécessaires au redémarrage.

• Données faisant autorité : transactions métier, documents originaux, validations et paramètres clients.
• Éléments reconstructibles : caches, index de recherche, miniatures et agrégats, à condition de disposer de leurs sources.
• Dépendances de reprise : identité, secrets, clés de chiffrement, images applicatives, configuration réseau et accès opérateurs.

Pour un logiciel métier sur mesure, faites valider ce classement par un référent opérationnel. Une pièce jointe oubliée peut rendre un dossier inutilisable alors que toutes les lignes de la base sont présentes.

Prévoir la réconciliation avec les systèmes externes

Considérez cet exemple fictif : un paiement est accepté par le prestataire, puis la base applicative est restaurée à un instant antérieur. Le paiement existe toujours à l’extérieur, mais son enregistrement local a disparu.

Le PRA doit prévoir la comparaison avec le système faisant autorité et la reconstruction des opérations manquantes. Avant de relancer les traitements, imposez un contrôle des effets déjà produits : paiements, emails, commandes fournisseurs ou écritures comptables. L’objectif est de reprendre sans reproduire aveuglément les actions.

Traiter la restauration d’un seul client comme un besoin distinct

Pour PostgreSQL, la récupération physique décrite dans la documentation concerne le cluster entier, pas un sous-ensemble de données. Si votre SaaS doit pouvoir récupérer un seul client après une erreur, prévoyez une procédure spécifique : restauration isolée, extraction contrôlée, vérification des dépendances et réintégration.

Ne promettez pas une restauration individuelle rapide avant d’avoir testé ce parcours. Son coût dépend notamment du modèle d’isolation des clients et des relations entre leurs données.

Combien budgéter pour un PRA SaaS ?

Le budget doit séparer l’étude initiale, la mise en place, les ressources permanentes et les exercices. Sans connaître le volume de données, l’automatisation existante et les objectifs de reprise, un montant global serait trompeur.

Pour préparer une consultation, vous pouvez utiliser les enveloppes de charge indicatives suivantes. Ce sont des hypothèses de planification proposées ici, pas des moyennes de marché. Les lignes ne s’additionnent pas automatiquement.

Multipliez la charge retenue par votre coût journalier réel, puis ajoutez stockage, transferts, calcul et services secondaires. Le nombre de dépendances, la volumétrie, les contraintes d’hébergement et l’état des déploiements font varier fortement l’enveloppe.

Pour comparer deux options, utilisez un horizon budgétaire commun, par exemple trois ans : mise en place, exploitation, exercices et maintenance. En face, estimez l’impact d’une interruption : marge réellement perdue, travail immobilisé, réconciliation et conséquences contractuelles. Évitez de compter automatiquement tout le chiffre d’affaires horaire comme une perte définitive.

Notre recommandation : financez d’abord la suppression des angles morts, puis la réduction du délai. Un secours plus rapide ne compense pas des documents absents ou des clés introuvables.

Qui décide de la bascule et qui valide la reprise ?

Attribuez les responsabilités avant l’incident. Pour une startup ou une PME, un document court avec des titulaires et des remplaçants est préférable à une procédure exhaustive sans responsable disponible.

• Responsable d’incident : qualifie la situation, décide des priorités et autorise la bascule.
• Opérateur de reprise : exécute la procédure et conserve la trace des actions.
• Référent métier : vérifie les parcours et la cohérence des opérations.
• Responsable communication : informe les clients et centralise les demandes.

Une personne peut cumuler plusieurs rôles, mais prévoyez une alternative à chaque accès critique. Testez notamment le cas où le fournisseur d’identité habituel est indisponible. Les moyens d’urgence doivent rester protégés et leur utilisation traçable.

Définissez aussi les conditions de retour au fonctionnement nominal : quel environnement fait autorité, comment transférer les nouvelles écritures et qui autorise la fermeture du secours ? La CNIL inclut explicitement ce retour à la normale dans les points à anticiper.

Un exercice de reprise doit produire des preuves

Nous recommandons de commencer par une restauration dans un environnement isolé, puis d’élargir les exercices aux scénarios prioritaires. La fréquence doit suivre la criticité et les changements importants de l’application ; elle ne doit pas être choisie uniquement pour remplir un calendrier.

1. Choisir un scénario précis : perte de base, région indisponible ou suppression découverte tardivement.
2. Restaurer sans improviser : faire suivre la procédure par une personne autre que son auteur.
3. Mesurer le parcours complet : accès, reconstruction, récupération et validation métier.
4. Vérifier les effets externes : traitements suspendus, doublons évités et opérations à réconcilier.
5. Corriger puis rejouer : confirmer que les anomalies bloquantes ont réellement disparu.

Conservez une fiche de résultat : version applicative, volume restauré, point de récupération atteint, durée observée et fonctions validées. Ne présentez pas un test sur une petite copie ancienne comme la preuve d’une reprise à la volumétrie actuelle.

Questions fréquentes

Faut-il choisir un autre fournisseur pour le secours ?

Pas systématiquement. Dans votre arbitrage, comparez le risque que vous voulez couvrir avec le coût d’une seconde plateforme : compétences, services équivalents, déploiements et exercices. Retenez un autre fournisseur si cette indépendance répond à un scénario explicite et si l’équipe peut réellement exploiter les deux environnements.

Peut-on vendre plusieurs niveaux de reprise selon les clients ?

Oui, mais vérifiez que l’architecture permet de tenir ces engagements séparément. Si tous les clients dépendent de la même restauration globale, une option commerciale plus protectrice nécessite peut-être une isolation technique supplémentaire. Faites chiffrer cette différence avant de la vendre.

Que demander à un prestataire qui annonce un PRA inclus ?

Demandez les scénarios couverts, les exclusions, les délais d’intervention, les objectifs de récupération et le compte rendu du dernier exercice pertinent. Faites préciser qui prend la décision de bascule et qui réalise la validation métier. Le mot « inclus » ne décrit pas à lui seul le service rendu.

Choisir le niveau que votre équipe peut démontrer

Pour une petite équipe acceptant plusieurs heures d’arrêt, privilégiez un plan de reprise d’activité SaaS simple : copies isolées, restauration automatisée et exercice complet. Si ce dispositif échoue à respecter un objectif métier justifié, investissez dans un secours préprovisionné. Réservez plusieurs sites actifs aux contraintes qui en justifient aussi l’effort d’exploitation.

Vous devez arbitrer entre ces niveaux ? La séance de consulting IT offerte de Novane peut servir à confronter votre architecture, vos objectifs de reprise et vos moyens. Préparez un schéma des dépendances, le volume des données et, si vous en disposez, le résultat de votre dernière restauration.