View
752
Download
3
Category
Preview:
Citation preview
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.
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.
Recommended