Gérer une entreprise, c’est jongler entre clients, factures, stocks, RH, e-commerce, projets… L’idée des ERP open source : offrir un outil que l’on peut voir, adapter et faire évoluer sans boîte noire ni verrou propriétaire. Dans ce paysage :
- Odoo — suite ERP complète et intégrée : large couverture (CRM, ventes, achats, compta, MRP, site web/e-commerce, marketing), ergonomie soignée, rythme d’innovation soutenu, écosystème riche (modules, intégrateurs) et modèle open-core — c’est-à-dire un cœur libre (Community sous LGPLv3) + des modules propriétaires (Enterprise sous Odoo Enterprise Edition License v1.0 / Odoo Proprietary License v1.0).
- Dolibarr — simplicité modulaire, légèreté et accessibilité (souvent choisi par PME, associations, indépendants).
- Apache OFBiz — ERP Java très flexible et sa lignée : SCIPIO ERP, opentaps, etc.
- Axelor — suite ERP + BPM en Java/low-code, pensée pour modéliser vite les processus.
- Lignée Compiere (Compiere a rejoint Aptean ; la branche commerciale n’est plus open source depuis 2010, après le rachat par Consona) : ADempiere, iDempiere, metasfresh, Libertya, OpenZ, etc.
- Lignée Odoo : Tryton (issu du projet Odoo, fork historique de TinyERP).
- Autres familles : ERP5, webERP/FrontAccounting, OpenConcerto, …
Dans cette écosystème, Odoo occupe un rôle central : il permet de démarrer vite sur des besoins standard sans fermer la porte aux adaptations primordiales ; il s’appuie sur un réseau d’intégrateurs présent dans beaucoup de métiers ; il propose une offre cloud ou sur site (On Premise) adaptée aux exigences de sécurité et de gouvernance ; et il bénéficie d’une communauté structurée (entre autres, l'OCA) qui diffuse les bonnes pratiques. Résultat : un coût de changement maîtrisé et une évolution prévisible du premier pilote aux déploiements à grande échelle. Odoo revendique par ailleurs 13 millions+ d’utilisateurs dans le monde, signe d’une adoption large et continue.
1- Des origines à la marque : TinyERP → OpenERP → Odoo
- 2005 : naissance de TinyERP en Belgique, avec une idée simple : un ERP modulaire et libre que l’on étend selon ses besoins.
- 2008–2014 : montée en puissance, changement de nom en OpenERP en 2008, puis Odoo en 2014 pour refléter l’ambition d’une suite au-delà de l’ERP classique.
Clin d’œil – La courte coopération avec Axelor (le tout premier client web)
Dès 2007, Tiny (éditeur de TinyERP) s’allie à Axelor pour proposer TinyERP en mode Web : un client web avec sa propre interface et des fonctions graphiques (projets, stocks). En 2009, à la sortie d’OpenERP 5.0, ce client devient OOweb 5.0 (Open Object Web), co-développé par Axelor et Tiny. Cette première interface web comprenait le logo Axelor ; Axelor prendra ensuite sa propre voie d’éditeur avec une application 100 % Java.
2- Le virage des licences : du copyleft fort au modèle hybride
2.1 Le parcours (en bref)
- Débuts : licences GPL (copyleft fort).
- Serveur en AGPLv3 : le copyleft s’étend à l’usage via le réseau.
-
Depuis Odoo 9 (2015) :
- Community : LGPLv3 (plus permissive que l’AGPL)
- Enterprise : licence propriétaire Odoo Enterprise Edition License v1.0 (parfois « Odoo Proprietary License »).
- Cette répartition reste en vigueur jusqu’aux versions actuelles (principe inchangé depuis Odoo 9).
2.2 Périmètre de la licence entreprise - pour éviter les malentendus
- La clause « interdiction de publier, distribuer, sous-licencier ou vendre des copies (y compris modifiées) du logiciel sans abonnement valide » s’applique au périmètre Enterprise, pas au code de la Community ni, en soi, aux modules libres tiers.
- On peut développer des modules qui s’appuient sur Enterprise et les distribuer sous une licence au choix, tant qu’elle reste compatible avec les termes de la licence Enterprise.
Résumé rapide : Community = LGPLv3 (libre) ; Enterprise = licence propriétaire (usage conditionné à abonnement, avec ouverture pour développer des modules compatibles).
3- La communauté, l’OCA et la vraie vie des compromis
3.1 L’OCA (Odoo Community Association)
Association indépendante (créée en 2013) : elle oriente, structure et professionnalise l’écosystème communautaire (dépôts de modules, conventions de code, revues, PSC). Au moment du relicensing (passage massif à la LGPL pour le core), un accord public OCA ↔ Odoo SA a clarifié les règles, notamment sur la compatibilité de licences et les dépendances entre modules.
3.2 Les divergences (et pourquoi elles persistent)
- Le passage à un open-core a nourri l’idée (récurrente) d’un fork “100 % libre” du cœur. Mais maintenir un ERP complet (migrations, sécu, QA, écosystème) est colossal ; aucun fork « core » n’a pris l’ascendant.
- Côté licences, les débats AGPL/LGPL restent vifs : LGPL est vue par certains comme plus pragmatique, par d’autres comme un affaiblissement du commun si l’on n’a pas, en face, un modèle de financement collectif. Les fils de discussion OCA en témoignent, encore en 2025.
4- Forks et voies complémentaires
4.1 Tryton (le fork historique)
Tryton est né en 2008 comme fork de TinyERP 4.2. Projet 100 % GPLv3, architecture 3-tiers Python/PostgreSQL, gouvernance fondation. Moins “produit packagé” qu’Odoo, Tryton avance avec une cohérence technique stricte, un tempo plus posé et sert de plateforme (ex. GNU Health).
Odoo vs Tryton, deux philosophies :
- Tryton privilégie le tout-libre et la stabilité du core.
- Odoo assume l’open-core : cadence rapide, diffusion large, investissement massif — au prix de tensions communautaires récurrentes.
Aujourd'hui, le projet Tryton est plutôt confidentiel
4.2 - Bâtir « autour » plutôt que « contre » : l’exemple Konvergo ERP
Konvergo ERP illustre une stratégie intéressante : ne pas forker Odoo, mais l’étendre via des modules métiers et des services (IA, automatisation).
- Le module web_konvergo_magic (public) sert de baseline d’intégration avec l’écosystème Konvergo (MAGIC / Allo).
- Cette voie mise sur la valeur métier + pragmatisme de migration quand Odoo évolue (plutôt que la refonte d’un cœur).
6- Deux visions qui s’opposent… et se nourrissent
6.1 Vision 100 % Open Source (copyleft fort)
- Tout (cœur + modules) reste libre (GPL/AGPL).
- Monétisation par les services (intégration, support, hébergement).
- Les plus : transparence maximale, pérennité indépendante.
- Les moins : financement de la R&D moins prévisible, adoption « clé en main » plus lente.
6.2 Vision double licence / open-core
- Cœur libre (LGPL) + couche Enterprise propriétaire.
- Monétisation par souscriptions, cloud, services.
- Le plus : capacité d’investissement (produit, UX, infra, go-to-market), diffusion accélérée.
- Les moins : tension avec la communauté, risque de marginaliser la Community si la gouvernance n’est pas claire.
6.3 Ce qui les rassemble / ce qui les sépare
- Rassemble : valeur d’un socle ouvert, importance de la modularité, besoin de règles de compatibilité et d’une communauté active.
- Sépare : degré d’ouverture acceptable, pouvoir de l’éditeur sur la feuille de route et répartition de la valeur (qui paie quoi, pour qui).
7- Conseils pratico-pratiques (terre-à-terre avec pragmatisme)
- Choisir la trajectoire (pas la “taille”) :
- Community = autonomie/souveraineté (plus de compétences techniques à mobiliser, attention à ne pas laisser grignoter le fonctionnel).
- Enterprise = accélération (SLA, time-to-value).
- Licences & dépendances : vérifiez tôt AGPL/LGPL/propriétaire pour éviter verrouillages et coûts cachés. Cadrez les choix selon vos objectifs business.
- Partenaire & équipe : les références sectorielles sont un plus, pas un couperet ; jugez surtout les personnes proposées et sécurisez leur affectation. Exigez un pilote court payant avec livrables concrets.
- Exigence de résultat sans piège : ne l’acceptez qu’après un cadrage lié à un POC précis (SOW, critères d’acceptation, hypothèses). Sinon, tout écart devient avenant.
- S’appuyer sur l’écosystème (OCA) : privilégiez des modules mûrs et, si possible, contribuez ; c’est du TCO et du risque de migration en moins.
- Migrations & réversibilité : plan de version, jeu de tests, portes de rollback. Assurez l’export des données et un plan B si une brique devient bloquante.
- Gouvernance par la valeur : mesurez des KPI métier (cash, délais, qualité de données).
- Ajustez en conséquence.
Conclusion : communauté, modèle… et cap (retour d’expérience)
J’ai eu l’occasion de travailler sur des projets Dolibarr (de 2007 à 2014) et Apache OFBiz (2006-2007) : la sobriété efficace de l’un, la lourdeur de l’autre m’ont appris beaucoup. À la base, j'avais pourtant une appétence pour OFBiz venant du monde java. Depuis 2009, j'intègre de l'Odoo : projets variés, migrations, verticaux métiers.
Deux vérités peuvent cohabiter sans se contredire :
- Odoo n’aurait jamais décollé sans sa communauté. L’OCA, les contributeurs, les intégrateurs et les retours terrain ont fait tenir l’écosystème dans la vraie vie.
- Odoo ne serait pas là où il en est sans la double licence. Le duo Community (LGPLv3) + Enterprise (Odoo Enterprise Edition License v1.0) a financé la R&D, la cadence produit et l’industrialisation — et, par ricochet, a tiré la communauté open source en élargissant l’adoption.
Odoo n’est ni l’idéal platonique du « tout-libre », ni une citadelle propriétaire. C’est une ligne de crête : garder un cœur ouvert, faire prospérer une communauté et financer l’ambition avec une couche Enterprise — sans laisser la Community devenir une coquille vide. Tant que ces garde-fous tiennent, le pari reste gagnant : un ERP puissant, modulaire, durable… et au fond, très fidèle à l’esprit qui a lancé TinyERP.