Un logiciel sur mesure arrive en fin de vie : l'activité s'arrête, un outil le remplace, un client part. Éteindre le serveur fait économiser un abonnement, mais c'est irréversible. Si un an plus tard il faut retrouver une facture, répondre à un contrôle ou relancer l'outil, la question devient : peut-on vraiment le restaurer ? Un développeur a récemment documenté la fermeture de sa plateforme Laravel avec une règle simple : ne pas tester qu'on sait créer une sauvegarde, mais qu'on sait restaurer depuis elle. Voici la méthode, adaptée à une PME.
Que faut-il inventorier avant de fermer ?
Dressez la liste de ce qui fait tourner l'application : version de PHP, de la base de données, du framework, services annexes (file d'attente, cache), envoi d'e-mails, tâches planifiées, certificat HTTPS, noms de domaine, services externes branchés (paiement, transporteur, comptabilité). Cet inventaire sert de feuille de route à celui qui devra remonter l'outil un jour, y compris vous-même dans deux ans, quand vous aurez oublié ce qu'il y avait derrière.
Qu'est-ce qu'il faut archiver ?
Quatre ensembles, de préférence séparés pour pouvoir les tester un par un :
- Le code de l'application, avec le fichier qui fixe les versions exactes des composants. Sans lui, une restauration dépend de ce qui existera encore chez les éditeurs.
- La configuration du serveur (web, tâches planifiées, files d'attente).
- La base de données, exportée à part : c'est elle qui contient votre activité.
- Un guide de reconstruction : l'ordre des opérations, les versions, les réglages DNS, les contrôles à faire après restauration.
Pensez enfin aux secrets, dont la clé de chiffrement de l'application : si des données sont chiffrées et que cette clé est perdue, elles sont définitivement illisibles. Elle doit être conservée, mais jamais en clair.
Comment protéger ces archives ?
Elles contiennent des données de clients et des secrets : chiffrez-les avant de les sortir du serveur, avec un mot de passe long rangé dans un gestionnaire de mots de passe, pas dans le même dossier. Pour les données personnelles, vérifiez avec votre responsable de la conformité la durée pendant laquelle vous avez le droit (et l'obligation) de les conserver, et ce qui doit être supprimé ensuite.
Où stocker les copies ?
Hors de l'hébergeur que vous quittez : sur un stockage de l'entreprise, et sur un second support distinct. Une capture ("snapshot") chez l'hébergeur n'est pas une archive : elle est liée à son infrastructure et disparaît avec le compte.
Comment vérifier que la copie est fiable ?
Deux contrôles, à ne pas confondre. D'abord l'empreinte (une signature numérique du fichier, calculée par la commande sha256sum) : on la calcule sur le serveur, puis sur la copie téléchargée. Si les deux valeurs sont identiques, le fichier n'a pas été altéré en route. Elle prouve que les fichiers sont identiques, pas qu'ils sont utilisables. Ensuite, le test de restauration.
Comment tester la restauration ?
Dans un environnement jetable, sans lien avec la production, par exemple un conteneur contenant la même base de données :
- déchiffrer et décompresser l'archive de la base ;
- l'importer dans le conteneur vide ;
- vérifier que les tables sont là et que le nombre de lignes des tables clés (clients, commandes, factures) correspond à ce que vous attendez ;
- supprimer le conteneur.
Le développeur dont nous parlons précise lui-même ce qu'il n'a pas testé : reconstruire toute l'application (serveur web, files, certificat, DNS) reste décrit dans son guide mais pas rejoué. C'est un niveau de confiance honnête : la base est prouvée restaurable, l'application est documentée. Si l'enjeu justifie plus, ajoutez un test complet sur une machine temporaire avec les mêmes versions.
Quand peut-on enfin supprimer le serveur ?
Seulement après ces vérifications. Supprimez alors le serveur, la base hébergée, les captures et les enregistrements DNS devenus inutiles, mais gardez le nom de domaine et la messagerie si vous en avez encore l'usage. Notez dans un document partagé où se trouvent les archives, qui détient le mot de passe, et la date du dernier test.
Si vous changez de prestataire plutôt que d'arrêter l'outil, la logique est la même : lisez ce qu'il faut récupérer avant de partir. Et si vous hésitez entre fermer, conserver ou faire évoluer votre outil, parlons-en ; c'est aussi ce que couvrent nos applications sur mesure.
- Ne testez pas la sauvegarde, testez la restauration, dans un environnement jetable.
- Archivez le code, la base, la configuration, un guide, et la clé de chiffrement (jamais en clair).
- Chiffrez, copiez hors de l'hébergeur, comparez les empreintes.
- Supprimez le serveur en dernier, et gardez le domaine et la messagerie utiles.
Source : Decommissioning a Laravel SaaS Without Losing the Ability to Restore It.
Questions fréquentes
Un snapshot de l'hébergeur suffit-il comme archive ?
Non. Il est lié à l'infrastructure et au compte de l'hébergeur, et disparaît avec eux. Gardez une archive indépendante, copiée ailleurs.
Pourquoi conserver la clé de chiffrement de l'application ?
Les données chiffrées avec cette clé deviennent illisibles si elle est perdue. Conservez-la dans les archives chiffrées ou dans un gestionnaire de mots de passe, jamais en clair.
À quelle fréquence retester la restauration ?
Si l'archive doit durer plusieurs années, refaites un test de temps en temps (par exemple chaque année) : les formats, mots de passe et supports peuvent se perdre avec le temps.