PRA et SLA : les piliers de la résilience informatique des entreprises face aux sinistres majeurs

Comment garantir la continuité de votre activité lorsqu’un événement exceptionnel frappe votre entreprise ? Cyberattaque, panne électrique, erreur humaine, inondation… ou encore incendie de grande ampleur comme ceux qui touchent régulièrement la Gironde. La réponse repose sur deux notions essentielles : le PRA (Plan de Reprise d’Activité) et le SLA (Service Level Agreement).

Pourquoi parler du PRA et du SLA aujourd’hui ?

Ces dernières années, les entreprises ont pris conscience que leur système d’information est devenu le cœur de leur activité. Un arrêt prolongé des serveurs, de la messagerie Microsoft 365, de l’ERP ou de la téléphonie peut entraîner des pertes financières importantes, une dégradation de l’image de marque et parfois même l’arrêt complet de l’activité.

Les incendies ayant affecté la Gironde montrent que les risques ne sont pas uniquement numériques. En juillet 2026, plusieurs communes du littoral girondin ont dû faire face à des évacuations et à l’activation de dispositifs de crise face aux feux de forêt. Les entreprises implantées dans ces secteurs ont parfois vu leurs locaux devenir inaccessibles ou leurs activités fortement perturbées.

Dans ce contexte, disposer d’un PRA efficace et de SLA clairement définis avec ses prestataires devient un enjeu stratégique plutôt qu’une simple bonne pratique informatique.

Qu’est-ce qu’un PRA ?

Le Plan de Reprise d’Activité (PRA) est l’ensemble des procédures, moyens techniques et ressources humaines permettant de restaurer les systèmes et les données après un sinistre majeur. Son objectif est simple : remettre l’entreprise en état de fonctionnement le plus rapidement possible après une interruption critique.

Le PRA intervient lorsque la crise est déjà survenue :

• incendie des locaux ;
• ransomware ;
• panne électrique prolongée ;
• destruction d’un serveur ;
• erreur humaine provoquant une perte de données ;
• catastrophe naturelle ;
• vol ou sabotage d’équipements informatiques.

Un PRA bien construit permet d’éviter l’improvisation et de suivre un scénario documenté et testé à l’avance.

PRA et PCA : quelle différence ?

Les termes PRA et PCA sont souvent confondus.

Le PCA (Plan de Continuité d’Activité) vise à maintenir les activités critiques pendant la crise.

Le PRA intervient ensuite pour rétablir un fonctionnement normal après l’incident.

Exemple concret

Une PME de Bordeaux utilise Microsoft 365, un serveur de fichiers et une solution de téléphonie IP.

Lors d’un incendie dans le bâtiment :

• le PCA permet aux collaborateurs de continuer à travailler temporairement en télétravail ;
• le PRA permet de reconstruire l’infrastructure informatique, restaurer les données et remettre l’entreprise dans son état opérationnel normal.

Les deux démarches sont complémentaires.

Les objectifs principaux d’un PRA

Un PRA doit répondre à plusieurs objectifs essentiels :

1. Limiter l’arrêt de production

Chaque heure d’interruption peut représenter une perte de chiffre d’affaires importante.

2. Réduire la perte de données

Les sauvegardes doivent permettre de récupérer les informations les plus récentes possibles.

3. Assurer la survie de l’entreprise

Une interruption prolongée peut mettre en danger la pérennité de certaines PME.

4. Respecter les obligations réglementaires

Certaines réglementations imposent de pouvoir restaurer les données dans des délais appropriés.

5. Préserver l’image de marque

Les clients acceptent généralement un incident exceptionnel. Ils acceptent beaucoup moins un manque total de préparation.

Les indicateurs clés d’un PRA

Deux notions sont fondamentales.

Le RTO (Recovery Time Objective)

Le RTO correspond au délai maximal acceptable pour remettre un service en fonctionnement.

Par exemple :

• téléphonie : 2 heures ;
• messagerie : 4 heures ;
• ERP : 8 heures ;
• serveur de fichiers : 24 heures.

Plus le RTO est faible, plus l’infrastructure nécessaire est coûteuse

Le RPO (Recovery Point Objective)

Le RPO détermine la quantité de données que l’entreprise accepte de perdre.

Exemple :

• RPO de 24 heures : perte possible d’une journée de travail ;
• RPO de 1 heure : perte maximale d’une heure d’informations ;
• RPO de 15 minutes : quasiment aucune perte de données.

Le choix dépend des besoins métiers.

Les composantes essentielles d’un PRA

Sauvegardes fiables

Un PRA sans sauvegarde n’existe pas.

Les sauvegardes doivent être :

