Votre logiciel de gestion est-il vraiment sauvegardé ?

Souvent, non. La sauvegarde d'un logiciel de gestion ne se résume pas à copier ses fichiers. Une base de données en service ne se copie pas comme un document. Le résultat peut être une sauvegarde qui existe, qui pèse le bon poids, mais que l'application refuse de rouvrir. PostgreSQL le dit sans détour : pour qu'une copie du système de fichiers soit exploitable, le serveur de base doit être arrêté, et les demi-mesures ne suffisent pas.

Une base de données ne s'arrête jamais pendant les heures d'ouverture, et elle ne tient pas entièrement sur le disque. Une partie de son état vit en mémoire, dans des tampons pas encore vidés, et dans un journal qui enregistre les transactions en cours. La copier à cet instant donne un état partiel : certaines écritures sont passées, d'autres non, et le journal ne correspond plus aux données.

C'est une copie incohérente. Une copie cohérente est l'inverse : une image de la base à un instant donné, sans transaction à moitié faite. C'est le seul état à partir duquel l'application redémarre.

PostgreSQL est catégorique : « The database server must be shut down in order to get a usable backup. Half-way measures such as disallowing all connections will not work. » L'outil d'export dédié produit une copie « internally consistent », une image de la base à l'instant où l'export a démarré.

Sous Windows, le service de cliché instantané des volumes règle le même problème, que Microsoft pose ainsi : les applications tournent encore pendant la sauvegarde, donc leurs fichiers peuvent être ouverts ou incohérents. Le service leur demande de terminer leurs transactions et de vider leurs caches, puis fige les écritures le temps du cliché, dix secondes au maximum.

SQL Server sauvegarde en ligne, mais son mode de récupération complète réclame aussi des sauvegardes du journal des transactions.

La règle 3-2-1 reste le socle, et elle est détaillée dans notre guide sur la règle 3-2-1 pour les sauvegardes.

Cinq catégories échappent à une sauvegarde de fichiers.

La base d'un logiciel installé en local. Gestion commerciale, ERP, GMAO, planning d'atelier. Le dossier est copié tous les soirs. Il est copié ouvert.

Le logiciel loué en ligne. Vous ne possédez ni le serveur, ni la base, ni le fichier. Vous possédez un contrat.

Les configurations d'équipements. Pare-feu, routeur, switch, contrôleur du réseau Wi-Fi. Aucune ne vit sur un poste, donc aucune n'entre dans la sauvegarde des postes. L'ANSSI range les configurations des applications métier et les médias d'installation dans le périmètre.

Les certificats et les clés. Certificat du site, clés d'accès aux services, licences liées à une machine.

Le contenu d'un logiciel de caisse. Journal des ventes, catalogue, remises.

Ajoutez la sauvegarde d'une machine virtuelle entière. Veeam, éditeur de la solution que nous déployons, l'écrit : par défaut, l'outil produit une sauvegarde dite crash-consistent et ne traite pas les journaux applicatifs. Le traitement applicatif doit être activé.

Reste le logiciel en ligne. La question n'est plus « est-ce sauvegardé », mais « qu'est-ce qui est écrit ». La CNIL demande que le contrat avec un sous-traitant fixe « les conditions de restitution et de destruction des données en fin du contrat ». L'article 28 du RGPD prévoit qu'au terme de la prestation le sous-traitant supprime les données ou les renvoie au responsable du traitement, et détruit les copies. L'ANSSI y ajoute une clause de réversibilité, pour reprendre la fonction externalisée ou la confier à un tiers.

Voici la question à envoyer à chaque éditeur. Copiez-la telle quelle.

> « Bonjour, dans le cadre de notre politique de sauvegarde, merci de nous confirmer par écrit les quatre points suivants. 1. Quelles données de notre compte sont sauvegardées, à quelle fréquence, et combien de temps chaque sauvegarde est conservée. 2. Pouvons-nous déclencher nous-mêmes une restauration, et sinon, sous quel délai la réalisez-vous à notre demande. 3. Par quel moyen et sous quel format pouvons-nous exporter à tout moment la totalité de nos données, pièces jointes et historique compris. 4. Que prévoit le contrat sur la restitution et la suppression de nos données au terme de la prestation, et sous quel délai. »

Une réponse écrite se classe avec le contrat. Ces éléments restent généraux : faites valider votre situation par un professionnel du droit.

La sauvegarde d'un logiciel métier se pilote avec l'éditeur, pas contre lui. C'est lui qui connaît l'export de sa base, l'ordre d'arrêt de ses services et la procédure de remontée.

Trois décisions remettent le sujet d'aplomb. Recenser les applications une par une, avec l'endroit où vivent leurs données. Choisir pour chacune le mécanisme adapté : export natif de la base, traitement applicatif, ou export contractuel chez l'éditeur. Puis vérifier en restaurant l'application, pas en ouvrant un fichier.

L'ANSSI le formule ainsi : les sauvegardes doivent être testées régulièrement, et une procédure de restauration doit être rédigée et mise en œuvre. Relancer l'application sur la copie, et faire ouvrir un dossier réel par un utilisateur quotidien.

Nous avons passé plus de 400 heures d'intervention sur site en 14 mois. Ce contrôle se fait là, application par application, pas depuis un tableau de bord.

Nous recensons vos applications, nous ouvrons le sujet avec chaque éditeur, et nous testons la remontée en relançant l'application. Nos clients sous contrat ont une intervention sous 8 heures ouvrées, un dépannage sous 24 heures ouvrées maximum, déplacement et main d'œuvre illimités. Prenez rendez-vous avec la liste de vos logiciels.