Hébergement & exploitation
Sauvegarde, panne et mise à jour : le plan à écrire avant la mise en service
Quatre réponses écrites suffisent à savoir si votre application est réellement protégée : fréquence des sauvegardes, durée de reprise, endroit où l’on teste, et qui valide quoi avant une mise à jour.
Un plan d’exploitation tient en quatre réponses écrites : à quelle fréquence les données sont sauvegardées, combien de temps il faut pour repartir après une panne, où les nouveautés sont testées avant d’arriver en production, et qui valide quoi avant une mise à jour. Écrites avant la mise en service, ces quatre réponses coûtent une réunion. Découvertes après une panne, elles coûtent des jours de travail et parfois des données.
En bref
- Une sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde : c’est une hypothèse.
- La fréquence de sauvegarde définit exactement ce que vous acceptez de perdre. Une copie par nuit signifie au pire une journée de saisie à refaire.
- Un environnement de test n’est pas un luxe : c’est ce qui permet de valider une nouveauté sans risquer l’activité réelle.
- Une interruption planifiée à minuit, annoncée à l’avance et de durée connue, ne ressemble en rien à une panne subie en pleine journée.
- Exigez ces engagements par écrit avant la signature : après, ils deviennent une négociation.
Les quatre questions auxquelles répondre par écrit
La plupart des mauvaises surprises d’exploitation ne viennent pas d’un incident technique, mais du fait que personne n’avait écrit ce qui devait se passer. Quatre questions suffisent à révéler si un dispositif tient debout, et elles se posent avant la mise en service, pendant que le rapport de force permet encore d’obtenir des réponses précises.
Une réponse floue à l’une de ces quatre questions annonce presque toujours un coût différé. Ce n’est pas nécessairement un mauvais prestataire — c’est un point qui n’a pas encore été traité, et qui le sera dans l’urgence.
- À quelle fréquence les données sont-elles copiées, et où cette copie est-elle stockée ?
- Combien de temps faut-il pour remettre le service en marche après une panne complète ?
- Où les nouveautés sont-elles installées et essayées avant d’arriver chez vous ?
- Qui décide qu’une mise à jour part en production, et à quel moment ?
Sauvegarder, c’est décider ce que vous acceptez de perdre
Une fréquence de sauvegarde n’est pas un réglage technique : c’est une décision de gestion. Une copie complète chaque nuit signifie que, dans le pire des cas — une panne juste avant la copie — vous repartez de la veille et vous refaites une journée de saisie. Formulée ainsi, la question se tranche en une minute par un dirigeant, sans aucune compétence technique.
Si une journée est inacceptable, la fréquence s’augmente : plusieurs copies par jour, ou une copie continue du journal de la base de données. C’est un réglage et un coût de stockage, pas une reconstruction du système. Ce qui compte est que le choix soit conscient.
Reste la partie que presque personne ne fait : restaurer. Une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est une hypothèse. Une restauration d’essai, faite une fois sur le serveur de test, transforme cette hypothèse en fait vérifié — et révèle au passage combien de temps l’opération prend réellement.
Le serveur d’essai : rien n’arrive chez vous sans y être passé
Un environnement de test est une copie de l’application, alimentée par des données d’essai, où les nouveautés sont installées d’abord. Vous les y ouvrez, vous les manipulez, vous demandez des corrections, et rien de tout cela ne touche votre activité réelle.
Son intérêt dépasse le test. Il donne une réponse concrète à la question « à quoi ressemblera la version suivante », avant qu’elle soit installée. Il déplace la validation du moment où corriger coûte cher vers le moment où corriger ne coûte presque rien.
Bien dimensionné, ce serveur cumule plusieurs fonctions : il héberge la copie de sauvegarde nocturne, il sert de banc d’essai, et il peut prendre le relais du serveur principal en cas de panne. Trois besoins réels, une seule petite machine.
Le chemin d’une mise à jour, étape par étape
Une évolution ne devrait jamais apparaître sur les écrans de vos équipes sans que vous l’ayez vue. Le trajet suivant est celui qui produit le moins de mauvaises surprises, et il se décrit en cinq étapes que vous pouvez exiger telles quelles.
Le point important est l’étape deux. Tant que vous n’avez pas validé, rien ne part. Et l’interruption de l’étape quatre n’est jamais découverte : elle est planifiée avec vous, elle a lieu à une heure où personne ne travaille, et sa durée est annoncée avant de commencer.
| Étape | Ce qui se passe | Ce que vous voyez |
|---|---|---|
| 1. Développement | La nouveauté est construite et installée sur le serveur d’essai | Rien encore : votre application ne bouge pas |
| 2. Validation | Vous l’essayez vous-même, sur des données d’essai | Vous acceptez, ou vous demandez des corrections |
| 3. Planification | La maintenance est fixée avec vous, généralement vers minuit | Une date, une heure et une durée annoncées |
| 4. Coupure | La mise à jour est appliquée au serveur principal | Une interruption courte, connue à l’avance |
| 5. Vérification | Le service est contrôlé après la bascule | Une confirmation le lendemain matin |
Le jour où le serveur principal s’arrête
Ce jour-là, trois choses seulement comptent, et elles se mesurent : combien de temps le service reste indisponible, combien de données sont perdues, et qui décide de basculer. Si ces trois réponses ne sont pas écrites quelque part, elles seront improvisées au pire moment.
Avec un serveur de secours prêt et une copie de la nuit, la séquence est courte : constat de la panne, décision de bascule, redémarrage du service sur la machine de secours, vérification des données, information des utilisateurs. Ce qui manque, ce sont les saisies effectuées depuis la dernière copie — d’où l’importance d’avoir choisi la fréquence en connaissance de cause.
Une bascule qui n’a jamais été répétée prend toujours plus longtemps que prévu. Faire l’exercice une fois, à froid, sur une plage horaire choisie, est la seule façon de connaître la vraie durée plutôt que la durée espérée.
Ce qu’il faut exiger, quel que soit le prestataire
Ces demandes ne sont ni agressives ni inhabituelles. Elles sont le minimum qu’une entreprise doit obtenir sur un système dont dépend son activité, et un prestataire sérieux les fournit sans difficulté.
- La fréquence de sauvegarde, écrite, et l’endroit où les copies sont stockées.
- Une restauration d’essai réalisée au moins une fois, avec sa durée constatée.
- La durée de reprise annoncée en cas de panne complète, et qui la déclenche.
- Un environnement de test où vous validez avant toute mise en production.
- Les fenêtres de maintenance annoncées à l’avance, avec leur durée.
- La propriété des accès : le domaine, l’hébergement et la base doivent être à votre nom.
- Une procédure de sortie : ce que vous récupérez, et sous quelle forme, si vous changez de prestataire.
Questions fréquentes
Les réponses courtes
À quelle fréquence faut-il sauvegarder ?
La fréquence se déduit d’une seule question : combien de travail acceptez-vous de refaire ? Une copie par nuit convient à la majorité des activités de bureau et de commerce. Une activité qui saisit en continu, ou qui manipule des paiements, demande plusieurs copies par jour ou une copie continue du journal de la base.
Une sauvegarde sur le même serveur suffit-elle ?
Non. Une copie stockée sur la machine qu’elle protège disparaît avec elle. La copie doit vivre ailleurs : autre machine, autre hébergeur, idéalement autre lieu. C’est la première chose à vérifier dans une offre d’hébergement, et c’est souvent la plus vite oubliée.
Combien de temps dure une maintenance planifiée ?
De quelques minutes pour une correction simple à une demi-heure pour une évolution qui touche la structure des données. Ce qui compte n’est pas la durée elle-même mais le fait qu’elle soit annoncée avant de commencer, et qu’elle ait lieu à une heure où personne ne travaille.
Peut-on refuser une mise à jour ?
Oui, et c’est tout l’intérêt d’avoir un serveur d’essai. Vous validez la version après l’avoir manipulée. Une seule catégorie échappe à ce choix : les correctifs de sécurité, qui doivent être appliqués rapidement — ils sont annoncés, pas soumis à validation.
Qui doit posséder les accès au serveur et au domaine ?
Vous. Le nom de domaine, le compte d’hébergement et la base de données doivent être ouverts au nom de votre entreprise, avec un accès administrateur pour votre prestataire. L’inverse — un prestataire propriétaire des accès — transforme un désaccord commercial en blocage de votre activité.