Architecture Dolibarr : traçabilité avec une approche sécurité

Architecture Dolibarr : traçabilité avec une approche sécurité
Un guide complet pour comprendre comment Dolibarr organise la traçabilité et comment la sécuriser dans un contexte d’entreprise.

1. Introduction

Dolibarr est un ERP / CRM open‑source à destination des PME et des petites structures. Sa simplicité d’installation et son architecture modulaire le rendent attractif, mais la question de la traçabilité (qui a fait quoi, quand, pourquoi) reste cruciale, notamment lorsqu’on manipule des données sensibles (comptabilité, stocks, contrats…).

Cet article décortique l’architecture de Dolivarr, décrit les mécanismes de traçabilité intégrés, puis montre comment les renforcer sous l’angle de la sécurité : contrôle d’accès, journalisation, chiffrement, conformité RGPD, etc.

2. Architecture de Dolibarr

Niveau Composant Fonction principale
Front‑office Interface Web (HTML/CSS/Javascript) Usager final (commercial, comptable, logisticiens)
Back‑office API PHP + moteur de templates Traitement des requêtes, génération de pages
Data layer Bibliothèques class.entities.php & class.functions.php Abstraction des accès BD (MySQL/PostgreSQL/SQLite)
Base de données Tables de modules (llx_...) Persistance des objets métiers (clients, factures, stocks…)
Modules Plugins (ex. : multicurrency, expenserequest) Fonctionnalités spécifiques, souvent liés à des tables spécifiques

2.1. Le principe « objet‑relationnel »

Dolibarr représente chaque entité métier (ex. : Facture, Devis, Produit) comme une classe PHP (class Facture extends LlxObject).

  • $this->id : identifiant unique (clé primaire).

  • $this->date : horodatage de création/modification.

  • $this->user : référentiel de l’utilisateur qui a déclenché l’action (dans les logs).

Ces objets sont sérialisés dans des tables dédiées (llx_fiche, llx_product, etc.). L’interaction se fait via des méthodes comme add(), update(), delete() qui déclenchent automatiquement des hooks (évènements) : 

$this->getConnection()->begin();

$this->add();               // insère la ligne, enregistre la trace

$this->update();            // met à jour, génère audit trail

$this->delete();            // supprime, capture le delete‑audit

Ces hooks sont le socle de la traçabilité.

3. Traçabilité native dans Dolibarr

Type de trace Où est‑il stocké Exemple d’information
Journal d’évènements (llx_user_action) Table llx_user_action Action (create, update, delete), user (id_user), table, record_id, date
Historique des modifications (llx_c_modif) Table llx_c_modif (pour les factures, devis…) Champ modifié, ancienne valeur, nouvelle valeur, date, user
Journal d’audit (llx_audit) Table llx_audit (si activé) Toute modification d’un champ, même de type SELECT ou STOCK
Versionnage d’objets (llx_version) Table llx_version Version du module, numéro de version du script, checksum du fichier
Log de session (llx_sessions) Table llx_sessions Session ID, user, IP, horodatage, durée

3.1. Activation & Configuration

  1. Navigation : Administration → Maintenance → Paramètres avancés.

  2. Activer les tables llx_c_modif et llx_audit.

  3. Définir le niveau de détail : 0 = aucune trace, 1 = uniquement création/modif/suppression, 2 = trace détaillée (champ‑par‑champ). 4. Choisir le log à conserver (ullastaction) : par défaut 30 jours, réglable via LLX_KEEP_LOGS_DAYS.

Astuce : sauvegarder régulièrement ces tables (ex. : via mysqldump) afin de pouvoir reconstituer l’historique en cas de restauration.

4. Approche sécurité : protéger la traçabilité

Même si les mécanismes natifs offrent une trace, il faut les verrouiller pour éviter toute altération ou fuite d’informations sensibles.

4.1. Contrôle d’accès granulaire

  • Rôles et profils (Administration → Permissions → Roles).

    • Exemple : Admin → tout accès (y compris les droits sur llx_user_action).

    • Exemple : Auditeur → peut voir les logs mais ne peut pas modifier les données audit.

  • Permissions par module : chaque objet (Facture, Produit, etc.) possède un tableau de permissions (create, read, update, delete).

    • Restreindre read sur les tables de log aux seules personnes autorisées.

