Promouvoir et soutenir le logiciel libre

Expérience de déploiements 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 OpenERP et/ou me signaler une erreur ou une faute d'orthographe dans le document.

Introduction

Ce document a pour objectif de faire profiter les personnes envisageant un déploiement d'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, en attendant une section dédiée à ce sujet.
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.

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 trésorier 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. Entre le passage en production le 1er Janvier 2009 et aujourd'hui, nous avons ajouté :

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.

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ébâts 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 optionnel 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.

Les développeurs travaillent maintenant à la préparation d'OpenERP version 8.0, dont la principale nouveauté technique sera l'introduction d'une nouvelle API pour le développement des modules (cette API était intialement annoncée pour OpenERP 7.0, mais elle a été repoussée à OpenERP 8.0). Cette nouvelle API promet de corriger les limitations et les défauts de l'API actuelle ; l'API actuelle continuant d'être supportée. Autre changement important : la gestion des stocks a été ré-écrite pour OpenERP 8.0.

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 a plusieurs objectifs :

Le travail le plus visible de l'association au quotidien consiste à maintenir des branches communautaires thématique qui rassemblent des modules communautaires utiles et de qualité qui ont vocation à être largement déployés et dont vous trouverez la liste ici. Ces branches, dites branches 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 proposition de merge sur la branche 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'ojection valable, alors une personne membre du groupe OpenERP Community Reviewers fusionne la branche de développement dans la branche OCA.

Le lancement des projets/branches OCA a également 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 branches/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 branches 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 :

Les branches OCA connaissent actuellement un succès important et les développeurs de la communauté les ont largement adoptées. A tel point que les reviewers de la communauté ont du mal à faire face à l'afflux de merge proposals sur les branches OCA. Il faut certes se réjouir de ce succès, mais également prendre des mesures pour réduire l'embouteillage de merge proposal, pour éviter que les développeurs de la communauté se démotivent et se détournent des branches OCA.

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 trois 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).

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) :

