Produit du marché ou maison : Do it or buy it ?

Produit du marché ou maison : Do it or buy it ?

Lorsque vous concevez et développez un produit en interne, from scratch, l’Agilité est idéale pour :

• Organiser le travail en équipe
• Apporter rapidement de la valeur ajoutée
• Optimiser le Time To Market
• Améliorer le produit par itérations

Mais, en amont de son développement, comment et pourquoi choisit-on de construire un produit maison plutôt que de sélectionner un produit du marché ? Quelles sont les étapes à suivre avant de faire ce choix ?

J’ai travaillé sur deux projets différents sur lesquels la question “Do it or buy it” s’est posée.

Cas numéro 1 : L’application Log’Inventaire

WMS du marché lors de la phase initiale du projet

Tout d’abord en 2018, sur un projet nommé Login chez Adeo Leroy Merlin. Ce projet visait à mettre en place un nouvel outil de gestion des stocks en magasin. L’équipe projet avait choisi la solution WMS Reflex, développée par un éditeur français nommé Hardis basé dans la banlieue de Grenoble.

Ce gros projet était divisé en plusieurs parties : gestion des réceptions, gestion des évolutions de stocks en magasin, SAV et retours clients, etc. Je devais pour ma part piloter le sujet des inventaires. En 2018, quelques semaines avant mon arrivée sur le projet, Login a été déployé sur un magasin pilote, à Saint-Etienne. Ensuite, il a été déployé sur un deuxième magasin, Reims Cormontreuil.

Comme tous les magasins Leroy Merlin de France, ceux-ci étaient soumis à un inventaire annuel, généralement réalisé en fin d’année civile. L’inventaire annuel consiste à :

• compter l’intégralité du stock du magasin (surface de vente + réserve)
• à comparer ce comptage avec la valeur de stock connue dans les systèmes informatiques
• et à constater une éventuelle perte de valeur de stock (démarque).

L’inventaire se déroulait de la façon suivante :

• comptage de la réserve (environ 30% du stock) sur les 10 jours précédant l’inventaire de la surface de vente (jours J-10 à J).
• comptage de la surface de vente (environ 70% du stock), magasin fermé, sur une nuit par un prestataire type Rgis, Ivalis ou Novastock (jour J de l’inventaire)
• contrôle à J+1 des plus gros écarts de stock par rayon/nomenclature
• audit à J+2

Bilan après les deux premiers inventaires

Fin 2018, nous avons donc réalisé deux inventaires annuels avec le nouveau système de gestion des stocks (Login/Reflex) : Saint-Etienne et Reims Cormontreuil. Nous en avons tiré quelques enseignements majeurs pour la suite de notre projet.

1/ Amélioration de l’inventaire de la réserve

L’utilisation du WMS Reflex a permis de gros progrès sur le comptage de la réserve. En effet, le magasin passait d’un mode crayon/papier puis saisie informatique à un mode en temps réel. Muni d’un device mobile, l’inventoriste, généralement salarié du magasin, venait flasher l’adresse du rail en réserve (1 adresse par mètre et par niveau), comptait les articles en scannant les code-barres et déclarait le nouveau stock en temps réel. Cela a permis d’améliorer considérablement la fiabilité du stock en réserve, même hors période d’inventaire.

2/ Dégradation de l’inventaire de la surface de vente

En revanche, le WMS Reflex n’était pas adapté pour le comptage de la surface de vente. En fin d’inventaire, vers 2h du matin, le prestataire de service remet un fichier long de 50.000 à 100.000 lignes avec tout le comptage de la surface de vente, chaque ligne étant de type V001P002;12345678;10 avec :

• V001P002 l’adresse (le lieu où se trouve le produit sur la surface de vente)
• 12345678 la référence produit
• 10 le stock compté

Le challenge était d’intégrer ce fichier de comptage dans le système et de le valider comme étant le nouveau stock de la surface de vente, avant la réouverture du magasin le lendemain matin. En effet, dès que le magasin est ouvert aux clients, le stock bouge à nouveau de par les diverses entrées et sorties de marchandises. Problème : le WMS mettait environ 6 heures pour digérer ce fichier et mettre à jour le stock de la surface de vente, mettant en péril la réouverture du magasin le lendemain matin.

Premier bilan post-inventaires

Passés les deux premiers inventaires réalisés sous Login fin 2018, nous en avons tiré plusieurs enseignements. Il y avait incontestablement des choses que nous devions améliorer pour les inventaires futurs.