4.2. Sécurisation des API PHP

  • Validation d’entrée : tous les champs passent par des méthodes validate() avant d’être enregistrés.

  • CSRF token : chaque formulaire inclut un token (<input type="hidden" name="token" value="…">) vérifié côté serveur pour empêcher les soumissions frauduleuses.

  • Limitation de débit (mod_evasive ou configuration php-fpm rlimit_as) afin de se prémunir contre les attaques par force‑brute sur les points d’audit.

4.3. Chiffrement des journaux

Technique Implémentation Avantages
Chiffrement au repos Utiliser MySQL Transparent Data Encryption (TDE) ou MariaDB ColumnEncryption. Les fichiers de logs restent illisibles même si la base est copiée.
Hashage des identifiants Stocker les user_id comme hash (password_hash) dans les logs de récupération. Empêche la re‑identification directe.
Export crypté Script de sauvegarde qui compresse (gzip) puis chiffre (openssl enc -aes-256-cbc -salt) les dumps de llx_user_action. Stockage sécurisé hors‑site (cloud, bande magnétique).

Bonnes pratiques : conserver les clés de chiffrement hors du serveur web, dans un Hardware Security Module (HSM) ou un coffre‑fort numérique.

4.4. журналирование (journalisation) externe

  • Syslog / rsyslog : rediriger les messages de Dolibarr (error_log) vers un broker centralisé (ex. : Graylog, ELK).

  • Intégration avec SIEM : envoyer les tables llx_user_action et llx_audit vers un SIEM (Splunk, QRadar).

    • Permet de déclencher des alertes en temps réel lorsqu’un effacement ou modification massive de logs est détecté.

4.5. Conformité RGPD

Obligation Action Dolibarr Exemple de configuration
Droit d’accès Table llx_user_action inclut user, module, record_id, action. Publier un rapport de conformité qui montre les modifications apportées aux données personnelles.
Droit à l’oubli Possibilité de anonymiser les entrées (setField('email', '')). Utiliser le script cleaner.php qui supprime les traces liées aux fiches supprimées, tout en conservant les logs pour audit (conservation obligatoire).
Durée de conservation Paramètre LLX_KEEP_LOGS_DAYS. Adapter à 2 ans pour les faits de commerce, 5 ans pour les historiques comptables.

5. Mise en œuvre : Checklist de sécurité de la traçabilité

Étape Action Vérification
1️⃣ Activation des tables d’audit Configuration → Avancé → Activer llx_audit Vérifier l’existence de la table llx_audit.
2️⃣ Affichage des logs Créer un menu Administration → Traçabilité dédié. Le menu n’est visible que par le rôle Auditeur.
3️⃣ Restriction d’accès Dans Permutation des droits, retirer Update/Delete sur les tables log. Test : connexion en tant que Comptable → impossible de modifier un enregistrement de llx_user_action.
4️⃣ Chiffrement Configurer le serveur MySQL avec ENCRYPTION = 'Y' ou activer column_encryption. Vérifier avec SHOW VARIABLES LIKE 'encrypt%';.
5️⃣ Journalisation externe Rediriger error_log vers rsyslog et configurer des forwarders vers ELK. Vérifier la présence des messages de Dolibarr dans le système de logs central.
6️⃣ Sauvegarde sécurisée Script backup_audit.sh qui mysqldump -t llx_audit | gzip | openssl enc -aes-256-cbc -salt -out audit_$(date +%F).sql.gz. Test de restauration : openssl enc -d -aes-256-cbc -in audit_2025-10-31.sql.gz | gzip -d | mysql ….
7️⃣ Monitoring Alerte sur SELECT count(*) FROM llx_user_action WHERE action='delete' AND date < NOW() - INTERVAL 1 DAY; Configurer un seuil (ex. : >10 suppressions/jour) → notifier par e‑mail.

