Le 24 juillet 2025, la loi n° 25-11 est venue modifier la loi n° 18-07 du 10 juin 2018 relative à la protection des personnes physiques dans le traitement des données à caractère personnel. Depuis, la même question revient dans chaque comité de direction informatique en Algérie : « concrètement, qu'est-ce qu'on doit faire de plus ? »
La réponse courte tient en une obligation que presque personne n'a encore lue correctement — ce que les commentateurs ont pris l'habitude d'appeler le carnet d'audit.
La réponse longue est l'objet de cet article.
Note de méthode. Cet article a été rédigé avant que le texte primaire n'ait pu être consulté intégralement. Les hôtes gouvernementaux algériens qui publient le Journal officiel présentent des certificats TLS invalides et l'accès au texte est irrégulier. Chaque endroit où un numéro d'article ou une citation littérale est nécessaire est signalé comme tel dans le texte. Nous préférons publier un article plus court et exact qu'un article complet et faux. Les numéros d'articles seront ajoutés dès vérification sur le texte primaire.
1. Ce qui a changé le 24 juillet 2025 — et ce qui n'a pas changé
Premier point, souvent mal compris : la loi 25-11 ne remplace pas la loi 18-07. Elle la modifie.
La conséquence est pratique, pas théorique. Votre analyse de conformité ne repart pas de zéro : le socle de 2018 — définitions, base de licéité, droits des personnes concernées, rôle de l'autorité — reste en vigueur. Ce que 25-11 ajoute, ce sont des obligations opérationnelles qui, elles, touchent directement l'architecture de vos systèmes.
Autrement dit : jusqu'en 2025, la conformité data en Algérie était principalement un travail juridique et déclaratif. À partir de 25-11, elle devient un travail d'ingénierie. C'est exactement ce déplacement que la plupart des organisations n'ont pas encore intégré.
2. La clause dite du « carnet d'audit »
C'est la disposition centrale de cet article, et c'est celle qui coûtera le plus cher à mettre en œuvre.
Les commentaires publiés à ce jour décrivent une obligation d'enregistrer, pour chaque opération portant sur des données à caractère personnel :
- le motif de l'opération,
- son horodatage,
- l'identité de l'opérateur qui l'a réalisée,
et ce sur l'ensemble du cycle de vie de la donnée, de la collecte jusqu'à sa destruction.
Ces quatre éléments sont la formulation qui circule dans la littérature secondaire, pas la formulation légale. Tant que le texte primaire n'a pas été confirmé, traitez-les comme une description fidèle de l'intention et non comme une citation.
Mais même sous cette réserve, l'exigence est déjà d'une nature différente de ce que produit un parc informatique ordinaire. Regardons pourquoi.
3. Ce que cela exige réellement : motif, horodatage, opérateur, cycle complet
Prenons les quatre éléments un par un, du point de vue de quelqu'un qui doit les produire.
Le motif
C'est le plus difficile, et de loin. Un système d'information sait presque toujours qui a fait quoi. Il ne sait pratiquement jamais pourquoi.
Quand un agent du service client ouvre le dossier d'un abonné, votre CRM enregistre un SELECT. Il n'enregistre pas « traitement d'une réclamation facturation n° 88421 ». Or c'est précisément cette seconde information qui distingue un accès légitime d'une consultation curieuse — et c'est celle-là qui est demandée.
Produire le motif suppose que la finalité soit portée par la transaction métier elle-même, puis propagée jusqu'à la couche de journalisation. Ce n'est pas un réglage : c'est une modification applicative.
L'horodatage
Apparemment trivial, en réalité piégeux. Un horodatage n'a de valeur probatoire que si :
- l'horloge est synchronisée sur une source de temps commune à tout le parc,
- le fuseau est explicite et cohérent entre les systèmes,
- et la valeur est inaltérable après écriture.
Trois serveurs qui divergent de quelques minutes suffisent à rendre une chronologie inexploitable — et une chronologie inexploitable est exactement ce qui vous manquera le jour où vous devrez prouver à quel moment vous avez su.
L'opérateur
L'identité doit être nominative et non répudiable. Deux pratiques très répandues la détruisent :
- les comptes partagés (
admin,dba,support) — ils font disparaître la personne derrière le rôle ; - les accès applicatifs mutualisés, où l'application se connecte à la base avec un compte technique unique. Côté base, tous les accès ont alors le même auteur.
Si votre application accède à la base via un compte de service, votre journal de base de données ne vous dira jamais qui a consulté quoi. La trace doit être produite au niveau applicatif, là où l'utilisateur est encore identifié.
Le cycle de vie complet, jusqu'à la destruction
C'est le point le plus souvent oublié. « Jusqu'à la destruction » signifie que l'effacement est lui aussi un événement à tracer.
Il faut donc pouvoir démontrer que la donnée a été détruite : quand, par qui, sur quel fondement, et — question que peu d'organisations savent traiter — dans toutes ses copies : sauvegardes, environnements de recette, exports analytiques, pièces jointes de messagerie.
4. Pourquoi un log applicatif n'est pas un carnet d'audit
C'est l'objection que nous entendons systématiquement : « mais on a déjà des logs. »
Vous en avez, oui. Ils ne répondent presque jamais à l'exigence, pour trois raisons.
Ils sont modifiables. Un fichier de log sur un serveur est un fichier comme un autre : l'administrateur peut l'éditer, le tronquer, le supprimer. Une trace dont le gardien peut effacer sa propre trace n'a aucune valeur probatoire. Il faut un stockage en append-only, une intégrité vérifiable, et surtout une séparation des pouvoirs : celui qui administre le système ne doit pas pouvoir administrer la preuve de ce qu'il y a fait.
Ils ne sont pas conservés assez longtemps. La rétention par défaut d'une pile technique typique va de sept à trente jours, parce qu'elle a été dimensionnée pour du diagnostic d'incident, pas pour de la preuve. Un contrôle porte sur des faits bien plus anciens.
Ils sont techniques, pas métier. Un log applicatif dit GET /api/customers/4471 200. Le carnet d'audit doit dire : tel agent, à telle heure, a consulté le dossier de telle personne, dans le cadre de tel motif. Passer de l'un à l'autre demande une corrélation que personne ne fait rétroactivement dans l'urgence d'un contrôle.
Le résumé honnête : la plupart des parcs produisent des traces d'exploitation, pas des traces de conformité. Ce sont deux objets différents, et le second ne s'obtient pas en augmentant la rétention du premier.
5. Les quatre obligations voisines qui arrivent avec
Le carnet d'audit n'arrive pas seul. Quatre obligations l'accompagnent et se renforcent mutuellement.
La désignation d'un délégué à la protection des données (DPO).
Le registre des traitements. L'inventaire de vos traitements, de leurs finalités, de leurs catégories de données et de leurs destinataires. C'est aussi, en pratique, le document qui rend le carnet d'audit exploitable : sans registre, vous avez des traces sans référentiel pour les interpréter.
L'analyse d'impact (DPIA) et la consultation préalable. Pour les traitements présentant un risque élevé, une analyse formalisée est requise, et au-delà d'un certain niveau de risque résiduel, l'autorité doit être consultée avant le déploiement.
La notification des violations. Les sources secondaires convergent sur un délai de cinq jours. Ce délai fera l'objet d'un article dédié, mais retenez dès maintenant le point qui relie tout : le délai commence à courir à partir d'un moment que vous devez être capable de prouver.
C'est le lien qui rend le carnet d'audit structurant plutôt qu'administratif : sans trace fiable, vous ne pouvez pas établir la date de connaissance, donc vous ne pouvez pas démontrer que vous avez notifié dans les délais.
6. Ce qu'un contrôle peut demander
L'ANPDP — l'autorité nationale de protection des données à caractère personnel — est opérationnelle depuis 2023 et a engagé des contrôles sur le terrain auprès d'entités privées.
Indépendamment du détail des pouvoirs de l'autorité, la question pratique à se poser est simple, et vous pouvez y répondre aujourd'hui sans avocat :
Si l'on vous demandait, sous quinze jours, la liste complète et horodatée des accès aux données personnelles d'une personne nommée, sur les vingt-quatre derniers mois, tous systèmes confondus — pourriez-vous la produire ?
Dans la grande majorité des organisations que nous rencontrons, la réponse est non. Pas par négligence : parce que le système n'a jamais été conçu pour cela.
7. Une liste de contrôle exploitable
Sept points, dans l'ordre où nous conseillons de les traiter. Aucun ne suppose l'achat d'un outil.
- Inventoriez les systèmes qui touchent des données personnelles. Pas tous vos systèmes : ceux qui lisent, écrivent, exportent ou sauvegardent de la donnée personnelle. La liste est généralement plus longue que prévu — pensez aux exports tableur et aux boîtes aux lettres partagées.
- Pour chacun, répondez : produit-il aujourd'hui l'auteur nominatif d'un accès ? Un « non » signale un compte partagé ou un compte technique à traiter en priorité.
- Synchronisez les horloges sur une source unique et vérifiez la dérive. C'est le prérequis le moins coûteux et le plus souvent négligé.
- Sortez les traces du système qui les produit. Une trace conservée uniquement sur la machine qu'elle surveille n'est pas une preuve. Centralisez, en écriture seule.
- Fixez et documentez une durée de conservation des traces, cohérente avec la durée pendant laquelle vous pourriez avoir à en répondre — et non avec l'espace disque disponible.
- Ajoutez le motif là où c'est possible. Commencez par les accès aux données les plus sensibles ; n'essayez pas de traiter tout le parc d'un coup.
- Tracez les suppressions comme vous tracez les accès, sauvegardes comprises.
Si vous ne devez retenir qu'une chose : commencez par l'identité nominative et la centralisation en écriture seule. Ce sont les deux points sans lesquels tout le reste est décoratif.
Le point de départ
Avant de construire un carnet d'audit, il est utile de savoir ce qui a déjà fuité — parce qu'une donnée d'authentification exposée transforme n'importe quelle trace en fiction : vous aurez le nom d'un opérateur légitime en face d'un accès qui ne l'était pas.
Vérifiez gratuitement l'exposition d'une adresse professionnelle — sans compte, sans engagement, en quelques secondes.