1/ La priorité numéro 1 était l’intégration de ce fichier de stock. Elle devait absolument se faire de façon beaucoup plus rapide afin de mettre le stock à jour avant la réouverture du magasin. Il fallait absolument trouver une solution pour pouvoir envisager un déploiement de la solution sur un plus grand nombre de magasins.

2/ L’éditeur Hardis nous a accompagnés sur l’inventaire et nous avons rapidement fait un constat commun.

• Le processus d’inventaire défini par l’entreprise ne s’était pas suffisamment adapté aux possibilités standards offertes par l’outil Reflex concernant l’inventaire de la surface de vente
• Pour espérer une amélioration du temps de traitement du fichier, sans garantie de résultat, il aurait fallu se lancer dans des cadrages puis des développements spécifiques.
• Pour rappel, notre contexte était déjà délicat et contraint : un siège en métropole lilloise, des magasins pilotes à Saint-Etienne et Reims, et un éditeur en métropole grenobloise. Pas évident pour faciliter les interactions dans un contexte pré-Covid19 où le télétravail ne s’était pas encore démocratisé.

Analyse approfondie

Après réflexion, nous avons pris le temps en toute transparence de présenter un bilan de nos deux premiers inventaires aux différentes parties prenantes. Si, d’un point de vue global, Login/Reflex restait l’outil cible de gestion de stocks, il nous fallait trouver une solution pour intégrer les nouveaux stocks en masse suite à la nuit d’inventaire.

Nous avons pris du recul et analysé en détail comment se faisait le traitement du fichier côté Reflex. Nous avons constaté que le traitement se faisait ligne par ligne dans Reflex. Or il était dans l’absolu possible :

• d’agréger les lignes du prestataire : en effet, si dans le fichier nous avions une ligne adresse1;ref1;3 puis plus loin une ligne adresse1;ref1;7, cela veut dire qu’il y a un stock de 10 pour la ref 1 à l’adresse 1. Il convenait donc de mettre en place des règles de gestion pour agréger ces lignes en début de traitement, pour n’avoir ensuite à traiter qu’une seule ligne au lieu de deux.
• de paralléliser les traitements : plutôt que d’attendre la fin de la mise à jour du stock de la ref1 pour mettre à jour celui de la ref2, il était possible de mettre à jour les deux en même temps, dans la mesure où ils concernaient des références différentes.

A l’issue de cette analyse approfondie, nous n’avions plus de doute sur le fait que nous devions développer notre propre application maison pour réaliser cette partie du traitement.

Création de notre produit maison

Afin de pouvoir créer cette application, nous avons dû respecter différentes étapes.

Annonce de notre plan d’action aux parties prenantes

Nous avons une nouvelle fois échangé avec les parties prenantes : logistiques, techniques (IT LM et éditeur), contrôleurs de gestion, auditeurs, comptables. Nous leur avons présenté les résultats de notre analyse approfondie et notre principale conclusion, à savoir que le développement d’une application maison nous semblait incontournable. Ces échanges nous ont permis d’affiner notre cadrage et de recueillir différents besoins pour le développement de notre produit, au-delà du MVP :

• Le MVP restait clairement le fait de mettre à disposition une interface, pour le contrôleur de gestion magasin, afin qu’il puisse y charger le fichier du prestataire à l’issue de l’inventaire. Ensuite, en back, s’effectue le travail d’agrégation des lignes puis les posts parallélisés vers Reflex pour mettre à jour les stocks.
• Mais, quitte à développer une interface pour charger ce fichier, autant l’enrichir au-delà du MVP avec d’autres éléments importants pour le contrôleur de gestion magasin. Cette app pourrait donc servir aussi à remonter les principaux écarts de stocks avant/après inventaire, en quantité et en valeur absolue, par nomenclature produit (rayon), afin de permettre au contrôleur de gestion de mieux piloter ses contrôles d’inventaire à J+1.
• D’un point de vue technique, cette app a été conçue pour être “Login on” and “Login off” : autrement dit pour pouvoir fonctionner dans les magasins Backo (l’ancien système de gestion de stock), Login, voire même avec un autre nouveau système différent si Login venait à ne pas être déployé sur le long terme au-delà des deux premiers magasins.

Lancement d’un PoC