6. Exemple concret : création d’une facture avec suivi complet 1. Création de la facture (Commande → Factures → +)

  • L’objet Facture (classe Facture) déclenche le hook after_insert.

  • Le hook écrit dans llx_user_action : 
     $objUserAction = new User_action();
    
 $objUserAction->id_user = $_SESSION['user']['id'];
    
 $objUserAction->action = 'create';
    
 $objUserAction->module='invoices';
    
 $objUserAction->from_module='invoices';
    
 $objUserAction->to_module='invoices';
    
 $objUserAction->record_id = $this->id;
    
 $objUserAction->save();

  1. Édition du catalogue (ajout d’un article) – Lorsqu’un champ price est modifié, le hook after_update du modèle Product enregistre dans llx_c_modif chaque champ changé : 

     champ | avant | après | user | date
    
 -------------------------------
    
 price | 12,50 | 13,00 | 12   | 2025-10-30 14:22:01

  2. Audit du montant total – La somme totale (total_ttc) est recalculée à la volée. Tout changement entraîne un enregistrement supplémentaire dans llx_audit avec le champ total_ht, total_ttc, total_taxe.

  3. Contrôle de sécurité

    • L’utilisateur qui crée la facture possède le rôle Commercial.

    • Ce rôle n’a pas la permission update sur llx_user_action. Ainsi, même si le commercial tente de modifier manuellement la table via phpMyAdmin, il sera bloqué par la contrainte d’accès. 5. Export d’audit (pour le responsable conformité) 

      
SELECT * FROM llx_user_action 
      
WHERE action='delete' AND date >= DATE_SUB(NOW(), INTERVAL 90 DAY) 
      
ORDER BY date DESC;
      
| gzip > /backups/audit_user_action_$(date +%F).sql.gz
      
| openssl enc -aes-256-cbc -salt -pass file:/etc/keys/audit.key -out /backups/audit_user_action_$(date +%F).sql.gz.enc   ```

7. Points d’attention & bonnes pratiques

Risque Solution Dolibarr Recommandation supplémentaire
Altération des logs Restriction des droits d’écriture sur les tables audit. Utiliser des permissions de base de données (GRANT SELECT seulement).
Falsification de timestamps Horodatage stocké au niveau serveur. Activer le MOD_TIMESTAMP de MySQL (DEFAULT CURRENT_TIMESTAMP).
Exfiltration de données via API Token CSRF présent sur chaque appel. Implémenter OAuth2 ou JWT pour les API externes, avec scope limité aux tables log (audit:read).
Accumulation de logs Purge automatique LLX_KEEP_LOGS_DAYS. Mettre en place un rotate quotidien (logrotate) et archivage hors‑site.
Non‑conformité RGPD Anonymisation possible mais parfois difficile. Documenter la politique de conservation et la justification légale (ex. : obligation légale de conservation des factures 10 ans).

8. Conclusion

Dolibarr propose déjà une architecture solide pour la traçabilité : chaque objet métier déclenche des hooks qui alimentent des tables de journalisation détaillées. En les verrouillant (rôles, permissions), en les chiffrant (au repos et en transit) et en les exposant à des systèmes de monitoring centralisés, on obtient une traçabilité qui répond aux exigences modernes de sécurité et de conformité.

Adopter une approche « security‑by‑design » dès le déploiement :

  1. Définir les profils d’accès (auditeur, éditeur, lecteur).

  2. Activer et configurer les tables d’audit.

  3. Sécuriser le stockage (chiffrement, sauvegarde, rotation).

  4. Intégrer les logs dans un SIEM ou un système de centralisation.

  5. Auditer régulièrement les droits et les journaux pour détecter toute anomalie.

En suivant ces étapes, Dolibarr ne sera plus seulement un ERP fonctionnel, mais deviendra également un pilier de gouvernance des données, garantissant que chaque action, chaque modification et chaque suppression soit traçable, immuable et protégée – exactement ce que requiert une organisation soucieuse de la sécurité de ses informations.

Ce guide a été rédigé à destination des équipes IT, administrators système et auditors souhaitant mettre en place une traçabilité fiable et sécurisée sur les instances Dolibarr, qu’elles soient on‑premise ou hébergées en cloud.

Publications similaires