Dolibarr en production : multi-société et bonnes pratiques pour mieux piloter

Dolibarr en production : Multi‑société et bonnes pratiques pour mieux piloter votre activité

Version : Novembre 2025 – pour les équipes qui souhaitent exploiter Dolibarr comme solution ERP/CRM industrielle à l’échelle de plusieurs entités juridiques.

1. Introduction

Dolibarr est un ERP‑CRM open source qui se veut simple à installer, à configurer et à personnaliser. Depuis la version 9, la plateforme propose un mode « multi‑société » (ou multi‑company) qui permet de gérer simultanément plusieurs structures juridiques (sociétés, filiales, associations) depuis une même base de données, tout en séparant leurs données et leurs processus métier.

De nombreux groupes d’entreprises, PME à activités diversifiées ou communautés de projets utilisent Dolibarr pour :

  • centraliser la comptabilité, les achats, les ventes, la gestion des stocks et des contrats dans chaque entité;

  • partager les tableaux de bord, les rapports consolidationnés et les exigences de conformité;

  • garantir la sécurité des données sensibles grâce à des droits d’accès granulaire.

Le défi consiste à passer de « un seul » à « plusieurs » sociétés tout en préservant la performance, la gouvernance et la conformité. Cet article décrit comment activer et exploiter le mode multi‑société, puis détaille les bonnes pratiques à appliquer pour piloter efficacement ces environnements en production.

2. Architecture du mode multi‑société dans Dolibarr

Concept Description Implications opérationnelles
Entité légale Chaque société possède son identifiant société (socid) et un code société (company_id). Permet de filtrer tous les enregistrements (articles, fiches clients, factures, etc.) par société.
Schémas de données Toutes les tables sont partagées, mais des colonnes socid marquent l’appartenance. Requêtes multi‑société doivent inclure le filtre WHERE socid = :societe_id.
Modules spécifiques Certains modules (ex. : Product Families, Priceتم, Contracts) offrent un paramétrage par société. Nécessite la mise à jour des paramètres de chaque société (ex. : seuils de stock différents).
Utilisateurs et groupes Les droits d’accès sont définissables par socid via les groupes d’utilisateurs. On peut restreindre lavue du dossier comptable d’une société à certains collaborateurs.
Multi‑société native Depuis Dolibarr 9+, le mode multi‑société est intégré nativement, aucune extension externe requise. Simplifie la mise à jour, la compatibilité et le support officiel.

À retenir : le multi‑société ne crée pas de bases de données séparées, mais un même référentiel physique où chaque ligne possède un identifiant société. Cette architecture assure une meilleure cohérence des données (pas de duplication) mais impose de toujours filtrer par société dans les requêtes personnalisées.

3. Passage en production multi‑société : étapes clés

  1. Audit préalable

    • Lister chaque société (nom, SIRET, devise, paramètres comptables).

    • Définir les flux métiers spécifiques (ex. : plusieurs statutes de TVA, traitements d’intrants différents).

  2. Installation initiale

    • Déployer la dernière version stable de Dolibarr (ex. v23.x).

    • Créer une base de données unique où chaque société sera associée à un socid.

  3. Création des sociétés (Setup → Sociétés → Gestion des sociétés)

    • Ajouter chaque entité avec :

      • Nom de la société (affiché dans le menu).

      • Socid (auto‑généré ou choisi). – Currency (devises supportées).

      • Comptable (ex. : mode de gestion, type de comptabilité).

    • Activer l’option « Activer le mode multi‑société » dans les paramètres globaux.

  4. Configuration des modules

    • Articles : définir des familles par société si besoin.

    • Clients / Fournisseurs : créer des listes distinctes ou partager certaines avec droits d’accès limités. – Paiement : prévoir des moyens de paiement différents selon société (ex. : SEPA vs. PEB).

  5. Migrations des données existantes

    • Exporter les données par société via les fonctions d’export CSV ou les scripts SQL INSERT INTO ... SELECT ... WHERE socid = X. – Importer en vérifiant les contraintes d’intégrité (foreign key sur socid).

  6. Sécurisation

    • Définir les groupes d’utilisateurs (ex. : admin_soc1, user_soc2).

    • Associer chaque groupe à une ou plusieurs sociétés via la rubrique Access Rights → Societies.

  7. Tests fonctionnels – Scénarios de création de facture, de devis, de commande d’achat par société.

    • Vérification de la consolidation (rapports consolidés, tableau de bord global).

    • Tests de charge (charge simultanée de plusieurs sociétes) pour identifier les points de goulot d’étranglement.

  8. Mise en production

    • Planifier la bascule lors d’une période de faible activité.

    • Mettre en place un processus de rollback (point de sauvegarde complet, versionnage du code).

