Infrastructure

Sauvegarde et plan de reprise d'activité pour une PME

Publié le Par Dr Ir Hüseyin Cakmak
#sauvegarde entreprise #plan de reprise d'activité PME #PRA #règle 3-2-1 #sauvegarde immuable
Sauvegarde et plan de reprise d'activité pour une PME

Un plan de reprise d'activité (PRA) est ce qui sépare une PME qui redémarre en quelques heures d'une PME qui ferme après un sinistre. Sauvegarder ne suffit pas : encore faut-il pouvoir restaurer vite, et résister à un rançongiciel qui vise d'abord vos copies. En Belgique, une entreprise sur cinq a déjà subi les conséquences d'un incident de sécurité, incluant interruptions de service et pertes de données [1].

Sauvegarde et plan de reprise d'activité : de quoi parle-t-on ?

Une sauvegarde est une copie de vos données conservée à part, pour pouvoir les récupérer si l'original est perdu, corrompu ou chiffré. C'est nécessaire, mais ce n'est qu'une brique. Le plan de reprise d'activité, lui, décrit comment remettre en marche l'ensemble du système d'information après un sinistre : dans quel ordre, en combien de temps, avec quelles ressources et qui fait quoi.

La distinction avec le plan de continuité d'activité (PCA) mérite d'être posée. Le PRA se concentre sur la restauration technique après l'incident. Le PCA, plus large, vise à maintenir les fonctions vitales de l'entreprise pendant la crise, y compris les aspects humains et organisationnels. Pour une PME de 20 à 250 personnes, la démarche réaliste consiste à bâtir d'abord un PRA solide, puis à l'étendre progressivement vers un PCA.

Le déclencheur d'un sinistre n'est pas toujours spectaculaire. Une panne de disque, un dégât des eaux dans le local serveur, une erreur de manipulation ou une attaque par rançongiciel produisent le même résultat : des données indisponibles et une activité à l'arrêt. Le rançongiciel reste d'ailleurs l'une des menaces majeures identifiées à l'échelle européenne [2].

Comprendre RPO et RTO sans jargon

Deux indicateurs pilotent tout plan de reprise. Ils sont simples une fois traduits en langage clair.

Le RPO (Recovery Point Objective, ou objectif de point de reprise) répond à la question : combien de données puis-je me permettre de perdre ? Il se mesure en temps. Un RPO de 24 heures signifie qu'en cas d'incident, vous acceptez de repartir de la sauvegarde de la veille, donc de perdre au maximum une journée de travail. Concrètement, le RPO détermine la fréquence de vos sauvegardes [4].

Le RTO (Recovery Time Objective, ou objectif de temps de reprise) répond à : en combien de temps dois-je être de nouveau opérationnel ? Un RTO de 4 heures veut dire que le système doit être rétabli dans les quatre heures suivant le sinistre. Le RTO conditionne le type de solution : une simple sauvegarde sur disque externe ne tiendra pas un RTO de deux heures, là où une réplication vers un site secondaire le permettra [5].

Indicateur Question posée Ce qu'il pilote
RPO Combien de données puis-je perdre ? La fréquence des sauvegardes
RTO En combien de temps redémarrer ? Le type d'architecture de reprise

Le bon réflexe n'est pas de viser zéro partout, car un RPO et un RTO très courts coûtent cher. Il s'agit de fixer, service par service, ce qui est acceptable pour l'entreprise. La comptabilité et l'ERP ne tolèrent pas le même niveau de perte qu'un partage de fichiers secondaire.

La règle 3-2-1, socle d'une sauvegarde fiable

