Memoire Yannick Buron - SUPINFO 2011

65
La création d’une entreprise d’intégration OpenERP Mémoire de fin d’étude Yannick Buron 07/09/2011

Transcript of Memoire Yannick Buron - SUPINFO 2011

La création d’une entreprise d’intégration

OpenERP

Mémoire de fin d’étude

Yannick Buron

07/09/2011

2

Document sous Licence Creative Common By-Sa – Yannick Buron

Table des matières Introduction ............................................................................................................................................. 3

Présentation de la société SYNERPGY ..................................................................................................... 4

Contexte général du marché des ERPs .................................................................................................... 5

Problématique générale des logiciels de gestion ................................................................................ 5

ERPs propriétaires et ERPs libres ....................................................................................................... 12

Pourquoi OpenERP ? ......................................................................................................................... 18

Créer son entreprise d’intégration d’OpenERP ..................................................................................... 22

Choix de la structure et formalités .................................................................................................... 22

Choix des services proposés .............................................................................................................. 26

Positionnement sur le marché .......................................................................................................... 30

Positionnement commercial ............................................................................................................. 33

Prospection .................................................................................................................................... 33

Discours commercial, proposition et négociation ......................................................................... 35

Compétences nécessaires ................................................................................................................ 38

Méthodologie .................................................................................................................................... 41

Choix et stratégie de la société SYNERPGY depuis sa création, et autocritique ................................... 52

L’environnement d’OpenERP ................................................................................................................ 56

Le modèle économique de l’éditeur d’OpenERP .............................................................................. 56

Les limites d’OpenERP ....................................................................................................................... 59

Réflexions sur l’avenir ........................................................................................................................... 63

Conclusion ............................................................................................................................................. 65

3

Document sous Licence Creative Common By-Sa – Yannick Buron

Introduction

Les logiciels de gestion font partie des problématiques les plus importantes dans le parc informatique

d’une entreprise et nombreux sont les logiciels qui ont voulu apporter des réponses. Etant moi-

même attiré par cette problématique et par le logiciel libre, j’ai vu il y a deux ans une opportunité

avec le logiciel OpenERP qui deviendra certainement dans quelques années une réelle alternative aux

logiciels propriétaires.

C’est pourquoi j’avais décidé, en parallèle de mes études, de créer à ce moment là avec quelques

amis ma propre société d’intégration d’OpenERP, et voir ensuite ce qu’il adviendrait. Ce fut une

expérience passionnante, extrêmement intéressante et formatrice, mais également très difficile. Les

obstacles sont nombreux lorsque l’on veut créer une entreprise, et bien plus encore quand on choisit

un secteur tel que les logiciels de gestion et un produit qui évolue autant qu’OpenERP.

Aujourd’hui, je profite de la rédaction de mon mémoire de fin d’étude pour coucher par écrit tout ce

que j’ai appris, mes réflexions, ce auquel je crois, dans l’espoir que les personnes qui liront ce

document et souhaiterons également s’investir dans OpenERP ne fassent pas les mêmes erreurs que

j’ai pu faire.

Le sujet de ce mémoire sera donc la création d’une entreprise d’intégration sur OpenERP, les choses

à savoir, à faire et à éviter.

Dans un premier temps je donnerai ma vision sur le marché des logiciels de gestion et ce en quoi

OpenERP est une opportunité dans le contexte actuel. J’attaquerai ensuite dans le vif du sujet en

présentant les différentes problématiques de la création d’une entreprise sur OpenERP, des

formalités de création à la méthodologie, en passant par les compétences nécessaires et le

positionnement commercial. Enfin je terminerai par un résumé de mes propres expériences avec

SYNERPGY et des réflexions sur l’avenir d’OpenERP.

4

Document sous Licence Creative Common By-Sa – Yannick Buron

Présentation de la société SYNERPGY

La société SYNERPGY est une société d’intégration d’OpenERP sous la forme d’une SARL. Elle fut

créée en juin 2008 lors de ma première expérience entreprenariale, un site d’e-commerce.

Devant le peu de succès de celui-ci, je décidais de rechercher d’autres opportunités pour la société et

c’est ainsi que j’ai commencé à m’intéresser à OpenERP. En juillet 2009, la première société change

de nom pour devenir SYNERPGY, dont le nom qui associe ERP et synergy1 a vocation à évoquer les

actions de toute la communauté d’OpenERP et comment ceux-ci influent sur l’évolution du logiciel.

On retrouve cette même symbolisation sur le logo de la société.

Etant plutôt sur un positionnement généraliste, avec une petite spécialisation sur les ERP couplés à

des sites d’e-commerce, la société a surtout tenté de se différentier via la création de documents de

spécifications et d’une méthodologie d’intégration adaptée spécifiquement à OpenERP, des actions

d’organisation de la communauté et un discours commercial mettant en avant les avantages du

logiciel libre pour la problématique des logiciels de gestion.

1 Synergie en anglais.

5

Document sous Licence Creative Common By-Sa – Yannick Buron

Contexte général du marché des ERPs

Problématique générale des logiciels de gestion L’organisation et le choix de ses logiciels de gestions est l’une des principales problématiques

informatiques qui se pose aux entreprises, tous secteurs confondus.

En effet, que ce soit pour des besoins communs à la majorité des entreprises (Comptabilité, gestion

de la facturation, des stocks, des commerciaux etc…) ou pour des besoins spécifiques à l’entreprise

utilisatrice, le logiciel de gestion déterminera la procédure de travail et souvent la productivité des

employés du département de l’entreprise où il est utilisé. Les logiciels de gestion ont permis de

passer d’une gestion entièrement matérielle via des traitements papiers et donc des procédures

lourdes, des pertes d’informations et des coûts d’archivage importants à un système de données

centralisé et sécurisé, et surtout permettant de réduire la saisie et le traitement des informations au

strict minimum. C’est principalement grâce à eux que l’informatique est considérée comme un grand

progrès dans l’amélioration des procédures de travail dans les entreprises et on retrouve ces logiciels

de gestion sous des formes très différentes.

Pour autant, il s’agit également d’une des problématiques les plus complexes à gérer et la méthode

utilisée peut avoir des conséquences importantes sur cette complexité.

L’une des deux principales méthodes concernant l’organisation de ses logiciels de gestion consiste

notamment à prendre pour chaque département de l’entreprise le logiciel le plus adapté à celui-ci2.

Le principal avantage de cette approche est qu’il permet d’adapter le plus possible le logiciel de

gestion au fonctionnement de l’entreprise car c’est chaque département qui aura la possibilité de

choisir le logiciel qui lui correspond le plus, facilitant d’autant l’acceptation du logiciel par les équipes

et le temps de mise en place de la solution. Ils auront même la possibilité, si aucune solution du

commerce ne leur convient ou a un coût trop important, à demander le développement d’un logiciel

spécifique qui sera parfaitement adapté à leur méthode de travail.

Un mot sur les avantages et les inconvénients des développements spécifiques : Les développements

spécifiques disposent d’avantages intéressants en terme de contrôle sur le produit, tant en terme de

coût que de fonctionnalité. En effet, via l’utilisation d’un logiciel géré par un éditeur, la société client

subira complètement les choix de l’éditeur en termes de politique tarifaire et d’orientation

fonctionnelle. Il pourra ainsi augmenter ses tarifs de licences annuelles ou partir dans

l’implémentation d’un processus très éloigné des méthodes de travail de l’entreprise sans que celle-

ci n’ait aucun moyen de s’y opposer.

Inversement, les logiciels spécifiques impliquent de garder au moins une personne en interne

connaissant le logiciel et comment le maintenir ce qui peut souvent poser d’importants problèmes si

cette personne venait à partir. Nous dresserons plus tard un parallèle avec les logiciels libres et

verront comment ceux-ci permettent de profiter des avantages des développements spécifiques tout

en évitant leurs inconvénients.

2 Par exemple Cegid pour la comptabilité, Sage pour la gestion commerciale, Salesforce pour la prospection, un

logiciel développé en interne pour la gestion de la production etc…

6

Document sous Licence Creative Common By-Sa – Yannick Buron

L’approche consistant à partir sur un parc de logiciels adaptés à chaque département de l’entreprise

est appelée l’approche « Best of Breed » expression anglaise signifiant grossièrement qu’on prend ce

qui se fait de mieux dans chaque domaine.

Cette approche présente ainsi d’importants avantages en termes d’adéquation du logiciel avec

l’entreprise mais présente aussi des inconvénients, principalement au niveau de la synchronisation

des informations.

En effet les logiciels de gestions ont généralement des informations en communs3 ou ont besoin de

faire référence à des données d’un autre logiciel4, ce qui implique de synchroniser les informations.

Le problème, c’est qu’il faut souvent synchroniser chaque logiciel avec chaque autre logiciel du parc

informatique, nécessitant de créer des dizaines de synchronisations et aboutissant à ce qu’on appelle

un « effet spaghetti », quand le nombre de synchronisation devient tellement important qu’ils

deviennent pratiquement impossible à maintenir. Il s’agit d’une situation catastrophique qui doit à

tout prix être évité.

Figure 1 Illustration de l'effet spaghetti. Extrait des cours d'ERP à SUPINFO.

Pour cette raison, de plus en plus de sociétés abandonnent l’approche « Best of Breed » au profit

d’autres solutions, notamment les ERPs. Il reste néanmoins pour les sociétés utilisant cette approche

une solution : les logiciels d’EAI. Ceux-ci agissent en effet comme une sorte de logiciel de messagerie,

transférant les données aux logiciels qui en ont besoin.

Concrètement, au lieu d’avoir à développer une synchronisation entre chaque logiciel, il suffira de

3 Par exemple la base client ou la base produit.

4 Par exemple une écriture comptable doit pouvoir être reliée à la facture qui peut être située dans le logiciel

de gestion commerciale.

7

Document sous Licence Creative Common By-Sa – Yannick Buron

faire une synchronisation entre l’EAI et chaque logiciel, et celui-ci se chargera ensuite d’organiser les

transferts d’informations. On peut ainsi facilement éviter l’effet spaghetti grâce à ce genre de

logiciel.

Figure 2 Illustration d'une infrastructure "Best of Breed" avec EAI. Extrait des cours d'ERP à SUPINFO.

Ceci clôture ma présentation de la première méthode de conception du parc de logiciel de gestion,

l’approche « Best of Breed » et les EAIs. Nous allons maintenant passer à la deuxième méthode qui

représente également le sujet central de ce mémoire : Les ERPs.

ERP signifie « Enterprise Resource Planning » en anglais, le terme français étant PGI, « Progiciel de

gestion intégré ». Le terme français est un peu plus explicite à mon sens en ce qu’il utilise le terme

« intégré » résumant à lui seul cette méthode : Il s’agit, au lieu d’utiliser tout un parc de divers

logiciels spécialisés pour gérer la société, d’en utiliser un seul qui saura tout faire. Les ERPs sont en

effet capables de gérer toutes les fonctions les plus communes aux sociétés, tels la comptabilité,

gestion commerciale, gestion des stocks, projets, RH, fabrication etc…

8

Document sous Licence Creative Common By-Sa – Yannick Buron

Figure 3 Illustration de la couverture fonctionnelle d'un ERP. Extrait des cours d'ERP à SUPINFO.

Le principal avantage de cette approche apparait instantanément : Il n’y a plus aucun besoin de

synchronisation. Tout est géré directement par le logiciel qui récupère et utilise les données d’une

manière bien plus efficace que n’importe quelle synchronisation, et en pratique cela facilite

considérablement la communication entre les différents départements de l’entreprise.

Mais le principal inconvénient était également le principal avantage du « Best of Breed » : Il devient

extrêmement difficile de trouver un produit qui réponde aux exigences et corresponde aux

procédures de travail de chaque département de l’entreprise et donc l’adéquation du logiciel ne

saurait être aussi important qu’avec l’approche « Best of Breed ». C’est de là que vient le reproche

communément fait aux ERPs : « C’est l’entreprise qui s’adapte à l’ERP et non l’inverse ».

Pour tenter de compenser ce défaut dépendant de la nature même des ERPs, de nombreux éditeurs

se sont spécialisés dans des secteurs d’activités précis (Untel pour les sociétés de communication, un

autre pour les experts-comptables, etc…). On dit de ces ERPs qu’ils sont des ERPs « verticaux »,

fortement adaptés à un secteur mais surement pas à un autre. C’est ainsi qu’on retrouve plusieurs

centaines d’ERPs de part le monde, en faisant l’un des secteurs de l’informatique les plus riches

même si la majorité d’entre eux sont très peu connus.

Si vous recherchiez une solution ERP pour votre société, vous seriez certainement bien inspiré de

rechercher l’un de ces ERPs dédiés spécifiquement à votre secteur d’activité, en le sens que cette

spécialisation permet de compenser les faibles chances d’adéquation inhérent aux ERPs. Attention

néanmoins, les éditeurs de ses solutions sont souvent de petites structures et une faillite de celui-ci

constitue une catastrophe pour l’ensemble de leurs clients, ceux-ci se retrouvant du jour au

lendemain sans mise à jour ni support et il sera très difficile de trouver des personnes aptes à

intervenir dessus.

9

Document sous Licence Creative Common By-Sa – Yannick Buron

A l’inverse, les éditeurs ERPs généralistes5 implémentent les fonctionnalités d’une manière devant

prendre en compte les besoins de tous les secteurs d’activités possibles. Les chances d’adéquation

sont dans ce cas vraiment minimales et l’important budget marketing de ces sociétés ne devrait pas

masquer l’existence des centaines d’autres ERPs peut-être plus adaptés. A leur décharge néanmoins,

l’important budget en R&D de ces sociétés permet également de baser l’ERP sur une meilleure

technologie et de développer les fonctionnalités de manière plus poussée que pour des éditeurs plus

petits.

Toute la question pour la société cliente souhaitant partir sur un ERP est alors de faire le choix entre

un ERP fort et rassurant, avec des fonctionnalités poussée utilisés par des milliers de sociétés mais

avec de faibles chances de parfaite adéquation et un éditeur inflexible ayant tout pouvoir sur son

produit, et un ERP plus petit et spécialisé, peut-être moins stable financièrement mais avec des

fonctionnalités spécialisées dans son secteur et un éditeur déjà plus prompt à écouter les remarques

de ces clients.

Pour terminer cette partie sur la problématique générale des logiciels de gestion, je vais vous

présenter une autre manière de classer les ERPs. Nous avons vu qu’il est possible de les classer entre

ERPs spécialisés et généralistes, mais il est également intéressant de les classer en fonction du type

d’entreprise utilisatrice visée :

Les ERPs visant les TPEs6. On peut notamment citer des logiciels tels que Ciel et EBP et la

majorité des ERPs spécialisés qui misent souvent plus sur le nombre de clients que sur leur

budget ERP.

J’hésite vraiment à les qualifier d’ERP car les ERPs doivent posséder un minimum de

flexibilité pour pouvoir faire des développements spécifiques et adapter au moins un peu

l’ERP à la société. Or ces produits sont des logiciels complètement packagé, prêt à l’emploi,

mais totalement non-modifiables. Ils sont intéressants pour des petites structures souhaitant

avoir un logiciel de gestion à moindre coût7 mais doivent être à tout prix évité par les

structures plus importantes qui n’auront sur ces produits là vraiment aucun contrôle sur leur

logiciel de gestion.

Par ailleurs, ces logiciels manquent de fonctionnalités importantes tels la gestion de projet,

feuilles de temps, fabrication, gestion des stocks trop faible etc… Comme ils peuvent

néanmoins implémenter d’importantes fonctions comme la comptabilité, gestion

commerciale et CRM, et ceci de manière intégré ce qui correspond à la définition d’un ERP

on peut les considérer comme des ERPs mais attention ce ne sont vraiment pas des produits

conseillés une fois que la structure commence à dépasser la dizaine d’employés.

Enfin, précisons que ces critiques visent principalement Ciel et EBP, les ERPs spécialisés visant

les TPEs étant trop nombreux pour pouvoir faire une généralisation sur eux.

5 Souvent les plus connus, tels Sage, Cegid, SAP etc…

6 Très petites entreprises, moins de 10 personnes.

7 Souvent un millier d’euros.

10

Document sous Licence Creative Common By-Sa – Yannick Buron

Les ERPs visant les PMEs8. On peut notamment citer Sage, Cegid, Microsoft Dynamics et la

majorité des ERPs spécialisés qui peuvent souvent correspondre à la fois aux TPEs et aux

PMEs grâce à leurs chances d’adéquation plus importantes.

Comme précédemment, mes commentaires concernant surtout les principaux noms du

secteur. Ces ERPs sont déjà plus complets que ceux à destinations des TPEs, et mérite

pleinement leur titre. Ils sont capables de gérer l’ensemble des besoins des sociétés, y

compris les projets, fabrications, etc… Tout en implémentant les fonctionnalités d’une

manière correspondant à un fonctionnement hiérarchique où tous les employés ont accès à

la partie de l’ERP dont ils ont besoin.

Qui plus est, et bien que celle-ci reste très limitée, il est déjà plus facile de faire les

modifications pour adapter l’ERP à sa société. Attention toutefois, cela reste très difficile et

fera souvent exploser votre budget ERP au-delà de la barre de la centaine de milliers d’euros.

Les frais de licence reviendront généralement à 5000€ suivant la taille de votre structure9

mais il faudra compter au moins 30 000€ si vous avez recours à un intégrateur, ce qui est

fortement conseillé à partir d’une vingtaine d’employé, et il faudra éviter de demander trop

de développements spécifiques.

Précisons que niveau développements spécifiques, Microsoft Dynamics a un important

avantage car il repose sur la technologie .NET qui est bien plus récente que la base

technologique des autres ERPs propriétaires, et qui plus est dispose du savoir-faire Microsoft

en matière de logiciel, qui si il peut être décrié, reste bien plus importante que celle de ses

concurrents du secteur des ERPs pour PMEs.

Les ERPs visant les grandes entreprises. On peut notamment citer l’allemand SAP10,

l’américain Oracle ou le suédois IFS. Les ERPs spécialisés ne sont normalement pas présent

sur ce secteur.

Ici on trouve ce qui se fait de mieux en matière d’ERP, avec des fonctionnalités tellement

poussées qu’elles sont capables de couvrir l’ensemble des secteurs d’activités minimisant le

risque d’inadéquation, avec un logiciel capable d’absorber la charge de milliers de

connexions simultanées et une technologie capable d’adapter facilement l’ERP suivant les

besoins de la société11.

Ces produits sont parfait pour des grandes entreprises mais ne le sont pas pour des PMEs car

ils ont généralement un coût très élevé12 et nécessitent un très important travail de

paramétrage, le prix à payer pour un ERP généraliste capable de couvrir l’ensemble des

secteurs d’activités. C’est notamment pour ces raisons que SAP, pourtant le leader en terme

8 Petites et moyennes entreprises, de 10 à 500 employés pour être large.

9 Prix par utilisateur et par module, suivi souvent de frais de mise à jour pour passer à la version suivante.

10

Le leader du secteur des ERPs. 11

Langage de programmation ABAP pour SAP par exemple. 12

Généralement un million d’euros est un minimum.

11

Document sous Licence Creative Common By-Sa – Yannick Buron

