Dolibarr en production : SSO et bonnes pratiques orienté performance

Version 2025 – Article destiné aux équipes IT, développeurs et chefs de projet qui souhaitent exploiter Dolibarr dans un environnement de production fiable, sécurisé et ultra‑performant.

1. Introduction

Dolibarr est un ERP / CRM open‑source léger, intégré et très modulable. Sa simplicité d’installation le rend attractif, mais, comme tout logiciel en production, il exige une configuration adaptée pour garantir sécurité, disponibilité et performance.

Ce guide se focalise sur deux aspects essentiels : 1. Single Sign‑On (SSO) – centraliser l’authentification et réduire la surface d’attaque.

  1. Bonnes pratiques de performance – optimiser le code, la base de données, le serveur web et le déploiement.

2. SSO avec Dolibarr

2.1 Pourquoi un SSO ?

Avantages Impact business
Gestion centralisée des comptes (Azure AD, Keycloak, Okta, LDAP…) Réduction du coût de maintenance et des erreurs d’accès.
SSO transparent pour les utilisateurs → meilleure UX. Augmentation de l’adoption de l’outil.
Audit & conformité (RGPD, ISO 27001) simplifiés. Réduction des risques de non‑conformité.
Scalabilité : ajout dynamique d’utilisateurs sans toucher le code. Gain de flexibilité pour la croissance de l’entreprise.

2.2 Méthodes d’intégration

Méthode Description Points forts / limites
Modulo Single Sign‑On de Dolibarr (v15+) Configuration via l’interface « Administration > Authentification > SSO ». Supporte OAuth2 / OpenID Connect, SAML et LDAP. ✅ Installation simple.
⚠️ Nécessite que le module soit activé et que le serveur web supporte les directives Rewrite.
Reverse Proxy + Header de sécurité Un reverse proxy (NGINX, Traefik) gère l’authentification (ex. Auth0, Keycloak) et transmet les attributs via le header Authorization. Dolibarr accepte le header remote_user. ✅ Découplage complet de l’app.
⚠️ Complexité supplémentaire (certificats, TLS).
Authentification HTTP Basic via .htaccess / htaccess Utilisé sur des environnements très restreints. ✅ Très rapide à mettre en place.
⚠️ Pas de gestion de rôles avancés; à éviter en production.

