Sauvegardes ERP : demander une restauration testée

Pour apprécier les sauvegardes d’un ERP, demandez ce qui est protégé et comment une restauration est vérifiée. L’existence d’une copie ne prouve pas que votre activité pourra reprendre. Définissez les données, les documents et la configuration nécessaires, puis faites préciser les responsabilités et les délais dans un scénario adapté à votre organisation.

Distinguer sauvegarde, archive et disponibilité

Une sauvegarde sert à restaurer un état ; une archive répond à un besoin de conservation et de consultation ; la disponibilité concerne l’accès au service. Ces fonctions peuvent se compléter sans être interchangeables. Un système accessible peut contenir une erreur de données, et une copie conservée ne garantit pas une recherche documentaire pratique. Décrivez vos besoins séparément. Demandez ce qui couvre la base, les pièces jointes, le paramétrage et les extensions. Les obligations de conservation propres à votre activité doivent être examinées avec les interlocuteurs compétents plutôt que déduites de la seule politique technique du fournisseur.

Définir les conséquences d’un incident

Choisissez des situations concrètes : suppression involontaire, données corrompues ou indisponibilité de l’environnement. Pour chacune, décrivez ce que vous devez récupérer et les opérations qui risquent d’être perdues ou reprises. Les objectifs de délai et de point de reprise doivent être discutés à partir de l’activité. N’adoptez pas des valeurs techniques sans comprendre leurs conséquences. Si vous ne pouvez pas travailler pendant une certaine période, préparez une procédure temporaire et son rapprochement ultérieur. La continuité dépend aussi des personnes, des accès et des applications connectées.

Examiner le périmètre du service

Demandez la fréquence, la conservation, la séparation des copies et la procédure de restauration dans les limites communicables du service. Précisez qui peut demander une restauration et comment cette demande est autorisée. Certaines opérations peuvent rétablir un environnement complet plutôt qu’un document isolé. Vérifiez les limites et les coûts éventuels. Si un composant tiers n’est pas couvert, attribuez sa protection à un acteur identifié. Une liste technique doit être reliée à vos besoins de reprise ; elle ne suffit pas si personne ne sait qui agirait en cas d’incident.

Tester le résultat et le rapprochement

Un test de restauration doit vérifier l’accès à l’application, la présence des données et le fonctionnement d’un parcours important. Contrôlez aussi les pièces jointes et les droits. Une copie techniquement restaurée peut rester incomplète pour le métier. Demandez un compte rendu avec périmètre, conditions, résultat et limites. Les données utilisées pour le test doivent être protégées selon leur nature. Ne concluez pas qu’un essai unique garantit tous les scénarios. Il fournit une preuve sur un périmètre donné et permet d’améliorer les procédures avant une situation réelle.

Organiser les rôles et le maintien des procédures

Nommez la personne qui autorise la reprise et celle qui vérifie le résultat métier. Prévoyez leurs remplaçants et un canal de communication accessible si l’ERP ne fonctionne plus. Conservez les procédures essentielles dans un support approprié, distinct du système susceptible d’être indisponible. Réexaminez le plan lorsque les volumes, les composants ou les interlocuteurs changent. Les actions de sauvegarde et de test doivent avoir un responsable de suivi. Une politique rédigée au lancement mais jamais revue peut ne plus correspondre à l’environnement utilisé quelques mois plus tard.

Exemple de travail

Scénario illustratif : après une erreur de paramétrage, l’équipe demande la restauration d’un environnement de test à partir d’une copie autorisée. Elle vérifie les accès, un document avec pièce jointe et un flux de commande. Le contrôle constate que l’interface doit être reconnectée avant le parcours complet. Cette dépendance est ajoutée au plan de reprise. Aucune durée de rétablissement n’est inventée : elle doit être mesurée dans les conditions de l’essai et interprétée avec ses limites. Le résultat montre pourquoi la seule présence d’un fichier de sauvegarde ne suffit pas.

Fiche de vérification

Élément	Question à documenter	Preuve ou responsable
Périmètre	Base et composants	Inventaire couvert
Déclenchement	Demande autorisée	Responsable et remplaçant
Restauration	Procédure et limites	Compte rendu de test
Reprise métier	Parcours et rapprochement	Validation opérationnelle

À faire dans votre équipe

Choisissez un processus essentiel et demandez ce qui lui manquerait après une restauration de la base seule. Pensez aux pièces jointes, aux comptes, aux secrets d’interface et aux applications externes. Classez chaque élément selon son responsable et sa méthode de récupération. Vérifiez ensuite que les documents nécessaires restent accessibles lorsque l’ERP est arrêté. Préparez un test proportionné avec les intervenants concernés et faites valider le résultat par le métier. Cette démarche permet de repérer des dépendances sans prétendre réaliser un audit de sécurité complet. Si les compétences nécessaires ne sont pas disponibles dans votre équipe, faites définir l’essai et ses précautions par un professionnel qualifié.

Questions fréquentes

Le SaaS dispense-t-il de poser ces questions ?

Non. Le fournisseur peut prendre en charge certaines opérations, mais vous devez comprendre le périmètre, les limites et la procédure de demande de restauration.

Une sauvegarde est-elle une archive légale ?

Ne le supposez pas. Les objectifs et les conditions de conservation doivent être examinés selon vos obligations et votre organisation.

À quelle fréquence faut-il tester ?

Définissez une fréquence adaptée aux risques et aux changements, avec les responsables compétents. Aucun rythme universel n’est présenté comme une exigence dans ce guide.

Pour poursuivre

Sources et portée

CNIL — rôles des acteurs du cloud — référence officielle consultée le 30 octobre 2026.

Les démarches, tableaux et scénarios sont des propositions de méthode propres à ce guide. La référence officielle permet de vérifier les conditions ou notions mentionnées ; elle ne valide pas les hypothèses chiffrées illustratives et ne constitue pas un classement de produits.