Dolibarr : comment réussir logs sans casser l’existant

Guide pratique pour mettre en place une journalisation fiable tout en préservant le bon fonctionnement de votre ERP/CRM open‑source.

1. Introduction – Pourquoi les logs sont indispensables dans Dolibarr

Dolibarr regorge de fonctionnalités : gestion des devis, factures, stocks, contacts, agenda, etc. Chaque transaction génère des informations précieuses : qui a créé quoi, quand, pourquoi et avec quels résultats. Un bon mécanisme de logging vous permet de :

  • Diagnostiquer rapidement les erreurs ou les performances dégradées.

  • Traquer les actions suspectes (fraude, mauvaise configuration, bug).

  • Obtenir des statistiques d’usage pour optimiser vos processus. – Respecter la traçabilité exigée par les audits internes ou les obligations légales (RGPD, tenue de registre comptable, etc.).

Le défi consiste à ajouter ces informations de façon progressiste et non intrusive, sans modifier le cœur du code ni perturber les opérations déjà en production.

2. Préparer son environnement – Les bases avant toute chose

Étape Action Raison
2.1. Faire un backup complet Copier le dossier custom, la base de données (mysqldump, pg_dump, …) et le dossier files/ (documents,images) vers un répertoire temporaire. Permet de revenir à l’état initial si la mise en place du logging crée un problème.
2.2. Identifier le moteur de base Dolibarr fonctionne sur MySQL / MariaDB, PostgreSQL ou SQLite. Certains logs s’appuient sur des triggers ou des tables de suivi qui sont plus faciles à mettre en place selon le SGBD.
2.3. Choisir le canal de logging – Fichier texte (log/ du serveur Apache/Nginx).
– Table de suivi (llx_log ou log_element).
– Syslog via l’extension PHP syslog.		 Le canal choisi doit être compatible avec votre configuration serveur et vos politiques de rétention.
2.4. Vérifier les droits Le processus PHP doit pouvoir écrire dans le répertoire de log choisi et/ou disposer des privilèges d’insertion dans la table de log. Éviter les erreurs 500 « Permission denied ».
2.5. Créer un environnement de test Duplicatez une petite base de données (ex. dolibarr_test) et reproduisez le même schéma de modules que vous utilisez en prod. Testez les changements sans impacter les utilisateurs réels.

3. Configurer les logs dans Dolibarr

Dolibarr propose plusieurs mécanismes natifs pour journaliser les événements :

3.1. Activation du module log intégré

  1. Ouvrir le menu Administration → Configuration → Logs.

  2. Cochez “Activer le log”. 3. Sélectionnez le type de stockage (fichier, base ou syslog).

  3. Indiquez le chemin du fichier (ex. /var/log/dolibarr/dolibarr.log) ou le nom de la table à utiliser si vous préférez la table llx_log.

  4. Définissez le niveau de verbosité :

    • INFO – seules les actions majeures (création, modification, suppression).

    • DEBUG – tout, y compris les appels internes, utiles pour le dépannage.

  5. Enregistrez.

Conseil : Commencez avec le niveau INFO. Vous augmenterez progressivement si vous avez besoin de plus de détails.

3.2. Ajouter des triggers DB pour des tables spécifiques

Parfois vous voulez capturer les changements sur des tables critiques (ex. llx_facture, llx_product). Vous pouvez créer des triggers SQL : 

CREATE TRIGGER after_update_facture AFTER UPDATE ON llx_facture

FOR EACH ROW BEGIN

   INSERT INTO llx_log (id_user , action , date , tableau , id_enregistrement , description)

   VALUES (1, 'UPDATE', NOW(), 'facture', NEW.id, CONCAT('Modification du montant : ', NEW.total_ht));

END;

  • Idempotence : Vérifiez que le trigger ne provoque pas de récursivité (ex. pas de INSERT qui déclenche de nouveau le trigger).

  • Sécurité : Restreignez l’accès au tableau llx_log aux seuls rôles d’audit.

3.3. Utiliser les hooks PHP ($setup->...)

