En informatique nuage, utiliser un logiciel SaaS ne signifie pas que toutes vos données sont sauvegardées selon vos besoins. Le fournisseur assure l’exploitation du service dans les limites de son contrat. Votre organisation doit définir ses exigences de récupération et vérifier qu’un dispositif permet réellement d’y répondre. Une sauvegarde complémentaire peut être nécessaire, mais elle n’est pas automatiquement indispensable si les fonctions incluses couvrent vos risques et sont testées.
Pour une PME ou une collectivité des Antilles-Guyane, la question est donc précise : après une suppression, un compte compromis ou un incident fournisseur, qui peut restaurer les données, lesquelles et sous quel délai ?
Informatique nuage et SaaS : qui est responsable de quoi ?
L’informatique en nuage, ou cloud computing, consiste à utiliser des ressources informatiques accessibles à distance. Le SaaS, pour Software as a Service, en est une forme : l’organisation utilise une application exploitée par un fournisseur, comme Microsoft 365, Google Workspace ou un logiciel de gestion en ligne.
Le fournisseur prend généralement en charge l’infrastructure et le fonctionnement de l’application. L’organisation conserve des responsabilités sur ses données, ses utilisateurs et les droits qu’elle attribue. Le modèle de responsabilité partagée présenté par Microsoft illustre cette distinction, dont les modalités concrètes dépendent du service et du contrat.
Un prestataire informatique peut administrer les comptes, superviser les sauvegardes et réaliser les restaurations. Ces tâches doivent toutefois figurer explicitement dans son périmètre d’intervention. Un contrat d’assistance ne vaut pas automatiquement contrat de sauvegarde SaaS.
Dans un projet d’informatique en nuage, la bonne répartition associe donc un décideur métier, un responsable opérationnel et des engagements vérifiables du fournisseur.
Synchronisation, rétention et sauvegarde ne rendent pas le même service
Une application disponible peut contenir des données supprimées ou devenues inutilisables. La continuité technique du service ne prouve pas que votre entreprise pourra récupérer un dossier dans son état antérieur.
| Mécanisme | Fonction principale | Limite à examiner |
|---|---|---|
| Réplication et haute disponibilité | Maintenir le service malgré certaines défaillances techniques | Une suppression ou une corruption peut être répliquée |
| Synchronisation | Reporter les modifications entre appareils et espaces partagés | Elle peut propager une suppression ou une modification indésirable |
| Corbeille et historique des versions | Récupérer certains éléments ou états précédents | Délais, objets couverts et droits de récupération variables |
| Politique de rétention | Conserver des contenus selon des règles définies | Elle ne constitue pas nécessairement un dispositif de restauration opérationnelle |
| Sauvegarde dédiée | Conserver des points de récupération et permettre leur restauration | Couverture, isolation et capacité de restauration à vérifier |
Une copie utilisée par l’éditeur pour reconstruire son infrastructure n’est pas nécessairement accessible pour restaurer votre seule boîte mail ou un dossier précis.
En informatique en nuage, il faut donc distinguer la protection du service de la récupération de vos données métier. L’existence d’une copie ne suffit pas : son usage, sa durée de conservation et ses conditions de restitution doivent être connus.
Ce que le contrat SaaS doit préciser sur la récupération
Avant d’acheter une sauvegarde supplémentaire, examinez les garanties déjà disponibles dans votre abonnement. Certaines fonctions sont incluses, d’autres dépendent d’une option, d’une configuration ou d’une licence particulière.
Demandez des réponses écrites sur les points suivants :
- Le périmètre couvert : messages, fichiers, pièces jointes, espaces partagés, bases métier, métadonnées et droits d’accès.
- La conservation : durée des historiques, traitement des suppressions définitives et conséquences de la fermeture d’un compte.
- Les opérations possibles : restauration d’un élément, d’un utilisateur, d’un espace partagé ou d’un ensemble complet.
- Les délais et responsabilités : personne autorisée à demander la récupération, intervenant chargé de l’exécuter et engagements applicables.
- Les exclusions et coûts : demandes facturées, limites techniques, frais d’export et assistance nécessaire.
Un engagement de disponibilité, souvent appelé SLA, mesure le fonctionnement du service selon une méthode contractuelle. Il ne garantit pas, à lui seul, un délai de restitution de vos données.
Pour maîtriser le budget d’informatique en nuage, comparez le coût total : abonnement, protection complémentaire, stockage, exploitation et opérations de restauration. Une fonction disponible mais jamais configurée ne constitue pas une protection effective.
Fixer un RPO et un RTO selon les usages métier
Deux indicateurs permettent de traduire le besoin métier en exigences techniques.
Le RPO représente la perte de données maximale acceptable, exprimée en durée. Si une application ne peut perdre plus de quatre heures de travail, les points de récupération exploitables doivent permettre de respecter cette limite.
Le RTO représente la durée maximale acceptable pour rétablir l’activité concernée. Il comprend les opérations nécessaires à la reprise, pas seulement le téléchargement des fichiers.
Prenons un exemple fictif : une PME fixe un RPO de quatre heures et un RTO de huit heures pour son outil de gestion. Une sauvegarde quotidienne ne répond pas au premier objectif. Une restauration qui dure une journée ne répond pas au second, même si aucune donnée n’est perdue.
Les délais dépendent du volume, des limitations d’API, du débit réseau et des contrôles à effectuer avant réouverture aux utilisateurs. Dans l’informatique en nuage, une fréquence de sauvegarde annoncée ne prouve donc pas le respect du RPO : les tâches doivent aboutir et leurs résultats être contrôlés.
Évitez d’appliquer le même niveau d’exigence à une application de facturation et à des archives rarement consultées.
Construire une sauvegarde SaaS suffisamment indépendante
L’objectif n’est pas simplement de multiplier les copies. Il faut éviter qu’un même incident rende indisponibles les données de production et tous leurs points de récupération.
Isoler les accès et protéger les copies
Une sauvegarde administrée uniquement avec le compte compromis de l’application reste exposée. Séparez les rôles, utilisez l’authentification multifacteur et limitez les personnes autorisées à supprimer les copies ou à réduire leur conservation.
Selon la criticité, recherchez des mécanismes de verrouillage ou d’immutabilité. Une copie immuable ne peut pas être modifiée ou supprimée pendant une période définie, dans les conditions techniques du dispositif. Cette propriété doit être vérifiée, et non déduite d’une simple mention commerciale.
L’indépendance ne se résume pas au choix d’un deuxième fournisseur. Elle concerne aussi les identités d’administration, le stockage et les moyens d’accès en cas d’incident. Pour approfondir cette architecture, la démarche de sauvegarde des données d’entreprise aux Antilles permet de replacer les applications SaaS dans la protection globale du système d’information.
Vérifier la couverture réelle de l’application
Une solution peut protéger les fichiers sans récupérer tous les commentaires, liens de partage ou droits associés. Les possibilités dépendent notamment des interfaces proposées par l’éditeur et des fonctions du produit de sauvegarde.
Demandez une démonstration sur un échantillon représentatif : dossier partagé, boîte mail, pièce jointe métier ou enregistrement applicatif. Contrôlez ensuite que le résultat est exploitable par les utilisateurs.
Pour l’informatique en nuage, la restauration granulaire est souvent déterminante : récupérer quelques éléments peut être préférable au retour en arrière d’un espace complet. Vérifiez également les possibilités de restauration vers un autre compte ou d’export dans un format réutilisable.
Un export de données peut faciliter une sortie de service sans permettre, à lui seul, de reconstituer l’application et ses fonctions.
Tester une restauration, pas seulement surveiller les sauvegardes
Un indicateur vert confirme généralement qu’une tâche s’est terminée selon les critères de l’outil. Il ne prouve pas que l’ensemble des données nécessaires à l’activité est récupérable.
Un test utile suit une procédure documentée :
- Choisir un scénario réaliste : suppression d’un dossier partagé, perte d’accès à un compte ou altération de données métier.
- Sélectionner un point de récupération : vérifier sa date, son intégrité et son adéquation avec la perte acceptable.
- Restaurer dans un espace contrôlé : éviter d’écraser la production et mesurer le délai complet.
- Faire valider le résultat par le métier : ouvrir les fichiers, vérifier les pièces jointes, les droits et les éléments associés.
- Conserver les preuves et corriger les écarts : consigner le périmètre, les temps mesurés et les actions à mener.
La fréquence des tests dépend de la criticité et des changements apportés au service. Un changement de licence, de configuration ou d’outil mérite une nouvelle vérification.
Pour l’informatique en nuage, testez aussi un scénario où l’application d’origine est inaccessible. Pouvoir exporter des fichiers est utile, mais ne signifie pas nécessairement que les équipes peuvent poursuivre leur travail sans cette application.
Adapter le dispositif aux contraintes des Antilles-Guyane
En Martinique, en Guadeloupe et en Guyane, les scénarios doivent tenir compte des aléas climatiques, de l’alimentation électrique et de la connectivité des sites. Une sauvegarde distante peut rester intacte alors que les utilisateurs ne peuvent plus accéder au service.
Pour une organisation multisite, distinguez donc la protection des données et les moyens de continuer à travailler : connexion de secours, équipements disponibles, site de repli ou procédure temporaire adaptée au métier.
Le lieu de stockage des copies mérite également un examen précis. Un hébergement proche ne suffit pas à démontrer la résilience si la production et les sauvegardes partagent les mêmes dépendances électriques ou réseau. À l’inverse, une copie distante doit rester récupérable dans des délais compatibles avec les débits réellement disponibles.
Une stratégie d’informatique en nuage doit intégrer ces conditions d’accès. La proximité d’une équipe capable d’intervenir sur site complète l’assistance distante, sans remplacer les tests de reprise.
Organiser le pilotage, la conservation et la sortie du service
Désignez un responsable qui vérifie les alertes, suit les échecs et organise les tests. Le prestataire peut exécuter ces tâches, tandis que la direction valide les priorités et les pertes acceptables. Cette répartition doit rester compréhensible en situation de crise.
La conservation doit être proportionnée aux besoins. Lorsque des données personnelles sont concernées, le RGPD, notamment son article 32, prévoit des mesures de sécurité adaptées au risque, dont des moyens de rétablir la disponibilité et l’accès dans des délais appropriés après un incident. Il prévoit aussi une procédure visant à tester et évaluer régulièrement l’efficacité des mesures. Il n’impose pas systématiquement une marque ou une solution de sauvegarde distincte.
Enfin, anticipez la fin du contrat : récupération des données, accès aux copies, formats et suppression après transition. La préparation de la réversibilité du cloud informatique complète la sauvegarde, mais répond à un objectif différent : pouvoir changer de service sans dépendance excessive.
Ces éléments rendent l’informatique en nuage pilotable : un périmètre connu, des responsabilités écrites et des résultats de restauration mesurés.
Questions fréquentes
Mon fournisseur SaaS sauvegarde-t-il déjà mes données ? Il peut disposer de sauvegardes techniques et de fonctions de récupération. Vérifiez si elles permettent de restaurer vos données après les incidents qui vous concernent, avec la bonne granularité et dans les délais attendus.
Faut-il toujours une sauvegarde externe pour Microsoft 365 ou Google Workspace ? Pas automatiquement. Analysez les fonctions natives, leur configuration et les limites de votre abonnement. Une protection complémentaire est pertinente lorsqu’un risque ou une exigence de récupération n’est pas couvert de manière suffisante et vérifiable.
Qui réalise la restauration si l’informatique est externalisée ? L’intervenant désigné dans le contrat : équipe interne, éditeur ou prestataire. Précisez qui reçoit l’alerte, autorise l’opération, l’exécute et fait valider le retour à la normale.
Une sauvegarde protège-t-elle contre tous les effets d’un ransomware ? Non. Elle peut aider à récupérer des données si les copies sont saines et accessibles. Elle n’empêche pas le vol d’informations, la compromission de comptes ou toutes les interruptions. Elle complète la prévention, la détection et la réponse à incident.
Peut-on restaurer les données si le fournisseur SaaS est indisponible ? Cela dépend de l’accès aux copies et des fonctions de restauration. Pour l’informatique en nuage, demandez explicitement quels exports ou destinations alternatives restent utilisables. Les données récupérées peuvent nécessiter une autre application pour être exploitées.
Faire évaluer votre protection SaaS avec AITEC
Avant d’ajouter un outil, faites examiner vos applications critiques, les garanties contractuelles et les preuves de restauration disponibles. L’objectif est d’identifier les écarts entre votre besoin métier et la protection réellement opérationnelle.
AITEC accompagne les entreprises et collectivités des Antilles-Guyane en audit, cloud, sauvegarde, cybersécurité et exploitation informatique. Cet accompagnement peut relier la définition de l’architecture, son déploiement et son suivi, avec un périmètre de responsabilités à formaliser.
Pour étudier votre stratégie cloud avec AITEC, préparez la liste de vos services SaaS, vos contraintes d’interruption et le compte rendu du dernier test de restauration. Ce sont des bases concrètes pour décider quoi conserver, renforcer ou remplacer.
