Acheter ou Développer ?

Acheter ou Développer ?
Pour la création de nouveaux sites, aussi bien que pour la refonte ou l’enrichissement de sites existants, le marché est en train de basculer vers l’achat d’application plutôt que le développement spécifique.
Le marché des sites d'e-commerce se transforme. En effet, pour la création de nouveaux sites, aussi bien que pour la refonte ou l’enrichissement de sites existants, le marché est en train de basculer vers l’achat d’application plutôt que le développement spécifique. Cette tendance est inéluctable : dans l’histoire du logiciel, le "buy" finit toujours par l’emporter sur le "build".
Dans les années 70, de nombreuses sociétés affrétaient des armées de développeurs Cobol afin de construire leur système de gestion de la paie : 10 ans plus tard, l’essor inéluctable des ERP rendait cette pratique obsolète. On retrouve un cycle similaire dans tous les logiciels d’entreprise: ERP, gestion commerciale, CRM, gestion de la facturation, gestion de production, logistique, procurement… Il est clair que la décision d’acheter ou de développer est importante et complexe.

Acheter
Les trois principales raisons pour lesquelles les applications du marché l'emportent inévitablement face au développement spécifique sont :
1. un coût initial inférieur,
2. un niveau d'innovation supérieur,
3. un délai de déploiement réduit.

Réduire le délai de déploiement
Toutes les applications du marché ne sont pas égales sur ce point. C'est pourquoi il convient de s'assurer que l'application choisie a déjà été déployée dans la majorité des projets en un laps de temps court, trois mois tout au plus. Le déploiement rapide dépendra en particulier de facteurs tels que :
- La livraison d'objets prêts à l'emploi beaucoup plus rapides à mettre en œuvre que les traditionnelles API XML,
- La disponibilité de l'application en mode SaaS, qui élimine l'installation technique et réduit d'autant le temps de mise en œuvre,
- L'utilisation de standards récents d'interopérabilité.
On peut penser que plus le besoin est générique, plus il sera facile de trouver une application du marché qui y répond. Cette règle est toutefois soumise à de sérieuses limitations :- D'une part, il faut savoir apprécier le degré objectif de spécificité de l'activité : chaque entreprise a une tendance naturelle à considérer abusivement que la nature de son e-business est exclusive.
- D'autre part, les applications les plus récentes offrent une grande faculté de personnalisation : elles allient fonctionnalités industrialisées et fortes capacités d'adaptation par simple paramétrage.
- Enfin, le choix d'une application du marché reste généralement attractif même si la totalité des besoins n'est pas couvert. Il faut que sa richesse fonctionnelle couvre la majorité des besoins et que le logiciel puisse facilement s'adapter aux besoins métier, plutôt que d'être contraint de modifier les processus métier pour les adapter au logiciel.

Évaluer les coûts cachés
Dans la majorité des cas, il est probable qu'une solution du marché soit la solution la plus rapide et la moins coûteuse, à condition toutefois de ne pas tomber dans le piège classique des coûts cachés et à bien évaluer l'ensemble des postes de coût avant de vous lancer. Si l'application requiert de nombreuses customisations, il est nécessaire d'avoir correctement évalué le coût, les délais et le risque du développement spécifique.
L'un des mythes les plus répandus concerne la multiplication des solutions de niche en complément d'un développement spécifique maison. En effet, beaucoup d'e-marchands pensent encore pouvoir se doter de la meilleure application en juxtaposant les meilleures applications du marché à mesure que leurs besoins apparaissent : social shopping cette année, personnalisation l'année prochaine, puis gestion des bundles dynamiques l'année d'après, etc.
Or, le nombre de solutions accroît de façon exponentielle le risque de volatilité lié au nombre et à la fréquence des nouvelles versions. Lorsque l'E-Marchand doit "coudre" ensemble son application maison avec une multitude de fonctions de niche externalisées, le coût de la "couture" devient rapidement prohibitif. Si le nombre des applications augmente considérablement, les ennuis peuvent commencer.

Les solutions intégrées
L'approche "tout-intégré", quant à elle, ne fonctionne pas non plus : trop générique, elle tente d'assembler des fonctionnalités qui ne peuvent être optimisées avec une même architecture. C'est le cas notamment des applications de recherche sémantique contraintes de se doter de fonctionnalités de gestion de catalogue : les deux fonctions font appel à des architectures très différentes pour être performantes. Or, la gestion de catalogue est fondamentale car elle est la base d'un e-commerce performant : c'est elle qu'il conviendra donc de privilégier, car elle pilotera la recherche sémantique, devenue une commodité et dont il existe de très nombreuses applications.

