Plan de continuité IT pour PME romande : 1 page, testé deux fois par an

Un vendredi soir, 18h47 : votre NAS chiffré, vos équipes rentrées chez elles

La majorité des PME romandes disposent d'une sauvegarde quelque part. Très peu savent en combien de minutes elles peuvent restaurer un serveur de fichiers critique, et encore moins ont testé cette procédure depuis un réseau de secours. Un plan de continuité IT (BCP IT) n'est pas un document de conformité qui dort dans un dossier SharePoint : c'est une feuille A4 laminée que n'importe quel collaborateur technique peut exécuter seul, à 2h du matin, depuis un hôtel à Lausanne.

Ce que la nLPD impose concrètement aux PME

Depuis le 01.09.2023, la loi fédérale sur la protection des données révisée (nLPD) oblige tout responsable de traitement à notifier une violation de données au Préposé fédéral à la protection des données et à la transparence (PFPDT) dans les meilleurs délais dès qu'un risque élevé pèse sur les personnes concernées. Le délai implicite retenu par la doctrine et les autorités est de 72 heures — calqué sur le modèle RGPD, même si la nLPD ne fixe pas ce chiffre explicitement dans la loi.

Ce délai impose une capacité de détection et de qualification de l'incident en moins de 24 heures, ce qui est impossible sans procédure documentée. Concrètement :

• Vous devez pouvoir identifier quelles données personnelles sont concernées (catégories, volume, sensibilité).
• Vous devez évaluer le risque résiduel pour les personnes physiques.
• Vous devez savoir qui notifie (DSI ? juriste ? direction ?) et avec quel formulaire.

Sans BCP IT documenté, cette qualification se fait dans la panique, avec des informations incomplètes, et la notification arrive hors délai — ce qui constitue lui-même une violation.

Ce que la nLPD ne dit pas mais que vous devez anticiper

La loi ne prescrit pas de RTO (Recovery Time Objective) ni de RPO (Recovery Point Objective). Elle exige des mesures techniques et organisationnelles appropriées (art. 8 nLPD). Le NCSC recommande explicitement aux PME de tester leurs sauvegardes régulièrement et de disposer d'une procédure de réponse aux incidents. Un BCP IT testé deux fois par an constitue une preuve de diligence raisonnable si vous devez démontrer vos mesures au PFPDT ou à un assureur cyber.

Architecture d'un BCP IT d'une page : ce qui doit y figurer

L'objectif est qu'un technicien junior ou un MSP mandaté puisse exécuter le plan sans vous appeler. Une page recto, police 10pt, suffit si vous retirez tout ce qui n'est pas une action ou un seuil.

Bloc 1 : seuils de déclenchement

Définissez trois niveaux, chacun avec un déclencheur objectif :

• Niveau 1 — Dégradation : un service non critique indisponible > 30 minutes. Action : alerte DSI, ticket ouvert.
• Niveau 2 — Interruption : un service critique (ERP, messagerie, VPN) indisponible > 2 heures. Action : activation du plan de continuité, escalade direction.
• Niveau 3 — Sinistre : perte ou chiffrement de données, infrastructure principale hors ligne > 4 heures. Action : BCP complet, notification NCSC, évaluation nLPD.

Bloc 2 : contacts d'astreinte avec rôles

Quatre personnes maximum, avec un rôle unique chacune :

• Responsable technique (DSI ou sysadmin) — décide des actions techniques.
• Responsable métier (DG ou COO) — décide de la communication externe et de la priorité des services.
• MSP ou partenaire IT externe — accès aux systèmes, intervention sur site si nécessaire.
• Juriste ou DPO — qualifie l'incident nLPD, rédige la notification PFPDT.

Bloc 3 : RTO et RPO par service critique

Listez vos 3 à 5 services critiques avec des seuils réalistes issus de vos tests :

Bloc 4 : procédure de restauration en 7 étapes

1. Isoler les systèmes compromis (débrancher du réseau, ne pas éteindre pour préserver les traces forensiques).
2. Ouvrir un canal de communication hors-bande (Signal, téléphone) — ne pas utiliser la messagerie interne si elle est compromise.
3. Identifier le vecteur et la portée : quels endpoints, quels comptes, quelles données.
4. Activer le site de reprise ou les instances cloud de secours.
5. Restaurer les services dans l'ordre de criticité (AD en premier, puis messagerie, puis ERP).
6. Valider l'intégrité des données restaurées avant toute remise en production.
7. Documenter la chronologie pour le rapport post-incident et la potentielle notification PFPDT.

