Une panne de serveur, un incendie, une erreur humaine ou une cyberattaque peuvent rendre une partie du système informatique d’une entreprise inutilisable en quelques minutes.
Le problème n’est alors plus seulement de réparer un ordinateur ou de restaurer quelques fichiers. Il faut être capable de remettre en fonctionnement les services indispensables à l’activité dans un délai acceptable.
C’est précisément le rôle du plan de reprise d’activité informatique, généralement désigné par l’acronyme PRA.
Pour une PME dépendante de son informatique, préparer ce plan avant qu’un incident survienne peut faire toute la différence entre une interruption maîtrisée et plusieurs jours de désorganisation.
Qu’est-ce qu’un plan de reprise d’activité informatique ?
Un PRA est un ensemble de procédures techniques et organisationnelles prévues pour permettre à une entreprise de redémarrer son système informatique après un incident important.
Il répond notamment à plusieurs questions :
- quels systèmes doivent être restaurés en priorité ?
- où sont stockées les sauvegardes ?
- qui intervient lorsqu’un incident survient ?
- comment accéder aux applications si l’infrastructure principale est indisponible ?
- combien de temps l’entreprise peut-elle fonctionner sans certains services ?
- quelle quantité de données peut-elle accepter de perdre ?
L’objectif n’est donc pas simplement de disposer d’une sauvegarde.
Un véritable plan de reprise prévoit comment passer d’une infrastructure indisponible à un système suffisamment opérationnel pour reprendre l’activité.
Quelle différence entre un PRA et un PCA ?
Les deux notions sont proches mais ne répondent pas exactement au même objectif.
Le PCA, ou plan de continuité d’activité, vise à permettre à l’entreprise de continuer à fonctionner pendant la perturbation, éventuellement de manière dégradée.
Le PRA, ou plan de reprise d’activité, intervient davantage dans la restauration du fonctionnement normal après l’incident.
Prenons l’exemple d’une entreprise dont le serveur principal devient indisponible.
Un PCA peut prévoir une solution permettant aux salariés d’accéder temporairement aux applications essentielles depuis une infrastructure secondaire.
Le PRA détaille ensuite la manière dont les serveurs, applications et données doivent être restaurés afin de revenir à une situation normale.
Dans la pratique, les deux approches sont donc souvent complémentaires.
Quels incidents peuvent déclencher un PRA ?
On pense immédiatement aux cyberattaques, mais de nombreux événements peuvent provoquer une interruption informatique.
Une attaque par ransomware
Un rançongiciel peut chiffrer les fichiers et rendre certains systèmes inutilisables.
Dans ce cas, restaurer simplement les dernières sauvegardes n’est pas toujours suffisant. Il faut également identifier les systèmes compromis et éviter de réintroduire l’attaque lors de la remise en service.
Une panne matérielle importante
Un serveur, un équipement réseau ou un système de stockage peut tomber en panne.
Si plusieurs services essentiels dépendent de cet équipement, une défaillance matérielle apparemment simple peut rapidement bloquer une partie de l’entreprise.
Une erreur humaine
Une mauvaise manipulation peut entraîner la suppression de données, la modification d’une configuration ou l’arrêt d’un service important.
Le PRA doit donc également tenir compte des erreurs internes.
Un sinistre dans les locaux
Incendie, dégât des eaux, problème électrique ou vol de matériel : certains incidents peuvent rendre l’infrastructure physique totalement inaccessible.
C’est l’une des raisons pour lesquelles conserver toutes les sauvegardes au même endroit que les serveurs constitue un risque.
Quels systèmes faut-il restaurer en premier ?
Tous les services informatiques n’ont pas la même importance.
Une entreprise doit commencer par identifier les outils indispensables à son fonctionnement.
Il peut notamment s’agir :
- du logiciel métier ;
- de l’ERP ;
- du CRM ;
- de la messagerie ;
- des fichiers partagés ;
- du système de facturation ;
- des bases de données ;
- des outils logistiques ;
- des serveurs ;
- des accès réseau.
Une société de transport n’aura évidemment pas les mêmes priorités qu’un cabinet comptable ou qu’une entreprise industrielle.
La première étape d’un PRA consiste donc à réaliser une cartographie des systèmes et à déterminer lesquels doivent être restaurés en priorité.
Déterminer combien de temps l’entreprise peut rester arrêtée
Imaginons deux applications.
La première peut rester indisponible pendant deux jours sans conséquence importante.
La deuxième bloque totalement la production après trente minutes.
Les deux services ne doivent évidemment pas bénéficier du même niveau de priorité.
Pour chaque élément critique, l’entreprise doit donc déterminer la durée maximale pendant laquelle elle peut accepter une interruption.
Plus cette durée est courte, plus l’infrastructure de secours nécessaire risque d’être importante.
Une reprise en quelques minutes peut nécessiter des systèmes redondants ou une réplication quasiment permanente des données.
Une reprise pouvant attendre plusieurs heures permettra généralement une architecture plus simple.
Combien de données peut-on accepter de perdre ?
Deuxième question fondamentale : jusqu’à quel moment doit-on pouvoir restaurer les données ?
Prenons une entreprise effectuant une sauvegarde chaque nuit.
Si son système tombe en panne à 17 heures, la restauration de la sauvegarde précédente peut entraîner la perte de toutes les données créées depuis le début de la journée.
Pour certaines entreprises, cette perte restera acceptable.
Pour d’autres, perdre plusieurs heures de commandes, de documents ou de transactions serait extrêmement problématique.
La fréquence des sauvegardes et des réplications doit donc être adaptée à la valeur des données.
Une sauvegarde n’est pas un PRA
C’est une confusion fréquente.
Avoir une sauvegarde est indispensable, mais cela ne garantit pas que l’entreprise pourra reprendre rapidement son activité.
Encore faut-il savoir :
- si la sauvegarde est exploitable ;
- combien de temps prend sa restauration ;
- où restaurer les données ;
- dans quel ordre remettre les systèmes en fonctionnement ;
- qui possède les accès nécessaires ;
- si les dépendances entre les applications sont documentées.
Il faut également envisager qu’une cyberattaque puisse toucher simultanément le système principal et certaines sauvegardes accessibles depuis ce système.
Le PRA doit donc être pensé comme une procédure complète de reprise, et pas uniquement comme une copie des données.
Prévoir plusieurs niveaux de sauvegarde
Une stratégie robuste repose généralement sur plusieurs copies des données.
L’objectif consiste à éviter qu’un même événement puisse supprimer simultanément les données d’origine et toutes leurs sauvegardes.
On peut par exemple combiner :
- une sauvegarde locale ;
- une sauvegarde sur une autre infrastructure ;
- une copie externalisée ;
- une sauvegarde isolée ou protégée contre les modifications.
La configuration exacte dépend évidemment de la sensibilité des informations et de l’activité de l’entreprise.
Une PME manipulant quelques documents bureautiques n’aura pas les mêmes contraintes qu’une entreprise utilisant des bases de données mises à jour plusieurs centaines de fois par heure.
Documenter précisément la procédure de reprise
Lorsqu’un incident majeur survient, ce n’est pas le meilleur moment pour chercher les mots de passe, les coordonnées des prestataires ou l’ordre dans lequel les serveurs doivent être redémarrés.
Les procédures doivent donc être documentées à l’avance.
Un PRA peut notamment contenir :
- la liste des responsables ;
- les coordonnées des personnes à contacter ;
- l’inventaire des équipements ;
- les accès aux différentes infrastructures ;
- l’emplacement des sauvegardes ;
- l’ordre de restauration des services ;
- les procédures de bascule vers les systèmes de secours ;
- les modalités de communication avec les collaborateurs.
Cette documentation doit également rester accessible lorsque l’infrastructure informatique principale ne fonctionne plus.
Mettre en place une solution adaptée à l’entreprise
Il n’existe pas un modèle de PRA identique pour toutes les organisations.
Une petite PME possédant essentiellement des outils cloud pourra mettre en place une architecture relativement simple.
Une entreprise exploitant plusieurs serveurs, des applications métier critiques et différents sites géographiques aura besoin d’une stratégie plus élaborée.
Il est donc généralement nécessaire d’analyser l’infrastructure existante avant de déterminer les solutions techniques pertinentes.
Des prestataires spécialisés comme Expertis IT accompagnent notamment les entreprises dans la conception de solutions PCA/PRA comprenant l’analyse des risques, l’identification des systèmes prioritaires, les mécanismes de sauvegarde ou de réplication et les tests de reprise.
Pourquoi faut-il tester régulièrement son PRA ?
Un plan qui n’a jamais été testé reste une hypothèse.
Entre le moment où le document a été créé et celui où un véritable incident survient, l’environnement informatique peut avoir profondément changé.
De nouveaux serveurs ont pu être installés.
Un logiciel métier peut avoir été remplacé.
Des salariés peuvent avoir quitté l’entreprise.
Les volumes de données peuvent également avoir fortement augmenté.
Une procédure de restauration qui fonctionnait deux ans auparavant peut ainsi devenir insuffisante.
Des exercices réguliers permettent de vérifier que les sauvegardes sont exploitables et que les différentes procédures fonctionnent réellement.
Ils permettent aussi de mesurer le temps nécessaire pour restaurer les services.
À quelle fréquence faut-il tester un plan de reprise ?
Il n’existe pas une fréquence universelle adaptée à toutes les entreprises.
En revanche, un test doit être réalisé régulièrement et après les modifications importantes du système informatique.
Une migration cloud, l’installation d’un nouvel ERP, le remplacement d’un serveur ou la modification de l’architecture réseau peuvent par exemple nécessiter une révision du PRA.
Il est également utile de prévoir différents niveaux de test.
Tout exercice ne nécessite pas forcément l’arrêt complet de l’infrastructure.
Des tests de restauration ciblés permettent déjà de contrôler régulièrement certains éléments essentiels.
Les erreurs à éviter lors de la création d’un PRA
La première erreur consiste à penser qu’un simple logiciel de sauvegarde suffit.
La deuxième est de vouloir restaurer tous les services avec le même niveau de priorité.
Une autre erreur fréquente consiste à créer un document extrêmement détaillé puis à ne jamais le mettre à jour.
Enfin, il faut éviter que la totalité du dispositif dépende d’une seule personne.
Si cette personne est absente lorsque l’incident survient, le plan devient beaucoup moins efficace.
Un PRA doit donc rester compréhensible, documenté et utilisable par plusieurs intervenants.
Comment mettre en place un PRA dans une PME ?
La démarche peut être organisée autour de quelques grandes étapes.
Il faut commencer par inventorier les systèmes et identifier ceux qui sont réellement critiques.
L’entreprise doit ensuite déterminer la durée maximale acceptable d’interruption et le niveau de perte de données tolérable.
À partir de ces besoins, il devient possible de choisir les solutions adaptées : sauvegardes, réplication, hébergement secondaire, cloud, virtualisation ou infrastructure de secours.
Les procédures de restauration doivent ensuite être documentées.
Enfin, le dispositif doit être testé puis mis à jour régulièrement.
Un PRA doit être préparé avant la panne
Lorsqu’un système informatique fonctionne correctement, investir du temps dans la préparation d’une panne peut sembler secondaire.
Pourtant, c’est précisément à ce moment qu’il faut construire le plan.
Après une cyberattaque ou une panne majeure, les décisions doivent être prises rapidement et dans un contexte souvent beaucoup plus difficile.
Un plan de reprise d’activité informatique permet de transformer une situation improvisée en une procédure préparée : l’entreprise sait quelles données protéger, quels systèmes restaurer en priorité, qui doit intervenir et dans quel délai l’activité doit pouvoir reprendre.
Le véritable objectif du PRA n’est donc pas d’empêcher toutes les pannes.
Il est de faire en sorte qu’une panne informatique ne se transforme pas en arrêt prolongé de l’entreprise.