de solution ERP avec 48% sur les grandes entreprises en France en 200613, ne parvient pas à

percer sur le marché des PMEs malgré quelques tentatives14 ses produits sont jugés trop

lourds par les sociétés de cette taille15.

Figure 4 Revenu et part de marché des principaux éditeurs d'ERP, chiffres de 2006. Extrait des cours d'ERP à SUPINFO.

Ceci clôture la présentation de la problématique générale des entreprises en matière de logiciel de

gestion. Dans la prochaine partie, nous verrons que le logiciel libre peut apporter des éléments de

réponses très intéressantes aux différentes problématiques du secteur.

13

http://www.journaldunet.com/solutions/intranet-extranet/indicateurs/erp.shtml 14

http://www.sap.com/france/sme/index.epx 15

http://www.silicon.fr/pmepmi-les-7-peches-capitaux-de-sap-21417.html

12

Document sous Licence Creative Common By-Sa – Yannick Buron

ERPs propriétaires et ERPs libres

Dans la présentation de la problématique générale des logiciels de gestion j’ai volontairement mis de

coté les logiciels libres car je pense qu’ils méritent une partie à part de ce travail.

Je précise que pour cette partie, comme pour la partie suivante présentant OpenERP, je m’appuierai

principalement sur le livre blanc de la société Smile sur les ERPs open-sources, édité en 200916. Non

pas que je souhaite ici en faire un résumé ou une actualisation, mais ce livre est la raison qui m’a

poussé il y a deux ans à lancer ma société d’intégration d’OpenERP, et qui m’a convaincu de son

potentiel. C’est ainsi une des bases importantes de mon discours et je tacherai de lui rendre

hommage dans ce mémoire autant que je le pourrai.

Avant toute chose il convient de définir ce qu’est un logiciel libre : Il s’agit d’un logiciel qui détourne

l’usage normal du droit d’auteur pour accorder un certain nombre de libertés à l’utilisateur, au lieu

de l’en priver.

Un logiciel est ainsi réputé libre lorsque l’utilisateur a17 :

La liberté d’exécuter le programme.

La liberté d’étudier le code source du programme, et donc d’y avoir accès.

La liberté de redistribuer le programme à d’autres personnes.

La liberté de modifier et redistribuer le programme, pour ainsi le faire bénéficier de vos

propres améliorations. Dans la majorité des licences libres, la redistribution du programme

modifié (hors usage personnel) est même une obligation pour empêcher des entreprises peu

scrupuleuses de bâtir un logiciel propriétaire sur la base d’un logiciel libre.

Beaucoup de personnes peuvent se poser la question s’ils existent des logiciels libres dans un secteur

aussi complexe que le domaine des ERPs. Et oui il en existe, beaucoup même. Je peux facilement en

citer une bonne dizaine : OpenERP, OpenBravo, Ofbiz/Neogia, Tryton, Dolibaar, Lundi Matin

business, Xtuple, Adempierre, ERP5, et bien d’autres encore.

Face à ce secteur primordial de l’informatique, mais complètement saturé par d’importants acteurs

propriétaires généralistes d’une part et des centaines de petits éditeurs spécialisés d’autre part, le

logiciel libre représente tout simplement un moyen de différentiation très efficace que de

nombreuses personnes ont su repérer. Ceci d’autant plus que les logiciels libres ont tendance à

générer d’eux-mêmes leur notoriété sans forcément avoir besoin d’un gros budget marketing.

C’est donc pour cette raison que nous avons autant de solution d’ERPs libres actuellement, faire un

produit libre est une opportunité pour l’éditeur d’arriver à exister dans ce marché extrêmement

saturé et difficile. Mais ce n’est pas tout, car les ERPs libres possèdent également d’intéressants

avantages pour les entreprises utilisatrices.

16

http://www.smile.fr/Livres-blancs/ERP-et-decisionnel/ERP-open-source 17

Selon la définition de la Free Software Foundation, à l’origine des licences libres. http://www.gnu.org/licenses/agpl.html .

13

Document sous Licence Creative Common By-Sa – Yannick Buron

Le premier, et le plus important de tous, est la maitrise que l’entreprise utilisatrice a sur son logiciel

de gestion. Sur le plan tarifaire déjà, aucun risque de voir le tarif de licence augmenter d’un an sur

l’autre sans pouvoir réagir, car les frais de licences n’existent pas dans le logiciel libre18.

Sur le plan fonctionnel également, l’entreprise utilisatrice dispose de nombreux moyens pour

s’assurer que le logiciel reste conforme à ses besoins. Elle peut dans un premier temps donner son

avis sur les forums de discussions, et même y gagner une certaine notoriété suivant son degré

d’implication. Si une fonctionnalité n’est pas implémentée comme elle le voudrait, ses

développements spécifiques peuvent facilement être repris par d’autres membres de la

communauté qui peuvent le porter sur la version suivante. Enfin elle peut même provoquer un fork19

du logiciel dans les cas les plus extrêmes et maintenir sa propre version. Les solutions sont

suffisamment nombreuses pour que la société utilisatrice n’ait pas à s’inquiéter sur ce point.

L’autre point important est la flexibilité du logiciel. Les logiciels libres sont souvent des logiciels

jeunes, basés donc sur des technologies plus récentes et plus facile à maitriser. D’autre part, ceux-ci

sont codés de sorte à ce que le code puisse être compréhensible par les autres contributeurs, on a

donc des efforts plus importants pour rajouter différentes couches d’abstraction, commenter le

code, respecter les standards ou tout simplement le rendre le plus simple possible à lire et à

modifier. Il est également beaucoup plus facile de trouver des personnes maitrisant le logiciel pour

faire des développements spécifiques, celui-ci étant ouvert à tous chacun peut l’étudier. Enfin, et

non des moindres, l’accès complet au code source permet d’étudier le cœur même du logiciel,

permettant de comprendre le fonctionnement du logiciel dans sa globalité.

Tout ceci permet de dire que développer des fonctionnalités spécifiques dans un ERP libre prend

beaucoup moins de temps et est beaucoup moins couteux, car il est plus facile de trouver un

développeur, celui coute donc moins cher et il y passe beaucoup moins de temps. L’entreprise

utilisatrice peut plus facilement augmenter son niveau d’exigence et demander à « plier » l’ERP

conformément à ses méthodes de travail. Qui plus est, pour peu que les développements en

question intéressent d’autres sociétés, celles-ci peuvent aider à maintenir les développements, à les

porter sur une nouvelle version de l’ERP etc… Permettant de limiter encore plus les coûts et les

risques pour l’entreprise.

La maitrise sur son logiciel de gestion est capitale pour l’entreprise utilisatrice, de même qu’elle doit

s’assurer d’avoir la possibilité de modifier facilement le logiciel. Ces deux points, qui sont

complètement laissés de coté par les ERPs propriétaires20, constituent les forces des ERPs libres.

18

Le business model se repose principalement sur les services comme les garanties contre les bugs, l’hébergement, l’intégration etc…. 19

Le fork est l’action de s’emparer du code source d’un logiciel libre pour le faire partir dans une direction complètement différente. Cela arrive notamment en cas de désaccord profond avec l’éditeur ou la communauté. 20

En dehors néanmoins des grands ERPs comme SAP. Celui-ci s’assure en effet d’avoir la flexibilité de son coté en proposant un langage de programmation spécifique nommé l’ABAP, pour Advanced Business Application Programming. Néanmoins comme dit plus haut, ces ERPs ne conviennent pas à tous les projets, loin de là.

14

Document sous Licence Creative Common By-Sa – Yannick Buron

Ce ne sont néanmoins pas les seules. On peut également citer des avantages en termes de qualité et

de diversité. Le logiciel libre est un mouvement mondial, et chaque logiciel libre ayant une

communauté forte dispose de milliers de contributeurs, d’expérience et d’origine souvent très

diverses et apportant donc des points de vues très différents. La majorité des éditeurs d’ERPs

propriétaires tentent d’imposer leur procédure en les appelants des « Best practices »21.

Ce n’est pas forcément une mauvaise chose, car cela permet une réflexion sur la meilleure manière

d’implémenter tel ou tel processus, mais ici encore le logiciel libre apporte des éléments intéressants

car la diversité des contributeurs profite à l’élaboration des « Best practices » des ERP libres, tandis

que la société qui ne serait pas d’accord avec le reste de la communauté trouvera facilement des

modules22 implémentant la fonctionnalité de la manière dont il le souhaite, sans forcément répondre

aux « Best practices » du reste de la communauté. Ainsi chacun y trouve son compte.

Bien entendu, un ERP libre présente également des avantages en termes de coût. Il ne faut

néanmoins pas s’attendre à des prix compétitifs de quelques centaines d’euros comme des Ciel ou

EBP. Les ERPs libres ne sont pas actuellement des logiciels prêt à l’emploi, et faire appel à un

intégrateur est indispensable, ce qui est synonyme d’un budget en dizaine de milliers d’euros.

A moins d’être capable de l’intégrer vous-même, un ERP libre n’est pas un bon choix pour une TPE en

termes de coûts. C’est bien plus intéressant pour une PME qui fera là une économie d’au moins 30%

sur le projet par rapport à un ERP propriétaire, grâce à la disparition des frais de licences.

De plus, un ERP libre limite également considérablement l’explosion du budget dès qu’il s’agit de

faire des développements personnalisés, pour les raisons évoqués plus haut. Vous pouvez ainsi vous

permettre beaucoup plus facilement des adaptations pour que votre ERP corresponde vraiment à

votre entreprise.

En moyenne, il est raisonnable de dire qu’un projet d’ERP libre coûtera 60%23 du budget d’un projet

d’ERP propriétaire, en fonction du degré d’exigence de la société utilisatrice. En partant sur un ERP

libre, vous serez perdant en termes de coûts si les développements consistent à implémenter des

fonctionnalités manquantes mais présentes sur les ERPs propriétaires, mais totalement gagnant si

ces fonctionnalités sont tellement spécifiques qu’elles ne sont pas présentes sur les ERPs

propriétaires.

Un dernier point important sur les avantages d’un ERP libre : J’ai évoqué précédemment, concernant

les ERPs spécialisés, le risque pour l’entreprise utilisatrice si l’éditeur venait à faire faillite. Il s’agit là

encore d’une force d’un ERP libre, en effet même dans le cas où l’ERP était supporté par un éditeur

et que celui-ci déposait le bilan, cela n’aurait pour autant que peu de conséquences pour l’entreprise

utilisatrice car elle trouvera toujours aussi facilement des membres de la communauté pour assurer

le support du logiciel, et il est fort probable que le développement du logiciel soit repris par la

communauté.

Avoir un logiciel de gestion libre est ainsi une forte garantie de pérennité que même les plus forts des

éditeurs propriétaires ne sauraient apporter. On peut prendre pour exemple le rachat de PeopleSoft

21

Les meilleures pratiques en anglais. 22

Partie d’un ERP qu’on peut installer ou désinstaller et qui modifie plus ou moins le fonctionnement de l’ERP. 23

Je n’ai pas de source à donner, il s’agit de mon ressenti personnel.

15

Document sous Licence Creative Common By-Sa – Yannick Buron

par Oracle, où les utilisateurs ont vu du jour au lendemain leur interlocuteur changer et ensuite les

prier de passer petit à petit vers les solutions d’Oracle24.

On peut dresser assez facilement un parallèle entre les logiciels de gestion libres et les

développements de logiciels en interne. Comme eux, les ERPs libres apportent les mêmes garanties

en termes de maitrise du produit et de flexibilité, mais en revanche ils apportent également la qualité

et la pérennité du logiciel grâce à sa communauté et éventuellement le suivi d’un éditeur à part

entière. C’est pour cette raison qu’on peut dire qu’un ERP libre apporte tous les importants

avantages d’un développement interne en éliminant néanmoins leurs inconvénients. Je pense

sincèrement qu’il n’y a plus aujourd’hui de justification pour choisir le développement de logiciels en

interne et qu’un ERP libre constitue par nature un bien meilleur choix, sauf éventuellement à vouloir

protéger des méthodes de travail uniques à la société utilisatrice.

Pour autant, et je terminerai cette partie par cette remarque, tout n’est pas forcément en faveur du

choix d’un ERP libre. Certes, par nature il n’y a que des avantages à partir sur une solution libre et les

différents avantages sus-cités vont continuer à prendre de plus en plus d’importance. Néanmoins,

aujourd’hui, les communautés des ERPs libres n’ont pas encore atteint la taille critique et ne sont pas

encore suffisamment organisés pour obtenir la qualité que l’on pourrait en espérer. Il faut dire

qu’organiser une communauté sur un ERP libre est bien plus complexe que pour un autre logiciel

libre car il s’agit d’un logiciel complexe et qui intéresse plus les professionnels que le grand public, et

surtout qui ne nécessite pas tant des compétences en informatique que des compétences métiers.

Par ailleurs, les ERPs libres ont actuellement encore trop tendance à être dirigé par des éditeurs qui

ne laissent pas suffisamment la communauté s’épanouir et s’approprier le logiciel, ce qui relève du

gâchis selon moi, et l’annulation pure et simple de l’avantage en termes de qualité pour un logiciel

libre.

24

http://www.fidelead.fr/Les-utilisateurs-en-majorite-opposes-au-rachat-de-Peoplesoft-par-Oracle_a1023.html .

16

Document sous Licence Creative Common By-Sa – Yannick Buron

Figure 5 Périmètre de compétitivité pour un ERP libre. Extrait du livre blanc de Smile p24.

En résultat, à l’heure actuelle, les ERPs libres ont généralement une couverture fonctionnelle plus

faible que les ERPs propriétaires et les « Best practices » sont généralement moins bien pensés.

Néanmoins cet état de fait peut facilement s’inverser à l’avenir si les experts métiers25 par exemple

dans les écoles supérieures s’approprient les ERPs libres, cherchent à les améliorer et surtout à en

faire les solutions référentes dans leur domaine.

En attendant que cela arrive, une société hésitant à choisir un ERP libre doit se poser les questions

suivantes :

25

Personnes expérimentés dans un métier précis de l’entreprise, la personne la mieux placé pour critiquer la manière dont un processus est implémenté.

17

Document sous Licence Creative Common By-Sa – Yannick Buron

L’ERP libre que je vise a-t-il, de base ou en nécessitant une quantité raisonnable de

développement, une couverture fonctionnelle suffisante pour répondre à mes exigences ? Si

oui, alors un ERP libre peut représenter un choix raisonnable.

A quel point la maitrise que j’ai sur mon logiciel de gestion et sa flexibilité est importante

pour moi ? S’il s’agit d’un critère primordial alors les ERPs propriétaires sont à bannir et il

conviendra alors de partir sur un ERP libre.

Figure 6 Illustration de la répartition des avantages entre les différents types de solutions, passé, présent et avenir.

Voici qui clôture cette partie présentant la situation entre ERP libres et propriétaires. Nous allons

maintenant voir plus en détail les différentes solutions d’ERP libres et voir pourquoi OpenERP semble

être le meilleur projet à l’heure actuelle.

Avant les ERPs libres

ERPs Propriétaires

+Couverture fonctionnelle +Qualité de la base technologique et du code

+Perrenité

Développements spécifiques

+Flexibilité +Maitrise sur le produit

Aujourd'hui

ERPs Propriétaires

+Couverture fonctionnelle

ERPs libres

+Flexibilité +Maitrise sur le produit

+Qualité de la base technologique et du code +Coûts

+Perrenité

Développements spécifiques

+Si l'on ne veut pas publier ses méthodes de travail

Une fois les communautés suffisantes et

organisées

ERPs Propriétaires

Néant

ERPs libres

+Couverture fonctionnelle +Flexibilité

+Maitrise sur le produit +Qualité de la base technologique et du code

+Coûts +Perrenité

Développements spécifiques

+Si l'on ne veut pas publier ses méthodes de travail

18

Document sous Licence Creative Common By-Sa – Yannick Buron

Pourquoi OpenERP ?

Pour cette partie, je ne prétendrais pas être capable de dresser une comparaison détaillée de chaque

ERP libre existant sur le marché, faute de tous les avoir essayé. Ce n’est par ailleurs pas l’objet de ce

mémoire et je recommande plutôt la lecture du livre blanc de Smile, dont les informations sont pour

l’essentiel toujours d’actualités.

L’objectif de cette partie sera ainsi plutôt de mettre en avant les différentes forces d’OpenERP, qui

m’amènent à penser qu’OpenERP est la solution d’ERP libre la plus avancée actuellement.

OpenERP est un logiciel libre sous licence AGPL 326. Bâtie à partir de la plus connue des licences

libres, la licence GPL, celle-ci protège en plus le logiciel des entreprises qui tenteraient de fournir un

service en ligne d’OpenERP sans redistribuer leurs modifications.

La première d’entre elle est qu’il est l’un des seuls ERPs à avoir fait le pari de partir sur un langage de

programmation considéré comme étant de très haut niveau27 : Python.

Les langages de haut niveau sont intéressants car ils permettent de développer plus rapidement, en

effet une fonctionnalité nécessitera beaucoup moins de lignes de code avec un langage haut niveau

qu’avec un bas niveau, et cela prend une tout autre importance dans le cas spécifique des ERPs.

En effet, on peut considérer qu’un ERP est toujours en mouvement, il y a toujours des nouvelles

fonctionnalités à implémenter, des processus à perfectionner etc… Et plus il est facile de développer

sur un ERP et plus celui-ci a l’avantage sur ses concurrents car il progresse tout simplement plus vite.

Moins de lignes de code permet également de maintenir plus facilement le logiciel ce qui se révéler

salvateur sur des logiciels comme les ERPs qui sont parmi les plus complexes du marché.

A titre de comparaison, la majorité des ERPs libres sont basés sur du Java (OpenBravo, Adempierre,

Ofbiz/Neogia …) et seul ERP5 utilise également Python comme langage de programmation.

Dans le même registre, dans l’objectif de continuer à gagner toujours plus de temps de

programmation, OpenERP a développé son propre framework : OpenObject, qui est spécifiquement

adapté au développement de fonctionnalités de gestion.

Le framework prend ainsi en charge les communications avec la base de donnée, l’affichage des

interfaces via les menus/vues/droits d’accès, et dans une

certaine mesure les interactions entre eux, ou encore la

gestion des traductions. On peut dire le framework prend

en charge la gestion du modèle MVC28 au sein d’OpenERP

26

Affero General Public Licence. 27

Plus un langage de programmation est « haut niveau » plus il est considéré comme proche du langage humain. Inversement, un langage « bas niveau » sera plus proche du langage machine et plus difficilement lisible. 28

Model – View – Controller, ce modèle a pour principe de séparer le modèle, contenant les données dans la base de donnée qui doivent rester dans un cadre strict pour ne pas compliquer les migrations, et les vues qui représentent l’interface utilisateur et qui doit au contraire évoluer en fonction de l’ergonomie requise par les utilisateurs, la partie contrôleur permettant de faire le lien entre les deux via la réalisation d’actions complexes.

Figure 7 Logo OpenObject

19

Document sous Licence Creative Common By-Sa – Yannick Buron

de sorte à ce que le développeur puisse se concentrer directement sur le développement des

