Prévention

Plan de reprise d'activité (PRA) pour un site web : le guide TPE/PME

Mis à jour le 21 octobre 2026 · 9 minutes de lecture

Vous avez des sauvegardes. Très bien. Mais si votre hébergeur disparaît demain matin, savez-vous exactement qui restaure quoi, où, et en combien de temps ? Sans réponse écrite à cette question, une panne grave se transforme en plusieurs jours de chaos. Le plan de reprise d'activité (PRA) est le document qui évite ce scénario.

Qu'est-ce qu'un PRA, concrètement ?

Le plan de reprise d'activité est né dans les grandes entreprises, mais son principe s'applique très bien à un simple site vitrine ou une boutique en ligne : c'est un document qui répond, à l'avance et au calme, aux questions qu'on se pose toujours trop tard, en pleine panne et sous pression.

• Où se trouve la dernière sauvegarde utilisable, et depuis quand n'a-t-elle pas été testée ?
• Qui détient les accès à l'hébergeur, au bureau d'enregistrement du domaine et au CMS ?
• Quelle est la procédure exacte pour restaurer le site sur un nouveau serveur si besoin ?
• Qui prévient les clients, et avec quel message, pendant que la panne est en cours ?

Sans PRA, chacune de ces questions se pose pendant l'incident, au pire moment, souvent en cherchant un mot de passe oublié ou en attendant qu'un prestataire injoignable réponde au téléphone.

PRA, sauvegarde, post-mortem : ne pas confondre

Trois notions se ressemblent mais répondent à des moments différents de la vie d'un incident.

Une sauvegarde sans PRA est un coffre-fort dont personne ne connaît la combinaison : la donnée existe, mais personne ne sait précisément comment et où la réinjecter en urgence. À l'inverse, un PRA sans sauvegarde à jour ne sert à rien : les deux sont indissociables.

RTO et RPO : les deux chiffres qui pilotent tout

Avant d'écrire le moindre mot de votre PRA, répondez à deux questions. Ce sont elles qui détermineront le niveau d'investissement nécessaire.

RTO — Recovery Time Objective

Combien de temps pouvez-vous tolérer que le site soit hors ligne avant que cela ne devienne réellement grave pour votre activité ? Pour une boutique en ligne qui réalise l'essentiel de son chiffre d'affaires en continu, le RTO acceptable peut être de quelques heures. Pour un site vitrine institutionnel, une journée peut rester supportable.

RPO — Recovery Point Objective

Combien de données êtes-vous prêt à perdre ? Avec une sauvegarde quotidienne, vous acceptez de perdre jusqu'à 24 heures de commandes, d'articles de blog ou de messages de contact en cas de restauration. Si cette perte est inacceptable (commandes, paiements), il faut des sauvegardes plus fréquentes, voire en temps réel sur la base de données.

Ces deux objectifs ne sont pas théoriques : ils déterminent directement la fréquence de vos sauvegardes et le niveau de contrat d'hébergement qu'il vous faut réellement.

Les 6 éléments indispensables d'un PRA, même minimaliste

1. L'inventaire des accès

La cause numéro un des pannes qui s'éternisent n'est pas technique : c'est l'accès perdu ou bloqué chez une seule personne. Listez, dans un endroit sécurisé mais consultable par au moins deux personnes de confiance :

• Les identifiants de l'espace client hébergeur
• Les identifiants du bureau d'enregistrement du nom de domaine
• Les accès FTP/SFTP et à la base de données
• Les accès administrateur du CMS (WordPress, Shopify, etc.)
• Le contact direct de votre développeur ou agence, avec un numéro de secours

2. L'emplacement et la fraîcheur des sauvegardes

Notez où se trouve chaque sauvegarde (chez l'hébergeur, sur un stockage externe, chez un prestataire tiers), à quelle fréquence elle est générée, et surtout : la date du dernier test de restauration réel. Une sauvegarde jamais restaurée pour vérification est une sauvegarde dont la fiabilité est inconnue.

3. La procédure de restauration, étape par étape

Écrivez la marche à suivre comme si vous l'expliquiez à quelqu'un qui découvre votre hébergement pour la première fois : quel bouton cliquer, quel fichier importer, dans quel ordre restaurer le site puis la base de données. L'objectif est qu'une personne différente de celle qui gère habituellement le site puisse suivre la procédure sans improviser.

4. La chaîne de décision et de communication

Qui est prévenu en premier ? Qui décide de basculer sur une page de maintenance ? Qui rédige le message aux clients, et sur quels canaux (e-mail, réseaux sociaux, bannière sur le site) ? Une page de maintenance préparée à l'avance évite d'afficher une erreur brute pendant que vous travaillez à la résolution.

5. Les dépendances externes à vérifier

Un site n'est presque jamais isolé : module de paiement, service d'envoi d'e-mails, API tierce, CDN. Listez ces dépendances et la marche à suivre si l'une d'elles tombe en panne indépendamment de votre hébergeur.

6. Le scénario du pire : changer d'hébergeur en urgence

Que faire si votre hébergeur actuel est injoignable ou a perdu vos données ? Identifiez à l'avance un hébergeur de secours où vous pourriez redéployer rapidement votre site à partir d'une sauvegarde externe, et notez les étapes de repointage DNS nécessaires. Voir notre guide sur la propagation DNS pour anticiper ce délai.

Combien de temps garder le PRA à jour ?

Un PRA obsolète est presque aussi dangereux qu'une absence de PRA : il donne un faux sentiment de sécurité. Revoyez-le à chaque événement qui change l'un de ses éléments : changement d'hébergeur, nouveau prestataire, modification des mots de passe, ou simplement une fois par trimestre si rien n'a bougé. Profitez-en pour vérifier que votre contrat d'hébergement correspond toujours à vos objectifs de RTO et RPO.

Le PRA ne remplace pas la détection rapide

Un plan de reprise parfait, mais déclenché trois jours après le début de la panne parce que personne ne l'a remarquée, reste un échec. Le PRA répond à « que faire une fois que l'on sait ». Il doit donc toujours être couplé à une détection automatique qui raccourcit au maximum le délai entre l'incident et son déclenchement.

Questions fréquentes