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 :

- pour le métier de cette société, il n'existe pas de solution adaptée et disponible out-of-the-box sans nécessiter des développements spécifiques parmi les logiciels métier ou les ERPs propriétaires à un coût raisonnable,

- pour le métier de cette société, il existe une verticalisation d'OpenERP mature et bien maintenue,

- la société a des postes de travail Linux ou Mac qui ont besoin d'avoir accès à l'ERP (très peu d'ERPs propriétaires ont un client Linux ou Mac ou une interface Web iso-fonctionnelle qui fonctionne sur autre chose qu'Internet Explorer... à l'exception des ERPs propriétaires en mode SaaS),

- la société dispose de compétences informatiques en interne, qui sont capables de s'approprier OpenERP et de faire en interne certaines adaptations ou certains développements spécifiques simples (voir plus, selon les compétences en développement Python).

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

- Vous avez beaucoup plus de libertés vis-à-vis de l'éditeur que si vous aviez choisi un ERP propriétaire. L'éditeur peut donc difficilement abuser de sa position dominante et organiser un racket collectif, comme cela s'est déjà vu dans le monde des ERPs propriétaires (par exemple chez SAP, cf cet article ou celui-ci ou encore chez Oracle, cf cet article en anglais).

- Vous êtes libre de souscrire ou pas au contrat de maintenance de l'éditeur. Contrairement à un ERP propriétaire, vous ne serez pas soumis à un chantage du type "Si vous ne souscrivez pas au contrat de maintenance de l'éditeur, vous n'aurez pas accès aux mises à jour requises par les évolutions réglementaires" ou autre argument fallacieux du type "Imaginez que vous rencontriez un bug qui vous empêche soudain d'éditer vos factures client... !". Comme le code source est ouvert, vous pouvez corriger les bugs vous-même ou les faire corriger par une personne sans lien avec l'éditeur ayant le niveau technique requis.

- Vous serez doté d'un ERP ouvert et moderne, entièrement pilotable via XML-RPC et reposant sur des composants libres et standards (PostgreSQL, Python, ...). Si vous avez besoin de faire des échanges de données avec un logiciel tiers, votre travail devrait en être largement facilité et le coût allégé. Certains ERPs propriétaires font payer très cher l'accès à leurs APIs de développement, ce qui renchéri d'autant le coût de mise en place d'une passerelle d'échange de données avec un logiciel tiers. Je pense par exemple à Salesforce, qui est un logiciel de CRM en mode SaaS, et qui facture très cher la possibilité d'accès à ses APIs : il faut être au niveau Enterprise pour avoir accès aux APIs, or ce niveau est deux fois plus cher que le niveau Professional qui est généralement adopté par les PMEs, cf le pricing Salesforce.

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.

Alexis de Lattre

Pour accéder au document complet :
Retour d'expérience de déploiements OpenERP