L’adoption d’une plateforme SaaS simplifie l’infrastructure, les mises à jour et l’accès, mais elle peut créer une hypothèse dangereuse : si le service est dans le cloud, les données seraient automatiquement protégées. Pour la sauvegarde SaaS, disponibilité, redondance et sauvegarde sont liées, mais ne sont pas équivalentes.
Un fournisseur peut maintenir l’application disponible en cas de panne d’un composant sans pour autant offrir au client la restauration granulaire d’un document supprimé. De même, il peut répliquer les données entre plusieurs sites et propager rapidement une corruption ou une suppression. Il peut aussi conserver des copies techniques pour restaurer la plateforme entière, sans mettre à la disposition du client un point de restauration individuel.
C’est pourquoi la question « faites-vous des sauvegardes ? » est trop vague. Une réponse utile doit préciser ce qui est copié, quels incidents sont couverts, quelle perte est possible, en combien de temps on restaure, qui décide et quelle preuve existe.
Sauvegarde ne veut pas dire synchronisation, historique ou haute disponibilité
Sauvegarde : Copie distincte qui permet de restaurer des données à partir d’un point antérieur après une perte, une corruption ou un incident.
Synchronisation : Maintient des informations cohérentes entre sites ou systèmes ; elle peut propager une suppression ou une erreur.
Historique des versions : Permet de récupérer des versions antérieures dans l’application, selon ses propres règles et délais.
Réplication : Copie les modifications vers un autre environnement pour la disponibilité ; elle ne conserve pas toujours les états antérieurs.
Export : Remet les données au client dans un format défini ; il peut faciliter la portabilité, mais ne remplace pas la restauration opérationnelle.
Haute disponibilité : Réduit les interruptions de service en cas de panne ; elle ne résout pas forcément une perte logique de données.
Règle pratique : Si le mécanisme ne permet pas de revenir à un état antérieur, isolé de l’incident, et de restaurer des données exploitables, il ne doit pas être considéré comme une sauvegarde simplement parce qu’il existe plusieurs copies.
Avant les 12 questions : Transformez les réponses en engagements
Des réponses commerciales comme « sauvegarde quotidienne », « redondance géographique » ou « nous appliquons les meilleures pratiques » ne suffisent pas pour gérer le risque. Recherchez donc quatre qualités : un langage contractuel, des indicateurs mesurables, des responsabilités attribuées et des preuves vérifiables.
Contractuel : la réponse doit figurer dans le contrat, le SLA, l’annexe de sécurité ou la documentation contraignante applicable.
Mesurable : la fréquence, la rétention, le RPO, le RTO, la couverture et les délais ne doivent pas dépendre d’interprétations.
Opérationnel : le processus doit préciser la demande, l’approbation, l’escalade, la communication, le coût et les critères de clôture.
Démontrable : des rapports, des tests, des journaux, des certifications ou des preuves équivalentes doivent étayer l’affirmation.
12 questions sur la sauvegarde SaaS
1. Quelles données, quelles métadonnées et quels paramètres sont inclus ?
Vérifiez si la copie couvre les documents, les versions, les métadonnées, les commentaires, les décisions de validation, les pièces jointes, les utilisateurs, les permissions, les journaux d’audit, les règles, les flux et les paramètres nécessaires pour reconstruire le processus. En effet, restaurer uniquement les fichiers peut laisser l’information sans contexte, sans titulaire ou sans valeur probante.
Demandez une liste des inclusions et des exclusions. Par exemple, les intégrations, les fichiers temporaires, les données des applications connectées et les clés peuvent suivre des politiques différentes.
2. Quels scénarios de perte sont réellement couverts ?
Confrontez la réponse à des situations concrètes : suppression accidentelle par un utilisateur, modification indue, corruption silencieuse, compromission d’un compte administrateur, rançongiciel, panne d’une région, indisponibilité prolongée du fournisseur et erreur lors d’une mise à jour. En effet, une même architecture de sauvegarde peut ne pas répondre à tous ces scénarios.
3. Les copies sont-elles séparées de l’environnement de production ?
Demandez s’il existe une séparation des identifiants, des comptes, des tenants, des régions ou des environnements, et si un compte compromis en production peut supprimer ou chiffrer les copies. La CISA recommande des sauvegardes hors ligne ou de cloud à cloud, chiffrées, testées et protégées contre la modification ou la suppression. Elle recommande aussi de revoir le modèle de responsabilité partagée dans le cloud.
« C’est dans un autre datacenter » ne répond pas à la question de savoir si les mêmes privilèges, clés ou commandes atteignent les deux environnements.
Restauration de la sauvegarde SaaS
4. Quel est le RPO pour chaque catégorie d’information ?
Le Recovery Point Objective (RPO) indique la perte de données maximale tolérée, exprimée en temps. Si le RPO est de quatre heures, une restauration peut faire reculer l’organisation de quatre heures au maximum. Comparez donc cet intervalle avec le rythme réel des soumissions, des validations, des accès et des modifications documentaires.
En outre, des données aux impacts différents peuvent justifier des objectifs différents. Le NIST recommande de définir un RPO par actif et d’aligner la fréquence et la technologie de copie sur cet objectif.
5. Quel est le RTO et quand le décompte commence-t-il ?
Le Recovery Time Objective (RTO) représente le délai attendu pour rétablir le service ou les données. Précisez si le décompte commence à l’incident, à la détection, à l’ouverture de la demande ou à la confirmation du fournisseur. Vérifiez également si le délai couvre seulement la remise des fichiers ou le rétablissement fonctionnel de l’application, y compris les paramètres, les permissions et les dépendances.
Un RTO n’est crédible que s’il a été mesuré lors d’un test comparable et s’il inclut des composants comme les données, l’application, la configuration et les clés.
6. Quelle granularité de restauration est disponible ?
Vérifiez s’il est possible de restaurer un document, une version, un enregistrement, un dossier logique, un prestataire, une unité, une base de données ou tout l’environnement. Toutefois, plus la restauration est large, plus son impact peut être important sur les modifications légitimes effectuées après le point choisi.
Demandez également comment les données restaurées sont rapprochées de l’état actuel et comment on évite de réintroduire des informations corrompues ou du code compromis.
Rétention, protection et tests
7. Pendant combien de temps les points de restauration restent-ils disponibles ?
La rétention doit être suffisamment longue pour détecter des incidents tardifs, mais elle ne doit pas être confondue avec une conservation indéfinie. Demandez la séquence réelle des points disponibles : quotidiens, hebdomadaires, mensuels ou autre modèle. Vérifiez aussi ce qui se passe lorsque le client supprime des données en vertu d’une obligation ou d’une politique.
Distinguer la rétention des sauvegardes, la conservation documentaire et l’archivage évite qu’une copie technique serve de substitut à une politique de conservation approuvée.
8. Comment le fournisseur protège-t-il les accès, les clés et les emplacements ?
Vérifiez le chiffrement en transit et au repos, la gestion et la récupération des clés, l’authentification forte, le moindre privilège, la séparation des tâches, la journalisation des accès et la protection contre la suppression. De plus, demandez où le fournisseur traite et stocke les données, quels sous-traitants interviennent et comment il contrôle les transferts internationaux.
Une copie chiffrée est inutile si l’organisation ne peut pas accéder à la clé pendant la restauration ; elle n’est pas sûre si la clé peut être compromise par le même chemin que la production.
9. Quand le dernier test a-t-il eu lieu et quelles preuves existent ?
Demandez la date, le périmètre, le scénario, le volume, le résultat, le RPO et le RTO observés, les défaillances constatées et les actions correctives. Un test portant sur un petit fichier ne prouve pas qu’une base de données, un historique ou un environnement complet peut être restauré dans le délai requis par l’activité.
Le RGPD prévoit la capacité de rétablir la disponibilité et l’accès aux données dans des délais appropriés, ainsi qu’une procédure régulière de test et d’évaluation des mesures de sécurité. Le responsable compétent doit valider l’application concrète.
Responsabilités et réversibilité dans la sauvegarde SaaS
10. Qui peut demander, approuver et exécuter une restauration ?
Définissez les contacts, l’authentification de la demande, l’autorité de décision, les priorités, la communication, l’escalade, les fenêtres d’exécution et les coûts. Un processus techniquement possible peut échouer parce que personne ne sait qui autorise la restauration, ou parce que le contact est injoignable en dehors des heures habituelles.
Enfin, précisez la responsabilité du client, qui classe les données, définit les objectifs, tient les contacts à jour et valide le résultat. Précisez aussi celle du fournisseur, qui exécute, communique et conserve les preuves, conformément au service contracté.
11. Comment exporter les données et préparer la réversibilité ?
Sauvegarde et portabilité ne sont pas identiques, mais une stratégie de réversibilité réduit la dépendance. Vérifiez les catégories exportables, les formats structurés, les métadonnées, les pièces jointes, les journaux, la documentation technique, la fréquence, la durée, le coût et la capacité d’import dans un autre environnement.
Le règlement sur les données de l’Union européenne contient des règles sur le changement de services de traitement de données, l’information sur les formats, la continuité et les périodes de récupération. L’applicabilité et les clauses du contrat doivent être examinées par des juristes, en tenant compte du type de service et d’éventuelles exceptions.
12. Que deviennent les copies à la fin du contrat ?
Le contrat doit préciser la période pendant laquelle les données peuvent être récupérées, le moment de la suppression, le traitement des copies résiduelles, l’émission d’une confirmation, les cas de conservation obligatoire et l’impact des litiges ou d’un legal hold. Par conséquent, le client doit terminer et valider l’export avant de perdre l’accès.
Pour le traitement de données personnelles, les instructions, la restitution ou la suppression en fin de service et les mesures de sécurité doivent être alignées sur les rôles et obligations applicables au responsable du traitement et au sous-traitant.
Grille rapide d’évaluation du fournisseur
Couverture
Preuve attendue : Inventaire des données, métadonnées, journaux et paramètres inclus.
Signal d’alerte : « Nous sauvegardons tout » sans liste d’exclusions.
Restauration
Preuve attendue : RPO/RTO par service, granularité et procédure.
Signal d’alerte : Délais seulement indicatifs ou décomptés après acceptation interne.
Résilience
Preuve attendue : Séparation des environnements, immuabilité et contrôle de la suppression.
Signal d’alerte : Mêmes identifiants administrateur en production et pour la sauvegarde.
Tests
Preuve attendue : Rapport récent, scénario comparable et actions correctives.
Signal d’alerte : Test limité à un fichier, sans mesure du temps.
Sécurité
Preuve attendue : Chiffrement, clés, accès, journaux, emplacements et sous-traitants.
Signal d’alerte : Réponses génériques, sans responsables ni preuves.
Exploitation
Preuve attendue : Contacts, approbation, escalade, communication et coûts.
Signal d’alerte : Processus dépendant d’une seule personne ou d’un canal informel.
Réversibilité
Preuve attendue : Formats, périmètre, période de récupération, assistance et suppression.
Signal d’alerte : Export sans métadonnées ou sans test de réutilisation.
Définissez les objectifs à partir de l’impact sur l’activité
Ne choisissez pas un RPO et un RTO simplement parce que le fournisseur les propose déjà. Au contraire, ils doivent découler de l’impact de l’indisponibilité et de la perte de modifications. Ainsi, une analyse simple par processus documentaire évite d’appliquer le même niveau de service à tout.
Autorisations d’accès
Impact principal : Blocages ou entrées indues.
Conséquence pour la sauvegarde : Faible tolérance ; restauration prioritaire.
Validations et rejets
Impact principal : Perte de décisions et reprises.
Conséquence pour la sauvegarde : Préserver l’historique, les commentaires et les responsables.
Documents juridiques et contractuels
Impact principal : Manque de preuves et risque en cas d’audit.
Conséquence pour la sauvegarde : Rétention et restauration alignées sur des exigences validées.
Configuration et permissions
Impact principal : Processus restauré avec de mauvaises règles.
Conséquence pour la sauvegarde : Inclure dans le périmètre ou maintenir une reconstruction documentée.
Contenu informatif
Impact principal : Impact opérationnel limité.
Conséquence pour la sauvegarde : Objectifs proportionnés à la valeur et au coût.
Responsabilité partagée : Quatre décisions à ne pas déléguer
Classer la criticité des informations et identifier les dépendances du processus.
Approuver le RPO, le RTO, la rétention et les priorités de restauration avec les responsables métier.
Tenir à jour les contacts, les procédures internes et l’autorité pour demander et valider une restauration.
Tester la continuité complète, y compris les personnes, les intégrations, les accès et la communication, et pas seulement la copie technique.
Le fournisseur maîtrise la technologie et exécute le service contracté ; l’organisation continue de décider ce qui est critique, quelle perte elle tolère et quand le résultat est acceptable. C’est pourquoi cette frontière doit figurer dans une matrice des responsabilités simple et à jour.
Plan de revue sur 30 jours
Semaine 1
Inventorier les plateformes SaaS et identifier les propriétaires, les données critiques, les intégrations et les contrats.
Semaine 2
Envoyer les 12 questions, réunir les SLA, les annexes de sécurité, les rapports de tests et la documentation de réversibilité.
Semaine 3
Comparer les besoins avec le RPO/RTO, la couverture et la rétention ; consigner les écarts, les responsables et le risque accepté.
Semaine 4
Réaliser ou observer un test représentatif ; mettre à jour les procédures, les contacts, les clauses et le plan d’amélioration.
Questions fréquentes sur la sauvegarde SaaS
Le fournisseur SaaS est-il toujours responsable de la sauvegarde ?
Il ne faut pas le présumer. Le contrat et le modèle de responsabilité partagée déterminent le service fourni, tandis que l’organisation conserve des responsabilités en matière de classification, d’objectifs, d’accès, d’instructions et de continuité. Faites-le confirmer par écrit.
L’export périodique remplace-t-il une sauvegarde ?
Pas nécessairement. Il peut favoriser la souveraineté et la réversibilité, mais ne préserve pas toujours les versions, les relations, les permissions, les journaux ou la capacité de restauration rapide. Il convient donc de le tester dans le cadre d’une stratégie plus large.
Qu’est-ce qu’un bon RPO ou RTO ?
Il n’existe pas de valeur universelle. L’objectif adéquat dépend de l’impact de la perte de modifications et de la durée d’interruption maximale tolérable pour chaque processus.
Une sauvegarde immuable élimine-t-elle le risque de rançongiciel ?
Elle réduit le risque de modification ou de suppression de la copie, mais ne garantit pas que la copie soit saine, complète ou restaurable. Elle ne remplace pas non plus le contrôle d’accès, la détection, la réponse et les tests.
Faut-il tester si le fournisseur présente déjà des certifications ?
Oui. Les certifications peuvent renforcer la confiance dans le système de management et dans les contrôles évalués. Cependant, elles ne démontrent pas à elles seules que vos données et dépendances ont été restaurées dans le délai propre à votre activité.
Quels services doivent participer à l’évaluation ?
L’informatique et la sécurité, le propriétaire du processus, les achats, le juridique, la protection des données, la continuité et la gestion documentaire. De cette façon, on évite une décision uniquement technique ou uniquement contractuelle.
De l’évaluation à l’exploitation documentaire
La qualité de la sauvegarde dépend aussi de la façon dont la plateforme est administrée : propriétaires identifiés, accès à jour, paramètres documentés, modifications contrôlées et procédures connues. D’ailleurs, une plateforme techniquement robuste peut rester vulnérable à des processus informels ou à des responsabilités ambiguës.
GEDOC Service intervient dans la numérisation, le paramétrage, l’administration technique et l’accompagnement à l’utilisation des plateformes de gestion documentaire, sur la base des processus définis par le client. Ainsi, cette exploitation structurée peut aider à maîtriser les informations de configuration, les responsabilités et les procédures. Elle ne remplace pas pour autant la définition des exigences légales, de sécurité ou de continuité par l’organisation et les fournisseurs compétents.
Prochaine étape : Choisissez une plateforme documentaire critique et demandez des réponses documentées aux 12 questions. Si le RPO, le RTO, la granularité, le test ou la réversibilité ne peuvent pas être démontrés, consignez l’écart comme un risque et attribuez une action assortie d’un délai et d’un responsable.
Découvrez GEDOC Service et consultez les contenus complémentaires sur la validation de la restauration et la sauvegarde 3-2-1-1-0.
Articles associés
Sauvegardes, service AISP-GEDOC
Validation de la restauration (Proof of Restore)
L’importance des sauvegardes dans la gestion documentaire
GEDOC Service, administration technique des plateformes
Politique de gestion de l’historique des documents
Note éditoriale et sources consultées
Cet article est informatif et s’adresse aux organisations qui évaluent des services SaaS au Portugal et dans l’Union européenne. Il ne constitue pas un conseil juridique, en cybersécurité ou en continuité d’activité, et ne confirme pas les caractéristiques d’un fournisseur. Des professionnels compétents doivent valider les exigences, les contrats, les risques et les mesures.
Sources consultées le 4 août 2026 :
EUR-Lex, RGPD, articles 28 et 32
EUR-Lex, règlement sur les données, chapitre VI
NIST SP 800-209, Security Guidelines for Storage Infrastructure
ENISA, Procure Secure: cloud security service levels
GEDOC, Sauvegardes, GEDOC Service et articles associés
Pour aller plus loin : Comment choisir une plateforme de gestion documentaire.