Une fois le produit conçu sur le papier, nous avons fait appel à deux développeurs du centre de service Norsys pour réaliser un Poc (Proof of Concept) sur la partie agrégation des lignes et parallélisation des mises à jour de stock.

Le PoC s’est rapidement avéré concluant, le traitement était beaucoup plus rapide ainsi. Cela a renforcé notre conviction, nous avons présenté les résultats du PoC aux différentes parties prenantes et nous avons décidé de lancer notre produit.

Obtention d’un budget

Nous avons pu obtenir un budget dédié pour créer ce produit que nous avons nommé Log’Inventaire. Nous avons alors recruté nos deux développeurs du PoC plus deux autres au lancement du projet..

En 2019, nous avons pu prendre le temps de développer notre application, de la tester en magasin tout au long du premier semestre et d’enrichir ensuite notre MVP. Cette application a été utilisée sur les magasins Login sur Q3 et Q4 2019, puis a encore pu être enrichie de nouvelles fonctionnalités par la suite.

Cas numéro 2 : Le référentiel de métadonnées

Contexte : Internationalisation d’un CMS

Je travaille depuis avril 2021 sur une mission au sein de la Customer and Commerce Digital Platform (CCDP) d’Adeo. Je suis Product Owner d’un produit Saas qui s’appelle Contentful. Il s’agit d’un Content Management System (CMS). Ce produit était déjà utilisé à mon arrivée sur le projet par Leroy Merlin France pour héberger ses contenus éditoriaux : Comment choisir, Make It, etc.

Avec mon binôme chef de projet intégration, nous avons eu pour mission :

1/ de benchmarker plusieurs CMS et de valider Contentful comme étant le CMS multi-BU de la CCDP

2/ d’internationaliser l’outil de façon à le rendre utilisable par 3 nouvelles BUs en 2022 (Leroy Merlin Italie, Espagne, Portugal), puis une nouvelle en 2023 (Leroy Merlin Pologne).

La phase de contractualisation avec l’éditeur passée, nous avons recruté un développeur afin de construire un Extract Transform Load (ETL) capable de récupérer le contenu déjà rédigé dans le CMS local (Contentchef pour l’Italie, Adobe pour l’Espagne, Studio pour le Portugal) afin de le migrer vers le CMS cible (Contentful).

En parallèle, mon rôle a été également de former les utilisateurs en BU à l’utilisation de Contentful, afin qu’ils puissent :

• modifier, valider et publier les contenus migrés automatiquement car la migration automatique est rarement parfaite (mise à jour des médias, des liens, de la mise en forme…)
• créer leurs nouveaux contenus directement dans l’outil.

Les métadonnées : pourquoi ?

Nous utilisons des métadonnées et des valeurs de métadonnées afin de catégoriser le contenu.

Exemple :

• “Web nomenclature” est une métadonnée. Cette métadonnée Web nomenclature est, en quelque sorte, l’équivalent du rayon.
• “Salle de bains” est une valeur de la métadonnée Web nomenclature.

Ces métadonnées et valeurs de métadonnées ne sont pas seulement exploitées à des fins de référencement SEO.

Elles sont aussi utilisées, entre autres, pour classer les contenus (catégoriser) de la façon souhaitée sur le site, mais aussi pour construire l’url et le fil d’ariane. Ces métadonnées ont donc un rôle central.

Définition de la cible et mise en place de la trajectoire

Cible : Un référentiel commun de métadonnées

Avant l’ouverture aux nouvelles BUs, Leroy Merlin France renseignait un champ éditorial qui faisait appel à des métadonnées modélisées en dur et en français dans le produit Contentful en lui-même.

Ce mode n’était pas compatible avec l’ouverture de Contentful aux nouvelles BUs. Nous avons rapidement compris que nous allions devoir externaliser la gestion des métadonnées dans un référentiel, d’autant que potentiellement, les métadonnées pouvaient être nécessaires à d’autres produits du domaine comme le DAM multi-BU, etc.

Trajectoire : Une externalisation des métadonnées dans Phrase

Sur le premier semestre 2022, le timing était relativement serré, car nous devions à la fois :

• Internationaliser nos modèles dans Contentful : traduire les noms des modèles, champs et clés en anglais
• Former les utilisateurs des nouvelles BUs
• Migrer les contenus de leur CMS vers Contentful

Nous n’avions donc ni le budget ni le temps nécessaire pour cadrer et construire en parallèle un référentiel de métadonnées. Cependant, nous avions tout de même besoin d’externaliser la gestion des métadonnées afin de pouvoir partager nos modèles dans Contentful.

