Hébergement & exploitation
Sauvegarde, panne et mise à jour : le plan à écrire avant la mise en service
Quatre réponses écrites vous disent si votre application résiste à une panne : 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 le prestataire copie les données, combien de temps il faut pour repartir après une panne, où il teste les nouveautés avant la 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
- Faites restaurer une sauvegarde au moins une fois. C'est le seul moyen de savoir qu'elle fonctionne.
- La fréquence de sauvegarde définit ce que vous acceptez de perdre. Une copie par nuit signifie au pire une journée de saisie à refaire.
- Sur un environnement de test, vous validez une nouveauté sans toucher au travail de vos équipes.
- 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, il faudra les négocier.
Les quatre questions auxquelles répondre par écrit
La plupart des mauvaises surprises d'exploitation arrivent parce que personne n'avait écrit ce qui devait se passer. Quatre questions suffisent à révéler si un dispositif est solide, et mieux vaut les poser avant la mise en service, tant que vous êtes encore en position d'obtenir des réponses précises.
Si le prestataire répond de façon floue à l'une d'elles, il n'est pas forcément mauvais. Il n'a simplement pas encore traité ce point. Sans réponse écrite, il le traitera en pleine panne.
- À 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
C'est au dirigeant de choisir la fréquence de sauvegarde, car elle fixe la quantité de travail que l'entreprise peut perdre. Avec une copie complète chaque nuit, le pire des cas est une panne juste avant la copie. Vous repartez alors de la veille et refaites une journée de saisie. Dans ces termes, un dirigeant tranche la question en une minute, sans 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. Le prestataire change un réglage et vous payez un peu plus de stockage. Le système reste le même.
Reste l'étape que presque tout le monde saute : restaurer. Une sauvegarde jamais restaurée n'a encore rien prouvé. Une restauration d'essai, faite une fois sur le serveur de test, apporte cette preuve et donne au passage la durée réelle de l'opération.
Le serveur d'essai, où passe chaque nouveauté avant vos équipes
Un environnement de test est une copie de l'application, alimentée par des données d'essai, où l'on installe d'abord les nouveautés. 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. Vous voyez la version suivante avant son installation, et vous corrigez une nouveauté avant qu'elle arrive chez vos équipes, au moment où la correction 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.
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 tient en cinq étapes que vous pouvez exiger telles quelles.
Tout se joue à l'étape deux, car rien ne part tant que vous n'avez pas validé. L'interruption de l'étape quatre ne vous surprend pas non plus, puisque vous la planifiez ensemble à une heure où personne ne travaille et que le prestataire annonce sa durée à l'avance.
| Étape | Ce qui se passe | Ce que vous voyez |
|---|---|---|
| 1. Développement | Le prestataire construit la nouveauté et l'installe 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 | Vous fixez ensemble la maintenance, généralement vers minuit | Une date, une heure et une durée annoncées |
| 4. Coupure | Le prestataire applique la mise à jour au serveur principal | Une interruption courte et prévue |
| 5. Vérification | Le prestataire contrôle le service après la bascule | Une confirmation le lendemain matin |
Le jour où le serveur principal s'arrête
Ce jour-là, il faut savoir combien de temps le service reste indisponible, combien de données sont perdues et qui décide de basculer. Sans réponse préparée, on improvise 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. Il manque alors les saisies faites depuis la dernière copie, et leur volume dépend de la fréquence choisie au départ.
Une bascule que personne n'a jamais répétée prend toujours plus longtemps que prévu. Faites l'exercice une fois, à froid, sur une plage horaire choisie. Vous connaîtrez la durée réelle, chronomètre en main.
Ce qu'il faut exiger, quel que soit le prestataire
C'est le minimum à obtenir sur un système dont dépend votre activité.
- La fréquence de sauvegarde et l'endroit où le prestataire stocke les copies.
- 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.
- Le domaine, l'hébergement et la base de données ouverts à 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 ?
Demandez-vous combien de travail vous acceptez 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. Vérifiez ce point en premier dans une offre d'hébergement, car c'est aussi le plus vite oublié.
Combien de temps dure une maintenance planifiée ?
Quelques minutes pour corriger un défaut, jusqu'à une demi-heure pour une évolution qui modifie la structure des données. Vous connaissez la durée avant l'intervention, qui a lieu hors des heures de travail.
Peut-on refuser une mise à jour ?
Oui. Vous validez chaque version sur le serveur d'essai après l'avoir manipulée, et rien ne part sans cet accord. Seuls les correctifs de sécurité échappent à ce choix. Ils partent vite, donc le prestataire vous les annonce sans attendre votre 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é.