• automatisées ;
• surveillées ;
• historisées ;
• testées régulièrement ;
• stockées sur plusieurs supports.

La règle 3-2-1 reste une référence :

• 3 copies des données ;
• 2 supports différents ;
• 1 copie hors site.

Site secondaire ou cloud

L’hébergement dans le cloud permet aujourd’hui aux PME d’accéder à des niveaux de résilience autrefois réservés aux grands groupes.

Les solutions modernes permettent :

• la réplication de machines virtuelles ;
• la restauration rapide de serveurs ;
• l’hébergement multi-sites ;
• la continuité de la messagerie et de la collaboration.

Procédures documentées

Un PRA doit préciser :

• qui intervient ;
• dans quel ordre ;
• avec quels accès ;
• sur quelles infrastructures ;
• selon quelles priorités.

Le stress d’un sinistre est rarement compatible avec l’improvisation.

Tests réguliers

Un PRA jamais testé est un PRA théorique.

De nombreux plans échouent simplement parce que les équipes découvrent le jour du sinistre que certaines procédures ne fonctionnent plus ou que les sauvegardes ne sont pas exploitables.

Le SLA : l’engagement contractuel qui garantit les niveaux de service

Parallèlement au PRA, les entreprises doivent comprendre le rôle du SLA.

Définition du SLA

Le Service Level Agreement (SLA) est un engagement contractuel définissant les niveaux de service attendus d’un prestataire.

Il précise notamment :

• le temps de prise en charge ;
• le temps de résolution ;
• la disponibilité d’un service ;
• les modalités d’escalade ;
• les engagements de support.

Dans les contrats de services QCS ou d’hébergement, ces éléments permettent d’encadrer les attentes des clients et des prestataires. Un exemple de disponibilité peut atteindre 99,8 % sur certains services hébergés.

Les indicateurs d’un SLA

Disponibilité

Exemple :

• 99 % ;
• 99,5 % ;
• 99,9 % ;
• 99,99 %.

Chaque décimale supplémentaire représente un effort technique considérable.

Temps de prise en charge

Incident critique :

• prise en charge sous 1 heure.

Incident mineur :

• sous 4 ou 8 heures ouvrées.

Temps de résolution

Le SLA détermine le délai attendu pour résoudre l’incident.

Par exemple :

Criticité	Délai cible
Bloquant	4 heures
Majeur	8 heures
Standard	24 heures
Mineur	72 heures

Exemple : un incendie majeur en Gironde

Prenons un scénario réaliste.

Une PME située dans le Bassin d’Arcachon exploite :

• un serveur local ;
• une solution de téléphonie ;
• Microsoft 365 ;
• un logiciel de gestion.

Suite à un incendie de forêt provoquant l’évacuation de la zone :

• les salariés ne peuvent plus accéder aux locaux ;
• les infrastructures deviennent inaccessibles ;
• l’activité est interrompue.

C’est précisément le type de situation exceptionnelle observé lors des épisodes d’incendies ayant mobilisé les autorités en Gironde.

Avec un PRA moderne :

1. Les collaborateurs basculent en télétravail.
2. Les données sont restaurées depuis le cloud.
3. La téléphonie est redirigée.
4. Les services critiques redémarrent sur une infrastructure de secours.

Le SLA prévoit alors :

• prise en charge immédiate ;
• restauration des services prioritaires selon les RTO définis ;
• communication régulière auprès du client.

L’entreprise continue ainsi à servir ses clients malgré un sinistre majeur.

Les erreurs les plus fréquentes

Penser que Microsoft 365 remplace les sauvegardes

C’est faux.

La disponibilité du service ne remplace pas une stratégie de sauvegarde métier.

Ne jamais tester les restaurations

Une sauvegarde non restaurée n’est qu’une hypothèse.

Conserver toutes les sauvegardes sur le même site

En cas d’incendie ou de vol, tout peut disparaître simultanément.

Ne pas impliquer la direction

Le PRA n’est pas un projet informatique.

C’est un projet d’entreprise.

Conclusion

Les incendies, les cyberattaques et les sinistres exceptionnels rappellent une évidence : aucune entreprise n’est totalement à l’abri d’une interruption de son activité. Les événements récents en Gironde démontrent qu’un risque majeur peut survenir rapidement et impacter durablement une organisation.

Mettre en place un PRA solide et définir des SLA adaptés ne sont plus des options. Ce sont des investissements stratégiques qui garantissent la continuité de votre activité, la protection de vos données et la confiance de vos clients.

Pour les PME de Bordeaux et de Gironde, la résilience informatique est aujourd’hui un véritable facteur de compétitivité. Un sinistre peut être inévitable. Une interruption prolongée, en revanche, ne doit jamais être une fatalité.