Memoire Yannick Buron - SUPINFO 2011

La création d’une entreprise d’intégration OpenERP Mémoire de fin d’étude

Yannick Buron 07/09/2011

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

2 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 moimê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.


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.


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 celleci 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…


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.


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…


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.


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.




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.


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


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 Selon la définition de la Free Software Foundation, à l’origine des licences libres. http://www.gnu.org/licenses/agpl.html . 17


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


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.


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


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






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.

Avant les ERPs libres

Aujourd'hui

Une fois les communautés suffisantes et organisées

ERPs Propriétaires

ERPs Propriétaires

ERPs Propriétaires

+Couverture fonctionnelle

Néant

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

ERPs libres +Flexibilité +Maitrise sur le produit +Qualité de la base technologique et du code +Coûts +Perrenité

ERPs libres +Couverture fonctionnelle +Flexibilité +Maitrise sur le produit +Qualité de la base technologique et du code +Coûts +Perrenité

Développements spécifiques +Flexibilité +Maitrise sur le produit

Développements spécifiques

Développements spécifiques

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

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

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.


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 Figure 7 Logo OpenObject 26

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

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.


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

Figure 8 Logo Tryton

Page 69 du livre blanc.


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


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.


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


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.


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.

Autoentrepreneur

Entreprise Individuelle

•+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

•+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

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 Toutes les taxes calculées directement sur le chiffre d’affaire à 23,5%. 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. Impôt sur le revenu, calculé sur le chiffre d’affaire avec un barème similaire à celui des salariés. Impôt sur les sociétés, calculé à 30% des bénéfices de la société. Cotisation foncière des entreprises, environ 500€/an suivant où est située l’entreprise. CVAE, à valeur non-nulle à partir de 500 000€ de chiffre d’affaire. De 0,5% à 1,5% du chiffre d’affaire. Facturation de la TVA, et TVA déductible sur les factures fournisseurs.

EI

EURL

SARL

SAS et SA

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

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


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.


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.


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.


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

Migration

• Comprendre le besoin • Rédiger cahier des charges • En Régie

Hébergement Infogérence • Sauvegardes • Supervision • Forfait mensuel

Intégration • Créer la base de production • Configuration • Importation des données • Développements • Au forfait

Support • A la demande du du client • Régie

Maintenance

Formation

• Responsabilité du prestataire • Forfait mensuel

• Peut être assurée par le chef de projet client • En interne ou externe

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.


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


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 .


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.

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

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.


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.


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.


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

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


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.


Méthodologie complète avec phase d'étude

Méthodologie simplifiée avec acceptation de l'existant

Niveau d'exigeance du client important

Faible niveau d'exigeance

Budget important

Faible budget

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.


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.


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.

Profil fonctionnel

Profil développeur

N'est pas obligatoirement informaticien de formation

Informaticien de formation

Recueille les besoins et les modélisent. Configure les bases OpenERP de production

Développe les modules, les synchronisation, assure la maintenance des serveurs

Est le contact du client, dispose de bonnes qualités relationnelles et de fortes compétences métiers

Dispose de fortes compétences en Python et en administration système Linux

Comprend comment OpenERP fonctionne et est capable de lire le code

Comprend l'utilité de ce qu'on lui demande de développer et est force de proposition

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


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.


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









66

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

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…




 

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.


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.


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


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.



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


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.


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.

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

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.


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.


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

•Installation du serveur OpenERP •Création de la base de production •Configuration de la base de production Partie forfaitaire du •Modification des rapports et importation des données projet

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

Figure 21 Méthodologie simplifiée d'intégration OpenERP


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


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


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


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


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



77

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

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.








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


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.


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.


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


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/erp9782212127164, et j’en recommande fortement la lecture.


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.


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


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.


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.


Memoire Yannick Buron - SUPINFO 2011

Recommend Documents