fonctionnalités.

Enfin dernier point mais non des moindres, le framework OpenObject prend également en charge le

système modulaire d’OpenERP. Le système de module est capital pour un logiciel libre car il permet à

n’importe qui de développer une nouvelle fonctionnalité ou simple correction qui viendra s’installer

ou se désinstaller facilement sur l’ERP. Tout un chacun peut ainsi développer les fonctionnalités dont

il a besoin dans un module, le publier pour en faire profiter les autres membres de la communauté et

le tout sans forcement influer sur le développement du cœur du logiciel. On peut dire que le système

modulaire apporte une vraie diversité à un logiciel et il s’agit d’un moyen très efficace pour

augmenter la taille de la communauté du logiciel.

Le livre blanc de Smile ne s’y était d’ailleurs pas trompé à l’époque « Si cela a peu de conséquences

sur les ERP commerciaux au développement naturellement monolithique, dans l'open source un

logiciel se doit d'être modulaire, c'est une qualité vitale. Pas d'exception avec les ERP: très peu

d'entre eux ont des architectures dont la modularité actuelle est suffisante. En fait, encore une fois

OpenERP fait la course en tête loin devant avec plus de 200 modules d'extensions dont une bonne

moitié ont été développées par des tierces parties. »29. OpenERP était alors l’un des seuls ERPs libres

modulaires et c’est sans doute l’une des principales raisons qui l’ont fait aujourd’hui devenir l’ERP

libre de référence. La modularité est un atout majeur pour un logiciel libre, on peut également citer

le succès de Firefox largement dû à ses extensions pour en témoigner.

On le voit, le pari qui a été fait pour OpenERP a été de tout miser sur le fait de faciliter le plus

possible les développements pour ensuite implémenter les fonctionnalités le plus vite possible. C’est

ainsi qu’aujourd’hui OpenERP dispose de loin de la couverture fonctionnelle la plus importante de

tous les ERP libres, allant de la comptabilité à la gestion de projet, en passant par des

synchronisations avec les CMS d’e-commerce. C’est aujourd’hui près de deux cents modules

développé par l’éditeur du logiciel et plus d’un millier par la communauté, et ce n’est sans doute

qu’un début.

Pour toutes ces raisons, car le logiciel a été conçu sur une base technologique solide, qu’il a déjà une

bonne avance, et parce que le logiciel libre porte généralement un seul champion par secteur que je

pense sincèrement qu’OpenERP est l’ERP libre le plus abouti à l’heure actuelle et le plus à même de

concurrencer les ERPs propriétaires.

Un petit commentaire supplémentaire néanmoins : OpenERP a un fork nommé

Tryton, né d’une divergence entre certains membres de la communauté et

l’éditeur. Celui-ci est reconnu pour disposer d’un framework encore plus

impressionnant que celui d’OpenERP mais accuse encore beaucoup de retard

au niveau de la couverture fonctionnelle.

29

Page 69 du livre blanc.

Figure 8 Logo Tryton

20

Document sous Licence Creative Common By-Sa – Yannick Buron

Toutefois, l’éditeur d’OpenERP faisant parfois des erreurs, Tryton est un logiciel à suivre car celui-ci

dispose d’encore plus de potentiel qu’OpenERP il y a quelques années.

Il faut également noter que contrairement à OpenERP, Tryton a été intégré dans les gestionnaires

Python ainsi que dans les distributions Linux, dont la plus importante et la plus strict, Debian30.

A l’inverse, déjà que les paquets OpenERP ne faisait partie que des versions de test, mais ils ont

récemment été éjectés du projet pour cause d’un manque de suivi et du manque de script de

migration31.

Enfin, l’excellent projet GnuHealth32, qui vise à développer un système de gestion d’hôpitaux à

destination principalement des pays du tiers-monde, se reposait à l’origine sur OpenERP mais a

désormais migré sur Tryton33. Il est depuis devenu un des projets GNU34, ce qui est une véritable

consécration pour ce projet qui le mérite. Et indirectement, en tant que base technologique du

projet, c’est Tryton et non OpenERP qui en profite.

Pour le moment, par manque de respect des strictes conventions qui sont de mise dans les

principaux projets libres, OpenERP n’a pas encore été intégré à ceux-ci malgré l’enthousiasme qui

l’entoure et l’intérêt qu’il suscite. Principalement pour des raisons de qualité, et sans doute de

manque d’intérêt de la part de l’éditeur.

C’est une erreur, car pendant ce temps c’est la réputation de Tryton qui se construit petit à petit

dans les communautés du libre. J’avoue ne pas avoir suffisamment étudié Tryton pour en citer ses

qualités, mais je crois ceux qui le prétendent, pour la majorité d’anciens membres de la communauté

OpenERP. Il serait un acte responsable de chercher à fusionner les deux projets pour prendre le

meilleur des deux, malheureusement je doute que les dirigeants des deux projets en prennent le

chemin…

30

http://packages.debian.org/search?searchon=sourcenames&keywords=tryton-server 31

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633587 32

http://health.gnu.org/ 33

Les raisons sont détaillées ici : http://www.meanmicio.org/2011/09/free-software-versus-open-source-tryton.html . Il semblerait que le manque de script de migration soit en cause, ce qui n’est guère étonnant. 34

Pour rappel, Linux se nomme en réalité GNU/Linux. Le projet GNU regroupe la majeure partie des logiciels libres les plus utilisés lorsque l’on travaille sur ce système.

21

Document sous Licence Creative Common By-Sa – Yannick Buron

Figure 9 Comparaison d'écran entre OpenERP et Tryton

Ceci clôture ma vision du marché des logiciels de gestion. Nous allons maintenant entrer dans le vif

du sujet et voir quels sont les points à considérer pour créer une société d’intégration sur OpenERP.

22

Document sous Licence Creative Common By-Sa – Yannick Buron

Créer son entreprise d’intégration d’OpenERP

Choix de la structure et formalités

Que vous ayez un projet solide avec plusieurs associés et investisseurs ou que vous souhaitiez juste

apporter un complément de revenu à votre vie d’étudiant, gagner de l’argent en proposant des

prestations sur OpenERP implique de créer une structure d’entreprise. Le choix du type de structure

est primordial car de celle-ci dépendra vos droits et devoirs par rapport à l’Etat et doit être adapté à

votre situation. Je précise que tout ce dont je parlerai ici n’est bien sûr valable que si vous créez la

structure en France.

Pour beaucoup, souhaitant juste arrondir leurs fins de mois et tester dans un premier temps la

réaction des clients face à OpenERP et voir si vous arrivez à être rentable, le statut d’auto-

entrepreneur est de loin le plus intéressant.

En effet les formalités de création se résument à un formulaire à remplir sur un site internet, les

formalités d’exploitation consistent simplement à déclarer mensuellement ou trimestriellement

votre chiffre d’affaire et les taxes (cotisations sociales et impôts) seront calculées directement via un

pourcentage de celui-ci. En 2011, le taux de cotisations était de 23,5% pour une activité de prestation

de service telle que la prestation sur OpenERP35. Il faut aussi rajouter selon les cas une somme

d’environ 500€ par an au titre de la Cotisation Foncière des Entreprises (CFE) qui est venue remplacer

l’ancienne taxe professionnelle.

Ce pourcentage est bien moins élevé que n’importe quelle autre type de structure et en fait donc la

plus rentable, tant en terme de taxes que de formalités, pour une personne souhaitant travailler

seule.

Néanmoins le statut d’autoentrepreneur a une limite, il n’est pas possible d’en bénéficier une fois

que vous commencez à dépasser un chiffre d’affaire annuel de 32 600 HT36. C’est pour cette raison

que le statut est intéressant pour lancer le projet tout en ayant la possibilité de se concentrer sur son

travail et en prenant le moins de risque possible, mais il est ensuite nécessaire de changer le type de

structure une fois le succès au rendez-vous.

Dans ce cas, vous créerez probablement une EI, Entreprise Individuelle, étant également le type de

structure ayant le moins de démarches à effectuer auprès de l’état. Vous devrez néanmoins à partir

de là commencer à tenir une véritable comptabilité et donc faire appel à un expert comptable37. De

plus, il est également beaucoup moins intéressant au niveau des taxes car il n’y a plus la possibilité

de calculer les taxes sur un pourcentage du chiffre d’affaire et le mode de calcul sera beaucoup plus

complexe.

L’impôt sur le revenu sera calculé de la même manière qu’un salarié. Il sera donc axé sur le chiffre

d’affaire de la structure et ressemblera donc sur ce point au statut d’autoentrepreneur.

35

http://www.lautoentrepreneur.fr/questions_reponses.htm#Couts 36

Pour une société de service telle une société sur OpenERP. 37

Il reste néanmoins possible de faire soi-même sa comptabilité, avec l’aide notamment d’OpenERP, pour réduire considérablement les frais comptables.

23

Document sous Licence Creative Common By-Sa – Yannick Buron

Cela se complique en revanche pour les prélèvements sociaux. Tout d’abord il faudra prendre en

compte chaque cotisation (Maladie, retraite, etc…) et le pourcentage par rapport au chiffre d’affaire

dépend fortement de celui-ci. Disons que de manière générale et pour être large, les prélèvements

sociaux prendront entre 30% et 40% du chiffre d’affaire, ce qui est bien moins avantageux que

l’autoentrepreneur.

Par ailleurs, le RSI38 vous demandera chaque année plusieurs milliers d’euros de cotisations même si

vous n’avez fait aucun chiffre d’affaire ce qui peut être dramatique pour un créateur qui doit déjà

dans ce cas affronter le fait de ne pas toucher de revenu de son activité. C’est pour cette raison que

créer son activité était très difficile avant le statut d’auto-entrepreneur et que le nombre de création

d’entreprise a fortement augmenté.

Un autre point à considérer est la sécurité de son patrimoine personnel. En autoentrepreneur et EI39

le patrimoine de l’entreprise est confondu avec son patrimoine personnel. Ainsi si la structure a des

dettes les créanciers peuvent saisir les biens personnels de l’entrepreneur.

Il peut ainsi être une bonne idée de créer une personne morale40 pour s’en protéger. L’EURL,

Entreprise Unipersonnelle à Responsabilité Limitée, est la plus adaptée dans ce cas de figure où une

seule personne physique possède l’ensemble de la société. Elle nécessite un formalisme un peu plus

lourd au moment de la création, avec la rédaction des statuts de la personne morale et la nomination

d’un gérant.

Elle permet également d’être taxé sur l’impôt des sociétés au lieu de l’impôt sur le revenu. Celui-ci a

le principal avantage par rapport à l’impôt sur le revenu de pouvoir réinvestir l’ensemble des

bénéfices sans être taxé. L’impôt sur les sociétés est calculé à 30% du bénéfice, il n’y a donc rien à

payer si l’ensemble des bénéfices est réinvesti.

Toutes ces structures sont valables si une personne physique unique possède l’ensemble de la

structure. Si vous êtes plusieurs à monter le projet alors il faudra certainement passer par la création

d’une SARL, Société Anonyme à Responsabilité Limitée. Celle-ci est très similaire à l’EURL, avec la

création d’une personne morale, une imposition via l’impôt sur les sociétés, la rédaction de statut

etc… Simplement en revanche, au moins deux personnes possèdent une partie du capital de la

société.

Cela rend la rédaction des statuts particulièrement importante car ils permettent de décider les

pouvoirs que possèdent chacun des actionnaires (droit de veto, d’information etc…) en fonction du

pourcentage qu’ils possèdent. Ce pourcentage est déterminé par la somme qu’ils ont investi

initialement dans le capital de la société.

38

Régime Social des Indépendants, les entrepreneurs ne relevant pas de l’URSSAF comme les salariés. 39

l’EI connait néanmoins depuis quelque temps une option nommé EIRL permettant de profiter de certaines particularités de l’EURL http://www.apce.com/pid11669/l-eirl.html . 40

On distingue les personnes physiques et les personnes morales, ces dernières sont des entités immatérielles ayant une responsabilité juridique. Les seuls types d’entreprises qui ne sont pas également des personnes morales sont les autoentrepreneurs et les EIs.

24

Document sous Licence Creative Common By-Sa – Yannick Buron

Il existe de nombreux autres types de structure, notamment les SAS et les SA, Société par Actions

Simplifiée et Société par Actions, mais je vous ai présenté les plus communs et faciles à monter, et si

vous envisagez d’autres types de structure vous n’avez sans doute pas besoin de lire ce texte.

Figure 10 Résumé du comparatif entre les différents types de structure

Il me reste deux points à préciser :

-L’ancienne taxe professionnelle a été remplacée par deux taxes, la CFE déjà évoquée et la CVAE.

Celle-ci est basée sur un pourcentage progressif du chiffre d’affaire et n’est redevable qu’à partir de

152 500€ de chiffre d’affaire avec un taux nul jusqu’à 500 000€41.

-En tant qu’entreprise vous ne payez pas la TVA. C'est-à-dire que vous devez la facturer à vos client et

la reverser ensuite à l’Etat. Inversement, vous pouvez déduire de la TVA reversée la TVA payée à vos

fournisseurs. Si la TVA payée à vos fournisseurs est supérieure à celle payée par vos clients, alors

l’Etat vous remboursera la différence à la fin de votre année fiscale, pour ces raisons la TVA n’a

normalement pas d’impact sur la trésorerie de votre entreprise.

Précisons que les autoentrepreneurs sont un cas spécial à ce niveau, ils ne facturent pas la TVA mais

ne peuvent pas non plus la récupérer sur leurs factures fournisseurs.

41

http://fr.wikipedia.org/wiki/Cotisation_sur_la_valeur_ajout%C3%A9e_des_entreprises

Autoentrepreneur

•+Formalités de création simplissime

•+Taux de taxation extrèmement faible, 0 CA = 0 taxes

•-Dans la limite d'un CA inférieur à 32000€ HT annuel

Entreprise Individuelle

•+Formalités simples

•+Pas de limite de CA

•-Pas de protection du patrimoine personnel

•-Impôt sur le revenu et non impôt sur les sociétés

EURL

•+Protection du patrimoine personnel

•+Impôt sur les sociétés

•-Formalités plus importantes

•Uniquement avec un seul actionnaire

SARL

•+Protection du patrimoine personnel

•+Impôt sur les sociétés

•-Formalités plus importantes

•A partir de deux actionnaires

SAS et SA

•Avec un nombre important d'actionnaires nécessitant des statuts stricts, pour cadrer les droits et devoirs de chacun

25

Document sous Licence Creative Common By-Sa – Yannick Buron

Autoentrepreneur EI EURL SARL SAS et SA

Toutes les taxes calculées directement sur le chiffre d’affaire à 23,5%.

X

Cotisations sociales à la RSI, calculées à environ 30-40% du salaire versé au créateur/gérant si celui-ci détient la majorité des parts de l’entreprise. Dans le cas contraire, application du régime salarié normal.

X X X X

Impôt sur le revenu, calculé sur le chiffre d’affaire avec un barème similaire à celui des salariés.

X

Impôt sur les sociétés, calculé à 30% des bénéfices de la société.

X X X

Cotisation foncière des entreprises, environ 500€/an suivant où est située l’entreprise.

X X X X X

CVAE, à valeur non-nulle à partir de 500 000€ de chiffre d’affaire. De 0,5% à 1,5% du chiffre d’affaire.

X X X X

Facturation de la TVA, et TVA déductible sur les factures fournisseurs.

X X X X

Figure 11Tableau résumé des taxes pour chaque type de structure

Ceci clôture cette présentation des différents types de structures possibles avec les formalités et les

taxes correspondantes. Nous allons maintenant nous concentrer sur les types de services qu’il est

possible de proposer sur OpenERP et comment nous positionner sur le marché.

26

Document sous Licence Creative Common By-Sa – Yannick Buron

Choix des services proposés

A moins de « fork » le logiciel et de vouloir devenir un nouvel éditeur, vous allez sans doute baser

votre activité sur l’intégration d’OpenERP. Un intégrateur est une société connaissant suffisamment

bien le logiciel pour être capable d’analyser les besoins du client, préparer un produit prêt à être

utilisé et intervenir en cas de problème.

La première des tâches de l’intégrateur est donc de comprendre les besoins de son client, ce qui

implique une prestation d’étude. Celle-ci est très importante dans un projet ERP et peut dans

certains cas prendre plus de la moitié du projet.

Cette étude consiste notamment à comprendre quelles sont leurs méthodes de travail actuelles et en

quoi ils souhaitent les améliorer. Il faut ensuite indiquer au client comment ces méthodes de travail

seront portées sur l’ERP et modéliser si nécessaire les développements. Au niveau de l’interface, une

maquette permettra au client de valider les différents écrans et droits d’accès pour chaque

utilisateur.

Cette prestation d’étude peut parfois être indépendante, et il s’agira alors uniquement de rédiger les

spécifications pour une intégration qui sera faite par un autre prestataire. Une stratégie commerciale

souvent utilisée consiste d’ailleurs à offrir la phase d’étude si le client accepte le devis d’intégration

suite à la phase d’étude, c’est une méthode très efficace pour faire accepter une phase d’étude qui

ne peut par nature être réalisée qu’en régie42 étant donné que la durée de celle-ci dépend

entièrement des exigences du client.

La tâche suivante consiste en l’intégration proprement dite. Il s’agira de créer la base OpenERP de

production, de la configurer, de faire les développements spécifiés en phase d’étude, d’importer les

données (bases clients, produits, stocks etc…), de procéder à la phase de recette43 et enfin le

lancement en production avec une assistance au démarrage.

Etant donné que l’ensemble des informations doit avoir été modélisé par une phase d’étude,

l’intégration est généralement proposée par un devis forfaitaire44.

L’assistance est un autre service très important pour un intégrateur. Notamment car elle génère des

revenus récurrents et limite donc la dépendance de la société aux nouveaux clients.

Il y a plusieurs manières de proposer des prestations d’assistance. Généralement elles sont à base

d’heures prépayés, le client achète plusieurs heures à la fin de l’intégration et les utilisent ensuite au

fur et à mesure.

Il est également possible de procéder à la demande, mais il faut dans ce cas minimiser le plus

possible les échanges contractuels pour être rentable. Il peut y avoir deux manières de faire, à priori

42

Type de contrat de prestation où le client paye le prestataire en fonction du temps qu’il y passera. Etant donné que le temps passé pour une prestation de service peut parfois être très variable, le client ne possède qu’une très faible maitrise des coûts. 43

Phase pendant laquelle le prestataire et le client passent en revue le produit fini. 44

Par opposition à la régie, dans un forfait le prestataire s’engage à réaliser un travail précis pour une somme fixée à l’avance. En cas de dépassement de durée c’est donc lui qui est perdant.

27

Document sous Licence Creative Common By-Sa – Yannick Buron

en décrivant par e-mail le travail à effectuer et la durée estimée, ce qui permet avec le bon pour

accord du client de valider rapidement une prestation forfaitaire, ou à posteriori en effectuant

d’abord la prestation et ensuite en envoyant un e-mail au client avec le montant qui sera facturé et

indiquant qu’il a X jours pour faire valoir ses remarques avant que la facture ne soit émise. En cas de

profond désaccord et comme il s’agit normalement de petits travaux, vous pourrez réagir en

