Vous êtes ici

Le choix de l'Open source ?

Dans certains dossiers commerciaux que nous traitons, nous sommes en compétition avec de grands noms des logiciels propriétaires (SAP, Microsoft Dynamics, Oracle Applications, Sage,...) Vu l'offre nettement plus compétitive que nous offrons, la stratégie de leurs équipes de vente s'axe systématiquement sur la décrédibilisation de l'Open Source en général, et d'OpenERP en particulier. Ce type de discours peut prendre, en particulier auprès de clients non initiés au concept de l'Open Source. Chez ADN nous pensons que l'Open Source garantit une forte indépendance et une vraie pérennité, une bien meilleure couverture fonctionnelle grâce aux capacités d'adaptation garanties par une licence Open Source et au final une solution globale moins chère et plus satisfaisante.
> Les éditeurs propriétaires caricaturent l'Open Source comme quelque chose de complexe réservé à des geeks de l'informatique.
 
L'open Source recouvre une communauté de contributeurs (utilisateurs-clients, intégrateurs, éditeurs) adhérant à des principes d'utilisation de logiciels dit "libres". 
 
Pour faire court, le concept du logiciel libre, qui a été défini juridiquement (i.e. Licences GNU/GPL/AGPL), est que chacun des acteurs a le droit d'utiliser l'application/code OpenSource et de le modifier, à condition d'assumer le devoir de redistribuer le code modifié (via notamment des sites internet de "projets" communautaires tels que Launchpad ou SourceForge)
Ce concept explique pourquoi les suites Linux, Open Office et pléthore d'autres logiciels Open Source soient gratuitement disponibles sur internet.
 
Dans le cadre d'OpenERP qui est sous licence AGPL, cela explique pourquoi il est librement téléchargeable, et pourquoi la garantie de maintenance de l'éditeur OpenERP S.A. reste optionnelle et non obligatoire.
> Les éditeurs propriétaires présentent les logiciels Open Source comme des produits non pérennes et instables
 
Nous pourrions en dire autant de certains logiciels propriétaires: en toute logique les applications de piètre qualité entraînent la faillite de l'éditeur.
Il en va de même de pour un logiciel Open Source: si ses fonctionnalités sont déficientes ou ses technologies surannées, il ne parvient pas à fédérer une communauté de contributeurs et le logiciel finit par disparaître.
 
OpenERP a une communauté bien vivace ( un éditeur employant 200 personnes, 350 Implementation Partners à travers le monde et des milliers de sociétés utilisatrices, et plus de 2000 contributeurs actifs sur le site communautaire Launchpad.
OpenERP, toujours sous la guidance de son concepteur originel Fabien Pinckaers, évolue constamment et se maintient à jour d'un point de vue technique et fonctionnel à la satisfaction de l'ensemble des acteurs de sa communauté.
 
De plus, dans le monde des logiciels propriétaires, des applications de qualité ont néanmoins disparus ou peu évolué suite à des rachats, avec par exemple:
- PeopleSoft racheté par Oracle 
- Navision, Axapta, Great Plains, tous  rachetés par Microsoft
Dans ces deux cas, il s'agissait avant tout pour un acheteur avec une grosse trésorerie de s'emparer de parts de marché des concurrents achetés. Dans la pratique les clients n'ont plus vu évoluer leurs anciennes applications et devaient migrer vers le nouveau produit utilisant d'autres technologies, parfois moins riche en fonctionnalités.
 
Dans le cas d'OpenERP, l'éditeur OpenERP S.A. est une proie peu intéressante dans la mesure où cet éditeur ne possède pas la propriété intellectuelle sur le code (licence AGPL) mais n'est seulement que le coordinateur de la communauté. Donc même en cas de rachat par un prédateur issu du monde propriétaire, le logiciel OpenERP continuera à vivre car un ou plusieurs acteurs communautaires reprendront le rôle de coordinateur d'OpenERP S.A.
> Les éditeurs propriétaires présentent les logiciels Open Source comme des bouts de code que n'importe qui peut modifier, ce qui créerait un système indétricotable et non fiable.
 
Oui, pour certains projets/logiciels OpenSource, il est vrai que n'importe qui peut soumettre ses modifications de codes, au péril même de la stabilité de l'application.
 
Il faut néanmoins tempérer ce jugement beaucoup trop généraliste:
- Toutes les applications Open Source destinées aux entreprises sont régies par des règles de mise à jour incluant une revue collective par des développeurs reconnus par la communauté.
- De plus Sudokeys, en tant qu'intégrateur, ne sélectionne que des solutions OpenSource répondant au plus hauts standards de stabilité.
 
Dans le cadre d'OpenERP, les règles de mise à jour sont parmi les plus contrôlées:
- Les modules communautaires sont régis par le contributeur originel qui autorise, ou pas, la modification après revue.
- Les 200 modules de la suite Enterprise gérées par OpenERP S.A. ne peuvent être modifiés que par moins de 10 personnes, toutes salariées d'OpenERP S.A.; de plus toutes les modifications font l'objet de testing d'intégration.
> Les éditeurs propriétaires annoncent que les logiciels Open Source réservent beaucoup de surprises sous forme de coûts d'exploitation additionnels.
 
En effet, un critère important pour un responsable d'entreprise ou un directeur informatique est quelquefois davantage le coût prévisionnel de son application plutôt qu'un coût bas "catalogue " accompagné d'imprévus.
Dans ce cadre, les logiciels propriétaires mettent en avant le fait que leurs logiciels ont un tarif fixe de maintenance par utilisateur couvrant les coûts d'exploitation. Mais cela sans mentionner les coûts cachés inhérents aux migrations de version.
 
Avec OpenERP il y a en toute honnêteté aucun coût caché par rapport à un logiciel propriétaire: si vous souscrivez à la garantie éditeur d'OpenERP S.A. (équivalente à la maintenance annuelle des éditeurs propriétaires mais nettement moins chère)
  • Vous avez au minimum les mêmes services (bug fixing, alertes de sécurité, patches correctifs)
  • Vous n'avez aucun frais additionnel de migration technique des modules Enterprise puisque ceux-ci sont assurés par l'éditeur dans le cadre du contrat de garantie
  • Concernant les frais de migration de code non standard:
    • Soit il s'agit de customisations légères réalisées dans les règles de l'art par un intégrateur expérimenté tel que Sudokeys, auquel cas elles sont reprises d'office dans la migration éditeur
    • Soit il s'agit de customisations importantes, basées sur des modules communautaires ou des développements spécifiques. Dans ces deux derniers cas le coût de migration peut être prévisible:
  • l'éditeur OpenERP S.A. migre ces fonctionnalités au tarif forfaitaire de 800€ par 1000 lignes de code (dans le cadre d'un module communautaire, il est possible que la communauté elle-même ait déjà migré le code vers la version supérieure)
  • Sudokeys a conçu le module et vous fournit un devis pour le coût de migration pouvant être plus intéressant que le prix éditeur qui constitue de toute façon un plafond.
