Dans presque toute première conversation autour d'Odoo, la question finit par tomber : faut-il utiliser Community ou payer pour Enterprise ? On attend une réponse par oui ou par non, et les prestataires sont généralement ravis d'en donner une — ceux qui revendent des licences disent Enterprise, ceux qui facturent des heures disent Community. Les deux réponses sont suspectes pour la même raison : elles ont été décidées avant que quiconque n'examine votre entreprise.
La réponse honnête, c'est que la question de la licence n'est pas une seule décision. Ce sont trente petites décisions. Odoo est modulaire, et le choix l'est aussi : ventes, achats, inventaire, facturation, RH, fabrication — chaque domaine dispose d'une version Community, souvent d'une alternative OCA mature, parfois d'une fonctionnalité Enterprise qui compte vraiment, et occasionnellement de rien qui convienne sans développement sur mesure. Décider au niveau de « l'ERP » masque toute cette nuance, et c'est dans la nuance que se trouve l'argent.
Nous décidons donc module par module. Voici la méthode que nous utilisons réellement — y compris là où nous estimons qu'Enterprise mérite sa licence, et là où ce n'est pas le cas.
Community plus une sélection OCA soignée : le choix par défaut
Notre position de départ pour tout module est Community plus une sélection soignée issue de l'OCA — l'écosystème de modules ouverts et relus par les pairs de l'Odoo Community Association. Non pas parce que le gratuit est automatiquement meilleur, mais parce que pour la plupart des domaines opérationnels, le cœur Community couvre le flux de travail essentiel, et l'OCA comble les lacunes pratiques avec du code public, relu et maintenu par des personnes qui l'exploitent elles-mêmes en production.
Soignée est le mot qui porte tout. Nous n'installons pas de modules OCA à la légère, et personne ne devrait le faire. Chaque module tiers que nous adoptons passe par la même discipline que le code que nous écrivons : il vit dans notre arborescence Git à une version figée, il passe les tests de montée de version avant tout changement, et il atteint les environnements via le même pipeline de livraison versionné que notre propre travail. Un module OCA que personne dans votre équipe ne sait maintenir n'est pas une économie — c'est un passif non chiffré qui arrive à échéance à la prochaine montée de version.
Là où Enterprise mérite véritablement sa licence
Nous ne sommes pas idéologues sur ce sujet, car l'idéologie coûte de l'argent aux clients dans les deux sens. Il y a des cas où Enterprise est tout simplement la meilleure décision d'ingénierie.
La comptabilité est le cas le plus clair. Le reporting financier dynamique d'Enterprise — états légaux, rapports avec navigation en profondeur, outils de lettrage qui les accompagnent — représente des années de travail accumulé qu'il serait réellement coûteux de reconstruire et encore plus coûteux de maintenir correct à mesure que les réglementations et les versions évoluent. Si le reporting comptable est central dans le fonctionnement d'un client, nous le disons franchement : c'est là que la licence se justifie d'elle-même.
Certaines applications métier entrent dans la même catégorie. Quand Enterprise fournit une application approfondie, conçue spécifiquement pour le flux de travail réel du secteur d'un client, et que la voie Community plus OCA reviendrait à assembler et maintenir un patchwork, l'abonnement est généralement l'option la moins chère quand on compte honnêtement. Le chemin de migration officiel qui accompagne l'abonnement fait aussi partie de ce calcul honnête.
Pour chaque module du périmètre, nous déroulons la même courte liste de questions :
- La version Community couvre-t-elle le flux de travail que cette équipe exécute réellement au quotidien ?
- Existe-t-il un module OCA mature et activement maintenu pour ce qui manque ?
- La fonctionnalité Enterprise est-elle structurante pour cette entreprise, ou simplement agréable en démonstration ?
- Combien coûterait le développement sur mesure pour combler l'écart — et, plus important encore, le portage de ce code à travers chaque future montée de version ?
- Qui maintiendra ce choix dans trois versions ?
Coût de la licence contre coût du développement sur mesure
C'est sur cette dernière paire de questions que la plupart des débats sur la licence devraient réellement se jouer. Un abonnement Enterprise est une ligne budgétaire récurrente et prévisible. Le développement sur mesure paraît moins cher parce que la facture n'arrive qu'une fois — mais le vrai coût du code sur mesure n'est pas de l'écrire, c'est de le porter. Chaque module sur mesure que nous livrons est versionné dans Git et passe des tests de montée de version avant toute livraison, et cette discipline existe précisément parce que porter le code est la partie coûteuse. Quand une fonctionnalité Enterprise correspond étroitement à ce que vous construiriez autrement, la licence gagne généralement la comparaison honnête.
Le cas inverse est tout aussi réel. Payer Enterprise pour toute l'entreprise parce qu'un seul service veut une seule fonctionnalité est un mauvais calcul quand un petit module sur mesure — ou un module OCA existant — comble l'écart pour une fraction du coût récurrent. Nous voyons les deux erreurs, et elles ont la même racine : répondre à une question de niveau module au niveau du contrat.
C'est pourquoi, selon notre expérience, la bonne réponse est très souvent un mélange — Community comme socle, OCA là où l'écosystème est solide, Enterprise là où elle prouve manifestement sa valeur, et des modules sur mesure ciblés pour ce qui est véritablement spécifique à l'entreprise. Ce mélange est exactement ce que produit notre phase de cadrage : une cartographie module par module avec le raisonnement consigné, et un prix fixe attaché avant tout démarrage de développement. Si vous pesez les deux éditions en ce moment, cette conversation de cadrage est le lieu pour trancher — avec vos modules sur la table, pas la plaquette commerciale de quelqu'un d'autre.