conséquences aux demandes suivantes en étant beaucoup plus rigide.

Dans les prestations d’assistance, il convient de séparer ce qui relève du support et ce qui relève de

la maintenance. La maintenance consiste en toutes les erreurs relevant de la responsabilité du

prestataire, on peut citer une panne du système, un plantage d’OpenERP, un bug dans un module

développé par le prestataire, etc… Le support en revanche concerne toutes les demandes émanant

du client, que ce soit des questions, des petits développements, une reconfiguration etc…

Le support doit faire l’objet d’heures prépayés ou à la demande, tandis que la maintenance doit faire

l’objet d’une proposition à part au forfait et mensuelle. Précisons qu’il vaut mieux exclure de la

maintenance les bugs dû aux modules développés par l’éditeur car seul lui peut intervenir

efficacement, et en profiter pour vendre son propre contrat de maintenance45.

Il est également possible de proposer des prestations d’hébergement. Il est possible de procéder en

logiciel à la demande46 ou via l’infogérance d’un serveur dédié au client.

Dans le cas d’un service de logiciel à la demande, il s’agit d’une sorte de service de location par mois

et par utilisateur de l’ERP. L’éditeur d’OpenERP lui-même propose un tel service à maximum

39€/mois et par utilisateur, ce qui est très compétitif aussi ne fournissez un service de logiciel à la

demande que si vous avez un élément de différentiation, comme par exemple rajouter des modules

issus de la communauté suffisamment fiables et que l’éditeur ne propose pas dans son propre

service.

L’infogérance est un service déjà beaucoup plus commun pour un intégrateur. Il s’agit d’assurer la

mise en place et la mise à jour du système d’exploitation sur lequel tournera l’ERP, les mises à jour

mineures de l’OpenERP, les sauvegardes ainsi que la supervision47. Le serveur dédié sera loué au nom

du prestataire ou du client, suivant sa préférence.

Concernant les sauvegardes, elles sont d’une importance primordiale pour un ERP car la perte de ses

données pourrait avoir des conséquences catastrophiques pour le client. Pour cette raison, il est

impératif de réaliser dans le cadre de l’infogérance au minimum une sauvegarde quotidienne stockée

dans au moins deux lieux géographiquement distants, en plus d’un RAID 148 sur le disque dur du

serveur bien entendu. Par ailleurs, le client peut parfois avoir besoin d’accéder à des données

anciennes qui ont été supprimées de l’ERP. Je recommande ainsi pour les clients exigeants une

politique de rétention des sauvegardes de chaque jour de la semaine en cours, des lundis de chaque

45

Comme nous le verrons par la suite, cela peut être d’une grande aide pour la prospection. 46

Aussi appelé SaaS pour « Software as a Service ». 47

Système permettant de surveiller le serveur et de récolter des données sur l’évolution de la charge, telle que le processeur, mémoire vive, espace disque, ou d’être prévenu quand un serveur est indisponible. 48

Duplication matérielle des données sur deux disques durs pour s’assurer que le serveur soit toujours immédiatement opérationnel en cas de crash de l’un des disques durs.

28

Document sous Licence Creative Common By-Sa – Yannick Buron

semaine du mois en cours, du premier lundi de chaque mois de l’année en cours, et stocker pour une

durée indéterminée les sauvegardes du premier jour de chaque année. Pour les cas les plus

extrêmes, rajouter une sauvegarde incrémentale à chaque heure de la journée en cours peut

également être une option intéressante. Le logiciel libre Bacula est une solution adaptée pour gérer

ce genre de politique de sauvegarde, bien qu’un peu compliqué à configurer.

Pour en finir avec la présentation du service d’infogérance, précisons qu’il est préférable de vendre le

contrat de maintenance comme étant inclus dans l’infogérance, étant tous les deux des services

mensuels forfaitaires. Ceci permet de marquer la différence avec le service de support.

Concernant les formations, j’ai personnellement tendance à penser qu’elles ne sont guère

nécessaires dans le cadre d’un projet d’intégration car le responsable de projet client, étant sollicité

en permanence pendant tout le projet, est généralement en mesure de les faire lui-même tout en

ayant des propos plus adaptés aux employés de la société où il travaille. Néanmoins, si la société

cliente en fait la demande, vous pouvez bien sûr proposer des sessions de formations en interne.

Ne manquez pas également de proposer des sessions de formations ouvertes à tous et d’en faire la

promotion sur votre site internet. C’est un bon moyen de promouvoir vos services, surtout si vous

proposez des formations sur des modules intéressants et que vous avez développé vous-mêmes.

N’oubliez pas non plus de devenir un centre de formation agréé par l’Etat, permettant à vos

stagiaires d’assister à vos séances dans le cadre de la formation continue49.

Enfin concernant les migrations entre versions majeures d’OpenERP, il est préférable de ne pas les

inclure dans le contrat de maintenance car il s’agit souvent de travaux assez difficiles et comportant

une part importante de risque pour le prestataire50.

Le plus simple pour cela est de vendre le contrat de maintenance de l’éditeur qui inclus les

migrations majeures. Leur script de migration va agir directement sur la base de production du client

et la modifier pour la passer directement dans la version supérieure d’OpenERP.

Néanmoins, les scripts de migrations sont la seule partie d’OpenERP qui ne soit pas sous licence libre,

aussi il peut parfois être plus sécurisant de proposer son propre service de migration. Pour ce faire, il

faut au préalable créer une nouvelle base de production sous la nouvelle version et la configurer.

Ensuite le module server_migration51 permettra de créer une correspondance de champ entre les

deux bases et d’importer la majorité des données. Pour les quelques données restantes et un peu

plus complexe à migrer, il sera nécessaire de passer par un ETL52 comme par exemple le logiciel libre

49

Toutes les entreprises en France cotisent à la formation continue, et dispose ensuite d’un budget pour des formations ce qui constitue une manne financière pour les organismes de formation. Il est réellement préférable de pouvoir répondre au client qu’il peut utiliser ce budget pour une partie de vos services. 50

Pour un prestataire, le risque consiste généralement à passer plus de temps sur un projet que ce qui était prévu, et donc entamer la rentabilité du projet. 51

Créé à la base par la société kndati mais amélioré par nous-mêmes dans le cadre du développement d’une migration de la V5 vers la V6. 52

Extract Transform Load, un logiciel utilisé en Business Intelligence pour récupérer des données et les transformer pour en faire des rapports statistiques. Il est possible de s’en servir comme puissants outils de synchronisation.

29

Document sous Licence Creative Common By-Sa – Yannick Buron

Pentaho PDI53.

Cette méthode est une méthode de migration par injection de données, là où l’éditeur transforme

directement la base de production. L’éditeur arrive par sa méthode à contourner la difficulté pour lui

de migrer les modules issus de la communauté car ceux-ci restent installés sur la base transformée,

mais je saurais dire avec quel degré de fiabilité. Il est impossible pour un intégrateur de procéder de

même car seul l’éditeur a les informations suffisantes pour faire une telle migration, mais la méthode

par injection de données a également ses avantages car permettant une migration sur une base

propre, plus souple pour intégrer également les modules de la communauté ou développé

spécifiquement pour le client, au prix sans doute d’un temps plus important pour la faire.

Figure 12 Illustration des différents types de services possible pour un intégrateur OpenERP

Ceci clôture la présentation des différents services qu’il est possible de proposer en tant

qu’intégrateur OpenERP. Voyons maintenant comment il est préférable de se positionner sur le

marché.

53

Egalement appelé de son ancien nom Kettle.

Etude

• Comprendre le besoin

• Rédiger cahier des charges

• En Régie

Intégration

• Créer la base de production

• Configuration

• Importation des données

• Développements

• Au forfait

Formation

• Peut être assurée par le chef de projet client

• En interne ou externe

Maintenance

• Responsabilité du prestataire

• Forfait mensuel

Hébergement Infogérence

• Sauvegardes

• Supervision

• Forfait mensuel

Support

• A la demande du du client

• Régie

Migration

30

Document sous Licence Creative Common By-Sa – Yannick Buron

Positionnement sur le marché

Comme nous l’avons vu en début de ce document, le marché des ERPs est classé en fonction de la

taille de la société cliente, et en fonction du degré de spécialisation54 du produit dans un secteur

d’activité.

L’un des avantages d’être intégrateur d’un ERP libre est que vous avez une telle maitrise sur le

produit que vous pouvez facilement l’adapter en fonction du marché que vous ciblez, néanmoins

certains seront plus faciles que d’autres.

Le marché des TPEs notamment, peut se révéler un marché très difficile pour un intégrateur

OpenERP. Le client voudra un outil prêt à l’emploi et n’aura guère d’intérêt pour les forces

d’OpenERP en termes de maitrise et de flexibilité. Il se sera certainement tourné vers OpenERP pour

la prétendue gratuité des logiciels libres55 et n’aura de cesse de le comparer à des outils de gestion

complètement packagé et simplifié comme Ciel ou EBP, qu’on ne peut que difficilement nommer

ERP.

OpenERP n’est pas un ERP prêt à l’emploi, en tout cas à l’heure d’aujourd’hui, il nécessite de

comprendre les besoins du client et passer un certain temps en paramétrage avant de pouvoir en

faire un produit fini. Ceci est parfaitement incompatible avec le marché des TPEs où un budget de

quelques milliers d’euros, soit uniquement quelques jours de travail, est déjà considéré comme très

cher. Pour être rentable, un intégrateur OpenERP visant ce secteur doit trouver un moyen d’intégrer

le logiciel en seulement quelques heures et avoir suffisamment de nouveaux clients pour compenser

le faible budget.

Le marché des TPEs reste néanmoins très alléchant, et peut être ciblé par un intégrateur OpenERP

motivé s’il s’y prend de la bonne façon. Cela nécessitera de très fortement se spécialiser dans un

secteur d’activité et si possible qu’au moins l’un des associés ait une très bonne expérience de ce

secteur et y dispose d’un vaste réseau de contact.

Dans ce cas, vous pourrez développer une base OpenERP spécifiquement adaptée à ce secteur

d’activité car vous y connaitrez les besoins, faire les développements nécessaires pour que les

processus de l’ERP soient ceux communément utilisés par le secteur, adapter les interfaces pour les

rendre les plus fonctionnels possibles etc… Si vous envisagiez dès le départ de développer vous-

même un ERP verticalisé, partir d’OpenERP sera beaucoup plus simple que si vous créez un tout

nouveau produit à partir de zéro et la marque OpenERP vous permettra en plus de vous différencier

des autres éditeurs d’ERP spécialisés.

Etant donné que le produit final sera totalement adapté au secteur, il sera prêt à l’emploi et vous

permettra de cibler les TPEs de ce secteur en permettant une intégration rapide grâce à un produit

qui remportera l’adhésion immédiate du client. Il vous faudra néanmoins trouver de nombreux

clients dans un premier temps pour être rentable d’où l’importance du réseau de contact, le bouche

à oreille fera ensuite le reste.

54

Egalement appelé verticalisation. 55

Vrai en terme de licence, mais comme nous l’avons déjà vu la licence n’est qu’une petite partie du prix d’intégration d’un ERP, libre comme propriétaire.

31

Document sous Licence Creative Common By-Sa – Yannick Buron

Attention à ne pas se disperser en essayant de cibler plusieurs secteurs d’activité à la fois, repérez en

un qui pourrait être intéressant, assurez-vous d’avoir suffisamment de clients potentiels et

persévérez jusqu’à obtenir un OpenERP prêt à l’emploi pour ce secteur. En cas de réussite, vous

pourrez toujours capitaliser sur ce secteur et commencer à envisager d’en cibler un autre.

Bien entendu, le fait que cette approche soit sans doute la seule possible pour cibler les TPEs ne veut

pas dire qu’elle vous empêche de cibler les PMEs du même secteur, bien au contraire car elles seront

sans doute également très intéressées et vous disposerez en plus de la maitrise et de la flexibilité

d’OpenERP pour les satisfaire. Pour cette raison, je recommande cette approche à toute société

souhaitant se lancer sur OpenERP, d’autant qu’elle peut grandement faciliter la prospection en se

différenciant des autres intégrateurs.

Cette manière de faire peut être prometteuse, néanmoins vous n’aurez pas forcément les contacts et

l’expérience nécessaire dans un secteur pour cela. Dans ce cas vous aller sans doute adopter une

approche plus généraliste en ciblant plusieurs secteurs, mais il vous faudra impérativement oublier le

marché des TPEs qui ne sera jamais assez rentable et cibler les PMEs.

Celles-ci seront en effet beaucoup plus faciles à convaincre grâce aux arguments de maitrise sur le

produit et de flexibilité. Les ERPs propriétaires pour PMEs sont en effet souvent trop rigide pour

s’adapter à l’entreprise et celle-ci est souvent découragée par le prix des développements

spécifiques.

Les PMEs sont ainsi la cible prioritaire pour un intégrateur OpenERP, attention néanmoins elles

peuvent se révéler difficile à prospecter comme nous le verrons plus tard, et surtout peut prendre

beaucoup de temps avant de se décider (souvent plus de six mois), adaptez votre business-plan en

conséquence. Une fois convaincu, les projets peuvent tourner généralement autour de 30K€, parfois

beaucoup plus, ce qui vous donnera le temps nécessaire pour faire un travail de qualité.

Il peut même être envisageable de cibler des grandes entreprises. Alors il ne s’agit pas de se leurrer,

OpenERP ne pourra sûrement pas (en tout cas pas pour l’instant) remplacer un SAP dans le cœur de

la société, mais il peut néanmoins se révéler une alternative intéressante pour informatiser des

filiales, des franchisés ou des départements ayant besoin d’outils spécifiques. En effet les grandes

entreprises ont généralement le choix entre laisser un grand ERP tel SAP gérer l’ensemble du groupe

et assurer la cohérence du système informatique ou l’utiliser uniquement au siège et utiliser des

logiciels développés en interne pour gérer les filiales, magasins, etc… Logiciels qui remonteront

ensuite les informations au siège.

Comme vous pouvez vous en doutez, c’est dans ce dernier cadre qu’OpenERP peut devenir

intéressant pour une grande entreprise car comme dit précédemment il ne possède que des

avantages par rapport à un logiciel développé en interne. La direction informatique du groupe pourra

ainsi économiser des sommes colossales en licences d’ERP propriétaires ou en développements

internes en simplement prenant OpenERP et en l’adaptant en fonction d’où il est destiné, que ce soit

les points de ventes du groupe, les entrepôts, les franchisés etc…56 Tel point de vente aura par

56

Un projet mené par Danone est récemment venu valider cette affirmation : http://www.octo.com/uploads/pagemaster/01%2009%2011%20OCTO%20accompagne%20Danone%20dans%20le%20deploiement%20de%20ses%20logiciels%20integres-110901-113052.pdf .

32

Document sous Licence Creative Common By-Sa – Yannick Buron

exemple un OpenERP extrêmement similaire57 à celui du point de vente situé à l’autre bout du pays,

permettant à la direction informatique d’avoir un parc homogène et bien plus facile à maintenir

qu’avec des logiciels développés en interne, et pour un coût ridicule par rapport au déploiement d’un

grand ERP sur l’ensemble du groupe.

Il est recommandé de procéder de manière progressive, par exemple d’abord dans un département

ayant besoin de changer de système, puis ensuite une fois les employés familiarisé avec le système,

déployer au fur et à mesure les autres fonctions de l’ERP.

Ceci devrait vous donner les clés pour pouvoir vous positionner sur le marché avec OpenERP. Si vous

connaissez parfaitement les besoins d’un secteur et disposez d’un bon réseau de contact, alors

surtout spécialisez-vous en créant un OpenERP dédié au secteur en question. Si vous le pouvez pas

ou souhaitez rester généraliste, alors ciblez les PMEs. Et si vous avez la chance d’arriver à convaincre

un grand groupe, alors tout va bien pour vous.

Figure 13 Résumé du positionnement en fonction de la taille des entreprises ciblées

Nous allons maintenant voir quels sont les choses à savoir concernant la question commerciale, en

commençant par le plus important : trouver les clients.

57

Il reste possible même dans ce cadre d’apporter quelques corrections spécifiques au dit point de vente tout en gardant le cadre fixé par la DSI grâce au système modulaire.

TPEs

• A cibler uniquement en s'étant spécialisé sur un secteur d'activité

• Budget par projet : environ 1000€.

• Peut être un marché très rentable avec un produit packagé, en jouant sur un vaste parc client

• Faible temps de prospection

PMEs

• Peuvent être ciblé avec un positionnement généraliste

• Budget par projet : environ 30 000€

• Rentabilité même avec un faible nombre de client

• Long temps de prospection avant signature

Grandes entreprises

• Peuvent être interessée pour déployer OpenERP dans des filiales / franchisés / départements en dehors du siège du groupe

33

Document sous Licence Creative Common By-Sa – Yannick Buron

Positionnement commercial

Prospection

La prospection dans le secteur des ERPs peut être quelque chose de très difficile. En effet, il ne s’agit

pas seulement de trouver la bonne personne, mais de la trouver au bon moment c'est-à-dire au

moment où ils envisagent de changer leur système de gestion.

La prospection directe, c'est-à-dire récupérer des contacts en fonction du secteur d’activité ou de la

position géographique et les appeler directement est à cause de cela pratiquement inefficace, les

prospects ne prenant pas le temps d’étudier le produit si une solution est déjà en place.

Si vous envisagez tout de même de recourir à la prospection directe, vous pourrez trouver quelques

fichiers de contacts, par exemple ceux des visiteurs des salons ERP58 mais je n’ai moi-même pas eu

l’occasion d’en tester la pertinence.

Vous pouvez également, une fois que vous disposez d’un premier fichier client, demander à vos

clients de vous recommander à leurs contacts, pourquoi pas en échange d’un rabais sur vos futures

prestations. Ceci peut notamment très bien marcher si vous ciblez un secteur bien particulier car cela

vous permet de progresser dans un marché de niche qui peut générer rapidement du bouche à

oreille.

Dans un marché où il est difficile de trouver le client au bon moment, il peut être préférable de

laisser le client vous trouver au moment où il a besoin de vous. Il vous faudra pour cela vous faire

connaitre à la fois de la communauté OpenERP et du secteur ciblé.

Un site internet est bien entendu indispensable. Je recommande personnellement de le faire sous le

CMS59 Drupal, qui dispose d’une importante flexibilité et de nombreux modules vous permettant

d’implémenter de nombreuses fonctionnalités sur votre site internet. Evidemment, il s’agit à

nouveau d’un logiciel libre, disposant d’une forte communauté.

Votre site devra comporter la présentation de vos services, vos références clients, et ce qui vous

différencie de vos concurrents. Il peut notamment être particulièrement pertinent de publier des

études ou vos développements OpenERP pour attirer des personnes sur votre site et faire monter

votre référencement. N’oubliez pas qu’en tant qu’intégrateur d’un logiciel libre, vous ne pouvez

proposer de développements à un client sans le publier à la communauté, alors utilisez le plutôt à

votre avantage, il s’agit réellement un puissant vecteur de notoriété. Même si d’autres intégrateurs

venaient à profiter de vos développements, ceci ne ferait que renforcer votre notoriété en tant que