Nous avons donc travaillé sur une trajectoire qui consistait à :

• Externaliser la gestion des métadonnées et des valeurs associées dans Phrase, avec implémentation de clés et traductions dans les différentes locales.
• Créer un nouveau champ “ccdpMetadata” dans les modèles éditoriaux utilisant les métadonnées, ce champ appelant les métadonnées de Phrase et leurs valeurs
• Faire en sorte que l’utilisateur créateur de contenu ne puisse voir que les métadonnées qui l’intéressent : exemple un créateur de contenu “Comment choisir” italien ne verra que les métadonnées et valeurs de métadonnées relatives aux “Comment choisir” et les données s’afficheront en italien.
• A terme, basculer progressivement la BU Leroy Merlin France, qui utilisait l’ancien champ dit “old Metadata” vers le nouveau champ ccdp afin de pouvoir être tous sur le même mode et construire des usages et reportings communs

Une fois ces étapes de trajectoire respectées, nous pourrions alors passer à la cible et le véritable référentiel de métadonnées viendrait remplacer la “trajectoire Phrase”.

Pourquoi Phrase en trajectoire ?

Nous avons saisi l’opportunité d’utiliser Phrase car nous avions déjà des licences disponibles au sein de notre domaine.

Quand un créateur de contenu avec un rôle LMIT se connecte à Contentful pour créer un contenu Editorial de type Comment Choisir, nous avons développé une app qui détecte le contexte (LMIT, Comment Choisir), appelle Phrase via une API Metadata intermédiaire et affiche les métadonnées et valeurs de métadonnées pertinentes en langue italienne.

Cela dit, Phrase ne répond pas à tous les besoins fonctionnels définis par les utilisateurs. Il ne couvre notamment pas un besoin fonctionnel majeur qui est la gestion de thésaurus, autrement dit la définition et structuration de métadonnées et valeur de métadonnées sur plusieurs niveaux.

Do it or buy it ?

Les deux cas exposés précédemment sont différents.

Dans le cas numéro 1, nous avons utilisé un outil du marché, qui ne répondait pas à notre besoin. Nous avions donc la conviction qu’il fallait développer notre propre application. Nous avons créé un PoC qui a prouvé la viabilité de notre produit, nous avons ensuite lancé notre produit et nous l’avons amélioré continuellement. Le produit est en phase de run.

Dans le cas numéro 2, nous avons établi une solution trajectoire qui répond partiellement au besoin. Elle n’est pas pérenne. Nous avons analysé et cadré notre besoin global. Nous devons maintenant décider si nous développons le produit nous-mêmes ou si nous nous orientons vers un produit du marché. Voici les différentes étapes de notre analyse

Avantages et inconvénients “Do it” vs “Buy it”

Nous avons commencé à établir une matrice générique des avantages et inconvénients, selon nous, du “Do it” vs “Buy it”.

Analyse Gartner pour sélectionner les meilleurs produits du marché

Pour pouvoir évaluer de façon optimale l’option “Produit du marché”, encore faut-il connaître les meilleurs produits du marché, pour la gestion des métadonnées dans notre cas.

Gartner Inc. est une entreprise américaine de conseil et de recherche dans le domaine des techniques avancées. C’est l’un des principaux cabinets d’études et de conseil en technologie de l’information.

Le Gartner Magic Quadrant est une évaluation annuelle publiée par Gartner. Il fournit une analyse comparative des entreprises de technologie dans un marché spécifique en fonction de leur capacité d’exécution et de leur vision stratégique.

Nous avons donc recherché les meilleures solutions d’EMM (Enterprise Metadata Management) sur Gartner : https://www.gartner.com/reviews/market/metadata-management-solutions

La page recense 64 solutions. Nous ne pouvons les analyser toutes. Nous avons donc décidé d’en sélectionner 4 en se basant sur les critères suivants :

• Tri par meilleure note
• Nombre de reviews suffisant (si une solution a une note de 5 sur 5 mais avec juste 1 review, on ne la prend pas en compte)

Nous avons donc sélectionné les éditeurs suivants :

• Alex
• Data Galaxy
• PoolParty
• Solidatus

Dans cette liste, nous savons que PoolParty est déjà utilisé en interne, par d’autres domaines que le nôtre. Nous allons donc pouvoir explorer cette piste en priorité afin de savoir si elle est viable.

