Dans les projets Odoo (*) que je mène pour mes clients, j'essaie généralement pour des raisons budgétaires, de ne pas réaliser de développement spécifique soit en étendant les fonctionnalités Odoo Community de base par des modules tiers (ex: OCA), soit en orientant le besoin client.

Néanmoins, il m'arrive parfois d'être obligé de développer un module pour traiter un besoin client spécifique.

A chaque fois, cela est un vrai plaisir grâce à la conception de Odoo reposant sur une modélisation objet (héritage, encapsulation), une modularité, une architecture MVC, un ORM efficace et un langage typé dynamique fort (python) qui permet souvent en quelques lignes Python et Xml de traiter le besoin.

Les points forts de Odoo (anciennement OpenERP) sont très bien décrits dans une étude Smile de 2008 (**).

(*) Je traite des projets Odoo pour des PME généralement de moins de 20 employés. En général, la mise en oeuvre initiale d'Odoo requiert une charge de 4-5 jours.

(**) extrait de l'étude SMILE  sur les ERP open-source :

Ce qui change fondamentalement dans la conception d'OpenERP et ERP5, c'est qu'ils disposent d'une modélisation qui suit fidèlement les préceptes de la programmation dite «objet».

En conséquence, le fonctionnel métier peut y être surchargé au gré des besoins de verticalisation pour atteindre exactement les fonctionnalités souhaités sans pour autant engendrer de code cher à maintenir ou à intégrer, les fameuses usines à gaz.

Plus précisément, la capacité d'héritage de la modélisation dite objet permet de définir les concepts et comportements métiers par surcharge de modèles pré-existants, c'est à dire en ne spécifiant que les écarts à ces étalons au lieu de devoir redéfinir chaque modèle en partant de zéro ou encore, à l'instar de produits type SAP R/3, d'embarquer systématiquement d'office tous les paramétrages imaginables ce qui mène à des intégrations trop coûteuses pour les PME et TPE.

Par exemple, un produit pour l'agro-alimentaire dont on devra considérer la date de péremption, dans le calcul du prix de vente par exemple, ne sera qu'une spécialisation opportuniste du modèle générique de produit.

A charge à l'entreprise de l'agro-alimentaire d'installer ce plugin alors que, par exemple, l'entreprise de service, elle, ne se verra pas ses coûts d'intégration s'envoler avec des paramétrages inutiles à son secteur d'activité.

Pourtant ces deux entreprises utiliseront la même plateforme d'ERP et participeront toutes deux à construire sa robustesse et sa compétitivité: l'unité de code réutilisable dans l'écosystème open source, est fine et permet à plus de gens de fédérer leur développements spécifiques en des plugins cohérents et réutilisables directement.

D'autre part, la modélisation dite objet va apporter à ces ERP des propriétés dite d'encapsulation: c'est à dire qu'on délègue explicitement certaines responsabilités à certains concepts (ou objets). Ce qui permet: d'apporter de la lisibilité au code et de le stabiliser en évitant les effets de bords.

Par exemple, le calcul du prix d'un produit est localisé à un endroit précis unique et dont le langage lui même contrôle l'accès afin que tous les développeurs, y compris les tiers intégrateurs, puissent facilement comprendre toute fonctionnalité mettant en jeux le prix de vente d'un produit et garder la maîtrise lors des nécessaires personnalisations.

Les lecteurs renseignés remarqueront que l'on parle ici d'ERP écrits en langage Python alors que ceux de la première classe le sont en langage Java. Pourtant ces deux langages sont bien des langages permettant la modélisation objet.

Mais il se trouve que les seuls ERP fonctionnellement matures en langage Java n'utilisent pas encore la modélisation dite objet, ou alors assez imparfaitement comme sur Neogia tout au plus.

L'explication est que Java est un langage appartenant à la famille des langages de typage dit fort et statique: c'est à dire qu'on doit déclarer, avant même la phase de compilation et le déploiement, les classes de comportements attendus des entités de modélisation. Or, techniquement parlant, ceci cadre très mal avec la possibilité de personnalisation à chaud de ces modèles de comportement.

Et pourtant c'est bien ce qui est recherché dans l'ERP: un paramétrage assez poussé sans avoir à rien recompiler ni à redéployer: idéalement, le plus de paramétrage possible sera assumé par des consultants métiers sans avoir à recourir à des développements coûteux. C'est précisément ce qui était visé par l'application dictionnary de Compiere également repris par Openbravo: permettre l'altération à chaud des modèles de données et de leurs écrans.

Or, étant basé sur un langage de typage statique fort, la famille des Compiere a dû renoncé à la modélisation objet pour permettre une certaine dose de paramétrage à chaud (celle des structures de données).

Au contraire, les ERP basé sur Python,un langage typé fort dynamiquement n'ont pas eu à renoncer à la modélisation objet pour permettre un maximum de capacités de personnalisations à chaud par des non développeurs.