Architecture Dolibarr : secteurs pour passer à l’échelle

Par [Votre Nom] – [Date]

Introduction

Dolibarr est un ERP/PGMI (Gestionnaire de Gestion Intégrée) open‑source particulièrement adaptable, ce qui en fait un choix idéal pour les PME, les associations, les startups et même les grandes entreprises qui souhaitent digitaliser leurs processus métiers. Mais comme tout logiciel, l’architecture de Dolibarr doit être pensée dès le départ si l’on veut passer à l’échelle sans perdre en performance, en sécurité ou en maintenabilité.

Cet article détaille :

  1. Les composantes clés de l’architecture de Dolibarr.

  2. Les stratégies de mise à l’échelle appliquées aux principaux secteurs d’activité (e‑commerce, services, fabrication, distribution, etc.).

  3. Les bonnes pratiques à ne pas négliger (bases de données, cache, hébergement, CI/CD, sécurité).

1. Architecture de base de Dolibarr

Couche Composant Rôle
Présentations Templates (Smarty), UI mobile Interface web (écran, cahier de charges).
Logique métier Modules (ex. : product, order, invoice), Controllers Gestion des transactions, validations métier.
Persist­ence MySQL / MariaDB / PostgreSQL Stockage des données structurées.
Services externes API (PayPal, Stripe), SMTP, LDAP Fonctionnalités additionnelles (paiement, mailing).
Middleware Apache/Nginx, PHP‑FPM Routage des requêtes, gestion des processus PHP.
Cache & Jobs APCu, Redis, RabbitMQ, Cron Optimisation des appels récurrents et traitements asynchrones.

Astuce : Dans une architecture « cloud‑native », le controller et le service peuvent être externalisés dans des micro‑services Dockerisés, ce qui rend le déploiement de Dolibarr plus « modulaire ».

2. Scalabilité par secteur d’activité

2.1. E‑commerce (boutiques en ligne)

Besoin Solutions de mise à l’échelle
Gestion des pics (Black‑Friday, promotions) • Horizontal scaling : ajouter des pods Docker/Nginx derrière un Load Balancer.
• Cache d’objets : Redis/Memcached pour les vues de fiches produits frequently accessed.
• Queue de paiement : décaler les appels à la passerelle (Stripe, PayPal) vers RabbitMQ ou Kafka.
Traitement des paiements Utiliser un consumer dedicado à l’API de paiement (ex. : Symfony Messenger ou simple daemon PHP) qui place les transactions en file d’attente avant validation.
Catalogue dynamique Table product en partitionnement_hash sur le champ category_id afin de répartir les fiches produit sur plusieurs nœuds DB.
Multilingue + Monto Stocker les langues dans des tables séparées, chaque langue sur un shard dédié (utile si le trafic multilingue devient très asymétrique).

Mise en pratique 1. Déployer l’application dans un cluster Kubernetes avec autoscaling basé sur CPU/mémoire et le nombre de requêtes/séc.

  1. Configurer un L7‑Ingress (Traefik/NGINX) avec TLS termination.

  2. Activer le cache dynamique de Dolibarr ($conf->global->cache_* en mode redis).

2.2. Services & Consulting (agences, cabinets)

Besoin Solutions
Gestion de projets multiples Créer un modèle de projet dédié avec ses propres champs personnalisés (CRM) et le sauvegarder dans un schéma dédié (schéma de base de données séparé) via l’extension Multi‑DB.
Temps & facturation Utiliser le module time & expense + cron pour générer automatiquement les factures toutes les 24h. Un worker distinct assure le calcul des factures sans charger le front‑office.
Collaboration Intégrer LDAP/Active Directory + SSO (Keycloak ou Azure AD) pour simplifier l’accès OAuth2/SAML.
Scalabilité Étendre la couche web avec Nginx + PHP‑FPM en mode pool dédié aux “admin” (gestion des projets). DB Read‑Replica pour les rapports lourds.

Mise en pratique

  • Docker Compose pour séparer web, scheduler, worker et db.

  • Journalisation centralisée (ELK ou Loki) afin de suivre les aller‑retours de tickets et d’optimiser les processus internes.

2.3. Fabrication / Production