Evaluation du TCO — Macro chiffrage global

L’évaluation du Total Cost of Ownership (TCO) est une étape très importante. Elle consiste à calculer le coût global du cycle de vie d’un produit. Evidemment, cela reste très théorique car quand on cadre un produit, il est difficile pour ne pas dire impossible de tout anticiper.

En revanche, l’exercice du macro chiffrage global est intéressant. Nous l’avons fait pour le développement du MVP d’une solution maison. Nous avons créé notre produit dans Jira, avec nos Epics et nos premières tâches indispensables rattachées à ces Epics.

Selon nous, et même si cette analyse doit être affinée avec les différentes parties prenantes, nous évaluons à environ 60 jours/homme le développement d’une V1 maison du MetaRef

Nous parlons bien ici du coût de développement, or le TCO prend aussi en compte les coûts d’hébergement, de run, etc. Ce CTO global n’a pas encore été évalué à ce stade de la réflexion.

Nous avons déjà cadré notre besoin donc le développement du produit maison pourrait être lancé dès maintenant, sous condition de priorisation du sujet et de budget officiellement alloué.

En comparaison, si nous optons pour un produit du marché, avant même l’implémentation du produit nous devrions

• Lancer une analyse approfondie des 4 éditeurs sélectionnés via Gartner
• Prendre contact avec les éditeurs
• Préparer et lancer un Request For Proposal (RFP), autrement dit un Appel d’Offres
• Établir une short list suite aux réponses du RFP
• Organiser une démo produit avec chaque éditeur shortlisté
• Sélectionner l’éditeur et contractualiser la relation

Certaines de ces étapes peuvent être longues :

• Organiser un RFP par exemple. Chaque éditeur doit répondre à un ensemble de documents : matrices fonctionnelles, techniques, documents légaux, commerciaux
• Contractualisation : Il s’agit d’un contrat multi-BUs dans lequel nous devons nous mettre d’accord sur les relations commerciales et juridiques. Cela peut prendre plusieurs mois.

Conclusion

Ces temps d’analyse, de RFP et de contractualisation sont longs et sollicitent de nombreuses ressources en interne. C’est pourquoi à ce stade de l’analyse, et si rien n’est encore décidé, nous recommandons dans notre cas du Référentiel de Métadonnées d’opter pour la solution “produit maison”. Il serait en théorie bien plus simple et rapide pour nous de développer le MVP, déjà cadré et macro-chiffré, que de lancer un RFP pour évaluer différents éditeurs.

Il n’existe cependant pas une bonne et une mauvaise solution. Notre produit référentiel de métadonnées est un produit de petite taille à l’échelle de notre SI. Il se prête parfaitement au développement Agile d’un MVP avec une amélioration continue au fil des itérations.

Cela dit, le choix du produit du marché peut être de loin le plus adapté en d’autres circonstances. Votre choix va dépendre de nombreux critères. En voici quelques uns parmi les plus importants :

• TCO : Quel est le coût global ? Quelle est la solution la moins chère ?
• Time to Market : Quelle solution pourrait être commercialisée le plus rapidement ?
• Architecture SI : Quelle est la place du produit au sein de l’architecture de votre SI ?
• Robustesse/Taille du produit : Votre produit va-t-il devoir gérer un grand nombre de fonctionnalités ? Stocker beaucoup de données ?
• Utilisation/Sollicitation de votre produit : Votre produit va-t-il être déployé à grande échelle ? Dans plusieurs BUs ? Exploité par combien d’utilisateurs ?
• Équipes de développement : Avez-vous une équipe de développeurs à votre disposition ? Combien de développeurs ? Quel est le niveau technique de votre équipe ? Et votre niveau de confiance en votre équipe ?

Vision produit/entreprise : Quelle est la politique/stratégie de votre entreprise concernant les équipes digitales ? Quelles sont les règles en cours ? Internaliser un maximum pour être en totale maîtrise du cycle de vie des produits (maîtrise métier, fonctionnelle, fréquence de delivery, rapidité d’adaptation, etc…) ? Externaliser (avec par exemple l’utilisation de Centre de Services et/ou de projets au forfait, pour potentiellement mieux maîtriser les coûts via des contrats, et ne pas avoir de charges salariales) ? Stratégie intermédiaire ?

Article rédigé par

Alexandre LABADIE