PRA informatique BPO : définir les objectifs de reprise

Un plan de reprise ne protège réellement une activité que s’il fixe des objectifs mesurables. Dans un environnement externalisé, le PRA BPO précise notamment le délai acceptable avant reprise, la perte de données tolérée, les systèmes prioritaires et les moyens nécessaires au redémarrage. Ainsi, le donneur d’ordre peut vérifier concrètement la capacité de son prestataire à reprendre l’activité après un incident.

Qu’est-ce qu’un PRA BPO ?

Un PRA BPO organise la reprise des systèmes nécessaires à une activité externalisée après une panne, une cyberattaque, un sinistre physique ou une indisponibilité majeure. Il couvre notamment les applications, les données, les accès et les équipements indispensables aux équipes.

En revanche, le plan de continuité d’activité poursuit un objectif plus large. Le PCA cherche à maintenir les opérations critiques pendant la perturbation. Le PRA organise leur redémarrage. Ainsi, les deux dispositifs se complètent.

Pourquoi RTO et RPO structurent-ils le PRA BPO ?

Deux indicateurs donnent au PRA des objectifs précis : le RTO et le RPO. D’une part, le RTO fixe le délai cible avant le retour du service. D’autre part, le RPO précise la quantité maximale de données que l’entreprise accepte de perdre.

Indicateur	Définition	Question métier
RTO	Recovery Time Objective	Dans quel délai faut-il rétablir le service ?
RPO	Recovery Point Objective	Quelle perte de données l’activité peut-elle tolérer ?

Autrement dit, le RTO mesure un délai et le RPO mesure une perte acceptable. Toutefois, leur définition ne relève pas uniquement de l’équipe informatique. Les responsables métier doivent aussi participer aux arbitrages, car eux seuls connaissent les conséquences concrètes d’une interruption.

Comment définir un RTO réaliste ?

D’abord, l’entreprise doit mesurer l’impact d’un arrêt du service. Plus les conséquences apparaissent rapidement, plus le RTO doit rester court.

Pour cela, plusieurs questions permettent de cadrer le besoin :

• combien de temps l’activité peut-elle s’arrêter ?
• quels engagements clients risquent de subir un impact ?
• quelles opérations peuvent attendre ?
• quelles tâches peuvent continuer autrement ?
• quels systèmes doivent redémarrer en premier ?

Ensuite, le donneur d’ordre et le prestataire doivent confronter cet objectif aux moyens nécessaires. En effet, réduire fortement le délai de reprise demande généralement davantage de redondance, de ressources techniques et de tests. Par conséquent, le RTO doit refléter le besoin métier réel plutôt qu’un objectif arbitrairement très court.

Comment définir un RPO adapté à l’activité ?

Le RPO répond à une autre question : combien de données récentes l’entreprise peut-elle perdre sans conséquence inacceptable ? Ainsi, un processus qui enregistre des opérations en continu exige souvent une protection plus fréquente qu’un système consulté occasionnellement.

Plusieurs critères influencent ce choix :

• le volume de données créé chaque heure ;
• la fréquence des modifications ;
• la possibilité de reconstituer les opérations perdues ;
• la sensibilité des données ;
• l’impact métier d’une restauration incomplète.

De plus, la fréquence des sauvegardes doit rester cohérente avec le RPO. Cependant, sauvegarder fréquemment ne suffit pas. L’entreprise doit aussi vérifier que les données restent exploitables et que les équipes savent réellement les restaurer.

Comment hiérarchiser les systèmes critiques ?

Tous les systèmes n’ont pas la même importance. Par conséquent, le PRA BPO doit attribuer une priorité de reprise à chaque application selon son impact sur l’activité.

Criticité	Impact	Priorité
Critique	Bloque directement une activité essentielle	Reprise prioritaire
Importante	Dégrade fortement l’activité	Deuxième niveau
Secondaire	Impact limité à court terme	Après les services essentiels

Ainsi, l’entreprise concentre ses investissements sur les fonctions réellement sensibles. Elle évite également d’imposer des exigences excessives à des outils secondaires.

Pourquoi cartographier les dépendances techniques ?

Une application dépend rarement d’un seul composant. Par exemple, elle peut utiliser une base de données, une connexion internet, un système d’authentification ou un service cloud.

Par conséquent, un PRA qui analyse uniquement les applications visibles risque d’oublier un maillon indispensable. La cartographie doit donc identifier :

• les applications critiques ;
• les bases de données ;
• les systèmes d’authentification ;
• les connexions internet et télécom ;
• les outils de téléphonie ;
• les accès distants ;
• les fournisseurs techniques ;
• les personnes habilitées à intervenir.

Grâce à cette cartographie, l’équipe connaît l’ordre réel de redémarrage. Ainsi, elle peut restaurer d’abord les composants dont dépendent plusieurs systèmes.

