Par Justin Rialland, fondateur d’Anthera
Sauvegardes, accès, continuité : ce qu'on vérifie avant de livrer
Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde. La liste de ce qu'il faut vérifier avant une mise en service, et le test qui vaut tous les contrats.
Les questions de sauvegarde et de continuité se posent toujours au mauvais moment, c'est à dire après. Elles se règlent en une heure avant la mise en service, et en plusieurs jours de panique ensuite.
La première vérification : où sont vos données
Il faut pouvoir répondre précisément. Chez quel hébergeur, dans quel pays, sous quel compte, payé par quelle carte.
Si la réponse est « je ne sais pas, c'est mon prestataire qui gère », vous n'avez pas un problème technique, vous avez une dépendance. Elle se règle en créant les comptes à votre nom et en y invitant le prestataire, plutôt que l'inverse.
La sauvegarde : trois questions
À quelle fréquence ? Pour un site vitrine qui change peu, une par jour suffit largement. Pour une application qui enregistre des commandes ou des dossiers clients, la question devient : combien d'heures de travail acceptez vous de perdre ?
Où ? Une sauvegarde stockée sur le même serveur que les données ne protège de rien. Un incident sur la machine emporte les deux. Il faut un emplacement distinct.
Combien de temps ? Une sauvegarde de la veille ne protège pas contre une corruption découverte trois semaines plus tard. Conserver plusieurs points dans le temps, par exemple les sept derniers jours puis quelques semaines, coûte peu et sauve les cas tordus.
Le test qui vaut tous les contrats
Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde, c'est une intention.
Demandez une restauration d'essai avant la mise en service. Pas une capture d'écran du panneau de configuration : une restauration réelle, sur un environnement de test, avec vérification que les données sont là.
C'est le seul test qui dit quelque chose, et il révèle régulièrement des surprises : des fichiers absents du périmètre, une base sauvegardée sans ses pièces jointes, un format illisible sans un outil qu'on n'a plus.
La liste des accès à tenir
Un document simple, tenu à jour, qui liste pour chaque élément qui détient l'accès et comment le récupérer.
Le nom de domaine et son bureau d'enregistrement. L'hébergement. Le dépôt de code. La base de données. Les comptes de messagerie. Les services tiers, paiement, envoi de courriels, mesure d'audience. Et les certificats, s'ils ne sont pas renouvelés automatiquement.
Ce document n'a rien de technique. Il décide pourtant de votre capacité à reprendre la main un jour.
Le point qu'on oublie toujours : le nom de domaine
C'est le seul élément vraiment irremplaçable, et c'est celui qui est le plus souvent enregistré au nom du prestataire « pour simplifier ».
Un domaine perdu ne se rachète pas. Les adresses de messagerie qui en dépendent cessent de fonctionner, et les clients qui écrivent n'obtiennent plus de réponse. Vérifiez que le contact propriétaire est bien vous, pas votre agence, et que le renouvellement automatique est actif sur un moyen de paiement valide.
Ce qu'il faut écrire pour le jour du départ
Quel que soit le prestataire, prévoyez la fin dès le début : ce qui vous est remis, sous quel format, dans quel délai, et qui accompagne le transfert.
Une clause de réversibilité tient en quelques lignes, elle ne coûte rien à écrire, et c'est elle qui fait la différence entre un changement de prestataire et une reprise en urgence.
Notre article sur à qui appartient le code complète ce point côté propriété, et celui sur la maintenance précise ce qui est couvert une fois en ligne.