> Les éditeurs propriétaires prétendent que les logiciels libres, et OpenERP en particulier, nécessitent de revoir de fond en comble l'infrastructure informatique de la société
 
Ceci est absolument faux.
De par notre expérience des grands logiciels propriétaires, nous pouvons vous affirmer que les gros ERP requièrent une infrastructure supplémentaire extrêmement lourde (SAP peut requérir une batterie de serveurs: DEV-TEST-PRD pour l'applicatif R/3 avec une triple réplication similaire pour le middleware Netweaver, le serveur BI et le serveur internet,...)
En fait, nous pourrions vous dire que le fait de passer en Open Source pour l'ensemble de l'infrastructure serait économiquement plus intéressant:  
1) cela générerait de grosses économies de licences car tous ces produits Open Source sont essentiellement gratuits: adoption de Linux/Ubuntu comme système d'exploitation, de Thunderbird en remplacement d'Outlook, d'OpenOffice comme suite bureautique en lieu et place de Microsoft Office, de Drupal en remplacement de Sharepoint...
2) Vous seriez bien plus à l'abri des virus et autres chevaux de Troie infestant le net.
 
Dans la pratique, ceci implique une démarche Open Source "totale" qui doit s'appréhender avec le temps et progressivement.
C'est bien pourquoi OpenERP est conçu pour s'intégrer parfaitement avec des environnements Microsoft ou Apple pré-existants:
  • Intégration du client lourd sur Windows ou OS-X
  • Intégration du client léger avec un navigateur web classique
  • Intégration Excel
  • Plug-in Outlook/Mozilla Thunderbird pour la gestion des e-mails
 
La seule contrainte Open Source étant d'exploiter le serveur de production sous environnement Linux/Ubuntu (les serveurs de test/acceptance pouvant opérer directement sous Windows) – Ceci étant du au fait qu'OpenERP étant nativement Linux, les patchs de sécurité doivent préférablement être installés sous Linux 
Dans la pratique ce serveur Linux est peu contraignant:
  • Installation en interne: soit réserver un serveur pour une exploitation en Linux/Ubuntu, ou installer une virtual machine sur un serveur Windows/MAC avec un OS Linux/Ubuntu (gratuit)
  • Installation hébergée dans le cloud: les principaux hébergeurs (OVH, Amazon, Gandi) proposent des serveurs Linux/Ubuntu
  • Installation hébergée par Sudokeys : nous gérons le tout sur base forfaitaire mensuelle, en ce compris la gestion de la sécurité, des mises à jour et des backups.