Les postes de travail doivent-ils entrer dans le PRA ?

Oui. Restaurer les serveurs ne suffit pas si les collaborateurs ne peuvent pas accéder aux outils. Dans un centre de contact, les postes, les connexions sécurisées, la téléphonie et les accès distants jouent donc un rôle essentiel.

De plus, une solution de travail depuis un autre site ou à distance doit fonctionner avant l’incident. Ainsi, les équipes évitent d’improviser des accès ou des configurations au moment où chaque minute compte.

Comment intégrer les sauvegardes au PRA BPO ?

Une sauvegarde apporte une réelle protection uniquement si l’équipe sait la restaurer. Le PRA doit donc préciser quelles données protéger, à quelle fréquence les copier et comment contrôler leur intégrité.

Il faut notamment vérifier :

• la fréquence des sauvegardes ;
• leur cohérence avec le RPO ;
• leur séparation avec la production ;
• les droits nécessaires à la restauration ;
• leur intégrité ;
• les résultats des derniers tests.

En cas de cyberattaque, une étape supplémentaire devient essentielle. Avant toute reprise, l’équipe doit vérifier l’environnement cible et les données restaurées. Sinon, elle risque de reproduire le problème initial.

Comment tester concrètement un PRA BPO ?

Un PRA jamais testé reste une hypothèse. C’est pourquoi les exercices doivent vérifier progressivement les procédures, les personnes et les outils.

Le test documentaire

D’abord, les équipes parcourent le scénario étape par étape. Elles vérifient les contacts, les responsabilités, les dépendances et les procédures. Ainsi, elles repèrent rapidement les informations obsolètes ou les incohérences.

Le test de restauration

Ensuite, l’équipe restaure une sauvegarde ou un composant dans un environnement contrôlé. Ce test confirme que les données restent exploitables et que la procédure technique fonctionne réellement.

Le test de bascule partielle

Puis, l’équipe active une partie du dispositif de secours. Elle contrôle notamment les accès, les outils, les connexions et les dépendances entre systèmes.

Le test étendu

Enfin, un exercice plus large peut simuler l’indisponibilité d’une infrastructure ou d’un site. Ce scénario demande davantage de préparation. Cependant, il permet de tester la coordination globale du dispositif.

Quels résultats mesurer pendant un test ?

Un test ne doit pas seulement confirmer que les systèmes redémarrent. Il doit aussi comparer les performances réelles avec les objectifs annoncés.

Ainsi, le compte rendu peut mesurer :

• le délai avant déclenchement du PRA ;
• le temps réel de restauration ;
• la quantité de données récupérée ;
• les erreurs rencontrées ;
• les dépendances oubliées ;
• les interventions manuelles ;
• la disponibilité des responsables ;
• les corrections à apporter.

Par conséquent, un RTO de quatre heures n’a de valeur que si les tests montrent que l’organisation peut réellement reprendre dans ce délai.

À quelle fréquence tester un PRA BPO ?

La fréquence dépend de la criticité de l’activité et du rythme d’évolution de l’infrastructure. Toutefois, l’entreprise doit organiser des tests réguliers et relancer une vérification après tout changement majeur.

Par exemple, un nouveau test devient pertinent après :

• une migration d’infrastructure ;
• l’ajout d’une application critique ;
• un changement de fournisseur essentiel ;
• une évolution importante des volumes ;
• une modification des accès ;
• un incident ayant révélé une faiblesse.

Ainsi, le PRA évolue avec l’organisation. Sans cette mise à jour, les procédures risquent de ne plus correspondre aux systèmes réellement utilisés.

Qui doit valider les objectifs de reprise ?

Le prestataire apporte son expertise technique. Cependant, le donneur d’ordre doit valider les priorités métier.

Il doit notamment se prononcer sur :

• les processus critiques ;
• les RTO ;
• les RPO ;
• l’ordre de reprise ;
• les niveaux de service attendus ;
• les modalités de communication ;
• les résultats des tests majeurs.

De cette manière, le prestataire dimensionne le dispositif à partir d’objectifs validés plutôt qu’à partir d’hypothèses techniques.

Quels documents doit contenir un PRA BPO ?

Le PRA doit rester facilement exploitable pendant une situation dégradée. Par conséquent, il doit réunir des documents courts, précis et régulièrement actualisés.

Le dossier peut notamment contenir :

• la cartographie des systèmes ;
• la classification par criticité ;
• les RTO et RPO ;
• les dépendances techniques ;
• les procédures de restauration ;
• les procédures de bascule ;
• les responsabilités ;
• les coordonnées des intervenants ;
• les résultats des tests ;
• le plan d’actions correctives.

De plus, les responsables doivent pouvoir consulter ces informations même lorsque l’infrastructure habituelle rencontre une panne.

