Une sauvegarde fiable commence par une question simple : que faut-il pouvoir récupérer pour que l'entreprise continue à travailler ?
La réponse demande souvent un inventaire attentif. Les documents clients sont visibles. Les devis, les factures et les dossiers partagés aussi. Mais il y a souvent autre chose : une base métier, une boîte mail, un site web, une configuration de serveur, un accès à un logiciel, un export comptable, un NAS, un tenant Microsoft 365, une machine virtuelle, un poste utilisé par une personne clé.
Tant que cette liste n'existe pas, la sauvegarde reste vague. Elle peut fonctionner techniquement et rester insuffisante le jour où un fichier disparaît, où un disque tombe, où un poste est chiffré, où un prestataire fait une mauvaise manipulation.
L'objectif de ce guide est pratique. Il donne une méthode pour mettre en place une sauvegarde fiable, même dans une entreprise qui n'a pas d'équipe informatique interne. Le choix de l'outil arrive après le périmètre, la séparation des copies, la surveillance et le test de restauration.
En bref
- Listez d'abord les données nécessaires à l'activité.
- Définissez la perte acceptable en cas d'incident : une heure, une journée, une semaine.
- Gardez au moins une copie séparée du système principal.
- Protégez les comptes qui administrent les sauvegardes.
- Surveillez les échecs de sauvegarde.
- Testez une restauration sur un fichier, puis sur un dossier ou un service représentatif.
- Documentez la méthode pour éviter de dépendre d'une seule personne.
Pourquoi une sauvegarde est nécessaire
Une entreprise ne perd pas seulement des fichiers. Elle perd parfois la capacité de répondre à un client, d'envoyer une facture, de retrouver un historique, de produire un document ou de reprendre un chantier.
Les incidents courants sont souvent simples.
- Un dossier client est supprimé par erreur.
- Un ordinateur portable est volé.
- Un disque dur tombe en panne.
- Une base de données devient corrompue.
- Un serveur ne redémarre plus après une mise à jour.
- Un ransomware chiffre les fichiers accessibles.
- Un prestataire modifie une configuration sans retour arrière.
- Un site web casse après une mise à jour.
Dans ces situations, une question devient centrale : existe-t-il une copie exploitable quelque part ?
La bonne question devient : quelle version peut être récupérée, par qui, depuis où, en combien de temps, et avec quel impact sur l'activité ?
L'ANSSI recommande de sauvegarder régulièrement les données importantes, de conserver des copies séparées et de vérifier la capacité de restauration. La CISA insiste aussi sur la protection des sauvegardes face aux ransomwares, notamment avec des copies hors ligne ou difficiles à modifier par un attaquant.
Ces principes sont simples. Leur valeur dépend de la manière dont ils sont appliqués.
Étape 1. Lister ce qui doit être protégé
La première erreur consiste à partir de l'outil. Un logiciel de sauvegarde ne sait pas décider seul ce qui est vital pour l'entreprise.
Il faut commencer par un inventaire court. Pas un audit de trois semaines. Une liste exploitable.
À noter dans un tableau :
| Élément | Où se trouve-t-il | Impact si perdu | Priorité |
|---|---|---|---|
| Dossiers clients | Serveur de fichiers ou SharePoint | Retard, perte d'historique, litige | Haute |
| Comptabilité | Logiciel local ou SaaS | Facturation bloquée, obligations comptables | Haute |
| Devis et factures | Dossier partagé, logiciel métier | Suivi commercial perturbé | Haute |
| Mails importants | Microsoft 365, Google Workspace, serveur mail | Perte d'échanges et pièces jointes | Moyenne à haute |
| Site web | Hébergement web, dépôt de code, base de données | Perte de visibilité ou de leads | Variable |
| Configurations réseau | Firewall, switchs, VPN | Reprise plus lente après incident | Moyenne à haute |
La priorité ne dépend pas seulement du volume. Un petit fichier peut être plus critique qu'un gros dossier d'archives.
Une bonne liste répond à trois questions.
- Quelles données servent chaque semaine ?
- Quelles données seraient difficiles ou impossibles à reconstruire ?
- Quels systèmes doivent revenir en premier après un incident ?
Ce travail clarifie immédiatement le périmètre. Il évite de sauvegarder beaucoup de choses secondaires et d'oublier un élément métier central.
Étape 2. Définir la fréquence de sauvegarde
Toutes les données ne changent pas au même rythme. Une archive juridique peut être sauvegardée une fois par semaine. Une base commerciale active peut nécessiter plusieurs points de sauvegarde par jour.
Le bon raisonnement consiste à partir de la perte acceptable.
| Situation | Fréquence possible | Point de vigilance |
|---|---|---|
| Archives peu modifiées | Hebdomadaire | Vérifier la conservation longue |
| Dossiers clients actifs | Quotidienne | Tester la récupération d'un dossier complet |
| Comptabilité active | Quotidienne ou plus | Vérifier la cohérence avec l'application |
| Base métier | Plusieurs fois par jour selon usage | Prévoir un test avec l'éditeur ou le prestataire |
| Site web vitrine | Avant changement + sauvegarde régulière | Inclure fichiers et base de données |
La formulation la plus utile est concrète : si la dernière copie date d'hier soir, l'entreprise peut-elle accepter de perdre le travail de la journée ?
Si la réponse est non, la fréquence doit être revue.
Étape 3. Choisir où stocker les copies
Une sauvegarde fiable repose sur la séparation. Si les données de production et les sauvegardes dépendent du même disque, du même serveur, du même compte administrateur ou du même site physique, l'incident peut toucher les deux.
Une base simple peut combiner trois niveaux.
| Niveau | Rôle | Exemple |
|---|---|---|
| Données de production | Ce que l'équipe utilise chaque jour | Poste, NAS, serveur, SharePoint, application métier |
| Copie proche | Restauration rapide | NAS dédié, stockage local séparé, appliance de sauvegarde |
| Copie séparée | Protection contre panne large, vol, ransomware, sinistre local | Cloud backup, stockage externalisé, copie hors site, support déconnecté |
La règle 3-2-1 est une bonne base : trois copies, deux supports ou environnements, une copie séparée. Elle est expliquée plus en détail dans notre guide sur la règle 3-2-1.
Le point important reste la séparation réelle. Une copie cloud accessible avec le même compte compromis peut être supprimée. Un NAS de sauvegarde monté en permanence peut être chiffré avec le reste. Une sauvegarde dans le même local peut disparaître avec le matériel.
Le stockage doit donc répondre à une question pratique : qu'est-ce qui survit si le problème touche le système principal ?
Étape 4. Protéger les sauvegardes elles-mêmes
La sauvegarde devient un actif critique. Elle doit être protégée comme un système sensible.
Les points minimum :
- compte administrateur dédié
- mot de passe unique et robuste
- MFA activé sur la console de sauvegarde
- droits limités aux personnes qui en ont besoin
- journalisation des actions importantes
- alerte en cas d'échec de job
- rétention protégée contre la suppression rapide
- copie difficile à modifier depuis le réseau principal
Le sujet est particulièrement important face aux ransomwares. Les attaquants cherchent souvent à supprimer ou chiffrer les sauvegardes avant de déclencher l'incident visible. Une copie de secours qui peut être effacée depuis le même compte que la production réduit fortement la capacité de reprise.
Une mesure simple consiste à séparer les comptes. Le compte utilisé au quotidien pour administrer les postes ou les fichiers ne doit pas donner automatiquement le contrôle complet sur les sauvegardes.
Étape 5. Surveiller les échecs
Une sauvegarde qui échoue silencieusement donne une impression de sécurité. Le risque augmente avec le temps, parce que l'entreprise continue à travailler en pensant que les copies existent.
La supervision doit répondre à quatre questions.
- Le job s'est-il lancé ?
- Le job est-il allé au bout ?
- Le volume sauvegardé est-il cohérent ?
- Quelqu'un reçoit-il l'alerte en cas d'échec ?
Il faut aussi regarder les signaux faibles.
- durée de sauvegarde qui augmente fortement
- volume sauvegardé anormalement bas
- erreurs récurrentes sur certains fichiers
- support presque plein
- ancien poste qui ne se connecte plus
- licence expirée ou agent désinstallé
Un tableau de suivi simple suffit au départ.
| Contrôle | Fréquence | Responsable |
|---|---|---|
| Vérifier les jobs échoués | Chaque semaine | Interne ou prestataire |
| Vérifier l'espace disponible | Chaque mois | Interne ou prestataire |
| Tester une restauration simple | Mensuel ou trimestriel | Interne ou prestataire |
| Revoir le périmètre sauvegardé | Après changement majeur | Direction + IT |
Sans surveillance, la sauvegarde dépend de la chance. Avec une surveillance minimale, les erreurs deviennent visibles avant l'incident.
Étape 6. Tester une restauration simple
Le test le plus utile ne demande pas forcément un gros chantier. Il faut commencer petit.
Procédure :
- Choisir un fichier non critique.
- Noter son emplacement exact.
- Demander ou lancer la restauration depuis la sauvegarde.
- Restaurer le fichier dans un dossier temporaire.
- Ouvrir le fichier.
- Vérifier que la version correspond à ce qui était attendu.
- Mesurer le temps nécessaire.
- Noter le résultat.
Ce test paraît simple. Il révèle souvent beaucoup de choses : qui a les accès, où se trouve la console, quelle version est disponible, si les droits sont conservés, si la procédure est claire, si le prestataire sait répondre vite.
Un test utile produit une preuve. Le fichier restauré existe, il s'ouvre, son contenu est correct, et le temps de restauration est connu.
Étape 7. Tester un scénario réaliste
Une fois le fichier simple restauré, il faut tester un cas plus proche de la réalité.
Exemples :
- récupérer un dossier client complet
- restaurer un dossier supprimé par erreur
- récupérer la base d'un logiciel métier dans un environnement de test
- remettre en ligne une copie du site web
- restaurer quelques mails importants
- récupérer une configuration de firewall ou de NAS
Le bon scénario dépend de l'activité. Une entreprise qui vit dans les dossiers partagés doit tester un dossier complet. Une entreprise qui dépend d'un logiciel métier doit tester la base ou demander une preuve de restauration. Une entreprise qui génère des demandes via son site doit savoir comment le remettre en ligne.
Le résultat doit être documenté.
| Élément testé | Date | Temps de restauration | Résultat | Problème observé |
|---|---|---|---|---|
| Dossier client test | 2026-04-27 | 18 min | OK | Droits à vérifier |
| Base métier test | 2026-04-27 | 1 h 10 | OK partiel | Validation éditeur nécessaire |
Cette documentation crée une mémoire. Elle évite de refaire le diagnostic dans l'urgence.
Étape 8. Documenter la procédure
Une sauvegarde fiable doit pouvoir être comprise par plus d'une personne. La documentation n'a pas besoin d'être longue. Elle doit être claire.
À documenter :
- ce qui est sauvegardé
- où se trouvent les copies
- fréquence des sauvegardes
- durée de conservation
- comptes utilisés
- personne ou prestataire responsable
- procédure de restauration simple
- dernier test réalisé
- prochain test prévu
- contacts utiles en cas d'incident
La documentation protège l'entreprise contre un autre risque : dépendre de la mémoire d'une seule personne.
Si le prestataire est le seul à savoir où sont les sauvegardes, comment les restaurer et quels comptes les administrent, la reprise dépend aussi de sa disponibilité. Ce point rejoint un enjeu plus large de gouvernance IT et de réversibilité.
Les erreurs classiques
Sauvegarder sur le même support
Une copie sur le même disque ou le même serveur protège peu. Elle peut aider contre une suppression simple, mais elle ne tient pas face à une panne matérielle ou un incident plus large.
Ne jamais tester
Un tableau de bord vert ne remplace pas une restauration. Le test donne la preuve que les données sont récupérables et que la procédure est comprise.
Oublier les services cloud
Microsoft 365, Google Workspace, SharePoint, OneDrive ou un CRM SaaS doivent être regardés avec attention. La disponibilité de la plateforme ne garantit pas toujours que l'entreprise peut restaurer les données au niveau souhaité.
Laisser les sauvegardes accessibles avec les mêmes droits
Si un compte compromis peut atteindre production et sauvegarde, le risque augmente fortement. La séparation des comptes et des droits fait partie de la stratégie.
Ne pas surveiller les échecs
Une sauvegarde peut échouer pendant plusieurs jours sans bruit si personne ne regarde les alertes. La supervision reste indispensable, même avec un outil simple.
Ne pas inclure les configurations
Les fichiers métier sont importants, mais les configurations le sont aussi. Firewall, NAS, switch, hyperviseur, DNS, tâches planifiées, scripts et documentation peuvent accélérer fortement la reprise.
Exemple de mise en place simple
Voici une base raisonnable pour une petite entreprise avec un serveur ou un NAS, Microsoft 365 et un site web.
| Élément | Sauvegarde | Fréquence | Test |
|---|---|---|---|
| Dossiers partagés | Copie locale + copie séparée | Quotidienne | Dossier test trimestriel |
| Comptabilité | Export + sauvegarde applicative | Quotidienne | Fichier ou base testée |
| Microsoft 365 | Solution dédiée ou export selon besoin | Quotidienne selon criticité | Mail ou dossier restauré |
| Site web | Fichiers + base + configuration | Avant changement + régulier | Copie de test remise en ligne |
| Configurations réseau | Export sécurisé | Après modification | Vérification documentaire |
Cette base doit ensuite être adaptée. Le niveau de protection dépend du coût d'un arrêt, de la fréquence de modification des données et de la capacité interne à gérer les restaurations.
Quand demander de l'aide
Une entreprise peut appliquer seule une première méthode : lister les données critiques, vérifier où sont les copies, lancer une restauration simple, noter le résultat.
L'accompagnement devient utile quand certains points restent flous.
- personne ne sait exactement ce qui est sauvegardé
- aucun test de restauration n'a été fait récemment
- les sauvegardes sont accessibles avec les mêmes comptes que la production
- les alertes d'échec ne sont pas suivies
- les données Microsoft 365 ou SaaS ne sont pas couvertes clairement
- le prestataire est le seul à connaître la procédure
- le temps de reprise est inconnu
Dans ce cas, un diagnostic court permet déjà de remettre de l'ordre : périmètre, fréquence, stockage, sécurité, surveillance, test de restauration.
Initial Infrastructures peut vous aider à auditer votre stratégie de sauvegarde, identifier les données réellement critiques, mettre en place une architecture adaptée et tester la restauration avant qu'un incident arrive.
Vous pouvez demander un premier échange via la page diagnostic ou consulter nos services liés à la rétention et la sauvegarde.
Checklist finale
- Les données critiques sont listées.
- La fréquence de sauvegarde est adaptée au rythme de l'activité.
- Une copie séparée existe.
- Les comptes de sauvegarde sont protégés.
- Les échecs génèrent une alerte suivie.
- Une restauration de fichier a été testée.
- Un scénario réaliste a été testé.
- La procédure est documentée.
- Le dernier test et le prochain test sont connus.
Une sauvegarde fiable ne se reconnaît pas à la complexité de l'outil. Elle se reconnaît à la clarté de la méthode, à la séparation des copies, à la surveillance des erreurs et à la preuve qu'une restauration fonctionne.
Sources
- ANSSI, Guide d'hygiène informatique
- CISA, StopRansomware Guide
- NIST Cybersecurity Framework
- Microsoft Azure Backup overview
Sources
Accompagnement disponible sur ce sujet
Initial Infrastructures intervient sur l'ensemble de ces problématiques pour les PME et ETI. Un échange court permet d'identifier les priorités et le bon niveau d'intervention.