développeur originel d’une fonctionnalité appréciée.

N’oubliez pas également qu’il vous faut être connu à la fois de la communauté OpenERP et du

secteur que vous ciblez. N’hésitez pas à vous rapprocher des associations de métiers du secteur que

vous ciblez, de faire des campagnes de mots clés sur les moteurs de recherches avec les mots « ERP +

58

http://www.fichiersolutions.com/ 59

Content Management System, il s’agit d’un site internet prêt à l’emploi qu’il suffit de configurer, d’insérer les textes et d’appliquer un design pour qu’il soit finalisé. La majorité des sites internet d’aujourd’hui, y compris les sites d’e-commerces, fonctionnent sous un CMS.

34

Document sous Licence Creative Common By-Sa – Yannick Buron

nom du secteur » ou « logiciel de gestion + nom du secteur », vous limiterez ainsi le CPC60 et

maximiserez la rentabilité de votre campagne.

Une autre solution consiste à dresser des partenariats avec d’autres sociétés complémentaires de

l’ERP, et elles sont nombreuses. On peut notamment citer les intégrateurs e-commerces dont le CMS

possède souvent un connecteur avec OpenERP, des cabinets d’études en amélioration de processus,

etc… Ces sociétés ont souvent besoin de recommander un logiciel de gestion à leur client et si vous

arrivez à les convaincre eux ils pourront grandement vous aider à convaincre leurs clients.

Vous pouvez également compter sur le partenariat avec l’éditeur pour votre prospection. Celui-ci

permet, en échange d’un cout d’environ 3000€ /an61, d’être référencé sur le site de l’éditeur en tant

que partenaire et de recevoir une partie des prospects que celui-ci reçoit sur son site internet.

Il faut toutefois relativiser l’intérêt de ce partenariat. OpenERP étant un logiciel libre, la majorité des

personnes qui contactent l’éditeur sont des TPEs attirés surtout par la gratuité de la licence, et

comme vu précédemment des TPEs non ciblés par une base OpenERP adaptée à leur secteur ne

peuvent donner lieu à des projets rentables. On peut ainsi dire malheureusement que la majorité des

prospects de l’éditeur ne sont pas rentables.

Les PMEs intéressées par le logiciel vont quand à elles parfois laisser leurs coordonnées, mais vont

surtout chercher à contacter les entreprises Silver et Gold référencées sur le portail de l’éditeur. Vous

obtenez ce statut si vous vendez pour respectivement 20 000 et 40 000€ par an de services de

l’éditeur62. Ceci représente une bonne somme, mais d’après les partenaires ayant obtenus ces labels

elle en vaut la peine car vous avez alors un grand nombre de prospects hautement qualifiés qui vous

contactent directement, et votre activité devient alors stable.

En résumé, si vous avez fait le pari de vous spécialiser, tentez de faire parler de vous dans la presse

spécialisée et via des campagnes de publicité ciblée. Si vous chercher à mettre en place une activité

plus généraliste, trouver vos premiers clients risque d’être difficile essayez donc de cibler des

sociétés avec un budget conséquent, publiez vos travaux pour vous faire connaitre, n’hésitez pas à

dresser des partenariats en cas de difficulté et vendez le contrat de maintenance de l’éditeur pour

obtenir le plus vite possible les labels Silver et Gold.

60

Cout par clic, l’argent que vous reversez à l’annonceur chaque fois qu’un internaute clique sur votre annonce. Il s’agit généralement d’enchère, plus le mot-clé est prisé plus le CPC est élevé, d’où l’intérêt de chercher plutôt des combinaisons de mots-clés pertinentes. 61

http://www.openerp.com/partners/partners-key-benefits. 62

Vous touchez une retro-commission dans ce cas de figure.

35

Document sous Licence Creative Common By-Sa – Yannick Buron

Figure 14 Résumé des actions à effectuer en termes de prospection en fonction du positionnement

Discours commercial, proposition et négociation

Arriver à convaincre le prospect est normalement la partie la plus facile de toute la partie

commerciale. Le seul défaut d’OpenERP par rapport à un ERP propriétaire se situe dans les

fonctionnalités parfois moins bien implémentée mais on ne s’en rend compte que dans les détails ce

que le prospect est incapable de voir à ce stade. Il ne s’agit tout de même pas de faire de défaut de

conseil et il conviendra de convenablement prévenir le prospect sur l’implémentation ou non de telle

ou telle fonctionnalité, et de ne faire une proposition que si les fonctionnalités sont suffisamment

bien implémentée pour le prospect ou si le reste est facilement développable.

Ceci d’autant plus que le prospect doit être bien conscient de tous les termes du contrat qui sera

passé entre vous afin de ne pas vous accuser par la suite de problèmes qui relève de la responsabilité

de l’éditeur, comme nous le verrons par la suite.

Pour le reste, les arguments que je n’ai pas arrêté d’évoquer en termes de maitrise sur le produit, de

flexibilité et de coût suffiront. Pratiquement l’ensemble des informations que j’évoque dans la partie

« Contexte général du marché des ERPs » de ce document peuvent être utiles pour vendre OpenERP

et je vous laisse vous y référer pour travailler votre discours commercial.

Le plus important sera donc la proposition qui sera rédigée. Le secteur des ERPs est un secteur

particulièrement sensible car le client tentera systématiquement de vous accuser si telle ou telle

fonctionnalité n’est pas implémentée de la manière dont il l’avait imaginé. Pas de la meilleure façon

possible mais de la meilleure façon pour lui, autrement dit même si l’implémentation de la

Positionnement spécialisé

Faire parler de soi dans

la presse spécialisée et dans les salons du secteur

Faire des campagnes

de pub ciblées

Positionnement généraliste

Cibler des clients avec un budget

conséquent

Publiez vos travaux

Dresser des partenariats

Chercher à obtenir les

statuts silver et

gold chez l'éditeur

36

Document sous Licence Creative Common By-Sa – Yannick Buron

fonctionnalité était parfaite, vous ne seriez pas à l’abri des remarques du client pour autant. Etant

donné que ces conflits peuvent porter sur le moindre détail de l’ERP, cela peut très facilement

transformer en cauchemar la future phase de recette si vous ne prenez pas vos précautions.

La meilleure façon pour cela est de vous reposer sur la méthodologie. Je ferai par la suite une

présentation plus complète des deux types de méthodologie, mais en voici déjà une présentation

rapide en insistant sur les points relatifs aux précautions à prendre.

Pour des projets avec un budget raisonnable (au moins 20K€), mieux vaut proposer la

méthodologie complète. Proposez dans un premier temps la phase d’étude en mode régie,

en insistant bien sur le fait qu’il s’agit surtout d’une aide à la rédaction du cahier des charges

et qu’ils pourront soumettre les résultats de la phase d’étude à plusieurs intégrateurs pour

obtenir plusieurs propositions. Vous ferez bien entendu vous-même une proposition au

forfait, si possible en offrant la phase d’étude si le client vous choisit comme intégrateur.

La phase d’étude est véritablement un luxe pour un projet OpenERP, si vous pouvez la faire

alors vous serez en mesure de modéliser suffisamment les besoins du client pour faire une

proposition au forfait sans risque. Si le client tente de rajouter d’autres remarques en phase

de recette, vous pourrez lui répondre qu’il fallait transmettre ces remarques lors de la phase

d’étude et indiquer alors que ce n’est pas inclus dans la proposition forfaitaire.

Si le budget est plus réduit, alors la phase d’étude n’est malheureusement plus envisageable.

La meilleure solution dans ce cas pour prendre vos précautions vis-à-vis du client est de se

baser sur l’existant. C’est ce que propose la méthodologie simplifiée que je décris ci-après,

elle propose une intégration avec une partie forfaitaire (installation de la base OpenERP,

configuration, importation des données, refonte des factures) et une partie régie (Tout

développements supplémentaires par rapport à l’existant, formation, assistance etc…).

Dans ce cas de figure, le client doit parfaitement être conscient que l’intégration est basé sur

l’existant et de la limite de ce qui est inclus dans le forfait, cela doit être marqué sur les CGV,

dit explicitement à l’oral, et je conseille même de le mettre en titre dans le devis par exemple

« Méthodologie simplifiée avec acceptation de l’existant ». Si l’on sent que le client n’a pas

parfaitement compris les implications et qu’il a un niveau d’exigence important pour son

budget, il ne faut pas hésiter à refuser le projet.

37

Document sous Licence Creative Common By-Sa – Yannick Buron

Figure 15 Choix de la méthodologie à utiliser en fonction du projet

Avec ceci, vous pouvez normalement vous protéger contre l’insistance des clients à demander des

fonctionnalités qui n’ont jamais été évoqués à l’origine, et ainsi préserver la rentabilité de votre

travail.

Méthodologie complète avec phase

d'étude

Méthodologie simplifiée avec acceptation de

l'existant

Faible budget

Faible niveau d'exigeance

Budget important

Niveau d'exigeance du

client important

38

Document sous Licence Creative Common By-Sa – Yannick Buron

Compétences nécessaires

Qui est capable de devenir un intégrateur OpenERP ? Quelles études exiger ? Mon avis sur cette

question est très certainement sujet à débat mais je pense que n’importe qui de suffisamment

motivé ferait l’affaire car de toute façon il est quasiment impossible de trouver, à moins que la

personne ait déjà une expérience sur OpenERP ce qui est encore rare, une personne qui ait déjà

toutes les compétences requises.

En effet pour être consultant OpenERP il faut avoir une bonne connaissance des problématiques

métiers, que ce soit comptable, commercial, manutentionnaire, chef de projet, RH, etc… tout en

ayant des bonnes connaissances systèmes et réseau pour l’installation et en développement pour

faire les adaptations, en plus de bonnes qualités relationnelles pour communiquer avec le client.

Des informaticiens de formation ou des experts métiers technophiles63 sont bien entendu des

candidats de choix mais il faudra souvent les former au moins pendant 6mois avant qu’ils ne soient

pleinement opérationnels. D’anciens consultants d’autres ERPs peuvent être un moindre mal mais il

leur faudra également un peu de temps pour s’adapter à OpenERP. Quel que soit son niveau d’étude,

une personne capable de justifier d’une expérience sur OpenERP représente donc un atout pour la

société où il travaillera, et je pense qu’il est important que certaines écoles, d’informatiques ou

orientés métiers, commence à former des étudiants sur OpenERP d’autant qu’il reste l’un des ERP les

plus facile à prendre en main pour des étudiants64.

Une nouvelle personne à former sur OpenERP aura donc un nombre considérable de compétences à

acquérir et pour faciliter cet apprentissage je classe souvent les apprentis en deux catégories, les

fonctionnels et les développeurs.

Les consultants fonctionnels sont les plus nombreux car ce sont ceux qui sont au contact du client,

qui recueillent les besoins et les modélisent, qui paramètrent la base OpenERP, s’occupent des

importations, font les formations et interviennent en cas de problèmes ou de questions du client.

Ils connaissent parfaitement bien les différentes fonctionnalités d’OpenERP, que ce soit dans la

comptabilité, la gestion des ventes, stocks, projets etc… Et sont capables de parler d’égal à égal avec

le client à propos de celles-ci. Le consultant fonctionnel n’ayant généralement pas ces compétences

au début, il les aura acquis à force de tester les possibilités du logiciel en essayant de se mettre à la

place de l’expert métier qui les utilisera65.

Même si un consultant fonctionnel n’a pas à vraiment connaitre comment développer en Python, il

est préférable qu’il explore en priorité la partie administration d’OpenERP. En effet la majorité de ce

qui est défini dans un module peut également être modifié dans l’interface graphique d’OpenERP via

la partie administration, ce qui est d’une aide précieuse pour comprendre comment OpenERP

63

Par exemple des comptables ou responsable commerciaux attirés par tout ce qui est nouvelles technologies. 64

Cela ferait également du bien pour la communauté OpenERP qui est je pense trop « professionnalisée » et pas assez organisée. 65

C’est une méthode d’apprentissage que j’ai moi-même utilisée pour acquérir mes compétences métiers. Etre initié à un métier par l’outil qui lui est dédié est une méthode vraiment efficace que je recommande vivement.

39

Document sous Licence Creative Common By-Sa – Yannick Buron

fonctionne, et capital pour que le consultant fonctionnel puisse modéliser les développements à

effectuer. Cela lui permettra également de pouvoir lire par la suite les parties les plus simples mais

aussi les plus courantes du code d’un module OpenERP.

Les consultants fonctionnels n’ont que peu besoin de compétences informatiques, ils doivent surtout

avoir de bonnes qualités relationnelles, de compréhension et d’apprentissage. Leur motivation, leur

connaissance des problématiques métiers et si possible déjà des connaissances sur OpenERP doivent

primer lors de leur recrutement.

A l’inverse, les développeurs se concentrent sur l’installation et la maintenance du système qui

hébergera la base OpenERP de production, et bien entendu s’occupera de développer les modules

modélisés par les consultants fonctionnels, de développer des synchronisations avec d’autres

logiciels, modifier des rapports, etc…

Informaticien de formation, le développeur dispose déjà de bonnes connaissances en

programmation Python et en administration de système Linux. Il est également curieux de nature et

comprend l’utilité des fonctionnalités qui lui sont demandés, pour être force de proposition sur la

meilleure manière de l’implémenter du point de vue technique.

Figure 16 Répartition des compétences entre profil fonctionnel et profil développeur

Je sais que je suis l’une des rares personnes à faire cette distinction fonctionnelle et développeur. La

majorité des intégrateurs préfèrent considérer un seul type de profil, le consultant ERP capable à la

fois d’intervenir auprès du client et de développer les modules, et généralement informaticien de

formation. Je reste assez d’accord sur la nécessité de n’avoir finalement qu’une seule personne qui

intervienne sur le projet d’un client, car supprimer les échanges entre deux personnes fait gagner un

temps considérable. Toutefois, je reste convaincu qu’il n’est pas possible en début de carrière de

maitriser à la fois le fonctionnel et le développement, ce qui peut conduire à des approximations

dans le travail et qui ont tendance à persister. Fonctionnel et développement ne demandent

absolument pas les mêmes compétences et il est préférable dans un premier temps que l’employé se

Profil fonctionnel

Profil développeur

Comprend l'utilité de ce qu'on lui demande de développer et est

force de proposition

Dispose de fortes compétences en Python et en administration

système Linux

Développe les modules, les synchronisation, assure la maintenance des serveurs

Informaticien de formation

Comprend comment OpenERP fonctionne et est capable de lire

le code

Est le contact du client, dispose de bonnes qualités relationnelles et de fortes compétences métiers

Recueille les besoins et les modélisent. Configure les bases

OpenERP de production

N'est pas obligatoirement informaticien de formation

40

Document sous Licence Creative Common By-Sa – Yannick Buron

spécialise dans l’un ou l’autre des domaines, et qu’ensuite il acquiert petit à petit les compétences de

l’autre domaine jusqu’à avoir la double compétence. Comme nous l’avons vu, bien que les

compétences demandées soient très différentes, les deux distinctions sont très complémentaires et

l’employé finira par les maitriser toutes les deux au bout de quelques temps.

Une dernière chose : Dans le monde du logiciel libre, un employé qui publie des articles a une forte

valeur pour sa société car ceux-ci peuvent être repris dans un « blog des consultants » ce qui permet

à la société de se faire connaitre dans la communauté, en plus d’augmenter le référencement du site.

Un fonctionnel se doit de faire preuve d’esprit critique sur la manière dont telle ou telle

fonctionnalité est implémentée et un développeur a généralement un grand nombre de techniques

de développement à partager, en plus des modules à reverser à la communauté, autant de sujets

pour des articles à publier. Il ne faut donc pas hésiter à inciter les employés à publier, quitte à prévoir

un certain nombre d’heures par semaine, cela peut largement en valoir la peine en termes de

notoriété pour l’entreprise.

41

Document sous Licence Creative Common By-Sa – Yannick Buron

Méthodologie

La méthodologie d’implémentation que je vais décrire ci-après a été entièrement créé par moi-même

pour les besoins de ma société, même si je me suis fortement inspiré des recommandations de

l’éditeur en la matière66.

J’ai dû me pencher sur cette méthodologie, qui met l’accent sur la phase d’étude avec des livrables

précis et adaptés spécifiquement à OpenERP, du fait de la différenciation fonctionnel/développeur

qui existait au sein de SYNERPGY. Les spécifications de développements étaient en effet primordiales

pour assurer la bonne communication entre les deux profils intervenant dans un projet.

1ère partie : Premier entretien commercial avec le client

Ce premier entretien consiste aux premiers échanges entre les responsables clients et le prestataire.

Il consiste d'abord bien sûr à présenter le logiciel, la méthodologie, bref tout simplement vendre la

prestation tel que je l’ai présenté plus tôt dans ce document.

Ce premier entretien est également très important car c’est à ce moment que vous allez récupérer

les premières informations sur le projet et la société cliente :

Quels sont les chiffres clés (nombre de clients, de produits, de commandes par mois,

d’employés, d’utilisateurs etc…), quel est le type de produit vendu par la société, comment

se positionne t-elle ? Ceci permet d’acquérir une vision d’ensemble sur le fonctionnement de

la société cliente et sur les points qui sont vraiment importants pour elle.

Avec quels types de clients et de fournisseurs la société cliente est-elle en contact ? Ceci a

son importance pour prévoir les potentielles synchronisations avec des logiciels d’autres

sociétés, ou pour prévoir d’ouvrir des accès restreints sur l’ERP pour ces partenaires67.

Quels sont les logiciels utilisés actuellement par la société (Messagerie, logiciel de

comptabilité etc…) ? Ceci permet de connaitre les logiciels qui seront remplacés par OpenERP

et donc où le client attendra au moins le même niveau de fonctionnalité, et les autres

logiciels utilisés en interne qu’il faudra interfacer.

Qui est le chef de projet client ? Cette question revêt une vraie importance car il faut savoir

que de l’implication de cette personne dépendra la réussite du projet. C’est lui qui testera les

maquettes, fournira les informations, validera les choix et sera l’ambassadeur des autres

employés auprès du prestataire. Il devra également s’attendre à passer autant de temps sur

le projet que le prestataire, si ce n’est plus.

Le client doit prévoir tout cela, et le fait de poser la question et noter le nom de la personne

sur la fiche projet permet au client d’en prendre conscience.

Quels sont les différents départements de l’entreprise et les différents profils d’employés ?

Ceci permet d’imaginer le fonctionnement interne de la société et surtout de dégager les

profils d’employés qui sont très important pour définir les interfaces. On peut ainsi imaginer

66

http://www.slideshare.net/openobject/openerp-implementation-memento-5782176 67

Accès aux informations de son projet pour un client, à ses factures, faire en sorte qu’un fournisseur puisse renseigner ses produits et sa quantité en stock etc…

42

Document sous Licence Creative Common By-Sa – Yannick Buron

la quantité de travail nécessaire pour configurer les différents écrans et droits d’accès.

Il peut également être intéressant de noter sur la fiche projet le nom des employés clés qu’il

faudra interviewer en phase d’étude.

Quelle est la couverture fonctionnelle attendue ? Voilà la question capitale. Via cette

