Besoin de conseil ?
Prendre rdv sur Teams
Objectif : savoir, sans jargon, ce qu’est un plan de reprise d’activité (PRA), comment définir des objectifs réalistes (RTO/RPO), comment tester (et prouver) que ça marche, et quoi écrire dans le contrat si vous passez par un prestataire d’infogérance.
À retenir : un PRA n’est pas un document. C’est une capacité à redémarrer dans un délai acceptable, avec une perte de données acceptable, sur la base de procédures déjà testées.
Un incident “majeur” (rançongiciel, panne serveur, mauvaise manipulation, incendie, coupure longue…) peut bloquer :
Le PRA répond à une question simple : “Combien de temps pouvons-nous être arrêtés, et combien de données pouvons-nous perdre ?” Puis il décrit comment redémarrer (procédures, responsabilités, ordre de reprise), et surtout il est testé.
Si vous avez une infogérance (ou si vous envisagez d’en prendre une), le PRA doit être géré comme un engagement de service : objectifs, tests, preuves, responsabilités, et mécanisme d’escalade. C’est ce que recommande la CNIL, mais aussi l’ANSSI.
Pour resituer : notre guide pilier sur l’infogérance explique ce qu’un contrat d’infogérance couvre (et ce qu’il ne couvre pas).
Une sauvegarde, c’est une copie de données (fichiers, bases, messagerie…) destinée à être restaurée. Une sauvegarde non testée, en pratique, est une hypothèse.
Le PRA organise la remise en route après incident : dans quel ordre, avec quelles dépendances, qui fait quoi, en combien de temps, et sur quelle infrastructure (sur site, cloud, site de secours…).
Le PCA vise à maintenir une activité minimale pendant l’incident (mode dégradé) : processus “papier”, poste de secours, accès alternatif, solution temporaire…
Traduction simple : le PCA limite la casse pendant la crise, le PRA remet l’informatique (et donc l’activité) sur pied après la crise. Les deux ne sont pas qu’une simple sauvegarde, comme l’explique la CNIL.
Vous n’avez pas besoin d’être informaticien pour décider vos objectifs. Vous avez juste besoin de raisonner par impact business.
Point important : RTO/RPO s’appliquent par application (messagerie, ERP, fichiers, téléphonie, site web…), pas “pour l’entreprise en général”.
Si vous avez besoin d’un repère pour cadrer un contrat et ses niveaux de service, voir aussi : SLA en infogérance : définition, pièges, risques.
Copiez ce tableau dans un document interne. C’est votre base de PRA (et votre base de discussion avec un prestataire).
Astuce pragmatique : commencez par 5 à 10 “services critiques”. Le reste viendra ensuite.
| Application / service | Impact si indisponible | RTO (max arrêt) | RPO (perte données) | Dépendances | Contournement (mode dégradé) | Responsable (qui décide) | Preuve attendue (test / rapport) |
|---|---|---|---|---|---|---|---|
| Messagerie / agenda | Commercial bloqué, coordination difficile | 8h | 1h | Identités, MFA, Internet | Webmail / comptes secours | Direction + référent interne | Rapport test de restauration |
| Fichiers partagés | Production / admin stoppée | 4h | 30 min | AD/VPN, stockage | Dossiers locaux prioritaires | Ops + direction | Test restauration + durée réelle |
| ERP / logiciel métier | Facturation et opérations arrêtées | 4h | 15 min | Base de données, licences | Procédure papier temporaire | Direction + métier | Test bascule + validation métier |
Important : “plus robuste” n’est pas “mieux” si ça ne correspond pas à vos impacts. Le bon niveau est celui qui tient vos RTO/RPO, avec des preuves.
Un PRA doit être testé. Sinon, au premier incident, vous découvrez :
En infogérance, vous devez pouvoir demander des preuves simples :
Si vous avez un doute sur ce que l’infogérance couvre exactement (inclus / hors périmètre), voir : ce que couvre une infogérance (catalogue RUN).
Un PRA “annoncé” n’a de valeur que s’il est contractualisé : objectifs, responsabilités, preuves, et ce qui se passe si ça ne tient pas.
À lire : SLA : pièges et bonnes pratiques.
RACI = une matrice simple pour éviter “je croyais que c’était vous” :
Si vous faites de la co-gestion : infogérance co-managée : RACI + SLA.
Si le prestataire héberge, administre ou accède à des données personnelles, vous avez un sujet RGPD : obligations de sous-traitance, clauses et preuves.
À lire : infogérance et RGPD (Article 28) : preuves attendues.
Le contrat doit couvrir : procédure d’escalade, communication interne/externe, responsabilités en cas d’incident.
À lire : responsabilités en cas d’incident.
Le PRA ne sert pas si, le jour où vous changez de prestataire, vous ne récupérez pas vite : comptes, documentation, exports, sauvegardes, clés, etc.
Voir : clause de réversibilité.
Pour une vue globale : contrat d’infogérance : ce qu’il doit inclure et les pièges fréquents en PME.
Si vous passez d’une maintenance “au coup par coup” à une infogérance, vous pouvez vous aider de cette checklist : maintenance → infogérance (checklist) et de ce comparatif : infogérance vs maintenance : différences.
Si vous voulez un PRA concret (RTO/RPO par application), testé, avec preuves et clauses contractuelles (SLA, responsabilités, RGPD, réversibilité), vous pouvez passer par notre page service :
Prestataire infogérant à Paris
Ça dépend de votre secteur et de vos obligations contractuelles, mais dans les faits, c’est surtout une décision de gestion des risques : combien coûte une journée d’arrêt, et à quelle fréquence vous pouvez vous le permettre ?
Souvent non. Sans test de restauration, vous ne savez pas si vos sauvegardes redémarrent vraiment vos applications, dans l’ordre, avec les bons accès. Et en cas de rançongiciel, des sauvegardes non isolées peuvent être chiffrées aussi.
Ça varie selon vos objectifs (RTO/RPO), vos applications, et le niveau de stratégie (1 à 4). Plus votre RTO est court, plus il faut d’organisation, d’automatisation ou d’infrastructure de secours.
Pour raisonner “retour sur investissement” : calculer la rentabilité d’une infogérance.
Après tout changement majeur, et au minimum une fois par an pour les éléments critiques, avec un rapport (durée réelle, écarts, actions). L’important est d’avoir une trace et d’améliorer.
Les deux. Le prestataire exécute et outille, mais l’entreprise doit décider des priorités (RTO/RPO) et valider les résultats. Sans décision “métier”, le PRA reste flou.
Au minimum : RTO/RPO par service critique, SLA de reprise, responsabilités (RACI), calendrier de tests, livrables de preuve, clauses RGPD si données personnelles, et réversibilité.
Référence : ce que doit inclure un contrat d’infogérance.
Pas automatiquement. Microsoft 365 améliore souvent la continuité sur la messagerie et les fichiers, mais votre PRA doit couvrir : identités/MFA, postes, accès, logiciel métier, réseau, fournisseurs, et procédures internes.
Pour aller plus loin : guide sur l’infogérance Microsoft 365.
Note : cet article donne un cadre opérationnel. Pour les clauses contractuelles, faites valider la rédaction finale par votre conseil (avocat / juriste), surtout si vous avez des obligations sectorielles.