> Les éditeurs propriétaires prétendent qu'OpenERP et l'OpenSource nécessitent de nombreuses compétences informatiques en interne vu le côté exotique et avant-gardiste des technologies utilisées.
 
  • Justement, c'est tout le contraire, OpenERP est avant tout destiné aux PME, qui par essence ont peu de compétences informatiques internes :
  • Le rôle de Sudokeys en tant qu'intégrateur est de vous délivrer un produit requérant peu de modifications techniques ultérieures
  • 95% d'OpenERP s'appuie essentiellement sur le langage Python pour la définition du code et sur XML pour la définition des écrans (langages Open Source gratuits et largement documentés) 
  • les 5% restants ont trait à des fonctionnalités avancées auxquelles vous aurez rarement recours
  • des outils d'accélération de développement sont disponibles, et moyennant quelques jours de formation, ajouter des champs dans un écran, modifier un workflow, modifier un rapport, ou créer un ensemble de tables interconnectées deviendra un jeu d'enfant.
 
Par contre chez les éditeurs propriétaires cela devient beaucoup plus compliqué :
  • certains sont tellement opaques qu'ils est impossible d'accéder au code source, rendant impossible toute modification par le client.
  • généralement, ils facturent plusieurs milliers d'euros pour l'achat d'un profil utilisateur de développement permettant de réaliser des modifications du code.
  • ils utilisent beaucoup plus de technologies hétérogènes qu'ils ne le prétendent: par exemple un langage de développement pour le client lourd, un autre pour le client web (quand ils en ont un), un autre pour le reporting, voire, encore d'autres langages pour d'autres modules métiers achetés à des tierces parties...
> Les éditeurs propriétaires martèlent que pour le prix proposé par OpenERP, on ne peut avoir un produit sérieux en termes de couverture fonctionnelle et de qualité.
 
Tout d'abord comparons ce qui est comparable. Pour les avoir nous même pratiqués nous pouvons dire que les logiciels grands comptes sont des logiciels de qualité convenant extrêmement bien à des grandes entreprises utilisant des structures complexes à multiples sociétés, actives sur de nombreux pays.
 
OpenERP vise le marché ERP pour la PME entre 5 et 500 utilisateurs. Le tarif proposé et la couverture fonctionnelle d'OpenERP correspond mieux à ce secteur du marché, tout simplement.
Adopter un ERP grand compte dans ce contexte revient à bâtir une usine sur-dimensionnée par rapport au carnet de commandes de l'entreprise et à sa réalité économique.
 
Avec OpenERP vous trouverez toutes les fonctionnalités classiques nécessaires à votre activité.
Et si d'aventure ces fonctionnalités étaient insuffisantes, l'économie réalisée par rapport à l'achat des licences d'un logiciel propriétaire financera le développement spécifique répondant à votre besoin métier (qui déjà existe peut-être sous forme de module communautaire).
 
Pour aller plus loin dans l'explication du coût compétitif d'OpenERP, il faut également comprendre son business model composé de dépenses limitées (marketing web, vente via les SS2i partenaires), et de contributions de la communauté (retour d'expériences clients & suggestions de fonctionnalités, testing & bug fixing, traduction dans plus de 30 langues) qui sont des économies nettes par rapport à un logiciel propriétaire.
C'est ce modèle OpenSource et communautaire qui a permis à OpenERP de proposer un ERP complet en quelques années, là ou un logiciel propriétaire aura investi durant 15 à 20 ans... mais à un coût de développement nettement moindre.

> Les éditeurs propriétaires affirment que les intégrateurs Partners d'OpenERP ne seraient pas "à niveau" , car étant issus du monde du service technique micro-informatique PME, voire même de la TPE ou du service aux particuliers.

Oui, c'est une réalité pour certains des partenaires : les logiciels OpenSource sont accessibles à tous et un éditeur tel qu'OpenERP S.A. qui est en pleine croissance doit actuellement rechercher un maximum de partenaires pour distribuer son produit.

Nous pouvons néanmoins rétorquer que dans le cas de Sudokeys, vous avez face à vous une équipe professionnelle de 18 personnes combinant de nombreux talents complémentaires : des développeurs spécialistes du logiciel libre mais aussi des consultants fonctionnels ayant plus de de 10 années d'expérience en ERP, en comptabilité, logistique, ressources humaines et paie.

Par ailleurs Sudokeys a une expérience aiguisée de la réalité des PME, qui est très différente de celle des grands comptes dans lesquels les partenaires des ERP propriétaires naviguent :

  • Une culture du résultat immédiat bien plus importante, dans la mesure où souvent le dirigeant est lui-même le propriétaire de l'entreprise.
  • Les équipes de consultants impliquées dans le projet sont nettement moins importantes que dans les grands comptes. Sur nos projets de petites tailles, nos propres équipes sont composées d'un consultant fonctionnel/chef de projet accompagné d'un développeur, pouvant faire appel à un référent Sudokeys (product owner) pour des problématiques pointues.

Par comparaison, un logiciel propriétaire grand compte travaille avec des partenaires employant des consultants spécialisés par domaine fonctionnel vu la complexité de leurs logiciels. Dans la pratique cela engendre des équipes pléthoriques entraînant d'importants coûts supplémentaires de coordination et de planning.