Architecture Dolibarr : automatisation pour passer à l’échelle

Dolibarr : automatiser l’architecture pour passer à l’échelle
Guide technique pour intégrer, orchestrer et faire évoluer Dolibarr dans un environnement industriel

— ## 1. Introduction

Dolibarr ERP‑CRM est une solution Open‑Source très populaire pour la gestion de petites et moyennes structures. Sa simplicité d’installation et son modèle de plugins en font un excellent point de départ, mais lorsqu’il s’agit de supporter plusieurs dizaines voire plusieurs centaines d’utilisateurs ou de traiter des volumes de données importants, la question de l’architecture devient cruciale. Ce qui a longtemps limité la mise à l’échelle de Dolibarr, c’est son monolithe PHP/MySQL. Aujourd’hui, grâce à des patterns modernes d’automatisation (Docker, CI/CD, orchestration cloud, scripting), il est possible de :

  1. Isoler les dépendances (PHP, extensions, modules)

  2. Déployer rapidement (immutable infrastructure) 3. Surveiller et rééquilibrer la charge (auto‑scaling, load‑balancing)

  3. Automatiser les sauvegardes, la synchronisation des données et les mises à jour

Cet article détaille l’architecture recommandée pour Dolibarr en mode « scale‑out », propose les meilleures pratiques d’automatisation et fournit des schémas d’implémentation concrètes.

2. Architecture de base de Dolibarr

Couche Composant Rôle Points de friction pour le scaling
Web Apache/Nginx + PHP‑FPM Exposition de l’interface web Goulots d’étranglement HTTP si le pool PHP est statique
Business Dolibarr (PHP) Logique métier, modules Accès partagé à la base de données, état limité
Data MySQL / MariaDB / PostgreSQL Persistance des données Bottleneck de lecture/écriture, single‑writer
Cache / Job APCU / Redis (optionnel) Session + files d’attente Nécessite un store partagé ou externe

Limite principale : le moteur PHP est stateless mais dépend d’un unique serveur de base de données. Pour dépasser le plafond de charge, il faut décomposer ces couches et les orchestrer de façon automatisée.

3. Stratégie d’automatisation de l’infrastructure

3.1 Conteneurisation (Docker)

  • Image Docker unique : builder une image dolibarr:latest incluant

    • PHP‑FPM (version 8.2 ou supérieure)

    • Extensions requises (pdo_mysql, intl, gd, zip)

    • cron intégré pour les tâches périodiques (ex. : nettoyage des doublons, sauvegarde)

  • Multi‑stage build :

    1. Build : installation des dépendances, compilation du code

    2. Runtime : image minimale (php:apache-alpine + dolibarr)

  • Docker‑Compose : il sert de dev‑ops de test local. 
    version: "3.8"
    
services:
    
web:
    
  image: myrepo/dolibarr:web
    
  ports: ["80:80"]
    
  depends_on: ["db"]
    
  environment:
    
    - APP_ENV=prod
    
  volumes:
    
    - ./custom:/var/www/html/custom   # plugins, thèmes
    
db:
    
  image: mariadb:10.11
    
  environment:
    
    - MYSQL_ROOT_PASSWORD=secret
    
    - MYSQL_DATABASE=dolibarr
    
    - MYSQL_USER=dolibarr
    
    - MYSQL_PASSWORD=secret
    
  volumes:
    
    - db-data:/var/lib/mysql
    
redis:
    
  image: redis:7-alpine
    
  command: ["redis-server", "--appendonly", "yes"]
    
  volumes: ["redis-data:/data"]
    
volumes:
    
db-data:
    
redis-data:

3.2 Orchestration et scaling

Conteneur Replication recommandée Méthode de mise à l’échelle
web N réplicas (NFS‑shared cache ou Redis) Horizontal Pod Autoscaler (HPA) basé sur cpu ou http_requests_per_cpu
db 1 (ou plus avec Galera/ProxySQL) Pas d’horizontal scaling direct, mais read‑replicas pour les opérations en lecture
redis 1 ou plus (cluster) Pour gérer les jobs asynchrones (cron, notifications)

Note : Dolibarr n’est pas conçu nativement pour le clustering multi‑write. La solution consiste à externaliser le cache (APCu → Redis) et à déployer les job workers via composer cron ou php-batch.

3.3 CI / CD automatisé

