Dolibarr, l’ERP/CRM open source emblématique, connaît une transformation profonde de son architecture pour répondre aux défis de 2026. Entre modernisation technique, exigences des utilisateurs et mutations du monde numérique, la « fabrication » de Dolibarr se réinvente. Décryptage.
📐 1. Architecture actuelle : Un socle éprouvé mais vieillissant
Aujourd’hui, Dolibarr repose sur une architecture monolithique traditionnelle :
- Framework maison basé sur un modèle MVC simplifié.
- Base de données principale unique (MySQL/ MariaDB/ PostgreSQL).
- Extensions (modules) ajoutant des fonctionnalités, mais souvent avec un couplage fort au cœur.
- Interface web classique en PHP natif, sans framework moderne majeur.
Ce modèle, solide pour des installations de taille moyenne, montre ses limites face à :
- La complexité croissante des processus métier.
- Le besoin d’intégrations multiplateformes (API first).
- Les exigences de performance et de scalabilité.
- Le développement continu (CI/CD) et les tests automatisés.
🔮 2. Les tendances qui façonnent Dolibarr 2026
L’architecture de Dolibarr en 2026 sera mue par plusieurs forces :
- Cloud & SaaS : Montée en puissance des offres hébergées, nécessitant une architecture multi-tenants robuste, une gestion des configurations par locataire et une isolation des données.
- API Centric : Dolibarr doit devenir une plateforme, pas qu’une application. Une API REST/GraphQL moderne, complète et documentée (OpenAPI) sera le nerf de la guerre pour connecter l’ERP à l’écosystème (e-commerce, logistique, outils de compta, etc.).
- Modularité renforcée : Vers une architecture microservices ou modulaire à haute cohésion. Le cœur (« core ») serait réduit à ses fonctions essentielles (utilisateurs, produits, transactions), et chaque grand module (Ventes, Stock, Compta) pourrait évoluer indépendamment.
- Expérience Utilisateur (UX) : Migration progressive vers des interfaces plus réactives (framework JavaScript léger comme Vue.js ou React dans des modules spécifiques) sans sacrifier la simplicité d’accès.
- DevOps & Qualité : Intégration de pipelines CI/CD complets, tests unitaires et fonctionnels automatisés à grande échelle, et monitoring applicatif.
🏗️ 3. Scénario probable de l’architecture Dolibarr en 2026
À l’horizon 2026, une architecture hybride et évolutive semble la voie la plus plausible :
a) Cœur (Core) repensé
- Un micro-kernel ultra-light, gérant uniquement l’authentification, l’autorisation (RBAC fine), le système de modules et les services communs (notification, cache).
- Utilisation d’un composant PHP moderne (ex: Slim, Symfony Components) pour gérer les routes et le middleware, laissant le modèle MVC historique pour la compatibilité ascendante.
b) Modules comme services autonomes
- Chaque grand module (Ventes, RH, Projets) est un package autonome avec :
- Son propre schéma de base de données (possibilité de sharding ou bases dédiées).
- Sa propre logique métier.
- Son contrôleur API RESTful dédié.
- Sa propre couche de vue (template traditionnel ou API consommée par une SPA légère).
- Communication entre modules via événements (Event Sourcing partiel) et API internes, limitant les dépendances directes.
c) API comme couche primaire
- Toutes les actions (création de facture, consultation de stock) passent d’abord par une API REST/JSON.
- L’interface web classique devient alors une application cliente supplémentaire qui consomme cette API, comme le ferait une app mobile ou une connexion depuis un autre logiciel.
- Avantages : Uniformisation, testabilité aisée, réutilisation immédiate pour des intégrations.
d) Persistance des données flexible
- Base principale pour les données transactionnelles stables (clients, produits, historiques).
- Options pour données massives ou temporelles : connexion possible à des bases NoSQL (MongoDB) pour les logs, la télémétrie, ou les données IoT.
- Support renforcé des bases externes (schémas dédiés) pour de gros volumes de stock, par exemple.
e) Infrastructure & Déploiement
- Conteneurisation (Docker) standardisée pour chaque module/service.
- Orchestration possible avec Kubernetes pour les grosses installations SaaS.
- Configuration externalisée (variables d’environnement, fichiers de conf séparés) pour faciliter le déploiementcloud.
- Cache distribué (Redis) obligatoire pour les performances.
⚙️ 4. Implications pour la communauté et les utilisateurs
Cette transformation aura des impacts majeurs :
- Pour les développeurs de modules tiers : Ils devront s’adapter au nouveau modèle d’injection de dépendances et à l’API. La courbe d’apprentissage augmentera, mais la portée de leurs modules aussi.
- Pour les intégrateurs : Moins de "bidouilles" dans le code cœur. L’accent sera mis sur la configuration, le développement de connecteurs API et l’extension via des événements.
- Pour les petites structures : L’installation monolithique classique existera toujours en mode « tout-en-un packagé », mais elle sera une distribution du nouvel ensemble modulaire, pas le core lui-même.
- Pour les grandes entreprises / SaaS : Elles pourront déployer et scaler seulement les modules dont elles ont besoin, sur l’infrastructure de leur choix (privé, public, hybride).
🧱 5. Fabrication : Comment en arrive-t-on là ?
La « fabrication » de cette nouvelle architecture passerait par :
- Phase de prototypage (2024-2025) : Développement en parallèle d’un proof-of-concept modulaire/API, sans casser l’existant.
- Stratégie de migration progressive :
- Option 1 (Douce) : Le核心 actuel continue de fonctionner, mais de plus en plus de modules sont réécrits en nouveaux services. Une couche de compatibilité fait le lien.
- Option 2 (Radicale) : Branche dédiée (ex:
dolibarr-next) qui devient la référence, avec un outil de migration des données et une période de support long double (ancienne + nouvelle version).
- Communauté en pilote : Implication forte des contributeurs, tests extensifs sur des instances réelles. Documentation massive sur le nouveau paradigme.
🎯 Conclusion : Un virage nécessaire
En 2026, l’architecture de Dolibarr ne sera probablement plus un monolithe, mais un écosystème de services modulaires articulés autour d’une API robuste et d’un noyau minimal.
Cette évolution est cruciale pour :
- Assurer la pérennité face à des concurrents plus modernes.
- Séduire les grandes structures et les hébergeurs SaaS.
- Stimuler l’innovation communautaire avec des extensions plus faciles à maintenir.
Le plus grand défi ne sera pas technique, mais humain et organisationnel : guider la communauté, assurer une transition fluide pour des dizaines de milliers d’installations existantes, et maintenir l’ADN de Dolibarr : un ERP puissant, simple et libre.
La "fabrication" de Dolibarr 2026 est déjà en cours dans les discussions des contributeurs. C’est un projet ambitieux qui déterminera si Dolibarr reste la référence des ERP libres pour la prochaine décennie.