La règle 3-2-1 est le standard de référence, simple à retenir et à auditer :

  • 3 copies de vos données (l'original plus deux sauvegardes) ;
  • 2 types de supports différents (par exemple un NAS local et un stockage cloud) ;
  • 1 copie conservée hors site, à l'abri d'un sinistre physique touchant vos locaux.

L'intérêt de cette règle est de couvrir plusieurs modes de défaillance à la fois. Deux supports différents évitent qu'une même faiblesse technique détruise toutes les copies. La copie hors site protège de l'incendie, du vol ou de l'inondation. Face à la montée des rançongiciels, de nombreux référentiels recommandent aujourd'hui une variante renforcée, parfois notée 3-2-1-1-0 : une copie supplémentaire hors ligne ou immuable, et zéro erreur lors des tests de restauration [3][5].

Pour une PME belge, une mise en œuvre courante combine une sauvegarde locale rapide (restauration du quotidien) et une copie cloud chez un hébergeur assurant la résidence des données dans l'Union européenne, un point utile pour la conformité RGPD. Le choix de l'emplacement des données rejoint les arbitrages d'architecture que nous détaillons dans notre article sur l'infrastructure réseau d'une PME.

Sauvegarde immuable : la parade au rançongiciel

Le rançongiciel a changé les règles du jeu. Un attaquant méthodique cherche d'abord à repérer et à détruire les sauvegardes accessibles depuis le réseau, avant de chiffrer les données de production. Si vos sauvegardes vivent sur un partage réseau ordinaire, elles peuvent être chiffrées en même temps que le reste. C'est le scénario cauchemar : payer la rançon devient la seule option apparente.

La sauvegarde immuable répond exactement à cette menace. Une fois écrite, la donnée ne peut plus être ni modifiée ni supprimée pendant une période définie, même par un compte administrateur compromis. Techniquement, cela s'appuie sur des mécanismes de type WORM (write once, read many), sur le verrouillage d'objets proposé par certains stockages cloud, ou sur des copies réellement hors ligne, physiquement déconnectées du réseau.

Les autorités de cybersécurité insistent sur ce point : disposer de sauvegardes hors ligne ou immuables, testées, est l'une des mesures les plus efficaces pour se relever d'une attaque sans céder au chantage [2]. En Belgique, le Centre pour la Cybersécurité Belgique (CCB) et le portail Safeonweb diffusent des recommandations dans le même esprit à destination des organisations. L'idée directrice tient en une phrase : une sauvegarde que le rançongiciel peut atteindre n'est pas une vraie sauvegarde.

Tester ses restaurations, l'étape que tout le monde oublie

C'est la faille la plus répandue, et la plus dangereuse par sa discrétion. Beaucoup d'entreprises sauvegardent consciencieusement pendant des années sans jamais vérifier qu'une restauration fonctionne. Le jour du sinistre, elles découvrent une sauvegarde corrompue, incomplète, ou dont personne ne connaît la procédure de remontée. Une sauvegarde jamais testée n'est pas une sécurité, c'est une hypothèse.

Tester, c'est mesurer trois choses concrètes :

  1. L'intégrité : les fichiers restaurés sont-ils exploitables, sans corruption ?
  2. La complétude : toutes les données critiques sont-elles réellement dans le périmètre sauvegardé ?
  3. Le RTO réel : combien de temps prend une restauration complète, du démarrage à la reprise du service ?

Ce dernier point réserve souvent des surprises : le RTO mesuré dépasse fréquemment le RTO espéré. Le RGPD lui-même attend des organisations qu'elles vérifient régulièrement l'efficacité des mesures garantissant la disponibilité et la restauration des données [7]. La bonne cadence pour une PME est un test de restauration complet deux à quatre fois par an, plus un test après chaque changement majeur d'infrastructure. Documentez la procédure pas à pas, afin qu'elle reste exécutable même si la personne habituelle est absente.

Construire un plan de reprise d'activité pour votre PME

Un PRA utile n'a pas besoin d'être un document de cent pages. Il doit être clair, à jour et réellement applicable sous pression. Une démarche pragmatique tient en quelques étapes.

  • Cartographier les données et les services : identifiez ce qui est critique (ERP, comptabilité, messagerie, données clients) et ce qui l'est moins. Tout ne mérite pas le même niveau de protection.
  • Fixer un RPO et un RTO par service : c'est la décision structurante, à prendre avec la direction et non uniquement l'IT, car elle engage l'entreprise.
  • Choisir l'architecture de sauvegarde : appliquer la règle 3-2-1, ajouter l'immuabilité pour les données sensibles, définir la fréquence dérivée du RPO.
  • Écrire la procédure de reprise : ordre de redémarrage, responsables, coordonnées, accès de secours, communication interne et externe.
  • Tester, mesurer, corriger : planifier les tests de restauration et ajuster le plan à chaque écart constaté.

Chez ITOPS.be, nous abordons ce sujet selon notre logique en deux temps : un Blueprint qui cadre les priorités, le RPO/RTO et l'architecture cible, suivi d'un Build qui met en place la sauvegarde, l'immuabilité et le rituel de tests. Cette continuité entre le conseil et la réalisation évite l'écueil classique d'un beau plan qui reste dans un tiroir. La sécurité du système d'information, dont la reprise fait partie, se pense d'ailleurs de façon globale, comme nous l'expliquons dans notre guide sur l'audit de sécurité et la conformité RGPD.

Obligations belges : RGPD et disponibilité des données

La sauvegarde n'est pas qu'une bonne pratique technique, c'est aussi un point de conformité. Le RGPD impose aux organisations de garantir la sécurité des données personnelles, ce qui inclut explicitement la capacité à rétablir la disponibilité et l'accès aux données en cas d'incident physique ou technique [7]. Autrement dit, ne pas pouvoir restaurer ses données après un sinistre peut constituer un manquement.

En cas de fuite de données personnelles, une obligation de notification s'ajoute : l'entreprise doit en informer l'Autorité de protection des données (APD) dans un délai de 72 heures après en avoir pris connaissance, sauf si la violation est peu susceptible d'engendrer un risque pour les personnes concernées [6]. L'APD met à disposition des ressources pour les professionnels sur ces démarches [8]. Un plan de reprise fiable aide directement à tenir ces exigences : il permet d'évaluer rapidement l'étendue de l'incident, de restaurer les données et de documenter ce qui s'est passé.

Pour les secteurs concernés par la directive NIS2, ces exigences de résilience se renforcent encore. Nous détaillons ce cadre dans notre article sur la conformité NIS2 pour les PME belges. Dans tous les cas, la logique reste la même : une PME qui sait sauvegarder, protéger et surtout restaurer ses données transforme un incident potentiellement fatal en simple interruption maîtrisée.

Questions fréquentes

Quelle est la différence entre un PRA et un PCA ?

Le plan de reprise d'activité (PRA) organise le redémarrage du système d'information après un sinistre, une fois l'incident survenu. Le plan de continuité d'activité (PCA) est plus large : il vise à maintenir les fonctions essentielles de l'entreprise pendant la crise. Une PME commence en général par un PRA solide, puis l'étend en PCA.

Que signifie la règle 3-2-1 pour une sauvegarde ?

Trois copies de vos données, sur deux types de supports différents, dont une copie hors site. C'est le socle minimal reconnu pour survivre à une panne matérielle, un incendie ou un rançongiciel. Beaucoup d'experts recommandent d'ajouter une copie immuable ou hors ligne, d'où la variante 3-2-1-1-0 [3].

Qu'est-ce qu'une sauvegarde immuable ?

Une sauvegarde immuable ne peut être ni modifiée ni supprimée pendant une durée définie, même par un administrateur ou un rançongiciel disposant de droits élevés. C'est la parade la plus efficace contre un chiffrement malveillant qui cherche d'abord à détruire les sauvegardes accessibles [2].

À quelle fréquence faut-il tester ses restaurations ?

Une sauvegarde jamais testée n'est qu'une hypothèse. Testez une restauration complète au moins deux à quatre fois par an, et après tout changement majeur d'infrastructure. C'est le seul moyen de vérifier que votre RTO réel correspond à votre objectif [4][5].

Une PME belge a-t-elle une obligation légale de sauvegarde ?

Le RGPD impose de garantir la disponibilité et la capacité à restaurer les données personnelles après un incident, et de notifier une fuite à l'Autorité de protection des données sous 72 heures dans la plupart des cas [6][7]. Sans plan de reprise fiable, ces obligations sont très difficiles à tenir.

Sources et Références

  1. Statbel : Une entreprise sur cinq victime d'un incident de sécurité
  2. ENISA : ENISA Threat Landscape 2024
  3. CISA : StopRansomware, guidance et bonnes pratiques
  4. NIST : Recovery Point Objective (RPO), glossaire
  5. NIST : Recovery Time Objective (RTO), glossaire
  6. RGPD : Article 33, notification d'une violation de données
  7. RGPD : Article 32, sécurité du traitement
  8. Autorité de protection des données : Espace professionnel