Besoin Solutions
Gestion des stocks multiples sites / entrepôts Activer le module stocks en mode multi‑sites ; chaque site possède son propre schema de stock (ex. warehouse_1, warehouse_2). Utiliser replication de la table product_stock vers un data‑warehouse (Snowflake/Redshift) pour le reporting.
Traçabilité des lots Ajouter des champs custom (lot_number, batch_expiry) dans product et product_combination et indexer ces colonnes.
Intégration avec MES/ERP Exposer REST API ou SOAP (via soap_server) pour pousser les mouvements de stock vers un système externe. Utiliser message broker (RabbitMQ) pour la rétroaction en temps réel.
Scalabilité Partitionner la base via sharding de la table stock_quantities par warehouse_id. Ajouter des cluster de caches (Redis) pour les requêtes de disponibilité instantanées.

2.4. Distribution / Logistique

Besoin Solutions
Gestion des commandes Configurer le module order en status‑workflow fortement customisé (ex. : preparé → emballé → expédié → signé). Utiliser queue de traitement (Kafka) pour déclencher automatiquement les notifications d’expédition.
Suivi des livraisons Intégrer Google Maps API ou OpenStreetMap via des web‑hooks afin de calculer les itinéraires optimisés (algorithme de routage).
Multi‑devise / Multi‑langue Centraliser la conversion de devises dans un micro‑service dédié (Node/Python) et appeler cet endpoint depuis Dolibarr via curl.
Scalabilité Read‑scale : placer les requêtes de reporting (statistiques de volume de commandes) sur des replicas en lecture seule.
Write‑scale : segmenter la table order par année (partitionnement par range) pour éviter les locks lors de gros batchs d’import.

2.5. Secteur public / Associations

Besoin Solutions
Gestion des subventions / dotations Utiliser le module contrib (subventions) avec table de correspondance multi‑tenant (un enregistrement par subvention).
Reporting réglementaire Générer les rapports PDF via FPDF ou Dompdf asynchrone (backend job). Mettre en place audit trail via logbook module et sauvegarder les changements dans une table d’audit non modifiable.
Scalabilité Limiter les requêtes lourdes aux heures creuses. Utiliser des jobs cron planifiés avec crond ou systemd timers au lieu de executephp au runtime.
Sécurité Mettre en place rate‑limiting (Nginx limit_req) et IP whitelist pour les accès externes. Un HTTPS strict (HSTS) est obligatoire.

3. Bonnes pratiques transversales pour passer à l’échelle

Domaine Action clé Pourquoi
Base de données • Partitionnement (range / hash) des tables volumineuses (order, stock, product_combination).
• Replication précédente (master‑slave) pour les lectures intensives.
• Utilisation d’un ORM léger (Dolibarr utilise PDO) avec pool de connexions.		 Réduit les locks, améliore les temps de réponse pour les rapports massifs.
Cache • Activer $conf->global->cache_* → redis ou memcached.
• Cache des vues SQL fréquentes (orderstatus, productlist) avec TTL courte (< 5 min) pour les pics.		 Diminue le nombre d’appels DB.
File d’attente • Déplacer les traitements asynchrones (envoi email, génération PDF, paiement) dans des workers dédiés (ex. : php queue_worker.php). Sépare la charge de la UI et évite les time‑outs.
Hébergement • Containers (Docker) avec php-fpm & nginx séparés.
• Orchestration via Kubernetes ou Docker Swarm (auto‑scaling, health‑checks).
• Storage : volume tmp partagé via NFS ou Ceph si besoin de persistance.		 Facilite le scaling horizontal, la récupération en cas de panne.
CI / CD • Pipeline CI (GitHub Actions, GitLab CI) avec linting PHP, tests unitaires (PHPUnit), tests d’intégration (behat).
• Déploiement Blue/Green ou Canary pour minimiser les risques.		 Garantit la stabilité en production lorsqu’on ajoute de nouvelles extensions ou modules personnalisés.
Monitoring • Prometheus + Grafana pour métriques php-fpm, nginx, redis, mysql.
• Alertes sur le nombre de requêtes lentes (slowlog), le taux d’erreurs 5xx, et l’utilisation de la mémoire.		 Permet d’anticiper les goulots d’étranglement avant qu’ils n’affectent les utilisateurs.
Sécurité • Mise à jour régulière du core (git pull origin master).
• Utilisation de mod_security et fail2ban.
• Chiffrement TLS 1.3 + HSTS.
• Séparer les comptes DB par application (user dédié, pas root).		 Réduit les surface d’attaque et empêche la compromission du serveur.
Scalabilité fonctionnelle • Ajouter des hooks dans les modules (hookObject*) pour injecter du code personnalisé sans modifier le core.
• Créer des modules complémentaires (ex. : myext_logistics) qui utilisent les mêmes tables mais avec leurs propres préfixes de champ pour éviter la fuite de schéma.		 Facilite l’évolution incrémentale de l’ERP sans réécrire tout le code.

