Plan de reprise d'activité (PRA) : définition et exemple

Qu'est-ce qu'un plan de reprise d'activité ?

Un plan de reprise d'activité, c'est l'ensemble des « procédures » techniques et humaines qui permettent de redémarrer les systèmes d'une entreprise après un arrêt brutal. Qui fait quoi. Dans quel ordre, avec quels outils. Pour une PME, le périmètre couvre le site web, la boutique en ligne, le CRM, la messagerie et les logiciels métier.

Empêcher la panne ? Ce n'est pas son rôle. Le PRA part du principe qu'elle arrivera un jour, et il prépare le retour à la normale. Voilà ce qui le distingue des mesures de sécurité, dont le but est de réduire le risque en amont.

Le terme en anglais et ses cousins

En anglais, on parle de disaster recovery plan, souvent abrégé DRP. Vous croiserez aussi le business continuity plan, l'équivalent de notre plan de continuité d'activité (PCA). La nuance compte. Le PCA vise à continuer à travailler pendant la crise ; le PRA, lui, organise le redémarrage une fois l'interruption subie.

À quoi sert un PRA pour un site qui rapporte

Chaque heure hors ligne coûte. Surtout quand votre site génère des leads ou des ventes. L'indisponibilité bloque aussi vos campagnes payantes, et vous continuez de payer des clics vers une page qui ne répond plus. Le PRA limite cet impact en rendant la remise en route rapide et, surtout, prévisible.

Votre réputation en dépend, votre trafic naturel aussi. Un site qui renvoie une erreur 500 pendant plusieurs jours peut perdre des positions durement gagnées. Reste la protection des données de vos clients : en cas de fuite, elle pèse lourd sur le plan légal.

• Réduire la durée d'arrêt après une panne, une erreur humaine ou une cyberattaque.
• Limiter la perte de données : commandes, contacts, contenus publiés.
• Savoir quoi faire dans les premières minutes, sans improviser.
• Rassurer vos clients et vos partenaires sur la solidité de votre service.

Comment fonctionne un plan de reprise d'activité informatique

Tout commence par un inventaire. Listez vos outils, repérez les systèmes critiques, puis classez-les selon leur importance réelle pour l'entreprise. Un tunnel de commande passe avant un blog. Un ERP avant un intranet.

RTO et RPO : deux objectifs à fixer

Le RTO, pour Recovery Time Objective, correspond à la durée maximale d'arrêt que vous acceptez. Le RPO, pour Recovery Point Objective, mesure la quantité de données que vous consentez à perdre, exprimée en temps. Prenons un RPO de vingt-quatre heures : une sauvegarde par jour suffit. Proche de zéro ? Il faut une réplication continue.

Ces deux chiffres guident tout le reste. Plus ils sont bas, plus la solution devient complexe et chère. Je le dis franchement : c'est une décision de dirigeant, pas seulement d'informaticien, parce qu'elle dépend de ce que vous coûte vraiment une journée d'arrêt.

Sauvegardes, réplication et restauration

Au cœur technique du PRA, on trouve les sauvegardes. Automatiques, chiffrées, stockées hors du serveur principal, idéalement chez un autre fournisseur cloud ou dans une autre région : voilà le minimum. Une copie posée sur la même machine disparaît avec elle.

La réplication va plus loin. Elle copie les données en temps quasi réel vers un second environnement prêt à prendre le relais. Vous êtes sous WordPress ? Notre guide pour sauvegarder un site WordPress détaille les bonnes pratiques. Ne négligez pas non plus le choix de l'hébergement web, car tous les hébergeurs n'offrent pas les mêmes garanties de restauration.

Des procédures documentées et testées

Restaurer la base, redéployer le code, basculer le DNS, vérifier les paiements : le PRA décrit les étapes nécessaires pour relancer chaque brique. Documentez-les pas à pas. Rendez-les accessibles hors du système en panne, et faites en sorte qu'au moins deux personnes les connaissent. Ajoutez enfin les contacts utiles, de l'hébergeur au registrar en passant par le prestataire et l'assureur.

Exemple de plan de reprise d'activité après un sinistre

Imaginez une PME qui vend en ligne et dont le serveur vient d'être chiffré par un rançongiciel. Sans plan, la panique s'installe et chacun tente quelque chose dans son coin. Avec un PRA ? Le scénario est déjà écrit.

Incendie de datacenter, mise à jour qui casse tout, suppression accidentelle : le même schéma s'applique. Si des données personnelles ont fuité, vous devrez aussi gérer la violation de données auprès de la CNIL. Pour le nettoyage, notre guide sur le site piraté complète ce scénario.

Mettre en place un PRA sans tomber dans les pièges courants

Pas besoin d'un gros budget. Il faut de la rigueur. La plupart des échecs viennent moins de la technique que de l'organisation, et voici les erreurs que nous croisons le plus souvent chez les TPE et PME.

• Ne jamais tester la restauration : une sauvegarde jamais relue peut se révéler corrompue ou incomplète.
• Garder toutes les copies au même endroit, chez le même hébergeur, avec les mêmes accès.
• Oublier les dépendances : nom de domaine, certificats, clés d'API, comptes de paiement.
• Écrire un plan que seul le prestataire comprend, ou stocké sur le serveur qui vient de tomber.
• Ne pas le mettre à jour après une refonte ou l'ajout d'un nouvel outil.

Mon conseil : testez au moins une fois par an, et après chaque changement important. L'exercice le plus simple consiste à restaurer le site sur un environnement de test en chronométrant l'opération. Le temps dépasse votre RTO ? Vous savez où agir. Ce travail trouve naturellement sa place dans un contrat de maintenance de site web.

Questions fréquentes