Plan de continuité d'activité PME : tester la panne avant la panne

Combien de temps votre entreprise peut-elle travailler sans son serveur

Un plan de continuité d'activité PME répond à une seule question : combien de temps votre entreprise peut tenir sans son serveur, et avec quelles données. Il se construit en fixant un RTO et un RPO pour chaque application, puis en testant la bascule pour de vrai, pas sur le papier.

Le symptôme : vous le voyez déjà tous les mois

Vous reconnaissez probablement une partie de ce tableau. Un serveur posé dans un local technique qui chauffe l'été. Deux ou trois postes qui mettent plusieurs minutes à ouvrir une session. Un logiciel métier qui tourne encore sur une version que l'éditeur ne suit plus. Un disque de sauvegarde branché en USB, dont personne ne sait précisément ce qu'il contient ni depuis quand il tourne correctement.

Et surtout : la phrase que vous entendez quand vous posez la question. « Oui, les sauvegardes se font. » Personne ne dit « oui, nous avons restauré un dossier complet le mois dernier, en vingt minutes ». C'est la différence entre une sauvegarde et une capacité de reprise d'activité réelle.

Un parc informatique vieillissant ne tombe pas en panne d'un coup. Il se dégrade par petites touches, jusqu'au jour où une seule défaillance — un disque, une alimentation, un ransomware arrivé par une pièce jointe — bloque tout le monde en même temps. C'est à ce moment-là que l'on découvre si les sauvegardes jamais testées valent quelque chose.

Le coût réel de l'attente

Le risque ne se mesure pas en matériel, il se mesure en heures d'arrêt. Quand le serveur de fichiers ou l'ERP tombe, l'atelier, l'administratif et le commerce s'arrêtent ensemble. Les devis ne partent pas, les commandes ne sont pas saisies, les demandes entrantes attendent. Ce temps-là n'est jamais rattrapé, il est reporté sur les semaines suivantes, en heures supplémentaires.

Il y a aussi un volet réglementaire. L'article 32 du RGPD impose, parmi les mesures de sécurité, « la capacité à rétablir la disponibilité des données à caractère personnel et l'accès à celles-ci dans des délais appropriés en cas d'incident physique ou technique », ainsi qu'une procédure visant à tester et évaluer régulièrement l'efficacité de ces mesures. Autrement dit : le test de restauration n'est pas une bonne pratique facultative, c'est une exigence écrite.

Dernier coût, plus silencieux : la dépendance. Quand une seule personne — un prestataire historique, un salarié débrouillard — détient les mots de passe administrateur, la cartographie du réseau et l'historique des interventions, votre continuité repose sur sa disponibilité. Ce n'est pas une organisation, c'est un point unique de défaillance humain.

La méthode : sept étapes pour un plan qui tient

1. Inventorier le parc, sans trou

Postes, serveurs, NAS, switchs, box, licences, contrats de maintenance, dates d'achat, garanties, versions de systèmes. Un tableau suffit, à condition qu'il soit exhaustif et daté. Sans inventaire, tout le reste est de l'approximation.

2. Classer les applications par criticité

Listez ce que fait réellement l'entreprise : facturation, ERP, messagerie, fichiers partagés, téléphonie, accès distants. Pour chacune, une question simple : combien de temps peut-on s'en passer avant que le travail s'arrête ? Cette cartographie des applications critiques est le socle du plan.

3. Fixer un RTO et un RPO par application

Le RTO est le délai maximal de remise en service. Le RPO est la quantité maximale de données que vous acceptez de perdre. Ce sont des décisions de direction, pas des choix techniques.

| Application | RTO visé | RPO visé | | --- | --- | --- | | ERP / facturation | Quelques heures | Moins d'une heure | | Fichiers partagés | Une demi-journée | Quelques heures | | Messagerie | Quelques heures | Proche de zéro | | Poste de travail individuel | Un à deux jours | Une journée |

Ces valeurs sont des exemples de cadrage, à arbitrer avec vos équipes. Un RTO court coûte plus cher : c'est précisément l'arbitrage que le plan doit rendre explicite.

4. Traquer les points uniques de défaillance

Un seul serveur physique, un seul lien internet, un seul administrateur, une seule copie de sauvegarde dans le même local que le serveur. Chaque élément sans doublure doit être listé, puis traité ou assumé par écrit.

5. Mettre la sauvegarde au niveau du RPO décidé

La fréquence, la rétention et l'emplacement des copies découlent du RPO, pas de l'habitude. Une copie hors site et une copie non modifiable par le réseau de production restent la base contre le chiffrement malveillant. Si vous n'avez pas encore structuré ce volet, commencez par la règle 3-2-1 et la restauration réelle, puis revenez au plan de continuité.

6. Écrire la procédure de bascule

Qui décide, qui appelle qui, dans quel ordre on redémarre, où sont les identifiants de secours, comment on prévient les clients. Deux pages, imprimées, accessibles hors du système d'information. Un plan stocké uniquement sur le serveur en panne n'existe pas.

7. Faire l'exercice en conditions réelles

Un exercice de bascule annuel, planifié, chronométré, sur un créneau choisi. On restaure un jeu de données complet sur un environnement de test, on mesure le temps obtenu et on le compare au RTO visé. L'écart constaté est votre véritable niveau de préparation. C'est aussi le moment où une migration cloud devient une option sérieuse : si votre RTO est inhabituellement court, l'hébergement local atteint vite ses limites, et quitter un serveur local sans coupure demande sa propre méthode.

Comment savoir si c'est bien fait

Quelques critères vérifiables, que vous pouvez demander à votre prestataire actuel sans être technicien :

• Le dernier test de restauration est daté, documenté et chiffré en minutes. Pas « ça fonctionne », mais « restauration complète du partage comptabilité en 1 h 40, le 14 du mois dernier ».
• Le RTO et le RPO sont écrits noir sur blanc, application par application, et validés par la direction.
• L'inventaire du parc est à jour à moins de six mois et mentionne les fins de support constructeur et éditeur.
• Au moins une copie de sauvegarde est hors site et inaccessible en écriture depuis le réseau courant.
• Les comptes administrateurs sont nominatifs, et vous disposez d'un accès de secours scellé que vous contrôlez.
• La procédure de bascule existe en version papier, avec les numéros d'urgence des opérateurs et des éditeurs.
• Les journaux de sauvegarde génèrent une alerte en cas d'échec, et quelqu'un est désigné pour la traiter.

Si trois de ces points manquent, vous n'avez pas un plan de reprise d'activité, vous avez une intention. L'objectif d'un audit d'infrastructure IT est précisément de transformer cette intention en trajectoire datée et budgétée.

Passez à l'action

La question n'est pas de savoir si une panne majeure surviendra, mais si votre entreprise saura combien de temps elle durera et ce qu'elle coûtera. Un plan testé transforme un incident critique en interruption gérable.

Securium Agency réalise des audits d'infrastructure pour les PME d'Île-de-France : inventaire complet du parc, cartographie des applications critiques, identification des points uniques de défaillance, vérification réelle des sauvegardes et cadrage du RTO et du RPO. Demandez votre audit d'infrastructure gratuit : vous recevez un diagnostic écrit de votre parc, une liste de correctifs classés par criticité et une trajectoire de mise à niveau chiffrée, utilisable telle quelle en comité de direction.