question le client va citer les différentes fonctions qui lui viennent spontanément à l’esprit,

on peut raisonnablement supposer qu’il s’agit alors des fonctions les plus importantes et il

faudra mettre l’accent dessus tout au long du projet.

Il peut s’agir à la fois des grandes fonctionnalités comme la comptabilité ce qui permet de

connaitre les grandes étapes du projet, comme des points de détails sur lesquels ont est

d’emblée prévenu que le client sera intransigeant.

Quels sont les données à importer ? On peut notamment imaginer l’importation des bases

clients, produits, stocks, comptabilité etc…

Quel hébergement prévoir ? Quel niveau de maintenance ? Ceci permet de savoir si le client

souhaite prendre ou non un serveur à son nom, et si il pourra être opportun d’essayer de

vendre le contrat de maintenance de l’éditeur.

Les réponses à ces questions seront consignées dans un document carte mentale Xmind68 dont le

modèle est en annexe. Ce document permet de visualiser facilement à la fois pour le client et le

prestataire l’envergure du projet.

Figure 17 Modèle de fiche projet

68

Les mindmaps ou carte mentales sont des types de documents permettant de facilement organiser ses idées de manière hiérarchique.

43

Document sous Licence Creative Common By-Sa – Yannick Buron

Ainsi un intégrateur OpenERP un minimum expérimenté pourra facilement déterminer le temps

nécessaire pour un tel projet et fournir au client un chiffrage global pour le projet et une proposition

pour la phase d’étude.

Une précision : Je ne vais pas parler beaucoup des méthodologies Agile69 mais il est néanmoins très

simple d’y adapter cette méthodologie. Il suffit de déterminer via la fiche projet le thème des

différentes itérations, par exemple d’abord la gestion commerciale, puis la comptabilité, puis la

gestion de projet etc… et faire pour chacune une phase d’étude/d’intégration/mise en production

centré sur le thème de l’itération. Il s’agit d’une méthode d’intégration très robuste, qui permettra

de prendre plus de temps pour tester et d’intégrer plus vite les fonctions les plus attendues de l’ERP.

2ème partie : Phase d’étude

Comme je l’ai mainte fois répété, la phase d’étude est vraiment importante. Elle va servir à

comprendre les besoins du client, à lui soumettre le fonctionnement actuel d’OpenERP pour recueillir

ses remarques, et surtout à modéliser les développements à effectuer en consignant le tout dans des

documents adaptés permettant à n’importe quel intégrateur de réaliser le projet après la phase

d’étude.

Celle-ci se déroule de la manière suivante :

1. Dans un premier temps, le consultant doit dresser des schémas BPMN70 simples du

fonctionnement actuel de l’entreprise cliente et notamment des processus. Il devra

également dresser à partir du schéma précédent comment l’entreprise souhaite faire évoluer

ces processus.

Cette partie sert uniquement au prestataire pour comprendre la problématique du client et

comment il fonctionne. Il s’agit pas encore de modéliser comment sera le processus avec

OpenERP et il ne doit donc pas se laisser brider par ce qui existe actuellement sur OpenERP.

2. Dans un second temps, le consultant va passer des entretiens avec chacun des utilisateurs

clés de l’entreprise (responsable comptabilité, responsable RH, employé représentatif etc...)

et leur posera à chacun une série de questions permettant de cibler leurs fonctions et ce

qu'ils attendent ou peuvent redouter de la mise en place de l'ERP. Cette étape est très

importante afin d'impliquer l'ensemble de l'entreprise dans le changement du système,

faciliter son acceptation et comprendre les besoins de chacun qui peuvent avoir des

préoccupations parfois éloignés de celles du chef de projet client ou de la direction et mettre

l’accent sur des détails supplémentaires.

69

Méthodologie ayant pour principe directeur le fait de ne pas faire toute l’intégration d’un coup (Par opposition aux méthodes dites « Big bang ») mais au contraire en implémentant progressivement, département après département. Chaque étape se nomme itération, on ne passe à l’itération suivante que lorsque l’on considère que celle-ci a été parfaitement et complètement réalisée. 70

Norme de schématisation relativement simple à comprendre et couramment utilisée qui permet de modéliser des processus.

44

Document sous Licence Creative Common By-Sa – Yannick Buron

Chaque entretien fera l'objet d'un livrable sous forme d’une autre carte mentale dont le

modèle est en annexe71.

3. A ce stade, le consultant dispose d’une compréhension suffisante de la problématique du

client pour commencer à faire une maquette. Celle-ci servira à définir l'interface utilisateur et

en profiter pour fournir un premier aperçu déjà relativement complet du résultat final.

Pour la réaliser, il s’agit de profiter d'une particularité unique d'OpenERP : Faire des

modifications sur l'interface utilisateur, modifier un menu, un formulaire, des droits d'accès,

prend extrêmement peu de temps via l’interface graphique si bien qu’il est possible de la

faire directement en rendez-vous avec le client et ainsi recueillir directement ses remarques.

Ceci permet de faire évoluer la maquette en temps réel jusqu’à arriver à un résultat au

niveau des interfaces qui sera le résultat final du projet. Il est évidemment très rassurant

pour le client d’avoir une telle maquette sous les yeux, et c’est pour cela qu’il faut la réaliser

en premier dans la phase d’étude.

Attention néanmoins à ne pas tomber dans le piège et être tenté de faire les modifications

uniquement à l’interface graphique sur la future base de production sans les pérenniser dans

un module. On peut être certain que les modifications seront perdus à la première migration

majeure voire simple mise à jour du système, aussi porter les modifications dans un module

en phase d’intégration reste indispensable. Les modifications via interface graphique ne

doivent servir qu’à faciliter la réalisation de la maquette en face à face avec le client.

Le livrable de cette partie sera la maquette OpenERP elle-même, qui sera confiée au client au

format SQL et avec la version d’OpenERP et de ses modules qui ont été utilisés pour la faire.

4. La maquette est d’une aide précieuse pour modéliser et soumettre au client les adaptations

à faire sur l’interface. Elle est en revanche inutile pour représenter tout ce qui concerne

l’adaptation aux processus de l’entreprise.

Le consultant va donc dresser les futurs processus BPMN de la société cliente, qui seront

bien plus détaillés que les premiers processus qui ont été fait en indiquant notamment

précisément où chaque champ va chercher ses informations et sous quels évènements, s’il

s’agit d’une action manuelle ou automatique etc…

Ces schémas de processus vont définir comment les différents domaines fonctionnels de

l'ERP vont interagir entre eux, comment telle information sera envoyée au service

comptabilité, sur quel base le commercial saura qu'il reste telle quantité de tel produit en

stock etc... Il s'agit à la fois du document de référence sur le futur fonctionnement de la

société comme des premières informations techniques sur les processus concernant les

adaptations à développer.

Un certain nombre d’exemple de processus est disponible en annexe72 ou sur le site internet

de SYNERPGY. Ils représentent un considérable travail pour être maintenu à jour, aussi dans

le cas contraire on peut se contenter dans cette étape de simplement modéliser les points

nécessitant des développements. La modélisation de ces développements est importante car

71

http://www.synerpgy.fr/sites/default/files/carte_mentale_interview_employe.xmind 72

Finalement, la taille limite de fichiers pour le rendu de mémoire rendra impossible le fait de joindre les exemples de processus. Seul le processus de gestion des stocks sera joint au travail.

45

Document sous Licence Creative Common By-Sa – Yannick Buron

il s’agit de la meilleure manière pour chacune des parties de pouvoir visualiser leur futur

fonctionnement, ce que l’interface de la maquette ne peut montrer.

46

Document sous Licence Creative Common By-Sa – Yannick Buron

47

Document sous Licence Creative Common By-Sa – Yannick Buron

Figure 18 Exemple de modélisation de processus, ici le processus de stock-achat-fabrication

5. Le livrable suivant concerne le document des spécifications techniques, disponible également

en annexe73. Toutes les adaptations à réaliser pour adapter l’ERP aux processus modélisés,

toutes les modifications effectuées sur l'interface pour la maquette, sont consignées dans ce

document dans l'objectif d'être pérennisés par la suite dans un module OpenERP au nom de

la société cliente.

Ce document est rédigé de tel sorte qu'il soit compréhensible facilement par n'importe quel

intégrateur OpenERP. Il s’agit en quelque sorte du document qui résume le travail fait sur la

maquette et les processus, et dois donc être rédigé au fur et à mesure de l’avancement de

ceux-ci.

6. La dernière partie de la phase d’étude consiste à récupérer les informations de configuration

du client via un certain nombre de questions. Il peut s’agir de récupérer l’adresse de la

société, les en-têtes de document, les informations sur la configuration de la comptabilité,

les catégories de produits, de partenaires, les départements de l’entreprise, la liste des

emplacements de stocks etc… Le genre d’information que nombre de clients ne pensent

jamais à transmettre à leurs prestataires.

Cela peut représenter un nombre important de questions, facilement plus d’une

cinquantaine par projet. Celles-ci ont été répertoriées dans le moteur de cahier des charges

disponible sur le site de SYNERPGY, le consultant peut y aller et sélectionner les questions

pertinentes concernant le projet pour les transmettre au client.

Il peut évidemment être pertinent de faire ce travail, qui nécessite peu de travail de la part

du consultant mais beaucoup de recherche de la part du client, en début de la phase d’étude

afin d’avoir les réponses à la fin de celle-ci.

Figure 19 Image du moteur de cahier des charges disponible sur http://cahier_charges.synerpgy.fr

Une fois la phase d’étude finalisée, vous pouvez transmettre les livrables au client et lui faire une

proposition forfaitaire pour la mise en œuvre de son ERP.

73

http://www.synerpgy.fr/sites/default/files/specifications_techniques_formation_technique_0.ods

48

Document sous Licence Creative Common By-Sa – Yannick Buron

3ème partie : L’intégration et la mise en production

Une fois le projet signé, il va être temps de commencer à mettre en place la future base de

production.

La première chose à faire est bien entendu de préparer le serveur qui hébergera l’ERP, souvent un

serveur dédié au client sauf en cas d’hébergement en SaaS. Je déconseille vivement de l’héberger

sous du Windows tout simplement car très peu de personnes le font et je n’ai aucun retour sur les

problèmes éventuels.

Il est donc fortement conseillé de l’héberger sur un serveur sous Linux, de préférence une

distribution Debian qui sera plus fiable au niveau des dépendances. Même si j’ai déjà fait tourner un

serveur OpenERP de production sous une distribution Ubuntu, Debian reste plus adapté pour cet

usage grâce à sa stabilité plus que reconnue.

La procédure d’installation consiste principalement à installer les dépendances Python, la base de

données PostgreSQL, télécharger les fichiers d’OpenERP, les configurer et faire en sorte qu’ils se

lancent au démarrage du système. Il est également recommandé de rediriger le port https du serveur

vers le client web d’OpenERP via la fonction reverse proxy d’Apache pour que l’accès via le client web

soit sécurisé. Il s’agit de données d’entreprise ne l’oublions pas.

Vous pouvez ensuite commencer à créer la base de production, la configurer, développer le module

du client suivant les spécifications de la phase d’étude etc… Pour les synchronisations, pensez à

utiliser l’ETL Pentaho qui peut se révéler un outil très puissant pour cet usage, surtout depuis qu’il

existe un module permettant de se connecter au serveur OpenERP et non directement à la base de

donnée, fiabilisant considérablement les transactions.

Tout ce travail se fait généralement sans l’intervention du client et chez le prestataire car toutes les

informations ont normalement été récupérées en phase d’étude. Une fois la base de production

finalisée, le consultant revient chez le client pour la phase de recette.

Il arrive souvent que le client critique à ce moment la manière où telle ou telle fonctionnalité

d’OpenERP est implémentée. Il convient d’être ferme alors car ces remarques auraient dû apparaitre

lors de la phase d’étude, dans ce cas prenez note et indiquez que vous y travaillerez pendant une

phase future du projet après la mise en production. Pareil si cela concerne une erreur dans les

spécifications, le client les a validées autant que vous, vous n’avez à répondre que si le résultat

diffère des spécifications.

Pour faciliter le test de la solution, il peut être intéressant de demander à quelques employés de

jouer le rôle de pilote et d’utiliser l’ERP dans leur travail quotidien, si nécessaire avec une double

saisie sur l’ancien système.

49

Document sous Licence Creative Common By-Sa – Yannick Buron

Si des malfaçons74 bloquantes pour le projet et non spécifiés en phase d’étude apparaissent, il vous

faudra indiquer au client que cela n’est pas inclus dans la proposition forfaitaire. Vous pourrez

souvent vous permettre de faire un geste commercial mais attention cela peut rapidement se

retourner contre vous car le client essaiera ensuite surement de tenter de corriger d’autres

malfaçons non spécifiés.

Une fois que le client confirme que le produit est prêt à être lancé en production, demandez

impérativement la réception écrite du produit75. Ceci obligera le client à s’assurer que le produit est

vraiment prêt pour la production et surtout vous immunisera contre d’autres remarques que le client

pourrait émettre par la suite alors que vous avez commencé à travailler sur un autre projet.

Une fois ceci fait, vous pouvez commencer à former les utilisateurs, que ce soit vous-même qui vous

en chargiez ou le chef de projet client, et décider d’une date de mise en production.

L’assistance au démarrage, qui est prévu dès le départ dans la proposition forfaitaire, permettra de

faciliter le lancement en production. Il s’agit d’une période prévue à l’avance où vous prévoyez d’être

disponible chez le client pour répondre aux questions ou régler les derniers détails. Il s’agit

généralement de prévoir une journée par semaine pendant un mois après la mise en production puis

une journée par mois pendant 4mois par exemple.

En dehors de l’assistance au démarrage, les pannes seront couverts par le contrat de maintenance et

les diverses questions par le support décrit plus haut dans ce document.

Figure 20 Méthodologie complète d'intégration OpenERP

Méthodologie simplifié

74

Il s’agit d’un terme que j’utilise souvent pour désigner une fonctionnalité qui n’est pas implémenté de la meilleure des manières, que ce soit d’après l’avis général ou d’après un client uniquement, et qui n’a rien à voir avec le terme « bug ». 75

Il s’agit de l’acte par lequel le client confirme que le travail a été réalisé, reçu et est conforme à ses exigences.

Premier entretien avec le client

• Recueil des premières informations du projet

• Création de la fiche projet

Phase d'étude

• Modélisation des processus existants

• Comprendre le fonctionnement actuel de la société cliente

• Interview des utilisateurs

• Comprendre les besoins de chaque département

• Réalisation de la maquette

• Définir les interfaces, les droits d'accès, rassurer le client sur la faisabilité du projet

• Modéliser les processus OpenERP

• Modéliser de manière précise le fonctionnement futur du processus

• Rédiger le document des spécifications techniques

• Résumer les développements à réaliser

• Faire remplir le questionnaire de configuration au client

• Permet de récupérer les informations nécessaires pour configurer la base de production

Phase d'implémentation

• Mise en place du serveur de production qui hébergera OpenERP

• Création de la base OpenERP de production

• Configuration de la base de production

• Développements

• Importation des données

• Phase de test et de recette

• Formation des utilisateurs

• Reception de l'OpenERP

Phase de production

• Assistance au démarrage

• Maintenance

• Support

• Sauvegardes

• Supervision

50

Document sous Licence Creative Common By-Sa – Yannick Buron

Il faut le dire, la méthodologie que je viens de décrire est très complète, peut prendre du temps et ne

pas convenir à tous les budgets. Il ne faut pas hésiter, dans la mesure où l’on est certain que le client

a correctement testé le logiciel et fait part de toutes ses remarques, à faire rapidement la phase

d’étude. C’est elle qui spécifie les détails du contrat, si le client a oublié de mentionner certaines

demandes il pourra toujours le faire dans un futur projet ou si c’est vraiment important le

mentionner à la fin du projet et en dehors du forfait.

Toutefois, certains projets ne laissent parfois vraiment pas le temps pour une phase d’étude. C’est

notamment le cas si vous ciblez les TPEs. Il faut dans ce cas procéder différemment.

Comme indiqué plus tôt, il faut alors baser le périmètre du contrat à l’existant d’OpenERP et que le

client soit bien conscient de cette limitation.

L’entretien initial avec le client se passe exactement de la même façon, avec la même fiche projet qui

sera créée. C’est d’ailleurs à ce moment que vous pouvez décider si la méthodologie complète est

indispensable ou si vous pouvez proposer la méthodologie simplifiée au client.

Pour la méthodologie simplifiée, elle vous permettra de déterminer directement la proposition à

faire au client, avec une partie forfait et une partie régie. La partie forfait inclura tout ce qui est

installation du serveur, configuration de la base, modification des rapports et importation de fichiers,

tandis que tout ce qui est développement, formation, synchronisation ne sera inclus que dans la

limite de la durée totale de jours correspondant au devis, ce qui s’apparente plus à de la régie.

Précisons que c’est le consultant qui décide de la priorisation du travail à effectuer, pour s’assurer

que la partie forfaitaire du travail soit finalisée dans les temps.

Avant d’estimer la proposition, pensez toutefois à envoyer au préalable les questions de

configurations de la base, en insistant pour avoir les fichiers à importer et les modèles de rapport76.

Les informations qu’il vous transmettra à ce moment correspondront au cahier des charges et donc à

la partie forfaitaire de la proposition. Faites enfin votre proposition en conséquence.

Une fois la proposition acceptée, procédez directement à l’intégration en installant le serveur et

créant et configurant la base de production. Une fois que vous pensez avoir intégré toute la

configuration demandée par le client et que la base de production est utilisable, vous pouvez

considérer que la partie forfaitaire de la prestation est finalisée.

Assurez vous qu’il reste encore du temps sur le projet, et dupliquez la base de production sur une

base de test que vous allez tester avec le client. Prenez note de ses remarques et faites les

corrections tant que vous restez dans la durée spécifiée par votre proposition. N’oubliez pas que

vous ne devez pas faire de correction à l’interface graphique à ce stade, corrigez directement dans un

module au nom du client.

Si vous arrivez au bout de la durée et que le client a toujours des remarques, ce sera à lui de décider

s’il souhaite continuer en mode régie, en tout les cas même si il décide de s’arrêter il aura une base

OpenERP utilisable grâce à la partie forfaitaire de la prestation.

76

Il s’agit généralement des modèles de devis et de facture.

51

Document sous Licence Creative Common By-Sa – Yannick Buron

Figure 21 Méthodologie simplifiée d'intégration OpenERP

Premier entretien avec le client

•Recueil des premières informations du projet

•Création de la fiche projet

•Décision de partir sur une méthodologie simplifiée

•Transmission du questionnaire de configuration

Partie forfaitaire du projet

•Installation du serveur OpenERP

•Création de la base de production

•Configuration de la base de production

•Modification des rapports et importation des données

Partie régie du projet

•Test du logiciel avec le client

•Configuration supplémentaire non indiquée sur le questionnaire par le client

•Développements

•Formations

•Assistance

52

Document sous Licence Creative Common By-Sa – Yannick Buron

Choix et stratégie de la société SYNERPGY depuis sa création, et

autocritique

On dit souvent que l’on apprend surtout de ses erreurs, et si je peux aujourd’hui présenter tous mes