Étape Outil Impact
Build d’image GitLab CI / GitHub Actions Produits automatisés à chaque git push
Tests unitaires PHPUnit (plugins) + Behat (UI) Garantir la non‑regression avant le déploiement
Static analysis phpstan, PHPCS Qualité du code
Versioning Semantic Release (semver) Tagging automatique des releases
Déploiement ArgoCD / FluxCD (GitOps) Application sans interruption, rollback instantané
Monitoring Prometheus + Grafana Alertes sur latence, erreur 5xx, utilisation mémoire

4. Modèle d’automatisation des requêtes de scaling

4.1 Autoscaling horizontal du front‑end

« `yamlapiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: dolibarr-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: dolibarr-web
minReplicas: 2
maxReplicas: 20
metrics:

  • type: External
    external:
    metric:
    name: http_requests_per_cpu
    target:
    type: AverageValueUtilization averageValue: "500"

  • Bibliothèque : nginx-ingress expose le compteur http_requests_per_cpu grâce au NGINX Prometheus Exporter.

  • Scaling trigger : lorsqu’un CPU dépasse 500 RPS par pod, un nouveau pod démarre.

4.2 Gestion des jobs de maintenance

Dolibarr possède des scripts périodiques (cron internes). Pour les exécuter de façon décentralisée :

  1. Créer un conteneur cron-worker basé sur la même image que web.

  2. Définir la fréquence via un CronJob Kubernetes : 

    apiVersion: batch/v1
    
kind: CronJob
    
metadata:
    
 name: dolibarr-db-backup
    
spec:
    
 schedule: "0 */4 * * *"   # toutes les 4h
    
 jobTemplate:
    
   spec:
    
     template:
    
       spec:
    
         containers:
    
         - name: backup
    
           image: myrepo/dolibarr:cron
    
           env:
    
           - name: BACKUP_BUCKET
    
             valueFrom:
    
               secretKeyRef:
    
                 name: s3-credentials
    
                 key: access_key_id
    
           command: ["php","/var/www/html/cron/backup.php"]

  3. Conserver les sauvegardes dans un store externe (S3, MinIO, Azure Blob) avec rotation automatisée (retention 30 jours).

4.3 Synchronisation des statuts et des sessions

  • Sessions : stockées dans Redis plutôt que dans le filesystem. 
    // configurationphp.ini
    
session.save_handler = redis  session.save_path = "tcp://redis:6379"

  • Files d’attente : utiliser php-amqp ou symfony/mailer pour les e‑mails, notifications, etc.

  • Cache : activer APCu uniquement en mode single‑node ; en multi‑node privilégier Redis ou Memcached.

5. Exemple complet : déploiement sur Kubernetes (AWS EKS)

5.1 Infrastructure as code (IaC)

# modules/k8s/main.tfmodule "dolibarr_eks" {

  source = "terraform-aws-modules/eks/aws"

  version = "21.2.0"
cluster_name = "dolibarr-prod"

  cluster_endpoint_private_access = true

  cluster_endpoint_public_access = false
vpc_config {

    cidr_block = "10.0.0.0/16"

    public_subnet_ids = [...]   # subnets avec NAT

  }
# Enable IAM OIDC for service accounts

  enable_irsa = true

}

# modules/dolibarr/k8s.tf

resource "kubernetes_deployment" "dolibarr" {

  metadata {

    name = "dolibarr-web"

    labels = { app = "dolibarr" }

  }

  spec {

    replicas = 3

    selector { match_labels = { app = "dolibarr" } }

    template {

      metadata { labels = { app = "dolibarr" } }

      spec {

        container {

          name  = "dolibarr"

          image = "myrepo/dolibarr:web:2.2.0"

          ports { container_port = 80 }

          env {

            name  = "MYSQL_HOST"

            value = kubernetes_service.db.metadata[0].name # service DNS

          }

          env {

            name  = "REDIS_HOST"

            value = kubernetes_service.redis.metadata[0].name

          }

          volume_mount {

            name = "custom"

            mount_path = "/var/www/html/custom"

          }

        }

        volume {

          name = "custom"

          config_map {

            name = "dolibarr-custom"

          }

        }

      }

    }

  }

}

Terraform crée le cluster EKS, puis les manifests Kubernetes sont appliqués via terraform apply. Toutes les ressources sont versionnées dans le dépôt Git.

5.2 Pipeline CI/CD

  1. Merge Request → GitLab CI déclenche build-and-push → image versionnée v2.2.1.

  2. ArgoCD détecte le nouveau tag, met à jour le HelmRelease (ou le Kustomize) : 
    apiVersion: helm.toolkit.fluxcd.io/v2beta1
    
kind: HelmRelease
    
metadata:
    
 name: dolibarr
    
 namespace: production
    
spec:
    
 chart: https://repo.mycorp.com/charts/dolibarr-0.1.0.tgz     values:
    
   replicaCount: 5       image:
    
     tag: v2.2.1

  3. Post‑deployment → exécution de tests de charge (k6) pour valider l’autoscaling.

6. Points d’attention spécifiques à Dolibarr

Aspect Risque Solution d’automatisation
Gestion des modèles de données Ajout de champs dans des versions antérieures → migration non‑déterministe Utiliser Flyway ou Doctrine Migrations dans un conteneur migrate.php exécuté avant chaque déploiement (pre‑upgrade).
Plugins Certains plugins modifient le schéma ou utilisent des fichiers de configuration en dehors du répertoire custom Versionner les plugins dans le même dépôt, inclure leurs migrations et tester via Behat.
Limites de session Si le serveur PHP s’éteint, les sessions stockées dans tmpfs sont perdues Passer à Redis ou Memcached pour la persistance des sessions.
Sauvegarde de la base Dolibarr n’a pas de dump automatisé Scripter mariadb-backup via un CronJob dédié, compresser et pousser vers S3 avec retention.
Conflits d’écriture Si plusieurs pods écrivent simultanément dans la même table Limiter l’écriture à un seul pod (via leader election) ou configurer statement‑level locking (InnoDB).

7. Bonnes pratiques pour “passer à l’échelle” | # | Pratique | Pourquoi |

|—|———-|———-|
| 1 | Stateless front‑end – toutes les données d’état sont dans le cache partagé (Redis) ou la DB | Permet d’ajouter ou de retirer des pods sans perte de session. |
| 2 | Externalisation du cache – APCU → Redis / Memcached | Évite le partage de mémoire entre pods, garantit la persistance. |
| 3 | Planification des jobs – découpler les tâches longues (backup, recherche d’objets) dans des workers | Empêche le blocage du processus web. |
| 4 | Monitoring granulaire – rate(http_requests_total[5m]), db_connections, redis_used_memory | Détecte précocement les goulots d’étranglement avant qu’ils n’impactent les utilisateurs. |
| 5 | Versionning sémantique – chaque changement de version de Dolibarr ou de plugin est tagué major/minor/patch | Facilite le rollback et la planification des migrations. |
| 6 | Policy de sauvegarde – 3 copies (local, off‑site, cold) avec chiffrement | Garantit la résilience face aux pertes de données. |
| 7 | Feature flags – activer/désactiver les modules à chaud via config env | Permet de déployer de nouvelles fonctionnalités sans impacter la charge. |
| 8 | Testing de charge – scripts k6 ou locust exécutés à chaque sprint | Valider la scalabilité avant le passage en prod. |

8. Conclusion

Dolibarr, bien qu’originellement conçu comme une solution monolithique, peut être modernisé et scalé grâce à une approche d’automatisation qui combine :

  • Conteneurisation (Docker, Kubernetes) pour rendre l’infrastructure immutable et déployable à la demande.

  • Orchestration (HPA, CronJobs, Sidecars) afin d’équilibrer la charge et de séparer les préoccupations (front‑end, DB, cache, jobs).

  • CI/CD GitOps pour garantir que chaque version passe par un pipeline de tests rigoriste avant d’être mise en service.

  • Observabilité (Prometheus, Grafana) pour détecter les besoins de scaling en temps réel.

En suivant ces principes, les organisations peuvent passer de quelques dizaines d’utilisateurs à plusieurs milliers sans devoir réécrire leur stack, tout en profitant de la flexibilité d’un environnement cloud‑native.

Prochaine étape : définir le niveau de charge attendu (RPS, nombre d’utilisateurs simultanés), choisir le moteur de base de données (MySQL vs PostgreSQL) et établir le plan de migration des données existantes vers la nouvelle architecture.

Bonne mise à l’échelle ! 🚀

Publications similaires