[Tribune] Make or buy? That is the question

L'état de l'art, les standards du marché ou la force du support éditeur sont autant d'atouts en faveur de solutions prêtes à l'emploi pour de nouveaux projets digitaux, même si les tenants du développement spécifique ont la vie dure. Alors, "make or buy"?

On voit bien que la tendance s'inverse: les DSI se tournent de moins en moins vers des solutions 100% développées en interne pour leurs projets digitaux (e-commerce, CRM...), au profit de plateformes techniques prépackagées. Certes, la souplesse et la liberté de travailler en interne sans avoir à souscrire des licences ont leurs afficionados... Mais l'offre prépackagée s'est multipliée et arrive à maturité.

Aujourd'hui, l'emploi de progiciels du marché n'a que des avantages: être en permanence à état de l'art, employer des standards du marché robustes et bien testés, et avoir un support éditeur utile et rassurant... C'est nettement plus évolutif qu'une solution maison 100% réalisée avec des équipes internes... Et en termes d'investissements humain et financier, l'impact n'est pas neutre...

Arbitrer avant même le cahier des charges

J'ai remarqué que, de plus en plus et de plus en plus tôt dans les process, les projets digitaux et notamment dans l'e-commerce sont confrontés à la nécessité d'arbitrer entre générique et spécifique, parfois même avant la rédaction d'un cahier des charges. C'est le fameux dilemme du "make or buy".

Les marques, et c'est légitime, souhaitent proclamer leur différence et leurs spécificités. Y compris en ligne... Elles veulent un site web et des fonctionnalités qui reflètent leur ADN (leurs USP, unique selling proposition) ou le caractère particulièrement attractif de leur offre. Une aspiration qui plaide a priori pour une approche "taylor made", aucun socle et aucune plateforme digitale n'étant à même de répondre à tous les besoins spécifiques d'un projet donné. Mais faire le choix du "tout spécifique" ou du "trop spécifique", c'est inévitablement s'exposer à des délais plus longs et à des coûts directs et indirects plus élevés, pour un résultat difficile à garantir.

Or, la plupart des fonctionnalités réellement utiles sur ce type de plateformes existent dans au moins une solution packagée, sous une forme "plug and play" ou une forme "customisable". Je conseille donc d'étudier de près les fonctionnalités génériques proposées par les plateformes digitales et de les confronter aux besoins recensés pour effectuer les bons arbitrages. Une approche de type "gap analysis" permettra de mettre en regard les besoins fonctionnels et les réponses d'une plateforme générique, à la fois sur les grandes fonctions de la plateforme et sur des portfolios de fonctions produit. Ici, j'insiste sur la nécessité de challenger les métiers sur les ROI business des fonctionnalités métiers non-standard... Cest d'ailleurs un particulaité de l'approche française par rapport à l'anglo-saxonne.

Et vous verrez: la plupart du temps, il est préférable de choisir le générique, quitte à ne répondre qu'à 80% du besoin. Car il est bien rare que le spécifique s'impose par l'impératif d'y répondre à 100%... Combien d'entreprises se sont rendu compte, au bout d'un ou deux ans d'exploitation, que seulement 50% des fonctionnalités spécifiques développées pour leur site étaient effectivement utilisées! Pour un catalogue décliné par par pays, pour des promotions à différencier ou pour le merchandizing, je conseille de faire du buy mais avec une part de customisation si cela s'avère nécessaire.

Quel impact sur l'architecture et les solutions applicatives

Plus tôt vous déterminerez où placer le curseur entre généricité et spécialisation, plus il vous sera facile de mettre en place une architecture évolutive permettant de répondre aux besoins actuels et à venir. L'autre question concerne les solutions applicatives. Là aussi, les possibilités sont multiples. On peut utiliser un socle soit pour un seul pays et une seule langue, soit pour plusieurs pays et plusieurs langues. Des choix qui appellent de nouveaux arbitrages. Par exemple, si je développe une fonctionnalité pour un pays, est-ce que je la développe pour ce seul pays ou de manière à pouvoir la mettre à disposition des autres pays? En d'autres termes, est-ce que je rends mon développement spécifique "généricable" (pardon pour le barbarisme), ce qui laisse à chaque pays la possibilité de l'utiliser ou non?

Enfin, concernant les coûts, ne pas oublier que l'option Buy est vraiment plus économe notamment en matière de maintenance et d'évolutivité (on profite du standard).

Surtout, ne pas se tromper d'équipe projet

Il est pertinent et légitime que ces projets soient pilotés par le marketing car l'une des missions de la DSI reste bien de répondre aux nécessités du time to market et d'être réactif par rapport aux besoins des métiers. Mais il faut s'entourer de spécialistes techniques expérimentés dans ce type de projets et ayant la connaissance des différentes plateformes pour éviter les erreurs. Ici, les "vieux routiers" de l'informatique pourront être plus indiqués que les "jeunes loups du digital". Au final, expérience, anticipation, teamplay et vision internationale pourraient faire la différence. Mais, comme pour tout projet digital, le bon sens est un vrai plus...