Exemple d’utilisation du module OAuth2 (OpenID Connect)

  1. Installation – Téléchargez le module depuis le répertoire « contrib » ou le marketplace Dolibarr.

    • Copiez le dossier sso dans custom/ ou interfaces/.

  2. Configuration
    « `php // Dans Admin → Authentication → SSO $sso_provider = ‘openid’;
    $client_id = ‘YOUR_CLIENT_ID’;
    $client_secret = ‘YOUR_CLIENT_SECRET’;
    $discover_url = ‘https://sso.example.com/.well-known/openid-configuration‘;
    $redirect_uri = ‘https://dolibarr.example.com/oauth/callback‘;

  3. Test

    • Accédez à https://dolibarr.example.com/index.php?login=1 → vous êtes redirigé vers le provider SSO.

    • Après authentification, le token OIDC est échangé contre un access_token, et Dolibarr crée/actualise l’utilisateur.

  4. Mise en production

    • Activez le HTTPS strictement (certificat valide).

    • Ajoutez les en‑têtes de sécurité : Content-Security-Policy, X-Content-Type-Options, X-Frame-Options.

    • Redirigez les requêtes HTTP vers HTTPS via le reverse proxy. ### 2.3 Gestion des groupes et des droits

Dolibarr stocke les droits d’accès dans la table usergroups. Avec SSO vous pouvez : – Mapper les groupes d’identité du provider (ex. admin, manager, member) à des user groups Dolibarr.

  • Limiter l’accès à des modules (ex. facturation, projet) en fonction du groupe.

Tip : Utilisez le plugin “SSO + LDAP Sync” pour synchroniser automatiquement les changements de groupe.

3. Bonnes pratiques de performance

Dolibarr est volontairement léger, mais quelques ajustements permettent de soutenir plusieurs dizaines de milliers d’utilisateurs simultanés.

3.1 Architecture générale

+-------------------+          +-------------------+

|   Client Web (HTTPS)  -->   NGINX/Apache   -->   PHP-FPM  -->   Dolibarr

+-------------------+          +-------------------+       |

                                            +-------------------+

                                            |   MySQL / MariaDB |

                                            +-------------------+

3.1.1 Reverse Proxy (NGINX)

server {

    listen 80;

    server_name dolibarr.example.com;

    return 301 https://$host$request_uri;

}
server {

    listen 443 ssl;

    server_name dolibarr.example.com;
ssl_certificate     /etc/letsencrypt/live/dolibarr.example.com/fullchain.pem;

    ssl_certificate_key /etc/letsencrypt/live/dolibarr.example.com/privkey.pem;
# Performance TLS

    ssl_protocols TLSv1.2 TLSv1.3;

    ssl_ciphers HIGH:!aNULL:!MD5;
# Caching TLS session

    ssl_session_cache shared:SSL:10m;

    ssl_session_timeout 10m;
# HSTS

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Cache static assets

    location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {

        expires 30d;

        access_log off;

        add_header Cache-Control "public, immutable";

    }
# Forward to PHP-FPM

    location / {

        proxy_pass         http://127.0.0.1:9000;

        proxy_set_header   Host $host;

        proxy_set_header   X-Real-IP $remote_addr;

        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header   X-Forwarded-Proto $scheme;

        # Optimisation du timeout

        proxy_read_timeout 90;

        proxy_send_timeout 90;

    }

}

  • Keepalive entre NGINX et PHP‑FPM (optimise le nombre de connections).

  • Compression (gzip ou brotli).

3.1.2 PHP‑FPM

Paramètre Valeur conseillée (exemple) Raison
pm.max_children 50 × CPU cores (ex. 400 si 8 cores) Suffisant pour la plupart des charges web, évite le fork excessif.
pm.start_servers 10 Lance un pool initial minimal.
pm.min_spare_servers 5 Maintien d’un petit pool inactif.
pm.max_spare_servers 15 Idem, sans exploser la RAM.
php_value[memory_limit] 256M Suffisant pour les traitements de fichiers lourds.
php_value[upload_max_filesize] 50M Permet les pièces jointes volumineuses.
opcache.enable 1 Cache bytecode, gain de 30 % en temps de réponse.

Tip : Activez opcache.validate_timestamps=0 en production (aucune modification du code à la volée).

3.1.3 Base de données

  • Choix : MySQL 8.0 ou MariaDB 10.6+ (optimisé pour les tables InnoDB). – Configuration : 
    innodb_buffer_pool_size = 70% de la RAM disponible (ex. 4 GB si serveur 8 GB)
    
innodb_log_file_size   = 256M
    
innodb_flush_method    = O_DIRECT   # évite le cache double
    
query_cache_type        = 0        # désactiver le query cache (inefficace en MySQL 8)
    
max_connections          = 200
    
table_open_cache         = 2000
    
thread_cache_size        = 10

  • Indexation : revérifiez les EXPLAIN sur les requêtes lentes (ex. SELECT * FROM llx_facture WHERE date >= '2024') et créez des index composites sur les colonnes de filtre (date, status, client_id).

3.2 Optimisation du code Dolibarr | Action | Impact | Comment faire |

|——–|——–|—————|
| Désactiver les modules inutiles | Réduction du temps de chargement et du nombre de requêtes. | Via Setup → Modules → Désactiver tout ce qui n’est pas utilisé (ex. CRM, Project). |
| Cache interne de Dolibarr | Cache persistant des résultats de recherche/selection. | Dans Setup → Misc → Cache, activez Cache et définissez Cache lifetime = 3600. |
| Utiliser le moteur de templating "Smarty" en mode « compile never » | Évite la recompilation des templates à chaque appel. | Ajoutez $php->setVar('tplCacheCompileDir', '/tmp'); $php->setVar('tplCacheCompile', false); dans design.php. |
| Batch jobs planifiés | Traite les tâches lourdes (ex. export PDF, sauvegarde) hors heures de pic. | Utilisez cron avec les scripts php -f /path/to/dolibarr/cron.php. |
| Limiter les téléchargements de fichiers volumineux via Range | Réduction de la charge serveur et meilleure UX. | NGINX location ~* \.(pdf|docx)$ { add_header Accept-Ranges bytes; } |

3.3 Tâches asynchrones & queues

  • Cron jobs : par défaut Dolibarr s’appuie sur des appels récurrents (php cron.php).

  • Alternative recommandée : RabbitMQ ou Redis Queue (BullMQ) pour déléguer les traitements lourds : génération de factures, envoi d’emails, nettoyage de logs.

  • Avantage : le serveur web reste réactif; les workers peuvent être scalés indépendamment.

3.4 Monitoring & alertes

Métrique Seuil d’alerte Outil recommandé
Latence moyenne des requêtes HTTP > 500 ms Grafana + Prometheus
Taux d’erreur 5xx > 1 % Alertmanager
Utilisation CPU MySQL > 80 % pendant 5 min Percona Monitoring
Espace disque DB > 80 % du volume Zabbix
File d’attente de worker (Redis/RabbitMQ) > 10 000 messages Kibana

Bon à savoir : exportez les logs Dolibarr en format JSON (log4j2 ou monolog) pour les ingérer facilement dans votre stack ELK.

4. Checklist de mise en production

✅ Action Responsable Commentaire
1 Installation du serveur web (NGINX) avec TLS Let’s Encrypt. Ops Vérifier le renouvellement automatique (certbot renew).
2 Configuration du module SSO (OAuth2/OpenID Connect). Sécurité Tester le flux complet (login → callback → groupe).
3 Activation du cache interne et du opcache PHP. Dév/Ops Valider opcache_get_status() dans phpinfo().
4 Optimisation de la base (index, innodb_buffer_pool_size). DB‑Admin Exécuter ANALYZE TABLE après gros import.
5 Mise en place d’un cron pour les tâches planifiées. Ops Utiliser */5 * * * * php /var/www/dolibarr/cron.php.
6 Déploiement d’un worker (Redis/RabbitMQ) pour les jobs asynchrones. Dev Surveiller le nombre de jobs en attente.
7 Configuration du monitoring (Prometheus, Grafana). Ops Créer des alertes dès le dépassement des seuils.
8 Tests de charge (JMeter/Locust) sur les scénarios clés (ex. création facture). QA Simuler 200 RPS et valider la latence < 300 ms.
9 Sauvegarde quotidienne + rétention 30 jours (full + incrémental). DBA Tester la restauration au moins une fois par trimestre.
10 Audit de sécurité (OWASP ZAP) + revue SSO. SecOps Corriger toute vulnérabilité critique avant le go‑live.

5. Cas d’usage réel (exemple)

Entreprise : TechNova (150 employés, production de pièces mécaniques)

Besoin Solution mise en œuvre
Gestion des devis, factures et stocks Dolibarr installé sur un serveur Ubuntu 22.04 (4 CPU, 8 GB RAM).
Authentification unique avec Azure AD Implémentation du module SSO (OAuth2) ; mapping des groupes « admin », « manager », « employee ».
Rapidité de l’interface pour les équipes commerciales Optimisation du cache interne, désactivation du module “CRM” non utilisé, gzip + Brotli.
Rapports financiers nocturnes (export PDF) Workers Redis Queue exécutant php gen_reports.php à 02 h00, sans impacter les utilisateurs actifs.
Surveillance en temps réel Dashboard Grafana avec Prometheus collector : latence < 250 ms, 0 % d’erreurs 5xx.
Sauvegarde et reprise Backup quotidien mysqldump + innodb_file_per_table → Recovery testée chaque trimestre.

Résultat : 30 % de réduction du temps de réponse (de 700 ms → 500 ms) et 0 incident de sécurité depuis le passage en production avec SSO et l’architecture décrite.

6. Conclusion

Dolibarr peut être déployé en production sans sacrifier la performance lorsqu’on adopte les bonnes pratiques suivantes :

  1. SSO : centraliser l’authentification via les modules natifs ou un reverse‑proxy, tout en gardant le contrôle des groupes et des droits.

  2. Performance : exploiter le reverse‑proxy (NGINX), optimiser PHP‑FPM et MySQL, activer les caches (opcache, interne Dolibarr), et déléguer les traitements lourds à des workers asynchrones.

  3. Surveillance & backup : mettre en place des alertes précoces et des stratégies de sauvegarde robustes.

En suivant la checklist et les astuces présentées, votre instance Dolibarr sera prête à supporter des centaines d’utilisateurs simultanés, à rester conforme aux exigences de sécurité modernes (SSO, HSTS, CSP…) et à offrir une expérience fluide à vos équipes.

Sources & ressources complémentaires

Rédigé par l’équipe Architecture & Performance – 03 Novembre 2025.

Publications similaires