4. Bonnes pratiques pour piloter des environnements multi‑société

4.1. Gouvernance et organisation

Action Pourquoi Comment la mettre en œuvre
Charte de gouvernance multi‑sociétés Clarifie les responsabilités et évite les doublons de configuration. Rédiger un tableau de calcul décrivant le périmètre par société (siège, filaux, activités annexes).
Comité de pilotage mensuel Suivi de la conformité, des KPI, des incidents de sécurité. Centraliser les rapports de suivi (finances, stocks, ventes) par société dans un tableau de bord unique.
Processus de validation des changements Empêche les modifications non contrôlées qui pourraient impacter plusieurs entités. Utiliser le workflow Git‑Lab ou GitHub avec des branches « release/societe‑X ».

4.2. Sécurité et conformité

  • Gestion fine des droits : Exploiter les access rules pour limiter chaque utilisateur à la société ou aux sociétés dont il a le droit de voir les données.

  • Audit trail : Activer le module History pour enregistrer chaque modification (qui, quoi, quand). Exporter les logs d’audit vers un SIEM pour une détection précoce.

  • Chiffrement :

    • En base MySQL/MariaDB, activer innodb_encrypt_tables (ou transparent_data_encryption en version ≥ 10).

    • Utiliser TLS/SSL pour les communications API (ex. : via le module Web Services). – Conformité fiscale : Mettre à jour les paramètres de TVA, de rétentions et de rapports fiscaux par société afin d’éviter les erreurs de conformité.

4.3. Optimisation des performances

  • Indexation ciblée : Ajouter un index sur socid dans toutes les tables critiques (llx_facture, llx_product, llx_stock). 
    ALTER TABLE llx_facture ADD INDEX idx_facture_soc (socid);

  • Partitionnement (optionnel) : Si le volume est très important (≥ 10 M lignes), considérer le partitionnement par socid pour accélérer les requêtes ciblées.

  • Cache des listes statiques : Uniformiser les listes de codes (ex. : codes clients) par société dans le cache mémoire (memcached ou redis).

  • Batchs nocturnes : Limiter les traitements lourds (recomptage de stocks, génération de états) à des plages horaires hors connexion. Utiliser le cron de Dolibarr : 
    */30 * * * * /usr/bin/php /var/www/dolibarr/cron.php > /dev/null 2>&1

4.4. Reporting & consolidation