Bloc 5 : checklist de notification nLPD

Sur la même page, une case à cocher :

• ☐ Données personnelles impliquées ? (oui/non)
• ☐ Risque élevé pour les personnes concernées ? (critères : données sensibles, volume > 500 personnes, risque de discrimination ou fraude)
• ☐ Si oui : notification PFPDT via le formulaire de meldepflicht PFPDT dans les meilleurs délais.
• ☐ Notification aux personnes concernées si le risque le justifie.
• ☐ Signalement au NCSC si infrastructure critique ou attaque sophistiquée.

Protocole de test biannuel : ce qui doit être validé

Deux tests par an : un test de table (tabletop exercise) en janvier-février, un test de restauration réelle en juin-juillet. Ces dates évitent les périodes de clôture comptable (mars, décembre) et les vacances estivales tardives.

Test 1 — Exercice de table (janvier, 2 heures)

Participants : DSI, responsable métier, juriste/DPO, optionnellement le MSP. Scénario préparé à l'avance mais non communiqué aux participants jusqu'à J-2. Exemple de scénario : un poste RH est chiffré par ransomware un jeudi matin, les données de paie de 45 employés sont potentiellement exfiltrées.

Questions posées séquentiellement :

• Qui est appelé en premier ? En combien de minutes ?
• Quelle décision technique dans les 30 premières minutes ?
• À quelle heure la direction est-elle informée ?
• À quelle heure le juriste qualifie-t-il l'incident nLPD ?
• Le formulaire de notification PFPDT est-il connu et accessible ?

Résultat attendu : un rapport d'une page listant les écarts entre la procédure documentée et le comportement réel, avec des actions correctives datées.

Test 2 — Restauration réelle (juin-juillet, demi-journée)

Ce test doit partir d'une sauvegarde réelle et aboutir à un service fonctionnel. Pas de simulation : vous restaurez effectivement Active Directory ou le serveur de fichiers dans un environnement isolé (VLAN de test ou VM sandbox).

Métriques à mesurer et documenter :

• Temps effectif de restauration (comparez avec le RTO cible).
• Intégrité des données restaurées (hash MD5/SHA-256 des fichiers critiques).
• Accès fonctionnel depuis un poste client hors réseau principal.
• Durée de la procédure complète exécutée par une seule personne.

Si le RTO mesuré dépasse le RTO cible de plus de 50 %, le plan est mis à jour avant la fin du trimestre. Les résultats de test sont archivés pendant 5 ans — durée de prescription standard en droit suisse, et preuve de diligence en cas de litige ou d'audit.

Cas pratique : fiduciaire vaudoise, 38 endpoints

Une fiduciaire de 22 collaborateurs basée à Morges, avec 38 endpoints (18 PC Windows 11 23H2, 12 MacBook Pro macOS 14, 8 iPads en mobilité), traite des données fiscales et comptables de 340 entreprises clientes — soit plusieurs milliers de personnes physiques indirectement. Son infrastructure : un serveur Windows Server 2022 on-premise, un tenant Microsoft 365 Business Premium, des sauvegardes Veeam vers un NAS Synology + réplication S3 vers un bucket Exoscale à Genève.

Contexte de l'incident simulé

