PCA et PRA d’un SaaS : préparer des tests utiles aux audits

Publié et mis à jour le 1 octobre 2026 · Rédaction : Scope & Evidence

Un plan de continuité ou de reprise utile décrit comment votre SaaS maintient ou rétablit les activités importantes dans un scénario défini. L’existence de sauvegardes ne prouve pas que la restauration fonctionne. Le CTO doit relier les objectifs aux dépendances, aux personnes et aux tests. La direction valide les besoins et les arbitrages. Aucun RTO ou RPO standard n’est proposé ici : les objectifs viennent de votre activité et des engagements réellement pris envers les clients.

Cadre de référence : source primaire du sujet. Les recommandations opérationnelles ci-dessous sont à adapter à votre organisation.

Distinguer les besoins des capacités

Identifiez ce que les clients doivent pouvoir continuer à faire et les conséquences d’une interruption. Examinez les engagements contractuels, puis comparez-les aux capacités techniques. Le RTO représente un objectif de délai de reprise ; le RPO concerne la perte de données admissible selon l’objectif retenu. Ces notions doivent être comprises par les décideurs. Une capacité annoncée par le cloud ne prouve pas que l’ensemble de votre SaaS peut respecter les mêmes valeurs, avec ses applications et interfaces.

Cartographier les dépendances de reprise

Une restauration peut nécessiter l’annuaire, des clés, une résolution DNS et des intervenants autorisés. Décrivez les dépendances qui pourraient elles-mêmes être indisponibles. Vérifiez les accès de secours et leurs protections avant l’exercice, sans copier les secrets dans le plan. Identifiez les personnes capables de prendre les décisions et celles qui exécutent les opérations. Si un prestataire intervient, précisez les contacts et les obligations convenues plutôt que de supposer une disponibilité permanente.

Choisir un scénario de test

Définissez ce que l’exercice examine : perte d’une base, indisponibilité d’une région ou erreur de déploiement, par exemple. Le scénario doit avoir une portée, des critères de réussite et des règles de sécurité. Un test sur un environnement isolé peut être utile, mais ses limites doivent être décrites. Ne concluez pas à une reprise complète de production si seule une base de test a été restaurée. Préparez les conditions d’arrêt lorsque l’exercice pourrait affecter le service.

Conserver le déroulement et les résultats

Gardez les heures observées, les opérations réalisées et les écarts rencontrés. Les mesures réelles doivent être distinguées des objectifs. Un compte rendu utile explique ce qui a été restauré, comment l’intégrité a été vérifiée et quels éléments restent hors test. Conservez les actions de correction avec leurs responsables. Le résultat d’un exercice peut conduire à revoir les objectifs ou l’architecture ; il ne doit pas être réécrit pour correspondre aux engagements annoncés.

Préparer la communication de crise

Définissez qui informe les clients, sur quels canaux et avec quelles validations. Les obligations de notification dépendent du contrat et du droit applicable ; elles nécessitent un examen propre au contexte. Un modèle de message ne remplace pas cette analyse. Testez aussi la capacité à joindre les décideurs et à travailler si les outils habituels sont indisponibles. Après l’exercice, faites examiner les enseignements par les responsables concernés et vérifiez les corrections lors d’un contrôle ultérieur.

Vérifier la cohérence des engagements

Comparez les objectifs du plan aux documents commerciaux et au contrat client. Une équipe peut avoir testé une capacité différente de celle annoncée. Si une contradiction apparaît, faites arbitrer le sujet par la direction et les responsables compétents. La correction peut porter sur l’architecture, le test ou la formulation de l’engagement. Gardez la raison et les éléments examinés. Ne modifiez pas le résultat du test pour rendre artificiellement cohérents les documents.

Exemple de travail, fictif

Exemple fictif : un test restaure la base du SaaS dans un environnement isolé, mais l’équipe ne peut pas ouvrir l’application parce que le fournisseur d’identité utilisé pendant l’exercice est indisponible. Le compte rendu ne marque pas la reprise comme réussie. Il décrit la dépendance et les corrections proposées. La direction examine ensuite les objectifs avec le CTO. Le test apporte une information utile sans créer une garantie de reprise pour tous les scénarios.

Ce que votre dossier doit permettre de vérifier

Des activités importantes et impacts d’interruption identifiés.
Des objectifs validés et distingués des capacités observées.
Les dépendances techniques et humaines de reprise.
Un scénario de test avec critères et limites.
Un compte rendu réel, des écarts et un contrôle des corrections.

Questions avant de décider

Une sauvegarde réussie suffit-elle ?

Non. La possibilité de restaurer et d’utiliser les données doit être examinée dans un scénario pertinent. Précisez les limites du test et les dépendances du service.

Existe-t-il un RTO imposé à tous les SaaS ?

Ce guide ne présente aucune valeur universelle. Les besoins, contrats et règles applicables doivent être examinés pour fixer et valider les objectifs de votre service.

Peut-on partager le plan complet au client ?

Évaluez le besoin et la confidentialité. Une synthèse des objectifs et des tests peut être appropriée ; les secrets et détails sensibles de reprise doivent rester protégés.

Préparer la suite du travail

Sources et portée de lecture

Les sources ci-dessous documentent le cadre ou le fait cité. Les propositions d’organisation sont des conseils de préparation à adapter à votre situation. Elles ne reproduisent pas le texte des normes et ne constituent pas une décision d’audit ni un avis juridique.