Promouvoir et soutenir le logiciel libre

Expérience de déploiements Odoo (ex-OpenERP) dans des entreprises françaises

Auteur : Alexis de Lattre <alexis _arobase_ via.ecp.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 http://people.via.ecp.fr/~alexis/openerp/

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

Note : dans la suite de ce document, j'utilise l'ancienne marque OpenERP pour désigner le logiciel qui s'appelle maintenant Odoo.

Introduction

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

Une des limitations de ce retour d'expérience est que vous n'y trouverez pas un comparatif entre OpenERP et d'autres ERPs du marché ; en effet, comme je n'ai jamais déployé d'autres ERPs qu'OpenERP, 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 OpenERP.

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'OpenERP 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'OpenERP avec l'arrivée des branches OCB (OpenERP Community Branches). Mention du fiasco de la gestion des contacts dans OpenERP 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'OpenERP avec un lien vers le suivi des bugs d'un autre de mes clients. Mise à jour de la partie Comment utiliser la comptabilité d'OpenERP ? à 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 OpenERP 8.0 et les moteurs de rapport.
2014-06-05 Mise à jour sur l'actualité récente d'OpenERP/Odoo.
2015-08-11 Grosse mise à jour avec toute l'actualité 2014/2015 et un retour d'expérience actualisé avec la v8.

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.

Je suis l'auteur ou co-auteur de deux autres documents sur le logiciel libre :

Aujourd'hui, je m'intéresse principalement à l'utilisation des logiciels libres dans les entreprises. J'ai d'ailleurs déjà témoigné à ce sujet à plusieurs reprises, avec une présentation intitulée Une PME en logiciel libre de A à Z ?.

Je suis également membre de la sympathique association Asterisk-France, qui a pour objet la promotion d'Asterisk en France et dans les pays francophones.

L'expérience OpenERP 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ée 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, OpenERP 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 qui ne reste pas minuscule toute sa vie !

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 entrain 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 succinte, 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'OpenERP. 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 à 2500 €, 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 critère très important pour le succès d'un logiciel libre.

Raphaël Valyi m'a expliqué les qualités d'OpenERP. 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 OpenERP : OpenERP 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 OpenERP, je lui ai fait confiance.

J'ai pu convaincre mes associés de faire le choix d'OpenERP 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'OpenERP 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 avait mis au point leurs méthodes et leurs processes (et c'était également moi qui faisait leur boulot quand ils étaient absents !).

Le démarrage d'OpenERP à 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'OpenERP à 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 OpenERP et de lancer OpenERP 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'OpenERP 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'OpenERP. L'équipe d'Akretion France a grossi au fil des années et est maintenant composée d'une dizaine de consultant, à la fois développeurs et experts fonctionnels, basée à Lyon (sauf une personne basée en région parisienne).

Cette section sur mon histoire personnelle sur OpenERP 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 OpenERP dans ce document, il faut que les lecteurs aient les informations nécessaires pour mettre en perspective mon opinion.

Les contributions sur OpenERP de l'auteur

Ma contribution à OpenERP 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'OpenERP, 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'OpenERP

Petit historique d'OpenERP

