Continuité d’activité7 min

Sauvegardes en PME : les 7 questions à poser avant un incident

Avoir des sauvegardes ne suffit pas. Voici les 7 questions qu’un dirigeant de PME devrait poser pour savoir si son entreprise peut vraiment redémarrer après une panne, une cyberattaque ou une perte de données.

Dans beaucoup de PME, la sauvegarde est perçue comme une case cochée : le prestataire indique qu’elle existe, un outil tourne en arrière-plan, et tout le monde suppose que l’entreprise est protégée.

Mais en cas de panne majeure, de cyberattaque, de suppression accidentelle ou de perte serveur, la question n’est pas seulement de savoir si une sauvegarde existe. La vraie question est : peut-on restaurer les bonnes données, dans le bon ordre, dans un délai acceptable, avec les bonnes personnes autour de la table ?

Une sauvegarde non testée, mal documentée ou inaccessible au moment critique peut donner une illusion de sécurité. Voici les 7 questions qu’un dirigeant de PME devrait poser avant l’incident.

1. Que sauvegardons-nous réellement ?

La première question paraît simple, mais elle est souvent mal maîtrisée. Il ne suffit pas de savoir qu’une sauvegarde existe. Il faut savoir précisément ce qui est sauvegardé : fichiers, bases de données, messagerie, logiciels métier, paramètres serveurs, machines virtuelles, documents partagés ou postes critiques.

Le risque fréquent est de sauvegarder une partie visible du système, mais d’oublier une dépendance essentielle : une base SQL, un dossier de configuration, un export comptable, un connecteur métier ou une application ancienne.

  • Quels serveurs, logiciels et bases de données sont sauvegardés ?
  • Les documents partagés sont-ils couverts ?
  • Les paramètres applicatifs et configurations sont-ils inclus ?
  • Les postes ou dossiers locaux critiques sont-ils identifiés ?
  • Les outils métiers anciens ou spécifiques sont-ils intégrés au périmètre ?

2. À quelle fréquence les sauvegardes sont-elles réalisées ?

La fréquence de sauvegarde doit être cohérente avec le niveau de perte acceptable pour l’entreprise. Perdre une journée de données peut être acceptable dans certains contextes, mais catastrophique dans d’autres.

Le bon raisonnement consiste à se demander combien d’heures ou de jours de travail l’entreprise peut réellement se permettre de perdre.

  • Sauvegarde quotidienne, horaire ou temps réel ?
  • Quelle perte de données maximale est acceptable ?
  • Les données les plus critiques ont-elles une fréquence différente ?
  • La fréquence est-elle adaptée aux périodes de forte activité ?

3. Où sont stockées les sauvegardes ?

Une sauvegarde stockée au même endroit que le système de production protège contre certaines erreurs, mais pas contre tous les scénarios. Si le serveur principal tombe, si le site est indisponible ou si un ransomware chiffre aussi les sauvegardes accessibles, l’entreprise peut se retrouver bloquée.

Il faut donc comprendre où sont stockées les copies, sur quels supports, avec quelles protections et dans quelle logique de séparation.

  • Existe-t-il une copie hors site ?
  • Les sauvegardes sont-elles séparées du système principal ?
  • Une attaque ransomware peut-elle les atteindre ?
  • Les accès aux sauvegardes sont-ils protégés ?
  • Existe-t-il plusieurs générations de sauvegarde ?

4. Les sauvegardes ont-elles déjà été restaurées ?

C’est probablement la question la plus importante. Une sauvegarde n’a de valeur que si elle peut être restaurée. Pourtant, beaucoup d’entreprises n’ont jamais réalisé de test réel de restauration.

Un test de restauration permet de vérifier que les fichiers sont exploitables, que les bases redémarrent, que les versions sont cohérentes et que les procédures sont comprises.

  • Un test de restauration a-t-il été réalisé récemment ?
  • Le test portait-il sur un simple fichier ou sur un système complet ?
  • Le temps réel de restauration a-t-il été mesuré ?
  • Les erreurs rencontrées ont-elles été documentées ?
  • La direction connaît-elle le résultat du test ?

5. Dans quel ordre faut-il redémarrer ?

En cas d’incident, toutes les applications ne se valent pas. Certaines sont vitales pour produire, facturer, livrer, soigner, vendre ou communiquer. D’autres peuvent attendre.

La sauvegarde doit donc être reliée à une priorisation métier. Sans ordre de reprise, l’entreprise risque de restaurer ce qui est techniquement simple plutôt que ce qui est réellement critique.

  • Quels outils doivent redémarrer en premier ?
  • Quelles activités doivent continuer en priorité ?
  • Quels systèmes dépendent d’autres systèmes ?
  • Quels utilisateurs doivent être réactivés en premier ?
  • Existe-t-il un mode dégradé pendant la restauration ?

