Le test de 3 minutes qui prédit si votre PME va perdre toutes ses données (et pourquoi “sauvegarde terminée” ne signifie rien)

Ce qui s’est réellement passé (en 2 niveaux)

Le cas technique est simple quand on retire le jargon. SQLite est, littéralement, un carnet d’adresses interne utilisé par des milliers d’applications — de l’application de votre téléphone aux systèmes internes d’entreprise — pour écrire et lire des données. Ce carnet possède un mécanisme appelé « WAL » (qui signifie « write-ahead log ») : imaginez qu’à chaque fois que quelqu’un écrit quelque chose dans le carnet, une copie de sauvegarde est d’abord faite sur une feuille séparée, pour ne pas perdre ce qui est déjà là.

Tailscale, l’entreprise qui construit l’un des VPN les plus utilisés par les PME pour que leurs employés puissent travailler depuis l’extérieur du bureau, a découvert qu’ un fragment de ce mécanisme dysfonctionnait depuis 16 ans : lorsque le système redémarrait à certains moments, la copie de sauvegarde restait « bloquée » à un état antérieur. Le système continuait de fonctionner. Les logs disaient « OK ». Mais la copie était dépassée. Et quand quelqu’un essayait de restaurer à partir de celle-ci, il recevait des données incomplètes ou simplement vides.

Le point critique n’est pas le bug lui-même. C’est que :

• Le système a signalé « tout OK » pendant des années.
• Le journal des sauvegardes marquait chaque nuit « terminée » avec succès.
• Le premier vrai avertissement est venu quand quelqu’un a eu besoin des données et qu’elles n’étaient pas là.

C’est ce qu’en cybersécurité on appelle une « défaillance silencieuse » : elle n’avertit pas, elle ne bipe pas, elle n’apparaît dans aucun tableau de bord. Elle ne se manifeste que lorsqu’il est déjà trop tard.

Pourquoi votre PME (presque certainement) a le même schéma

Votre PME n’utilise probablement pas Tailscale, ni SQLite directement. Mais le schéma est identique à celui de tout service cloud que vous avez souscrit : le CRM où vous stockez les données de vos clients, le logiciel de facturation, l’outil de prise de rendez-vous en ligne, l’email professionnel, les sauvegardes cloud du serveur. Chacun d’eux a, caché quelque part, son propre « WAL » — son propre système de protection interne — qui :

• Redémarre périodiquement (mises à jour du fournisseur, maintenance nocturne, coupures de courant).
• Possède une sauvegarde écrasée chaque nuit.
• Vous dit « OK » parce que le fichier existe, mais ne vérifie pas que des données valides se trouvent à l’intérieur.

Selon les statistiques publiques du secteur cloud, entre 30 % et 40 % des PME européennes découvrent que leur sauvegarde est cassée uniquement lorsqu’elles essaient de l’utiliser. Ce n’est pas un cas rare. C’est le schéma d’incident de données le plus courant dans les PME.

Le test de restauration du dimanche (5 étapes, 3 minutes)

Vous n’avez pas besoin de connaissances techniques. Vous avez besoin de 3 minutes un dimanche après-midi — quand personne ne vous dérange — et d’un café. Voici les 5 étapes :

1. Demandez à votre fournisseur la dernière sauvegarde. Un email type : « Bonjour, pourriez-vous m’envoyer la dernière sauvegarde complète de mon compte, dans un format que je puisse ouvrir sur mon ordinateur ? » S’ils répondent « nous ne pouvons pas » ou « il faut payer », vous avez un problème de fond.
2. Ouvrez le fichier qu’ils vous envoient. S’il s’agit d’un tableur : ouvrez-le et vérifiez qu’il contient des lignes réelles (clients, factures, produits). S’il s’agit d’une base de données : ouvrez-la avec l’outil que vous utilisez habituellement et vérifiez que des données apparaissent.
3. Comptez 5 enregistrements et comparez-les avec votre système actuel. Par exemple : prenez les 5 derniers clients que vous avez. Sont-ils dans la sauvegarde ? Avec les données correctes (téléphone, email, adresse) ? S’il en manque un, la sauvegarde est incomplète.
4. Vérifiez la date. La sauvegarde devrait contenir des données vieilles de 24 à 48 heures maximum. S’ils vous disent « la dernière sauvegarde date du mois dernier », vous avez un problème plus important : personne ne sait ce qui s’est passé dans votre système depuis.
5. Prenez une capture d’écran du fichier ouvert et sauvegardez-la. C’est votre « preuve que la sauvegarde fonctionne ». Le jour où vous aurez un vrai incident, cette capture fera la différence entre récupérer votre activité ou perdre des semaines de travail.

Si l’une de ces étapes échoue, ne paniquez pas : cela signifie que vous avez un problème silencieux, mais vous êtes encore à temps de le résoudre. Une sauvegarde qui n’a jamais été vérifiée n’est pas une sauvegarde : c’est une hypothèse.