commentaires sur la création d’une société d’intégration d’OpenERP c’est que j’ai fait de nombreuses

erreurs pendant l’aventure SYNERPGY.

Evolution de la structure

Sur le plan des ressources humaines d’abord. La société SYNERPGY a commencé avec moi, mon ami

développeur et six stagiaires qui étaient également intéressés par OpenERP. Pure folie évidemment

que de penser trouver des contrats pour toutes ces personnes alors que la société venait tout juste

de démarrer et la période d’été a ainsi principalement consisté à apprendre tous ensemble le

fonctionnement du logiciel.

Au moins cela n’était pas une si mauvaise chose car vu le nombre de notions non seulement

informatique, mais aussi de comptabilité, commercial etc… Etre tous ensemble à faire des recherches

sur le logiciel à ce moment là m’a personnellement beaucoup aidé pour acquérir mes propres

compétences et je ne puis qu’espérer qu’eux aussi.

A la fin de leur stage, ayant pris un peu plus conscience de la difficulté pour trouver des contrats sur

OpenERP, seul est resté moi, le développeur et le stagiaire qui était le plus motivé, ce qui était déjà

beaucoup plus réaliste. Nous avons trouvé nos premiers contrats peu après.

Je dois en profiter pour remercier mon ami développeur qui fait encore partie de la société

aujourd’hui après deux ans. Pour faciliter le démarrage de la société il a accepté d’être en statut

autoentrepreneur le temps de pouvoir l’embaucher et d’être payé en fonction des contrats, me

donnant plus de marge de manœuvre quand nous en manquions. En résultat vu la faible réussite de

la société il n’a pas été payé autant qu’il le méritait mais du moins est-ce lui qui a le plus profité du

chiffre d’affaire de la société, moi-même n’ayant pratiquement pas touché de salaire finalement.

Moi et le stagiaire restant faisions du bon travail en tant que consultant fonctionnel mais on n’y

serait pas arrivé si nous avions dû également nous occuper du développement. C’est pourquoi je ne

regrette pas de lui avoir demandé son aide, je reste persuadé que les deux types de profil sont

indispensables pour créer une structure sur OpenERP.

Pour ne pas répéter les mêmes erreurs, je recommande aux créateurs s’orientant sur OpenERP de ne

pas partir seul mais de ne pas non plus sous-estimer le nombre de contrat que nécessite toute

personne supplémentaire. Deux voire trois personnes, associées de préférence, sont un maximum

pour lancer une telle structure.

Pour en finir sur le sujet, le stagiaire a fini par nous quitter à la fin de l’été dernier, souhaitant voir

plus de développements dans d’autres secteurs de l’informatique. Ne pouvant pas assurer seul la

partie fonctionnelle du travail avec mes études en parallèle, j’ai décidé d’embaucher à temps partiel

un autre de mes amis qui avait quelques problèmes d’orientation professionnel. C’était un risque

calculé pour lui car l’expérience acquise sur une spécialisation tel qu’OpenERP lui permettra

53

Document sous Licence Creative Common By-Sa – Yannick Buron

désormais certainement de se faire embaucher par un autre intégrateur OpenERP, les candidats

ayant déjà de l’expérience sur le logiciel étant encore très rares.

Positionnement commercial

Au niveau du positionnement commercial il faut avouer que je n’ai pas été bon non plus. N’ayant pas

de carnet d’adresse dans un secteur particulier je n’ai pas pu me spécialiser et je suis donc resté sur

un positionnement très généraliste.

Dans un premier temps, j’ai souscrit au partenariat de l’éditeur. Ceci a représenté un investissement

mais nous a permis de recevoir quelques prospects qui nous ont permis de tenir pendant la première

année. Il ne s’agissait malheureusement pratiquement que de TPEs et nous n’avons pas pu être

rentable par rapport au temps qu’on passait sur chaque projet, j’y reviendrais un peu plus tard mais

les négociations n’étaient pas non plus mon fort.

J’ai testé plusieurs solutions pour améliorer le nombre de prospects. La prospection directe tout

d’abord, en croisant les informations des pages jaunes avec l’annuaire des entreprises de la chambre

du commerce. Ce dernier annuaire fut mine de rien très efficace, me permettant de cibler les

entreprises à contacter par taille et secteur d’activité.

Je n’avais donc pas de problème pour obtenir les numéros, mais il en allait autrement une fois l’appel

passé car je me rendais compte à chaque fois que le prospect n’avait pas l’intention de changer son

système de gestion. D’où ma conclusion qu’il ne servait à rien d’obtenir les coordonnées d’un

prospect, il fallait surtout les obtenir au bon moment et donc laisser le prospect venir à nous quand il

en avait besoin.

Je me suis alors concentré vers l’amélioration de la notoriété de SYNERPGY, via la création du site

internet et de mon blog, et la publication de documents pouvant intéresser la communauté. Ne

souhaitant guère intervenir directement sur Launchpad dans les discussions très longues sur

l’implémentation de telle ou telle fonctionnalité, je préférais publier sur des thèmes plus globaux à

savoir la méthodologie, comment définir des spécifications techniques sur OpenERP et comment

organiser sa communauté. Ceci m’a également permis de me rapprocher et d’échanger avec d’autres

intégrateurs OpenERP.

J’ignore aujourd’hui si toutes ces publications ont vraiment été lues par les autres intégrateurs ou si

cela m’a apporté quelques clients, mais je suis content de l’avoir fait car je pense que ce travail

servira certainement plus tard quoi qu’il arrive. En tout cas avec le recul, la meilleure manière que

ma participation à la communauté rapporte des clients aurait certainement été de participer sur les

forums, que ce soit ceux d’OpenERP ou non, comme le fait la société SISalp dont le gérant est un bon

ami. Participer aux forums est un bon moyen de publier son expertise sur OpenERP tout en aidant

des potentiels futur client, un moyen que j’ai négligé par manque de temps.

J’ai également envisagé un temps de sous-traiter la prospection à des sociétés spécialisées, mais je

me suis rapidement et heureusement rendu compte que c’était une mauvaise idée. Ces sociétés sont

très chère et surtout n’ont pas d’engagement de résultat ce que je trouve paradoxal.

Ayant expérimenté personnellement toutes les difficultés pour trouver les clients, je craignais qu’un

commercial qui était loin de pouvoir répondre aussi bien que moi aux questions très spécifiques du

prospect sur les ERPs n’arrive aucunement à rapporter des contrats. Ces sociétés auraient donc

54

Document sous Licence Creative Common By-Sa – Yannick Buron

certainement achevé SYNERPGY.

J’en étais d’autant plus certain que j’avais embauché à mi-temps peu auparavant un étudiant en

école de commerce dont le bilan a été nul. Non pas qu’il manquait de motivation ou de compétence,

mais je crains qu’il ne soit très difficile de vendre de l’OpenERP sans être soi-même consultant

intégrateur.

A la fin des cours en avril dernier, dans une dernière tentative pour assurer la rentabilité de la

société, j’ai tenté de dresser des partenariats avec d’autres sociétés complémentaires de nos services

d’intégration d’OpenERP, notamment les intégrateurs d’e-commerce. Une bonne idée je pense mais

que j’aurais dû mettre en œuvre plus tôt pour que cela ait un réel impact sur la survie de la société.

Relation avec les clients, méthodologie et organisation administrative

Le plus important problème auquel j’ai dû faire face n’était pourtant pas forcément le nombre de

client, mais le montant que j’arrivais à leur facturer. La majorité d’entre eux étaient des TPEs pour

qui quelques milliers d’euros pour un logiciel de gestion étaient déjà une somme très importante,

sans aucune réalité de ce que coûte réellement une intégration ERP à savoir plusieurs dizaines de

milliers d’euros.

Ainsi nous avons passé beaucoup plus de temps sur chaque projet que le montant effectivement

facturé au client. Au début nous nous disions que c’était normal, le temps que nous soyons vraiment

efficace sur le logiciel, mais plus le temps passait et plus nous nous rendions compte que l’abus des

clients était vraiment une problématique à part entière dans le secteur des ERPs.

Par ailleurs, je n’étais guère bon en négociation que si j’avais derrière moi des arguments imparables.

C’est pour cette raison que je me suis donné tant de mal sur la méthodologie, c’était pour moi le

meilleur moyen de légitimer des chiffrages de projets supérieurs à dix mille euros. Mais avant que

cette méthodologie ne soit faite, nous avons dû finir des projets qui ont pris des mois pour un budget

ridicule, en affrontant notamment également l’instabilité d’OpenERP à cette époque.

Malheureusement une fois la méthodologie en place, si cela pouvait nous aider à tirer les budgets

vers le haut il n’en restait pas moins que nous n’avions que des TPEs pour client. D’où l’intérêt de la

méthodologie simplifié qui nous permettait au moins d’accepter des contrats faibles en restant un

minimum rentable puisqu’on pouvait limiter les exigences du client.

Je recommande sincèrement aux créateurs de suivre les différents conseils que je donne au niveau

de la méthodologie pour restreindre les exigences des clients qui n’en ont pas le budget. Même si au

début des efforts sont inévitables il faut impérativement cadrer dès le début du projet le périmètre

de la prestation pour rester rentable.

Enfin pour finir sur une note plus positive devant toutes ces difficultés, OpenERP permet bien sûr,

outre d’apporter de nombreuses compétences à son contact, de grandement faciliter

l’administration de la société. Encore heureux me direz-vous…

Les modules qui auront été le plus utile ont été le CRM, la gestion des ventes, la comptabilité et la

gestion de projet.

Le CRM et la gestion des ventes m’ont permis de suivre les prospects et d’envoyer les devis

rapidement. Cela avait vraiment son importance car comme je passais d’un travail à un autre, sans

55

Document sous Licence Creative Common By-Sa – Yannick Buron

compter mes études, cela me permettait de garder un historique très précieux pour quand je

retournais à la prospection.

La comptabilité, en plus de gérer les factures, m’a permit de faire ma comptabilité moi-même, en

minimisant l’intervention de l’expert comptable au minimum. La note de l’expert comptable s’est

donc limité à environ mille euros par an ce qui est raisonnable, sans compter les compétences en

comptabilité que j’ai pu acquérir.

Enfin la gestion de projet m’a surtout permis de garder trace des différents travaux pour surveiller la

rentabilité des projets. Au moins de voir la rentabilité catastrophique en tout cas.

Ceci clôture le bilan de SYNERPGY, qui n’est certes guère glorieux. Néanmoins si c’était à refaire je le

referais sans hésiter, certes pas de la même façon bien sûr mais je le referais pour l’expérience et les

compétences que cela m’a apporté.

56

Document sous Licence Creative Common By-Sa – Yannick Buron

L’environnement d’OpenERP

Le modèle économique de l’éditeur d’OpenERP

Même si elle ne l’interdit pas explicitement, le droit de redistribution rend complètement non-viable

pour un logiciel libre le modèle économique habituel à base de vente de licence. Les éditeurs de

logiciels libres doivent faire preuve d’imagination pour arriver à trouver des modèles économiques

viables77.

Le plus utilisé, et de loin, consiste à la vente de service au client autour du logiciel. C’est en plus un

très bon argument de vente car il est possible de dire que tout ce que paye le client est un service

personnalisé, il n’a pas à payer le droit d’utiliser le logiciel ce droit étant garanti par la licence. La

majorité du travail généré par le logiciel libre provient de ces services, notamment pour les sociétés

d’intégration ou d’hébergement. En revanche il est assez rare que les éditeurs se reposent dessus.

Les éditeurs dans le monde du logiciel libre sont souvent des fondations qui fonctionnent sur la base

de dons ou de partenariat avec des sociétés importantes, comme la fondation Linux, Mozilla, Apache,

etc…

Malheureusement c’est vrai pour des logiciels libres ciblant principalement le grand public. Les

logiciels libres à destination des entreprises sont généralement organisés par des éditeurs

commerciaux. Non que ce soit forcément un mal, mais ceux-ci ont tendance dans leur recherche d’un

modèle économique viable à partir sur le modèle de la double licence78, ce qui est souvent vécu

comme une entorse au logiciel libre par la communauté car l’éditeur a intérêt dans ce cas de figure à

brider le développement de la version libre du logiciel.

Comme vous le verrez plus tard, je ne manque pas de reproche à faire à l’éditeur d’OpenERP mais la

double licence n’en est pas une. A mon sens ils ont même fait preuve d’un certain acharnement à

éviter à tout prix ce piège en multipliant les business models :

La vente d’un contrat de partenariat avec les intégrateurs OpenERP, incluant une visibilité sur

le site internet officiel, la transmission des prospects que reçoit l’éditeur, des réductions sur

les services de l’éditeur notamment les formations et des rétro-commissions sur la vente des

services de l’éditeur.

Comme tout éditeur, celui-ci évite de traiter directement les projets des clients pour les

transmettre aux intégrateurs. Le contrat de partenariat lui permet ainsi d’assurer la création

d’un large réseau de partenaire à travers le monde tout en en tirant un revenu important.

Comme je le disais plus tôt, ce contrat est particulièrement intéressant une fois la société

bien établie pour avoir le label « Gold », très efficace pour la prospection, mais d’un intérêt

limité pour une entreprise qui débute.

L’autre principal revenu de l’éditeur est le contrat de maintenance, qui permet au client de

profiter d’une garantie en cas de bugs sur les modules certifiés et des migrations majeures

77

http://www.zdnet.com/blog/open-source/11-open-source-business-models/5371 78

Ce modèle consiste à avoir une version libre mais allégée en fonctionnalité et en parallèle une version entreprise plus complète et sous une licence propriétaire.

57

Document sous Licence Creative Common By-Sa – Yannick Buron

d’OpenERP. Comme dit plus tôt, il n’est pas réaliste pour un intégrateur de proposer une

garantie sur les modules certifiés aussi ce contrat est obligatoire pour une société souhaitant

impérativement s’assurer toutes les garanties pour la bonne marche de son ERP.

On peut néanmoins faire deux reproches à ce contrat. Le premier est qu’il n’inclus pas les

modules non-certifié de la communauté, l’éditeur aurait gagné à dresser des accords avec les

principaux contributeurs pour augmenter l’intérêt de ce contrat de maintenance et aussi

inciter les contributeurs à proposer des modules de qualités.

L’autre consiste en la migration. Tant que la communauté ne trouvera pas une solution

concurrente, l’éditeur est le seul à pouvoir faire les migrations vers les migrations majeures

d’OpenERP ce qui en fait bel et bien une sorte de double licence sur une fonction vitale du

produit. Ceci a été plutôt mal vécu par la communauté et même si cela a certainement

apporté quelques clients à l’éditeur on peut se poser la question si ce choix était réellement

pertinent.

L’éditeur propose également un service d’hébergement en SaaS. Celui-ci, au pire à

39€/mois/utilisateur est extrêmement compétitif par rapport à d’autres offres SaaS

d’éditeurs propriétaires dépassant souvent les 100€/mois/utilisateurs79. Malheureusement,

OpenERP n’est pas un produit prêt à l’emploi et nécessite encore souvent un intégrateur,

aussi je doute de la réussite du service.

En tout cas pour le moment, car le jour où OpenERP disposera d’un niveau de fonctionnalité

suffisant et sera véritablement prêt à l’emploi, ce service sera extrêmement bien positionné

pour répondre à une large part de la demande des TPEs.

L’éditeur propose également un service de certification de module, permettant ensuite au

module qui peut être soit un module de la communauté soit un module spécifique au client

d’être inclus dans les contrats de bugfix et dans les migrations.

Là par contre je suis certain que ce service n’a pratiquement aucun succès, car que ce soit un

client ou un intégrateur, personne n’a envie de payer la certification en plus du temps-

homme qui a été investi pour le développer. Ce service a certainement besoin d’être

entièrement revu.

Enfin, l’éditeur inclus depuis quelque mois dans le contrat de maintenance une exception à la

licence permettant à la société cliente de ne pas redistribuer le code source de ses modules

personnalisés à ses employés en cas d’utilisation interne, dans le potentiel objectif de

protéger ses méthodes de travail. Cela ne viole pas l’esprit des licences libres car il s’agit

toujours d’un usage uniquement interne80.

En revanche, il faut bien savoir que l’on n’est pas vraiment sûr que la licence libre AGPL,

utilisée pour OpenERP, oblige à redistribuer le code source aux employés81. Dans le doute,

cela fait toujours un argument supplémentaire et qui ne porte pas à conséquence pour

vendre le contrat de maintenance aux clients souhaitant à tout prix protéger leurs

développements personnalisés.

79

http://www.indexel.net/applications/erp-en-mode-saas-les-grands-editeurs-tous-presents-3204.html 80

http://yannick_buron.synerpgy.fr/mon-point-de-vue-sur-le-changement-de-licence-dopenerp/2011/06/30/ 81

http://www.openerp.com/forum/post87088.html?sid=46e05a1b0e41e029efadddefdcb7f792#p87088

58

Document sous Licence Creative Common By-Sa – Yannick Buron

Comme vous pouvez le constater, l’éditeur a basé une grande partie de son modèle économique sur

la fourniture de services, que ce soit aux partenaires ou aux clients. En diversifiant ses offres, il a ainsi

pu dresser un modèle que j’espère pour lui rentable sans violer l’esprit du logiciel libre.

La seule exception concerne les migrations, et j’espère sincèrement qu’il y aura un jour un

changement de politique à ce niveau.

De nombreux membres de la communauté critiquent le fait que les statuts « Silver » et « Gold »

soient uniquement indexés sur le nombre de contrat de maintenance apporté par le partenaire, sans

prendre en compte son niveau de contribution au code.

Mon avis sur la question est qu’il est vrai qu’une visibilité aussi importante que ces statuts doivent

être délivré de manière réfléchie et sans doute avec un profit pour l’éditeur, un bon compromis

serait certainement de créer un statut à part « Top contributeur » indépendant des statuts « Silver »

et « Gold » et leur offrir la visibilité sur le site internet même sans le partenariat. En effet un certain

nombre de partenaires pourtant d’importants contributeurs refusent désormais le contrat de

partenariat pour protester contre leur non-reconnaissance et ne sont donc même pas visible sur le

site officiel ce qui est vraiment regrettable.

59

Document sous Licence Creative Common By-Sa – Yannick Buron

Les limites d’OpenERP

Que ce soit dit, tout n’est pas parfait sur OpenERP. Certes le produit est basé sur une technologie que

je pense comme étant bien meilleure que celle des ERPs propriétaires, certes c’est aussi et de loin

l’ERP libre le plus avancé au niveau de la couverture fonctionnelle. A ce titre, comme il n’y a

généralement qu’un seul logiciel libre qui finit par réellement s’imposer sur un marché, c’est sans

doute OpenERP qui sera toujours l’ERP de référence dans quelques années.

Mais il y a quand même un certain nombre de problèmes, principalement dû à la manière dont la

communauté et le produit est géré. A ce titre, c’est donc principalement l’éditeur que j’accuse.

Dans un premier temps, on constate une volonté extrêmement forte de la part de l’éditeur à vouloir

garder la complète propriété du logiciel, en faisant notamment en sorte qu’ils soient les seuls à écrire

du code dans les fichiers du serveur, client, serveur web et des modules certifiés. Ils s’assurent ainsi

