Article 23 loi 09-08 : la sécurité obligatoire

L'article 23 de la loi n° 09-08 tient en une phrase. Le responsable du traitement doit prendre toutes les précautions utiles, eu égard à la nature des données et aux risques présentés par le traitement, pour préserver la sécurité des données et empêcher leur altération, leur perte ou leur accès par des tiers non autorisés. C'est tout. Pas de liste de mesures, pas de seuils chiffrés, pas de méthodologie imposée. La sobriété du texte cache la profondeur de l'obligation.

Cette ouverture rédactionnelle a un effet pratique double. D'un côté, elle permet à l'organisation de calibrer ses mesures de sécurité au regard de ses propres risques — pas de cahier des charges unique imposé. De l'autre, elle déplace la charge de la preuve : c'est à l'organisation de démontrer que les mesures retenues étaient adaptées à l'état de l'art au moment où l'incident s'est produit. Et l'état de l'art, lui, évolue vite.

Ce que dit l'état de l'art en 2026

Pour qu'on se comprenne, voici la baseline technique qu'on devrait pouvoir prouver sur n'importe quel site qui collecte la moindre donnée personnelle au Maroc en 2026. Ce n'est pas un idéal théorique, c'est ce qu'un auditeur ordinaire vérifie en premier — et ce qui sera reproché en cas de manquement.

Le chiffrement TLS sur l'ensemble du site, version 1.2 au minimum, version 1.3 recommandée. Aucune exception, y compris pour les pages publiques d'information. Le mythe selon lequel « la home n'a pas besoin de HTTPS » a disparu il y a une dizaine d'années dans la communauté technique. Il reste pourtant la configuration par défaut dans une fraction non négligeable des hébergements marocains.

Le HSTS (HTTP Strict Transport Security) avec inclusion des sous-domaines et preload. C'est l'instruction donnée au navigateur de refuser tout downgrade vers HTTP, y compris au premier contact. Sans HSTS, une attaque de type SSL stripping reste théoriquement possible — peu utilisée en pratique, mais l'absence est un signal de configuration laxiste.

Une Content-Security-Policy stricte. Au minimum default-src 'self', idéalement enrichie d'instructions par type de ressource. La CSP est la mesure défensive la plus efficace contre les attaques par injection de script (XSS). Elle exige un travail de configuration initial, mais c'est un investissement ponctuel qui paie pendant toute la durée de vie du site.

Les en-têtes HTTP de sécurité complets : X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy désactivant les API non utilisées (caméra, micro, géolocalisation, capteurs). Aucun de ces en-têtes ne coûte plus de cinq minutes à configurer ; leur absence est le marqueur le plus immédiat d'une configuration laissée par défaut.

La gestion des accès sur le principe du moindre privilège, avec authentification forte (MFA) pour les accès administrateurs. Pas de compte partagé, pas d'authentification par défaut, pas de mot de passe écrit en clair dans un wiki interne. Les comptes inactifs doivent être désactivés dans des délais raisonnables — typiquement quatre-vingt-dix jours pour les comptes salariés ayant quitté l'entreprise.

La journalisation des accès aux données sensibles, conservée dans un délai utile pour l'investigation post-incident — généralement six à douze mois, plus pour les secteurs régulés. Sans logs, l'organisation est aveugle ; en cas d'incident, elle ne peut ni reconstituer l'attaque, ni notifier précisément, ni démontrer ce qui n'a pas été affecté.

Les sauvegardes régulières, chiffrées, et — c'est la partie qu'on néglige — testées. Une sauvegarde qu'on n'a jamais restaurée est une fiction technique. Le test de restauration au moins annuel devrait être un rituel de gouvernance. Sans ça, on apprend en situation de crise que la sauvegarde n'est pas exploitable, généralement au pire moment.

L'anti-spoofing email via SPF, DKIM et DMARC avec une politique au moins en quarantaine, idéalement en reject. Un domaine sans DMARC en 2026 est un domaine que n'importe qui peut usurper pour envoyer des courriels en votre nom. Ce n'est pas un sujet périphérique : la majorité des incidents data majeurs commencent par du phishing exploitant une identité de domaine non protégée.

Tout cela est mesurable, scoré objectivement, et public. Le Mozilla Observatory donne un score lettré qui synthétise une bonne partie de ces points. L'OWASP fournit le cadre méthodologique pour aller plus loin (ASVS pour les applications avec authentification, MASVS pour le mobile). La CNIL publie des guides pratiques de sécurité qui restent un référentiel utile, même hors RGPD strict.

Le pont avec la conformité administrative

Là où les directions sous-estiment souvent la portée de l'article 23, c'est dans son articulation avec les formalités CNDP. Une déclaration F211 ou F112 qui décrit des mesures de sécurité ne devient pas une vérité par sa seule existence. Elle devient un engagement opposable. Si vous déclarez que vos sauvegardes sont chiffrées et testées chaque mois, et qu'un contrôle révèle qu'elles ne le sont pas, vous avez deux problèmes : le manquement sécurité et l'inexactitude déclarative. Le second aggrave le premier.