Développer en Interne
Lorsque l'on développe son propre applicatif, une étude de 2003 de K Sharp Technology Inc. montre qu'il existe une corrélation inverse entre la taille du projet et la probabilité qu'il voit le jour. Ainsi, la probabilité de succès d'un projet de 500 000 euros est de 55%, celle d'un projet compris entre 550 000 euros et 1millions d'euros tombe à 33%.
Décider de développer en interne est le premier réflexe d'une entreprise qui dispose d'une équipe de développement. Mais la plupart des arguments pour le développement spécifique ne sont mis en avant que pour justifier le désir naturel des équipes de développeurs de faire soi-même. Or, la décision de développer en interne peut se révéler terriblement coûteuse si l'analyse est erronée.

Technique / métier : des difficultés de compréhension
Les équipes métiers et techniques ne se comprennent pas tout simplement parce qu'elles ne parlent pas le même langage. Le management est très efficace dans une approche à haut niveau, alors que les développeurs doivent travailler au niveau de détail le plus granulaire. Ce qui, aux yeux du management, apparaît comme une requête additionnelle insignifiante peut en fait se traduire par deux mois de programmation additionnels.
Cette incompréhension est mutuelle. Certains développeurs ne comprennent pas les besoins du métier. Ce qui leur paraît simple et évident peut se révéler inutilisable dans l'exercice du métier. C'est pourquoi l'analyse précise des délivrables et du design métier est indispensable. Même avec un cahier des charges précisément élaboré dès le démarrage du projet, l'e-marketing doit être fortement impliqué dans toutes les phases du cycle de développement.

Des ressources importantes à mobiliser
Au démarrage d'un projet, il est utile de désigner dès le début les responsables projet parmi les utilisateurs métier et de s'assurer qu'ils disposent du temps nécessaire pour s'immerger dans le projet pendant plusieurs mois. Pour un projet d'envergure, il n'est pas envisageable de ne pas impliquer le directeur de l'équipe de développement dès le début du projet, en tant qu'ultime responsable technique.
Quant au responsable du projet côté métier, il sera préférable d'essayer de trouver un e-marketeur ayant déjà une expérience de la programmation, une pratique intense des tableurs et des macros... Trouver ce type de responsable projet dans l'équipe métier accroit les chances de réussite

Les coûts cachés du développement spécifique
Très souvent, les projets de développement interne démarrent sans aucune analyse financière préalable, ce qui est une grave erreur.
Beaucoup d'entreprises considèrent que leurs développeurs sont déjà payés et que leurs coûts sont déjà absorbés. Cette hypothèse est erronée puisqu'elle reviendrait à considérer que les équipes de développement sont payées à ne rien faire jusqu'à ce que le projet se présente. De même, il est important de ne pas sous-estimer la charge de maintenance et de support. L'impact de ces coûts cachés est considérable pour déterminer la viabilité d'un développement interne avant de commencer, puisqu'ils représentent généralement plus de 50% du coût total de possession (TCO) de l'application (source IC Harris - Economic Model for Software Reuse - 2002).

Les risques à anticiper
On peut lister quelques-uns des nombreux pièges dans lesquels beaucoup d'entreprises tombent lorsqu'elles décident de se lancer dans un développement spécifique :,
- Des délais irréalistes imposés par le management,
- Une définition trop vague des délivrables du projet,
- Trop peu de temps alloué aux phases de design,
- Peu ou pas de temps alloué aux tests (Alpha et Beta testing),
- Des problèmes de politique interne qui perturbent le bon déroulement du projet,
- Une technique pas assez rigoureuse pour l'estimation des coûts et délais,
- Pas de processus d'assurance qualité,
- Le calcul incorrect ou inexistant des coûts de développement réels,
- La faiblesse de la gestion de projet métier et technique,
- L'insuffisance des ressources allouées au support et à la maintenance,
- Des capacités de design et d'innovation qui ne sont plus à jour,
- L'absence partielle ou totale de documentation,
- La dérive du périmètre du projet et la dérive des coûts et des délais associés,
- La sous-estimation du problème de tâches multiples confiées aux équipes de développement, qui doivent assurer le quotidien en plus du développement d'un nouvel applicatif.

Une organisation qui développe régulièrement et avec succès des applications logicielles aura réglé tous ces problèmes. En revanche, les statistiques sur la probabilité de succès d'un projet citées plus haut ne doivent pas être ignorées : si vous souhaitez développer en interne mais que vos équipes n'ont pas encore établi un track-record crédible d'expériences multiples et réussie de développement d'applications dans le domaine du e-commerce, si votre entreprise ne développe pas régulièrement des applications robustes qui fonctionnent et sont utilisées avec succès par les équipes métier, alors il vaut mieux renoncer et chercher de l'aide à l'extérieur.

Développer en Outsourcing
Si les besoins sont à ce point spécifiques qu'aucune application de marché n'est disponible pour régler la problématique et si le développement d'application n'est pas une dans les compétences-clés interne à l'entreprise, alors choisir de faire développer par un prestataire tiers peut être une option à considérer. Évidemment, il est nécessaire de transférer au prestataire la connaissance des processus métier. Ce transfert de connaissance engendre des coûts et des délais importants qui ne doivent pas être sous-estimés.

