Journal d’audit BO — Guide complet
Installer, configurer et exploiter le journal d'audit back-office : traçabilité des créations/modifications/suppressions avec diff avant/après, suivi des connexions, masquage des champs sensibles, rétention et export CSV pour PrestaShop 8 et 9.
Présentation
Le module Journal d’audit BO enregistre qui a modifié quoi et quand dans votre back-office PrestaShop. Pour chaque création, modification ou suppression, il conserve l’employé concerné, son profil, l’adresse IP, le contrôleur, la méthode HTTP, l’URL, l’horodatage et — pour les modifications — le détail champ par champ (ancienne valeur → nouvelle valeur). Il trace également le début de session de chaque employé et, sur PrestaShop 8, les tentatives de connexion échouées et les déconnexions.
Le module s’appuie exclusivement sur les hooks natifs d’ObjectModel et n’effectue aucune surcharge (override) du cœur. Il est compatible PrestaShop 8 et 9, en mono comme en multi-boutique, et multilingue.
Le journal est conçu pour la sécurité et la conformité RGPD : il fournit une piste d’audit fiable (responsabilité et traçabilité des traitements) sans modifier le fonctionnement de votre boutique.
Installation
- Depuis le back-office, ouvrez Modules > Gestionnaire de modules.
- Cliquez sur Installer un module et déposez l’archive ZIP du module.
- Une fois l’installation terminée, cliquez sur Configurer.
À l’installation, le module crée deux tables dédiées (le journal et le détail des champs modifiés), enregistre ses hooks et ajoute l’entrée de menu Paramètres avancés > Journal d’audit. Aucune configuration n’est obligatoire pour démarrer : un ensemble d’entités pertinent est déjà activé par défaut.
Fonctionnement
Le module écoute les hooks génériques d’ObjectModel présents dans PrestaShop 8 et 9 (ajout, mise à jour et suppression d’objets) ainsi que le hook d’affichage du back-office. À chaque opération sur une entité surveillée :
- il identifie l’employé connecté, son profil et la boutique active ;
- pour une modification, il compare l’état avant et après et n’enregistre que les champs réellement changés ;
- pour une création ou une suppression, il enregistre (en option) l’ensemble des champs de l’objet ;
- il écrit l’entrée directement en base de données.
Les écritures se font en SQL direct, sans repasser par ObjectModel : il n’y a donc aucun risque de récursion des hooks, et l’audit ne peut jamais interrompre une opération métier.
Configuration
Entités surveillées
Cochez les entités à tracer, regroupées par domaine : Catalogue (produits, catégories, fabricants, fournisseurs, déclinaisons, prix spécifiques, images, stocks…), Clients & commandes (commandes, états de commande, clients, adresses, groupes, règles panier), Transport & localisation (transporteurs, pays, zones, devises, taxes), Contenu (pages et catégories CMS, métadonnées) et Administration & sécurité (employés, profils, clés webservice, boutiques, configuration).
Seules les entités cochées sont enregistrées. Un jeu pertinent et peu verbeux est activé par défaut ; la Configuration est désactivée par défaut car très bavarde.
Tracer les connexions BO
Lorsque cette option est active, le module enregistre le début de session de chaque employé. Sur PrestaShop 8, il enregistre aussi les tentatives de connexion échouées (avec l’e-mail saisi) et les déconnexions.
Sur PrestaShop 9, la page de connexion est gérée par Symfony : les connexions réussies sont tracées, mais les échecs et déconnexions sur l’écran de login ne sont pas captés. Toutes les modifications de données restent tracées sur les deux versions.
Conserver le détail des créations/suppressions
Active l’enregistrement de l’ensemble des champs lors d’un ajout ou d’une suppression. Désactivez cette option pour ne conserver que l’évènement (qui, quoi, quand) sans le détail complet de l’objet.
Tracer aussi les actions hors back-office
Par défaut, seules les actions effectuées par un employé connecté au back-office sont enregistrées. Activez cette option pour tracer également les modifications déclenchées en front-office, par une tâche CRON ou via le webservice. Le volume d’entrées peut alors augmenter sensiblement.
Rétention
Définissez la durée de conservation en jours (365 par défaut). Une purge automatique quotidienne supprime les entrées plus anciennes. Réglez la valeur sur 0 pour une conservation illimitée.
Employés exclus
Saisissez les identifiants d’employés (séparés par des virgules) dont les actions ne doivent pas être tracées — par exemple un compte technique d’intégration.
Limites de volume
Deux réglages protègent la base : le nombre maximum de champs enregistrés par entrée et la longueur maximale d’une valeur (au-delà, la valeur est tronquée). Un garde-fou interne limite par ailleurs le nombre d’entrées écrites par requête pour préserver les performances lors des imports de masse.
Consulter le journal
Rendez-vous dans Paramètres avancés > Journal d’audit. La liste affiche, pour chaque entrée : la date, le type d’action (badge coloré), l’entité, l’identifiant et le libellé de l’objet, le nombre de champs modifiés, l’employé, le profil, l’adresse IP et le contrôleur. Vous pouvez filtrer et trier sur ces colonnes.
Vue détaillée
Cliquez sur une entrée pour ouvrir sa vue détaillée. Elle présente le contexte complet (employé, IP, contrôleur, méthode, URL, User-Agent) et, pour une modification, un tableau de différences champ par champ : l’ancienne valeur (sur fond rosé, barrée) et la nouvelle (sur fond verdâtre).
Sécurité des données sensibles
Les champs sensibles ne sont jamais enregistrés en clair. Tout champ dont le nom contient un terme sensible (mot de passe, secure_key, token, clé d’API, clé webservice…) est automatiquement remplacé par des astérisques. Le journal indique qu’un champ sensible a changé sans en révéler la valeur.
Conformité, rétention et export
Le journal conserve le nom de l’employé même après sa suppression, garantissant une piste d’audit durable. Depuis l’écran du journal, le bouton Exporter en CSV génère un fichier UTF-8 (compatible Excel) reprenant toutes les colonnes : date, action, entité, objet, employé, profil, IP, contrôleur, méthode et URL. Le bouton Purger supprime l’ensemble des entrées (action réservée aux profils disposant du droit de suppression).
L’export CSV est idéal pour fournir vos preuves d’audit à un DPO, un commissaire aux comptes ou un auditeur de sécurité.
Désinstallation
La désinstallation supprime les tables du journal, l’ensemble de l’historique, les hooks et l’entrée de menu. Cette opération est définitive : pensez à exporter le journal au préalable si vous devez en conserver une trace.
FAQ
Le module ralentit-il le back-office ?
L’impact est minime : écritures en SQL direct, filtrage par entité et garde-fou de volume. Vous pouvez réduire encore la charge en limitant les entités surveillées.
Les mots de passe sont-ils enregistrés ?
Non. Les champs sensibles sont masqués par des astérisques avant stockage.
Le module modifie-t-il le cœur de PrestaShop ?
Non, aucun override. Le module utilise uniquement les hooks officiels d’ObjectModel et un autoloader interne.
Les actions du front-office sont-elles tracées ?
Par défaut non : le journal se concentre sur les actions des employés en back-office. Vous pouvez activer la traçabilité des actions front-office, CRON et webservice dans la configuration.
Le module est-il compatible PrestaShop 9 ?
Oui, compatible PrestaShop 8.x et 9.x, en mono comme en multi-boutique et multilingue.