Dolibarr et cache : erreurs fréquentes et solutions avec une approche sécurité

Dolibarr, l’ERP/CRM open source populaire, repose sur une architecture PHP classique où le mécanisme de cache joue un rôle essentiel dans les performances. Cependant, une mauvaise gestion du cache peut entraîner des erreurs fonctionnelles, des lenteurs et même introduire des vulnérabilités de sécurité. Cet article examine les problèmes courants liés au cache dans Dolibarr et propose des solutions en intégrant systématiquement une dimension sécurité.

1. Comprendre le cache dans Dolibarr

Dolibarr utilise plusieurs niveaux de cache :

  • Cache des templates (Smarty) : stocke les pages HTML compilées.

  • Cache des données : requêtes SQL, listes, configurations.

  • Cache des sessions : données utilisateur temporaires.

  • Cache d’opcode PHP (OPcache) : accélère l’exécution du code PHP lui-même.

Ces caches sont généralement stockés dans le dossier cache/ à la racine de Dolibarr, et parfois dans des dossiers temporaires système (/tmp).

2. Erreurs fréquentes liées au cache

a) Pages blanches / erreurs 500 après mise à jour

Cause : Le cache Smarty ou les fichiers de configuration mis en cache ne correspondent plus au nouveau code après une mise à jour de Dolibarr ou d’un module.

b) Données obsolètes ou incohérentes

Cause : Cache de requêtes SQL non invalidé après une modification directe en base de données ou une opération métier (ex. : changement de prix, mise à jour de stocks).

c) Problèmes de permissions sur les dossiers de cache

Cause : Le serveur web (www-data, apache, nginx) ne peut pas écrire dans cache/ ou ses sous-dossiers après un changement de propriétaire ou une restauration.

d) Conflits avec le cache OPcache

Cause : OPcache conserve des versions anciennes de fichiers PHP en mémoire,尤其 après une modification de code sans redémarrage du service PHP.

e) Sessions qui "expirent" prématurément

Cause : Cache de session saturé ou nettoyé agressivement par le système, souvent dû à une configuration session.gc_maxlifetime inadaptée.

f) Erreurs de type "Unable to write cache file"

Elles surviennent lorsque le système de fichiers est plein, en read-only, ou que les quotas sont dépassés.

3. Solutions avec une approche sécurité

✅ Solution 1 : Vider le cache de manière contrôlée

Méthode sécurisée :

  1. Via l’interface admin Dolibarr : Accueil → Administration → Maintenance → Vider le cache. Cela déclenche un nettoyage propre.

  2. En ligne de commande (recommandé) : 
    # Se placer dans le répertoire de Dolibarr
    
php bin/console dolibarr:cache:clear

    Pourquoi c’est plus sûr : Cela évite de supprimer manuellement des fichiers, ce qui pourrait effacer des données critiques ou laisser des failles.

✅ Solution 2 : Vérifier et corriger les permissions

Procédure sécurisée :

# Donner le propriétaire au serveur web (exemple pour www-data)

sudo chown -R www-data:www-data /chemin/vers/dolibarr/cache/

# Permissions restrictives : dossier = 750, fichiers = 640

sudo find /chemin/vers/dolibarr/cache/ -type d -exec chmod 750 {} \;

sudo find /chemin/vers/dolibarr/cache/ -type f -exec chmod 640 {} \;

Note sécurité : Ne jamais mettre 777 sur ces dossiers. Cela permettrait à un utilisateur système non privilégié d’écraser des fichiers de cache, potentiellement pour injecter du code.

✅ Solution 3 : Gérer OPcache avec précaution

  • Pour les environnements de production : Gardez OPcache activé pour les performances.

  • Après une mise à jour : Redémarrer proprement le service PHP-FPM ou Apache, pas seulement vider le cache Dolibarr. 
    sudo systemctl restart php-fpm   # ou php8.1-fpm selon la version

  • En développement : Désactivez OPcache dans php.ini (opcache.enable=0) pour éviter les conflits.

✅ Solution 4 : Isoler le cache des accès web directs

Élément de sécurité critique :
Placez le dossier cache/ en dehors de la racine web (par exemple /var/cache/dolibarr/) et modifiez conf/conf.php :