Ce constat change le travail de constitution des dossiers CNDP. Ce qui apparaît dans la rubrique « mesures de sécurité » doit refléter la réalité, pas une projection optimiste. Si la réalité est en retard sur ce que vous aimeriez décrire, il vaut mieux décrire l'existant et ajouter un plan d'évolution daté, plutôt que de cocher des cases qui mentent. La CNDP préfère la vérité documentée à la fiction polie — c'est cohérent avec sa doctrine de gradation.

La notification d'incident — la zone qui va bouger

Pour l'instant, la loi 09-08 n'impose pas une obligation explicite de notification de fuite de données à la Commission, contrairement à l'article 33 du RGPD qui fixe un délai de soixante-douze heures. La réforme attendue depuis plusieurs années devrait introduire une disposition équivalente, alignée sur le standard européen. En attendant, la pratique recommandée — que la CNDP encourage dans ses délibérations publiques et que l'EDPB documente dans ses guidelines — est de notifier en cas d'incident significatif, par diligence.

Concrètement, cela veut dire avoir préparé en amont une procédure de notification : qui prend la décision, dans quel délai, vers quel canal (CNDP en parallèle, le cas échéant, des autorités européennes si exposition RGPD), avec quel template, quelle communication aux personnes concernées si nécessaire. Construire cette procédure dans le calme prend une journée ; la construire pendant un incident en prend trois ou quatre, avec des erreurs.

Dans la presse économique marocaine (Médias24, TelQuel), les incidents data publiés montrent presque invariablement le même schéma. Un incident technique évitable. Une découverte tardive. Une communication mal calée. Une CNDP qui doit reconstruire les faits à partir de bribes contradictoires. Une réputation qui paie le coût final. Tout cela est largement préventible, et c'est précisément ce que vise l'article 23 par sa formulation ouverte.

L'audit comme rituel, pas comme événement

L'erreur de positionnement la plus courante consiste à traiter la sécurité comme un événement ponctuel — un audit fait il y a deux ans, des correctifs déployés depuis, plus aucun suivi. C'est inadapté au rythme du Web. Un site sécurisé en 2024 peut être vulnérable en 2026 simplement parce que les standards ont avancé et que la stack technique a accumulé des dépendances obsolètes.

Le rythme défendable, c'est un audit annuel complet, complété d'un scan automatique mensuel des en-têtes et des dépendances. La majorité des dégradations peut être détectée par observation passive. L'audit annuel sert à creuser les sujets qui n'apparaissent pas dans le scan : qualité du code, gestion des permissions internes, configuration des services tiers, pertinence des journaux conservés.

Pour les applications qui exposent une authentification, du paiement ou des API, on ajoute un pentest tous les deux à trois ans. Pas chaque année si le périmètre n'a pas changé substantiellement — ce serait théâtral. Mais pas tous les cinq ans non plus. La fenêtre de deux à trois ans correspond à la durée de vie typique d'une architecture applicative non triviale.

Notre propre posture, opposable

Chez DataSouv on applique à nous-mêmes ce qu'on préconise — c'est l'engagement public consigné sur la page /securite. Score Mozilla Observatory visé A+, en-têtes HTTP complets publiés en clair, registre des traitements affiché publiquement, security.txt en place, aucun tracker tiers, hébergement européen. Si on dit que c'est faisable et utile, on le montre.

L'objectif n'est pas l'exhibition. C'est la cohérence. Une organisation qui vend la sécurité et la conformité sans les appliquer à elle-même envoie le signal le plus dommageable qui soit. Le marché marocain a vu cette contradiction trop souvent. C'est l'un des arguments simples qui distinguent les acteurs sérieux des acteurs opportunistes — et c'est, à coût quasi nul, l'un des leviers de différenciation les plus efficaces.

Ressources

• Mozilla Observatory — scoring objectif des en-têtes HTTP
• OWASP ASVS — niveaux de vérification applicatifs
• CNIL — guides sécurité — doctrine européenne comparée
• EDPB — guidelines incident — bonnes pratiques notification
• Site officiel CNDP
• Guide pilier — Conformité CNDP au Maroc 2026
• Notre posture de sécurité publique
• Service — Audit sécurité technique

L'article 23 est court ; ce qu'il recouvre ne l'est pas. La meilleure défense face à son ambiguïté, c'est la documentation. Documenter les mesures, documenter les revues, documenter les correctifs, documenter les exceptions et leurs justifications. Une organisation qui peut produire en deux clics un dossier de sécurité complet montre, indépendamment du résultat de l'audit, qu'elle prend ses obligations au sérieux. C'est ce que la doctrine de la CNDP valorise. C'est aussi ce qui transforme une dépense de conformité en un actif de gouvernance.

Salma O. — spécialiste sécurité applicative, contributrice DataSouv. Article relu et validé par Amine Rais, fondateur.