Choisir son prestataire
Le développement d'applications étant normalement la compétence clef du prestataire extérieur, il doit disposer d'un système efficace en termes d'organisation et de processus pour le recueil des besoins, le design, le développement, la documentation, les tests, ainsi que la gestion de projet.
Beaucoup plus difficile à tester si l'entreprise ne dispose pas d'équipes techniques internes est la qualité du code développé. En effet, pour un besoin donné ; il existe plusieurs façons de développer les fonctionnalités souhaitées : le prestataire devra faire preuve d'efficacité et de rigueur, voire d'imagination.

Les choix techniques
Pour pallier à un manque d'expérience ou accélérer le projet, certains prestataires font appel à un noyau applicatif déjà disponible sur le marché, souvent choisis parmi les applicatifs Open Source. L'expérience montre que quelques problèmes classiques découlent invariablement de ce genre de choix :- Le prestataire doit se livrer à une analyse rigoureuse du besoin avant de proposer une souche applicative comme base de son développement spécifique,
- Le prestataire tente souvent de placer l'applicatif Open Source qu'il connaît, même si le besoin ne correspond pas vraiment, et sous-estime l'effort nécessaire pour satisfaire au besoin réel,
- En matière d'e-commerce, les solutions Open Source ne sont pas synonymes de gratuité : si le prestataire peut disposer de licences gratuites, le travail nécessaire pour les déployer, les enrichir fonctionnellement et tenter d'améliorer leurs performances, se révèle souvent plus coûteux qu'un développement à partir de zéro.

Les modes de tarification
Dans le choix du prestataire, la structure de prix qu'il propose est importante. Il est clair qu'une tarification au temps passé ne devra pas être retenue. Pour éviter les risques de prix, un tarif forfaitaire est conseillé. En contrepartie, le prestataire demandera d'établir un cahier des charges précis. La seule possibilité d'accroissement du prix sera alors une modification des besoins par rapport au cahier des charges initial.
Ce point n'est pas à négliger : l'écriture d'un cahier des charges précis est un processus nécessaire, mais long et coûteux. Il doit impliquer les principaux membres de l'équipe métier et être dirigé, chez le prestataire, par un expert à la fois métier et technique. Ce type de profil est rare. De lui dépendra toutefois le succès du projet.

Le risque de dépendance
Les nombreux risques associés à la solution d'outsourcer la rendent rarement supérieure à celle d'un achat de logiciel du marché :
- L'entreprise se place en situation de forte dépendance vis-à-vis du prestataire concernant les versions ultérieures,
- Le prestataire doit être suffisamment flexible pour effectuer des changements en cours de développement,
- Le prestataire va-t-il tenir ses promesses ?
- Une formation de qualité est-elle fournie par le prestataire ?
- La stabilité financière du prestataire est-elle solide ?
- Le niveau d'expertise métier du prestataire est-il suffisant pour comprendre les besoins et les traduire en termes fonctionnels et techniques ?
- La communication du prestataire avec l'équipe métier est-elle de qualité suffisante ?
- Les applications précédentes développées par le prestataire sont-elles intuitives, faciles d'utilisation, mises en œuvre dans les délais et les budgets ?
Dans les années 90, au moment ou l'e-commerce démarrait à peine, cette option s'est révélée particulièrement populaire sous la conjonction de trois facteurs :
- Peu d'applications du marché étaient disponibles, ce qui ne laissait pratiquement pas d'autre alternative que de développer soi-même
- Le niveau peu élevé de fonctionnalité requis au début de l'ère du E-Commerce rendait cette option viable économiquement
- Beaucoup de web-agencies et SSII se sont engouffrées dans cette opportunité de marché, conseillant leurs clients dans ce sens.

Conclusion
En matière de logiciel pour la refonte, l'enrichissement de site existant, aussi bien que pour le démarrage de sites nouveaux, il est toujours difficile de prendre la bonne décision.
Dans tous les cas, il est important de réaliser une étude exhaustive et documentée afin d'étayer sa recommandation, dans la mesure où le jeu de la politique interne joue souvent un rôle dans la décision finale.
Les entreprises disposant d'une équipe de développement interne adopteront le plus souvent le réflexe premier de développer elles-mêmes, mais ce choix présente en général beaucoup plus d'inconvénients que d'avantages. L'externalisation du développement spécifique s'est révélé le choix le plus populaire des 10 dernières années, par manque d'alternative d'une part, mais également par la relative visibilité de ses coûts.
Aujourd'hui, une mutation de plus en plus nette se dessine en faveur des applications de marché, plus complètes, plus performantes, plus rapides à mettre en oeuvre et au final plus économiques.

Pascal PODVIN