Loi 25-11 : 5 jours pour déclarer une fuite de données. Saurez-vous seulement que vous en avez une ?
Imaginez un vendredi soir. Le site de votre entreprise fonctionne normalement, vos clients passent commande, personne ne s’inquiète. Pourtant, depuis trois semaines, quelqu’un copie discrètement votre base clients : noms, numéros de téléphone, adresses, historiques d’achat. Personne ne l’a remarqué. Pas d’alerte, pas de message de rançon, rien.
Posez-vous maintenant la question que la loi algérienne vous pose depuis juillet 2025 : à quel moment saurez-vous qu’il y a eu une violation de données, et qui préviendra l’autorité dans les délais ?
Ce n’est plus une question théorique. Selon des estimations de Kaspersky, l’Algérie aurait subi plus de 70 millions de cyberattaques en 2024. Et depuis la loi 25-11, une entreprise qui traite des données personnelles ne peut plus se contenter d’espérer que tout va bien.
Ce qui a changé, en deux minutes
La loi n° 25-11 du 24 juillet 2025 modifie et complète la loi 18-07 du 10 juin 2018, qui encadre le traitement des données à caractère personnel. L’essentiel à retenir :
- Un délégué à la protection des données (DPD) obligatoire, pour les responsables de traitement comme pour les autorités concernées. L’ANPDP a déjà publié une première délibération qui précise les conditions de nomination et les missions du délégué.
- Une notification des violations de données à l’ANPDP, avec un délai de 5 jours.
- Des analyses d’impact pour les traitements à risque.
- De nouvelles notions dans la loi : données biométriques, profilage, pseudonymisation, violation de données.
- Des garde-fous sur les transferts de données hors d’Algérie.
À cela s’ajoute un principe déjà posé par la loi 18-07 : tout traitement de données personnelles est soumis à une déclaration préalable auprès de l’ANPDP, ou à son autorisation selon les cas.
Violation de données : ce qui compte vraiment, et qui est concerné
Beaucoup de dirigeants imaginent une violation de données comme un piratage spectaculaire. En pratique, le périmètre est plus large : tout incident qui expose, fait disparaître, modifie ou rend inaccessible des données personnelles sans autorisation peut poser la question de la notification. La notion de « violation de données » figure désormais parmi les définitions de la loi : référez-vous au texte pour la formulation exacte.
Quelques situations courantes :
- un fichier clients envoyé par erreur au mauvais destinataire ;
- un ordinateur portable ou un téléphone professionnel perdu ou volé, sans chiffrement ;
- un ransomware qui chiffre une base contenant des données de clients ou de salariés ;
- une base de données exposée par erreur sur internet ;
- un ancien salarié qui conserve ses accès et copie des fichiers.
Qui est concerné ? La loi 18-07 encadre le traitement des données personnelles par les organismes publics comme privés. Si vous détenez des données sur des personnes physiques (clients, patients, élèves, salariés, candidats, abonnés), vous êtes très probablement dans son champ. Les données relevant de la défense et de la sécurité nationales suivent un régime spécifique.
Le vrai problème n’est pas de notifier. C’est de détecter.
Une entreprise ne peut déclarer que ce qu’elle sait. Et savoir suppose d’avoir mis en place, avant l’incident, les moyens de voir ce qui se passe.
Si vous dirigez une entreprise, voici trois questions simples à poser à vos équipes dès cette semaine :
- Qui est alerté quand quelque chose d’anormal se produit sur nos systèmes, y compris un samedi à 3 h du matin ?
- Qui décide qu’il s’agit d’une violation de données personnelles, et sur quels critères ?
- Qui rédige et envoie la notification, avec quelles informations, en combien de temps ?
Si les réponses sont floues, le délai de 5 jours sera très court. Le point de départ exact du délai et le contenu attendu de la notification sont à valider avec votre conseil juridique, mais votre procédure interne doit les anticiper.
Pour les DSI : traduire la loi en exigences techniques
| Exigence | En clair | Ce que ça implique côté système d’information |
|---|---|---|
| Notification des violations (5 jours) | Prévenir l’ANPDP vite, avec des faits | Journalisation centralisée (serveurs web, applications, bases de données, VPN, annuaire), rétention suffisante, alertes sur les comportements anormaux (exports massifs, connexions hors horaires, élévations de privilèges), procédure de réponse à incident documentée et testée |
| Délégué à la protection des données | Un référent compétent et indépendant | Registre des traitements à jour, cartographie des bases et des flux de données sur laquelle le délégué peut s’appuyer |
| Analyse d’impact | Évaluer le risque avant de lancer un projet | Revue d’architecture et test d’intrusion en amont des projets sensibles (biométrie, profilage, gros volumes de données) |
| Mesures de sécurité (loi 18-07) | Protéger contre le vol et l’accès non autorisé | Chiffrement en transit et au repos, authentification multifacteur, moindre privilège, gestion des correctifs, sauvegardes isolées et testées |
| Transferts hors d’Algérie | Savoir où vont les données | Inventaire des SaaS et clouds utilisés (messagerie, CRM, emailing, analytics, hébergeur), révision des contrats de sous-traitance, étude des options d’hébergement local |
Un point d’organisation à ne pas négliger : l’ANPDP insiste sur l’autonomie du délégué, à qui l’on ne doit pas confier de missions incompatibles avec la protection des données. Désigner le DSI comme DPD, c’est lui demander de contrôler les systèmes qu’il administre lui-même. La question mérite d’être examinée sérieusement.
Les failles qui transforment un incident en violation de données
Dans les audits web, API et réseau, les mêmes familles de failles reviennent. Chacune peut suffire à déclencher l’obligation de notification :
- CMS et plugins non mis à jour (WordPress en tête) : un plugin vulnérable donne accès à la base de données.
- API sans contrôle d’accès rigoureux : en changeant simplement un identifiant dans une requête, un utilisateur lit les données d’un autre client. Sans journalisation, personne ne le voit.
- Sauvegardes et exports oubliés sur le serveur web (fichiers .sql, .zip) : téléchargeables par n’importe qui connaissant l’adresse.
- Interfaces d’administration exposées sur internet (panneaux d’admin, outils de gestion de base de données).
- Comptes administrateurs sans authentification multifacteur, avec des mots de passe réutilisés ailleurs.
- Secrets dans le code ou les dépôts : clés d’API, mots de passe de base de données.
- Active Directory insuffisamment durci : à partir d’un seul compte compromis, un attaquant peut atteindre les droits d’administrateur du domaine, et donc toutes les données.
Le point commun : dans la plupart de ces cas, l’entreprise ne s’en aperçoit qu’au moment où un tiers l’en informe.
Détecter concrètement : quoi journaliser, quoi surveiller
Pour un DSI, la détection repose sur deux choses : collecter les bons journaux, et savoir quelles anomalies méritent une alerte.
| Source | À collecter | Signaux à alerter |
|---|---|---|
| Serveur web / reverse proxy | Requêtes HTTP, codes de réponse, adresses IP, user-agent | Pics d’erreurs 401, 403, 404 ou 500, énumération d’URL, téléchargement de fichiers sensibles (.sql, .zip, .bak), motifs d’injection dans les requêtes |
| Application et API | Authentifications, accès aux ressources par identifiant, erreurs d’autorisation | Un même compte qui lit des centaines d’identifiants différents, accès à des ressources d’un autre utilisateur, exports en masse |
| Base de données | Connexions, requêtes d’administration, volumes lus | Connexion depuis une machine inhabituelle, requêtes de lecture très volumineuses, création de comptes |
| Active Directory | Authentifications, modifications de groupes, comptes à privilèges | Ajout d’un compte aux groupes d’administration, rafales d’échecs de connexion, connexions hors horaires |
| VPN et accès distants | Connexions, origine géographique, durée | Pays inhabituel, deux connexions géographiquement incompatibles, accès à des heures atypiques |
| Messagerie | Règles de transfert, connexions, volumes d’envoi | Création d’une règle de transfert automatique vers l’extérieur, envoi massif de pièces jointes, connexions suspectes |
| Sauvegardes | Journaux des tâches, suppressions | Suppression ou modification de sauvegardes, échecs répétés, arrêt du service |
Trois règles pratiques :
- Centraliser hors de la machine surveillée. Un attaquant qui prend la main sur un serveur efface d’abord ses journaux locaux. Des outils open source comme Wazuh, Graylog ou la pile ELK permettent de le faire sans licence coûteuse.
- Synchroniser les horloges (NTP) de tous les systèmes. Sans cela, reconstituer la chronologie d’un incident devient un casse-tête.
- Commencer petit. Cinq ou six alertes réellement traitées valent mieux que deux cents ignorées. Chaque alerte doit avoir un responsable et une action associée.
Exemple de déroulé sur 5 jours
Voici une trame de procédure à adapter à votre structure. Le point de départ exact du délai et le contenu attendu de la notification sont à valider avec votre conseil juridique et l’ANPDP.
- Heure 0 : détecter et qualifier. Une alerte arrive. L’incident est-il confirmé ? Des données personnelles sont-elles concernées ? Ouvrez dès la première minute un registre d’incident : qui a fait quoi, quand.
- Premières heures : contenir. Isolez les machines et les comptes touchés, révoquez les accès et les secrets compromis. N’éteignez pas et n’effacez pas ce qui sert de preuve : conservez les journaux et, si possible, une copie des systèmes concernés.
- Jour 1 : informer en interne. Direction, délégué à la protection des données, juridique. Désignez un responsable de crise unique.
- Jours 1 et 2 : mesurer l’impact. Quelles données, combien de personnes, quel niveau de sensibilité (identité, santé, biométrie, données financières) ? L’exposition est-elle confirmée ou seulement probable ? C’est ici que la cartographie faite à l’avance fait gagner un temps précieux.
- Jours 2 à 4 : préparer la notification. En règle générale : nature de la violation, catégories de données et de personnes touchées, conséquences probables, mesures prises, coordonnées du délégué. Évaluez aussi si les personnes concernées doivent être informées.
- Avant la fin du délai : notifier l’ANPDP et conservez la preuve de l’envoi.
- Ensuite : corriger et documenter. Cause racine, correctifs, retour d’expérience et mise à jour de la procédure.
Et dans le secteur public ?
Le décret présidentiel n° 26-07 du 7 janvier 2026, publié au Journal officiel le 21 janvier, définit l’organisation et le fonctionnement des structures de cybersécurité au sein des institutions, administrations et organismes publics. Chaque institution doit disposer d’une entité dédiée, placée sous l’autorité directe de son premier responsable, qui coordonne les actions de cybersécurité et de protection des données.
Pour les entreprises qui travaillent avec le secteur public, il est raisonnable de s’attendre à ce que ces entités attendent de leurs prestataires un niveau de sécurité démontrable.
Questions fréquentes des dirigeants
« Nous sommes une petite structure. Est-ce que cela nous concerne ? » Ce qui déclenche la loi, c’est la présence de données personnelles, pas la taille de l’entreprise. Une boutique en ligne, un cabinet, une clinique ou une école qui conserve des données de clients, patients, élèves ou salariés est concerné.
« Notre site est hébergé à l’étranger, ou nous utilisons des outils cloud étrangers. Est-ce un problème ? » Pas forcément, mais la loi encadre les transferts de données hors d’Algérie. Commencez par savoir quelles données partent où : messagerie, CRM, emailing, analytics, hébergeur. Vérifiez ensuite les conditions applicables auprès de l’ANPDP ou d’un conseil juridique.
« Un prestataire gère notre site. Qui est responsable en cas de fuite ? » En principe, le responsable du traitement reste tenu de protéger les données, même s’il confie la technique à un tiers. Encadrez la relation par un contrat qui prévoit des mesures de sécurité, un délai d’alerte en cas d’incident et un droit d’audit.
« Un antivirus et un pare-feu suffisent-ils ? » Non. Ils bloquent une partie des attaques, mais ne disent pas ce qui s’est passé quand l’une d’elles passe. L’enjeu de la loi est autant la détection et la réaction que la prévention.
« Par où commencer avec un petit budget ? » Trois actions couvrent une grande partie des scénarios courants : l’authentification multifacteur sur la messagerie et les comptes d’administration, des sauvegardes hors ligne testées, et la centralisation des journaux du site et des accès.
Checklist : que faire dans les 30 prochains jours
- Désigner le délégué à la protection des données, formaliser son rôle et communiquer ses coordonnées à l’ANPDP.
- Cartographier : quelles données personnelles, où elles sont stockées, qui y accède, quels outils cloud et SaaS sont utilisés.
- Activer et centraliser les journaux des systèmes exposés (site, API, base de données, VPN, annuaire) et définir quelques alertes simples mais utiles.
- Écrire la procédure de réponse à incident : qui fait quoi, dans quel ordre, avec un modèle de notification prêt. Faire ensuite un exercice à blanc d’une heure.
- Sécuriser les bases : authentification multifacteur sur la messagerie et les comptes d’administration, correctifs à jour, sauvegardes hors ligne testées.
- Faire auditer ce qui est exposé : un test d’intrusion web et API montre ce qu’un attaquant verrait réellement, avant qu’il ne le fasse.
En conclusion
La loi 25-11 ne demande pas la perfection. Elle demande de la maîtrise : savoir quelles données vous détenez, où elles se trouvent, qui peut y accéder, et être capable de s’en rendre compte quand quelque chose tourne mal.
Chez Yamoa Solutions, nous réalisons des audits techniques (test d’intrusion web, application mobile, API, réseaux, Active Directory, analyse forensique) et fonctionnels (analyse de risque, PCA/PRA, ISO 27001). Contactez-nous pour un diagnostic de votre exposition technique et de votre capacité de détection.
Cet article est fourni à titre informatif et ne constitue pas un avis juridique. Référez-vous aux textes officiels publiés au Journal officiel et, si nécessaire, à un conseil juridique.