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

Un ransomware à 14h un mercredi : sans plan, l'improvisation coûte cher

Le 14.03.2024, une fiduciaire genevoise de 38 collaborateurs a découvert ses serveurs de fichiers chiffrés par LockBit 3.0. Huit jours de récupération, 47 000 CHF de coûts directs (forensics, heures supplémentaires, communication clients), et une notification tardive au Préposé fédéral à la protection des données (PFPDT) — parce que personne ne savait qui devait l'envoyer ni dans quel délai. Ce scénario se répète chaque semaine dans les PME romandes. Un plan de continuité IT d'une page, révisé et testé deux fois par an, aurait réduit ce délai de récupération de moitié.

Cadre légal : ce que la nLPD exige concrètement

Depuis le 01.09.2023, la nouvelle loi fédérale sur la protection des données (nLPD) impose aux responsables du traitement de notifier le PFPDT « dans les meilleurs délais » en cas de violation de données susceptible d'engendrer un risque élevé pour les personnes concernées. L'absence de délai chiffré dans la loi ne signifie pas l'absence d'obligation : la doctrine et les recommandations du PFPDT convergent vers 72 heures comme référence opérationnelle, en ligne avec le RGPD européen pour les entreprises à double exposition.

Ce que la nLPD ne dit pas — et qui compte quand même

La nLPD n'impose pas explicitement un plan de continuité documenté (BCP/DRP) aux PME non régulées. Mais deux obligations implicites l'exigent de facto :

• Art. 8 nLPD — sécurité des données : le responsable doit prendre les mesures techniques et organisationnelles appropriées. Un système de fichiers sans sauvegardes testées ne satisfait pas ce critère.
• Art. 24 nLPD — notification : pour notifier dans les délais, il faut savoir en moins de 4 heures si l'incident implique des données personnelles, lesquelles, et combien de personnes. Sans inventaire et sans procédure, c'est impossible.

Pour les PME soumises à la FINMA (gérants de fortune, assureurs-liés, banques de taille réduite), la circulaire FINMA 2023/1 sur les risques opérationnels impose un RTO (Recovery Time Objective) et un RPO (Recovery Point Objective) documentés et testés. Les sanctions peuvent atteindre le retrait d'autorisation.

Architecture minimale d'un plan de continuité IT sur une page

Le principe du « one-pager » n'est pas une simplification : c'est une contrainte de lisibilité. Un document de 40 pages n'est pas lu en crise. La page unique force à hiérarchiser ce qui compte vraiment.

Les 6 blocs indispensables

1. Déclencheurs et seuils : quand active-t-on le plan ? (ex. : indisponibilité du SaaS RH > 2h, chiffrement détecté sur > 3 endpoints, perte de connectivité WAN > 4h).
2. Matrice de rôles RACI : DSI = responsable technique, dirigeant = responsable communication externe, DRH = coordination RH, juriste/fiduciaire = notification PFPDT. Chaque rôle avec un numéro de téléphone direct et un backup.
3. Inventaire critique (tableau 5 lignes max) : les 5 systèmes sans lesquels l'entreprise ne fonctionne pas. Pour chaque système : RTO cible, RPO cible, lieu de la sauvegarde, procédure de restauration (lien vers runbook séparé).
4. Procédure de notification nLPD : qui décide qu'il y a violation, qui rédige la notification, via quelle adresse (formulaire PFPDT), dans quel délai. Inclure le lien direct vers la page de notification du PFPDT.
5. Communication de crise : template d'e-mail client (3 phrases), message Slack/Teams interne, contact assurance cyber (N° de police, N° d'urgence 24/7).
6. Dates de test et de révision : deux fenêtres par an (ex. : semaine 12 et semaine 40), avec nom du responsable du test et format retenu (tabletop exercise ou test de restauration réel).

RTO et RPO : définir des cibles réalistes

Pour une PME de 20 à 150 employés, des valeurs atteignables sans infrastructure enterprise sont :

• RTO : 4 à 8 heures pour les systèmes critiques (ERP, messagerie), 24 à 48 heures pour les systèmes secondaires.
• RPO : 1 heure si les sauvegardes sont incrémentales toutes les heures sur un stockage immuable (Veeam avec Object Lock, Backblaze B2 avec versioning verrouillé), 24 heures pour les archives.