4. Exemple de workflow de mise en production

  1. Audit initial

    • Export des statistiques de trafic (analytics.php) pour identifier les pics et les limites actuelles.

    • Analyse de la taille des tables ( SHOW TABLE STATUS ).

  2. Définir les shards 

    ALTER TABLE dolibarr_product 
    
 PARTITION BY HASH(id_product) PARTITIONS 4;

    Déploiement des partitions sur 4 serveurs DB.

  3. Création du pipeline CI 

    # .gitlab-ci.yml
    
build:
    
 stage: build
    
 image: php:8.2-fpm
    
 steps:
    
   - apt-get update && apt-get install -y unzip git
    
   - curl -sS https://getcomposer.org/installer | php
    
   - composer install --optimize-autoloader
    
   - vendor/bin/phpunit
    
 only:
    
   - master

  4. Déploiement dans Kubernetes « `yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: dolibarr
    spec:
    replicas: 3
    selector:
    matchLabels:
    app: dolibarr template:
    metadata:
    labels:
    app: dolibarr
    spec:
    containers:

    • name: php-fpm image: myrepo/dolibarr:php8.2-fpm
      env:

      • name: DB_HOST
        value: "db-primary.default.svc.cluster.local"

      • name: DB_USER
        valueFrom:
        secretKeyRef:
        name: dolibarr-db-credentials
        key: username resources:
        limits:
        memory: "512Mi"
        cpu: "500m"
        livenessProbe:
        httpGET:
        path: /
        port: 80
        initialDelaySeconds: 30
        periodSeconds: 10

  5. Définir les workers 

    # script/worker.sh
    
php bin/console dolibarr:payments:process --queue=payments
    
php bin/console dolibarr:order:generateInvoices --queue=invoices

    Lancer via systemd ou Kubernetes CronJob.

  6. Monitoring & Alerting – Prometheus collecte : php_fpm_active_processes, nginx_connections, redis_memory_used_bytes.

    • Alertmanager déclenche une alerte si order_status_changes > 500/mo.

5. Conclusion

Passer à l’échelle avec Dolibarr n’est pas seulement question de plus de serveurs ; c’est avant tout une architecture orientée services, un design de données anticipatif et une organisation du code qui respecte les limites du framework. En suivant les principes présentés :

  • Segmenter les domaines fonctionnels (e‑commerce, services, production, distribution).

  • Externaliser les traitements lourds (paiement, facturation, génération de rapports) dans des workers ou micro‑services.

  • Optimiser la base de données (partitionnement, réplication, cache).

  • Automatiser le déploiement avec containers, CI/CD et monitoring.

vous êtes alors en mesure de scaler de façon prévisible quel que soit le secteur d’activité de votre client. Dolibarr, grâce à sa modularité et son vaste écosystème d’extensions, devient alors un véritable moteur de digitalisation « prêt‑pour‑la‑croissance ».

Ressources complémentaires

Ressource Lien
Documentation officielle Dolibarr (architecture & modules) https://docs.dolibarr.org/en/latest/
Guide de scalabilité MySQL/MariaDB (partitionnement) https://dev.mysql.com/doc/refman/8.0/en/partitioning.html
Kubernetes autoscaling best‑practices https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
Dolibrarmods – Extensions populaires (e‑commerce, multi‑stock) https://github.com/Dolibarr/dolibarr-modules
Article : « Multi‑tenant ERP with Dolibarr » (PDF) https://www.example.com/dolibarr-multitenant.pdf

Vous avez besoin d’un schéma d’architecture plus détaillé ou d’une implémentation d’exemple pour votre secteur ? N’hésitez pas à me contacter ! —

Cet article a été rédigé à la lumière des retours d’expérience de la communauté Dolibarr et des meilleures pratiques cloud‑native.

Publications similaires