de pouvoir faire évoluer la licence quand ils veulent comme ils l’ont fait récemment en rajoutant

l’exception à l’AGPL82.

Quel objectif ils poursuivent en faisant cela, je n’en sais rien. Il peut très bien s’agir du simple fait de

vouloir se laisser plus de marge de manœuvre pour l’avenir, mais en revanche ce que je sais c’est les

conséquences que cela a sur l’évolution du produit.

En voulant garder la pleine propriété du cœur du logiciel, ils se privent de facto du fait de pouvoir

intégrer les contributions de la communauté, cantonné aux simples modules supplémentaires.

Profiter des idées et contributions de la communauté est un des principaux avantages d’un logiciel

libre, qui permet de compenser le faible budget R&D par rapport à un éditeur propriétaire. Ne pas en

profiter est un suicide pour le produit et nullifie les avantages du logiciel libre en terme de qualité,

sans cela le produit n’arrivera jamais à égaler la qualité d’un éditeur propriétaire.

Alors certes, la majorité des logiciels libres à destinations des entreprises fonctionnent sur le modèle

d’une double licence, et l’éditeur possède également la propriété sur l’ensemble du code de la

version libre. Ceci n’a pas empêché le succès de Magento83, Pentaho et Talend84, Zimbra85 ou encore

Alfresco86.

Mais je pense sincèrement que ce n’est pas comparable car les ERPs sont une problématique

réellement à part. Un ERP dispose d’une courbe de progression réellement gigantesque, il y a

toujours des améliorations à faire, de meilleures manières d’implémenter les fonctionnalités, etc… Et

82

Que, pour rappel, je ne condamne pas personnellement mais la manière dont cela a été fait a été brutale, sans concertation, et mal acceptée par la communauté. 83

CMS très utilisé pour créer des sites d’e-commerce. Il a été récemment racheté par EBAY. 84

Deux logiciels de Business intelligence, permettant de générer des rapports statistiques en se basant sur les données de l’entreprise. 85

Un serveur d’email. 86

Logiciel de gestion documentaire.

60

Document sous Licence Creative Common By-Sa – Yannick Buron

sans profiter un maximum de la communauté, OpenERP restera toujours derrière les ERPs

propriétaires.

C’est assez dommage qu’après avoir fourni tant d’effort au niveau du modèle économique pour

éviter la double licence, et ainsi avoir autant intérêt que la communauté au fait qu’OpenERP soit le

meilleur produit possible, l’éditeur se mette autant de bâton dans les roues en essayant à tout prix

de garder la propriété du logiciel.

Cela a conduit a des situations paradoxales, voire même proprement scandaleuse, où l’éditeur a

réécrit des parties entières du logiciel, et a parfois voulu intégrer des modules de la communauté en

les réécrivant complètement87. Il aurait été tellement plus rentable pour le produit d’utiliser les

mêmes ressources à passer en revu les plus de 1000 modules de la communauté pour en intégrer les

meilleurs, plutôt que de refaire un travail, parfois même en moindre qualité, et de briser ainsi les

efforts de la communauté.

Un dernier mot sur le sujet : Les logiciels libres sont généralement soit basés sur un éditeur soit sur

une communauté. Ceux basés sur un éditeur sont avantagés lors de la naissance du produit, au

moment où ils ne génèrent pas encore assez d’intérêt, tandis que ceux basés sur la communauté

sont avantagés une fois le produit mature car il faut bien avouer que l’éditeur a dans beaucoup de

cas un effet néfaste sur le produit, et j’ai peur qu’OpenERP ne fasse pas exception.

L’éditeur coure donc le risque à ce stade d’un fork qui réunisse une bonne part de la communauté

OpenERP et profite plus des avantages de qualité des communautés du logiciel libre qui je le rappelle

profite tout particulièrement à la problématique des ERPs. Si le fork finit par dépasser en termes de

qualité OpenERP, l’éditeur perdra tout.

Je ne m’attends pas à ce que l’éditeur change un jour d’avis, et ce n’est pas moi qui vais essayer

d’initier un fork. Aussi penchons nous sur d’autres problèmes d’OpenERP, qui seront je l’espère déjà

plus consensuel.

Selon moi, l’un des autres gros problèmes d’OpenERP est le manque de spécifications techniques.

Comme vous pouvez le constater, les spécifications techniques ont été d’une grande importance

pour moi au sein de SYNERPGY pour la bonne communication entre le client, le consultant

fonctionnel et le développeur, et c’est pour cela qu’ils tiennent une si grande place au sein de la

méthodologie.

Il n’existe aucune équivalence au sein de la communauté OpenERP. Nulle part ne sont consignées les

spécifications techniques d’OpenERP, comment fonctionne un module, comment est implémenté

telle ou telle action, etc… Ce qui fait que le seul moyen de comprendre tout ce que fait OpenERP est

de manipuler le logiciel encore et encore, même si la documentation fonctionnelle aide.

Pire que tout, la moindre proposition, la moindre idée, doit du coup être expliqué via de longs textes

sur Launchpad ou sur les forums. Lesquels appellent d’autres très longues réponses, etc etc…

Finalement, très peu de personnes vont prendre le temps de tout lire pour savoir si telle idée est

bonne ou non. J’ignore notamment à quel point l’éditeur les prends en considération, mais il est

certain que cette cacophonie n’aide pas la communication entre l’éditeur et la communauté, et que

parfois ce sont juste ceux qui parlent le plus fort qui arrivent à faire passer leurs idées sans forcément

87

https://lists.launchpad.net/openerp-community/msg00045.html

61

Document sous Licence Creative Common By-Sa – Yannick Buron

que ce soit les meilleures. Du coup, on peut assumer que l’éditeur implémente une bonne partie des

fonctionnalités de son coté, sans vraiment demander l’avis des experts métiers dont les débats se

concentrent souvent sur des points de détails sans spécifier exactement comment la fonctionnalité

doit globalement fonctionner.

Ceci est un grave problème, car déjà que l’éditeur a tendance à ne pas intégrer les contributions

comme vu précédemment, mais en plus les idées de la communauté ne lui remontent pas et cela est

vraiment catastrophique. Il est vraiment urgent de mettre en place des spécifications techniques qui

permettrons de faire une proposition en simplement changeant quelques termes dans les

spécifications et disant « Voila mon idée » ou en prenant tout le processus, en faisant de profonds

changements et en demandant « Voilà une manière de travailler que j’espère innovante, qu’en

pensez-vous ». Et tout un chacun pourra donner son avis de manière claire en s’appuyant sur ces

documents pour éviter de transformer la moindre réponse en livre.

Alors bien sûr cela va prendre du temps de rédiger les spécifications de tout ce qui est déjà

implémenté, mais OpenERP est aujourd’hui arrivé à un stade de complexité où ces spécifications

deviennent indispensables. Sans cela, seules les personnes les plus impliqués auront une vision

globale du fonctionnement d’OpenERP et la barrière à l’entrée pour contribuer restera beaucoup

trop haute. On laissera notamment sur le coté les experts métiers qui n’ont aujourd’hui presque

aucun moyen pour faire entendre leur voix, ce qui n’est vraiment pas bon pour la qualité du produit

et la chasse aux malfaçons.

Ceci est d’autant plus dommageable que finalement personne ne sait si OpenERP est en retard par

rapport aux ERPs propriétaires. Il existe des comparatifs entre ERPs propriétaires tel TEC88 qui

dispose d’une grille de comparaison très précise sur l’implémentation ou non de telle ou telle

fonctionnalité. Le fait qu’il n’y ait pas d’équivalent dans les ERPs libres prouvent le fossé qui séparent

ces deux univers et malheureusement aussi le retard d’OpenERP en terme d’organisation89.

Remplir ce genre de comparatif devrait être l’une des priorités afin de savoir très exactement le

travail qui reste à faire et ainsi motiver la communauté, sans ça tout n’est qu’incertitude.

Enfin le dernier gros problème d’OpenERP selon moi… est sa communauté en elle-même. Le logiciel

génère beaucoup d’intérêt, il n’y a qu’à voir le nombre de sujet sur le forum, mais cette communauté

est principalement constituée par l’éditeur et les intégrateurs, les autres personnes étant

généralement rebutées par le peu d’entraide et la complexité pour contribuer.

Même pour un logiciel pour entreprise, une communauté principalement constituée par des

personnes qui gagnent leur vie avec n’est pas sain, ne serait-ce à cause du manque de temps. Sur

cette question on me dit souvent que c’est inévitable et qu’il n’y a pas à s’en faire outre mesure mais

je n’y crois pas. La problématique des ERPs n’a encore une fois rien à voir avec la problématique de

88

Un des seuls sites de comparaisons d’ERP gratuit. Ne laissez néanmoins pas votre vraie adresse email… 89 Je recommande également la lecture des livres méthodologique sur les ERPs propriétaires pour se

faire une idée du retard. Je ne saurais dire s’il s’agit d’une référence, mais j’ai beaucoup apprécié ce

livre aux éditions Eyrolles qui me l’a fait réaliser http://www.eyrolles.com/Informatique/Livre/erp-

9782212127164, et j’en recommande fortement la lecture.

62

Document sous Licence Creative Common By-Sa – Yannick Buron

tout autre logiciel, et il faut une communauté forte, organisée et surtout hétérogène pour y faire

face. Pour l’instant de cette organisation je n’en vois rien, par rapport à ce qui existe par exemple

chez Debian90.

Je pense sincèrement qu’il faut arriver à organiser une toute nouvelle communauté, qui serait basée

sur l’entraide pour les personnes qui commencent à s’y intéresser et les réflexions sur les meilleures

manières d’implémenter les fonctionnalités. Des étudiants en école d’information ou métiers, ainsi

que des associations professionnelles sont des cibles de choix pour constituer cette communauté.

J’ai moi-même essayé de lancer une telle initiative avec le site OpenERP-Universe mais sans force de

frappe suffisante celui-ci restera à l’état de proof of concept91. Le but de ce site était d’être un site de

référence et d’entraide pour les nouveaux arrivants, de débat pour savoir comment implémenter les

fonctionnalités, de savoir à quoi servait tel ou tel module, qui avait intégré OpenERP dans son

entreprise et avec quelles fonctionnalités etc…

Pour l’instant le site ne marche pas je pense car OpenERP ne génère pas encore assez d’intérêt

auprès des personnes qui ne veulent pas en faire leur métier mais juste l’utiliser ou l’améliorer, et ce

faible intérêt est tué dans l’œuf par la complexité actuelle de la communauté et du manque de

spécifications. En plus de réels efforts sur l’organisation de la communauté et de la rédaction des

spécifications, des efforts de promotion d’OpenERP d’abord dans les programmes des écoles92 et si

possible auprès des associations professionnelles qui doivent reconnaitre l’intérêt qu’ils peuvent

avoir à l’émergence d’une concurrence libre sérieuse face à un marché ERP propriétaire de plus en

plus concentré.

Voilà mon point de vue sur la situation actuelle. Ces trois points affectent fortement le

développement d’OpenERP mais si un seul est corrigé je pense qu’il y a moyen pour qu’OpenERP

envahisse le marché dans les prochaines années. Etant donné que je doute fort que l’éditeur revoit

sa position sur sa propriété du cœur du logiciel, il faut se concentrer sur les spécifications et surtout

sur la promotion et l’organisation de la communauté.

90

Distribution Linux renommée pour sa stabilité comme dit plus haut. Ils sont arrivés à ce niveau de qualité grâce à une communauté forte mais surtout très organisée. 91

Un proof of concept, ou preuve de faisabilité, est une sorte de maquette montrant qu’une chose est faisable. Dans le cas d’OpenERP-Universe, il s’agissait surtout pour moi d’organiser les différentes idées que j’avais pour un tel site et les mettre en place. 92

Qui y ont intérêt, OpenERP est un logiciel libre qui peut se révéler très enrichissant pour les étudiants.

63

Document sous Licence Creative Common By-Sa – Yannick Buron

Réflexions sur l’avenir

Concernant SYNERPGY, il faut avouer qu’il y a assez peu de chance d’avenir. Le fait de ne pas être

spécialisé dans un secteur et de manquer de contact a été fortement préjudiciable à la société, et

mes différentes publications n’auront pas été d’un grand secours. Dans le meilleur des cas, un fort

partenariat avec une autre société pourrait surgir avant la fin de mes études, nous verrons bien.

Concernant OpenERP, j’ai listé un certain nombre de problèmes dans la partie précédente qui

menacent sérieusement le produit. Mais ce qui est certain, c’est qu’il va continuer à rester l’ERP libre

de référence tout simplement car il a bien trop d’avance sur ses concurrents ne serait-ce qu’en terme

de notoriété. Toute la question c’est est-ce qu’il va seulement rester le meilleur ERP libre ou est-ce

qu’il va commencer à devenir un des meilleurs ERP du marché, consacrant par là même la place du

logiciel libre dans le secteur des logiciels de gestion, là est la question.

J’avoue ne pas trop savoir… Est-ce que la stratégie de l’éditeur, à savoir tout développer lui-même

malgré un faible budget R&D sera suffisant pour arriver à bâtir seul un ERP suffisamment mature ?

Ou est-ce qu’il faudra impérativement régler un des trois gros problèmes d’OpenERP pour y arriver ?

Personnellement je ne pense pas qu’ils y arriveront seul, ou sinon ce sera dans bien trop d’années.

En attendant les intégrateurs vont continuer à faire des intégrations sans plan comptable à jour, avec

des processus remis en question en permanence par les clients, et avec des termes non-traduits ici et

là.

De plus en plus d’intégrateurs vont continuer à se lancer sur le marché, ce qui est une bonne chose.

Je critique principalement le faible nombre de contributeurs non-professionnel, mais cela ne veut pas

forcément dire qu’un grand nombre de professionnel est mauvais. A ceux qui veulent se lancer,

j’espère que ce document aura pu vous être utile et surtout je recommande vraiment de se

spécialiser dans un secteur.

La réputation d’OpenERP a surtout besoin d’exemples d’implémentations parfaitement réussies et

packagées. Seul l’éditeur peut faire cela pour tout OpenERP, mais un intégrateur spécialisé peut

apporter beaucoup à la réputation d’OpenERP dans son secteur s’il développe une verticalisation

reconnue.

Concernant la promotion d’OpenERP dans les écoles, il y a de timides initiatives. Par exemple

l’éditeur avait dressé un partenariat en 2007 sur la promotion d’OpenERP dans les écoles93 dont nous

n’avons malheureusement pas de nouvelle aujourd’hui. Certains intégrateurs lancent également des

initiatives94, et moi-même ait lancé sur le campus de Paris un laboratoire OpenERP à SUPINFO que

j’espère pouvoir continuer d’une manière ou d’une autre l’année prochaine.

Espérons que la situation continue à évoluer à ce niveau là car les avantages pour les étudiants sont

nombreux. Certes c’est une matière très exigeante mais ô combien intéressante, très instructive car

l’on apprend beaucoup au contact de l’ERP et ce n’est pas les sujets de travaux qui manquent, entre

93

http://www.reseaucerta.org/partenaires/partenariatTiny.htm 94

http://sisalp.fr/index.php/tag/Enseignement

64

Document sous Licence Creative Common By-Sa – Yannick Buron

décrire et faire des suggestions d’améliorations sur une fonctionnalité, ou dresser des comparatifs

avec d’autres ERPs propriétaires.

A titre personnel, je ne sais pas encore ce que je ferais après mes études si l’aventure SYNERPGY se

terminait. Ce qui est certain c’est que je suis un grand fan du logiciel libre et après m’être autant

impliqué sur OpenERP j’aimerais vraiment travailler ensuite à un endroit où je pourrais continuer à le

promouvoir et l’améliorer.

65

Document sous Licence Creative Common By-Sa – Yannick Buron

Conclusion

J’ai voulu à travers ce document partager mon expérience de la création d’entreprise sur OpenERP,

et j’espère que celle-ci pourra être utile à d’autres personnes voire faire évoluer la manière dont on

intègre OpenERP aujourd’hui. Il s’agissait d’un travail très important pour moi car il m’a également

permis de faire le bilan sur ces deux années d’entrepreneur et de maintenant pouvoir peut-être

passer à autre chose.

J’ai également pu donner ma vision des choses sur la manière dont OpenERP évolue actuellement,

avec un regard il est vrai très critique. Je reste persuadé de l’important potentiel d’OpenERP, mais

qu’il reste encore à transformer sans que l’on en emprunte aujourd’hui le chemin. Organiser la

communauté, faire en sorte que les experts métiers comprennent l’intérêt et l’opportunité pour eux

d’OpenERP, et enfin transformer OpenERP en le logiciel de gestion incontournable partout dans le

monde, tout cela reste encore à faire.

Nous verrons si ces objectifs finiront par être atteint, mais en attendant ce qui est certain c’est qu’il y

a des opportunités pour tout un chacun de prendre une part active à l’avenir d’OpenERP et que

beaucoup reste encore à faire et à imaginer.

Après mûres réflexions, je pense également que les problèmes exposés précédemment viennent en

fait d’une problématique plus générale. En effet après tout, existe-t-il quelque part des documents

fait par des DRH sur comment implémenter la paye ? Existe-t-il des forums quelque part où des

comptables débattent de la meilleure manière d’implémenter la gestion de la comptabilité ? Après

plusieurs recherches sur l’Internet, force m’est de constater qu’aucun organisme ne s’est encore

chargé de rédiger ces fameuses spécifications, qui ne sont ni plus ni moins que le meilleur moyen de

communication entre les informaticiens et les utilisateurs métiers, communication qui est encore

aujourd’hui l’une des principales problématiques des projets informatiques tant les préoccupations

des informaticiens et des experts métiers sont différentes.

Aussi finalement, c’est peut-être sur cette problématique générale qu’il faut d’abord concentrer les

efforts. Créer une large communauté non pas sur une problématique du logiciel libre mais beaucoup

plus générale, ouverte à tout expert de son métier, qui débattrait sur la meilleure manière

d’implémenter les processus métiers, et d’en rédiger les spécifications pour que les logiciels d’ERPs

puissent s’y comparer pour en déterminer leurs qualités.

Ce projet de communauté, en plus d’intéresser toute personne travaillant avec un logiciel de gestion

dans son entreprise, permettra aux décisionnaires de comparer plus facilement les logiciels de

gestion, et la qualité de l’ensemble des ERPs s’améliorera. Ceci profitera certainement aux ERPs

propriétaires, et peut-être ceux-ci aiderait même à créer cette communauté, mais je pense que ce

sont les ERPs libres et notamment OpenERP qui en profiteront le plus car je ne doute pas une

seconde qu’une fois qu’une communauté généraliste se sera suffisamment organisée pour produire

quelque chose d’aussi complexe que des spécifications pour implémenter les processus métiers, une

large part de celle-ci voudra voir ce travail concrétisé dans un logiciel libre et OpenERP sera le

meilleur candidat à ce moment là. Il n’aura plus alors qu’à suivre les spécifications, implémenter les

fonctionnalités plébiscitées par les utilisateurs eux-mêmes et sa notoriété deviendra alors telle que

plus aucun logiciel propriétaire ne fera le poids face à lui.