Les deux tournent sur un serveur que vous contrôlez. Les deux gèrent des clients, des devis, des factures, des stocks. Les deux sont massivement déployés en France. Et pourtant, entre Dolibarr et Odoo, le choix n'est pas un arbitrage de fonctionnalités : c'est un arbitrage sur ce qui vous arrivera dans trois ans.
Dolibarr est écrit en PHP, sous licence GPL version 3, sans zone réservée ni édition payante. Sa version 24.0.1 date du 7 septembre 2026. Odoo est écrit en Python, avec une édition Community sous LGPL version 3 et une édition Enterprise propriétaire qui ajoute plus de quarante modules, des applications mobiles, un éditeur visuel de personnalisation et des fonctions comptables avancées.
Cette différence de structure explique tout le reste.
Le coût qui n'apparaît pas la première année
Dolibarr est entièrement gratuit. Il n'existe pas de fonction retenue derrière un abonnement. Des modules complémentaires payants existent sur une place de marché, mais le coeur ne connaît pas de limite artificielle.
Odoo en édition Community est gratuit lui aussi, et suffisant pour une activité simple. La difficulté surgit quand un besoin précis tombe dans la partie Enterprise, ce qui arrive plus souvent qu'on ne l'anticipe : comptabilité analytique poussée, gestion documentaire, certaines automatisations, l'éditeur visuel. On se retrouve alors devant un choix inconfortable, faire développer l'équivalent, ou basculer sur un abonnement par utilisateur et par mois qui n'était pas au budget.
Il faut aussi savoir que le code Enterprise, y compris les modules qui y figurent sous LGPL, n'est pas utilisable sans abonnement valide. La frontière ne se contourne pas par une lecture habile de la licence.
L'erreur classique consiste à comparer les deux sur la première année, où ils coûtent la même chose : zéro. La comparaison honnête porte sur la cinquième année, en tenant compte du nombre d'utilisateurs, qui aura augmenté.
Ce que chacun fait le mieux
Dolibarr est pensé pour la petite structure française. La facturation, les devis, le suivi commercial, la conformité aux obligations locales fonctionnent d'emblée et sans configuration acrobatique. Son interface est datée, personne ne prétend le contraire, mais elle est dense et rapide pour qui la pratique quotidiennement. L'installation tient sur un serveur modeste avec PHP et MariaDB, ce qu'un hébergement mutualisé suffit parfois à porter.
Odoo vise plus haut. Son architecture modulaire permet de couvrir la production, la logistique, le point de vente, la maintenance, les ressources humaines, avec une cohérence entre modules que Dolibarr n'atteint pas sur ces terrains. L'interface est moderne et l'expérience utilisateur nettement supérieure. En contrepartie, l'installation demande Python, PostgreSQL, un serveur dimensionné, et la personnalisation exige un développeur qui connaît le cadre applicatif.
La taille est le premier discriminant, et il est assez net. En dessous de quinze utilisateurs, avec un métier de service ou de négoce classique, Dolibarr fait le travail sans rien coûter. Au-dessus de trente utilisateurs, avec de la production ou de la logistique, Odoo est le seul des deux à tenir la route.
Entre les deux, la réponse dépend du métier plus que du nombre de postes.
Trois profils, trois réponses
Une société de services de douze personnes qui facture à l'affaire, suit ses clients et ses fournisseurs, et veut tenir sa comptabilité : Dolibarr, sans hésitation. Le besoin est couvert d'origine, la maintenance est légère, et l'argent non dépensé en licences finance la reprise des données.
Une entreprise industrielle de quarante personnes avec des nomenclatures, des ordres de fabrication et des stocks multi-emplacements : Odoo. Dolibarr peut approcher le résultat avec des modules complémentaires, mais l'assemblage devient fragile et cher à maintenir. Autant partir sur l'outil conçu pour ça, en sachant que l'abonnement Enterprise arrivera probablement au deuxième exercice.
Un commerce de détail avec plusieurs points de vente : Odoo, pour son module de caisse et sa gestion multi-sites, mais en regardant d'abord les solutions spécialisées du secteur. Un ERP généraliste qui joue au logiciel de caisse est rarement le meilleur logiciel de caisse.
Le sujet que personne n'aborde assez tôt
La reprise des données est le poste qui coûte le plus cher et qu'on estime toujours à la baisse.
Sortir vingt ans de clients, d'articles, d'historique de factures et de balances comptables d'un logiciel existant, les nettoyer, les faire entrer dans le nouveau schéma sans casser les numérotations légales : c'est un projet en soi, qui se compte en semaines et non en jours. Les doublons de clients, les articles supprimés mais référencés dans d'anciennes factures, les taux de TVA historiques qui ne sont plus valides sont autant de cas particuliers à traiter un par un.
La règle qui évite la catastrophe : reprendre le minimum légalement nécessaire et laisser le reste en consultation dans l'ancien système. L'historique complet dans le nouvel outil est un confort ; il coûte souvent plus cher que les licences économisées.
Ce qu'un ERP auto-hébergé demande vraiment
Un ERP porte la facturation. Il est donc soumis aux obligations comptables et, à ce titre, sa sauvegarde n'est pas un sujet technique mais un sujet légal.
La base de données et les documents générés doivent être sauvegardés ensemble et de façon cohérente : une base restaurée sans ses PDF de factures est inutilisable, et l'inverse aussi. La restauration se teste, réellement, au moins une fois par an, sur une machine séparée, avec un contrôle de quelques factures ouvertes. Une sauvegarde jamais restaurée n'est pas une sauvegarde, et la règle des trois copies sur deux supports vaut ici plus qu'ailleurs.
La disponibilité mérite une conversation franche avec le dirigeant. Si l'entreprise ne peut pas facturer pendant deux jours, il faut une architecture qui l'évite et son coût, qu'il s'agisse d'un couple MariaDB répliqué pour Dolibarr ou d'une bascule PostgreSQL automatique pour Odoo ; si elle peut tenir une journée, une sauvegarde quotidienne bien testée suffit. Les deux réponses sont légitimes, l'absence de réponse ne l'est pas, et c'est tout l'objet d'un plan de reprise écrit.
Restent les montées de version, régulières dans les deux cas, qui se testent sur une copie avant d'être appliquées ; et l'exposition sur Internet, qui impose au minimum un accès authentifié et à jour, puisque l'outil contient l'intégralité du fichier client.
Ce qu'on choisirait
À taille égale et besoin couvert par les deux, Dolibarr, pour une raison qui n'est pas technique : il n'y a pas de deuxième conversation sur le budget. Ce que vous installez aujourd'hui est ce que vous aurez dans cinq ans, sans fonction qui se retire derrière un abonnement parce que l'éditeur a changé sa segmentation.
Odoo dès que le métier déborde du trio devis, facture, stock simple. Il est meilleur, il est plus beau, il tiendra la croissance, et il faut budgéter l'abonnement dès le départ plutôt que de le découvrir au moment où l'on en dépend déjà.
Dans les deux cas, le résultat se joue sur la reprise des données et sur la sauvegarde testée, bien plus que sur le choix du logiciel. C'est la partie que nous prenons en charge, du dimensionnement du serveur à la restauration vérifiée, sur les infrastructures que nous opérons en France.
Sources
- Dépôt GitHub Dolibarr, licence GPL v3, version 24.0.1 publiée le 7 septembre 2026, écrit en PHP
- Dépôt GitHub Odoo, 54 494 étoiles au 21 septembre 2026, édition Community et édition Enterprise
- Documentation Odoo, licences, LGPL v3 pour Community, licence propriétaire OEEL pour Enterprise
- Documentation Dolibarr, modules natifs, prérequis d'installation et place de marché


