Sauvegarde de site : qui s'en occupe ?

Qui est responsable de la sauvegarde de votre site ?

Juridiquement et en pratique, c'est vous, en tant que propriétaire du site, sauf si un contrat confie clairement cette tâche à quelqu'un d'autre. Beaucoup d'entreprises pensent que l'hébergeur ou le prestataire s'en charge, sans l'avoir jamais vérifié.

Trois acteurs peuvent intervenir, avec des rôles différents :

• L'hébergeur fait souvent des copies de ses serveurs, mais elles servent d'abord à le protéger contre ses propres pannes. Leur fréquence, leur durée de conservation et la possibilité de vous les restituer varient beaucoup selon les offres.
• Le prestataire peut inclure des sauvegardes dans un contrat de maintenance. Si ce n'est pas écrit, ne supposez pas qu'il le fait.
• Vous-même, en gardant une copie indépendante, notamment de vos contenus et de vos données clients.

La première étape consiste donc à poser la question par écrit à votre hébergeur et à votre prestataire, et à noter les réponses. C'est un point à intégrer dans les questions à poser à votre prestataire avant de signer.

Que faut-il sauvegarder exactement ?

Un site n'est pas un bloc unique : c'est un ensemble d'éléments qui ne sont pas toujours stockés au même endroit. Une sauvegarde incomplète peut se révéler inutile le jour où l'on en a besoin.

1. Le code : les fichiers qui font fonctionner le site et définissent son apparence.
2. La base de données, si le site en a une : c'est là que se trouvent souvent les textes, les articles, les commandes, les comptes clients et les réglages.
3. Les médias : photos, vidéos, documents PDF déposés sur le site.
4. Les données collectées par les formulaires, si elles sont stockées sur le site plutôt qu'envoyées par e-mail.
5. La configuration : réglages du nom de domaine, variables techniques, accès aux services connectés (paiement, envoi d'e-mails).

Un site WordPress, par exemple, a besoin à la fois de ses fichiers et de sa base de données : sauvegarder l'un sans l'autre ne permet pas de tout remettre en état. Un site Next.js dont le code est versionné, c'est-à-dire enregistré avec tout son historique de modifications dans un outil comme Git, a déjà une bonne partie de sa sauvegarde assurée par ce fonctionnement, mais les médias et données éventuellement stockés ailleurs doivent être traités à part.

À quelle fréquence sauvegarder ?

La fréquence dépend de la quantité de travail que vous accepteriez de perdre. La bonne question n'est pas « combien de sauvegardes », mais « si je devais revenir à la dernière copie, qu'est-ce que je perdrais ? ».

• Un site vitrine modifié quelques fois par an peut se contenter d'une sauvegarde après chaque modification, complétée par une sauvegarde automatique régulière.
• Un site avec un blog actif gagne à être sauvegardé au moins chaque semaine, ou après chaque publication.
• Une boutique en ligne ou un site de réservation reçoit des données en continu : une sauvegarde quotidienne est un minimum, et certaines activités justifient davantage.

Pensez aussi à la durée de conservation. Garder seulement la dernière copie est risqué : si un piratage passe inaperçu pendant deux semaines, les sauvegardes récentes sont elles aussi infectées. Conserver plusieurs versions, sur des périodes différentes, permet de remonter avant le problème.

Où stocker les sauvegardes ?

Jamais uniquement sur le même serveur que le site. Si le serveur tombe en panne, est piraté ou si le compte d'hébergement est fermé, les sauvegardes disparaissent avec lui.

Les professionnels de l'informatique citent souvent la règle dite 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site. Pour une TPE, cela peut se traduire simplement : la version en ligne, une sauvegarde automatique chez l'hébergeur ou le prestataire, et une copie indépendante dans un espace de stockage en ligne distinct, auquel vous avez accès.

Vérifiez aussi qui peut accéder aux sauvegardes. Elles contiennent parfois des données personnelles, comme des coordonnées de clients, et doivent être protégées au même titre que le site. C'est un point à intégrer dans votre démarche liée au RGPD.

Comment savoir si une sauvegarde fonctionne vraiment ?

En la testant. Une sauvegarde qui n'a jamais été restaurée est une promesse, pas une garantie. Il arrive qu'on découvre le jour de la panne que les copies étaient vides, incomplètes ou impossibles à relire.

Un test de restauration consiste à remettre en place une sauvegarde sur un environnement de test, c'est-à-dire une copie du site non visible du public, et à vérifier que tout fonctionne : pages, images, formulaires, commandes. Il n'est pas nécessaire de le faire chaque semaine, mais au moins une fois, puis régulièrement, par exemple une fois par an ou après un changement technique important.

Demandez aussi combien de temps prendrait une restauration réelle, et qui la ferait. Pour une boutique en ligne, savoir que le site peut revenir en quelques heures plutôt qu'en plusieurs jours change beaucoup de choses.

Gardez enfin une fiche simple, rangée avec vos documents importants, qui répond à quatre questions : où se trouvent les sauvegardes, qui peut y accéder, comment lancer une restauration et qui appeler en cas de problème. Le jour où le site tombe, souvent au pire moment, cette fiche évite de chercher dans de vieux e-mails les identifiants d'un compte oublié. Mettez-la à jour à chaque changement de prestataire ou d'hébergeur.

Dans quelles situations la sauvegarde vous sauve-t-elle ?

La sauvegarde sert dans des situations très concrètes, bien plus fréquentes qu'une panne de centre de données. En voici quelques-unes, rencontrées régulièrement par les petites entreprises.

• Une erreur de manipulation : une page supprimée par mégarde, un article écrasé, un réglage modifié qui casse l'affichage.
• Une mise à jour ratée, en particulier sur un CMS, qui rend le site inaccessible.
• Un piratage, après lequel il faut revenir à une version saine, puis corriger la faille. L'article sécurité d'un site présente les bases pour limiter ce risque.
• Un changement de prestataire difficile, quand l'ancien ne répond plus : avoir sa propre copie évite de repartir de zéro.
• La fermeture d'un compte chez un hébergeur ou une plateforme, pour un impayé ou une erreur administrative.

Dans chacun de ces cas, la différence entre quelques heures de désagrément et plusieurs semaines de reconstruction tient à l'existence d'une copie récente et utilisable.

Comment cela se passe-t-il pour un site réalisé par OSEOO ?

Nos sites sont construits avec Next.js et hébergés sur Vercel, et le code, le nom de domaine et les accès appartiennent au client. Vous pouvez donc toujours disposer de votre propre copie du code. Les formules Express et Standard incluent une période de support, et les projets sur mesure sont suivis par abonnement : les modalités sont présentées sur la page tarifs.