Quel rôle joue une organisation multi-sites ?

Une implantation sur plusieurs sites peut renforcer la continuité lorsqu’un incident reste localisé. Cependant, la présence de plusieurs implantations ne constitue pas automatiquement un PRA.

Pour qu’un autre site prenne réellement le relais, l’organisation doit prévoir les accès, les outils, les compétences et les capacités disponibles. Elle doit également tester la bascule.

ProContact dispose d’équipes à l’Île Maurice, à Madagascar et à Rodrigues. Ainsi, cette organisation multi-sites peut contribuer à la résilience d’une opération lorsque le dispositif prévu avec le donneur d’ordre utilise effectivement cette capacité.

Comment évaluer le PRA d’un prestataire BPO ?

Avant de confier une activité critique à un prestataire, le donneur d’ordre doit demander des éléments concrets. Une simple mention « PRA disponible » dans une proposition commerciale ne permet pas d’évaluer la capacité réelle de reprise.

Il peut notamment poser les questions suivantes :

• quels RTO proposez-vous pour mon activité ?
• quel RPO prévoyez-vous ?
• quels systèmes considérez-vous comme critiques ?
• quelles dépendances avez-vous identifiées ?
• quand avez-vous testé le dispositif pour la dernière fois ?
• quels écarts le test a-t-il révélés ?
• quelles corrections avez-vous ensuite appliquées ?
• quel scénario prévoyez-vous si un site devient indisponible ?

Ainsi, le client évalue une capacité opérationnelle plutôt qu’une simple documentation.

Comment ProContact aborde-t-il la continuité des opérations ?

Chez ProContact, les besoins de continuité dépendent du périmètre confié, des outils utilisés et de la criticité de l’activité. Par exemple, une opération de téléprospection ne présente pas nécessairement les mêmes contraintes qu’un service client ou qu’un back-office métier sensible.

Par conséquent, la préparation du projet doit intégrer les besoins de reprise dès le démarrage. Le client et ProContact peuvent alors préciser les responsabilités, les priorités et les dispositifs nécessaires.

Cette démarche complète plus largement notre approche de la continuité d’activité et du PRA.

PRA BPO : quels points vérifier en priorité ?

Un PRA BPO efficace repose sur quelques principes essentiels. D’abord, l’entreprise identifie les activités critiques. Ensuite, elle fixe des RTO et RPO réalistes. Puis, elle cartographie les dépendances et protège les données. Enfin, elle teste régulièrement le dispositif.

Ainsi, la qualité d’un PRA ne dépend pas du nombre de pages du document. Elle dépend surtout de la capacité réelle des équipes à restaurer les systèmes et à reprendre l’activité dans les délais convenus.

Évaluer la continuité de votre projet BPO

FAQ sur le PRA BPO

Qu’est-ce qu’un PRA BPO ?

Un PRA BPO organise la reprise des systèmes, des données et des accès nécessaires à une activité externalisée après un incident majeur.

Quelle différence existe entre PRA et PCA ?

Le PCA vise à maintenir les activités pendant une perturbation. En revanche, le PRA organise leur redémarrage après l’incident.

Qu’est-ce que le RTO ?

Le RTO fixe le délai cible dans lequel les équipes doivent rétablir un système ou un service après une interruption.

Qu’est-ce que le RPO ?

Le RPO indique la quantité maximale de données récentes que l’activité peut perdre après un incident.

Le RPO correspond-il à la fréquence des sauvegardes ?

Non. La fréquence des sauvegardes contribue à respecter le RPO. Cependant, le RPO représente avant tout un objectif métier de perte maximale acceptable.

Faut-il définir le même RTO pour tous les systèmes ?

Non. Chaque système doit recevoir un objectif adapté à sa criticité et aux conséquences réelles de son indisponibilité.

Pourquoi faut-il tester un PRA ?

Les tests permettent de vérifier que les systèmes, les sauvegardes, les accès et les équipes atteignent réellement les objectifs de reprise prévus.

Une organisation multi-sites suffit-elle pour disposer d’un PRA ?

Non. Plusieurs sites renforcent potentiellement la résilience. Cependant, l’organisation doit aussi prévoir et tester les accès, les outils et les procédures de bascule.

Les postes de travail font-ils partie du PRA ?

Oui. Sans postes, connexions et accès opérationnels, les collaborateurs ne peuvent pas reprendre leur activité même si les serveurs fonctionnent.

Qui doit définir les RTO et RPO ?

Les responsables métier et techniques doivent les définir ensemble. Ensuite, le donneur d’ordre valide les niveaux correspondant réellement à ses besoins.

Quand faut-il revoir un PRA BPO ?

Il faut le revoir régulièrement et après toute évolution majeure des systèmes, des fournisseurs, des accès ou des besoins métier.