Scénario de test janvier 2025 : un collaborateur clique sur un lien de phishing dans un e-mail imitant le portail swissdec. Son poste Windows est compromis à 16h30 un mercredi. Le script PowerShell malveillant tente de se propager via SMB sur le réseau local. La détection intervient à 17h15 grâce à une alerte Defender for Endpoint (blocage d'un processus lsass.exe suspect).

Déroulement minute par minute (test de table)

1. 17h15 — Alerte Defender for Endpoint reçue par le DSI (externalisé, MSP lausannois). Poste isolé via portail Intune (action « isoler l'appareil ») en 4 minutes.
2. 17h30 — DSI appelle la directrice associée et le juriste externe selon la liste de contacts du BCP. Canal Signal créé.
3. 17h45 — Vérification des journaux de connexion M365 : aucune exfiltration détectée vers l'extérieur. Le compte utilisateur est suspendu dans Azure AD.
4. 18h00 — Qualification nLPD : données personnelles sur le poste ? Oui (dossiers clients locaux non synchronisés, ~80 dossiers). Risque élevé ? Le juriste estime que non, l'exfiltration n'est pas confirmée et le poste était isolé rapidement. Décision : pas de notification PFPDT à ce stade, documentation de la décision motivée.
5. 18h30 — Réinstallation du poste via Windows Autopilot depuis une image de référence (durée effective : 47 minutes). Restauration des dossiers locaux depuis snapshot Veeam J-1 (RPO : 18 heures, dans les objectifs).
6. 20h00 — Poste opérationnel, collaborateur notifié. Rapport d'incident rédigé par le DSI.

Coût de l'incident

• 2,5 heures DSI (MSP) × CHF 180/h = CHF 450
• 1 heure juriste externe × CHF 300/h = CHF 300
• Perte de productivité collaborateur (demi-journée) = CHF 250
• Total : CHF 1 000, contre une estimation de CHF 15 000–45 000 pour un incident non contenu (restauration complète, notification clients, frais juridiques).

Écart identifié et action corrective

Le test a révélé que les dossiers clients locaux n'étaient pas couverts par la politique de redirection de dossiers vers SharePoint. Sur 18 postes Windows, 6 avaient des dossiers locaux hors sauvegarde Veeam. Action corrective déployée en février 2025 : GPO de redirection de dossiers activée sur tous les postes, vérifiée par rapport Intune hebdomadaire. Coût : 3 heures DSI.

Récapitulatif opérationnel

1. Rédigez le BCP sur une page A4 : seuils de déclenchement (3 niveaux), contacts d'astreinte (4 rôles max), RTO/RPO par service critique, procédure en 7 étapes, checklist nLPD.
2. Identifiez vos 3 à 5 services critiques et fixez des RTO/RPO mesurables, pas aspirationnels.
3. Planifiez deux tests dès janvier : tabletop en janvier-février, restauration réelle en juin-juillet. Bloquez les agendas maintenant.
4. Archivez les rapports de test pendant 5 ans : ils constituent votre preuve de diligence en cas d'audit nLPD ou de litige assureur.
5. Vérifiez votre couverture de sauvegarde : chaque endpoint doit avoir ses données critiques dans un système couvert par Veeam, rsync, ou une politique de redirection de dossiers vers le cloud.
6. Préparez le formulaire de notification PFPDT à l'avance : connaître la procédure le jour J évite les 72 heures perdues à chercher comment notifier.
7. Définissez un canal de communication hors-bande (Signal, téléphone) activable si votre messagerie est compromise.
8. Mettez à jour le plan après chaque test et après tout changement d'infrastructure majeur (migration cloud, nouvel ERP, rachat de société).
9. Signalez les attaques sophistiquées au NCSC via leur formulaire de signalement — même si l'incident est contenu, cela contribue aux statistiques nationales et peut déclencher une alerte sectorielle utile.
10. Relisez l'article 8 nLPD annuellement avec votre juriste : les pratiques de l'autorité sur la notion de « risque élevé » évoluent au fil des décisions.

Les outils MDM comme ceux proposés par SynGuard permettent d'automatiser certaines étapes (isolation d'un endpoint compromis, déploiement d'une image de référence via Autopilot ou ABM), mais aucun outil ne remplace la procédure documentée et testée — c'est elle que le PFPDT ou votre assureur cyber demandera à voir.

Sources

• Fedlex — Loi fédérale sur la protection des données (nLPD), RS 235.1 — Texte consolidé de la loi révisée en vigueur depuis le 01.09.2023.
• PFPDT — Obligation de signalement des violations de données — Procédure et critères de notification au Préposé fédéral.
• NCSC — Ransomware : recommandations pour les PME — Conseils techniques officiels du Centre national pour la cybersécurité.
• NCSC — Formulaire de signalement d'incidents — Portail de signalement pour les entreprises et particuliers en Suisse.
• CIS Controls — Center for Internet Security — Référentiel de contrôles de sécurité incluant la gestion de la continuité et des sauvegardes (Controls 11 et 17).