Expérience de déploiements Odoo dans des entreprises françaises

Auteur : Alexis de Lattre <alexis _chez_ miluni.fr>

Licence Creative Commons
Ce document est mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0.

La version la plus à jour de ce document se trouve à l'adresse https://alexis.miluni.fr/odoo/

N'hésitez pas à m'envoyer un mail pour me faire part de votre propre expérience sur Odoo et/ou me signaler une erreur ou une faute d'orthographe dans le document.

Introduction

Ce document a pour objectif de faire profiter les personnes envisageant un déploiement d'Odoo dans leur entreprise de l'expérience que j'ai acquise. Son objectif principal est de partager mon avis personnel et ma vision d'Odoo construits à partir de ma propre expérience sur le terrain et de mes contributions au sein de la communauté Odoo. Le lecteur pourra trouver ce témoignage parfois assez éloigné du discours marketo-idéaliste dominant sur Odoo !

Une des limitations de ce retour d'expérience est que vous n'y trouverez pas un comparatif entre Odoo et d'autres ERPs du marché ; en effet, comme je n'ai jamais déployé d'autres ERPs qu'Odoo, je ne suis pas en mesure de faire des comparaisons précises. Mais un de mes collègues, qui a été formé sur d'autres ERPs, en particulier CEGID et Microsoft Dynamics Nav, a publié une serie de petits articles où il compare ces deux ERPs propriétaires avec Odoo.

Historique

Date Changement
2012-10-18 Version initiale
2012-10-19 Premiers ajouts et correctifs suite au feedback de la communauté. Mention du moteur de rapport basé sur BIRT, signalé par Christophe Chauvet.
2012-12-22 Mise à jour du projet de moteur de rapport basé sur Pentaho et ajout du projet de moteur de rapport basé sur opengraphane.
2013-01-14 Mise à jour suite à la sortie d'Odoo 7.0.
2013-01-22 Ajout d'un lien vers le site openerp2tryton.
2013-03-30 Mise à jour de la liste des modules utilisés à Anevia (ajout des modules pour les export CSV des balances). Mise à jour de la partie La maturité d'Odoo avec l'arrivée des branches OCB (Odoo Community Branches). Mention du fiasco de la gestion des contacts dans Odoo 7.0 dans le SWOT.
2013-12-30 Mise à jour importante en cours : OCA, nouvelles pratiques de la communauté, relecture et mise à jour de chaque chapitre, etc.
2014-01-20 Mise à jour de la partie La maturité d'Odoo avec un lien vers le suivi des bugs d'un autre de mes clients. Mise à jour de la partie Comment utiliser la comptabilité d'Odoo ? à propos de la liasse fiscale, avec un lien vers le blog très détaillé d'Aurélien Dumaine.
2014-04-20 Petite mise à jour, notamment sur Odoo 8.0 et les moteurs de rapport.
2014-06-05 Mise à jour sur l'actualité récente d'Odoo.
2015-08-11 Grosse mise à jour avec toute l'actualité 2014/2015 et un retour d'expérience actualisé avec la v8.
2015-09-15 Mise à jour de la partie Exemple d'un cas réel avec l'exemple de l'Abbaye du Barroux qui utilise Odoo v8 depuis le 1er Janvier 2015.
2015-09-27 Mise à jour de la partie Comment utiliser la comptabilité d'Odoo avec la recommandation du module OCA account_asset_management pour la gestion des immobilisations. Mise à jour du schéma d'architecture et ajout d'un schémas sur l'architecture que je recommande.
2016-03-14 Mise à jour du SWOT avec un mot sur la traduction en français
2024-12-25 Remise en ligne sur une nouvelle URL alexis.miluni.fr/odoo

A propos de l'auteur

L'auteur et le logiciel libre

Je suis passionné par le logiciel libre. J'ai fait mes classes à VideoLAN quand j'étais étudiant, où je me suis principalement occupé de la documentation, du site Web, de l'organisation d'événements et de la mise en production de VideoLAN sur le campus de mon école. Comme je n'avais pas de compétences en développement à l'époque, je n'ai pas codé grand chose (à l'exception du support IGMPv3 et MLDv2 dans VLC). VideoLAN m'a permis de "vivre" un logiciel libre de l'intérieur et m'a énormément appris sur la philosophie du logiciel libre, la motivation des développeurs et le fonctionnement des communautés.

Dans la même série, j'ai écrit un document retour d'expérience d'un déploiement Asterisk dans une entreprise française.

Je suis membre actif de l'Odoo Community Association (OCA).

L'expérience Odoo de l'auteur

Je suis le co-fondateur de la société Anevia, qui est un équipementier télécom français spécialisé dans les serveurs de vidéo sur IP. J'ai fondé cette société en 2003 avec 3 camarades d'école, anciens membres du projet VideoLAN comme moi. A Anevia, j'avais la responsabilité de l'administratif (comptabilité, paye, déclarations sociales), de la production/logistique et de l'informatique interne (même si, dans les premières années de la société, comme ces 3 domaines ne m'occupaient pas à temps plein, j'ai surtout œuvré en tant qu'ingénieur commercial et ingénieur support).

Aux débuts d'Anevia, pour parer au plus pressé, j'ai adopté des outils de gestion simples et basiques, à savoir :

Il faut noter qu'Anevia a toujours tenu sa comptabilité en interne.

Ces outils simples et peu onéreux étaient bien adaptés au début de la société. Mais, avec la croissance de la société, quand j'ai commencé à avoir plusieurs employés dans mon équipe, ces outils ont vite révélé leurs limites :

Face à cette situation, il devenait urgent de changer nos outils de travail... l'ERP s'imposait.

Comme j'étais un fan de logiciel libre, je me suis d'abord intéressé aux ERPs libres. J'ai lu des articles sur Internet, j'ai discuté sur des salons, etc. A l'époque, en 2007, les ERPs OpenSource qui faisaient parler d'eux étaient :

Compière était le plus visible des trois au niveau médiatique ; il avait une communauté d'intégrateurs significative avec plusieurs intégrateurs français expérimentés qui affichaient déjà des références solides. C'était donc un bon candidat. Le gros point noir était le fait que Compière ne marchait qu'avec une base de données Oracle, ce qui était très surprenant pour un logiciel OpenSource, alors qu'il existe un large choix de bases de données OpenSource, dont un certain nombre ont une très bonne réputation en terme de fiabilité et de performances et ont des références prestigieuses. Avec Compière, on avait le sentiment que "l'OpenSource c'est bien, mais le logiciel propriétaire c'est mieux" !

A l'époque, Odoo s'appelait encore TinyERP. Son discours n'était pas encore très rodé, il n'y avait pas d'intégrateur français d'envergure et seule l'interface Gtk était disponible, ce qui n'était pas super sexy pour les démos. J'avais lu que TinyERP était écrit en Python, ce que j'avais du mal à comprendre car je pensais que Python était un langage de script (Python est souvent utilisé pour écrire des scripts, mais je ne savais pas à l'époque qu'il pouvait également convenir pour des applications complètes). Dans tous les cas, je ne me voyais pas aller convaincre mes associés qu'il fallait choisir TinyERP, un logiciel sous-entendu destiné à des Tiny-entreprises, alors qu'on avait l'ambition de construire une PME la plus grosse possible !

Ma préférence allait plutôt vers OpenBravo, qui avait un discours très rodé, une approche "full-Web" séduisante qui permettait à l'éditeur de faire de belles démos. OpenBravo était un ancien fork de Compière, mais l'éditeur avait abandonné le client Java pour une interface "full-Web" et était en train d'ajouter le support officiel de PostgreSQL en plus du support d'Oracle. OpenBravo affichait des ambitions importantes et l'éditeur était proche car basé en Espagne. OpenBravo n'avait pas encore d'intégrateur français mais la société apparaissait très dynamique. J'ai alors décidé de m'inscrire à la formation fonctionnelle d'une semaine organisée par l'éditeur d'OpenBravo à Barcelone en Mars 2008.

Après une semaine de formation à Barcelone, je suis arrivé à la conclusion qu'OpenBravo n'était probablement pas un bon choix pour Anevia. Attention, mon avis sur OpenBravo date de Mars 2008 et n'est donc certainement plus d'actualité. Je vous le partage quand même pour que vous puissiez comprendre mon choix :

Après cette expérience décevante avec OpenBravo, je m'étais dit : si l'ERP OpenSource que je considérais comme étant le plus à même de satisfaire les besoins d'Anevia ne fait pas l'affaire, alors il va falloir commencer à étudier les ERPs propriétaires.

J'ai alors commencé à prendre contact avec quelques ERPs propriétaires pour PME, comme Sage, Cegid ou Divalto. Lors de cette étude très succincte, je me suis notamment rendu compte combien il était difficile (impossible ?) de trouver un ERP propriétaire utilisable depuis un poste de travail Linux. En sachant qu'à Anevia les 2/3 des postes de travail étaient sous Linux - à commencer par le mien - c'était évidemment un critère de choix. Tous proposaient un client lourd Windows. Divalto proposait en plus une interface Web, mais uniquement pour la CRM. Cegid proposait une interface Web, mais uniquement compatible Internet Explorer... et, quand j'ai essayé d'accéder au site de démo qui en fait la présentation, la première chose qu'il m'a proposé est de télécharger un plugin... sous forme d'un fichier .exe ! Quand je les interrogeais sur la problématique de l'accès à l'ERP depuis un poste de travail sous Linux, leur réponse était toujours la même : pas de problème, il suffit d'installer un serveur Citrix ! Bienvenue au royaume de la légèreté ! Sans parler du coût...

Mon étude rapide des ERPs propriétaires m'a aussi fait découvrir une chose importante. Dans le cas de Divalto par exemple, un intégrateur spécialisé sur Divalto avait développé un module pour gérer les contrats de maintenance. Ce module était la propriété de l'intégrateur et non la propriété de l'éditeur ; il était donc développé, maintenu et commercialisé par l'intégrateur. Cela avait deux conséquences :

J'ai compris par la suite que cette pratique était courante dans le monde des ERPs propriétaires, où les intégrateurs développent des verticalisations métier (propriétaires également) pour s'arroger un quasi-monopole du déploiement de l'ERP en question dans ce secteur d'activité et s'assurer une fidélité forcée de leurs clients.

Mi-2008, j'ai alors rencontré Raphaël Valyi, qui travaillait à l'époque chez Smile, et qui venait de finir de rédiger le livre blanc de Smile sur les ERPs OpenSource. Dans le cadre de sa mission de veille technologique chez Smile, il avait passé plusieurs mois à évaluer les nombreux ERPs OpenSource disponibles et avait pris le temps de les installer, de regarder le code source, d'évaluer le périmètre fonctionnel, etc. Sa conclusion était claire : OpenERP (qui venait tout juste de changer de nom et avait abandonné l'ancien nom TinyERP) était le meilleur ERP OpenSource. J'ai compris que le Python n'était pas un simple langage de script, mais un vrai langage de développement orienté objet. L'éditeur venait de sortir un livre pour apprendre à se servir d'Odoo. C'était le premier livre sur un ERP OpenSource ! Même si ça peut paraître anecdotique, j'ai toujours considéré que ce point était important, car ça permet d'abaisser considérablement la barrière à l'entrée pour quelqu'un qui souhaite découvrir le logiciel : plutôt que de se payer une semaine de formation chez l'éditeur à 2 500 €, on pouvait désormais commander le bouquin sur Amazon à 40 € ! En abaissant ainsi la barrière à l'entrée sur le logiciel, l'éditeur se préparait à élargir considérablement la diffusion du logiciel, et s'assurait ainsi d'avoir la communauté la plus importante, ce qui est un élément très important pour le succès d'un logiciel libre.

Raphaël Valyi m'a expliqué les qualités d'Odoo. Il a pu me montrer via une démonstration que les fonctionnalités dont l'absence m'avait choqué dans OpenBravo étaient bien présentes dans Odoo : Odoo disposait nativement d'une balance analytique croisée avec le plan comptable général, il disposait nativement d'un réglage de la langue sur la fiche client permettant d'éditer les documents (devis, bon de livraison, facture) dans la langue du client, il disposait nativement d'une CRM, etc. Raphaël avait de très solides connaissances techniques et n'était pas un commercial qui raconte des bobards pour vendre sa camelote. Quand il m'a dit que, au vu des besoins d'Anevia, il était possible de déployer avec succès Odoo, je lui ai fait confiance.

J'ai pu convaincre mes associés de faire le choix d'Odoo pour Anevia et la décision a été officiellement prise le 10 Octobre 2008. Le travail a commencé aux alentours du 20 Octobre 2008. Parmi les modules métier à développer, il y avait notamment un module de gestion des contrats de maintenance. Vu le timing très serré du passage en prod, nous nous étions laissé la possibilité de développer ce module après le passage en prod. Mais comme Raphaël était un développeur expérimenté et que le framework d'Odoo permettait de développer assez efficacement, le module de gestion de contrats de maintenance a pu être développé avant le passage en production. Le passage en production a eu lieu le 1er Janvier 2009 avec OpenERP 5.0, qui était encore en version beta (OpenERP v5.0 a été releasé le 8 Févier 2009) sur le périmètre suivant :

Le projet avait pris son envol... J'ai formé mes équipes sur le tas et adapté l'organisation interne de la société en conséquence. Comme j'étais personnellement responsable de la comptabilité, de l'administration des ventes et de la production/logistique à Anevia, les choses étaient facilitées car j'étais personnellement le manager de toutes les personnes impactées par le démarrage de l'ERP ; je connaissais parfaitement leur façon de travailler et c'était moi qui avais mis au point leurs méthodes et leurs processes (et c'était également moi qui faisais leur boulot quand ils étaient absents !).

Le démarrage d'Odoo à Anevia avait fait l'objet d'un article sur le site erp-infos.com.

Après ce démarrage réussi, nous n'avons cessé d'élargir le périmètre fonctionnel d'Odoo à Anevia en ajoutant :

J'ai quitté mes fonctions opérationnelles à Anevia début 2010. Raphaël Valyi avait lui-même quitté Smile mi-2009 et créé sa société Akretion au Brésil, avec comme objectif de devenir intégrateur Odoo et de lancer Odoo sur le marché brésilien. Raphaël m'a rapidement proposé de créer le frère jumeau de sa société en France. Avec Sébastien Beau, qui était de retour en France après son stage de fin d'étude chez Akretion au Brésil, je me suis formé au développement en Python dans le framework d'Odoo et nous avons commencé à développer l'activité d'Akretion en France.

Je suis donc, depuis fin 2010, devenu moi-même intégrateur d'Odoo. L'équipe d'Akretion France a grossi au fil des années et est maintenant composée d'une dizaine de consultants, à la fois développeurs et experts fonctionnels, basée à Lyon (sauf une personne basée en région parisienne). En 2016, Akretion est devenue une coopérative et a ainsi rejoint le mouvement de l'économie sociale et solidaire.

Cette section sur mon histoire personnelle sur Odoo est un peu longue et très égocentrique, mais je pensais que c'était important de la présenter car, étant donné que je présente mon avis personnel sur Odoo dans ce document, il faut que les lecteurs aient les informations nécessaires pour mettre en perspective mon opinion.

Les contributions sur Odoo de l'auteur

Ma contribution à Odoo prend principalement la forme du développement de modules communautaires. J'ai notamment développé :

Je prends également du temps pour faire des améliorations sur les modules officiels d'Odoo, maintenus par l'éditeur. Voici mes principales contributions sous la forme de merge proposals :

Enfin, j'essaye de participer le plus possible aux bugs reports, en proposant des patchs pour les corriger quand ils sont de mon niveau !

A propos d'Odoo

Petit historique d'Odoo

Fabien Pinckaers a démarré TinyERP (l'ancien nom d'Odoo) en 2001-2002, alors qu'il était encore étudiant à l'université de Louvain-la-neuve. Il crée la société Tiny sprl pour commercialiser ses services autour de TinyERP, sa principale source de revenus étant constituée par les services d'intégration de TinyERP.

La première release publique de TinyERP a lieu en 2004 et les versions se sont ensuite succédées à un rythme soutenu :

En 2005-2006 arrivent les premiers intégrateurs, notamment Camptocamp, qui commencent le travail de localisation de TinyERP, qui consiste à adapter l'ERP aux spécificités légales, comptables et fiscales de chaque pays.

Sous la pression de ses intégrateurs, TinyERP adopte la plateforme Launchpad en 2008 pour faciliter le développement communautaire d'Odoo. En Juin 2008, TinyERP change de nom pour devenir Odoo et sort son premier livre chez Eyrolles. L'année 2008 est également marquée par le démarrage de Tryton, un fork d'Odoo, initié par deux anciens employés de Tiny sprl, et qui est toujours actif aujourd'hui et continue son développement indépendamment d'Odoo. La motivation affichée de ce fork était de mettre la priorité sur le nettoyage du code fonctionnel plutôt que de se disperser en fonctionnalités bling-bling type "on a codé un Webmail avec Odoo" (véridique, cf l'annonce de la version 5.0) ou on peut chatter dans Odoo (cf cette news de Février 2013 qui annonce l'ajout d'une messagerie instantannée dans le futur Odoo 8.0). L'autre priorité affichée était de travailler à l'amélioration du framework en corrigeant ses principaux défauts au prix d'un changement de l'API qui nécessita une adaptation en profondeur du code des modules fonctionnels. Ce fork aurait aussi une cause humaine, liée à des mésententes entre le patron de TinyERP et les deux développeurs en question.