Ces valeurs doivent être cohérentes avec votre fréquence de sauvegarde réelle — pas avec ce que vous aimeriez qu'elle soit. Si votre backup tourne une fois par nuit à 02h00 et que vous n'avez pas de snapshot intraday, votre RPO réel est de 22 à 24 heures. Écrivez-le clairement.

Tester deux fois par an : protocoles concrets

Un plan non testé est une illusion de sécurité. Le NCSC recommande aux PME de valider leurs procédures de sauvegarde et de restauration au moins annuellement. Deux fois par an est le minimum pour rester cohérent avec un paysage de menaces qui évolue tous les trimestres.

Test S1 (semaine 12) : tabletop exercise de 2 heures

Réunir le RACI en salle (ou en visio). Lire un scénario réaliste à voix haute (ex. : « Il est 08h30 un lundi, le responsable IT reçoit une alerte Defender — 12 machines Windows 11 affichent une note de rançon. »). Faire jouer chaque rôle en temps réel :

1. Le DSI isole les endpoints affectés (procédure de quarantaine : débrancher du réseau ou désactiver le port switch, pas éteindre les machines pour préserver la RAM).
2. Le dirigeant appelle l'assurance cyber dans les 30 minutes.
3. Le juriste identifie si des données nLPD sont concernées et prépare la notification PFPDT.
4. La DRH envoie le message interne en moins de 20 minutes.

Chronomètres en main, noter les écarts entre le plan et la réalité. Mettre à jour le one-pager dans les 5 jours ouvrables suivants.

Test S2 (semaine 40) : restauration réelle

Choisir un système non critique (poste de travail ou VM de test) et effectuer une restauration complète depuis la sauvegarde hors-site. Mesurer le RTO effectif. Vérifier l'intégrité des données restaurées. Ce test révèle systématiquement des problèmes invisibles lors du tabletop : credentials expirés pour le stockage cloud, version du client de backup incompatible, ou sauvegarde silencieusement corrompue depuis 6 semaines.

Les erreurs les plus fréquentes dans les PME romandes

• Sauvegardes sur le même réseau que la production : un ransomware qui se propage latéralement chiffre aussi le NAS local. La règle 3-2-1 (3 copies, 2 supports, 1 hors-site) reste le minimum, avec au moins une copie immuable (Object Lock S3 ou bandes air-gappées).
• Plan connu d'une seule personne : si le DSI est en vacances ou fait partie des victimes de l'incident (burnout post-attaque), personne d'autre ne sait quoi faire. Le RACI doit avoir deux noms par rôle.
• Pas de liste des contacts externes : numéro de l'hébergeur, du prestataire MSP, de l'assurance cyber, du CERT cantonal, du forensics externe — tout doit être sur papier dans un classeur physique. Si le réseau est coupé, votre SharePoint ne vous aide pas.
• Notification nLPD omise ou tardive : en cas de contrôle ou de plainte d'un client, l'absence de notification documentée aggrave la position légale. Le PFPDT peut recommander des mesures correctives ou transmettre à d'autres autorités.
• RTO irréaliste : écrire « RTO : 1 heure » pour un ERP qui n'a jamais été restauré en moins de 6 heures crée une fausse confiance et des engagements contractuels intenables vis-à-vis des clients.

Cas pratique : bureau d'études VD, 55 endpoints, test de restauration raté puis réussi

Un bureau d'ingénieurs civils basé à Lausanne, 55 collaborateurs, 55 endpoints (40 Windows 11 23H2, 10 macOS 14 Sonoma, 5 Linux Ubuntu 22.04 pour les calculs FEM), gère des projets avec des données personnelles de mandants (donc soumis à la nLPD). Leur ERP de gestion de projet est hébergé on-premise sur un serveur Dell PowerEdge sous Windows Server 2022.

Situation initiale (janvier 2024)

Sauvegarde : Veeam Backup & Replication 12, backup nightly à 01h00, cible = NAS Synology sur le LAN. Pas de copie hors-site. RTO annoncé dans un document Word de 2021 : « 2 heures ». Plan de continuité : 18 pages, jamais testé depuis sa rédaction.

Test S1 — tabletop (mars 2024) : résultats

