400 000 dirhams de rançon exigés, 12 jours d'arrêt de production, et une seule question que personne n'avait posée en comité de direction : "si nos serveurs sont chiffrés demain matin, combien de temps avant qu'on reparte ?" Cette scène se répète chaque mois dans des entreprises marocaines de toutes tailles. La prévention, pare-feu, Zero Trust, sensibilisation, reste indispensable, mais elle ne répond pas à cette question. Seul un plan de continuité d'activité (PCA) et un plan de reprise d'activité (PRA) correctement conçus le font. Et depuis la mise à jour de la Directive Nationale de la Sécurité des Systèmes d'Information (DNSSI) en 2023, ce n'est plus seulement une bonne pratique : c'est, pour un nombre croissant d'organisations, une obligation documentée.
Pourquoi la prévention seule ne suffit plus
Pendant longtemps, la cybersécurité d'entreprise s'est construite autour d'une hypothèse implicite : empêcher l'intrusion. Or les ransomwares modernes ne se contentent plus de chiffrer des postes de travail isolés. Ils se propagent latéralement pendant des semaines, exfiltrent les données avant de les chiffrer, puis s'attaquent spécifiquement aux sauvegardes connectées au réseau pour empêcher toute restauration rapide. C'est cette dernière étape qui transforme un incident gérable en crise existentielle : sans copie de secours saine et isolée, une entreprise n'a plus d'autre choix que de payer, de reconstruire à partir de rien, ou de fermer.
Le raisonnement des directions IT a donc évolué. La question n'est plus seulement "comment empêcher l'attaque ?" mais "combien de temps pouvons-nous survivre sans nos systèmes, et comment les restaurer avant que ce délai n'expire ?". C'est exactement l'objet d'un couple PCA/PRA et c'est un chantier distinct de la gestion des identités abordée dans notre article sur l'identité et le Zero Trust, qui protège l'accès, pas la capacité de reprise.
Le cadre réglementaire marocain : Loi 05-20, DGSSI et DNSSI
Le Maroc dispose depuis 2020 d'un arsenal juridique dédié à la cybersécurité, structuré autour de trois textes qu'il est utile de distinguer clairement.
La Loi n° 05-20 relative à la cybersécurité
Promulguée en 2020 et complétée par son décret d'application n° 2-21-406 (2021), cette loi pose le cadre général des mesures organisationnelles et techniques attendues des entités publiques et des infrastructures d'importance vitale (IIV), tout en structurant la coordination nationale de prévention et de réponse aux incidents.
La DGSSI, autorité de référence
La Direction Générale de la Sécurité des Systèmes d'Information (DGSSI), rattachée à l'Administration de la Défense Nationale, pilote la politique nationale de cybersécurité depuis sa création en 2011. Elle publie les référentiels, homologue les prestataires d'audit, et opère le centre de veille et de réponse aux incidents maCERT.
La DNSSI, le "comment" opérationnel
La Directive Nationale de la Sécurité des Systèmes d'Information traduit la loi en mesures concrètes. Une première version date de 2014 ; la version actuellement en vigueur a été diffusée par circulaire du Chef du Gouvernement en janvier 2023. Elle introduit une classification des systèmes d'information en trois classes de sensibilité (A, B, C) établie conjointement avec la DGSSI, qui détermine l'intensité des mesures exigées et la fréquence des audits obligatoires — au minimum tous les deux ans pour les systèmes classifiés.
Qui est concerné ?
Les administrations d'État, les établissements publics, les collectivités territoriales et les infrastructures d'importance vitale (IIV) publiques ou privées sont directement soumis à la DNSSI. Une PME privée non classifiée IIV n'est pas juridiquement tenue aux mêmes obligations — mais dès qu'elle contracte avec un donneur d'ordre public ou une IIV, les exigences de sécurité se propagent contractuellement le long de la chaîne de sous-traitance. La DNSSI devient alors, de facto, la grille de lecture du marché.
Cette logique de propagation rejoint une dynamique que nous avions déjà observée dans notre article sur le Shadow IT et la Loi 09-08 : la conformité marocaine ne se limite plus aux grandes structures classées, elle irrigue progressivement tout l'écosystème des prestataires.
Anatomie d'une attaque et coût de l'absence de PCA/PRA
Une intrusion par ransomware suit généralement un scénario en quatre temps : accès initial (le plus souvent par hameçonnage ciblé sur une boîte mail), propagation latérale silencieuse durant plusieurs jours à semaines, exfiltration des données sensibles, puis déclenchement du chiffrement — souvent un vendredi soir ou pendant un jour férié, au moment où les équipes de surveillance sont réduites.
Le coût réel ne se limite jamais à la rançon elle-même. Il faut compter la perte de productivité pendant l'arrêt, la reconstruction manuelle des systèmes, la notification réglementaire aux autorités et aux personnes concernées si des données personnelles ont fuité (obligation qui recoupe directement les exigences de la gouvernance des données déjà couverte sur ce blog), et le coût de réputation auprès des clients et partenaires. C'est précisément ce cumul de coûts indirects qui justifie, aux yeux d'un comité de direction, l'investissement dans un PCA/PRA construit en amont plutôt que dans une gestion de crise improvisée.
Construire un PCA/PRA robuste : la méthode
Un plan de continuité d'activité et un plan de reprise d'activité ne sont pas des documents que l'on rédige une fois puis que l'on archive. Ce sont des dispositifs vivants, testés et mesurés. La norme internationale ISO/IEC 27031, qui traite spécifiquement de la préparation des technologies de l'information à la continuité d'activité, ainsi que le guide méthodologique publié par la DGSSI sur l'élaboration des plans de continuité et de reprise, fournissent le socle méthodologique de référence.
1. L'analyse d'impact métier (BIA)
Avant toute mesure technique, il faut hiérarchiser les processus métier par criticité : quel système, s'il tombe, arrête la facturation, la production, ou la relation client dans l'heure ? Cette analyse détermine où concentrer l'effort et le budget.
2. Définir RTO et RPO par système
Le RTO (Recovery Time Objective) fixe le délai maximal tolérable avant restauration d'un système. Le RPO (Recovery Point Objective) fixe la perte de données maximale acceptable, exprimée en temps depuis la dernière sauvegarde valide. Un ERP de facturation et un serveur de fichiers d'archives n'ont évidemment pas les mêmes exigences — et c'est cette granularité qui évite de sur-investir partout ou de sous-protéger l'essentiel.
3. La règle de sauvegarde 3-2-1(-1)
Trois copies des données, sur deux supports différents, dont une hors site et, face aux ransomwares modernes qui ciblent activement les sauvegardes connectées, une copie immuable ou déconnectée du réseau (air-gapped). C'est ce dernier point qui fait souvent la différence entre une entreprise qui redémarre en 48 heures et une entreprise qui négocie avec des attaquants.
4. Tester, pas seulement documenter
Un plan jamais testé est une hypothèse, pas une garantie. Des exercices de crise réguliers, restauration réelle d'un serveur test, simulation de bascule révèlent systématiquement des angles morts : dépendances oubliées, comptes de secours ("break-glass") expirés, documentation obsolète. La DNSSI elle-même recommande l'organisation régulière d'exercices de crise et la formalisation de comptes rendus transmis à la DGSSI pour les entités concernées.
L'écosystème Microsoft au service de la résilience
Pour les organisations déjà engagées sur Microsoft 365 et Azure, le socle technologique de la majorité de nos clients plusieurs briques natives permettent de construire un PCA/PRA sans multiplier les fournisseurs.
| Brique | Rôle dans la résilience |
|---|---|
| Azure Backup / Azure Site Recovery | Sauvegarde centralisée et réplication de charges de travail critiques vers une région secondaire, avec définition de RTO/RPO par politique |
| Microsoft Purview | Cartographie et classification des données sensibles, essentielle pour prioriser la protection selon la criticité identifiée en phase de BIA |
| Microsoft Defender for Cloud / XDR | Détection précoce de mouvements latéraux avant le déclenchement du chiffrement |
| Microsoft Sentinel | Corrélation des signaux et orchestration de la réponse à incident (SIEM/SOAR) |
| Comptes d'accès d'urgence Entra ID | Comptes "break-glass" isolés du système d'authentification principal, testés régulièrement |
Ces briques ne remplacent pas la méthode : elles l'exécutent. Un tableau de bord Sentinel sans BIA préalable ne dit rien de ce qui est réellement critique. C'est le même principe que nous développions dans notre article sur l'observabilité des systèmes distribués: la donnée technique n'a de valeur que rattachée à un enjeu métier clairement défini.
Feuille de route pour les DSI marocains
- Cartographier votre exposition réglementaire — êtes-vous IIV, sous-traitant d'une IIV, ou prestataire d'une administration ? Cela détermine le niveau d'exigence applicable.
- Lancer une analyse d'impact métier (BIA) sur les 10 à 15 processus les plus critiques, pas sur l'ensemble du système d'information.
- Fixer des RTO/RPO réalistes et budgétés — un RTO de 15 minutes coûte largement plus cher qu'un RTO de 4 heures ; alignez l'ambition sur le risque réel.
- Déployer une sauvegarde immuable ou déconnectée pour les systèmes classés critiques, distincte de la sauvegarde de production.
- Planifier un exercice de crise annuel minimum, avec restitution documentée, c'est aussi une exigence DNSSI pour les entités concernées.
- Traiter la dette technique en parallèle : un système legacy mal documenté est presque toujours le maillon qui fait échouer une restauration, comme nous le détaillions dans notre article sur la dette technique.
Questions fréquentes
Quelle est la différence entre un PCA et un PRA ?
Le PCA (plan de continuité d'activité) couvre l'ensemble de l'organisation et vise à maintenir les fonctions métier essentielles pendant une crise, avec ou sans les systèmes informatiques habituels. Le PRA (plan de reprise d'activité) est le volet spécifiquement informatique du PCA : il décrit comment restaurer techniquement les systèmes, applications et données après un sinistre.
Une PME marocaine non classée IIV doit-elle se conformer à la DNSSI ?
Pas juridiquement, dans les mêmes termes qu'une entité classée. Mais dès qu'elle répond à des appels d'offres publics, travaille avec une infrastructure d'importance vitale, ou souhaite rassurer des partenaires et assureurs, la DNSSI devient la référence de marché la plus naturelle à laquelle s'aligner, même de façon proportionnée aux risques réels.
Faut-il payer la rançon en cas d'attaque réussie ?
La plupart des autorités de cybersécurité déconseillent le paiement : rien ne garantit la restitution des données, l'opération finance l'écosystème criminel, et elle ne traite pas la cause racine de l'intrusion. Un PCA/PRA testé est la meilleure alternative, car il rend le paiement optionnel plutôt qu'obligatoire.
À quelle fréquence faut-il tester son plan de reprise ?
Au minimum une fois par an pour les systèmes critiques, avec des tests plus fréquents (trimestriels) pour les composants à fort taux de changement. La DNSSI recommande par ailleurs des audits réguliers, au minimum biennaux, pour les systèmes classifiés.
Quel est le lien entre PCA/PRA et la Loi 09-08 sur les données personnelles ?
Les deux cadres sont complémentaires mais distincts : la Loi 09-08 et la CNDP protègent la confidentialité des données personnelles, tandis que la DNSSI et le PCA/PRA protègent la disponibilité et l'intégrité des systèmes. Un incident de sécurité mal maîtrisé peut cependant déclencher les deux obligations simultanément — d'où l'intérêt de traiter la gouvernance des données et la résilience opérationnelle comme un seul chantier.
Conclusion
La question n'est plus de savoir si une organisation marocaine sera un jour confrontée à une tentative de ransomware, mais quand et surtout, combien de temps il lui faudra pour repartir. Le cadre réglementaire national, avec la Loi 05-20 et la DNSSI, donne désormais une méthode structurée pour répondre à cette question, bien au-delà des seules entités formellement classées IIV. Pour une DSI marocaine équipée de l'écosystème Microsoft, les briques technologiques existent déjà : ce qui manque le plus souvent, c'est la méthode — BIA, RTO/RPO, sauvegarde immuable et tests réguliers — qui transforme ces outils en véritable résilience.
Vous ne savez pas si votre organisation entre dans le périmètre de la DNSSI, ou par où commencer votre PCA/PRA ?
Nos experts Microsoft et transformation digitale vous accompagnent dans le diagnostic et la mise en œuvre.