Fabien Pinckaers a démarré TinyERP (l'ancien nom d'OpenERP) 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 revenue é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'OpenERP. En Juin 2008, TinyERP change de nom pour devenir OpenERP et sort son premier livre chez Eyrolles. L'année 2008 est également marquée par le démarrage de Tryton, un fork d'OpenERP, initié par deux anciens employés de Tiny sprl, et qui est toujours actif aujourd'hui et continue son développement indépendamment d'OpenERP. 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 OpenERP" (véridique, cf l'annonce de la version 5.0) ou on peut chatter dans OpenERP (cf cette news de Février 2013 qui annonce l'ajout d'une messagerie instantannée dans le futur OpenERP 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'OpenERP 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 OpenERP 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'OpenERP 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 OpenERP S.A. en tant que directeur de la R&D. Sous son impulsion, le développement d'OpenERP se professionnalise et marque la fin de la fâcheuse tendance qu'avait OpenERP à 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'OpenERP 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'OpenERP 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'OpenERP 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'OpenERP 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ù OpenERP prétend avec cette release marquer la fin de l'ère des ERPs dinausores et l'avènement d'une nouvelle ère dominée par des ERPs léger 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'OpenERP est remplacé par l'interface Web d'un serveur OpenERP 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'OpenERP 7.0.

L'année 2013 a très mal commencé pour OpenERP 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 OpenERP 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'OpenERP 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 enflamés sur la solution technique à adopter, on s'est retrouvés 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'OpenERP 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'OpenERP 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'OpenERP 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'OpenERP Community Association a été faite lors des OpenERP Community Days en Juillet 2013 par 5 sociétés faisant partie des plus gros contributeurs communautaires sur OpenERP : Camptocamp, SavoirFaireLinux, Therp, Vauxoo et Akretion. La section suivante contient plus de détails sur l'Association Communautaire OpenERP. 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 OpenERP-Magento et OpenERP-PrestaShop pour OpenERP 7.0 basés sur ce nouveau framework de synchronisation.

Le 15 Mai 2014, OpenERP 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ée 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 les clients qui utilisent de nombreuses applications d'OpenERP. 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é !

Je trouve que cette modification est 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 OpenERP 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 ! Je pense que de nombreuses entreprises utilisatrices d'OpenERP ne vont pas accepter cette augmentation de tarif, ne renouvelleront pas leur contrat de maintenance avec l'éditeur et se tourneront vers le projet OpenUpgrade pour leurs migrations.

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

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

  1. les bases techniques d'OpenERP 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 OpenERP Enterprise), en abandonnant le pricing par application, et par conséquent en mettant fin à l'augmentation des tarifs pour les entreprises utilisant OpenERP 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 renouvellé 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é OpenERP : 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'OpenERP : 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 OpenERP. La licence LGPL est, comme la licence AGPL, une licence libre largement reconnue écrite par la FSF (Free Software Fondation), mais, contrairement à la licence AGPL, elle n'est pas contagieuse, donc les modules OpenERP 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é OpenERP, 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'OpenERP 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'OpenERP 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 OpenERP sans mise à disposition du code source pour les utilisateurs. Ces échanges ont également permis de faire prendre consicence à 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 OpenERP 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 OpenERP à 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 OpenERP, 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 quelle 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.

Tryton, un fork d'OpenERP

Tryton, le fork d'OpenERP, 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 a 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 à OpenERP (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 OpenERP, vous pouvez consulter le site OpenERP 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'OpenERP (ces deux sociétés étaient à l'époque très impliquées dans la communauté OpenERP, avec de grosses contributions à leur actif).

L'OpenERP Community Association

L'OpenERP 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ées 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é OpenERP. 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 OpenERP, la méthode de travail des développeurs communautaires OpenERP 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é OpenERP 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 OpenERP ; cela permet à l'OCA de peser face à l'éditeur et d'être un acteur incontournable de l'éco-système OpenERP.

L'association maintient également les branches OCB (OpenERP 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'OpenERP, je reviens plus en détail sur la naissance des branches OCB et leur fonctionnement.

Le business model de l'éditeur

L'éditeur d'OpenERP est la société belge OpenERP 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 OpenERP, mais il utilise ces livres comme un moyen de diffusion d'OpenERP et non comme une source de revenu, 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'OpenERP était 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 OpenERP 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 OpenERP 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 OpenERP 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 OpenERP 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é OpenERP. Le business model d'un éditeur de logiciel libre n'est pas une chose évidente et on peut comprendre que l'éditeur d'OpenERP 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'OpenERP

Pour ceux qui voudraient suivre l'actualité d'OpenERP "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'OpenERP, il faut également utiliser d'autres sources d'information moins classiques ; par ordre d'importance :

Vue générale sur OpenERP : 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 OpenERP v8 : le framework d'OpenERP 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 OpenERP 7.0).
  • Choix du langage Python : un langage orienté objet conçu pour être facile pour le développeur.
  • Légèreté et bidouillabilité : OpenERP n'est pas une usine à gaz, c'est un logiciel plutôt léger et assez facile à appréhender pour les développeurs. Avec OpenERP, 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 OpenERP 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é : OpenERP 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é OpenERP 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é OpenERP 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'OpenERP 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 OpenERP vers la dernière version.
  • Une marque (Odoo) et une image qui s'est beaucoup professionnalisée.
  • La faiblesse fonctionnelle des modules officiels. OpenERP 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'OpenERP.
  • 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 OpenERP 7.0 suite à un changement du modèle de données. D'ailleurs, si vous envisagez d'utiliser OpenERP 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 OpenERP 7.0 et discute des solutions possibles.
  • 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'OpenERP 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.
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 OpenERP v9, développés par l'éditeur ou par des tiers. Cela risque de dégrader l'image OpenSource d'OpenERP, 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'OpenERP.
  • Le risque d'un nouveau fork communautaire d'OpenERP, 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é OpenERP sont partis chez Tryton (un fork d'OpenERP) en 2010-2011, mais cette hémoragie semble stoppée.

OpenERP, la licence et les copyrights

OpenERP é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'OpenERP 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 OpenERP 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.

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

  1. le serveur OpenERP avec ses modules officiels dont le code source est disponible sur le projet Github odoo,
  2. les modules communautaires maintenus par l'OpenERP 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, 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, OpenERP 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'OpenERP 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é OpenERP. 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 OpenERP 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 OpenERP ou un des addons officiels pouvait vous poursuivre pour violation de licence, car vous utilisez 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'OpenERP 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é si 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 OpenERP : 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'OpenERP 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'OpenERP.

En effet, la quasi-totalité des grosses références d'OpenERP 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'OpenERP : 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'OpenERP 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'OpenERP, n'utilisent pas la gestion de stock d'OpenERP, etc... ce qui limite un peu la portée de ces références. Par contre, cela prouve que le framework d'OpenERP est de qualité, ce qui n'est pas rien !

En réalité, dans le cadre de "projets ERP", OpenERP est adapté pour des déploiements dans des PMEs de quelques dizaines à quelques centaines d'employés, mais le nom de ces PMEs sont rarement connues 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 OpenERP réalisé par Danone. Evidemment, Danone utilise SAP et n'est pas prêt d'en changer ! Mais Danone a choisi de déployer OpenERP 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 OpenERP 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'OpenERP 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'OpenERP se distingue sur les points suivants :

Le meilleur exemple qui illustre la qualité du framework d'OpenERP est l'ajout de vues cartographiques dans OpenERP, qui a été réalisé par l'intégrateur Camptocamp. En 2011, Camptocamp a fait évoluer le framework d'OpenERP pour ajouter le support des vues cartographiques : en un clic dans OpenERP, 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'OpenERP et développé des modules spécifiques. Cela aurait été impossible si le framework d'OpenERP 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 OpenERP 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'OpenERP n'est pas exempt de défauts. Heureusement, la nouvelle API introduite avec OpenERP 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é par les défauts de l'ancienne API. Or, dans OpenERP 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 OpenERP, 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'OpenERP. 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'OpenERP.

Le choix du moteur de rapport

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

Nom du moteur de rapport Module Mainteneur Outil de conception des rapports Formats de sortie possibles
QWeb intégré dans le serveur OpenERP 8.0 ; c'est le moteur utilisé dans les rapports officiels d'OpenERP 8.0. OpenERP S.A. Codage manuel HTML, PDF, TXT
RML intégré dans le serveur OpenERP + module officiel base_report_designer. C'est le moteur par défaut jusqu'à OpenERP 7.0 compris. Il fait encore partie d'OpenERP 8.0 mais n'est utilisé que dans quelques cas "spéciaux". OpenERP 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 OpenERP 6.0. Dans OpenERP 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 OpenERP s'explique en partie par les défauts du moteur de rapport utilisé par défaut dans OpenERP, qui ont poussé la communauté à développer des alternatives.

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

Le moteur de rapport QWeb a été développé par l'éditeur et livré dans OpenERP 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 OpenERP dans ce nouveau format, ce qui a permis d'imposer ce moteur de rapport dès la sortie d'OpenERP 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'OpenERP, 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'OpenERP

Le moteur de rapport par défaut d'OpenERP 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). OpenERP 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 OpenERP (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, OpenERP 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'à OpenERP 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é OpenERP é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 OpenERP ou sur une autre machine. Les deux modules concurrents développés par Syleam et Nan-tic assurent l'interconnexion entre le serveur OpenERP 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 OpenERP 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 OpenERP é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'OpenERP, écrit en Python 2.

En résumé :

Pour terminer sur le moteur de rapport Aeroo, un petit secret à connaitre : pour utiliser report_aeroo sur OpenERP 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 OpenERP et qui a fait de nombreuses contributions importantes et de grande qualité sur OpenERP. 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 OpenERP 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'OpenERP d'inclure le module report_webkit parmi les modules officiels, ce qui a été fait dans OpenERP 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'OpenERP). Le moteur Webkit continuera a être utilisé chez les clients qui ont développé leurs rapports en Webkit et qui ne souhaitent pas les re-développer en QWeb à l'occasion d'une mise-à-jour de leur OpenERP, mais je ne pense pas que ce soit une bonne idée de choisir le moteur de rapport Webkit pour un nouveau projet OpenERP.

Plateforme et requirements hardware pour le serveur

OpenERP n'est pas un logiciel gourmand en ressources. Pour un déploiement du serveur OpenERP et de sa base de donnée 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 OpenERP 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 OpenERP 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é OpenERP.

Il n'est pas envisageable aujourd'hui de déployer OpenERP 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é OpenERP via les packages de votre distribution Linux par exemple. De plus, l'éditeur ne fait plus de releases mineures d'OpenERP 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'OpenERP sur votre serveur de production :

La business intelligence avec OpenERP

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 OpenERP. Historiquement, les graphiques intégrés dans OpenERP étaient très limités, mais l'éditeur a redéveloppé from scratch la vue des graphiques dans OpenERP 7.0, cf ce post sur le blog officiel. Dans OpenERP 8.0, l'éditeur a développé des fonctionnalités de tableau croisé dynamique (OLAP) dans OpenERP, avec possibilité d'export Excel (cf ces slides). Ces tableaux croisés disponibles directement dans OpenERP 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'OpenERP est la fonction de drill-through.

Si les fonctionnalités de graphiques et de tableau croisés dynamique intégré dans OpenERP ne donnait 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 OpenERP Apps sont un peu limitées, l'intégrateur allemand initOS a lancé un moteur de recherche odoo code search qui permet à le 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 OpenERP sans besoin d'un enregistrement préalable.

Une des choses qui m'énerve le plus dans le discours qu'on peut entendre sur OpenERP 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 OpenERP, tant qu'on ne l'a pas essayé, on ne sais 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'OpenERP,
  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'OpenERP,
  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'OpenERP à 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 OpenERP 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 OpenERP 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'OpenERP concurrence avec ses modules officiels des ERPs propriétaires de premier plan dans le domaine fonctionnel. OpenERP 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'OpenERP. OpenERP, avec ses modules officiels, fournit un socle minimum dans chaque domaine, et le framework OpenERP 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 OpenERP 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 OpenERP. S'il y avait une chose à retenir, ce serait celle-là : OpenERP 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'OpenERP, 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'OpenERP en publiant une série de modules permettant d'étendre le périmètre fonctionnel natif d'OpenERP 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'OpenERP 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 un entreprise de ce secteur d'activité veut déployer OpenERP, 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 OpenERP, 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 OpenERP :

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

Les modules utilisés à Anevia

Je publie ici la liste des modules utilisés sur OpenERP 6.1 à Anevia. Cela permet de voir :

Je ferai ensuite une analyse sur la répartition entre les modules officiels, les modules communautaires 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
base officiel OpenERP S.A. lp:openobject-addons/6.1 0 16 098 Le module qui fournit les objets de base : utilisateurs, pays, monnaies, partenaires, ...
account officiel OpenERP S.A. lp:openobject-addons/6.1 7 21 405 Le module de facturation et de comptabilité. Concernant les patchs appliqués, 2 sont des backports de mes merge proposals que j'ai réussi à faire accepter dans OpenERP 7.0, 1 concerne une amélioration sur les libellés des écritures de report à nouveau générées lors de la clôture d'un exercice fiscal, et les 4 autres sont des bug fix : 1019324, 1045424, 1058390 et 1155690.
account_accountant officiel OpenERP S.A. lp:openobject-addons/6.1 0 21 Mini-module qui permet à l'administrateur d'avoir accès à la comptabilité.
account_cancel officiel OpenERP S.A. lp:openobject-addons/6.1 0 38 Module qui autorise l'annulation d'une facture en cas d'erreur
account_followup officiel OpenERP S.A. lp:openobject-addons/6.1 0 933 Module de gestion des relances client
account_invoice_layout officiel OpenERP S.A. lp:openobject-addons/6.1 1 602 Module qui ajoute des options de mise en page des factures : sections, notes, lignes de séparation, etc...
account_payment officiel OpenERP S.A. lp:openobject-addons/6.1 0 1 292 Module de gestion des paiements fournisseur
account_voucher officiel OpenERP S.A. lp:openobject-addons/6.1 0 2 987 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)
product officiel OpenERP S.A. lp:openobject-addons/6.1 2 3 294 Module qui contient les objets correspondant aux produits et les objets annexe. Le premier patch correspond au bug n°955051 et le second peut être considéré comment spécifique à Anevia.
sale officiel OpenERP S.A. lp:openobject-addons/6.1 0 3 940 Module de gestion des ventes (devis, commandes client)
sale_layout officiel OpenERP S.A. lp:openobject-addons/6.1 1 373 Module qui ajoute des options de mise en page des devis : sections, sous-totaux, notes, lignes de séparation, etc... Le patch appliqué corrige un bug critique (un devis pouvait avoir un montant total qui ne correspond pas à la somme des lignes !), qui fait maintenant partie de la branche 6.1 officielle.
product_visible_discount officiel OpenERP S.A. lp:openobject-addons/6.1 0 190 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'OpenERP).
purchase officiel OpenERP S.A. lp:openobject-addons/6.1 1 2 898 Module de gestion des achats chez les fournisseurs. Le patch corrige une incohérence sur les flags noupdate par rapport aux autres modules, que j'ai essayé de corriger plus globalement dans cette merge proposal.
stock officiel OpenERP S.A. lp:openobject-addons/6.1 4 7 717 Module de gestion des stocks. Les 4 patchs appliqués correspondent à 4 bug fix : 1027819, 1029537, 1030880, 1066127, en sachant que les deux premiers sont bloquants.
delivery officiel OpenERP S.A. lp:openobject-addons/6.1 0 934 Module de gestion des livraisons
mrp officiel OpenERP S.A. lp:openobject-addons/6.1 0 4 285 Module de gestion de la production
mrp_subproduct officiel OpenERP S.A. lp:openobject-addons/6.1 0 129 Permet d'avoir plusieurs produits en sortie d'une nomenclature.
edi officiel OpenERP S.A. lp:openobject-addons/6.1 0 1 214 Module de support de l'EDI. Anevia n'utilise pas l'EDI d'OpenERP, mais ce module est installé automatiquement par le jeu des dépendances.
crm officiel OpenERP S.A. lp:openobject-addons/6.1 0 6 914 Fournit la CRM d'OpenERP.
crm_claim officiel OpenERP S.A. lp:openobject-addons/6.1 0 832 Ajoute le support des réclamations client dans la CRM d'OpenERP. Le module fleet_maintenance utilise ce module pour la gestion des RMAs.
l10n_fr officiel Communauté française d'OpenERP lp:openobject-addons/6.1 0 10 112 Contient la localisation française d'OpenERP : 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.
users_ldap officiel OpenERP S.A. lp:openobject-addons/6.1 0 250 Module qui permet d'authentifier les utilisateurs via un annuaire LDAP.
email_template officiel Initiallement écrit par Openlabs dans le cadre du projet communautaire Poweremail, puis repris par OpenERP S.A. pour les addons lp:openobject-addons/6.1 0 1 128 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 OpenERP S.A. lp:openobject-addons/6.1 0 364 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é par Anevia.
hr officiel OpenERP S.A. lp:openobject-addons/6.1 1 1 198 Module de base pour la gestion des ressources humaines. Le patch corrige une incohérence sur les flags noupdate, comme pour le module purchase.
hr_expense officiel OpenERP S.A. lp:openobject-addons/6.1 0 1 066 Module de gestion des notes de frais.
hr_holidays officiel OpenERP S.A. lp:openobject-addons/6.1 0 1 692 Module de gestion des congés.
hr_timesheet officiel OpenERP S.A. lp:openobject-addons/6.1 0 937 Module de gestion des feuilles de temps.
hr_attendance officiel OpenERP S.A. lp:openobject-addons/6.1 0 1 079 Module de gestion de présence. Ce module est installé automatiquement par dépendance lors de l'installation du module hr_timesheet et n'est pas utilisé à Anevia.
document officiel OpenERP S.A. lp:openobject-addons/6.1 0 3 578 Module qui permet de stocker les pièces jointes de l'ERP sur le système de fichier plutôt que de les stocker dans la base de donnée (ce qui fait beaucoup grossir la base de donnée si on utilise beaucoup les pièces jointes dans l'ERP).
google_map officiel OpenERP S.A. lp:openobject-addons/6.1 0 77 Module qui permet de visualiser une adresse du partenaire de l'ERP dans Google Maps en un clic. Super pratique... et donc indispensable !
base_action_rule officiel OpenERP S.A. lp:openobject-addons/6.1 0 501 Module qui permet d'automatiser certaines actions dans l'ERP avec des conditions de déclenchement. Peut être utilisé par exemple pour envoyer un mail à certains employés lors de la création d'un nouveau produit dans l'ERP. Installé automatiquement par dépendance lors de l'installation de la CRM.
report_webkit officiel Camptocamp lp:openobject-addons/6.1 0 932 Module qui fournit le moteur de rapport Webkit, décrit dans la section de ce document dédiée aux Moteurs de rapport.
anonymization officiel OpenERP S.A. lp:openobject-addons/6.1 2 590 Module qui permet d'anonymiser sa base de donnée avant de l'envoyer à l'éditeur pour une migration vers une version supérieure d'OpenERP. Ce module permet aussi de désanonymiser la base de donnée renvoyée par l'éditeur après migration. Le premier patch est un bug fix, l'autre correspond à l'ajout de la possibilité de lire le fichier de dés-anonymisation depuis le filesystem (pour éviter d'avoir à l'uploader via l'interface, ce qui prend beaucoup de temps quand on travaille sur le serveur via Internet).
Modules Web officiel OpenERP S.A. lp:openerp-web/6.1 0 non comptés L'interface Web d'OpenERP utilise des modules pour son fonctionnement : web, web_dashboard, web_gantt, web_mobile, web_calendar, web_diagram, web_graph, web_kanban, web_process, web_tests. Je n'ai pas compté ces modules dans le décompte des lignes de code des modules fonctionnels.
Modules cachés officiel OpenERP S.A. lp:openobject-addons/6.1 0 11 403 De nombreux modules sont classés dans la catégorie Hidden ou Dependancy et s'installent tout seuls par dépendance. Exemple : l10n_fr_rib, analytic, process, board, base_setup, mail, etc...
report_aeroo communautaire Alistek lp:aeroo/openerp6.1.x 2 2 736 Fournit le moteur de rapport Aeroo, décrit en détail dans la section de ce document dédiée aux Moteurs de rapport. Le premier patch appliqué est un bug fix sur les code-barres EAN13, le second correspond au développement réalisé par Akretion pour ajouter un watchdog pour LibreOffice (si LibreOffice ne répond pas, un script est exécuté pour le relancer), cf cette branche.
report_aeroo_ooo communautaire Alistek lp:aeroo/openerp6.1.x 0 488 Complément du module précédent ; permet l'utilisation de LibreOffice côté serveur pour le rendu des rapports en PDF notamment.
report_aeroo_printscreen communautaire Alistek lp:aeroo/openerp6.1.x 0 59 Remplace la fonction printscreen native d'OpenERP : permet d'exporter les vues liste au format ODT plutôt qu'au format PDF, ce qui est plus facile à exploiter.
fleet_maintenance communautaire Akretion, principalement financé par Anevia lp:fleet-maintenance 0 1 651 Fournit la gestion des contrats de maintenance sur les équipements. Ce module a été développé pour les besoins d'Anevia, mais de façon générique.
sale_layout_fleet_maintenance communautaire Akretion lp:fleet-maintenance 0 50 Module qui permet la compatibilité entre le module fleet_maintenance et le module sale_layout.
account_invoice_layout_fleet_maintenance communautaire Akretion lp:fleet-maintenance 0 17 Module qui permet la compatibilité entre le module fleet_maintenance et le module account_invoice_layout.
fleet_serial communautaire Akretion lp:fleet-maintenance 0 33 Module qui permet de savoir si un production lot est couvert par un contrat de maintenance ou pas.
product_serial communautaire Akretion lp:openobject-addons/extra-6.0 0 483 Module qui permet de faciliter la gestion des stocks avec traçabilité par numéro de série. Ce module a initialement été développé pour les besoins d'Anevia ; il a été largement adopté par la communauté.
product_variant_multi communautaire Initialement développé par OpenERP S.A. ; désormais maintenu principalement par Akretion lp:openobject-addons/extra-trunk 0 667 Module qui permet de gérer les variantes de produit.
product_variant_multi_advanced communautaire Akretion lp:openobject-addons/extra-trunk 0 123 Module qui ajoute certaines fonctionnalités au module product_variant_multi qui ne sont pas forcément utiles à tout le monde.
product_hardware_revision communautaire Akretion, financé par Anevia lp:~openerp-community/openobject-addons/trunk-addons-community 0 178 Facilite la gestion des révisions hardware des produits dans OpenERP.
product_loan communautaire Akretion, financé par Anevia lp:~openerp-community/openobject-addons/trunk-addons-community 0 706 Permet la gestion de prêts gratuit d'équipements aux clients.
intrastat_base communautaire Akretion (codé par mes soins !) lp:new-report-intrastat 0 351 Module de base pour le support de la DEB (Déclaration d'Echange de Biens) et de la DES (Déclaration Européenne des Services).
l10n_fr_intrastat_product communautaire Akretion (codé par mes soins !) lp:new-report-intrastat 0 1 643 Fournit le support complet de la DEB, y compris la génération d'un ficher XML qu'il suffit de déposer sur le site ProDouane.
l10n_fr_intrastat_service communautaire Akretion (codé par mes soins !) lp:new-report-intrastat 0 336 Fournit le support complet de la DES, y compris la génération d'un ficher XML qu'il suffit de déposer sur le site ProDouane.
sale_partner_bank communautaire Akretion (codé par mes soins !) lp:openobject-addons/extra-trunk 0 64 Module utile si vous avez plusieurs comptes bancaires et que vous voulez associer chaque client à l'un de vos comptes bancaires pour ses règlements par virement.
coface_credit_insurance communautaire Akretion, financé par Anevia lp:openerp-coface-connector 0 619 Permet l'import automatique des ratings Coface sur les fiches partenaires. La Coface est un des principaux assureurs crédit français.
board_coface communautaire Akretion, financé par Anevia lp:openerp-coface-connector 0 31 Fournit un tableau de bord pour surveiller les échéances déclaratives à respecter auprès de la Coface en cas d'impayé client.
account_move_csv_import communautaire Akretion (codé par mes soins !) lp:openobject-addons/extra-trunk 0 228 Permet un import facile d'écritures comptables au format CSV. Utilisé notamment pour l'import des écritures de paye en provenance d'un autre logiciel.
account_analytic_required communautaire Akretion (codé par mes soins !) lp:openobject-addons/extra-6.0 0 64 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_reversal communautaire Akretion (codé par mes soins !) lp:openobject-addons/extra-6.0 0 136 Permet d'extourner facilement une écriture comptable sans saisie manuelle.
asterisk_click2dial communautaire Akretion (codé par mes soins !) lp:openerp-asterisk-connector 0 864 Fournit le connecteur entre OpenERP et Asterisk. Très pratique pour toutes les sociétés qui ont un IPBX basé sur Asterisk car il permet d'utiliser OpenERP comme annuaire téléphonique pour la société et inclu des fonctionnalités de click2dial et de remontée de fiche en un clic.
asterisk_click2dial_crm communautaire Akretion (codé par mes soins !) lp:openerp-asterisk-connector 0 161 Fonctions additionnelles du connecteur OpenERP-Asterisk pour la CRM.
currency_rate_update communautaire Camptocamp, sur lequel j'ai fait quelques contributions lp:c2c-financial-addons/6.1 0 616 Permet l'import journalier dans l'ERP des taux de change depuis une sélection de sites Internet.
currency_rate_date_check communautaire Akretion (codé par mes soins !) lp:openobject-addons/extra-trunk 0 71 Permet de s'assurer que l'ERP n'utilise jamais un taux de change trop vieux par rapport à la date de la transaction.
account_financial_report_webkit communautaire Camptocamp lp:c2c-financial-addons/6.1 0 3 223 Contient les célèbres rapports financiers de Camptocamp. Ce module remplace les rapports financiers natifs d'OpenERP.
account_trial_balance_csv communautaire Akretion (codé par mes soins !) lp:~akretion-team/+junk/account-balance-csv-61 0 47 Permet de faire un export CSV de la balance générale.
account_analytic_balance_csv communautaire Akretion (codé par mes soins !) lp:~akretion-team/+junk/account-balance-csv-61 0 128 Permet de faire un export CSV de la balance analytique.
account_banking communautaire Banking addons community, maintenu notamment par Stefan Rijnhart de la société Therp lp:~akretion-team/banking-addons/trunk-banking-addons-sepa 0 5 916 Fournit un framework pour l'import des relevés de compte et la génération de fichiers de virement ou de prélèvement dans différents formats.
account_banking_sepa_credit_transfer communautaire Akretion (codé par mes soins !) lp:~akretion-team/banking-addons/trunk-banking-addons-sepa 0 380 Permet la génération de fichiers de virement au format SEPA XML (implémentation de la norme SEPA Credit Transfer, plus précisément le format PAIN).
account_iban_preserve_domestic communautaire Therp lp:~akretion-team/banking-addons/trunk-banking-addons-sepa 0 40 Installé automatiquement par dépendance lors de l'installation du module account_banking.
partner_world_area communautaire Anevia lp:~openerp-community/openobject-addons/trunk-addons-community 0 100 Permet de définir des régions du monde et de rattacher chaque pays à une région du monde. Utile pour faire des statistiques par région du monde.
sale_layout_cleanup communautaire Akretion (codé par mes soins !) lp:openobject-addons/extra-trunk 0 45 Permet d'utiliser le module sale_layout de façon propre et techniquement facile, sans utiliser le parseur de rapport du module sale_layout.
scheduler_error_mailer communautaire Akretion lp:~akretion-team/+junk/scheduler_error_mailer 0 64 Permet d'envoyer un e-mail en cas d'échec d'exécution d'une tâche planifiée d'OpenERP. Très pratique pour l'administrateur !
7 modules *_viewer communautaire Akretion (codé par mes soins !) lp:openerp-viewer-groups 0 78 Ces 7 mini-modules ajoutent un niveau de droit Viewer (accès en lecture seule) dans les principaux domaines fonctionnels (vente, achat, gestion de stock, MRP et comptabilité), en plus des niveaux User et Manager. Les 7 modules sont sale_viewer, purchase_viewer, stock_viewer, account_viewer, account_voucher_viewer, mrp_viewer et sale_mrp_viewer.
bi_invoice_company_currency communautaire Akretion (codé par mes soins !) lp:~akretion-team/+junk/business_intelligence_fields 0 105 Ajoute sur la facture les montants dans la monnaie de la société (et pas seulement en devise). Utile pour alimenter la Business Intelligence dans le but de faire des statistiques de facturation.
bi_invoice_payment communautaire Akretion (codé par mes soins !) lp:~akretion-team/+junk/business_intelligence_fields 0 104 Ajoute sur la facture des informations sur le paiement. Utile pour alimenter la Business Intelligence dans le but de faire des statistiques sur les règlements client.
bi_expense_company_currency communautaire Akretion (codé par mes soins !) lp:~akretion-team/+junk/business_intelligence_fields 0 62 Ajoute sur les lignes de note de frais les montants dans la monnaie de la société. Utile pour alimenter la Business Intelligence dans le but de faire des statistiques sur les notes de frais.
bi_product_category communautaire Akretion (codé par mes soins !) lp:~akretion-team/+junk/business_intelligence_fields 0 59 Ajoute les niveaux de hiérarchies des catégories produit dans un format adapté pour la BI.
bi_build_datawarehouse communautaire Akretion (codé par mes soins !) Interne Anevia (à publier dès que j'ai le temps) 0 372 Permet de générer le datawarehouse de la Business Intelligence.
sale_no_dashboard communautaire Akretion lp:~akretion-team/+junk/addons-no-fluff 0 8 Ce mini-module neutralise le dashboard natif d'OpenERP sur les ventes. Indispensable quand on veut utiliser l'interface Web d'OpenERP ! En effet, dans l'interface Web, le dashboard s'affiche par défaut dès qu'on va dans le menu de gestion des ventes, or ce dashboard est extrêmement lent dès qu'on a un volume de données de vente significatif dans l'ERP, ce qui rend l'interface Web inutilisable.
stock_no_dashboard communautaire Akretion lp:~akretion-team/+junk/addons-no-fluff 0 8 Idem que le mini-module précédent, pour le dashboard sur les stocks.
stock_move_always_allow_cancel communautaire Akretion (codé par mes soins !) lp:~akretion-team/+junk/stock_misc 0 27 Mini-module qui autorise l'annulation d'un mouvement de stock dans tous les cas (par défaut, OpenERP ne permet pas d'annuler un mouvement de stock confirmé).
stock_prodlots_by_location communautaire Akretion (codé par mes soins !) lp:~akretion-team/+junk/stock_misc 0 25 Mini-module qui permet de visualiser la liste des lots de production situés sur un emplacement de stock donné.
base_external_referentials communautaire Akretion (et initialement OpenLabs) lp:~extra-addons-commiter/openobject-extension/oerp6.1-cleanning 0 2757 Permet de mapper les objets d'OpenERP avec des objets de logiciels externes. Requis par le connecteur OpenERP-PrestaShop.
base_onchange_player communautaire Akretion lp:~extra-addons-commiter/openobject-extension/oerp6.1-cleanning 0 30 Requis par le connecteur OpenERP-PrestaShop.
base_pop_up communautaire Akretion lp:~extra-addons-commiter/openobject-extension/oerp6.1-cleanning 0 103 Requis par le connecteur OpenERP-PrestaShop.
base_sale_multichannels communautaire Akretion (et initialement OpenLabs) lp:~extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning 0 1335 Fourni les fonctions de base nécessaires à la vente multi-canal. Requis par le connecteur OpenERP-PrestaShop.
base_sale_export_partner communautaire Akretion (code par mes soins !) lp:~extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning 0 68 Fourni les fonctions de base nécessaires à l'export d'un partenaire vers un logiciel externe. Requis par le connecteur OpenERP-PrestaShop.
base_sale_export_product communautaire Akretion lp:~extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning 0 96 Fourni les fonctions de base nécessaires à l'export d'un produit vers un logiciel externe. Requis par le connecteur OpenERP-PrestaShop.
sale_automatic_workflow communautaire Akretion lp:~extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning 0 276 Requis par le connecteur OpenERP-PrestaShop.
sale_exceptions communautaire Akretion lp:~extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning 0 349 Requis par le connecteur OpenERP-PrestaShop.
sale_quick_payment communautaire Akretion lp:~extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning 0 261 Requis par le connecteur OpenERP-PrestaShop.
product_custom_attributes_shop communautaire Akretion lp:~extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning 0 207 Requis par le connecteur OpenERP-PrestaShop.
product_images_sync communautaire Akretion (codé par mes soins !) lp:~extra-addons-commiter/e-commerce-addons/oerp6.1-cleanning 0 20 Requis par le connecteur OpenERP-PrestaShop.
product_custom_attributes communautaire Akretion lp:~extra-addons-commiter/product-extra-addons/oerp6.1-stable-product-images-renamed 0 594 Requis par le connecteur OpenERP-PrestaShop.
product_images communautaire OpenLabs et Akretion lp:~extra-addons-commiter/product-extra-addons/oerp6.1-stable-product-images-renamed 0 302 Ajoute la gestion des images sur les fiches produit. Requis par le connecteur OpenERP-PrestaShop.
product_m2mcategories communautaire OpenLabs lp:~extra-addons-commiter/product-extra-addons/oerp6.1-stable-product-images-renamed 0 30 Permet à un produit d'appartenir à plusieurs catégories. Requis par le connecteur OpenERP-PrestaShop.
product_sequence communautaire Zikzakmedia lp:~extra-addons-commiter/product-extra-addons/oerp6.1-stable-product-images-renamed 0 53 Requis par le connecteur OpenERP-PrestaShop.
prestashoperpconnect communautaire Akretion et Camptocamp lp:prestashoperpconnect 0 691 Module principal du connecteur OpenERP-PrestaShop.
prestashoperpconnect_catalog_manager communautaire Akretion lp:prestashoperpconnect 0 232 Module qui permet de gérer le catalogue produit dans OpenERP et de le synchroniser vers PrestaShop (sans ce module, le catalogue produit est géré dans PrestaShop et synchronisé vers OpenERP).
prestashoperpconnect_export_partner communautaire Akretion (codé par mes soins !) lp:prestashoperpconnect 0 35 Module qui permet d'exporter un partenaire d'OpenERP vers PrestaShop (sans ce module, les partenaires sont seulement importés depuis PrestaShop vers OpenERP).
anevia_base spécifique-Anevia Anevia Interne Anevia - 75 Mini-module qui complète le module base. Ne contient pas grand chose.
anevia_partner spécifique-Anevia Anevia Interne Anevia - 102 Module qui ajoute ou modifie certains champs sur les partenaires : ajoute le champ SIREN sur les partenaires, affiche le champ Pays sur la vue formulaire des partenaires et modifie la façon dont est calculé ce champ (par défaut, le champ Pays des partenaires est égal au Pays de la première adresse de ce partenaire, ce qui est trop simpliste pour Anevia). Ajoute une notification par mail en interne lors de la création d'un nouveau partenaire.
anevia_sale spécifique-Anevia Anevia Interne Anevia - 374 Empêche les utilisateurs de modifier manuellement les taxes sur les lignes de devis (ils doivent utiliser la position fiscale et rien d'autre !). Oblige les utilisateurs à sélectionner un produit sur une ligne de devis (par défaut, le champ produit n'est pas obligatoire). Ajoute une étape au workflow des commandes pour différencier la réception d'une commande et son acceptation par la société (par exemple : une nouvelle commande d'un client qui aurait une ancienne facture impayée serait avancée à l'étape de workflow commande reçue mais pas commande acceptée). Ajoute également une étape Proforma au workflow des commandes (cette étape met un titre Facture Pro-Forma au devis), pour que les commerciaux puissent envoyer une facture proforma aux clients qui le demandent sans déranger le service administratif. Plus quelques détails spécifique à Anevia.
anevia_stock spécifique-Anevia Anevia Interne Anevia - 321 Modifie la gestion des tracking numbers et du packaging. Par défaut dans OpenERP, le tracking number est une propriété de l'expédition. Or certains transporteurs (UPS et d'autres) attribuent un numéro de tracking par colis. Ajoute aussi un champ calculé nécessaire à la génération automatique des formulaires de douane (EUR-1 et ATR).
anevia_purchase spécifique-Anevia Anevia Interne Anevia - 72 Complément du module officiel purchase. Ajoute un champ Conditions de paiement aux commandes fournisseur, avec un comportement similaire au champ Conditions de paiement des commandes client. Ce module ne sera plus nécessaire avec OpenERP 7.0 car ma merge proposal sur l'ajout des conditions de paiement aux commandes fournisseur a été acceptée peu de temps avant la release d'OpenERP 7.0.
anevia_account spécifique-Anevia Anevia Interne Anevia - 384 Complément du module officiel account. Ajoute un lien depuis les lignes de facture vers les lignes de commande. Backport pour OpenERP 6.1 de ma merge proposal sur l'affichage de la devise du compte bancaire dans son libellé (merge proposal en 2 morceaux : addons et server) qui a été acceptée dans OpenERP 7.0.
anevia_followup spécifique-Anevia Anevia Interne Anevia - 26 Complément du module officiel account_followup : définition de quelques champs supplémentaires pour la gestion des relances client.
anevia_mrp spécifique-Anevia Anevia Interne Anevia - 15 Contient une modification mineure sur le module officiel mrp.
anevia_crm spécifique-Anevia Anevia Interne Anevia - 97 Ajoute une fonction permettant d'envoyer un mail généré à partir d'un template de mail lors du passage au stage de CRM suivant.
anevia_product spécifique-Anevia Anevia Interne Anevia - 254 Ajoute certains champs spécifiques à Anevia sur les fiches produit. Ajoute une notification par mail en interne lors de la création d'un nouveau produit (via base_action_rule).
anevia_product_variant spécifique-Anevia Anevia Interne Anevia - 173 Ajoute certaines fonctions spécifiques à Anevia au niveau de la génération des variantes de produit à partir du template.
anevia_hr spécifique-Anevia Anevia Interne Anevia - 85 Ajoute un lien inverse depuis la fiche employé vers la fiche utilisateur (nativement, le lien n'existe que dans l'autre sens). J'ai obtenu que ce lien soit ajouté dans le module hr officiel d'OpenERP 7.0. Ajoute une notification par mail en interne lors de la création d'un nouvel employé.
anevia_hr_expense spécifique-Anevia Anevia Interne Anevia - 623 Ajout de nombreuses fonctionnalités dans la gestion des notes de frais, que j'ai listées dans la section intitulée les modules officiels : le minimum dans chaque domaine
anevia_hr_holidays spécifique-Anevia Anevia Interne Anevia - 132 Personnalisation des droits sur les transitions du workflow de validation des congés. Ajout d'une notification par mail quand la demande de congé est soumise par l'employé et quand elle est acceptée ou refusée par son manager.
anevia_hr_timesheet spécifique-Anevia Anevia Interne Anevia - 271 Petites modifications spécifiques à Anevia pour faciliter la saisie des timesheets. Ajout d'un rapport supplémentaire.
anevia_prestashoperpconnect spécifique-Anevia Anevia Interne Anevia - 7 Petites modifications spécifiques à Anevia sur le connecteur PrestaShop-OpenERP (changement de mappings de champs et de valeurs par défaut).
anevia_sale_process spécifique-Anevia Anevia Interne Anevia - 116 Ajout de champs spécifiques à Anevia qui doivent suivre le process de vente client ; ils sont renseignés sur le devis, puis recopiés sur la facture et de nouveau recopiés sur l'avoir éventuel. Ce module ajoute aussi le lien depuis la facture vers les pickings et les commandes correspondantes.
asterisk_click2dial_ldap spécifique-Anevia Anevia Interne Anevia - 111 Synchronise les informations téléphoniques de la fiche utilisateur entre le LDAP d'Anevia et OpenERP
anevia_profile spécifique-Anevia Anevia Interne Anevia - 48 Ce module déclare les dépendances vers tous les autres modules utilisés par Anevia. Il contient aussi un certain nombre de règles de sécurité : ajout de groupes spécifiques, suppression d'un certain nombre d'ACLs natives et modification d'autres ACLs natives.
10 modules report_aeroo_* spécifique-Anevia Anevia Interne Anevia - 751 10 modules contenant les rapports personnalisés au format Aeroo avec les éventuels parseurs de rapport associés : report_aeroo_account, report_aeroo_delivery, report_aeroo_followup, report_aeroo_hr_expense, report_aeroo_product, report_aeroo_product_loan, report_aeroo_purchase, report_aeroo_sale, report_aeroo_stock, report_aeroo_terms_of_sale.

Pour compter les lignes de code des modules, j'ai utilisé le programme cloc avec la ligne de commande suivante : cloc --exclude-dir=lib --match-f=".*\.py$|.*\.xml$|.*\.js$" --not-match-f="__openerp__.py|.*_xsd\.py$" path_to_module.

Voici la répartition du nombre de lignes de code entre les modules officiels, communautaires et spécifiques :

Type de module Nombre de lignes de code Pourcentage du total
Officiels 111 000 76 %
Communautaires 30 420 21 %
Spécifique-Anevia 4 040 3 %
Total 145 460 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'OpenERP :

Composant Nombre de patchs appliqués Nombre de lignes de code Pourcentage du total Méthode de comptage
Server 0 27 740 12 % Module base exclus car compté dans les modules fonctionnels
Modules fonctionnels cf tableau ci-dessus 145 460 65 % Détail présenté dans le tableau ci-dessus
Interface Web 0 31 590 14 % Y compris la dizaine de modules web, qui n'a pas été compté dans les modules fonctionnels
Client Gtk 0 19 390 9 % Le code de SpiffGtkWidgets est exclus du décompte
Total 224 190 100 %

La maturité d'OpenERP

OpenERP 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 OpenERP 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 OpenERP 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 OpenERP 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 OpenERP 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, OpenERP 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. OpenERP 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'OpenERP 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 OpenERP qui les impactent :

Au vu des bugs que je rencontre, mon avis est qu'OpenERP 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é ci-dessus peut sembler effrayante pour une personne novice sur OpenERP. 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'OpenERP. 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'OpenERP 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'OpenERP a pour moi plusieurs conséquences concrètes :

Au vu de cette situation, l'éditeur devrait mettre la correction des bugs dans les branches stables parmi ses priorités. La théorie veut que les bugs corrigés pour les clients sous contrat de maintenance soient fusionnés dans les branches stables. A l'époque d'OpenERP 6.1, l'éditeur accusait un énorme retard dans ce domaine ; comme on le voit dans la liste des bugs remontés par Anevia sur OpenERP 6.1 via le contrat de maintenance (lien donné un peu plus haut), seuls 6 bugs sur les 18 corrigés, soit 33%, ont été fusionnés dans la branche stable (cf les cases en rouge dans la colonne Merge in stable branch). Cela freinait beaucoup la stabilisation des branches stables d'OpenERP 6.1 car cela empêchait de réellement mutualiser les efforts de bug fix sur la version stable d'OpenERP au niveau mondial. Concrètement, cela veut dire que la majorité des bugs fixés pour Anevia ne profitent pas aux autres sociétés, à moins que celles-ci passent leurs journées dans le bug tracker d'OpenERP à récupérer les patchs pour les appliquer eux-même sur leurs branches, ce qu'elles ne font évidemment pas !

L'éditeur a pris conscience de ce problème, et l'a reconnu dans les release notes d'OpenERP 7.0 en promettant que les bugfix sur OpenERP 7.0 seront mergés dans la branche stable d'OpenERP dans un délai court. Extrait des release notes, section 7.2 Maintenance : "We realize that up to now OpenERP 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 OpenERP. 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'OpenERP 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 OpenERP 7.0, ces intégrateurs ont décidé d'unir leurs efforts et de développer une branche stable commune, dénommées OpenERP 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é OpenERP 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'OpenERP 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é OpenERP, 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é OpenERP est tellement important 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 OpenERP

Est-il envisageable de tenir la comptabilité de son entreprise dans OpenERP ? 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'OpenERP ?" 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'OpenERP ?

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

La façon dont mes clients utilisent le scénario 2 est schématisé ci-dessous :

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

Si la comptabilité est effectivement tenue intégralement dans OpenERP, cela ne veut pas dire qu'OpenERP 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 OpenERP, en utilisant le module account_move_csv_import que j'ai développé. Depuis OpenERP 6.0, il existe un module pour faire la paye dans OpenERP, dénommé hr_payroll, mais nous n'en sommes qu'au tout début de la paye dans OpenERP et je ne connais encore aucune entreprise qui l'utilise en production.

Généralement, 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 OpenERP. Depuis OpenERP 6.1, le module de gestion des immobilisations account_asset est devenu un module officiel. Ce module avait été écrit à la va-vite par l'éditeur il y a longtemps, mais l'éditeur avait considéré à juste titre que ce module n'était pas prêt à devenir un module officiel (je l'avais testé à l'époque et j'avais eu plusieurs plantages pendant mes tests) ; la communauté avait commencé à le reprendre et à le nettoyer, puis l'éditeur s'est remis au travail pour en faire un module officiel dans OpenERP 6.1. Je ne l'ai pas testé en profondeur, mais d'après les présentations qu'on m'en a fait et les retours que j'ai pu avoir, il est envisageable de l'utiliser pour des cas simples :

La majorité des PMEs (sauf peut-être les PME industrielles) ont des immobilisations simples, sans démembrement et amorties en linéaire. Pour les PMEs dans ce cas qui ne sont pas déjà dotées d'un logiciel d'immobilisation, l'utilisation d'OpenERP pour gérer les immobilisations me semble envisageable, même s'il faudra probablement prévoir un peu de temps de développement pour ajouter un système de numérotation des immobilisations (il n'en existe pas dans le module natif) et un rapport correspondant au "Plan d'amortissement", qui n'est pas forcément facile à concevoir !