En Février 2009, la release d'Odoo version 5.0 marque un saut qualitatif significatif avec une amélioration de l'interface Web, l'introduction des diagrammes de Gantt et de l'éditeur de workflow et de nombreuses améliorations dans le code fonctionnel.

Début 2010, la société Tiny sprl, qui deviendra ensuite Odoo S.A., annonce une levée de fonds de 3 millions d'euros auprès de Sofinnova (une société française de capital risque), de Xavier Niel (le fondateur de Free) et d'Olivier Rosenfeld (membre du conseil d'administration d'Iliad). Jusqu'à cette date, la société avait financé sa croissance sur ses fonds propres sans actionnaire extérieur. Malgré cette levée de fonds, Fabien Pinckaers reste l'actionnaire majoritaire d'Odoo S.A., les investisseurs extérieurs ayant une participation minoritaire. Antony Lesuisse, qui avait aidé Fabien sur certains aspects techniques au démarrage de TinyERP et avait poursuivi sa carrière dans d'autres entreprises, rejoint Odoo S.A. en tant que directeur de la R&D. Sous son impulsion, le développement d'Odoo se professionnalise et marque la fin de la fâcheuse tendance qu'avait Odoo à développer en propre certains composants logiciels plutôt que d'adopter des composants logiciels existants sous licence libre.

En Janvier 2011, la release d'Odoo version 6.0 marque de nouveau un saut qualitatif important, avec une amélioration du code fonctionnel, la réécriture complète de la CRM et une amélioration de l'interface Web. Cette version est la première à être diffusée sous licence AGPL, en remplacement de la licence GPL.

En Février 2012, la release d'Odoo version 6.1 introduit une toute nouvelle interface Web, réécrite from scratch sous la direction d'Antony Lesuisse. Elle utilise les technologies Web modernes en ayant recours à des librairies Web libres reconnues et matures ; ses performances sont grandement améliorées à tel point qu'elle devient aussi rapide que le client Gtk.

Le 21 Décembre 2012, la release d'Odoo 7.0 (version avec support à long terme) apporte une amélioration importante de l'ergonomie et de la facilité d'utilisation de l'interface Web d'Odoo et marque l'abandon du client Gtk. Des fonctionnalités sociales font leur apparition, avec un système de commentaires/discussion sur chaque objet, une intégration avec Linked'In. Un module de gestion de flottes de véhicules est ajouté. Cette release, sortie le jour de la prétendue fin du monde, a été précédé d'une campagne marketing bâtisée Sorry SAP, où Odoo prétend avec cette release marquer la fin de l'ère des ERPs dinosaures et l'avènement d'une nouvelle ère dominée par des ERPs légers et agiles. L'origine de cette campagne a fait l'objet d'un post sur le blog officiel de l'éditeur, intitulé Sorry SAP Campaign - The Making Of. Le site Web classique d'Odoo est remplacé par l'interface Web d'un serveur Odoo de démo (avec des petits liens en bas pour basculer sur le site Web classique). Plus d'infos sur cette nouvelle version dans les release notes d'Odoo 7.0.

L'année 2013 a très mal commencé pour Odoo et se finit très bien. En effet, en Mars 2013, quelques mois après la sortie de la version 7.0, de nombreux bugs sont constatés par les utilisateurs suite au changement du modèle de donnée des partenaires dans Odoo 7.0 (un partenaire est un fournisseur et/ou un client), qui sont rassemblés dans un seul bug report. D'une part, ces soucis étaient totalement prévisibles vu les changements introduits dans le modèle de donnée et l'éditeur a fait preuve d'un grand amateurisme en laissant de tels bugs dans la release d'Odoo 7.0. D'autre part, il y a eu une énorme polémique concernant la solution à adopter pour résoudre tous ces bugs liés au changement du modèle de donnée des partenaires. Après plusieurs semaines de débats enflammés sur la solution technique à adopter, on s'est retrouvé avec d'un côté l'éditeur qui défendait sa solution technique (l'ajout d'un mécanisme de synchronisation des paramètres comptables entre la société et ses contacts) et de l'autre la grande majorité de la communauté qui défendait une autre solution technique (le champ partner_id pointerait vers la société client/fournisseur comme dans les versions antérieures d'Odoo et un nouveau champ contact_id serait utilisé pour pointer vers le contact de facturation). L'éditeur a finalement commité sa solution dans la branche stable d'Odoo avec une petite concession, à savoir l'ajout d'un nouveau champ commercial_partner_id sur les factures qui pointe vers la société client/fournisseur. Cette polémique à laissé des traces et la communauté ne s'est pas sentie très écoutée et respectée par l'éditeur.

Avant même le début de la polémique, Joël Grand-Guillaume de Camptocamp travaillait secrètement au lancement de l'Odoo Community Association (OCA), dont un des objectifs était justement de rassembler la communauté pour qu'elle puisse parler d'une seule voix face à l'éditeur et ainsi mieux se faire entendre. L'annonce officielle de la création de l'Odoo Community Association a été faite lors des Odoo Community Days en Juillet 2013 par 5 sociétés faisant partie des plus gros contributeurs communautaires sur Odoo : Camptocamp, SavoirFaireLinux, Therp, Vauxoo et Akretion. La section suivante contient plus de détails sur l'Association Communautaire Odoo. La fin de l'année a été marquée par la publication du nouveau framework de synchronisation (le module connector) développé par Camptocamp dans le cadre d'un crowd-funding et l'annonce dans la foulée par Camptocamp et Akretion de la disponibilité des connecteurs Odoo-Magento et Odoo-PrestaShop pour Odoo 7.0 basés sur ce nouveau framework de synchronisation.

Le 15 Mai 2014, Odoo S.A. a annoncé plusieurs nouvelles importantes :

Si le passage à Github a été unanimement applaudi par la communauté, la nouvelle politique de pricing des contrats de maintenance a été beaucoup critiquée et a sucité beaucoup d'inquiétude. Comme l'a reconnu l'éditeur sur ce post de blog, la nouvelle politique de pricing va provoquer une importante augmentation de tarif pour les clients qui utilisent de nombreuses applications d'Odoo. Par exemple, pour un client qui utilise la comptabilité, la gestion de stock, les achats, les ventes et les notes de frais, le prix public est désormais de 72 € / utilisateur / mois, au lieu de 35 € / utilisateur / mois avec l'ancienne politique de prix. Le prix a doublé !

Pour moi, cette modification était une grave erreur de la part de l'éditeur. Les entreprises qui ont utilisé des ERPs propriétaires par le passé ont souvent eu le sentiment d'être prises en otage par la décision unilatérale des éditeurs d'augmenter le prix des contrats de maintenance (cf cet article sur SAP par exemple). Si certaines font le choix d'un ERP libre, c'est parfois pour ne pas revivre ce genre de racket. Evidemment, avec un ERP libre, les entreprises ne sont pas obligées de souscrire au contrat de maintenance. La réaction de la communauté à cette modification a été immédiate : 2 semaines après cette annonce, un code sprint a eu lieu pour avancer sur le développement du projet OpenUpgrade, qui vise à fournir une solution libre et communautaire de migration des bases de données Odoo vers les nouvelles versions. Ce code sprint a rassemblé une douzaine de personnes de 6 sociétés différentes pour avancer sur les scripts de migration de la version 7.0 vers 8.0. Le projet OpenUpgrade n'avait jamais connu un tel succès !

La version 8.0 d'Odoo est publiée le 20 Septembre 2014. C'est une version majeure d'Odoo qui comprend :

Cette version 8.0 est pour moi une très bonne nouvelle pour le projet Odoo pour 2 raisons :

  1. les bases techniques d'Odoo ont enfin été modernisées, avec l'introduction de la nouvelle API et du nouveau moteur de rapports... enfin ! Les développeurs attendaient cela depuis longtemps ! La nouvelle API permet un développement plus simple et rapide ; pour une même fonctionnalité, elle utilise 10 à 20% de lignes de code en moins !
  2. par la réécriture complète du module de gestion des stocks, l'éditeur a montré sa capacité et sa volonté d'améliorer les modules essentiels de l'ERP sans avoir peur de casser la compatibilité avec l'existant. Lors des releases précédentes, les modules essentiels (vente, achats, stock, comptabilité) avaient tendance à être délaissés au profit des modules plus bling-bling, du type module de blogs ou module de messagerie instantanée.

Début 2015, l'éditeur a annoncé son retour à l'ancienne politique de pricing des contrats de maintenance (dénommés Odoo Enterprise), en abandonnant le pricing par application, et par conséquent en mettant fin à l'augmentation des tarifs pour les entreprises utilisant Odoo comme un ERP. Ce retour en arrière est une bonne chose, mais il est malheureusement trop tardif, car de nombreuses entreprises n'ont pas renouvelé leur contrat de maintenance et se sont habituées à fonctionner sans contrat de maintenance avec l'éditeur. De plus, la confiance entre l'éditeur et les entreprises utilisatrices mettra du temps à se rétablir. Par ailleurs, ce retour en arrière souligne un autre problème : l'éditeur n'a pas encore trouvé de business model satisfaisant pour lui, ce qui explique ses changements fréquents de business model et de politique tarifaire. Cette décision s'accompagne d'une nouvelle stratégie pour l'éditeur et d'un nouveau business model qui ne fait pas le bonheur de la communauté Odoo : l'éditeur choisi un modèle Freemium où certains modules seront payants ou disponibles uniquement aux entreprises ayant souscrit au contrat de maintenance (qui par conséquent n'est plus seulement un contrat de maintenance, mais devient aussi une licence pour utiliser les modules propriétaires). Pour que cela soit possible, l'éditeur annonce un changement de licence pour la version 9 d'Odoo : la licence AGPL est remplacée par la licence LGPL. En effet, la licence AGPL est contagieuse : elle oblige tous les modules à être publiés sous la même licence ; il n'est alors pas possible de développer et vendre des modules propriétaires pour Odoo. La licence LGPL est, comme la licence AGPL, une licence libre très utilisée, écrite par la FSF (Free Software Fondation), mais, contrairement à la licence AGPL, elle n'est pas contagieuse, donc les modules Odoo peuvent utiliser une autre licence, libre ou propriétaire. Conscient que ce changement de licence pourrait lui amener des ennuis juridiques étant donné que certains contributeurs sur les modules officiels risquent d'être opposés à ce changement qui ne va pas dans le "bon" sens du point de vue des militants du logiciel libre, l'éditeur annonce que les contributeurs vont devoir signer un CLA (Contributor Licence Agreement) qui donnera tous pouvoirs à l'éditeur sur le code écrit par les contributeurs. L'éditeur précise que si certains contributeurs ne signent pas le CLA, leur code sera retiré des modules officiels ou réécrit.

Cette annonce déclanche imméditement une grosse polémique dans la communauté Odoo, comme ça a été le cas dans le passé lors de chaque changement de licence. Cette annonce a été précédée d'échanges et de discussions non publiques entre le bureau de l'OCA et Fabien Pinckers. Ces échanges ont permis d'infléchir la position de l'éditeur, qui souhaitait initialement passer le code d'Odoo sous licence MIT, qui est une licence ultra-permissive qui permet non seulement d'utiliser des modules propriétaires mais en plus de rendre tout le code source d'Odoo propriétaire. Ces échanges ont abouti au choix par l'éditeur de la licence LGPL, qui permet 2 choses que ne permettait pas la licence AGPL : le développement et la vente de modules propriétaires, et le développement et la vente d'une offre SaaS basée sur Odoo sans mise à disposition du code source pour les utilisateurs. Ces échanges ont également permis de faire prendre conscience à l'éditeur que ce changement n'était juridiquement possible que si les contributeurs signent un CLA, alors que Fabien estimait initialement que le portage des modules officiels vers la nouvelle API réalisé par l'éditeur suffirait à "effacer" les copyrights des contributeurs sur les morceaux de code qu'ils ont contribués.

La réplique de l'OCA a été la suivante : les modules OCA peuvent utiliser n'importe quelle licence approuvée par l'OSI, mais l'OCA recommande l'utilisation de la licence AGPL, qui est la plus protectrice pour les utilisateurs et les développeurs. Et l'OCA ne prendra pas l'initiative de changer la licence de ses modules, qui resteront donc sous licence AGPL, même si le CLA de l'OCA permet techniquement de passer les modules OCA sous licence LGPL. Or, comme la licence AGPL contamine les autres modules, cette décision avait pour conséquence que, quand on utilise au moins un module OCA sous licence AGPL, on n'a pas le droit d'utiliser les modules propriétaires. Autrement dit : les utilisateurs doivent choisir entre utiliser des modules OCA ou utiliser des modules propriétaires, ils ne peuvent pas profiter des deux ! Or, l'OCA compte parmi ses modules certains modules très importants d'un point de vue fonctionnel (rapports comptables Webkit, modules de localisation, module de gestion des virements et des prélèvements SEPA, etc) et sans équivalent à l'heure actuelle parmi les modules de l'éditeur. Cela signifiait que, pour tous les déploiements Odoo où les modules OCA sont indispensables à la réussite du déploiement, les modules propriétaires ne pourront pas être utilisés. Cela signifiait par conséquent que le nouveau business model de l'éditeur serait de nouveau un échec. Finalement, un compromis a été trouvé entre l'OCA et l'éditeur : l'OCA garde ses modules actuels sous licence AGPL et continue de recommander l'utilisation de la licence AGPL, mais l'éditeur et l'OCA interprèteront l'effet de contagion de la licence AGPL d'une façon plus restreinte : un module AGPL contamine les modules qui dépendent de lui et seulement ceux-ci. Avec cette interprétation, il est possible d'utiliser des modules OCA sous licence AGPL et des modules propriétaires sur une même installation Odoo à condition que les modules propriétaires ne dépendent pas des modules AGPL et inversement. Lors des journées Odoo Experience 2015 à Louvain-la-neuve, quand Alexandre Fayolle a expliqué cette interprétation de la licence AGPL pour les modules Odoo, il a bien précisé la chose suivante : ceci est une interprétation retenue par l'OCA et l'éditeur, mais vous pouvez ne pas être d'accord avec cette interprétation et penser qu'un module AGPL contamine tous les autres modules sans exception quelles que soient les dépendances entre modules. Dans tous les cas, seul un juge pourrait trancher entre ces 2 interprétations dans le cadre d'un litige et une éventuelle décision de justice prise dans un pays donné ne signifierait pas forcément qu'un juge dans un autre pays prenne la même décision. Cet épisode montre deux choses : que l'OCA a clairement son indépendance vis-à-vis de l'éditeur et est attachée au logiciel libre, mais que la majorité du bureau de l'OCA n'est pas sur une ligne de puristes du logiciel libres mais plutôt sur une ligne pragmatique en cherchant des compromis avec l'éditeur quand cela est possible.

v9 : - retard portage v10 : - consolution - fix betises compta - MRP - abandon ancienne API

Tryton, un fork d'Odoo

Tryton, le fork d'Odoo, continue ses développements de son côté et se prépare à basculer vers Python 3. J'ai pu discuter avec les développeurs principaux de Tryton à l'occasion de PyconFR 2012, le rendez-vous annuel de la communauté Python francophone. Je leur ai demandé quels étaient les principaux points forts de Tryton par rapport à Odoo (je ne leur ai pas demandé quels étaient les points faibles... ils auraient été encore moins objectifs !), et voilà leur réponse :

Outre ces différences techniques mises en avant par les développeurs de Tryton, la principale différence est probablement dans la gouvernance et le contrôle du projet :