Pour ceux qui voudraient suivre de plus près l'actualité d'OpenERP, les autres sources d'information, par ordre d'importance, sont :

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 : 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).
  • 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 merge proposal à l'éditeur (qui ne prend pas toujours assez de temps pour les traiter !). La communauté OpenERP est très probablement 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 face à l'éditeur.
  • Une marque (OpenERP) et une image qui s'est beaucoup professionnalisée, même si l'éditeur ne publie pas beaucoup de success stories (la raison invoquée étant la difficultée d'obtenir l'autorisation de l'entreprise utilisatrice).
  • Une seule version d'OpenERP est disponible, entièrement libre et gratuite. Il n'y a pas une version "Entreprise" payante et une version "Communautaire" gratuite avec des fonctionnalités en moins, comme Pentaho ou JasperSoft par exemple.
  • la licence AGPL qui contamine les modules ; les modules distribués sont forcément AGPL. Il n'y a donc pas de modules payants sur OpenERP, contrairement à PrestaShop ou Magento par exemple. Cf le chapitre la licence et les copyrights.
  • 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.
  • La priorité n'est pas assez mise par l'éditeur sur l'amélioration du fonctionnel et la correction des "bugs fonctionnels", par rapport à d'autres fonctionnalités plus bling-bling comme par exemple l'ajout d'une messagerie instantannée dans 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 merge proposals communautaires sur les branches officielles de développement, alors même que l'éditeur se réserve le monopole des commits sur ces branches.
  • Les bugs fixés pour les clients ayant souscrit au contrat de maintenance de l'éditeur sont censés être fusionnés dans la branche stable d'OpenERP par l'éditeur, mais celui-ci accusait un énorme retard sur ce point dans OpenERP 6.1, ce qui ralentissait fortement la stabilisation de la branche stable d'OpenERP et ne permettait pas de mutualiser les efforts de bug fix sur la version stable d'OpenERP au niveau mondial. Heureusement, l'éditeur s'est beaucoup amélioré sur ce point avec OpenERP 7.0.
  • 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
  • Devenir le leader des ERPs OpenSource.
  • Développement de scripts de migration communautaires avec le projet OpenUpgrade.
  • 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.
  • Mauvaise gestion des copyrights par l'éditeur sur les modules officiels qui pourrait amener des contributeurs de la communauté à contester la validité de la licence, cf le chapitre la licence et les copyrights.

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.

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

  1. le serveur OpenERP, dont le code source est disponible sur le projet Launchpad openobject-server (OpenObject est l'ancien nom donné au framework d'OpenERP, mais comme cela était source de beaucoup de confusion car beaucoup de gens se demandaient quelle était la différence entre OpenObject et OpenERP, cette appellation a été officiellement abandonnée, mais le nom "technique" du projet Launchpad n'a pas été modifié),
  2. l'interface Web, qui vient s'intégrer dans le serveur, et dont le code source est disponible sur le projet Launchpad openerp-web (comme l'interface Web a été entièrement réécrite from scratch pour OpenERP 6.1, un nouveau projet Launchpad a été créé à cette occasion, et il porte donc un nom sans l'appellation OpenObject),
  3. les modules officiels, appelés addons, dont le code source est disponible sur le projet Launchpad openobject-addons,
  4. les modules communautaires maintenus par l'OpenERP Community Association, qu'on pourrait appeler les modules "communautaires officiels",
  5. les autres modules communautaires, qui ne sont pas gérés par l'association.

Les 3 premiers composants (le serveur, l'interface Web et les modules officiels dits addons) sont maintenus 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. Plus précisément, dans l'organisation actuelle, les développeurs du département R&D de l'éditeur ont le droit de commiter sur les branches trunk, i.e. les branches de développement qui constitueront la prochaine version d'OpenERP, alors que les développeurs du département Support ont le droit de commiter sur les branches stables i.e. les branches correspondant aux versions déjà releasées d'OpenERP (version 6.0, 6.1 et 7.0).

Les deux derniers composants (les modules communautaires) restent la propriété de son ou ses auteurs. Pour les branches communautaires maintenus par l'OpenERP Community Association, seuls les membres du groupe OpenERP Community Reviewers ont les droits de commit ; pour les autres branches communautaires, les droits de commit sont spécifiques à chaque projet.

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 permet de développer des modules privés i.e. des modules dont l'utilisateur ne pourra pas exiger le code source. Cette possibilité demeure très encadrée car la licence prévoit que, si le module en question est distribué à un tiers, alors il doit être distribué sous la licence AGPL normale. Elle a été introduite à la demande de certaines grosses entreprises utilisatrices d'OpenERP qui souhaitent garder privés certains modules développés par leurs soins (sinon, ces modules auraient été "contaminés" par la licence AGPL), car elles affirment que certains modules qu'elles ont 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 introduit la possibilité de développer des modules privés sous certaines conditions, une polémique a éclaté au sein des développeurs de la communauté OpenERP. Cette polémique a permis de souligner deux points importants.

Le premier point concerne 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 devient soumis à la licence AGPL normale sans la clause "private use". Autrement dit, si vous avez souscrit à un contrat de maintenance et que vous utilisez des modules communautaires, vous ne pourrez 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 nécessite des explications complémentaires ; il a trait à la détention du copyright sur les 3 composants maintenus par OpenERP S.A. (le serveur, l'interface Web et les modules officiels dits addons). Si un membre de la communauté souhaite modifier le code source d'un des composants maintenus par OpenERP S.A. :

Par ces deux moyens, du code source écrit par des développeurs de la communauté se retrouve dans un des composants maintenus par l'éditeur. Comme l'éditeur n'a pas mis en place de contributor agreement spécifiant que le copyright des contributeurs de la communauté est transféré à l'éditeur quand leur code source est accepté dans l'un des composants maintenus par l'éditeur, il y a donc à la fois le copyright de l'éditeur et le copyright de certains développeurs de la communauté sur ces composants. Certes, sur ces composants, l'éditeur possède de très loin la plus grosse partie du copyright, mais il y a quand même dans les faits une petite partie de copyright détenue par des développeurs de la communauté.

Or l'éditeur semble considérer qu'il possède l'intégralité du copyright sur ces 3 composants puisqu'il se permet de changer la licence sans demander l'accord préalable des développeurs de la communauté ayant apporté des contributions à l'un de ces composants. Cela engendre un risque : si vous détenez un contrat de maintenance et que vous utilisez la possibilité qui vous est offerte de développer des modules privés, un ou plusieurs contributeurs de la communauté ayant apporté des contributions à un ou plusieurs de ces 3 composants pourrait vous poursuivre pour violation de licence, car vous utilisez la licence AGPL + private use alors que ces contributeurs peuvent prétendre que le code qu'ils ont contribué est sous licence AGPL normale.

Il est étonnant que l'éditeur d'OpenERP ne prenne pas plus 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. Certes, mettre en place un contributor agreement et obliger tous les contributeurs réguliers et occasionnels de la communauté OpenERP à le signer pour pouvoir intégrer leur code dans l'un des composants maintenus par l'éditeur est une tâche fastidieuse au quotidien, mais beaucoup de projets libres s'y astreignent, comme les projets KDE et Asterisk par exemple.

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 !

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 Launchpad GeoEngine addons.

Les défauts du framework

Il est rare de trouver un framework parfait et celui d'OpenERP n'est pas exempt de défauts. En voici les plus embêtants :

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 : lien vers l'article.

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
RML intégré dans le serveur OpenERP + module officiel base_report_designer. C'est le moteur par défaut. OpenERP S.A. Codage manuel en RML ou conception dans OpenOffice SXW, HTML, PDF, TXT
Jasper projet openerp-jasperserver de Syleam ou projet openobject-jasper-reports de NaN-tic Syleam (intégrateur français) et NaN-tic (intégrateur espagnol) 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, PDF, HTML, DOC, ...
Webkit module report_webkit, devenu un module officiel avec OpenERP 6.0 Camptocamp (intégrateur suisse) Editeur HTML 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 RML - le 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 :

Au final, il y a 2 cas où le moteur de rapport par défaut d'OpenERP donne des résultats satisfaisants :

Prenons par exemple le cas du rapport des devis. Certaines sociétés veulent laisser à leurs commerciaux la possibilité de modifier autant qu'ils veulent le rapport de devis tel qu'il est généré par l'ERP. Dans ce cas, le rapport de devis sera configuré pour sortir au format SXW et le moteur de rapport par défaut d'OpenERP donnera satisfaction ; quand le commercial cliquera sur le bouton "Rapport de devis" dans le client OpenERP, le LibreOffice installé sur son poste se lancera et ouvrira le fichier SXW généré par l'ERP ; il pourra lors le modifier autant qu'il voudra, l'exporter dans n'importe lequel des formats supportés par LibreOffice et l'envoyer à son prospect. Si, par contre, la société ne souhaite pas que les commerciaux puissent modifier les devis générés par l'ERP (c'est le cas le plus courant, car sinon on court le risque que le commercial modifie manuellement dans LibreOffice des informations essentielles du devis, et que le devis envoyé au client ne corresponde plus au devis stocké dans l'ERP en terme de produits, de prix ou de quantités par exemple), alors le rapport de devis sera configuré pour sortir au format PDF (c'est d'ailleurs le cas par défaut). La société voudra certainement personnaliser la mise en page et le style des devis générés par OpenERP... et là les problèmes commencent :

  1. Le développeur du rapport va personnaliser la mise en page et le style du rapport dans LibreOffice,
  2. ensuite, il va uploader le nouveau rapport sur le serveur OpenERP,
  3. enfin, il se connectera via le client OpenERP pour voir le résultat sur un devis particulier... et il constatera amèrement que sa super mise en page et les jolis styles qu'il avait utilisés lors de la conception auront été massacrés.

J'ai passé des dizaines d'heure à jouer à ce petit jeu. Ce n'était pas rigolo du tout ! A cette époque, il n'y avait pas encore d'alternative communautaire au moteur de rapport par défaut d'OpenERP... vous comprenez maintenant pourquoi la communauté OpenERP était si motivée pour développer des alternatives, ce qu'elle a fait en profusion !

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 désormais

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 :

En résumé :

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 seulement 2 formats de sortie possible :

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é :

Je n'ai encore jamais utilisé le moteur de rapport Webkit, même si je pense que c'est certainement un bon moteur de rapport pour OpenERP. Comme le prouve le présent document, je suis assez mauvais en HTML/CSS, et l'idée de devoir développer en HTML/CSS un document qui doit in fine être en A4 m'a toujours paru être un truc incroyable... mais c'est sûrement parce que je ne connais pas toute l'étendue des possibilités de CSS !

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 en mode headless 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 avec bazaar, qui est l'outil de gestion de version de Launchpad.

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...

OpenERP avait lancé un projet pour développer en propre des fonctionnalités de BI (on retrouve ici le vieux défaut de l'éditeur qui avait tendance à redévelopper des briques logicielles déjà existantes en libre), mais il n'était pas allé jusqu'au bout du projet, qui a depuis été abandonné. Il est possible de développer des graphiques directement dans OpenERP, mais les possibilités sont très limitées, à tel point que l'éditeur a redéveloppé from scratch la vue des graphiques dans OpenERP 7.0, cf ce post sur le blog officiel.

Il existe de nombreuses solutions OpenSource de Business Intelligence, les quatre plus connues et matures étant :

Sur les conseils de Sylvain Decloix d'ATOL CD (qui tient le blog OSBI.fr), Anevia a opté pour Pentaho. Anevia a fait le choix de Pentaho car c'est la solution qui propose le plus de fonctionnalités dans sa version OpenSource gratuite. En effet, les trois premières solutions listées ci-dessus ont une version OpenSource gratuite (aussi appelée version communautaire), et une version "Enterprise" payante qui propose plus de fonctionnalités ; un tableau à la fin de ce post sur le blog OSBI.fr donne la liste des fonctionnalités disponibles dans la version communautaire de ces solutions. Akretion a depuis également adopté Pentaho pour les fonctionnalités de BI chez ses autres clients.

La fonctionnalité la plus utilisée est l'OLAP, qui est une sorte de tableau croisé dynamique qui puise ses données directement dans une base de donnée. Mais il est aussi possible d'utiliser Pentaho pour développer des rapports avec des graphiques compliqués, des tableaux de bord, des meta-datas à la "Business Objects", etc... Je ne vais pas rentrer en détail dans les fonctionnalités BI de Pentaho, car ce n'est pas l'objet de ce document, mais je voulais insister sur le fait que, si vous voulez avoir des fonctionnalités de BI plus avancées que le minimum vital fourni par OpenERP, il faudra vous intéresser aux solutions de BI OpenSource.

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 OpenERP Apps. Ce site permet de rechercher des modules par mots clés et de voir leur description et la branche Launchpad dans laquelle ils se trouvent. Ce site ne référence pas les modules OpenERP qui seraient uniquement disponibles sur Github ou BitBucket par exemple.

Une des choses qui m'énerve le plus dans le discours qu'on peut entendre sur OpenERP est "qu'il y a 3000 modules fonctionnels disponibles". Il y a effectivement plus de 3400 modules référencés sur OpenERP Apps, donc cette affirmation n'est a priori pas mensongère en sens strict. Sur les 3400 modules, il y a les 200 modules officiels qui sont maintenus par l'éditeur, 330 modules OCA, et 2870 autres modules communautaires (ce dernier chiffre a été obtenu par simple soustraction par rapport aux deux premiers). Sur ces 2870 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 ; il y a notamment certains modules de Camptocamp et le connecteur Magento-OpenERP qui est co-maintenu par Camptocamp et Akretion.

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 quasiment 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 par exemple la raison pour laquelle ma société, Akretion France, a choisi de développer et maintenir deux verticalisations d'OpenERP pour deux secteurs d'activité :

Akretion France ne réalise des déploiements OpenERP que dans l'un de ces deux secteurs d'activité. Cela permet aux sociétés de ces secteurs d'activité de ne pas financer trop de développements spécifiques et d'avoir ainsi un coût d'entrée raisonnable sur OpenERP, tout en ayant une bonne couverture fonctionnelle pour leur activité.

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 ordes 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 des branches stables communes, dénommées OpenERP Community Branches, alias OCB. Il en existe une pour chaque projet :

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

Je vais prendre comme exemple la façon dont Anevia utilise la comptabilité d'OpenERP, que j'ai 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 d'Anevia est gérée dans un logiciel dédié (en l'occurrence une plateforme de paye en mode SaaS), 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.

A Anevia, les immobilisations sont également gérées dans un logiciel dédié (en l'occurrence 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 ! Dans le cas d'Anevia, le module account_asset serait a priori suffisant moyennant ces deux développements supplémentaires, mais Anevia s'était déjà doté d'un logiciel d'immobilisation avant la migration vers OpenERP 6.1 en Juillet 2012.

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.

Si vous souhaitez en savoir plus sur les logiciels de liasse fiscale, qui sont généralement des logiciels propriétaires pour Windows, voici quelques noms pour vous aider dans vos recherche :

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.

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 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é, propre aux ingénieurs non commerciaux, 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.