$dolibarr_main_url_root = 'https://votredomaine.com';

$dolibarr_main_document_root = '/var/www/dolibarr';  # racine web actuelle

$dolibarr_main_data_root = '/var/cache/dolibarr';    # NOUVEAU : pour le cache

Puis déplacez le dossier cache/ vers cet emplacement et ajustez les permissions.

Pourquoi : Si une faille permet d’accéder au système de fichiers, l’attaquant ne pourra pas exécuter des fichiers cached situés hors de la racine web.

✅ Solution 5 : Nettoyage automatique et surveillance

  • Mettez en place un cron job pour nettoyer périodiquement les vieux caches (ex. : tous les jours à 2h du matin) : 
    0 2 * * * www-data php /chemin/dolibarr/bin/console dolibarr:cache:clear --no-interaction

  • Surveillez l’espace disque utilisé par /tmp et cache/ avec des outils comme du, ncdu, ou un监控 (Grafana, Prometheus).

4. Approche sécurité globale pour le cache de Dolibarr

Risque Mesure de sécurité
Divulgation de données sensibles via des fichiers de cache lisible – Droits restrictifs (640/750).
– Dossier cache/ hors racine web.
– Exclure cache/ des sauvegardes publiques.
Injections de code via un cache compromis – Ne jamais autoriser l’écriture dans cache/ par l’utilisateur web (www-data) et un utilisateurftp/sftp en même temps.
– Scanner les dossiers cache/ après une intrusion suspecte.
Déni de service par saturation du cache/disk – Limiter la taille des caches dans les paramètres Dolibarr (Admin → Paramètres divers).
– Mettre en place des quotas disque pour le serveur web.
– Nettoyage automatique agressif si espace critique.
Persistance d’attaques via fichiers malveillants en cache – Intégrer cache/ dans les scans antivirus/clamav.
– Vérifier les signatures de fichiers après un incident.

5. Bonnes pratiques préventives

  1. Tester les mises à jour dans un environnement préproduction avec le même cache que la production.

  2. Documenter toute modification manuelle du cache (suppression de fichiers spécifiques) et son raisonnement.

  3. Ne jamais modifier les fichiers dans cache/ à la main, sauf en cas d’urgence absolue et après sauvegarde.

  4. Auditer régulièrement les dossiers cache/ et tmp/ : qui y a accès ? quels fichiers sont étranges ?

  5. Utiliser un cache externe (Redis, Memcached) uniquement si nécessaire et en le sécurisant (auth, ACL, réseau privé). Cela déplace le risque mais peut améliorer la sécurité si bien configuré.

6. Checklist de dépannage rapide

Face à une erreur suspecte liée au cache :

  1. [ ] Identifier : L’erreur est-elle après une mise à jour, un upload de fichier, une action métier ?

  2. [ ] Vider le cache Dolibarr via l’interface ou CLI.

  3. [ ] Redémarrer le service PHP (OPcache).

  4. [ ] Vérifier les permissions sur cache/ et documents/ (certains modules y écrivent aussi).

  5. [ ] Consulter les logs : dolibarr.log, php-fpm.log, apache/nginx error log.

  6. [ ] Tester en désactivant temporairement le cache Smarty dans conf.php ($dolibarr_main_cache_active = 0;) – uniquement pour diagnostic.

  7. [ ] Restaurer depuis un backup sain si le problème persiste et que l’intégrité des données est en jeu.

Conclusion

Le cache dans Dolibarr est un levier de performance, mais il doit être considéré comme un composant critique de la sécurité. Une mauvaise configuration peut transformer un mécanisme d’optimisation en vecteur d’incident. La règle d’or : toujours privilégiger la simplicité, la traçabilité et l’isolation. En plaçant le cache hors de portée du web, en strictement contrôlant les permissions et en automatisant sa gestion, vous réduisez drastiquement la surface d’attaque tout en nowrant les performances.

Rappel final : Aucune solution technique ne remplace une politique de mise à jour régulière, des sauvegardes vérifiées et une sensibilisation des administrateurs aux risques liés au cache.*

Article rédigé pour les administrateurs système et responsables technique de Dolibarr. Adaptez les chemins et commandes à votre environnement.

Publications similaires