6. Qui fait quoi le jour de l’incident ?

Une sauvegarde peut être techniquement correcte, mais inutile si personne ne sait qui doit agir. En situation de crise, la confusion entre direction, prestataire, hébergeur, éditeur logiciel et utilisateurs peut faire perdre un temps précieux.

Il faut donc clarifier les responsabilités avant l’incident : qui décide, qui restaure, qui communique, qui vérifie, qui valide le retour en production.

  • Qui déclenche la procédure de restauration ?
  • Qui contacte le prestataire ou l’hébergeur ?
  • Qui décide du passage en mode dégradé ?
  • Qui vérifie que les données restaurées sont cohérentes ?
  • Qui informe les équipes, clients ou partenaires si nécessaire ?

7. Les sauvegardes sont-elles intégrées à un vrai PRA/PCA ?

La sauvegarde est une brique essentielle, mais elle ne constitue pas à elle seule un plan de continuité ou de reprise. Un PRA/PCA doit relier les données, les outils, les personnes, les délais, les priorités métier et les scénarios d’incident.

Sans cette vision globale, l’entreprise peut disposer de sauvegardes correctes mais rester incapable d’organiser une reprise efficace.

  • Existe-t-il une procédure écrite de reprise ?
  • Les activités vitales sont-elles identifiées ?
  • Les délais de reprise attendus sont-ils connus ?
  • Les sauvegardes sont-elles alignées avec ces délais ?
  • Un exercice ou test de crise a-t-il déjà été réalisé ?

Ce que doit retenir un dirigeant de PME

La bonne question n’est pas seulement : avons-nous des sauvegardes ? La vraie question est : savons-nous redémarrer correctement ?

Une PME n’a pas forcément besoin d’un dispositif lourd ou complexe, mais elle doit connaître ses priorités, ses dépendances, ses responsabilités et ses délais réalistes de reprise.

Un diagnostic PRA/PCA permet justement de passer d’une logique de sauvegarde technique à une logique de continuité d’activité compréhensible par la direction.

À lire selon votre situation

Prolonger la lecture vers une action concrète

Ces liens permettent de relier le sujet de l’article à une page plus opérationnelle : offre, cas d’usage, lexique ou prise de contact.

PRA / PCA PME

Clarifier les activités vitales, les scénarios de reprise, les responsabilités et les priorités de redémarrage.

Comprendre le PRA/PCA

Diagnostic cyber PME

Identifier les risques cyber prioritaires : sauvegardes, accès, ransomware, comptes sensibles et exposition internet.

Voir le diagnostic cyber

Audit SI PME

Cartographier les outils, prestataires, dépendances et points de fragilité de votre système d’information.

Découvrir l’audit SI

Questions fréquentes

Une sauvegarde suffit-elle à garantir la continuité d’activité ?

Non. Une sauvegarde est nécessaire, mais elle ne suffit pas. Il faut aussi savoir quoi restaurer, dans quel ordre, sous quel délai, avec quelles responsabilités et selon quelles priorités métier.

À quelle fréquence faut-il tester ses sauvegardes ?

La fréquence dépend de la criticité de l’activité. Pour une PME, un test régulier de restauration, au moins sur les éléments critiques, permet déjà de vérifier que les sauvegardes sont exploitables et que la procédure est comprise.

Quelle différence entre sauvegarde, PRA et PCA ?

La sauvegarde protège les données. Le PRA organise le redémarrage des systèmes. Le PCA définit comment l’entreprise continue à fonctionner pendant l’incident, même en mode dégradé.

Ressources liées

Pour aller plus loin

Pilotage SI6 min

Un projet SI ne réussit pas parce qu’il fonctionne, mais parce qu’il est adopté

Un projet SI échoue rarement à cause de la technique seule. Il échoue souvent parce que l’outil ajoute de la charge sans bénéfice immédiat pour les utilisateurs. La réussite se joue dans l’adoption.

Pilotage SI7 min

Votre PME dépend-elle trop de son prestataire informatique ?

Avoir un bon prestataire informatique est souvent indispensable. Mais lorsqu’une PME ne sait plus précisément qui détient les accès, où sont les procédures, comment restaurer ou comment arbitrer les décisions SI, la dépendance devient un risque de pilotage.

DSI externalisée7 min

DSI externalisée ou prestataire informatique : quelles différences pour une PME ?

Le prestataire informatique fait fonctionner le quotidien. La DSI externalisée aide la direction à décider, prioriser, challenger et piloter. Les deux rôles sont complémentaires, mais ils ne répondent pas au même besoin.

Vos sauvegardes existent, mais savez-vous vraiment redémarrer ?

Un premier échange permet de clarifier vos sauvegardes, vos scénarios de reprise, vos priorités métier et votre niveau réel de continuité d’activité.