Scénario joué : chiffrement du serveur ERP détecté à 08h45. Constats :

• Le DSI a retrouvé les credentials Veeam après 35 minutes (stockés uniquement dans son gestionnaire de mots de passe personnel).
• Personne dans l'équipe ne savait que la sauvegarde ciblait le NAS local — donc potentiellement chiffrable par le même ransomware.
• Aucun numéro d'urgence de l'assurance cyber dans le plan (le numéro était dans un e-mail de 2022).
• La notification PFPDT n'était pas mentionnée dans le plan — le dirigeant ne savait pas que cela s'appliquait à leur cas.

Durée du tabletop : 2h10. Actions correctives engagées dans les 10 jours : ajout d'une copie Veeam vers un bucket S3 avec Object Lock 30 jours (coût : ~85 CHF/mois pour 2 To), credentials partagés dans Bitwarden Teams (5 CHF/utilisateur/mois), one-pager rédigé depuis zéro, numéros d'urgence imprimés et collés dans la baie réseau.

Test S2 — restauration réelle (octobre 2024) : résultats

Restauration de la VM ERP depuis le bucket S3 sur un hyperviseur de test (Proxmox 8.1). RTO mesuré : 4h22. RPO effectif constaté : 23h50 (la sauvegarde nightly avait échoué silencieusement deux nuits avant à cause d'un certificat expiré — détecté grâce au test). Correction : alertes Veeam redirigées vers une boîte mail d'équipe, pas uniquement vers le DSI. Certificat renouvelé. Plan mis à jour avec RTO réel de 5 heures (marge de sécurité incluse) au lieu de « 2 heures ».

Coût total des deux tests et des corrections : environ 3 200 CHF (temps interne inclus). Coût évité estimé d'un incident réel sans plan opérationnel : 35 000 à 70 000 CHF selon les simulations d'assurance.

Récapitulatif opérationnel

1. Réduire le plan de continuité existant à une page lisible : 6 blocs (déclencheurs, RACI, inventaire critique, procédure nLPD, communication, dates de test). Archiver l'ancien document séparément.
2. Vérifier que chaque rôle RACI a un backup nominatif avec numéro mobile direct — pas un alias e-mail.
3. Appliquer la règle 3-2-1 avec au moins une copie immuable hors-site (Object Lock S3 ou bande air-gappée). Valider que le budget mensuel est provisionné.
4. Inscrire deux dates de test dans le calendrier de l'entreprise avant fin janvier de chaque année. Nommer un responsable du test avec mandat formel.
5. Planifier le test S1 (tabletop, 2h) avec scénario ransomware ou panne majeure. Chronométrer chaque rôle. Mettre à jour le plan dans les 5 jours.
6. Planifier le test S2 (restauration réelle) sur un système non critique. Mesurer le RTO et RPO effectifs. Corriger les écarts avec les valeurs déclarées.
7. Intégrer la procédure de notification nLPD dans le plan : critère de déclenchement, rédacteur de la notification, délai cible (72h), lien vers le formulaire PFPDT.
8. Imprimer le one-pager et l'afficher physiquement dans la salle serveur et dans un classeur d'urgence hors du bureau (domicile du DSI ou coffre).
9. Après chaque test, archiver le compte-rendu (écarts, corrections, RTO/RPO mesurés) pour constituer une preuve de diligence en cas de contrôle nLPD ou d'audit assurance.
10. Réviser le plan à chaque changement majeur d'infrastructure (migration cloud, nouveau SaaS critique, départ du DSI) — ne pas attendre le prochain test planifié.

SynGuard accompagne les PME romandes dans la mise en conformité de leur gestion d'endpoints et la structuration de leur posture de continuité IT.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023, arts. 8 et 24 sur la sécurité et la notification.
• Notifications au PFPDT — edoeb.admin.ch — Procédure officielle de notification en cas de violation de données personnelles.
• NCSC — Informations pour les entreprises — Recommandations du Centre national pour la cybersécurité à destination des PME suisses.
• CIS Controls — cisecurity.org — Référentiel de contrôles de sécurité incluant les exigences de sauvegarde et de plan de continuité (Control 11).
• NIST Cybersecurity Framework — nist.gov — Cadre de référence pour la gestion du risque cyber, fonctions Recover et Respond applicables aux plans de continuité.