On associe souvent le PRA SaaS aux grandes entreprises et aux DSI avec des équipes infra dédiées. C'est une erreur. Un Plan de Reprise d'Activité est aussi pertinent pour une TPE éditrice de SaaS B2B que pour un groupe coté : la dépendance opérationnelle de vos clients à votre plateforme est la même, et leurs exigences contractuelles aussi. D'expérience, sur les SaaS que je maintiens, la question du PRA arrive systématiquement dès qu'un prospect grand compte démarre la phase de due diligence sécurité. Voici comment construire un PRA proportionné à une TPE ou un éditeur indépendant, sans tomber dans la sur-ingénierie.
Pourquoi le PRA SaaS n'est plus optionnel
Trois forces rendent le PRA incontournable, même à petite échelle. D'abord, le RGPD article 32 impose explicitement « la capacité à rétablir la disponibilité des données à caractère personnel et l'accès à celles-ci dans des délais appropriés en cas d'incident physique ou technique ». Sans procédure documentée et testée, vous n'êtes pas conforme.
Ensuite, vos clients B2B exigent désormais un PRA dans leurs questionnaires fournisseurs. Un cabinet de relecture pharma, un éditeur de facturation télécom, une clinique : tous ces interlocuteurs vous demanderont les RTO et RPO contractuels avant de signer. Pas de PRA, pas de signature.
Enfin, l'ENISA Threat Landscape documente une hausse continue des incidents de disponibilité : rançongiciels, attaques DDoS, pannes de fournisseurs cloud. La résilience n'est plus une option pour les éditeurs SaaS européens.
RTO et RPO expliqués simplement
Le RTO et le RPO sont les deux indicateurs qui structurent tout PRA. Ils répondent à deux questions distinctes mais complémentaires.
- RTO (Recovery Time Objective) : le temps maximum acceptable entre un incident et le retour en service. Si votre RTO contractuel est de 4 heures, vous devez restaurer en moins de 4 heures, sauvegardes incluses.
- RPO (Recovery Point Objective) : la perte de données maximum acceptable. Un RPO de 1 heure signifie qu'au pire, 1 heure de données est perdue lors d'un incident - donc une fréquence de sauvegarde au moins horaire.
Ces deux cibles dictent l'architecture, le budget et le niveau de complexité du PRA. Voici les fourchettes que je rencontre le plus souvent sur les SaaS B2B que j'accompagne.
| Criticité du SaaS | RTO cible | RPO cible | Architecture associée |
|---|---|---|---|
| SaaS B2B standard (productivité, CRM léger) | 24 h | 24 h | Sauvegarde quotidienne, restauration manuelle |
| SaaS B2B sensible (facturation, RDV) | 4-8 h | 1-4 h | Sauvegarde horaire + snapshots BDD, runbook documenté |
| SaaS B2B critique (santé, finance) | 1-2 h | 15 min | Réplication active-passive multi-site, bascule semi-automatique |
| SaaS critique temps réel | < 30 min | < 5 min | Cluster actif-actif, bascule automatique, équipe d'astreinte |
La majorité des éditeurs SaaS B2B que je maintiens sont sur la deuxième ligne : RTO 4 à 8 heures, RPO 1 à 4 heures. Au-delà, le coût explose et la complexité devient difficile à gérer en solo ou en petite équipe.
Les quatre scénarios qu'un PRA doit couvrir
Un PRA crédible ne se limite pas à « si le serveur tombe, on restaure la sauvegarde ». Il couvre quatre familles de scénarios, qui demandent des réponses différentes.
- Panne hardware : disque SSD qui lâche, alimentation HS, panne réseau de l'hébergeur. Réponse : redondance disque RAID, basculement vers une seconde machine ou un second hébergeur, restauration depuis sauvegarde distante.
- Corruption logicielle : déploiement raté, migration Doctrine cassée, suppression accidentelle de données par un script administrateur. Réponse : snapshots BDD horaires permettant de remonter à l'état pré-incident sans toucher aux sauvegardes.
- Attaque rançongiciel : chiffrement des données et des sauvegardes accessibles. Réponse : sauvegardes immutables ou hors ligne, isolées du système principal - sinon le rançongiciel les chiffre aussi.
- Indisponibilité du fournisseur cloud : panne majeure de l'hébergeur, blocage juridique (Cloud Act), rachat hostile, faillite. Réponse : multi-hébergeur, infrastructure documentée comme code, capacité à reconstruire ailleurs en quelques heures.
Le piège classique : ne couvrir que le premier scénario, en oubliant qu'un rançongiciel chiffre aussi le NAS de sauvegarde s'il est monté en SMB sur le serveur principal. C'est exactement ce qu'a vécu un éditeur SaaS de facturation télécom dont j'ai repris le périmètre maintenance en 2024 : sauvegardes correctes sur le papier, mais toutes accessibles depuis le serveur infecté.
L'architecture qui tient en cas de coup dur
Quatre briques constituent le socle technique d'un PRA SaaS solide.
- Sauvegardes Proxmox Backup Server distantes : chiffrées, déduplication intégrée, hébergées chez un fournisseur différent du fournisseur principal. Rétention typique : journalière sur 15 jours, hebdomadaire sur 4 à 8 semaines, mensuelle sur 6 à 12 mois.
- Snapshots BDD horaires : pour MariaDB, j'utilise mariabackup avec rétention 24-72 h. Permet de restaurer l'état d'il y a 1 h, 3 h ou 12 h sans rejouer les binaires logs depuis la dernière sauvegarde quotidienne.
- Infrastructure documentée comme code : Terraform pour le provisionning des VMs, Ansible pour la configuration, scripts de déploiement versionnés. Reconstruire la totalité de l'infrastructure ailleurs ne demande pas de mémoire institutionnelle, juste un dépôt Git à jour.
- Runbook à jour : un document Markdown versionné qui décrit, étape par étape, la procédure de bascule. Il est testé, daté, et accessible hors ligne (PDF imprimé ou copie sur clé USB chiffrée).
Sur les SaaS Symfony en version LTS que je maintiens, MariaDB par défaut, ce socle se déploie en quelques jours. La vraie complexité, c'est la documentation et les tests, pas la mise en place initiale.
La procédure de bascule : exemple 4 heures
Un runbook crédible répond à trois questions : qui appelle qui, dans quel ordre, et en combien de temps. Voici une procédure type que je documente pour un SaaS B2B avec RTO 4 h, sur un setup Proxmox + sauvegardes Proxmox Backup Server distantes.
| Étape | Durée cible | Acteur | Action |
|---|---|---|---|
| 1. Détection | 0-15 min | Monitoring + astreinte | Alerte Grafana / appel client / supervision externe |
| 2. Confirmation | 15-30 min | Astreinte technique | Vérifier que l'incident n'est pas un faux positif, qualifier le scénario |
| 3. Communication initiale | 30-45 min | Astreinte + référent client | Page de statut mise à jour, mail aux clients critiques |
| 4. Provisionning secours | 45 min - 2 h | Astreinte technique | Terraform apply sur le second hébergeur, montée des VMs vides |
| 5. Restauration données | 2 h - 3 h 30 | Astreinte technique | Restaurer la dernière sauvegarde valide depuis Proxmox Backup Server |
| 6. Bascule DNS | 3 h 30 - 3 h 45 | Astreinte technique | Mettre à jour les enregistrements A/AAAA, TTL court préparé en amont |
| 7. Validation et communication | 3 h 45 - 4 h | Astreinte + référent client | Tests fonctionnels, page de statut résolue, mail de clôture |
Cette procédure n'est crédible que si elle est testée. Un runbook jamais exécuté, c'est comme une mauvaise documentation Wikipedia : juste assez détaillé pour rassurer, pas assez pour fonctionner.
Les tests trimestriels : pourquoi tester sa restauration
Une sauvegarde non testée n'est pas une sauvegarde, c'est un espoir. La règle « 3-2-1 » classique (3 copies, 2 supports, 1 hors site) est nécessaire mais pas suffisante. Il faut y ajouter le « 0 » de la version moderne : zéro erreur lors de la restauration.
Sur les SaaS que je maintiens, je programme un test de restauration chaque trimestre, en environnement isolé, avec validation fonctionnelle complète : démarrage de la base, login utilisateur, génération d'un export, vérification de l'intégrité des données récentes. Le test prend une demi-journée et lève régulièrement des défauts qu'aucun monitoring ne signale : sauvegarde tronquée, dépendance manquante dans le runbook, version de MariaDB incompatible avec le dump. Sans ce test, le PRA reste de la fiction.
La fiche ANSSI sur les sauvegardes formalise cette exigence : « Tester régulièrement la restauration des données », et insiste sur la traçabilité des tests dans un registre. Pour un SaaS qui vise des certifications comme ISO 27001 ou HDS, cette traçabilité est obligatoire.
Mettre en place un PRA SaaS sur votre périmètre
Construire un PRA n'est pas un projet à six mois. Sur un SaaS B2B Symfony de taille moyenne hébergé chez un fournisseur souverain (Scaleway, OVH, Infomaniak ou auto-hébergement Proxmox), l'architecture, le runbook initial et le premier test de restauration tiennent en quelques jours d'accompagnement. Le retour sur investissement est immédiat dès la première due diligence client réussie.
Pour aller plus loin, mon article sur Proxmox pour TPE détaille l'infrastructure cible que j'utilise pour la majorité de mes clients, et ma checklist RGPD SaaS 2026 situe le PRA dans le cadre plus large de la conformité européenne. Comme tous mes accompagnements, le périmètre et le tarif sont définis sur devis personnalisé après un échange initial gratuit de 30 minutes. Mon guide du développement SaaS sur-mesure détaille le cycle complet d'un projet de la conception à la maintenance. Le formulaire de contact permet de prendre date.