Fonctionnalité Option native Astuce pratique
Tableau de bord consolidé Rapports « Summaries » → regrouper par socid. Créer un tableau personnalisé avec des charts (Barres, Radar) pour visualiser les indicateurs clés par entité.
Consolidation comptable Importer les fichiers de comptabilité au format CSV ou utiliser le module ThirdParty intégré. Développer un script PHP qui regroupe les états de resultados en PDF avec un sélecteur de période par société.
BI via Power BI / Metabase Connecter directement la base via ODBC. Configurer les views qui filtrent automatiquement le champ socid. Exemple : 



  CREATE VIEW vw_sales AS

  SELECT * FROM llx_sales WHERE socid = 1;

  ``` |

| **Alertes automatisées** | Module *Notification* + règle de déclenchement. | Configurer des **alertes** (ex. : dépassement du seuil de stock) avec un canal Slack ou email dédié à chaque société. |
#### 4.5. Gestion des mises à jour & évolutions  
- **Versionning du code** : Utiliser **Git** pour versionner les customisations (templates, modules).  

- **Testing automatisé** : Intégrer des tests unitaires (PHPUnit) qui vérifient que les nouvelles modifications n’impactent pas inadvertamment les données d’une société.  

- **Plan de migration** : Documenter chaque mise à jour majeure (ex. : passage de Dolibarr 9.x à 9.2) avec les points de blocage spécifiques au multi‑société (ex. : migration du champ `socid` en 1.6).  

- **Rollback** : Conserver des sauvegardes incrémentales (ex. : `xbstream`) avant chaque mise à jour et tester la restauration sur un environnement de pré‑production.  
#### 4.6. Optimisation de l’expérience utilisateur  
- **Thèmes et langues** : Créer des thèmes dédiés par société afin de refléter les charte graphiques propres à chaque entité.  

- **Portails auto‑service** : Utiliser le module *Customer Portal* pour offrir à chaque client une vue limitée à la société concernée.  

- **Formulaires personnalisés** : Ajouter des champs spécifiques via le module *ThirdParty* afin de recueillir des informations légales propres à chaque société (ex. : numéro d’immatriculation de la branche bancaire).  
---
### 5. Cas d’usage concrets  #### 5.1. Un groupe de distribution avec 3 filiales  

- **Avant** : Chaque filiale utilisait une instance Dolibarr séparée, entraînant duplication des articles et des coûts de maintenance.  

- **Après** : Installation d’une **unique instance multi‑société** où chaque filiale possède son `socid`.  

- **Résultat** :  

  - Réduction de 30 % des licences serveur (un seul serveur Apache + MariaDB).    - Consolidation des stocks de matières premières (centralisée à l’échelle du groupe).  

  - Reporting mensuel automatisé depuis le tableau de bord central, avec alertes si le chiffre d’affaires d’une filiale chute de plus de 15 %.  
#### 5.2. Une coopérative agricole et ses exploitations membres  

- **Configuration** : Chaque exploitation possède son `socid` et ses propres comptes bancaires.  

- **Bonne pratique appliquée** :    - Tableaux de bord séparés pour les comptabilités internes, tout en conservant un **condashboard global** qui suit le volume de production du réseau.  

  - Utilisation du module *Contracts* pour gérer les contrats d’achat de fourrage avec des clauses spécifiques selon l’exploitation.  
---
### 6. Pièges fréquents & comment les éviter  
| Piège | Conséquence | Solution préventive |

|------|--------------|----------------------|

| **Oublier le filtre `socid`** dans les requêtes SQL personnalisées | Retour de données d’autres sociétés → erreurs de business logic. | Toujours injecter `WHERE socid = :current_society` dans les vues ou scripts de reporting. |

| **Configuration de droits trop permissifs** | Accès non autorisé à des données comptables sensibles. | Revue périodique des droits via le module *Access Rights* et audit chaque trimestre. |

| **Surchargement du serveur lors de pics d’activité simultanée** | Temps de réponse > 5 s, dégradation de l’expérience. | Mettre en place un **load‑balancer** ou répliquer la base en lecture pour les rapports. |

| **Mauvais paramétrage de la devise** | Arrondis incorrects, erreurs de conversion. | Vérifier la devise par société et effectuer des tests de conversion sur 1000 lignes aléatoires. |

| **Mise à jour du core sans compatibilité multi‑société** | Perte de données ou incompatibilité des colonnes `socid`. | Avant chaque mise à jour, consulter les *release notes* et tester sur une copie de production. |
---
### 7. Checklist de mise en production  
| ✅ | Action |

|----|--------|

| 1 | Backup complet de la base (dump SQL + sauvegarde des fichiers `htdocs/custom`) |

| 2 | Activation du mode multi‑société dans *Setup → Company → Enable multi-company* |

| 3 | Création des sociétés (`socid`, devise, paramètres comptabilité) |

| 4 | Import des données historiques (clients, articles, stocks) en vérifiant les filtres `socid` |

| 5 | Attribution des droits d’accès par groupe et par société |

| 6 | Tests fonctionnels : création de devis, factures, commandes par société |

| 7 | Création des rapports de consolidation et validation des totaux |

| 8 | Mise en place des alertes (email / Slack) pour seuils critiques |

| 9 | Documenter les procédures de rollback & de mise à jour |

|10| Planifier la première **revue post‑déploiement** (30 jours) avec les parties prenantes |
---
### 8. Conclusion  
Le mode **multi‑société** de Dolibarr constitue une plateforme puissante pour centraliser la gestion financière, logistique et commerciale de plusieurs entités sans recourir à une multiplication d’instances disparates. En suivant les bonnes pratiques décrites ci‑dessus — governance rigoureuse, sécurité fine, optimisation des performances, reporting consolidé et contrôle des changements — vous transformerez les contraintes techniques en leviers de **efficacité opérationnelle** et de **transparence** pour l’ensemble de vos sociétés.
**À retenir** : la clé du succès réside dans le **filtre `socid`** appliqué partout, la **délimitation claire des accès** et la **mise en place d’un processus de gouvernance** qui anticipe les évolutions futures. En adoptant ces principes, votre architecture multi‑society sera non seulement robuste, mais également prête à évoluer avec la complexité croissante de votre groupe.
---
*Pour toute question technique détaillée (scripts de migration, paramétrage de modules spécifiques, intégration BI), n’hésitez pas à me le préciser ; je pourrai vous fournir des exemples de code ou des postes de configuration adaptés à votre contexte.*

Publications similaires