En ce qui concerne la liasse fiscale, on entend parfois dire "On ne peut pas utiliser la comptabilité d'OpenERP en France car OpenERP 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'OpenERP vers Teledec.fr, nous avons utilisé l'astuce suivante : j'ai développé un petit module OpenERP dénommé account_balance_ebp_csv_export (disponible ici) qui permet d'exporter d'OpenERP 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'ils réfléchissaient à 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'OpenERP en France car OpenERP 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, il 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'OpenERP est utilisable, à plusieurs conditions :

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

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

Quel intégrateur choisir ?

Comme je l'ai indiqué dans la section l'expérience OpenERP de l'auteur, je travaille maintenant chez Akretion, qui est un intégrateur OpenERP ; 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 OpenERP :

Choisir OpenERP, 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 entraine 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é OpenERP.

Vais-je faire des économies en choisissant OpenERP 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 OpenERP 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 OpenERP 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'OpenERP 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 OpenERP pour élargir le périmètre fonctionnel natif d'OpenERP.

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'OpenERP sera important.

Mais, sur le moyen-long terme, OpenERP devrait se révéler plus économique. Cette source d'économie n'est pas spécifique à OpenERP 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'OpenERP car, comme expliqué dans la section les modules officiels : le minimum dans chaque domaine, on ne fait pas énormément de choses avec un OpenERP out-of-the-box.

Le mot de la fin

Pour ceux qui n'ont pas encore d'expérience avec OpenERP 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'OpenERP 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'OpenERP 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'OpenERP qui peuvent sembler effrayants pour une personne qui envisage de déployer OpenERP (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 OpenERP 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é OpenERP. 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'OpenERP.

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 : Relecture Révision Correction - Les Tropes de Charlotte.