Pour en savoir plus sur les différences entre Tryton et Odoo, vous pouvez consulter le site Odoo 2 Tryton, dont le contenu a été rédigé par deux sociétés espagnoles (NaN-tic et Zikzakmedia) qui sont toutes deux des intégrateurs de Tryton et d'anciens intégrateurs d'Odoo (ces deux sociétés étaient à l'époque très impliquées dans la communauté Odoo, avec de grosses contributions à leur actif).

L'Odoo Community Association

L'Odoo Community Association (OCA) a été lancée en Juillet 2013 et a commencé son travail immédiatement après. C'est une association de droit suisse qui est née juridiquement début 2014. Les statuts de l'association sont disponibles en ligne. Le premier board a été formé le 3 Juin 2014 pour une durée d'un an et est présidé par Joël Grand-Guillaume.

L'association a plusieurs objectifs :

Le travail le plus visible de l'association au quotidien consiste à développer sur Github des projets communautaires thématiques qui rassemblent des modules communautaires utiles et de qualité qui ont vocation à être largement déployés. La liste complète des projets est visible en consultant le compte Github de l'OCA. Ces projets, appelés projets OCA, sont gérés selon des règles décidées par la communauté. Pour pouvoir ajouter ou modifier un module dans une branche OCA, il faut d'abord réaliser l'ajout ou la modification dans une branche de développement, puis faire une pull request sur la branche principale appartenant à l'OCA. Cette proposition est alors auditée par la communauté ; si la proposition obtient une approbation de la part d'au moins deux personnes et que personne n'a formulé d'objection valable, alors une personne ayant les droits de commit sur la branche OCA fusionne la branche de développement dans la branche OCA.

Le lancement des projets OCA a changé de façon importante la méthode de travail des développeurs de la communauté Odoo. Auparavant, seules les branches officielles de l'éditeur avaient une visibilité et une audience importante ; par conséquent, quand on voulait ajouter une nouvelle fonctionnalité importante, on l'ajoutait dans un des modules officiels maintenus par l'éditeur et on faisait ensuite une merge proposal pour intégrer les améliorations dans la branche officielle de développement. Malheureusement, l'éditeur était submergé de merge proposals et avait souvent d'autres priorités. Le parcours du combattant-contributeur était le suivant :

  1. faire des pieds et des mains pour arriver à obtenir une review de l'éditeur sur sa merge proposal,
  2. espérer que la personne qui fasse la review comprenne bien le but de la modification ; argumenter et ré-expliquer le pourquoi de la modification,
  3. espérer que le reviewer approuve la merge proposal
  4. et voir enfin sa contribution arriver dans la branche officielle de développement.

Il fallait souvent compter de 6 à 9 mois, parfois plus, même pour des contributions simples. Cela devenait démotivant pour les développeurs de la communauté.

Désormais, étant donné que les projets OCA ont une visibilité importante et sont largement connus et déployés par les intégrateurs Odoo, la méthode de travail des développeurs communautaires Odoo a radicalement changé. Plutôt que d'essayer d'apporter des modifications sur les branches officielles maintenues par l'éditeur et d'élargir leur périmètre fonctionnel, les développeurs de la communauté préfèrent développer des modules dans les branches OCA :

L'objectif est que les modules des projets OCA deviennent des modules de référence dans la communauté Odoo et qu'ils soient largement déployés. Cette diffusion importante doit permettre d'atteindre une masse critique d'utilisateurs et de développeurs qui permette :

L'autre objectif non avoué est que les modules OCA deviennent indispensables au point qu'ils soient utilisés dans la grande majorité des déploiements Odoo ; cela permet à l'OCA de peser face à l'éditeur et d'être un acteur incontournable de l'éco-système Odoo.

L'association maintient également les branches OCB (Odoo Community Backport), qui sont des branches qui évoluent en parallèle des branches de l'éditeur et qui contiennent des bugs fix en plus et parfois des mini-améliorations. Ces branches permettent à la communauté d'avoir plus de réactivité du certains bugs et de gagner en autonomie. Dans la section sur la maturité d'Odoo, je reviens plus en détail sur la naissance des branches OCB et leur fonctionnement.

Le business model de l'éditeur

L'éditeur d'Odoo est la société belge Odoo S.A. avec son siège en Belgique et ses bureaux en Inde et aux Etats-Unis. Les principales sources de revenus de l'éditeur sont :

En plus de ces principales sources de revenus, l'éditeur gagne aussi sa vie en vendant des formations techniques ou fonctionnelles avec une certification à la clé : ces formations sont soit assurées par l'éditeur lui-même, soit assurées par des partenaires, qui reversent une partie du prix de vente de la formation à l'éditeur pour la fourniture des supports de formation et l'accès à l'examen qui permet aux élèves d'obtenir la certification officielle.

L'éditeur publie aussi une série de livres en anglais sur Odoo, mais il utilise ces livres comme un moyen de diffusion d'Odoo et non comme une source de revenus, ce qui explique que la version électronique de la plupart de ces livres soit disponible gratuitement en PDF (en échange d'un Tweet ou d'un message sur Facebook).

Depuis sa création, l'éditeur a changé très souvent de business model :

  1. au début, l'éditeur se rémunérait principalement avec le travail d'intégration sur de gros projets qu'il gérait en direct ; les scripts de migration pour passer à une nouvelle version d'Odoo étaient publics ;
  2. avec l'introduction des contrats de maintenance, l'éditeur a arrêté de publier les scripts de migration et annoncé que le service de migration faisait partie du contrat de maintenance,
  3. après la première levée de fonds, lors de journées Odoo 2010, l'éditeur annonce qu'il arrête l'intégration de projets en direct pour se focaliser sur les contrats de maintenance et le service aux intégrateurs,
  4. un ou deux ans plus tard, l'éditeur se remet à faire des projets d'intégration en direct en parallèle des contrats de maintenance, à la fois pour de gros et de petits projets,
  5. en Mai 2014, à l'occasion de sa 2ème levée de fonds, l'éditeur change radicalement le pricing de ses contrats de maintenance, ce qui augmente beaucoup le prix des contrats de maintenance pour la plupart des entreprises et par réaction booste la motivation de la communauté pour faire avancer le projet OpenUpgrade visant à proposer des scripts de migration libres. Lors des journées Odoo 2014 à Louvain-la-neuve, Fabien met en garde la communauté sur les effets néfastes d'OpenUpgrade sur le business model de l'éditeur, avec un discours visant à faire comprendre à la communauté qu'elle a intérêt à garder un éditeur en bonne santé pour financer la R&D sur Odoo et donc qu'elle n'a pas intérêt à mettre en avant le projet OpenUpgrade,
  6. Six mois plus tard, l'éditeur fait machine arrière et revient à l'ancienne logique de prix pour les contrats de maintenance,
  7. à partir de la version 9, l'éditeur compte se rémunérer principalement grâce à la vente de ses modules propriétaires qui proposent des fonctionnalités supplémentaires et grâce aux commissions perçues sur la vente de modules payants par des tiers sur l'App Store de l'éditeur. Lors des journées Odoo 2015 à Louvain-la-neuve, Fabien évoque même la possibilité que les scripts de migration redeviennent libres à l'avenir et soient publiés au sein du projet OpenUpgrade, si le nouveau business model de l'éditeur fonctionne bien !

Ces changements fréquents de business model de l'éditeur est une source d'instabilité pour les intégrateurs et toute la communauté Odoo. Le business model d'un éditeur de logiciel libre n'est pas une chose évidente et on peut comprendre que l'éditeur d'Odoo ait du mal à trouver le siens ; mais changer de business model chaque année est une folie que peu d'entreprises peuvent se permettre de faire sans désorienter complètement leurs clients et leurs partenaires.

Comment suivre l'actualité d'Odoo

Pour ceux qui voudraient suivre l'actualité d'Odoo "de loin", sans avoir beaucoup de temps à y consacrer, je leur conseille de s'abonner aux deux blogs suivants (disponibles en RSS) :

Malheureusement, cela est loin d'être suffisant ! Pour suivre correctement l'actualité d'Odoo, il faut également utiliser d'autres sources d'information moins classiques ; par ordre d'importance :

Vue générale sur Odoo : diagramme de SWOT

J'ai toujours trouvé ce truc de SWOT (Strenghts, Weaknesses, Opportunities, Threats) très pipeau quand on devait en faire à l'école, et me voilà maintenant en train de l'utiliser !

Forces Faiblesses
  • Bon framework de développement, qui s'est beaucoup amélioré avec l'introduction de la nouvelle API dans Odoo v8 : le framework d'Odoo intègre un ORM, une gestion des droits d'accès, un moteur de workflow et un moteur de rapports (cf Les qualités du framework). Il est très adapté pour le développement rapide de fonctionnalités de gestion.
  • Disponibilité d'une interface Web complète, rapide, jolie et facile à utiliser qui fonctionne avec Chrome, Firefox et Safari (le client Gtk historique a été abandonné avec Odoo 7.0).
  • Choix du langage Python : un langage orienté objet conçu pour être facile pour le développeur.
  • Légèreté et bidouillabilité : Odoo n'est pas une usine à gaz, c'est un logiciel plutôt léger et assez facile à appréhender pour les développeurs. Avec Odoo, si vous avez des connaissances techniques, vous arriverez relativement rapidement à un stade où vous n'aurez plus l'impression que l'ERP est une énorme boite noire mais où vous vous sentirez le maître à bord. En outre, les requirements hardware pour faire tourner un serveur Odoo sont modestes.
  • Ergonomie et facilité d'utilisation : l'éditeur, sous l'impulsion de son fondateur Fabien Pinkaers, est particulièrement porté sur les problématiques de "usability" et les progrès sont visibles à chaque nouvelle version.
  • Modularité : Odoo est très modulaire. Le code fonctionnel est réparti dans de très nombreux modules (comptabilité, gestion de stock, ventes, achats, CRM, gestion de production, gestion de projet, notes de frais, gestion des congés, etc...) et il est possible de n'installer que les modules dont on a besoin. Cette approche modulaire couplée à la notion d'héritage permet de modifier le comportement natif de l'ERP et de l'enrichir sans modifier le code des modules officiels : on peut enrichir les propriétés des objets natifs, modifier les vues natives et changer le comportement natif des fonctions dans des modules spécifiques sans patcher les modules officiels. Cf le chapitre les modules.
  • Une communauté dynamique, sympathique et qui code énormément. La communauté Odoo ne se contente pas de faire des bugs report et de demander des features à l'éditeur, comme on le voit parfois sur certains projets OpenSource ; elle développe de nombreux modules communautaires et propose de nombreuses améliorations sous forme de pull requests à l'éditeur (qui ne prend pas toujours assez de temps pour les traiter !). Je ne pense pas me tromper en disant que la communauté Odoo est la plus grosse communauté parmi les ERPs OpenSource. Je pense que la communauté a atteint un niveau de contribution et d'expertise sur le code lui permettant de continuer le développement du logiciel seule en cas de faillite de l'éditeur, ce qui est une assurance de pérennité.
  • L'existence de l'Odoo Community Association qui coordonne les développements de la communauté et lui permet de parler d'une seule voix et de peser face à l'éditeur.
  • L'évolution rapide du logiciel et son rythme d'innovation très soutenu, qui profite aux nouveaux utilisateurs mais aussi aux utilisateurs historiques quand ils mettent à jour leur Odoo vers la dernière version.
  • Une marque (Odoo) et une image qui s'est beaucoup professionnalisée.
  • La faiblesse fonctionnelle des modules officiels. Odoo possède le minimum dans chaque domaine, cf la section sur ce sujet.
  • Un manque de maturité, qui se ressent sur le temps passé à corriger des bugs, pour certains très basiques, cf le chapitre la maturité d'Odoo.
  • L'éditeur fait parfois preuve d'un grand amateurisme sur certaines problématiques fonctionnelles, comme l'a illustré le fiasco de la gestion des contacts dans Odoo 7.0 suite à un changement du modèle de données. D'ailleurs, si vous envisagez d'utiliser Odoo 7.0, il est important de prendre le temps de lire ce bug report, qui liste les principaux problèmes constatés dans la gestion des contacts dans Odoo 7.0 et discute des solutions possibles.
  • La sécurité n'a jamais été une préoccupation importante chez les développeurs d'Odoo (et c'est rarement le cas dans les logiciels de gestion en général), mais l'éditeur fait aujourd'hui la promotion des fonctionnalités de site Web (CMS, blog), de site e-commerce et de portail client d'Odoo. Pour les clients qui ont un serveur Odoo directement accessible sur Internet et qui activent ces fonctionnalités, cela expose toutes les données de l'entreprise présentes dans Odoo à un risque important de piratage.
  • Manque de disponibilité de l'éditeur pour approuver (ou refuser) les pull requests communautaires sur les branches officielles de développement, alors même que l'éditeur se réserve le monopole des commits sur ces branches.
  • L'éditeur change fréquemment de business model, ce qui impacte par ricochet tout l'écosystème d'Odoo et montre que l'éditeur n'a pas encore trouvé de business model satisfaisant pour lui, cf la section sur ce sujet.
  • Manque de disponibilité d'intégrateurs expérimentés qui ont un bon niveau technique et fonctionnel.
  • L'éditeur ne publie pas de scripts de migration pour les modules officiels ; il le fait payer sous forme de service.
  • Traduction en français perfectible sur les modules officiels. Les modules communautaires sont rarement traduits en français, ce qui fait un mélange français/anglais dans l'interface pour les utilisateurs qui veulent utiliser Odoo en français (la solution d'utiliser Odoo en anglais est à privilégier si possible).
  • La migration vers Python 3 n'est pas plannifiée, ni même évoquée par l'éditeur.
Opportunités Menaces
  • Etre le leader des ERPs OpenSource.
  • Développement de scripts de migration communautaires avec le projet OpenUpgrade.
  • L'apparition de modules propriétaires payants sur Odoo v9, développés par l'éditeur ou par des tiers. Cela risque de dégrader l'image OpenSource d'Odoo, de démotiver les contributeurs à développer des modules sous licence libre et de diviser les efforts avec l'apparition de doublons entre modules propriétaires et modules libres, sans possibilité de mise en commun du code et des efforts. A terme, le risque est que, pour les modules de l'éditeur, la frontière fonctionnelle entre les modules OpenSource gratuits et les modules propriétaires payants se décale progressivement en faveur des modules payants à chaque sortie d'une nouvelle version d'Odoo.
  • Le risque d'un nouveau fork communautaire d'Odoo, si l'éditeur ne joue plus le jeu du logiciel libre et réserve trop de fonctionnalités importantes pour les modules propriétaires.
  • Certains bons contributeurs de la communauté Odoo sont partis chez Tryton (un fork d'Odoo) en 2010-2011, mais cette hémoragie semble stoppée.

Odoo, la licence et les copyrights

Odoo était initialement disponible sous licence GPL, puis est passé sous licence AGPL en Octobre 2009 pour les branches de développement ; la première version d'Odoo diffusée sous licence AGPL est donc la version 6.0 sortie en Janvier 2011. La licence a de nouveau été modifiée en Juin 2011 (cf l'annonce de la nouvelle offre Odoo Enterprise, concomitante à la refonte du site web) pour devenir une licence "AGPL spéciale", dont j'expliquerai l'aspect "spécial" ci-dessous. Début 2015, l'éditeur annonce le passage sous licence LGPL pour la version 9 et demande aux contributeurs de signer un CLA.

Odoo, dans sa version actuelle, est composé des briques logicielles suivantes :

  1. le serveur Odoo avec ses modules officiels dont le code source est disponible sur le projet Github odoo,
  2. les modules communautaires maintenus par l'Odoo Community Association, qu'on pourrait appeler les modules "communautaires officiels",
  3. les autres modules communautaires, qui ne sont pas gérés par l'association.

Le premier composant (le serveur avec les modules officiels souvent appelés official addons) est maintenu par l'éditeur et les développeurs de l'éditeur sont les seuls à avoir le droit de commit sur la version officielle de ces composants. Depuis début 2015, pour qu'un patch d'un membre de la communauté soit accepté par l'éditeur sur ce composant, il faut que le contributeur ait signé un CLA qui donne tous les droits à l'éditeur pour changer la licence, sans restriction. C'est ce composant qui va passer de la licence AGPL "spéciale" à la licence LGPL à l'occasion de la sortie de la version 9.

Le deuxième composant, les modules communautaires de l'OCA, sont quasi-exclusivement publiés sous licence AGPL. L'OCA recommande l'utilisation de la licence AGPL mais accepte les contributions sous d'autres licences OpenSource compatibles avec la nouvelle licence LGPL de l'éditeur. Pour contribuer sur le code des projets de l'OCA, il faut avoir signé le CLA de l'OCA qui précise que l'OCA peut changer la licence de ses modules vers n'importe quelle licence approuvée par l'OSI (OpenSource Initiative). Mais, comme l'OCA a un fonctionnement démocratique avec un bureau élu pour une durée de 1 an, si le bureau de l'OCA décidait de changer la licence des modules OCA contre l'avis de la majorité des membres de l'OCA, on peut imaginer qu'il serait sanctionné aux élections suivantes et qu'un nouveau bureau serait élu qui pourrait décider de revenir à l'ancienne licence. Un petit groupe de contributeurs possède les droits de commit sur la totalité des branches de l'OCA et, sur chaque projet, des droits de commits sont attribués aux principaux reviewers du projet (les reviewers sont des contributeurs qui font des revues de code sur les pull requests).

Pour le dernier composant, les "autres" modules communautaires, il n'existe pas de règle particulière. Chaque auteur a les droits de commit sur son module et choisi la licence qui s'applique à son module ; il peut décider (en accord avec les autres auteurs éventuels si le module compte plusieurs auteurs) de changer la licence comme bon lui semble.

Le passage de la licence GPL à la licence AGPL en Octobre 2009 a été globalement bien accueilli. La licence AGPL ressemble à la licence GPL, mais introduit une clause supplémentaire : si une personne utilise le logiciel en mode SaaS, elle peut exiger de la personne qui héberge le serveur qu'elle lui transmette le code source de ce qui est exécuté côté serveur (l'utilisateur d'un logiciel sous licence GPL peut exiger le code source si le logiciel lui a été distribué/transmis, or, dans le cas d'un logiciel en mode SaaS utilisé via une interface Web, le logiciel reste sur le serveur de l'hébergeur et ne lui est jamais distribué/transmis... il ne peut donc pas exiger le code source !).

Ensuite, Odoo a de nouveau changé sa licence en Juin 2011 pour passer à une sorte de double licence :

Cette licence AGPL + private use permettait de développer des modules privés i.e. des modules dont l'utilisateur ne pourrait pas exiger le code source. Cette possibilité demeurait très encadrée car la licence prévoyait que, si le module en question était distribué à un tiers, alors il devait être distribué sous la licence AGPL normale. Elle a été introduite à la demande de certaines grosses entreprises utilisatrices d'Odoo qui souhaitaient garder privés certains modules développés par leurs soins (sinon, ces modules auraient été "contaminés" par la licence AGPL), car elles affirmaient que certains modules qu'elles avaient développés implémentent des secrets industriels ou leur confèrent un avantage compétitif par rapport à leurs concurrents.

La question de la licence est toujours un sujet sensible chez les développeurs de logiciels libres. Etant donné que ce deuxième changement de licence introduisait la possibilité de développer des modules privés sous certaines conditions, une polémique avait éclaté au sein des développeurs de la communauté Odoo. Cette polémique avait permis de souligner deux points importants.

Le premier point concernait la compatibilité entre l'utilisation de modules communautaires et la clause spéciale "private use". Les modules communautaires sont généralement disponibles sous licence AGPL normale. Or, si un serveur Odoo utilise à la fois des modules officiels et des modules communautaires sous licence AGPL normale, alors l'ensemble devenait soumis à la licence AGPL normale sans la clause "private use". Autrement dit, si vous aviez souscrit à un contrat de maintenance et que vous utilisiez des modules communautaires, vous ne pouviez pas développer des modules privés... sauf à contacter chacun des auteurs des modules communautaires et leur demander, éventuellement contre rémunération, qu'ils vous accordent une licence AGPL + private use sur leur module.

Le deuxième point avait trait au fait que l'éditeur ne possédait pas l'ensemble du copyright sur le premier composant (le serveur et les modules officiels dits addons) car il avait accepté des contributions de certains développeurs de la communauté. Or, dans le cas d'un co-développement, un changement de licence nécessite l'accord explicite et tous les co-auteurs. Or l'éditeur avait pris la décision de changer la licence de façon unilatérale sans demander l'accord des contributeurs. Et à l'époque, l'éditeur n'avait pas mis en place de contributor licence agreement (CLA) prévoyant un droit qui lui serait donné de changer la licence sans accord explicite des contributeurs. Cela engendrait un risque : si vous déteniez un contrat de maintenance et que vous utilisiez la possibilité qui vous était offerte de développer des modules privés, un ou plusieurs contributeurs de la communauté ayant apporté des contributions sur le serveur Odoo ou un des addons officiels pouvaient vous poursuivre pour violation de licence, car vous utilisiez la licence AGPL + private use alors que ces contributeurs pouvaient prétendre que le code qu'ils avaient contribué était sous licence AGPL normale.

A l'époque, l'éditeur d'Odoo ne prenait pas au sérieux cette problématique de la détention du copyright, à laquelle les développeurs de logiciels libres sont pourtant très sensibilisés. Pour l'anecdote, il semble que ce manque de rigueur au niveau de ce qui tourne autour de la licence soit très ancien, car le problème était déjà présent dans la toute première release de TinyERP le 6 Juillet 2004, cf le premier commentaire posté par snspy sur la news d'annonce de la version 1.0 sur LinuxFR !

Heureusement, avec le passage sous licence LGPL décidé début 2015, l'éditeur a enfin commencé à traiter cette problématique de façon sérieuse et a mis en place un CLA qui doit être signé par tous les contributeurs de la communauté s'ils souhaitent voir leurs patchs intégrés dans le serveur ou dans les modules officiels. On peut seulement regretter que le CLA de l'éditeur donne tous les droits à l'éditeur pour changer la licence, y compris passer le code du contributeur sous une licence propriétaire ! Par contraste, le CLA de l'OCA a une clause qui dit que le CLA permet à l'OCA de changer la licence mais que la nouvelle licence doit obligatoirement être une licence libre approuvée par l'OSI.

Le framework

Distinguer les projets framework des projets ERP

J'insiste souvent sur ce point quand je présente Odoo : il faut distinguer les "projets framework" des "projets ERP". Qu'est-ce que j'entends par un "projet framework" ? C'est un projet dans lequel seul le framework d'Odoo est utilisé et où les modules fonctionnels officiels (comptabilité, stock, vente, achat, CRM, production, gestion de projet) ne sont pas utilisés ou seulement un ou deux. Dans le cas d'un "projet framework", l'entreprise aurait pu choisir de développer son application en PHP/MySQL, en Ruby-on-rails ou en Python/Django, mais elle a choisi de développer son application dans le framework d'Odoo.

En effet, la quasi-totalité des grosses références d'Odoo sont des "projets framework". Des références comme La Poste, Véolia transport, Free, etc... sont toutes des "références framework".

L'entreprise qui a fait ce choix tire ainsi parti des avantages du framework d'Odoo : l'ORM, la gestion des droits d'accès, le moteur de workflow, le moteur de rapport et l'interface Web. En réalité, d'après mes discussions avec certains intégrateurs qui font souvent des projets framework, il semble que certains décideurs, pas forcément très au fait des réalités techniques, font le choix de développer leur application métier dans le framework d'Odoo car il contient le mot magique "ERP" ; ils peuvent ainsi dire "j'ai déployé un ERP pour gérer xxxxxx", ce qui sous-entend qu'il a utilisé un logiciel déjà fait pour cette fonction avec certains développements spécifiques pour les adaptations nécessaires, alors qu'en fait il a fait faire un énorme développement spécifique, où tout le code fonctionnel est entièrement sur mesure, ce qui implique qu'il devra supporter seul le coût des évolutions et le coût du portage du code vers les nouvelles versions du framework s'il souhaite tirer parti des améliorations du framework.

Cela signifie aussi que ces grosses "références framework" très prestigieuses n'utilisent pas la comptabilité d'Odoo, n'utilisent pas la gestion de stock d'Odoo, etc. Cela limite un peu la portée de ces références ! Par contre, cela prouve que le framework d'Odoo est de qualité, ce qui n'est pas rien !

En réalité, dans le cadre de "projets ERP", Odoo est adapté pour des déploiements dans des PMEs de quelques dizaines à quelques centaines d'employés, mais le nom de ces PMEs est rarement connu du grand public, ce qui ne permet pas de les ranger dans la catégorie des références prestigieuses !

Une exception à cela : le déploiement Odoo réalisé par Danone. Evidemment, Danone utilise SAP et n'est pas prêt d'en changer ! Mais Danone a choisi de déployer Odoo dans 3 filiales ou join-ventures en phase de démarrage en Colombie et en Australie (2 installations en Colombie pour 5 et 10 utilisateurs ; 1 installation en Australie pour 20 utilisateurs). Plutôt que d'assomer leurs filiales en phase de démarrage avec SAP, ils ont préféré leur installer Odoo pour gérer l'administration des ventes, les achats, les stocks, etc. Vous trouverez plus de détails sur cette success story dans cet article sur 01net.

Les qualités du framework

Je ne suis pas le plus à même de parler des qualités du framework d'Odoo car je n'ai pas développé avec les frameworks concurrents, donc je ne peux pas faire des comparaisons précises. Cependant, je peux quand même affirmer que le framework d'Odoo se distingue sur les points suivants :

Le meilleur exemple qui illustre la qualité du framework d'Odoo est l'ajout de vues cartographiques dans Odoo, qui a été réalisé par l'intégrateur Camptocamp. En 2011, Camptocamp a fait évoluer le framework d'Odoo pour ajouter le support des vues cartographiques : en un clic dans Odoo, vous pouvez par exemple voir tous vos clients sur une carte, comme le montre cette vidéo. Pour cela, ils ont fait évoluer intelligement le framework d'Odoo et développé des modules spécifiques. Cela aurait été impossible si le framework d'Odoo avait été mal conçu ! Si vous voulez en savoir plus, vous pouvez lire l'annonce initiale, consulter ces slides présentés aux community days Odoo 2012 et obtenir le code sur le projet OCA GeoSpacial.

Les défauts du framework

Il est rare de trouver un framework parfait et celui d'Odoo n'est pas exempt de défauts. Heureusement, la nouvelle API introduite avec Odoo v8 corrige les principaux défauts du framework ; cependant, il faudra attendre que tous les modules officiels soient portés en nouvelle API pour ne plus être impactés par les défauts de l'ancienne API. Or, dans Odoo v8, seul le module event utilise la nouvelle API ainsi qu'une petite partie du module account (la partie qui a trait aux factures). Voici les défauts du framework, abstraction faite des défauts de l'ancienne API (même si les développeurs y sont encore confrontés quand ils héritent un module écrit en ancienne API) :

Pour clore cette partie sur les qualités et les défauts du framework Odoo, je vous invite à lire cet article très intéressant d'un développeur habitué à coder des applications métier dans Lotus Domino et qui a suivi une semaine de formation technique pour apprendre à développer dans le framework d'Odoo. Il compare les deux framework et donne son avis sur ce qui est mieux dans l'un par rapport à l'autre ; attention, ce témoignage date de 2011 et ne tient pas compte de la nouvelle API d'Odoo.

Le choix du moteur de rapport

Voilà un tableau récapitulatif des moteurs de rapport utilisables avec Odoo :

Nom du moteur de rapport Module Mainteneur Outil de conception des rapports Formats de sortie possibles
QWeb intégré dans le serveur Odoo 8.0 ; c'est le moteur utilisé dans les rapports officiels d'Odoo 8.0. Odoo S.A. Codage manuel HTML, PDF, TXT
RML intégré dans le serveur Odoo + module officiel base_report_designer. C'est le moteur par défaut jusqu'à Odoo 7.0 compris. Il fait encore partie d'Odoo 8.0 mais n'est utilisé que dans quelques cas "spéciaux". Odoo S.A. Codage manuel en RML ou conception dans OpenOffice SXW, HTML, PDF, TXT
Jasper projet openerp-jasperserver de Syleam Syleam (intégrateur français) Jasper iReport Tous les formats supportés par Jasper
Aeroo module communautaire report_aeroo Alistek (intégrateur letton) LibreOffice Tous les formats supportés par LibreOffice : ODT, ODS, PDF, HTML, DOC, XLS, TXT...
Webkit module report_webkit, devenu un module officiel avec Odoo 6.0. Dans Odoo 9.0, il ne fera plus parti des modules officiels (cf ce mail) et deviendra un module communautaire. Camptocamp (intégrateur suisse) Editeur HTML PDF

Pour être exhaustif, il y a aussi :

La profusion de choix dans les moteurs de rapports pour Odoo s'explique en partie par les défauts du moteur de rapport utilisé par défaut dans Odoo, qui ont poussé la communauté à développer des alternatives.

Le moteur de rapport QWeb - le nouveau moteur par défaut d'Odoo

Le moteur de rapport QWeb a été développé par l'éditeur et livré dans Odoo 8.0. En même temps que la livraison de ce nouveau moteur de rapport Qweb, l'éditeur a fait l'effort de convertir tous les rapports livrés par défaut dans Odoo dans ce nouveau format, ce qui a permis d'imposer ce moteur de rapport dès la sortie d'Odoo 8.0 en Septembre 2014.

Qweb est le nom d'un moteur de template XML écrit par Antony Lesuisse et utilisé dans Odoo pour la génération des pages Web et maintenant également pour les rapports. A ma connaissance, Qweb n'est pas utilisé par d'autres logiciels qu'Odoo et n'est pas disponible en mode standalone en dehors d'Odoo.

La principale qualité de Qweb par rapport à d'autres moteurs de template est qu'il intègre nativement un mécanisme d'héritage, qui permet de définir une structure dans un module A et de la modifier dans un module B qui dépend du module A.

Les rapports au format QWeb sont développés en HTML/CSS ; ils ont 2 formats de sortie possibles :

Par rapport à ce que les développeurs avaient l'habitude avec les autres moteurs de rapports d'Odoo, le moteur de rapport Qweb a introduit quelques détails pratiques : la notion de widget pour permettre un rendu particulier de certains champs (par exemple le widget monetary pour afficher un montant avec sa devise associée), le fait que les champs soient traduisibles par défaut, que les dates et les nombres soient dans le format associé à la langue du rapport sans appel à une fonction spécifique, et quelques autres détails.

Les seuls défauts que je connais à ce moteur de rapport ne sont pas des défauts d'implémentation mais des défauts liés à la nature même du moteur :

Le moteur de rapport RML - l'ancien moteur par défaut d'Odoo

Le moteur de rapport par défaut d'Odoo est basé sur le langage RML (Report Markup Language), qui est un standard mis au point par la société anglaise ReportLab. Malheureusement, ce langage ne s'est pas imposé et son utilisation dans l'industrie du logiciel est restée confidentielle. La société ReportLab a développé une implémentation OpenSource limitée et une implémentation propriétaire payante plus complète du langage RML (cf la "feature comparison" sur cette page). Odoo a réalisé sa propre implémentation du langage RML en développant un outil de conversion RML vers PDF et RML vers HTML. Cette implémentation est disponible dans le serveur Odoo (cf les répertoires server/openerp/report/render/rml2html/ et server/openerp/report/render/rml2pdf/). Malheureusement, cette implémentation n'est pas complète et beaucoup de balises RML ne sont pas supportées. Pour éviter aux développeurs d'apprendre le langage RML, Odoo dispose d'un outil de conversion de SXW (le format de fichier d'OpenOffice 1.x) vers RML, qui est localisé dans le module base_report_designer des addons officiels (cf répertoire addons/base_report_designer/openerp_sxw2rml/). Comme on peut facilement l'imaginer, cette implémentation de la conversion SXW vers RML n'est pas complète... ce serait d'ailleurs un travail assez titanesque !

Il y a 2 façons de se servir de ce moteur de rapport :

Le moteur RML a été le moteur par défaut jusqu'à Odoo 7.0 inclus. Vu ses défauts et ses limitations, notamment en ce qui concerne les "pertes" de style et de mise en page, vous comprenez pourquoi la communauté Odoo était si motivée pour développer des alternatives, ce qui explique pourquoi il y a autant de moteurs de rapports communautaires alternatifs !

Le moteur de rapport Jasper

JasperReports est un moteur de rapport OpenSource reconnu, écrit en Java. Il fait partie de la solution de business intelligence de l'éditeur JasperSoft. C'est le moteur de rapport par défaut de l'ERP OpenSource OpenBravo. C'est une solution mature et performante. La conception des rapports se fait avec le logiciel iReport, qui fait partie de la suite Jasper. Cet outil est quand même un peu technique et nécessite un apprentissage, contrairement à LibreOffice par exemple ; il faut donc prendre le temps de se former sur cet outil. Le rendu est réalisé par le serveur Jasper, qui peut être installé sur la même machine que le serveur Odoo ou sur une autre machine. Les deux modules concurrents développés par Syleam et Nan-tic assurent l'interconnexion entre le serveur Odoo et le serveur JasperReports. C'est une solution que je connais assez peu car je ne l'ai jamais utilisée... je ne peux donc pas en parler de façon détaillée.

Le moteur de rapport Aeroo - celui que j'utilise

Aeroo Report est un moteur de rapport basé sur LibreOffice, qui est similaire à la solution utilisée par défaut dans Tryton. C'est le moteur de rapport que j'ai adopté pour tous mes déploiements Odoo en remplacement du moteur de rapport par défaut ; je le connais donc très bien. Il supporte de nombreux formats en entrée et en sortie :

Format d'entrée Format de sortie Outil requis coté serveur
TXT/CSV TXT/CSV avec choix du charset Genshi
HTML HTML Genshi
ODT ODT Genshi + aeroolib
ODS ODS Genshi + aeroolib
ODT PDF ou DOC Genshi + aeroolib + LibreOffice
ODS PDF, XLS ou CSV Genshi + aeroolib + LibreOffice

Les deux principaux cas d'utilisation d'Aeroo sont :

Le composant aeroo_docs est un mini-démon de moins de 500 lignes de code ; son utilité principale est de faire l'interface entre Odoo écrit en Python 2 et la librairie Python UNO qui permet d'accéder à LibreOffice, et dont les paquets disponibles dans les principales distributions Linux sont compatibles uniquement avec Python 3 (sur Ubuntu, il y a un paquet python3-uno, mais il n'existe plus de paquet python-uno). Aeroo_docs est donc écrit en Python 3 pour pouvoir utiliser la librairie uno et dialogue via une socket réseau avec le module report_aeroo d'Odoo, écrit en Python 2.

En résumé :

Pour terminer sur le moteur de rapport Aeroo, un petit secret à connaitre : pour utiliser report_aeroo sur Odoo v8.0, il ne faut pas prendre la branche 8.0 du projet Github aeroo_reports mais prendre la branche master !

Le moteur de rapport Webkit

Le moteur de rapport Webkit a été développé par la société suisse Camptocamp, qui est un intégrateur pionnier sur Odoo et qui a fait de nombreuses contributions importantes et de grande qualité sur Odoo. Webkit est le moteur de rendu HTML libre utilisé par Google Chrome et Safari ; c'est un concurrent du moteur Gecko utilisé par Firefox. Il est réputé pour ses très bonnes performances. Le moteur de rapport Webkit a été initialement développé par Camptocamp pour un de ses clients sous Odoo 5.0 qui avait un très grand nombre de factures à sortir à chaque début de mois. Il avait donc besoin d'une solution performante, capable de sortir des documents en masse dans un format non éditable (je veux dire pas en ODT ou DOC). Avec le moteur de rapport Webkit, le rapport doit être développé en HTML/CSS et il y a un seul format de sortie possible : le format PDF. Pour générer le fichier PDF, le module report_webkit utilise le moteur de template Mako pour remplacer les champs par leur valeur et envoie ensuite le document HTML résultant au programme wkhtmltopdf qui est un composant du projet Webkit qui converti les documents HTML en documents PDF.

Camptocamp a réussi à convaincre l'éditeur d'Odoo d'inclure le module report_webkit parmi les modules officiels, ce qui a été fait dans Odoo 6.0. Cela lui donne une forte visibilité et implique que le module est couvert par le contrat de maintenance proposé par l'éditeur. En résumé :

Avec l'arrivée du moteur de rapport QWeb, le moteur Webkit n'a plus d'intérêt à mon sens. En effet, le moteur de rapport QWeb a les mêmes qualités que le moteur Webkit et utilise la même base technique (le programme wkhtmltopdf), et possède des avantages supplémentaires (l'héritage, la sortie HTML et le fait d'être le moteur de rapport par défaut d'Odoo). Le moteur Webkit continuera à être utilisé chez les clients qui ont développé leurs rapports en Webkit et qui ne souhaitent pas les redévelopper en QWeb à l'occasion d'une mise à jour de leur Odoo, mais je ne pense pas que ce soit une bonne idée de choisir le moteur de rapport Webkit pour un nouveau projet Odoo.

Plateforme et requirements hardware pour le serveur

Odoo n'est pas un logiciel gourmand en ressources. Pour un déploiement du serveur Odoo et de sa base de données PostgreSQL dans une PME de quelques dizaines de personnes, on peut normalement se contenter d'un processeur décent et de 512 Mo de RAM ! Par contre, il faut aussi tenir compte des ressources requises par le moteur de rapport ; si vous faites le choix du moteur de rapport Jasper ou Aeroo, il faut prévoir plus de RAM pour faire tourner le serveur Jasper en Java ou LibreOffice sur le serveur !

Python et PostgreSQL étant des solutions multi-plateformes, il est possible de déployer le serveur Odoo sur l'OS de votre choix : Linux, Windows, Mac OS X, etc. Le mieux est probablement de le déployer sur l'OS serveur que vous connaissez le mieux, car c'est vous qui aurez ensuite à administrer le serveur, faire les mises à jour de sécurité, faire les backups, etc. La quasi-totalité des installations Odoo tournent sur des serveurs Linux : un OS libre pour héberger un ERP libre, quoi de plus naturel ? C'est aussi sur cette plateforme que vous trouverez le plus facilement de l'aide au sein de la communauté Odoo.

Il n'est pas envisageable aujourd'hui de déployer Odoo sur un serveur de production via des packages, que ce soit des packages de distributions Linux, les archives de type tarball ou des installeurs all-in-one Windows. En effet, vous serez très certainement amenés à appliquer des patchs sur les modules fonctionnels pour corriger certains bugs, ce qui ne serait pas du tout pratique si vous avez installé Odoo via les packages de votre distribution Linux par exemple. De plus, l'éditeur ne fait plus de releases mineures d'Odoo i.e. la release majeure 6.1 n'est plus suivie de releases mineures 6.1.1 puis 6.1.2, etc... Je conseille donc de déployer le code d'Odoo sur votre serveur de production :

La business intelligence avec Odoo

La business intelligence (BI) est un mot très pompeux qui désigne le fait de "faire parler" les données stockées dans ses bases de données, par le biais de statistiques, qui peuvent prendre la forme de graphiques, de tableaux croisés dynamiques (on dit OLAP en langage "BI"), de tableaux de bord, etc.

Il est possible de développer des graphiques ou des tableaux croisés dynamiques directement dans Odoo. Historiquement, les graphiques intégrés dans Odoo étaient très limités, mais l'éditeur a redéveloppé from scratch la vue des graphiques dans Odoo 7.0, cf ce post sur le blog officiel. Dans Odoo 8.0, l'éditeur a développé des fonctionnalités de tableau croisé dynamique (OLAP) dans Odoo, avec possibilité d'export Excel (cf ces slides). Ces tableaux croisés disponibles directement dans Odoo fonctionnent bien et devraient pouvoir satisfaire la plupart des utilisateurs. La solution est simple pour le développeur et intuitive pour les utilisateurs. Le seul manque important au niveau des cubes OLAP d'Odoo est la fonction de drill-through.

Si les fonctionnalités de graphiques et de tableaux croisés dynamiques intégrés dans Odoo ne donnent pas satisfaction, il existe de nombreuses solutions OpenSource de Business Intelligence, les plus connues et matures étant :

L'offre OpenSource dans le domaine de la business intelligence est large, diversifiée et mature. Pour suivre l'actualité de la business intelligence OpenSource, je vous conseille de suivre le blog OSBI.fr de Sylvain Decloix d'ATOL CD.

Les modules

Le nombre de modules

Tout d'abord, il faut aujourd'hui différencier trois catégories de modules :

L'ensemble de ces modules est répertorié sur le site Odoo Apps (à condition que le développeur du module ait enregistré la branche dans laquelle se trouve son module dans Odoo Apps). Ce site permet de rechercher des modules par mots clés et de voir leur description et la branche Launchpad ou Github dans laquelle ils se trouvent. Mais, comme les possibilités de recherche sur Odoo Apps sont un peu limitées, l'intégrateur allemand initOS a lancé un moteur de recherche odoo code search qui permet à la fois de chercher dans les métadonnées d'un module mais aussi dans le code source d'un module. Contrairement à Odoo Apps, ce moteur de recherche trouve par lui-même les modules Odoo sans besoin d'un enregistrement préalable.

Une des choses qui m'énerve le plus dans le discours qu'on peut entendre sur Odoo est "qu'il y a N milliers de modules fonctionnels disponibles". Il y a effectivement plus de 5800 modules référencés sur Odoo Apps, donc cette affirmation n'est a priori pas mensongère en sens strict. Sur les 5800 modules, il y a les 200 modules officiels qui sont maintenus par l'éditeur, environ 700 modules OCA, et 4900 autres modules communautaires (ce dernier chiffre a été obtenu par simple soustraction par rapport aux deux premiers). Sur ces 4900 autres modules communautaires, j'estime qu'il y a 90% de modules inutilisables, car :

J'ai l'habitude de dire : "un module Odoo, tant qu'on ne l'a pas essayé, on ne sait pas ce qu'il vaut !"

Parmi les modules communautaires non-OCA, on trouve tous les niveaux de qualités. Si je devais faire une classification, par ordre croissant :

  1. les modules peu génériques qui sont trop spécifiques à un cas particulier,
  2. les modules génériques mais pas bien maintenus i.e. qui ne supportent qu'une ancienne version d'Odoo,
  3. les modules génériques et maintenus, mais qui n'ont pas été finalisés, par exemple des modules qui créent de nouveaux objets sans s'occuper des ACL (Access Control List) correspondantes et/ou dont l'ergonomie est mal fichue ou n'est pas conforme aux standards d'ergonomie d'Odoo,
  4. les modules génériques, maintenus, qui ont été finalisés/peaufinés... ils ne sont pas si nombreux !
  5. le top étant les modules génériques, maintenus, peaufinés et qui sont dotés d'une suite de tests automatisés pour tracker les régressions éventuelles lors du développement ! Je n'en connais pas beaucoup, car la plupart des bons modules communautaires font maintenant partie de l'OCA.

Dans cette jungle de modules, où le meilleur côtoie le pire, il est souvent difficile de s'y retrouver. Au début du travail d'intégration d'Odoo à Anevia, il nous était même arrivé à deux reprises de nous lancer dans un développement spécifique avant de s'apercevoir par la suite qu'un module communautaire était disponible pour ce qu'on voulait faire ! Savoir quels sont les "bons" modules Odoo i.e. ceux qui marchent vraiment, qui sont codés correctement et dont la couverture fonctionnelle est intéressante, est une connaissance précieuse et longue à acquérir. Et comme personne ne peut connaître tous les modules ni avoir le temps de tous les tester, les experts Odoo ont l'habitude d'échanger entre eux leur expérience des bons et mauvais modules.

Les modules officiels : le minimum dans chaque domaine

N'allez pas vous imaginer qu'Odoo concurrence avec ses modules officiels des ERPs propriétaires de premier plan dans le domaine fonctionnel. Odoo fournit le minimum dans chaque domaine fonctionnel, je dirai presque le minimum vital !

Une des conclusions à laquelle je suis arrivé en observant les priorités de l'éditeur et en discutant avec ses équipes, est que cela fait partie de la philosophie d'Odoo. Odoo, avec ses modules officiels, fournit un socle minimum dans chaque domaine, et le framework Odoo est conçu pour permettre de facilement étendre ce périmètre fonctionnel minimum pour les besoins particuliers du client.

Dit autrement :

Voilà quelques exemples de "manques" fonctionnels qui ne sont pas couverts par les modules officiels :

Pour tous les exemples de "manques" fonctionnels cités ci-dessus, il existe un ou plusieurs modules communautaires qui assurent la fonction. Il est donc très rare de faire des déploiements Odoo en utilisant uniquement les modules officiels.

Autre exemple pour illustrer l'aspect minimaliste des modules officiels : voilà la liste de toutes les fonctionnalités qu'Anevia a eu besoin d'ajouter dans un module spécifique pour étendre la couverture fonctionnelle du module officiel de gestion des notes de frais (module hr_expense) :

J'espère que les exemples que je viens de citer vous permettent de mieux comprendre ce que je veux dire quand j'affirme que "les modules officiels fournissent le minimum dans chaque domaine". J'insiste un peu sur ce point car je crois qu'il est très important pour bien comprendre Odoo. S'il y avait une chose à retenir, ce serait celle-là : Odoo est un ERP simple et minimaliste doté d'un bon framework qui permet d'étendre facilement ses fonctionnalités dans les domaines où vous en avez besoin en développant des modules additionnels qui vont utiliser le mécanisme d'héritage.

Cela me rappelle ce que me disait mon père, qui travaillait à l'époque dans les ERPs propriétaires, quand j'ai commencé à chercher un ERP pour Anevia : "si un vendeur d'ERP te dit qu'il faut réaliser des développements spécifiques pour répondre à tes besoins, fuis-le comme la peste !" En disant cela, il faisait référence au coût important des développements spécifiques qui, avec un ERP propriétaire, s'ajoute au coût non négligeable des licences logicielles. En effet, quand on se lance dans un développement spécifique sur n'importe quel ERP, il faut compter :

Comme on le voit, la décision de réaliser un développement spécifique ne doit pas être prise à la légère, car cela demande des ressources importantes dans la durée. Néanmoins, dans le cas d'Odoo, cela fait partie de la méthode d'implémentation, dès que l'on s'adresse à des sociétés de taille moyenne et/ou à des sociétés qui ont des besoins qui sortent un peu du périmètre très basique des modules officiels. Heureusement, un certain nombre de projets communautaires ambitionnent de développer des verticalisations métier d'Odoo en publiant une série de modules permettant d'étendre le périmètre fonctionnel natif d'Odoo pour certains secteurs d'activité. Si vous avez la chance de faire partie de l'un de ces secteurs d'activité, alors cela devrait vous éviter d'avoir trop de développements spécifiques à réaliser.

C'est la raison pour laquelle il existe des initiatives pour développer des verticalisations métier d'Odoo pour certains secteurs d'activité. Ces verticalisations métier développent des modules pour couvrir les besoins d'un secteur d'activité donné ; ainsi, quand une entreprise de ce secteur d'activité veut déployer Odoo, elle bénéficiera d'un périmètre fonctionnel déjà large pour son métier et pourra financer certaines améliorations de la verticalisation métier et des développements spécifiques. Au contraire, si une entreprise a un métier spécifique avec des processus bien particuliers qui ne sont pas couverts par le modules actuellement disponible pour Odoo, elle devra financer de gros développements ; si son budget est trop limité, elle risque de limiter ces développements au strict minimum et de ne pas être satisfaite du résultat car elle estimera que son ERP n'est pas assez efficace et adapté pour son mode de fonctionnement.

Voilà un exemple de quelques verticalisations métier que je connais qui sont bien couvertes par Odoo :

Cette liste n'est pas exhaustive ; vous en trouverez d'autres en cherchant les projets OCA qui commencent par "vertical-".

Exemple d'un cas réel

Je publie ici la liste des modules utilisés par l'Abbaye du Barroux, qui utilise Odoo 8.0 en production depuis le 1er Janvier 2015. Cela permet de voir :

Je ferai ensuite une analyse sur la répartition du volume de code entre les modules officiels, les modules OCA, les modules communautaires non OCA et les modules spécifiques.

Nom du module Type de module Mainteneur Branche Nombre de patchs appliqués Nombre de lignes de code Fonctionnalités et commentaires
account officiel Odoo S.A. github/odoo/odoo 12 28 473 Le module de facturation et de comptabilité.
account_accountant officiel Odoo S.A. github/odoo/odoo 0 64 Mini-module qui permet à l'administrateur d'avoir accès à la comptabilité.
account_cancel officiel Odoo S.A. github/odoo/odoo 0 61 Module qui autorise l'annulation d'une facture en cas d'erreur
account_chart officiel Odoo S.A. github/odoo/odoo 0 35
account_payment officiel Odoo S.A. github/odoo/odoo 0 1 456 Module de gestion des paiements fournisseur
account_voucher officiel Odoo S.A. github/odoo/odoo 0 5 493 Ajoute une méthode de saisie des règlements client et fournisseur (plutôt que de saisir les écritures comptables directement dans le journal de banque)
analytic officiel Odoo S.A. github/odoo/odoo 0 422 Module pour la comptabilité analytique
auth_crypt officiel Odoo S.A. github/odoo/odoo 0 72 Module pour le stockage des mots de passe sous forme de hash
auth_signup officiel Odoo S.A. github/odoo/odoo 0 542 Module pour l'authentification et la ré-initialisation des mots de passe
base officiel Odoo S.A. github/odoo/odoo 1 27 723 Le module qui fournit les objets de base : utilisateurs, pays, monnaies, partenaires, ...
base_iban officiel Odoo S.A. github/odoo/odoo 0 179 Module pour la gestion des IBANs
base_import officiel Odoo S.A. github/odoo/odoo 0 1645 Module pour la gestion des imports de données
base_setup officiel Odoo S.A. github/odoo/odoo 0 411 Module qui enrichit les pages de configuration
base_vat officiel Odoo S.A. github/odoo/odoo 0 302 Module pour la gestion des numéros de TVA intra-communautaires
board officiel Odoo S.A. github/odoo/odoo 0 976 Module pour les tableaux de board
decimal_precision officiel Odoo S.A. github/odoo/odoo 0 166 Module pour la gestion de la précision décimale
delivery officiel Odoo S.A. github/odoo/odoo 0 1 065 Module de gestion des livraisons
document officiel Odoo S.A. github/odoo/odoo 0 2 663 Module de gestion des pièces jointes sur les objects de l'ERP.
edi officiel Odoo S.A. github/odoo/odoo 0 608 Module de support de l'EDI. Ce module est installé automatiquement par le jeu des dépendances.
email_template officiel Odoo S.A. github/odoo/odoo 0 1 543 Module qui permet de développer des templates de mail, qui sont ensuite envoyés lors d'une action particulière (validation d'une commande, validation d'une facture, etc...).
fetchmail officiel Odoo S.A. github/odoo/odoo 0 465 Module qui permet de télécharger les mails stockés sur un compte POP3/IMAP et de s'en servir comme point de départ d'un process ERP (exemple : mail envoyé à l'adresse rma@mycompany.com, qui va aboutir à la création d'un CRM claim). Ce module est installé automatiquement par dépendance lors de l'installation de la CRM. Il n'est pas utilisé dans ce déploiement.
knowledge officiel Odoo S.A. github/odoo/odoo 0 95 Module technique sans intérêt fonctionnel.
l10n_fr officiel Communauté française d'Odoo github/odoo/odoo 0 10 969 Contient la localisation française d'Odoo : plan comptable général, taxes, régimes fiscaux, etc... La définition du plan comptable général en XML représente 80% du code du module.
mail officiel Odoo S.A. github/odoo/odoo 0 9847 Module qui gère les mails et le chatter.
mrp officiel Odoo S.A. github/odoo/odoo 0 5 181 Module de gestion de la production
payment officiel Odoo S.A. github/odoo/odoo 0 639 Module de base pour la gestion des règlements
payment_transfer officiel Odoo S.A. github/odoo/odoo 0 135 Module non utilisé (installé automatiquement)
point_of_sale officiel Odoo S.A. github/odoo/odoo 10 15 466 Module pour la gestion de la caisse
procurement officiel Odoo S.A. github/odoo/odoo 0 657 Module pour la gestion des ré-approvisionnements
product officiel Odoo S.A. github/odoo/odoo 3 4 575 Module qui contient les objets correspondant aux produits et tous les objets annexes.
product_visible_discount officiel Odoo S.A. github/odoo/odoo 2 135 Permet de rendre le discount visible par le client sur le devis et la facture, plutôt que d'intégrer le discount dans le montant du prix unitaire (qui est le comportement par défaut d'Odoo).
purchase officiel Odoo S.A. github/odoo/odoo 7 5 216 Module de gestion des achats chez les fournisseurs.
purchase_double_validation officiel Odoo S.A. github/odoo/odoo 0 160 Module qui active la double validation des commandes fournisseurs.
report officiel Odoo S.A. github/odoo/odoo 0 1 106 Module technique pour les rapports Qweb, décrit dans la section de ce document dédiée aux Moteurs de rapport.
report_webkit officiel Camptocamp github/odoo/odoo 0 984 Module qui fournit le moteur de rapport Webkit, décrit dans la section de ce document dédiée aux Moteurs de rapport.
resource officiel Odoo S.A. github/odoo/odoo 0 4 555 Module qui gère la disponibilité d'une resource et son calendrier associé ainsi que ses absences.
sale officiel Odoo S.A. github/odoo/odoo 3 4 959 Module de gestion des ventes (devis, commandes client)
sale_mrp officiel Odoo S.A. github/odoo/odoo 0 362 Module technique de lien entre le module sale et le module mrp
sales_team officiel Odoo S.A. github/odoo/odoo 0 519 Module qui définit les équipes de vente
sale_stock officiel Odoo S.A. github/odoo/odoo 0 1 312 Module de lien entre le module sale et le module stock.
share officiel Odoo S.A. github/odoo/odoo 0 1 063 Module qui permet de partage certaines données de l'ERP avec des utilisateurs extérieurs à l'organisation. A désinstaller ?
stock officiel Odoo S.A. github/odoo/odoo 3 12 728 Module de gestion des stocks.
stock_account officiel Odoo S.A. github/odoo/odoo 0 1 367 Module de lien entre la gestion des stocks et la comptabilité.
stock_picking_wave officiel Odoo S.A. github/odoo/odoo 0 388 Module pour la gestion des courses dans l'entrepôt.
Modules Web officiel Odoo S.A. github/odoo/odoo 2 43 039 Modules techniques nécessaires pour le fonctionnement de l'interface Web d'Odoo : web, web_calendar, web_diagram, web_gantt, web_graph, web_kanban, web_kanban_gauge, web_kanban_sparkline, web_tests, web_view_editor. Je n'ai pas compté ces modules dans le décompte des lignes de code des modules fonctionnels.
Modules OCA
mass OCA Akretion & Barroux github/OCA/vertical-abbey 0 1 593 Module de gestion des messes
stay OCA Akretion & Barroux github/OCA/vertical-abbey 0 1 012 Module de gestion des séjours à l'abbaye
donation_stay OCA Akretion & Barroux github/OCA/vertical-abbey 0 175 Connexion entre le module de gestion des séjours et le module de gestion des dons
donation_mass OCA Akretion & Barroux github/OCA/vertical-abbey 0 271 Connexion entre le module de gestion des dons et le module de gestion des messes
donation OCA Akretion & Barroux github/OCA/donation 0 1 160 Module de gestion des dons
donation_bank_statement OCA Akretion & Barroux github/OCA/donation 0 221 Module de gestion des dons à partir des relevés de banque (pour les dons par virement)
donation_direct_debit OCA Akretion & Barroux github/OCA/donation 0 213 Module qui facilite la gestion des dons par prélèvement SEPA
donation_recurring OCA Akretion & Barroux github/OCA/donation 0 310 Module pour la gestion des dons récurrents
donation_tax_receipt OCA Akretion & Barroux github/OCA/donation 0 745 Module pour la gestion des reçus fiscaux
donation_recurring_tax_receipt OCA Akretion & Barroux github/OCA/donation 0 72 Connexion entre le module de gestion des dons récurrents et le module de gestion des reçus fiscaux
donation_thanks OCA Akretion & Barroux github/OCA/donation 0 76 Module pour les lettres de remerciements pour les dons
account_analytic_required OCA Akretion github/OCA/account-analytic 0 190 Permet d'obliger (ou d'empêcher) la saisie d'un compte analytique quand l'écriture comptable utilise certains comptes de comptabilité générale. Utile pour les sociétés qui utilisent systématiquement de l'analytique sur toutes leurs charges, ou sur tous leurs produits.
account_financial_report_webkit OCA Camptocamp github/OCA/account-financial-reporting 0 5 008 Contient les célèbres rapports financiers de Camptocamp. Ce module remplace les rapports financiers natifs d'Odoo.
account_financial_report_webkit_xls OCA Noviat github/OCA/account-financial-reporting 0 2 425 Ajoute l'export XLS sur les rapports financiers.
account_journal_report_xls OCA Noviat github/OCA/account-financial-reporting 0 1 293 Ajoute l'export XLS sur les journaux comptables.
account_move_line_report_xls OCA Noviat github/OCA/account-financial-reporting 0 501 Ajoute l'export XLS sur les écritures comptables.
account_auto_fy_sequence OCA Acsone github/OCA/account-financial-tools 0 169 Permet de mettre facilement l'année fiscale dans les séquences des journaux, et évite une intervention manuelle à chaque changement d'année fiscale.
account_check_deposit OCA Akretion github/OCA/account-financial-tools 0 588 Module pour la gestion des remises de chèque en banque.
account_fiscal_position_vat_check OCA Akretion github/OCA/account-financial-tools 0 116 Blocage en cas de tentative de validation d'une facture client intracommunautaire HT sans numéro de TVA sur la fiche client.
account_journal_always_check_date OCA Akretion github/OCA/account-financial-tools 0 33 Active automatiquement l'option de cohérence entre date et période comptable.
account_move_line_no_default_search OCA Therp github/OCA/account-financial-tools 0 38 Module qui désactive la sélection par défaut d'un journal et d'une période sur la vue des lignes comptables.
account_partner_required OCA Acsone github/OCA/account-financial-tools 0 193 Module qui rend le champ partenaire obligatoire pour certains types de comptes comptables.
account_reversal OCA Akretion github/OCA/account-financial-tools 0 277 Permet d'extourner facilement une écriture comptable sans saisie manuelle.
currency_rate_update OCA Camptocamp github/OCA/account-financial-tools 0 904 Permet l'import journalier des taux de change depuis une sélection de sites Internet.
account_invoice_merge OCA Elico Corp github/OCA/account-invoicing 0 293 Permet la fusion de factures.
account_payment_term_extension OCA Camptocamp github/OCA/account-invoicing 0 169 Permet notamment le décompte des échéances de paiement en mois et pas seulement en jours. Sans ce module, une facture datée du 30 Janvier et ayant des conditions de paiement à "30 jours fin de mois" aura un échéance au 31 Mars ; avec ce module et un paramétrage en mois, l'échéance sera le 28 Février.
invoice_fiscal_position_update OCA Julius et Akretion github/OCA/account-invoicing 0 63 Met à jour les lignes de facture lors d'un changement de la position fiscale.
account_banking_mandate OCA Akretion et Compassion CH github/OCA/bank-payment 0 458 Ajoute l'objet mandat de prélèvement.
account_banking_pain_base OCA Akretion et Noviat github/OCA/bank-payment 0 547 Module de base pour les virements et prélèvements SEPA.
account_banking_payment_export OCA Acsone et Therp github/OCA/bank-payment 0 640 Module de base pour les modules bancaires.
account_banking_payment_transfer OCA Multiples github/OCA/bank-payment 0 447 Génère des écritures comptables de transfert lors de la validation d'un virement ou d'un prélèvement.
account_banking_sepa_credit_transfer OCA Akretion github/OCA/bank-payment 0 456 Module pour les virements SEPA.
account_banking_sepa_direct_debit OCA Akretion github/OCA/bank-payment 0 947 Module pour les prélèvements SEPA.
account_direct_debit OCA Therp, Smile github/OCA/bank-payment 0 424 Module de base pour les prélèvements.
account_payment_partner OCA Akretion github/OCA/bank-payment 0 167 Module qui ajoute le mode de paiement sur la fiche partenaire
account_payment_purchase OCA Akretion github/OCA/bank-payment 0 88 Module qui gère le mode de paiement sur les commandes fournisseur
account_payment_sale OCA Akretion github/OCA/bank-payment 0 62 Module qui gère le mode de paiement sur les commandes client
account_payment_sale_stock OCA Akretion github/OCA/bank-payment 0 30 Module technique pour la gestion du mode de paiement sur les commandes client
connector OCA Camptocamp github/OCA/connector 5 591 Framework de base pour la synchronisation avec un logiciel externe
connector_base_product OCA Multiples github/OCA/connector 32 Ajoute les informations de synchronisation à la fiche article
connector_ecommerce OCA Camptocamp et Akretion github/OCA/connector-ecommerce 1 075 Ajoute les fonctions de base du e-commerce au dessus du module connector
sale_automatic_workflow OCA Camptocamp et Akretion github/OCA/e-commerce 454 Adapte le workflow de vente pour le e-commerce
sale_payment_method OCA Akretion github/OCA/e-commerce 361 Adapte le workflow de paiement pour le e-commerce
sale_payment_method_automatic_workflow OCA Camptocamp et Akretion github/OCA/e-commerce 219 Automatise le workflow de paiement pour le e-commerce
account_banking_fr_lcr OCA Akretion github/OCA/l10n-france 330 Génère les fichiers CFONB des LCRs
l10n_fr_base_location_geonames_import OCA Akretion (développé pour le Barroux) github/OCA/l10n-france 88 Adapte l'import automatique des villes et code postaux français depuis le site geonames
l10n_fr_department OCA GRAP et Akretion github/OCA/l10n-france 950 Ajoute le support des départements français
l10n_fr_siret OCA Numérigraphe github/OCA/l10n-france 143 Ajoute le SIREN et SIRET sur la fiche partenaire
l10n_fr_state OCA GRAP github/OCA/l10n-france 175 Ajoute les données des régions françaises (non utilisé, mais le module l10n_fr_department dépend de ce module
base_location OCA Camptocamp github/OCA/partner-contact 260 Permet la saisie rapide des codes postaux/villes/Etat/pays sur la fiche partenaire grâce à une base de données de ces informations
base_location_geonames_import OCA Akretion (développé pour le projet du Barroux) github/OCA/partner-contact 225 Permet de remplir la base de données des codes postaux/villes/Etat/pays par téléchargement à partir du site geonames.org
partner_address_street3 OCA Camptocamp github/OCA/partner-contact 131 Ajoute une 3e ligne d'adresse sur les partenaires
partner_firstname OCA Camptocamp github/OCA/partner-contact 303 Sépare le prénom du nom de famille sur la fiche partenaire
partner_helper OCA Akretion github/OCA/partner-contact 51 Module technique qui concerne le traitement des adresses
pos_customer_display OCA Akretion github/OCA/pos 352 Ajoute le support de l'afficheur LCD pour la caisse
pos_payment_terminal OCA Akretion github/OCA/pos 124 Ajoute le support du lecteur de carte et de l'imprimante de chèque pour la caisse
product_m2mcategories OCA Multiples github/OCA/product-attribute 44 Ajoute le support des catégories multiples sur les articles (pour le e-commerce)
purchase_partner_invoice_method OCA Akretion github/OCA/purchase-workflow 79 Permet la configuration de la méthode de facturation pour les commandes fournisseur sur la fiche fournisseur
report_xls OCA Noviat github/OCA/reporting-engines 297 Module technique pour l'export XLS sur les rapports comptables
base_report_to_printer OCA Multiples github/OCA/report-print-send 708 Module pour l'envoi automatique de documents à l'imprimante
sale_exceptions OCA Akretion github/OCA/sale-workflow 354 Module pour la gestion des cas particuliers sur les commandes de vente (module requis pour le e-commerce)
sale_partner_order_policy OCA Akretion github/OCA/sale-workflow 79 Permet la configuration de la méthode de facturation pour les commandes client sur la fiche client
base_optional_quick_create OCA Agile Business Group github/OCA/server-tools 68 Permet de pouvoir retirer la fonction quick create sur les modèles que l'on veut
cron_run_manually OCA Therp github/OCA/server-tools 103 Permet de lancer un tâche plannifiée à la main
disable_openerp_online OCA Therp github/OCA/server-tools 73 Désactive tous les liens vers openerp.com
stock_packaging_usability OCA Akretion (développé pour le projet du Barroux) github/OCA/stock-logistics-tracking 78 Facilite la gestion de l'attribution des colis sur les expéditions
stock_packaging_usability_ul OCA Akretion (développé pour le projet du Barroux) github/OCA/stock-logistics-tracking 112 Facilite la gestion de l'emballage sur les expéditions
stock_picking_invoice_link OCA Agile Business Group github/OCA/stock-logistics-workflow 140 Ajoute un lien entre les pickings et les factures
stock_transfer_split_multi OCA Akretion (développé dans le cadre du projet du Barroux) github/OCA/stock-logistics-workflow 98 Permet de diviser des lignes par N unités lors de la validation d'une picking
base_phone OCA Akretion (développé dans le cadre du projet du Barroux) github/OCA/connector-telephony 923 Module pour le formattage des numéros de téléphone
web_easy_switch_company OCA GRAP github/OCA/web 198 Permet de facilement passer d'une société à l'autre
web_sheet_full_width OCA Therp github/OCA/web 48 Elargit les écrans d'Odoo
account_bank_statement_import OCA Odoo S.A. github/OCA/bank-statement-import 371 Module de base pour l'import de fichiers de relevé bancaire
account_bank_statement_import_ofx OCA Odoo S.A. github/OCA/bank-statement-import 119 Module pour l'import de fichiers de relevé de banque au format OFX
account_statement_operation_multicompany OCA Akretion (développé pour le projet du Barroux) github/OCA/bank-statement-reconcile 61 Module pour corriger ce bug du module account officiel, que l'éditeur ne voulait pas corriger dans la branche stable car c'était contre ses règles d'intervention dans la branche stable
base_delivery_carrier_label OCA Camptocamp et Akretion github/OCA/carrier-delivery 457 Module de base pour la gestion des transporteurs
delivery_carrier_b2c OCA Akretion github/OCA/carrier-delivery 64 Mini-module qui enrichit la fiche partenaire avec des informations pour livrer chez des particuliers (code porte, etc...)
delivery_carrier_deposit OCA Akretion github/OCA/carrier-delivery 368 Module pour la gestion des enlèvements par les transporteurs
prestashoperpconnect OCA Akretion et d'autres intégrateurs github/OCA/connector-prestashop 0 5840 Module principal du connecteur Odoo-PrestaShop.
prestashoperpconnect_catalog_manager OCA Akretion et d'autres intégrateurs github/OCA/connector-prestashop 0 813 Module qui permet de gérer le catalogue produit dans Odoo et de le synchroniser vers PrestaShop (sans ce module, le catalogue produit est géré dans PrestaShop et synchronisé vers Odoo).
product_image OCA Akretion et d'autres intégrateurs github/OCA/product-attribute 0 175 Ajoute la gestion des images sur les fiches produit. Requis par le connecteur Odoo-PrestaShop.
intrastat_base OCA (PR en cours) Akretion github/OCA/account-financial-reporting 0 465 Module de base pour la DEB/DES.
intrastat_product OCA (PR en cours) Akretion github/OCA/account-financial-reporting 0 258 Module qui ajoute le codes douaniers sur les fiches articles.
l10n_fr_intrastat_product OCA (PR en cours) Akretion github/OCA/l10n-france 0 1 863 Module pour la DEB (Déclaration d'Echange de Biens) qui inclus la génération du fichier XML à déposer sur le site pro.douane.
Modules Communautaires (hors OCA)
l10n_be_account_bank_statement_import_bpost communautaire Akretion github.com/akretion/l10n-belgium 0 79 Importe les fichiers de relevé de compte de la Banque Postale belge (BPost) au format CSV.
report_aeroo communautaire Alistek github.com/aeroo/aeroo_reports 0 5 323 Fourni le moteur de rapport Aeroo, décrit en détail dans la section de ce document dédiée aux Moteurs de rapport.
account_statement_completion_label_simple communautaire Akretion (développé pour le projet du Barroux) github.com/akretion/bank-statement-reconcile-simple 0 147 Permet d'associer des extraits de labels de relevé de compte à des partenaires et permettre ainsi une reconnaissance automatique des partenaires récurrents lors de l'import des relevés de compte. Ce module est une alternative simple aux modules OCA du projet bank-statement-reconcile qui n'ont pas été portés en v8.
base_partner_one2many_phone communautaire Akretion Pas encore publié 0 164 Module pour avoir autant de numéros de téléphone que l'on veut sur une fiche partenaire (chaque numéro de téléphone étant ayant un type : Maison, Bureau, Mobile, etc...). Ce module n'a pas encore été publié (TODO : le publier)
delivery_carrier_file_document communautaire Akretion github.com/akretion/carrier-delivery-ak 0 35 Module technique qui fait le lien entre le module base_delivery_carrier_label et le module file_document.
delivery_carrier_colipostefr communautaire Akretion github.com/akretion/carrier-delivery-colipostefr 0 1159 Module de base pour la gestion des colis normaux avec La Poste, qui comprend la gestion des télé-transmissions.
delivery_carrier_label_colissimo communautaire Akretion github.com/akretion/carrier-delivery-colipostefr 0 373 Module pour la gestion des étiquettes d'expédition des colis avec La Poste.
cn23_aeroo communautaire Akretion (développé pour le projet du Barroux) github.com/akretion/cn23-aeroo 0 127 Contient un rapport CN23 (facture de douane des envois postaux) au format Aeroo.
connector_dev communautaire Akretion ??? github.com/akretion/connector-dev???? 0 78 Outils pour les développeurs qui travaillent sur le module connector.
connector_dev_delete_job communautaire Akretion ??? github.com/akretion/connector-dev???? 0 45 Permet de supprimer un job dans la queue de connector.
purchase_dilicom_csv communautaire Akretion github.com/akretion/dilicom 0 39 Mini-module qui édite un fichier CSV permettant de passer une commande sur l'extranet de Dilicom, qui est une plateforme qui fait le lien entre les librairies et les distributeurs de livres.
abstract_automatic_task communautaire Akretion github.com/akretion/file-exchange 0 180 Module technique utilisé pour la télétransmission des fichiers pour les colis expédiés par La Poste.
file_autotask_rel communautaire Akretion github.com/akretion/file-exchange 0 65 Module technique utilisé pour la télétransmission des fichiers pour les colis expédiés par La Poste.
file_document communautaire Akretion github.com/akretion/file-exchange 0 292 Module technique utilisé pour la télétransmission des fichiers pour les colis expédiés par La Poste.
file_repository communautaire Akretion github.com/akretion/file-exchange 0 529 Module technique utilisé pour la télétransmission des fichiers pour les colis expédiés par La Poste.
bank_statement_import_camt communautaire Akretion github.com/akretion/bank-statement-import-camt 0 119 Module pour l'import des relevés de compte au format CAMT .052 et .053. Ce module est une alternative au module OCA d'import des relevés de compte CAMT qui a l'époque ne gérait pas le format .052 et était trop lourd et trop gros.
partner_relation communautaire Akretion github.com/akretion/partner-contact 0 393 Module permettant d'établir des liens entre les partenaires. J'ai proposé ce module à l'OCA courant 2014, mais un autre intégrateur (Therp) a fait de même pour un module similaire appelé partner_relations et c'est ce dernier module qui a été accepté dans l'OCA, car son auteur a été plus rapide que moi à le re-proposer sur github suite à la migration de Launchpad vers Github. Il faudrait donc que je mette ce module sur un projet séparé, ce que je n'ai pas encore fait (ce serait trop compliqué à court terme de migrer sur le module OCA).
sale_tax_included_excluded communautaire Akretion github.com/akretion/sale-workflow 0 338 Module permettant de faire des ventes avec des prix HT (pour le marché B2B) et des ventes avec des prix TTC (pour le marché B2C). Je suis très fier de ce module car il traite cette problématique de façon relativement simple, alors que c'est un très vieux problème sur Odoo sur lequel plusieurs personnes avaient déjà planché et avaient élaboré d'autres solutions beaucoup plus compliquées. L'inconvénient de ce module est qu'il nécessite un patch sur les addons officiels car certains morceaux de code dans le module sale et le module product_visible_discount ne passent pas le context correctement ; j'ai fait une pull request pour corriger cela (ce qui éviterai d'avoir recours à un patch), mais elle n'a pas été acceptée pour le moment
account_fiscal_position_translate communautaire Akretion github.com/akretion/odoo-usability 0 20 Petit module qui permet d'afficher une phrase traduite sur la facture en fonction de la position fiscale.
account_invoice_picking_label communautaire Akretion github.com/akretion/odoo-usability 0 41 Petit module qui permet d'afficher les noms des pickings sur la facture
account_invoice_sale_link communautaire Akretion github.com/akretion/odoo-usability 0 41 Petit module qui ajoute le lien des factures vers les commandes, notamment pour pouvoir afficher le numéro de commande du client sur la facture
account_payment_hide_communication2 communautaire Akretion github.com/akretion/odoo-usability 0 29 Petit module qui masque un champ inutile sur les virements/prélèvements, pour éviter une confusion
account_usability communautaire Akretion github.com/akretion/odoo-usability 0 134 Petit module qui améliore la facilité d'utilisation de la comptabilité
base_fix_display_address communautaire Akretion github.com/akretion/odoo-usability 0 26 Petit module qui corrige un problème dans l'affichage des adresses dans les rapports
base_other_report_engines communautaire Akretion github.com/akretion/odoo-usability 0 21 Petit module qui corrige un problème qui empêche d'utiliser un moteur de rapport alternative dans un certain cas
base_partner_always_multi_contacts communautaire Akretion github.com/akretion/odoo-usability 0 32 Petit module qui permet d'avoir plusieurs contacts sur une fiche partenaire même si cette fiche n'est pas une société
base_usability communautaire Akretion github.com/akretion/odoo-usability 0 63 Petit module qui améliore la facilité d'utilisation du module de base
delivery_no_invoice_shipping communautaire Akretion github.com/akretion/odoo-usability 0 21 Petit module qui évite une double facturation des frais de port
eradicate_quick_create communautaire Akretion github.com/akretion/odoo-usability 0 25 Petit module qui supprime le quick create partout dans Odoo
mrp_usability communautaire Akretion github.com/akretion/odoo-usability 0 18 Petit module qui améliore la facilité d'utilisation de la gestion de production
partner_products_shortcut communautaire Akretion github.com/akretion/odoo-usability 0 80 Petit module qui permet d'accéder rapidement aux produits vendus par un fournisseur depuis sa fiche
pos_journal_sequence communautaire Akretion github.com/akretion/odoo-usability 0 46 Petit module qui permet de contrôler l'ordre des méthodes de paiement dans le point de vente. Cette fonctionnalité a été intégrée en standard dans Odoo v9 suite à mon initiative.
pos_sale_report communautaire Akretion github.com/akretion/odoo-usability 0 109 Petit module qui permet d'avoir un rapport avec la somme des produits vendus par le point de vente et par les devis/commandes.
procurement_usability communautaire Akretion github.com/akretion/odoo-usability 0 66 Petit module qui améliore la facilité d'utilisation des procurements
product_manager_group communautaire Akretion github.com/akretion/odoo-usability 0 25 Petit module qui restaure le groupe Product Manager, qui existait à une époque dans Odoo et qui a malheureusement été supprimé
product_manager_group_stock communautaire Akretion github.com/akretion/odoo-usability 0 15 Petit module technique
product_no_translation communautaire Akretion github.com/akretion/odoo-usability 0 37 Petit module qui rend les articles (et d'autres objets associés) non traduisibles, ce qui simplifie les choses pour les entreprises qui ne sont pas en multi-langue
product_variant_csv_import communautaire Akretion github.com/akretion/odoo-usability 0 31 Petit module qui débloque l'import de modèles d'articles par fichiers CSV
purchase_auto_invoice_method communautaire Akretion github.com/akretion/odoo-usability 0 49 Petit module qui permet de facturer systématiquement depuis les réceptions, sauf quand la commande ne contient que du service, de façon automatisée
purchase_suggest communautaire Akretion github.com/akretion/odoo-usability 0 464 Module qui change le comportement d'Odoo pour les ré-approvisionnements : au lieu de créer des bons de commande brouillon (ce qui est très intrusif et pas toujours adapté), les règles de stock minimum vont créer des alertes, que l'acheteur pourra facilement transformer en bon de commande.
purchase_usability_extension communautaire Akretion github.com/akretion/odoo-usability 0 86 Petit module qui améliore la facilité d'utilisation des achats
sale_stock_show_delivery_address communautaire Akretion github.com/akretion/odoo-usability 0 44 Petit module qui permet d'afficher l'adresse complète sur les bons de livraison, au lieu d'afficher seulement le nom du destinataire.
sale_usability_extension communautaire Akretion github.com/akretion/odoo-usability 0 81 Petit module qui améliore la facilité d'utilisation des ventes
stock_display_destination_move communautaire Akretion github.com/akretion/odoo-usability 0 49 Petit module qui affiche le champ move_dest_id qui est important dans la gestion des stocks d'Odoo et qui est masqué par défaut.
stock_display_sale_id communautaire Akretion github.com/akretion/odoo-usability 0 29 Petit module qui affiche le champ sale_id sur les bons de livraison, ce qui permet de revenir facielement à la commande depuis le bon de livraison.
stock_usability communautaire Akretion github.com/akretion/odoo-usability 0 171 Petit module qui améliore la facilité d'utilisation de la gestion des stocks.
Modules spécifiques
barroux_account spécifique Barroux et Akretion Branche interne 0 537 Module contenant les développements spécifiques sur la comptabilité et la partie bancaire.
barroux_base spécifique Barroux et Akretion Branche interne 0 949 Module contenant les développements spécifiques sur le module de base.
barroux_donation spécifique Barroux et Akretion Branche interne 0 243 Module contenant les développements spécifiques pour la gestion des dons.
barroux_mrp spécifique Barroux et Akretion Branche interne 0 35 Module contenant les développements spécifiques pour la gestion de production.
barroux_pos spécifique Barroux et Akretion Branche interne 0 183 Module contenant les développements spécifiques pour le point de vente.
barroux_product spécifique Barroux et Akretion Branche interne 0 592 Module contenant les développements spécifiques pour enrichir les articles.
barroux_profile spécifique Barroux et Akretion Branche interne 0 39 Module qui chapeaute tous les autres modules.
barroux_purchase spécifique Barroux et Akretion Branche interne 0 253 Module contenant les développements spécifiques pour la gestion des achats.
barroux_sale spécifique Barroux et Akretion Branche interne 0 404 Module contenant les développements spécifiques pour la gestion des ventes.
barroux_stay spécifique Barroux et Akretion Branche interne 0 98 Module contenant les développements spécifiques pour la gestion des séjours.
barroux_stock spécifique Barroux et Akretion Branche interne 0 1 126 Module contenant les développements spécifiques pour la gestion des stocks.

Pour compter les lignes de code des modules, j'ai utilisé le module base_module_code_stats que j'ai développé pour l'occasion et qui est publié sur la branche github/akretion/odoo-module-stats. Pour compter les lignes de code, ce module utilise le programme cloc avec la ligne de commande suivante : cloc --exclude-dir=lib --skip-uniqueness --exclude-ext=xsd --not-match-f="__openerp__.py|index.html". Pour compter les patchs appliqués sur les modules, j'ai simplement compté les blocs de diff ; pour une modification (ou un correctif), il peut donc y avoir blocs de diff. Pour être précis, le titre de la colonne devrait être Nombre de blocs de diff, mais ce n'est pas un terme très compréhensible.

Voici la répartition du nombre de lignes de code entre les différents modules fonctionnels (je ne compte pas les modules qui font l'interface Web, qui sont les modules qui commencent par le préfixe web_) selon le type de module : officiel, OCA, communautaire ou spécifique :

Type de module Nombre de lignes de code Pourcentage du total
Officiels (hors modules web) 156 782 71 %
OCA (hors modules web) 47 494 22 %
Communautaires 11 836 5 %
Spécifiques 4 459 2 %
Total 220 571 100 %

Quels enseignements tirer de cette liste ?

Je profite de cette section où le nombre de lignes de code des modules fonctionnels a été analysé pour faire l'analyse globale du nombre de lignes de code d'Odoo :

Composant Nombre de lignes de code Pourcentage du total Méthode de comptage
Server 27 872 9 % Module base exclus car compté dans les modules fonctionnels
Interface Web 43 285 15 % Tous les modules préfixés par web (officiels et OCA)
Modules fonctionnels 220 571 76 % Tous les autres modules du tableau ci-dessus
Total 291 728 100 %

La maturité d'Odoo

Odoo est-il un ERP mature ? C'est un peu la question qui tue... mais je vais essayer d'y répondre de façon objective, en me basant sur les bugs que j'ai personnellement constaté sur Odoo 7.0 depuis sa release en Décembre 2012. A mon sens, la meilleure façon de se rendre compte de la maturité d'un projet est d'analyser les bugs qu'on rencontre : si le projet est mature, les bugs rencontrés seront rares et se produiront dans des scénarios particuliers et a priori peu répandus ; à l'inverse, si l'on rencontre des bugs dans des scénarios basiques et standards, alors on ne peut pas affirmer que le logiciel est mature.

Domaine fonctionnel concerné Conditions particulières pour être concerné par le bug Résumé du scénario du bug Lien vers le bug report Date du bug report Date de disponibilité du fix Auteur du fix Date d'intégration du fix dans la branche stable
Procurements Avoir produits fabriqués en interne avec des règles de ré-approvisionnement Les dates panifiées des ordres de fabrication sont fausses. Bug 1269528 15 Janvier 2014 pas encore disponible - -
Comptabilité Avoir une condition de paiement avec plusieurs échéances Après enregistrement d'un premier paiement partiel, le montant restant à payer calculé par Odoo est faux. Bug 1263106 20 Décembre 2013 pas encore disponible - -
Achats Avoir renseigné un code produit et/ou un nom de produit et/ou un prix spécifique au fournisseur du produit Odoo ne tient pas compte du code produit et/ou du nom de produit et/ou du prix spécifique au fournisseur si le bon de commande est relié à un contact chez le fournisseur qui n'est pas le même que le contact fournisseur renseigné sur la fiche produit. Ce bug est une des conséquences non encore corrigées du fiasco lié au changement du modèle de donnée des partenaires dans Odoo 7.0. Bug 1246116 29 Octobre 2013 29 Octobre 2013 (workaround) Moi-même -
Achats Avoir une unité de mesure à l'achat différent de l'unité de mesure par défaut du produit (par exemple : l'unité de mesure à l'achat est le kilo alors que l'unité de mesure par défaut est le gramme). Si le prix est issu d'un prix spécifique au fournisseur du produit, Odoo se trompe dans le calcul du prix sur la ligne du bon de commande fournisseur. Bug 1220241 3 Septembre 2013 3 Septembre 2013 Moi-même en attente
Stocks Avoir une unité de mesure à l'achat différent de l'unité de mesure par défaut du produit (par exemple : l'unité de mesure à l'achat est le kilo alors que l'unité de mesure par défaut est le gramme) et faire de la tracabilité par lots. Odoo se trompe dans le calcul de la quantité de produit disponible pour un lot donné à cause des unités de mesures différentes. Ce bug et le précédent montrent qu'Odoo 7.0 ne sait pas gérer correctement un produit avec plusieurs unités de mesure. Bug 1229271 23 Septembre 2013 - - -

Pour compléter cette liste, j'ai obtenu l'autorisation de certains de mes clients de mettre en partage leur document de suivi des bugs Odoo qui les impactent :

Au vu des bugs que je rencontre, mon avis est qu'Odoo ne peut pas être considéré aujourd'hui comme un logiciel mature. Je le considère plutôt comme un logiciel en cours de maturation.

Les exemples de bugs que j'ai détaillés ci-dessus peuvent sembler effrayants pour une personne novice sur Odoo. Elle est effectivement effrayante, il ne faut pas se cacher la réalité. Mais il faut aussi souligner que, pour la plupart d'entre-eux, ils sont faciles à patcher pour un développeur Python de niveau moyen avec une bonne expérience du framework d'Odoo. Personnellement, je ne suis pas un développeur Python très expérimenté, loin de là, et je me suis mis à coder dans le framework d'Odoo seulement depuis fin 2010, et j'ai pu patcher une partie des bugs exposés ci-dessus moi-même. Cela demande de la patience et ça prend du temps, mais c'est tout à fait abordable.

En fait, ce manque de maturité d'Odoo a pour moi plusieurs conséquences concrètes :

Dans les release notes d'Odoo 7.0, l'éditeur a promis que les bugfix sur Odoo 7.0 seront mergés dans la branche stable d'Odoo dans un délai court. Extrait des release notes, section 7.2 Maintenance : "We realize that up to now Odoo was sending within a few days a patch to the customer or partner, but was taking time to merge it into the latest stable version of Odoo. We have reinforced the support team to ensure that the patches will be merged promptly. This reactivity process is more demanding on us, but will allow us to provide superior customer satisfaction."

Les intégrateurs de la communauté sont les premiers impactés par ce problème :

A l'époque d'Odoo 6.1, plusieurs intégrateurs, notamment Therp, Camptocamp et Akretion, avaient mis en place leurs propres branches stables avec des correctifs en plus par rapport à la branche officielle et utilisaient ces branches chez leurs clients en lieu et place des branches officielles. Pour Odoo 7.0, ces intégrateurs ont décidé d'unir leurs efforts et de développer une branche stable commune, dénommées Odoo Community Branches, alias OCB. Cette branche est devenue un projet de l'OCA ; elle est disponible sur le projet Github OCB.

Cette initiative a été annoncée par Stefan Rijnhart de Therp le 8 Février 2013 dans ce post sur la mailing-list openerp-community. Le mail d'annonce détaille les règles de fonctionnement de ces branches, qui peuvent se résumer ainsi :

Cette initiative a tout de suite reçu un très bon accueil de la communauté. De nombreux intégrateurs utilisent désormais les branches OCB en production chez leurs clients en lieu et place des branches stables officielles. Même si cela peut sembler un peu triste d'en être arrivé là, cette initiative montre que la communauté Odoo sait désormais s'organiser par elle-même et trouver des solutions concrètes à un certain nombre de problèmes, sans tout attendre de l'éditeur.

Il est intéressant de constater que l'éditeur est aujourd'hui beaucoup plus réactif qu'à l'époque d'Odoo 6.1 pour appliquer les correctifs dans les branches stables. Il faut dire que la mise en place des branches OCB a renforcé la pression sur l'éditeur pour qu'il applique les correctifs sur les branches stables officielles : en effet, si l'éditeur veut que ses branches stables continuent d'être les branches de référence pour la communauté Odoo, il se doit d'être réactif sur l'application des correctifs, sinon toute la communauté se mettra à utiliser les branches OCB à la place de ses branches stables. D'ailleurs, l'adoption des branches OCB par la communauté Odoo est tellement importante que cela a attiré l'attention de l'éditeur : par exemple, Fabien Pinckaers n'a pas hésité à critiquer les branches OCB dans ce mail sur la mailing-liste openerp-community en utilisant de faux arguments, ce qui a été immédiatement dénnoncé comme du FUD dans cette réponse de Stefan Rijnhart (si le terme FUD ne vous est pas familier, lisez l'article sur Wikipedia).

La comptabilité avec Odoo

Est-il envisageable de tenir la comptabilité de son entreprise dans Odoo ? Avec quel résultat ? Telle est la question à laquelle je vais essayer d'apporter certains éléments de réponse.

Les 2 scénarios

Si vous demandez à une entreprise "Est-ce que vous utilisez la comptabilité d'Odoo ?" et qu'elle vous répond Oui... vous n'avez qu'une partie de la réponse. En effet, il faut bien distinguer deux types d'utilisation de la comptabilité :

Ces deux scénarios sont en réalité très différents :

Les conséquences de cette confusion des scénarios sont les suivantes :

Comment utiliser la comptabilité d'Odoo ?

Dans cette section et les sections suivantes, je n'aborderai que le scénario n°2, où Odoo constitue le référentiel comptable de la société.

La façon dont la majorité de mes clients utilise le scénario 2 est schématisée ci-dessous :

Schéma d'utilisation de la comptabilité d'Odoo

Si la comptabilité est effectivement tenue intégralement dans Odoo, cela ne veut pas dire qu'Odoo fait tout ! La paye est toujours gérée dans un logiciel dédié, et l'écriture comptable mensuelle de paye est exportée du logiciel de paye sous forme d'un fichier CSV puis importée dans Odoo, en utilisant le module account_move_csv_import que j'ai développé. Depuis Odoo 6.0, il existe un module pour faire la paye dans Odoo, dénommé hr_payroll, mais nous n'en sommes qu'au tout début de la paye dans Odoo et je ne connais encore aucune entreprise qui l'utilise en production.

Souvent, les immobilisations sont également gérées dans un logiciel dédié (souvent un logiciel Windows propriétaire), et l'écriture comptable qu'il génère au format CSV est ensuite importée dans Odoo. Mais, depuis Odoo 6.1, le module de gestion des immobilisations account_asset est devenu un module officiel. Et, à partir d'Odoo 7.0, il existe un module OCA qui dérive du module officiel de l'éditeur (c'est une sorte de fork du module de l'éditeur) qui est disponible dans la branche account-financial-tools sous le nom account_asset_management. Ce module est complété par le module account_asset_management_xls développé par Noviat et disponible dans la même branche, qui ajoute un rapport Excel sur les immobilisations pour un exercice donné. Le module communautaire est plus riche fonctionnellement que le module officiel, ce qui se ressent sur le nombre de lignes de code : 3261 pour le module OCA vs 1225 pour le module officiel. J'ai commencé à utiliser le module OCA de gestion des immobilisations pour ma comptabilité personnelle pour mon exercice 2014-2015, et j'ai été très satisfait du module : le module marche bien, il est assez simple à paramétrer et à utiliser et couvre tous les scénarios dont j'ai besoin. Petit détail très pratique : quand on saisit une facture fournisseur, dès qu'on indique un compte d'immobilisation sur une ligne de facture (et que ce compte d'immobilisation est configuré sur une catégorie d'immobilisation), le système propose automatiquement la bonne catégorie d'immobilisation et l'immobilisation sera créée automatiquement en mode brouillon lors de la validation de la facture fournisseur, et la quasi-totalité des paramètres sont déjà configurés : le nom de l'immobilisation, sa date de début, sa durée, les comptes comptables de dépréciation, etc... Il n'y a plus qu'à vérifier la configuration de l'immobilisation, la modifier si nécessaire et confirmer l'immobilisation. On peut ensuite générer l'écriture d'amortissement de l'exercice en un clic. Je pense que ce module conviendra à la grande majorité des PMEs qui n'ont pas des besoins extra-ordinaires au niveau de la gestion des immobilisations. Un des gros client d'Akretion qui tient sa comptabilité dans Odoo utilise d'ailleurs le module OCA de gestion des immmobilisations en production.

En ce qui concerne la liasse fiscale, on entend parfois dire "On ne peut pas utiliser la comptabilité d'Odoo en France car Odoo ne sait pas générer les liasses fiscales". Cela est évidemment faux, et les personnes qui affirment cela ne connaissent généralement pas bien les méthodes de travail et les outils habituels des comptables. En réalité, la liasse fiscale est très souvent gérée dans un logiciel dédié, qu'il faut mettre à jour (comprendre "repayer") chaque année car la liasse fiscale change chaque année. Les éditeurs de logiciels de liasse fiscale sont tous également éditeurs de logiciels de comptabilité, et font en sorte de donner l'illusion que les deux logiciels sont intégrés... alors que ce sont en réalité deux logiciels séparés qui communiquent par un fichier texte ou assimilé. Les logiciels de liasse fiscale sont a priori toujours utilisables indépendamment du logiciel de comptabilité du même éditeur. Pour commencer à l'utiliser, il faut importer dans le logiciel de liasse fiscale la balance comptable en date du dernier jour de l'exercice fiscal.

Les logiciels de liasse fiscale les plus connus sont des logiciels propriétaires pour Windows ; on peut citer par exemple :

Les prix commencent à 300/400 euros HT pour les versions mono-société, et jusqu'à 600/900 euros HT pour les versions multi-société jusqu'à 10 sociétés. Mais attention, le logiciel de liasse fiscale ne suffit pas ; toutes les entreprises soumises à l'IS ont également l'obligation de télé-déclarer leur liasse fiscale depuis le 1er Mai 2013, et pour cela ils doivent passer par un prestataire agréé pour la télé-déclaration de la liasse fiscale. Les éditeurs de logiciels de liasse fiscale proposent aussi leurs services de télé-déclaration de la liasse... mais c'est généralement une option ! Et oui, il n'y a pas de petits profits ! Par exemple, chez Ciel, cette option s'appelle Ciel directDéclaration Fiscal et coûte 49 € HT / an / SIRET.

Comme le logiciel de liasse fiscale est un logiciel qu'il faut mettre à jour chaque année car la liasse fiscale change chaque année, il est pertinent de s'intéresser aux logiciels de liasse fiscale en mode SaaS. L'administration fiscale répertorie une liste de solutions de liasse fiscale en mode SaaS avec interface Web ; cf ce document. Pour les besoins d'Akretion France, nous avons choisi Teledec.fr pour établir et télétransmettre notre liasse fiscale ; c'est une solution que nous recommandons car les tarifs sont compétitifs par rapport à la concurrence, l'interface est simple et ergonomique et nous n'avons pas eu de bugs lors de l'utilisation. Pour réaliser le transfert de la balance d'Odoo vers Teledec.fr, nous avons utilisé l'astuce suivante : j'ai développé un petit module Odoo dénommé account_balance_ebp_csv_export (disponible dans la localisation française d'Odoo pour Odoo 7.0, et bientôt pour la version 8.0 également) qui permet d'exporter d'Odoo la liasse fiscale au format EBP Compta ; et comme Teledec.fr sait importer la liasse fiscale au format EBP Compta, la balance peut s'importer en quelques clics sans aucune re-saisie. Le seul manque au niveau de la solution Teledec.fr est qu'il n'est pas possible pour le moment d'éditer une plaquette des comptes ; j'ai questionné Teledec.fr à ce sujet fin Mai 2015 et l'éditeur m'a répondu quelques jours plus tard qu'il réfléchissait à l'ajout de cette nouvelle fonctionnalité, mais qu'aucune décision n'avait encore été prise.

Je profite de ces explications sur les liasses fiscales pour contre-dire une autre légende urbaine qu'on entend régulièrement : "On n'a pas le droit d'utiliser la comptabilité d'Odoo en France car Odoo n'est pas certifié par la DGI (Direction Générale des Impôts)". Cela est faux. Un logiciel comptable n'a pas besoin d'être certifié par la DGI pour être utilisé en France. Vous pouvez tenir votre comptabilité avec l'outil de votre choix. Si vous voulez la tenir dans un cahier Clairefontaine, il n'y a pas besoin de demander à Clairefontaine si ce modèle de cahier est certifié par la DGI ! Tout comme un logiciel de paye n'a pas à être certifié par l'URSSAF pour être utilisé en France. Cela ne veut pas dire que vous pouvez tenir votre comptabilité comme vous voulez ; quel que soit l'outil que vous utilisez, il faut respecter les lois et les textes officiels qui stipulent comment une comptabilité doit être tenue. Par contre, le logiciel de liasse fiscale doit effectivement être conforme aux spécifications de la DGI, et il existe une procédure officielle de certification pour la télé-déclaration. Cela peut se comprendre, puisque la liasse fiscale est un document officiel conçu par la DGI et les logiciels qui l'implémentent doivent respecter parfaitement son format, tout comme le protocole de sa télé-transmission pour éviter des problèmes d'inter-opérabilité avec les serveurs de l'administration fiscale. A ce sujet, je vous conseille la lecture de ce post du blog d'Aurélien Dumaine, qui détaille le format utilisé et la procédure de certification par l'administration fiscale. Dans son blog, Aurélien dénonce à juste titre la barrière à l'entrée que constitue la procédure de certification pour la télé-déclaration de la liasse : la loi impose à toutes les entreprises soumises à l'IS de télé-déclarer leur liasse fiscale, mais seuls des services payants d'éditeurs de logiciels permettent aux entreprises de télé-déclarer leur liasse fiscale... par conséquent, les entreprises sont obligées de payer pour pouvoir télé-déclarer leur liasse fiscale !

Au final, est-ce vraiment utilisable ?

La comptabilité d'Odoo est utilisable, à plusieurs conditions :

Ensuite, votre niveau de satisfaction à l'utilisation de la comptabilité dans Odoo dépendra notamment de :

Pour conclure ce chapitre sur la comptabilité, voilà l'architecture et les choix logiciels que je recommande :

Schéma que je recommande pour l'utilisation de la comptabilité d'Odoo

Si vous envisagez de déployer Odoo dans votre entreprise : conseils et questions fréquentes

Quel intégrateur choisir ?

Comme je l'ai indiqué dans la section l'expérience Odoo de l'auteur, je travaille chez Akretion, qui est un intégrateur Odoo. Mes conseils sur le choix d'un intégrateur ne sont donc probablement pas parfaitement objectifs !

Voilà en vrac quelques conseils pour bien choisir son intégrateur Odoo :

Choisir Odoo, est-ce un choix pérenne ?

Beaucoup de décideurs ont peur de choisir un logiciel libre parce qu'ils pensent que ce n'est pas un choix pérenne. Ils se disent "certes, les ERPs propriétaires abusent parfois au niveau des tarifs, mais au moins ce sont des sociétés riches qui ne vont pas faire faillite du jour au lendemain !" Alors qu'un éditeur de logiciel libre, qui n'a aucun revenu de licences...

Effectivement, il est assez rare qu'un éditeur d'ERP propriétaire ayant une bonne part de marché fasse faillite. En réalité, le facteur limitant de la durée de vie d'un ERP propriétaire n'est pas la faillite de son éditeur mais son rachat par un autre éditeur d'ERP plus riche que lui ! Bien souvent, au moment du rachat, l'éditeur qui a réalisé l'acquisition s'empresse d'annoncer que l'ERP racheté continuera d'être maintenu, histoire de rassurer les clients. Mais, après quelques années, la logique économique l'incite à arrêter de développer activement deux bases de code pour deux ERPs qui remplissement les mêmes fonctions. Il va alors arrêter de maintenir une des deux bases de code et inciter/forcer les clients à migrer vers l'autre base de code. Les clients équipés de l'ERP abandonné vont donc devoir changer d'ERP, et dépenser des fortunes pour refaire tous les développements spécifiques et tout le travail d'intégration !

C'est par exemple le cas d'Amaris, un ERP spécialisé pour l'industrie, racheté par Cegid en 1997, cf la page Wikipedia de Cegid, rubrique La croissance externe comme levier de développement. Cegid a repris toute l'équipe de développeurs d'Amaris, avec comme objectif de redévelopper les fonctionnalités proposées par Amaris pour l'industrie dans l'offre ERP principale de Cegid. Dès que la nouvelle implémentation a été finalisée, elle a été commercialisée auprès des anciens clients d'Amaris, avec un positionnement plus haut de gamme qu'auparavant (comprendre : des tarifs plus élevés). Certains clients ont suivi et ont dû assumer la hausse du coût des licences. D'autres clients n'ont pas voulu suivre, et ont préféré rester sur la base de code d'Amaris, qui n'évolue plus. Cela n'est pas sans poser certains problèmes : par exemple, le logiciel client de la solution Amaris ne fonctionne pas sous Windows 7. Les exemples de ce type sont nombreux ; l'exemple que je cite est un peu vieux... mais quand on voit la longue liste des acquisitions de CEGID telle que présentée sur leur page Wikipedia (24 acquisitions), on se doute que le scénario s'est répété à de nombreuses reprises. Le groupe Sage, un des principaux concurrents de CEGID, a aussi réalisé de très nombreuses acquisitions d'ERPs propriétaires concurrents, cf la page Wikipedia de Sage, rubrique Principales acquisitions de Sage Group (14 acquisitions) et Acquisitions de Sage en France (12 acquisitions).

Avec un ERP libre, l'éditeur peut effectivement faire faillite ou se faire racheter. Si cet évènement entraîne l'abandon de la base de code par l'éditeur, la communauté a la possibilité de continuer le travail en reprenant à son compte le maintien et l'amélioration de la base de code : c'est un des gros avantages des logiciels libres par rapport aux logiciels propriétaires. Pour que cela soit possible, il faut que les développeurs de la communauté soient suffisamment nombreux et aient une connaissance en profondeur du code, et pas seulement de certaines couches "hautes". On peut clairement dire que c'est le cas aujourd'hui de la communauté Odoo.

Vais-je faire des économies en choisissant Odoo plutôt qu'un ERP propriétaire ?

La deuxième question qui tue ! Je vais tout de même essayer d'apporter quelques éléments de réponse.

Le profil de société idéal pour un déploiement Odoo est le suivant :

Si votre société possède une ou plusieurs des caractéristiques listées ci-dessus, il est probable que vous ferez des économies substentielles en choisissant Odoo plutôt qu'un ERP propriétaire.

D'une manière générale, en supposant qu'il n'existe pas de solution adaptée à votre métier et disponible out-of-the-box sans besoin de développements spécifiques dans le monde propriétaire, le choix d'Odoo ne vous fera probablement pas réaliser d'économies sur le court terme (i.e. la première année, celle du déploiement), car l'argent économisé pour l'achat des licences logicielles devra être investi dans le développements de modules Odoo pour élargir le périmètre fonctionnel natif d'Odoo.

Etant donné que les ERPs propriétaires sont pricés par utilisateur (ou par utilisateur simultané), plus la société compte d'employés, plus les économies réalisées sur les licences logicielles seront importantes. Mais, d'une manière générale, plus la société est grosse, plus ses besoins fonctionnels sont larges et complexes, et donc plus le coût des développements nécessaires pour pallier les limitations fonctionnelles d'Odoo sera important.

Mais, sur le moyen/long terme, Odoo devrait se révéler plus économique. Cette source d'économie n'est pas spécifique à Odoo mais à l'utilisation d'un logiciel libre :

Dans tous les cas, sauf pour de très petites entreprises aux besoins très standards, il est conseillé de prévoir un budget significatif pour la phase de déploiement d'Odoo car, comme expliqué dans la section les modules officiels : le minimum dans chaque domaine, on ne fait pas énormément de choses avec un Odoo out-of-the-box.

Le mot de la fin

Pour ceux qui n'ont pas encore d'expérience avec Odoo et qui étudient l'opportunité de l'adopter, j'espère, à travers ce document, avoir pu éclaircir leur lanterne d'une lueur différente de celle du discours marketo-idéaliste ambiant. Quand j'étais en position de faire le choix d'un ERP pour Anevia, j'étais à la recherche de ce genre de témoignage, mais ils sont particulièrement difficiles à trouver. J'avais eu la chance d'avoir été mis en relation à ce moment là avec Raphaël Valyi, qui m'avait tenu un discours de vérité, et qui m'avait permis de faire un choix éclairé loin des mensonges et des exagérations commerciales.

En conclusion, en caricaturant un peu, je dirai qu'Odoo est un paradis pour les développeurs et un enfer pour les experts fonctionnels. En effet, le développeur pourra tirer parti d'un code source relativement simple, lisible et concis et d'un bon framework reposant sur des outils reconnus et de qualité (PostgreSQL, Python, ...). A l'inverse, l'expert fonctionnel qui n'a pas de compétences de programmation restera sur sa faim à cause du faible périmètre fonctionnel d'Odoo et pourra être agacé de rencontrer un peu trop souvent des bugs qu'il ne saura pas corriger, et il sera toujours en attente du travail de son collègue développeur pour lui corriger les bugs et lui développer de nouvelles fonctionnalités !

Il faut aussi souligner que, si je parle dans ce document de certains défauts d'Odoo qui peuvent sembler effrayants pour une personne qui envisage de déployer Odoo (je pense notamment au manque de maturité et aux exemples de bugs que j'ai cités), les autres ERPs propriétaires du marché ont aussi leurs défauts et leurs points noirs. La différence, c'est qu'avec Odoo vous avez la liberté : la liberté de corriger vous-même les bugs (vous en rêviez, n'est-ce pas ?), la liberté d'améliorer les modules fonctionnels, de modifier leur comportement natif, de personnaliser votre ERP autant que vous le voulez, etc... Cette liberté est précieuse car elle vous permet de vous approprier votre ERP et d'en (re)prendre le contrôle. Mais pour cela, il faut s'intéresser de près aux aspects techniques et ne pas hésiter à collaborer avec l'éditeur et la communauté Odoo. C'est la raison pour laquelle il me semble préférable d'avoir déjà une ou plusieurs expériences de déploiements réussis avec d'autres logiciels libres dans votre entreprise avant de vous lancer dans un déploiement d'Odoo.

N'hésitez pas à m'envoyer vos commentaires par mail pour me faire part de votre propre expérience et/ou de votre opinion sur ce document. Si vous trouvez une erreur ou une faute d'orthographe, je suis aussi preneur !

XHTML 1.1 et CSS valides. Lien vers sites partenaires : Appartement Miluni.