Pour une application web de PME, le minimum tient en trois règles. D'abord, une sauvegarde automatique et régulière de la base de données et des fichiers. Ensuite, au moins une copie stockée ailleurs que chez l'hébergeur principal. Enfin, un test de restauration fait régulièrement. Sans le troisième point, les deux premiers ne sont qu'une promesse.
La question de la sauvegarde d'une application web en PME se pose rarement avant le premier incident : une mise à jour qui efface des données, un serveur qui ne redémarre pas, un rançongiciel, ou simplement un collaborateur qui supprime la mauvaise ligne. À ce moment-là, une seule question compte : « à quelle date peut-on revenir, et en combien de temps ? »
Cet article s'appuie sur le guide Sauvegarde des systèmes d'information – Les fondamentaux publié par l'ANSSI (l'Agence nationale de la sécurité des systèmes d'information). Il le traduit pour une PME qui a une ou quelques applications, et pas de service informatique.
Sauvegarde d'une application web en PME : que faut-il protéger ?
On pense spontanément à la base de données. C'est le cœur, mais ce n'est pas tout. Une application web se compose en réalité de plusieurs éléments qu'il faut pouvoir reconstruire :
- La base de données : clients, commandes, contenus, tout ce que l'application enregistre.
- Les fichiers déposés par les utilisateurs ou par vous : documents, photos, factures PDF. Ils sont souvent stockés à part, et facilement oubliés dans les sauvegardes.
- La configuration : les paramètres de production, les clés d'accès aux services tiers, la configuration du serveur. L'ANSSI insiste sur l'importance de sauvegarder les configurations des applications métier, pas seulement leurs données.
- Le code source, dans un dépôt Git qui vous appartient. Ce n'est pas une sauvegarde au sens strict, mais sans lui, les données seules ne servent pas à grand-chose.
Un bon test mental : si votre serveur disparaissait ce soir, que vous manquerait-il pour remettre l'application en ligne ailleurs demain ? Tout ce qui vous vient à l'esprit doit figurer dans la sauvegarde.
Combien pouvez-vous perdre, combien de temps pouvez-vous attendre ?
Avant de choisir un outil, il faut répondre à deux questions, que l'ANSSI désigne par deux sigles :
- La perte de données maximale admissible (PDMA) : combien d'heures de travail pouvez-vous accepter de perdre ? Si l'application enregistre des commandes toute la journée, perdre une journée peut signifier perdre des ventes et devoir recontacter des clients.
- La durée maximale d'interruption admissible (DMIA) : combien de temps l'application peut-elle rester indisponible avant que cela devienne un vrai problème pour votre activité ?
Ces deux réponses sont des décisions de dirigeant, pas de technicien. Ce sont elles qui fixent la fréquence des sauvegardes et le dispositif de reprise. L'ANSSI précise un point important : si votre PDMA est inférieure à 24 heures, la sauvegarde seule ne suffit plus. Il faut alors envisager d'autres solutions, comme la réplication, c'est-à-dire une copie des données tenue à jour en continu sur un autre serveur.
Il faut aussi décider combien de temps garder les sauvegardes. L'ANSSI donne un exemple de répartition : 15 jours de sauvegardes journalières, un an de sauvegardes mensuelles, cinq ans de sauvegardes annuelles. Garder un historique est utile, car une corruption de données ou une intrusion peut n'être découverte que des semaines plus tard.
La règle 3-2-1 expliquée simplement
L'ANSSI recommande d'appliquer la règle « 3-2-1 » : trois copies distinctes des données (les données en production plus deux sauvegardes), stockées sur des supports différents, dont une hors ligne.
Pour une application web, cela donne :
- Copie n°1 : les données de production, sur votre serveur.
- Copie n°2 : une sauvegarde automatique sur un stockage distinct du serveur.
- Copie n°3 : une sauvegarde isolée, hors de portée de votre infrastructure habituelle.
Pourquoi cette troisième copie ? Parce que, comme le souligne l'ANSSI, un attaquant tente souvent de chiffrer ou d'effacer les sauvegardes pour augmenter ses chances d'obtenir une rançon. Une sauvegarde accessible avec les mêmes identifiants que le serveur peut disparaître en même temps que lui. L'ANSSI juge donc indispensable une sauvegarde hors ligne, ou au moins hors site en ligne sous certaines conditions, même si elle est moins fréquente que les sauvegardes régulières.
Un point souvent mal compris concerne les « snapshots » (images instantanées du serveur) proposés par beaucoup d'hébergeurs. Ils sont pratiques, mais s'ils sont stockés chez le même hébergeur, dans le même compte, ils ne constituent pas à eux seuls une copie indépendante. Si le compte est piraté ou suspendu, ils disparaissent avec lui.
Une sauvegarde non testée n'est pas une sauvegarde
Les administrateurs système répètent cette phrase, souvent après l'avoir apprise à leurs dépens. L'ANSSI le formule ainsi : les sauvegardes doivent être testées régulièrement, et une procédure de restauration doit être rédigée et régulièrement mise en œuvre.
Concrètement, tester une sauvegarde, c'est :
- prendre une sauvegarde récente ;
- la restaurer sur un environnement séparé, jamais par-dessus la production ;
- vérifier que l'application démarre et que les données sont complètes et cohérentes ;
- noter le temps nécessaire, et le comparer à votre durée d'interruption acceptable.
C'est pendant ce test qu'on découvre les oublis : un dossier de fichiers non sauvegardé, une clé de chiffrement que personne ne retrouve, une étape manuelle jamais documentée. Mieux vaut les découvrir un mardi calme que le jour d'une panne.
L'ANSSI recommande aussi de contrôler systématiquement les sauvegardes pour repérer un comportement inhabituel, comme un volume de données incohérent. Une sauvegarde qui passe de plusieurs gigaoctets à quelques kilooctets du jour au lendemain doit déclencher une alerte, pas un haussement d'épaules.
Applications créées avec l'IA : qui sauvegarde quoi ?
Si votre application a été construite avec Lovable, Replit ou Bolt, ou avec un agent comme Claude Code ou Cursor, la question se pose de façon particulière.
Sur les plateformes tout-en-un, l'hébergement et la base de données sont souvent fournis avec l'outil. C'est confortable, mais il faut savoir ce que prévoit exactement la plateforme : quelles sauvegardes, conservées combien de temps, avec quelle formule d'abonnement, et pouvez-vous exporter vos données vous-même ? Vérifiez-le dans la documentation de chaque service plutôt que de le supposer. Et gardez à l'esprit qu'une sauvegarde chez le même fournisseur reste une copie au même endroit.
Avec un agent qui travaille sur votre code, un risque s'ajoute : l'agent exécute des commandes. S'il a accès à la base de données de production, une instruction mal comprise peut supprimer ou écraser des données. La documentation de Claude Code rappelle d'ailleurs que l'utilisateur reste responsable de relire les commandes proposées avant de les approuver. La parade est simple : l'agent travaille sur une copie de développement, jamais directement sur la production, et les sauvegardes sont en place avant qu'il ne commence.
Dans les deux cas, le principe est le même : la sauvegarde ne doit pas dépendre du seul outil qui a construit ou qui héberge l'application. Elle fait partie du socle technique couvert par l'offre Autopilote. Pour 100 € par mois, l'hébergement, les sauvegardes, la surveillance et la mise en ligne automatisée sont pris en charge, sans que vous ayez à y penser.
Questions fréquentes
Mon hébergeur fait des sauvegardes, est-ce suffisant ?
C'est un bon début, mais demandez-lui à quelle fréquence elles sont faites, combien de temps elles sont gardées, où elles sont stockées et comment se passe une restauration. Si toutes les copies sont chez lui, ajoutez-en une ailleurs.
À quelle fréquence sauvegarder une application web ?
Tout dépend de la perte de données que vous jugez acceptable. Pour une application qui enregistre des données chaque jour, une sauvegarde quotidienne est un minimum raisonnable. Si perdre une journée est inacceptable, il faut aller plus loin.
Faut-il chiffrer les sauvegardes ?
Oui, dès qu'elles contiennent des données personnelles ou sensibles et qu'elles quittent votre serveur. L'ANSSI recommande que les sauvegardes soient aussi bien protégées que les données en production. Pensez aussi à conserver la clé de chiffrement en lieu sûr : sans elle, la sauvegarde est inutilisable.
Vous ne savez pas aujourd'hui où sont les sauvegardes de votre application, ni quand elles ont été restaurées pour la dernière fois ? C'est une bonne raison d'en parler. Un échange suffit en général pour faire le point sur ce qui existe et ce qui manque.