Dolibarr expose des points « d’entrée » (HOOK_...) que vous pouvez exploiter via un module custom. Exemple : « `php
function hookFormOpenInvoice($params) {
// Ajoute le texte de l’action dans le log
$GLOBALS[‘dol_logger’]->addLog(‘CREATION FACTURE’, $user->id, ‘FACTURE’, $_REQUEST[‘ref’]);
}



- **Avantage** : Vous n’avez pas besoin de toucher à la base de données ; le code est exécuté au même moment que l’opération.  

- **Limite** : Les hooks ne sont pas officiellement documentés, mais fonctionnent dans les versions stables (ex. 22.x, 23.x).  ---
## 4. Implémenter sans casser l’existant – Stratégie progressive  
### 4.1. **Effet papillon** – Commencer par un sous‑ensemble limité  
- **Ciblez un module** (ex. factures) avant de toucher à tout le système.  - **Activez le logging uniquement sur les actions** que vous jugez critiques (création, suppression, modification d’un état final).  

- **Surveillez les performances** pendant 24‑48 h. Si aucune anomalie n’apparaît, étendez le périmètre.
### 4.2. **Mode « dry‑run »** – Simuler les écritures de logs  
Dolibarr propose un paramètre **`debug_mode`** qui redirige les logs vers la console sans avaler les ressources du disque. Utilisez‑le pour :
- Vérifier que chaque appel de log est bien déclenché.  

- Contrôler le format du message (timestamp, utilisateur, type, description).  
> *Astuce*: Programmez pendant le mode `dry‑run` un script qui capture les messages et les réinjecte dans un fichier de test pour analyser la volumétrie prévue.
### 4.3. **Besoin de rétention** – Prévoir une rotation de logs  
- Utilisez `logrotate` sur le serveur (Linux) pour archiver automatiquement les fichiers de log lorsqu’ils dépassent, par ex., **5 Mo**.  

- Configurer `maxsize` et `rotate` selon votre politique de conformité (ex. garder 30 jours).  
```conf/var/log/dolibarr/*.log {

    daily

    rotate 14

    compress

    missingok

    notifempty

    create 640 www-data adm

}

4.4. Déploiement sans redémarrage

  • Les changements de configuration de log sont sans impact immédiat sur les sessions déjà ouvertes.

  • Pour être certain que chaque utilisateur recevra les nouveaux paramètres, effectuez le déploiement pendant une période de faible trafic (ex. fin de soirée).

5. Vérification et validation – Tester avant le go live | Action | Méthode |

|——–|———|
| 5.1. Vérifier la présence du fichier log | tail -f /var/log/dolibarr/dolibarr.log pendant la saisie d’une facture. |
| 5.2. S’assurer que l’utilisateur est bien enregistré | Cherchez le champ id_user dans le log ; il doit correspondre à la session du compte qui a effectué l’action. |
| 5.3. Contrôler la table llx_log | SELECT * FROM llx_log LIMIT 10; – les enregistrements doivent contenir action, date, description. |
| 5.4. Simuler une erreur (ex. refus d’accès) | Essayez de sauvegarder une facture sans droits suffisants. Le log doit refléter « Permission denied » et ne pas altérer le numéro de facture. |
| 5.5. Mesurer l’impact performance | Comparez le temps de réponse moyen avant/après (ex. via apachebenchmark ou ab). Un léger allongement (< 200 ms) est généralement acceptable. |
| 5.6. Nettoyage de la table de test | Avant le passage en prod, videz la table llx_log de la base de test pour éviter la duplication de données. |

6. Bonnes pratiques à adopter

  1. Séparez les logs par type

    • dolibarr.log → événements « système ».

    • audit.log → actions critiques (création/modification/suppression de factures, changements de tarifs).

  2. Utilisez des champs structurés (JSON ou CSV) pour faciliter le recherche et l’analyse automatisée (ELK, Splunk).

  3. Ajoutez un identifiant de session (session_id) dans chaque entrée de log pour pouvoir reconstituer le parcours utilisateur.

  4. Ne loggez jamais les mots de passe ou données très sensibles (numéros de carte, données personnelles brutes).

  5. Documentez chaque nouvelle règle d’enregistrement : pourquoi, où, quel niveau, qui peut y accéder.

  6. Planifiez une revue périodique (mensuelle ou trimestrielle) des logs : suppression du bruit, recherche d’anomalies (ex. trop nombreux DELETE sur des lignes de stock). —

7. Supervision et alertes – Toujours garder un œil sur le horizon | Outil | Fonctionnalité clés |

|——|———————-|
| ELK Stack (Elasticsearch‑Logstash‑Kibana) | Recherche en temps réel, visualisation des graphes d’activité, alertes via Watcher. |
| Graylog | Similaire à ELK mais plus léger, possibilité de créer des règles d’alerte sur des patterns spécifiques (error ou critical). |
| Prometheus + Alertmanager | Si vous exposez des métriques du server PHP via exporter, Alertmanager peut déclencher des notifications lorsqu’un seuil de lignes log par minute est dépassé. |
| Fail2Ban | Analyse les logs pour détecter des comportements suspects (ex. tentatives de créer plus de 100 factures en 5 min) et bloquer l’IP. |

Rappel : tout système d’alerte doit être testé en mode dry‑run avant d’être mis en production afin d’éviter les faux positifs qui généreraient des actions inutiles.

8. Maintenance – Garder les logs sains sur le long terme

  1. Rotation automatique (logrotate ou équivalent).

  2. Purge périodique d’anciens enregistrements de llx_log (ex. DELETE FROM llx_log WHERE date < NOW() - INTERVAL 90 DAY;). 3. Sauvegarde incrémentale des logs (ex. sauvegarde du répertoire via rsnapshot) pour conforme aux exigences d’audit.

  3. Monitoring de la taille : script cron qui envoie un mail si le fichier dépasse 100 Mo.
    « `bash #!/bin/bash
    LOG="/var/log/dolibarr/dolibarr.log"
    THRESHOLD=104857600 # 100 MB en octets
    if [ $(stat -c%s "$LOG") -gt $THRESHOLD ]; then
    mail -s "Log Dolibarr > 100 Mo !" admin@votredomaine.com < "$LOG"
    fi

  4. Mettre à jour le code : chaque mise à jour majeure de Dolibarr peut introduire de nouvelles tables ou fonctions ; revérifiez que le scheme de logs reste compatible.

9. Conclusion – Un logging maîtrisé sans impacts

La mise en place de logs dans Dolibarr n’est pas une opération à la légère ; elle requiert une approche graduelle, des tests rigoureux et une veille permanente sur les performances et la sécurité. En suivant le processus ci‑dessus :

  • Commencez petit (un module, un niveau d’information).

  • Validez chaque étape dans un environnement de test isolé.

  • Informez les équipes (support, audits, devs) sur les nouveaux indicateurs de suivi.

  • Automatisez la rotation, la sauvegarde et la surveillance pour éviter la croissance incontrôlée.

En adoptant cette méthode, vous gagnerez en visibilité sur vos processus métiers tout en préservant la stabilité de votre installation Dolibarr — un vrai win‑win pour les équipes techniques et les décideurs.

Bon logging ! 🚀

Cet article a été rédigé par un consultant spécialisé Dolibarr, fort de plus de 10 ans d’expérience dans la mise en production d’ERP open‑source pour la PME et l’administration publique.

Publications similaires