Amélioration du processus de remontées de données produits - Université de Lille
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Université de Lille
Master Informatique
Spécialité Infrastructures Applicatives et Génie Logiciel
Amélioration du processus de remontées
de données produits.
Responsable de formation :
Giuseppe Lipari
Auteur : Tuteur académique :
Louis Magand Laurence Duchien
Tuteur d’entreprise :
Lydéric Fovez
21 juin 2019
Résumé Leroy Merlin est une enseigne de grande distribution française spécialisée dans la construc- tion, le bricolage et le jardinage. Depuis sa création en 1923, Leroy Merlin a accumulé plus de 300 000 références en vente sur internet et dans les 140 magasins Français. Cette masse de produit a donnée naissance à un problème de grande envergure au sein de Leroy Merlin : des irrégularités dans les données produits. Remboursements et autres impacts négatives sur les clients en sont les principales résultantes. En sachant que Leroy Merlin a pour ob- jectif l’année prochaine d’arriver à 500 000 références pour concurrencer les markets places (ManoMano), ce problème parait d’autant plus critique. La solution : SOS Data. Construit en lien avec les utilisateurs et les équipes chez Leroy Merlin, sa simplicité d’utilisation permet de nombreuses remontées et des corrections effi- caces. Les technologies modernes utilisées pour son développement ont engendré un logiciel rapide et modulable. Le projet a été en phase de test dans 3 magasins et 3 équipes en interne, et les résultats sont à la hauteur de nos espérances.
Abstract Leroy Merlin is a French retail chain specializing in construction, DIY and gardening. Since its creation in 1923, Leroy Merlin has accumulated more than 300,000 references for sale on the internet and in its 140 French stores. This mass of product has rise a major issue within Leroy Merlin : irregularities in the product data. Reimbursement and negative impact on customers are the main results of it. Knowing that Leroy Merlin aims next year to reach 500,000 references to compete with the markets places (ManoMano), this problem seems even more serious. The solution : SOS Data. Built in conjunction with users and teams at Leroy Merlin, its ease of use allows for many reassemblies and effective corrections. Modern technologies used for its development have generated a fast and scalable software. The project has been tested in 3 stores and 3 internal teams, and the results are up to our expectations.
Acronymes
LM FR Leroy Merlin France
BU Business Unit
PDP Pilote Data Produit
PASCQ Produit Achat Supply Chain Qualité
AT Assistance Téléphonique
PRI Plateforme Relation Internet
SSO Single Sign-On ou Authentification Unique
CI Continious Integration ou Intégration Continue
CD Continious Déploiement ou Déploiement Continu
KPI Key Performance Indicator ou Indicateur Clé de Per-
formance
Termes
PDP Collaborateur Leroy Merlin s’occupant de gérer les
produits d’un ou plusieurs rayons.
Désignation Libellé d’un produit.
Datapack Dimensions du produit emballé.
Team Data Équipe LM FR s’occupant des données Datapack des
Délivrance produits.
PRI Équipe recevant des appels de clients en lien avec le
site Internet.
Supply Equipe s’occupant de gérer la chaîne d’approvision-
nement.
Step Logiciel de gestion des caractéristiques produit chez
Leroy Merlin.
Remerciements
Je tiens à remercier toutes les personnes qui ont contribué au succès de SOS Data et plus
particulièrement Lydéric Fovez qui a été mon tuteur d’entreprise et qui m’a consacré, au
cours de ces deux années, beaucoup de son temps sans jamais concéder sur les explications.
Je remercie également Laurence Duchien, pour son accompagnement de qualité et son suivi
régulier avec toujours une bonne humeur et des conseils à la clé.
Je tenais à remercier Elisabeth Chaumette, Julian De Sanctis, Romain Lahaxe et Tho-
mas Vincent pour leur implication dans SOS Data. Ils ont tous accordés de leurs temps
précieux pour rendre sa mise en place possible. Sans oublier ma petite soeur, qui a contribué
bénévolement à SOS Data en créant son magnifique logo.
Je n’oublierais bien sur pas l’équipe Offre avec qui j’ai passé deux très belles années au
sein de Leroy Merlin. Sans leurs tirs de Nerf et leur humour délicat, je serais sans aucun
doute quelqu’un de différent.
Pour finir, j’aimerais exprimer ma gratitude à l’entreprise Leroy Merlin France qui offre
d’incroyables conditions de travail à ses collaborateurs, tant sur le plan technique que social.
C’est une grande joie d’avoir eu l’opportunité d’effectuer mon apprentissage dans cette
société.
Table des matières
Introduction 1
1 Gestion des produits chez Leroy Merlin 2
1.1 Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Le cycle de vie du produit et leurs acteurs . . . . . . . . . . . . . . . . . . . . 2
1.3 Les différents processus de remontées de données produits . . . . . . . . . . . 6
1.4 La correction de données produit . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 SOS Data 9
2.1 La raison d’existence de SOS Data . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 L’équipe et son organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Les objectifs et les moyens mis en œuvre . . . . . . . . . . . . . . . . . . . . . 11
2.4 Le déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Ce que SOS Data va changer . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 L’environnement technique 14
3.1 Le fonctionnement de SOS Data . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 La structure de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Le backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Le frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 La gestion des utilisateurs et leurs droits . . . . . . . . . . . . . . . . . . . . . 22
4 L’infrastructure et déploiement du projet 24
4.1 Gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 CI avec Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 CD avec Openshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Le futur de SOS Data 28
5.1 Les fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Une ouverture pour ADEO et autre BU . . . . . . . . . . . . . . . . . . . . . 28
Conclusion 30
Annexes 32
Annexe 33
1 Schémas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2 Fichiers de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1 Gitlab CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Introduction
Leroy Merlin est une entreprise qui se donne pour mission de construire les nouvelles
façons d’habiter, pour mieux vivre demain. L’enseigne fait partie d’un grand groupe inter-
national, Adeo. Elle a su rester une entreprise à taille humaine, avec une simplicité dans
ses relations : une confiance accordée à chacun et dans laquelle chaque collaborateur parti-
cipe vraiment à l’écriture de la stratégie de l’entreprise. Avec une entreprise installée depuis
presque 100 ans sur le territoire français, Leroy Merlin possède maintenant un système de
données vaste et complexe. Chaque produit vendu par Leroy Merlin a un nombre de ca-
ractéristiques important, pouvant aller d’une petite dizaine pour des produits simples à
plus d’une cinquantaine. Les erreurs sont donc largement présentes et peuvent entraîner
de sérieux problèmes avec le client (surcoût de livraison, commande d’un mauvais produit,
remboursement). Avant que l’on commence à travailler sur l’amélioration du processus de
remontée de données produits, aucune méthode efficace n’existait pour remonter ces erreurs.
Rien n’était défini de manière officielle et aucun logiciel ne prenait en charge le problème.
Donc, afin de permettre la prise en compte de ces anomalies, une solution a été créée au sein
du SI Leroy Merlin : SOS Data.
Le principe de SOS Data est de centraliser toutes les remontées d’erreurs de données
produits, de procurer un retour aux collaborateurs qui remontent les anomalies. Cela per-
mettra d’enfin avoir une vision claire sur la qualité des données produits chez Leroy Merlin,
mais aussi de comprendre l’origine de ces irrégularités.
Nous allons donc voir, à travers ce mémoire, comment SOS Data va améliorer le processus
de remontées des erreurs de données produits.
Pour cela, premièrement, une explication sur la gestion des produits chez Leroy Merlin
sera apportée, à savoir : la création d’une référence dans la base de données produits, et la
découverte des acteurs qui gèrent les caractéristiques du produit tout au long de son cycle
de vie.
Dans un second temps, une présentation humaine et morale de SOS Data sera montrée,
à savoir : les différents buts et objectifs du logiciel, l’équipe mise en place pour travailler
dessus et leur rôle. Et finalement, la raison d’existence de SOS Data.
Puis, une partie sur l’environnement technique de développement et de déploiement sera
abordée. Le choix des technologies et les fonctionnalités de SOS Data seront également dé-
montrés, à travers plusieurs grandes parties présentant les fonctionnalités du logiciel, son
backend, son frontend et le système d’authentification mis en place. L’intégration et déploie-
ment continus seront aussi expliqués.
Enfin, une ouverture sur le futur du logiciel et de ses fonctionnalités à venir sera exposée
dans une dernière partie.
1Chapitre 1
Gestion des produits chez Leroy
Merlin
1.1 Enjeux
Au travers de ses 300 000 produits, Leroy Merlin gère un vaste flot de données, contenant
des informations très diverses. La bonne gestion de ces données est un facteur important
dans la concrétisation des ventes pour une enseigne de distribution. En effet, les données
sont des outils de communication et de vente tout autant que des outils de gestion et de
pilotage de la stratégie commerciale.
La problématique est d’autant plus importante qu’elle ne concerne pas uniquement les
données liées aux produits vendus par Leroy Merlin mais aussi celles de tous les produits
vendus par les enseignes du groupe. Pour regrouper toutes les enseignes, le Système d’Infor-
mation (SI) répertorie toutes les données d’Adeo et des autres Business Units (BUs) comme
l’Espagne ou le Portugal. Grâce à cela, des références produits ajoutées par le groupe Adeo
peuvent être déversées dans toutes les BUs.
Cependant les données deviennent plus complexes car des différences de gestion de ca-
ractéristiques produits peuvent exister.
Ainsi à cause d’un processus long, impliquant beaucoup d’acteurs et de multiples fichiers
Excel, il faut entre 2 semaines et 3 mois afin d’ajouter une référence sur le site internet. Là
où Amazon a un time-to-market 1 quasiment inexistant, la création d’un nouveau produit
sur leur site étant instantanée.
Ma mission au sein de Leroy Merlin n’était pas portée sur le processus de création d’un
produit dans le SI, mais sur le processus de gestion de sa vie et de ses mises à jour.
En effet, bien que le processus d’ajout soit bien cerné, celui de la correction de ses données
n’est que partiellement gérée.
1.2 Le cycle de vie du produit et leurs acteurs
Afin de bien comprendre les différents acteurs et logiciels qui interviennent dans la gestion
des données produits, nous allons voir 4 étapes (cf. fig. 1.1) du processus de référencement
produits qui posent problème dans la qualité de la donnée durant son cycle de vie.
Entourées en trait plein rouge sont les étapes qui engendrent des actions avec le client
(remboursement, dédommagement).
Entourées en pointillés sont les étapes où généralement aucune action n’est entreprise
mais engendre un mécontentement de la part du client.
1. Temps de publication d’un produit sur le marché numérique ou non.
2Figure 1.1 – Étapes posant le plus problème dans le processus de référencement produit 2 .
1. La première étape posant problème dans la qualité de la donnée est celle qui
s’intitule “Compléter les données et préparer les médias”. C’est une tâche effec-
tuée par le fournisseur qui doit préparer ses fichiers de médias et les données
qu’il va fournir à Leroy Merlin sur un fichier Excel. Cette action peut entraî-
ner une première possibilité d’erreurs car c’est à ce moment que les véritables
informations d’une référence et ces médias sont données par le fournisseur. Un
exemple concret avec la fig. 1.2.
2. Schéma complet disponible en annexe.Figure 1.2 – Image mettant en avant un problème de Médias.
Cette maisonnette en bois présente sur le site web de Leroy Merlin est accompagnée
d’un toboggan sur la photo. Or, le toboggan n’est pas homologué par le fournisseur. Et
bien sûr, le cas où un client s’est plaint de ne pas pouvoir mettre un toboggan est arrivé.
Un remboursement a dû avoir lieu. Ce problème aurait pu être rapidement identifié par un
collaborateur en magasin grâce à SOS Data.
2. La deuxième étape qui pose problème est “Intégrer les documents de confor-
mité”. C’est encore une fois le fournisseur qui est l’acteur principale de cette
tâche qui consiste à déposer les documents légaux et utiles aux clients sur une
plateforme dédiée. Ces documents sont, dans notre cas, des notices. En théo-
rie, un produit ne peut pas être publié sur le site internet si une notice utile
pour le client n’est pas mise à disposition par le fournisseur. Dans les faits,
des notices sont oubliées et la référence est quand même publiée, ou alors le
fournisseur dépose volontairement une notice vide. Cela génère beaucoup de
mécontentement chez le client. Nous avons une vision de ces irrégularités grâce
à l’Assistance Téléphonique qui reçoit de nombreux appels chaque jour et dont
40% de ces appels sont liés à des notices manquantes.
3. La troisième étape est “Relire et intégrer les données produits du fournisseur ”.
Ici beaucoup de problèmes sont présents, car la relecture est faite à la main par
le PDP. Il doit donc vérifier le fichier Excel que le fournisseur a préparé à l’étape
précédente. Un type de problème connu issue de cette étape sont les erreurs de
Datapack. La Datapack représente les dimensions ou poids du produit emballé.
La majeure partie du temps, c’est une unité ou une décimale qui est ajoutée
au produit, cela n’engendre normalement pas d’acte de dédommagement, le
client ayant quand même reçu le produit qu’il avait commandé. Mais il arrive
que cela se passe autrement. Avec, par exemple, ce tuteur de tomate fig. 1.3Figure 1.3 – Image expliquant un problème de Datapack.
D’après la désignation produit, il a une hauteur 1.5 mètres. Cela paraît être un tuteur
de tomate tout à fait banal. Mais en vérité, dans les informations du produit non visible par
le client, ce tuteur de tomate avait une hauteur de 15 mètres. Le résultat est que pour un
prix d’achat d’environ 10 euros, le client a dû payer des frais de livraison de 50 euros.
4. La 4ème et dernière étape concerne “[la certification] de la désignation client”.
La désignation administrative, donnée par le fournisseur, a été traitée par un
algorithme qui traduit cette désignation incompréhensible pour un client en
désignation client longue calculée. Le PDP doit maintenant valider la valeur
que l’algorithme a extraite. Plusieurs cas d’anomalies sont ici possibles, soit la
désignation administrative est erronée, soit l’algorithme a été coincé dans un
cas spécifique qui a résulté en erreur, soit le PDP n’a pas une connaissance assez
approfondie du produit et accepte la désignation client longue calculée même
si elle est mauvaise. A cause de cela, on arrive devant des cas intéressants,
comme le produit fig. 1.4. Ce diable non pliant est considéré comme pliant
dans la désignation client.Figure 1.4 – Image montrant un problème de désignation.
Ce processus de référencement produit est applicable à l’ensemble des références gérées
par Leroy Merlin. Mais toutes les références ne le sont pas. Les références PASCQ ont un
cycle de vie entièrement différents. C’est Adeo qui pousse ces références dans les Systèmes
d’Informations d’une sélection de BUs. Généralement, ce sont des produits qui peuvent
être utilisés par l’ensemble du groupe et que Adeo achète en très grande quantité pour
les revendre par la suite. On pourrait penser que le fait que cela soit Adeo qui injecte ces
références ne changent rien. Malheureusement ce n’est pas le cas car la PASCQ est une
petite BU en interne, qui gère elle-même ses comptes et ses références. De ce fait, seul cette
BU est responsable de leur cycle de vie. Les PDP n’ont donc pas la main pour les corriger,
et pour l’instant ils ne peuvent pas faire la distinction sur SOS Data, la donnée n’étant pas
récupérable via API.
Comme énoncé ci-dessus, de multiples acteurs participent au référencement produit : le
fournisseur, les PDP et les binômes produits (composés d’un chef et d’un assistant produit)
qui décident de référencer et de publier les références (première et dernière étapes). Les
Pilotes Data Produits sont les acteurs qui vont nous intéresser ici, car ce sont eux qui
s’occupent de gérer le cycle de vie du produit au sein de Leroy Merlin. C’est l’équipe des
PDP qui va modifier ou améliorer les données de produits avant qu’ils ne soient supprimés
du SI.
Bien entendu, l’erreur est possiblement créée au cours de toutes les étapes du proces-
sus puisque rien n’est automatisé et tout se fait via des échanges de fichiers Excel. Les
exemples précédents sont des cas d’écoles qui sont véritablement arrivés et dont la cause est
identifiable, mais il y a de forte chance qu’il existe d’autres origines d’erreurs de données
produits. Notamment à travers tous ces acteurs présents que sont les fournisseurs, Adeo
avec la PASCQ, le chef et l’assistant produits et les PDP. Heureusement, les PDP sont bien
formés à corriger des anomalies de données produits. En effet, aujourd’hui, dans les équipes
sans SOS Data, il existe diverse manières pour remonter une erreur de données produit.
1.3 Les différents processus de remontées de données pro-
duits
Pour comprendre et répondre aux besoins de correction de ces données, il est intéressant,
si ce n’est obligatoire, de connaître et comprendre les différents processus qui existent pourtous les collaborateurs de Leroy Merlin.
En magasin, les actions effectuées sont très longues. Il existe plusieurs canaux pour repé-
rer l’erreur de donnée produit : en programmant leurs opérations commerciales, en préparant
le balisage ou en conseillant un client. Après avoir repérée l’erreur, les collaborateurs en ma-
gasin vont sur le réseau social interne, font une petite dizaine de cliques et téléchargent
un PDF contenant les noms de l’ensemble des collaborateurs travaillants sur leur rayon. Ils
doivent ensuite chercher la bonne personne associée au produit. Tout cela pour finalement
lui envoyer un mail. De plus, une trop grosse partie de ces mails est adressée aux mauvaises
personnes (assistant ou chef produit), qui ne le transmettent pas toujours au PDP, qui sont
les responsables des données produits. Finalement la remontée est ici complètement inutile.
Les plus chanceux ont un trombinoscope imprimé des différentes personnes affiliées à leurs
rayons. D’autres remontent directement sur une communauté du réseau social interne, qui
est submergée par d’autres sujets que des remontées produits et dont une maigre partie des
PDP s’occupent. Dans ce cas là aussi, les remontées se perdent très rapidement, ou ne sont
jamais corrigées.
Le fonctionnement côté magasin n’est donc pas véritablement identifié ni efficace. En
effet, 71% des collaborateurs en magasin se disent peu satisfait de la façon dont ils remontent
les erreurs. Uniquement 29% des collaborateurs sont informés de la prise en compte de leur
remontée, de ce fait seul 52% des collaborateurs remontent les anomalies. Les collaborateurs
en magasin n’avaient donc, avant SOS Data, aucun moyen simple de remonter les erreurs
de données produits.
Dans les services internes, la méthode est un peu plus claire. Soit certaines équipes ont,
par expérience, les adresses mails des PDP et leurs envoient un message, ou alors elles vont
directement chercher le chef ou assistant produit (qui remontent au PDP). Pire, d’autres
collaborateurs se permettent eux-mêmes d’aller corriger les erreurs de données produits, au
risque d’en créer une nouvelle.
Grâce aux sondages distribués aux PDP, il a été mis en avant que 92% préviennent les
utilisateurs que la correction a été faite. Ce qui contraste nettement avec les résultats obtenus
en magasin. Cependant, les deux parties sont en adéquation au niveau de la satisfaction,
car 74% des PDP se disent peu satisfaits de la façon de gérer les remontées de données
produits. Le manque d’un processus clair engendre donc la naissance d’un irritant au niveau
des magasins et des PDP.
Il reste un dernier acteur participant à ces remontées : le client. A travers plusieurs
équipes en interne, avec l’AT ou la PRI, les clients remontent beaucoup d’erreurs de données
produits, environ 40% des appels pour l’AT et environ 400 appels par mois pour la PRI.
Fait intéressant, les collaborateurs de ces équipes n’avaient aucun moyen pour remonter ces
anomalies.
Nous avons pu voir à travers ce prisme qu’un point commun émerge : rien n’est défini.
Avant d’expliquer la solution mise en place, nous allons voir ce qu’un PDP fait après avoir
reçu une remontée d’erreur de données produit.
1.4 La correction de données produit
Aujourd’hui, la seule façon que les PDP ont de corriger la donnée est de passer par le
logiciel qui gère toutes les caractéristiques d’une fiche produit : Step. Mais cela reste assez
compliqué, le PDP doit analyser là où se trouve l’erreur pour ensuite modifier la bonne
caractéristique dans la fiche produit. Cela s’avère d’autant plus compliqué quand plusieurs
références d’un même modèle de produit, par exemple 4 radiateurs, sont remontés. Il se
peut que d’autres radiateurs aient le même problème. Un travail en profondeur doit ainsiêtre effectué pour pouvoir corriger la manière d’importer ce modèle dans Step afin d’éviter
de futures erreurs pour les mêmes types de radiateurs.
Dans le meilleur des cas, le PDP est autonome pour la correction. Sinon, il doit engager
un dialogue avec le fournisseur ou avec l’assistant produit pour avoir confirmation d’un
changement de caractéristique importante. La durée peut varier entre 3 jours et 2 semaines,
selon la disponibilité des différents interlocuteurs. Ce processus de correction de données est
voué à évoluer grâce à la création d’API complexe prévu pour l’année à venir.
A travers cette partie, le processus de référencement a été expliqué. Il a été mis en avant
que de nombreuses erreurs peuvent apparaître dans le SI de Leroy Merlin. Elles peuvent être
de tous types (désignation, datapack, médias, etc...) et de tous horizons (supply, AT, PRI,
clients). De plus, pour remonter ces erreurs, aucun processus ni aucun logiciel n’existent.
Avec la mise en lumière de ces manquements et problèmes, une solution a finalement
émergé : SOS Data.Chapitre 2
SOS Data
Il a été montré et expliqué que le processus de remontée d’anomalies de données produit
reste très imprécis. Pour permettre une centralisation de ces problèmes et une correction
efficace, SOS Data a été créé.
2.1 La raison d’existence de SOS Data
Avec mon tuteur d’entreprise, Lydéric Fovez, nous nous occupions d’un logiciel de bali-
sage, c’est-à-dire un logiciel qui permet de créer des étiquettes prix utilisées par les collabo-
rateurs en magasins et qui sont affichées dans les rayons. Avec le déploiement de ce logiciel
dans les 140 magasins, nous nous sommes rendu compte que beaucoup d’utilisateurs nous
avertissaient sur des données produits erronées. En effet, l’ancien logiciel palliait faussement
ce problème en enregistrant localement les modifications pour tout le magasin. Par exemple,
si la désignation client d’un diable était ‘Diable Pliant RED’ alors que le diable n’était pas
pliant, alors le collaborateur corrigeait la désignation en enlevant le mot pliant et la pro-
chaine fois que le balisage allait être fait, la désignation sauvegardée aurait été affichée par
défaut.
Nous nous sommes donc aperçu que sans l’ancien logiciel, beaucoup de problèmes étaient
présents. La sauvegarde de correction n’étant plus possible, les remontées se faisaient de plus
en plus nombreuses. Et de notre côté, aucun processus n’existait pour corriger cela. La seule
façon de remonter ces problèmes de données pour les collaborateurs en magasin était de soit
les rediriger vers une communauté de notre réseau social interne, où les demandes étaient
noyées et perdues sous la masse, soit par mail.
Nous avons décidé de créer un logiciel permettant de centraliser ces remontées. SOS Data
est donc un service web proposant :
— Soit une liste, permettant de gérer les remontées des utilisateurs.
— Soit un formulaire qui permet de faire les remontées tout en passant par les API de
Leroy Merlin pour ajouter des informations essentielles à la remontée.
Une liste pour gérer les erreurs a été choisie car il fallait que le PDP ait une vision élar-
gie des différentes remontées. En effet, plusieurs corrections d’erreurs pouvaient concerner
la même gamme ou famille de produit. Il était donc important que le PDP puisse aperce-
voir directement les différentes références présentes dans le tableau, pour pouvoir faire une
correction par lot. Aussi, avec la liste, le PDP peut facilement gérer le statut 1 d’un groupe
de références. Pour envoyer des remontées, il fallait que le collaborateur en magasin puisse
envoyer une erreur entre deux clients. C’est pour cela que l’idée d’un formulaire simple avec
1. Terminé ou En cours.
9seulement 3 champs a été mise en place. Le fonctionnement de ces deux composants sera
détaillé dans la partie 3.1.
La création de ce logiciel va permettre, sur le long terme, de découvrir les sources d’erreurs
des données produits et de les corriger en amont. Pour prendre un exemple concret, on peut
parler des désignations clients. Le libellé produit visible sur le site internet et en magasin
est en fait directement traduit depuis la désignation administrative (celle donnée par le
fournisseur) par un algorithme. Sur le long terme, après analyses des données de SOS Data,
il sera possible de savoir quelles spécifications de l’algorithme entraînent des erreurs de
traduction de désignation. Le but étant d’effectuer des corrections fiables et durables de
toutes les sources de données d’erreurs de données produits.
Une équipe a été formée au sein de Leroy Merlin pour guider le développement de SOS
Data.
2.2 L’équipe et son organisation
Pour avoir un fonctionnement efficace durant toute la durée de développement du projet,
nous avons construit une ‘squad’ avec des rôles précis, comme montré sur la fig. 2.1.
Figure 2.1 – Constitution de l’équipe travaillant sur SOS Data.
Une très bonne homogénéité dans les compétences ont permis un travail efficace. Le
Product Owner a établi une vision à long terme du logiciel en récoltant le besoin utilisateur.
Lydéric s’est occupé de confirmer ou infirmer les prises de décisions collectives que nous
prenions. Certaines orientations de développement pouvant être mitigées dans l’équipe, Ly-
déric était présent pour recadrer et conseiller sur des aspects que nous aurions pu oublier.
Elisabeth Chaumette est la responsable de l’organisation métier du projet, elle travaille en
lien direct avec le métier et cela a donc été notre relai principal avec l’ensemble des PDP
durant toute la conception du projet.
La composition de l’équipe se veut simple et très légère, et ceci pour plusieurs raisons :
(1) permettre une flexibilité dans la gestion du projet, (2) des évolutions simples et rapides,
où des modifications peuvent être apportées aux derniers moments sans effets néfastes sur
le travail de l’équipe et (3) une communication inégalée avec un nombre d’interlocuteurs
fortement réduit.En tant qu’unique développeur, c’était très appréciable car l’autonomie apportée grâce à
cette configuration a permis de construire sereinement le logiciel et son architecture. Chaque
semaine, une réunion de 30 minutes permettait de mettre tous les acteurs au courant et de
prioriser les différentes tâches pour les prochains sprints.
Cela a été un avantage pour déployer le Produit Minimum Viable, car le fait d’être une
petite équipe a permis une adaptation rapide dans le choix des déploiements des magasins,
des rayons et diverses équipes en fonction du nombre de remontées que l’on avait par semaine.
Par exemple, en seulement deux semaines, nous n’avions eu que 20 remontées. La faute a
une mauvaise estimation du nombre de remontées par personne par magasin, qui avait
été largement surestimée. Le choix de doubler les magasins, PDP et d’intégrer les équipes
internes a été fait. Grâce à cela les remontées ont quadruplé la semaine suivante. Pour
préparer et cerner au mieux le projet, nous nous sommes définis différents objectifs.
2.3 Les objectifs et les moyens mis en œuvre
Le projet s’est donc créé suite à un irritant, celui de ne pas avoir de moyen efficace de
remonter des erreurs de données produits. Une problématique que nous avons pu constater
ensemble, avec diverses équipes interne comme l’AT, la team Data Délivrance, la PRI et la
Supply.
Le fait de constater cet irritant sur d’autres projets, d’autres équipes, et dans d’autres
environnements a véritablement lancé le développement de SOS Data. L’analyse des besoins
et la construction d’un solide backlog sur Jira en lien avec les utilisateurs a permis de
démarrer les sprints de développement. Des priorités ont été établies sur l’ensemble des
tickets et ont été triées selon des Epic, représentant les fonctionnalités de l’application. Des
sprints de 2 semaines ont ainsi été effectués, avec des Story Points et une estimation en
demi-journées pour chaque ticket, afin d’établir un budget pour l’ensemble du backlog. Une
version est délivrée à chaque fin de sprint, procurant une plus-value comparée à la version
précédente.
Une feuille de route a commencé à émerger. Les fonctionnalités du projet ont donc été
basées sur les besoins des PDP d’un côté, et de l’autre, la volonté de remonter rapidement
et simplement les erreurs de données produits pour les collaborateurs.
Pour que le projet soit porté par Leroy Merlin, il faut le présenter devant le comité
de direction, afin d’avoir un budget et l’autorisation de le déployer dans l’ensemble des
magasins. Pour convaincre ce comité, il faut lui présenter les problèmes qu’engendre un
manque d’informations sur les processus ainsi que les KPI qu’on veut atteindre. Ces chiffres
serviront aussi à prouver, de manière continue, que le projet fonctionne toujours.
Pour cela, une analyse sur la base de données est effectuée avec l’outil Compass (outil
MongoDB pour visualiser les données sous forme de schémas et avec des requêtes) pour
mettre en avant les points suivants :
— Montrer que les délais de corrections sont de deux jours sans compter les
résolutions de type Notices, qui peuvent prendre une semaine à cause d’un
dialogue obligatoire avec le fournisseur.
— Identifier les retards de correction pour les remontées qui sont En Attente,
pour permettre d’identifier l’irritant.
— Avoir un taux de correction de remontées par jour de 80% (toujours en excluant
les notices).
— Avoir des statistiques selon la gamme et les fournisseurs, afin d’identifier plus
précisément les sources de problèmes.— Au moins 20% des remontées sont issues des magasins (et non des services
internes).
Ces KPI présentent clairement nos différents objectifs : créer un logiciel de remontées
d’erreurs de données produits permettant une correction rapide de la donnée, avec une iden-
tification des problèmes existants pour ensuite perfectionner le processus de référencement
produit. Certains indicateurs ont pu être extraits de la base de données après environ 400
références remontées, mais seulement une centaine corrigées :
— Concernant les délais de correction par type :
Désignation 10 jours
Visuel 2.5 jours
Datapack 8.2 jours
Notice 9.7 jours
Les délais sont pour l’instant supérieur à nos estimations. En effet, les PDP
n’étant pas encore complètement formés, certains n’utilisaient que rarement le
logiciel, ce qui a augmenté le délai de correction.
— Les retards de correction n’ont pas encore pu être identifiés, les PDP n’étant
pas encore tous impliqués dans le logiciel.
— Les gammes X et A sont celles qui posent le plus problèmes, représentant res-
pectivement 34% et 33% du total des remontées. Les fournisseurs ne sont pas
encore identifiés, car cette information est difficile à obtenir pour un produit
avec les APIs LM.
— Le taux de remontées effectuées par les magasins n’a pas pu être calculé pré-
cisément car on ne connaissait pas l’origine de celles-ci. Cependant, on estime
le pourcentage à moins de 10% du fait d’une grande présence de demandes de
corrections de type Notice, exclusivement envoyées par les équipes internes.
Pour avoir nous permettre de calculer ces KPI, un déploiement a été effectué avec diffé-
rents acteurs de Leroy Merlin.
2.4 Le déploiement
Afin d’en ressortir des mesures intéressantes, le projet a été en phase de test pendant un
mois et demi avec diverses équipes et plusieurs magasins avec des rayons prédéfinis.
Au niveau des remonteurs, il y avait l’assistance téléphonique, qui passait par un seul
collaborateur pour remonter toutes les corrections. L’équipe Data délivrance ainsi que la
PRI ont été entièrement formées pour que tous les membres de ces deux équipes remontent
des irrégularités de données. En plus, 6 rayons de trois magasins ont utilisé le formulaire
pour remonter des erreurs.
Pour les magasins, il a fallu préparer l’accessibilité du site web en préparant un raccourci
sur leurs bureaux mobiles, qui sont des sessions de Windows dans le Cloud. Et très rapide-
ment après la mise en place du raccourci, soit communiquer par mail, soit y aller directement
pour une légère formation. Au début la deuxième méthode a été beaucoup utilisée pour avoir
un feedback rapide et clair sur la façon dont était présentée le formulaire. En effet, la diffé-
rence de vocabulaire entre le magasin et les équipes internes est un véritable challenge, nous
nous en sommes rapidement rendu compte quand les premières remarques des utilisateurs
étaient des questions sur des termes qu’ils ne comprenaient pas. Ce sont des magasins dela région du Nord qui ont été choisis car leur proximité nous permettait de facilement nous
déplacer si le besoin s’en faisait sentir.
Au niveau des Pilotes Data Produits, nous avons présenté le projet à l’ensemble des PDP
mais uniquement formé une quinzaine, à raison de 2 ou 3 PDP par rayon. Des présentations
et formations de SOS Data ont eu lieu dans certaines équipes en interne, ce qui a permis
d’avoir beaucoup de remontées et de feedbacks. Nous avons effectué des séances individuelles
de retours d’utilisation de SOS Data avec les PDP pour nous permettre d’avoir des retours,
notamment sur l’interface. Après quelques semaines d’utilisation, il a été décidé de tripler
le nombre de rayons pour avoir des KPI les plus représentatifs possible. Nous sommes donc
retournés en magasins dans les nouveaux rayons, montrer et former à l’utilisation de SOS
Data. Cette expansion a été très efficace car le nombre de remontées a quadruplé après ce
choix.
Afin de mesurer au mieux les KPI et de calculer l’ensemble des remontées d’anomalies de
données produits (aucuns chiffres n’existaient auparavant), des formulaires ont été envoyés
aux diverses équipes internes et en magasin avant le déploiement de SOS Data, pour mettre
en avant ce que ce logiciel va changer au sein de LM.
2.5 Ce que SOS Data va changer
Grâce aux deux sondages effectués pour comprendre les différents processus de remontées
de données produit, nous nous sommes rendus compte qu’avec SOS Data, Leroy Merlin sera
en possession de plus de remontées d’erreurs de la part des magasins, et donc potentiellement
d’une meilleure qualité de données produits. En effet, seulement 50% des collaborateurs qui
remarquent des irrégularités les envoient au siège.
Dans un second temps, il sera possible d’avoir des métriques sur le type d’erreur le
plus présent, leurs temps de corrections moyen, et surtout la réponse à une question très
importante : d’où les erreurs proviennent-elles ? Quel est l’acteur le plus en faux dans le
processus de référencement de donnée ? Avoir la réponse à cette question permettrait une
amélioration continue du processus de référencement, dans l’espoir d’avoir une donnée 100%
fiable et utile pour le client.
Au niveau interne, SOS Data permettra aux collaborateurs dans les magasins de ne plus
être frustrés de ne pas avoir de moyen simple et efficace de remonter les erreurs de données
produits, et donc de remonter encore plus d’erreurs au siège.
A un niveau plus global, le logiciel permettra une augmentation de la lisibilité et compré-
hension des produits et une baisse de la frustration des clients liée à de mauvaises données
produits (cf. les problèmes décrient en début de document).Chapitre 3
L’environnement technique
3.1 Le fonctionnement de SOS Data
SOS Data se veut simple d’utilisation. Les utilisateurs finaux peuvent être de tous âges,
de tous horizons, et peuvent ne pas avoir le même jargon professionnel.
C’est pour cela que le logiciel se décompose en deux écrans distincts, utilisable par deux
types d’utilisateurs. D’un côté il y a les collaborateurs, qui viennent du service interne ou
des magasins qui sont les remonteurs des erreurs de données produits. Et il y a les utilisa-
teurs, qui sont les PDP. Le schéma (cf. fig. 3.1) explique bien les rôles de chacun à travers
l’illustration du cycle de vie d’une proposition de correction de données produit dans SOS
Data.
Figure 3.1 – Cycle de vie d’une proposition de correction de données produit via SOS Data.
L’action du remonteur est très primaire. Il peut uniquement remonter une erreur. Le
14geste a voulu être simplifié au maximum car destiné avant tout aux collaborateurs dans les
magasins. En effet, de par leurs connaissances disparates et le peu de temps dont ils disposent,
il était indispensable d’établir un processus simple et rapide. L’action de remontée se fait
par un formulaire, composé de 3 champs, visible fig. 3.2.
Figure 3.2 – Formulaire utilisé par les collaborateurs pour remonter des anomalies de
données produits.
Le champs Référence, qui contient l’identifiant du produit concerné. Le champs Type,
qui permet d’aiguiller le PDP pour la correction et qui permet de faire des statistiques. Pour
l’instant, seuls 5 types sont présents :
— Désignation, pour les problèmes de libellés produit
— Datapack, pour les dimensions des produits emballés
— Visuel, pour les photos de produits
— Documents, pour les documents de conformité comme les notices
— Autre, pour pouvoir spécifier un type qui n’est pas encore disponible dans SOS Data
Ces 5 types ont été trouvés suite aux différents problèmes rencontrés par l’ensemble des
équipes en interne et dans les magasins. Le dernier champ est la proposition, qui se veut être
le champ texte où le collaborateur précise l’erreur rencontrée et renseigne une suggestion de
correction pour le PDP. Le PDP, quant à lui, doit analyser et gérer les remontées d’erreurs
qui sont affiliées à son rayon. Pour cela, il a à sa disposition le tableau en fig. 3.3.Figure 3.3 – Tableau utilisé par les Pilotes Data Produits pour gérer les erreurs de données
produits.
Il peut lire les différents commentaires qui sont envoyés par les collaborateurs et il peut
traiter directement la référence en fonction de son avancement. Bien sûr, l’ensemble des
données affichées peuvent être filtrées. Les actions du PDP se déroulent en trois temps :
une lecture des commentaires écrit par les remonteurs en cliquant sur la petite bulle, puis
une analyse sur le logiciel Step pour bien comprendre le problème et finalement une action
de changement de statut dans SOS Data. Le changement de statut peut être soit de la
suppression de la remontée produit suite à la correction ou soit de la mise en attente car
le PDP peut contacter le fournisseur ou l’assistant produit avant de résoudre la remontée.
Le processus d’analyse et de gestion des erreurs est donc similaire à un outil de gestion
de tickets simplifié où la gestion de statut est utilisée pour gérer au mieux l’ensemble des
remontées.
Cependant, SOS Data diffère sur plusieurs points, comme par exemple sa connectivité
à des sources de données avec les API Leroy Merlin, ou encore son interface permettant de
voir les différentes remontées pour un même produit. En effet, plusieurs remontées peuvent
être faites pour un même produit et SOS Data permet de voir ces remontées simultanément
avec l’affichage de tous les commentaires remontés. Tout cela a été basé sur une architecture
et structure de donnée expliquée ci-dessous.
3.2 La structure de données
Pour SOS Data, il fallait une structure de données légère pour permettre des traitements
rapides et une gestion en masse efficace. Moins il y avait d’associations, plus la structure
allait être simplifiée. C’est dans cet esprit que les différentes classes ont été construites.
D’après le diagramme de classe fig. 3.4, on constate que la classe Dataproduct est la
classe centrale de SOS Data, en effet c’est ce modèle qui représente la donnée centrale du
logiciel. C’est cet objet qui est stocké dans la base MongoDB. Les diverses données associées
à cette classe sont récupérées dans les APIs LM, comme la désignation et le rayon.
La classe Comment permet de représenter le commentaire, avec un type, une date et
les informations de l’utilisateur. Les contenu et type du commentaire sont choisis par le
remonteur. Dans les faits, une grande liste de commentaires sur un Dataproduct montre un
véritable problème.
UserInfo contient les données mises à disposition par le protocole OpenID Connect uti-
lisé par le SSO (expliqué dans la partie authentification), et les données permettant d’iden-
tifier l’utilisateur dans les commentaires.
La classe PartialDataproduct sert uniquement à appliquer des PATCH, pour modifier
partiellement la donnée d’un objet par appel d’API. C’est une classe où chaque membre
est facultatif (seule la référence doit être présente pour identifier le produit car unique), etFigure 3.4 – Diagramme de classe représentant le modèle de données.
permet donc de faire une modification de certains champs précis et non de l’objet en entier.
Par exemple, le frontend a uniquement à envoyer une référence avec le champ qu’il désire
modifier et non l’objet en entier avec uniquement un champ différent. C’est ce qui permet de
faire le changement de statut, seule la référence et le statut voulu sont envoyés. Les autres
propriétés de la classe sont présentes pour de futur fonctionnalités, elles ne sont pas encore
utilisées par le front de SOS Data.
Les classes d’énumération servent à gérer les statuts des produits et les différents types
de commentaires possibles.
La programmation du projet est réactive, c’est donc sensiblement différent de la program-
mation itérative. Cela permet, à travers des Observers, d’effectuer les actions de manière
non concurrente et non bloquante[20]. Le concept de la programmation réactive repose sur
le design pattern Observable - Observer. Des flux émettent des valeurs qui peuvent être
observées de manière continue. Les Flux (ou Mono si une seule et unique valeur est attendue)
peuvent émettre trois types de signaux différents, soit une valeur, soit une erreur, soit un
signal de fin. Dans le cas d’un Flux, l’Observer effectue une action à chaque signal reçu.
Un backend a été développé pour exposer avec ces données.
3.3 Le backend
Le backend de SOS Data est développé en Kotlin, langage de programmation orienté objet
et fonctionnel, permettant de compiler sur une machine virtuelle Java et qui est devenu lepremier langage de programmation Open Source supporté par Google pour les applications
Android. Ce langage a été choisi pour plusieurs raisons :
— La première est que l’architecture applicative est basée sur celle de l’équipe
Colibri, qui ont des librairies développées en Kotlin et Java. SOS Data a donc
une forte dépendance avec ces librairies. Le développer dans le même langage
était donc obligatoire.
— La deuxième raison est les légères performances qu’apportent Kotlin par rap-
port au Java, avec une évolution très intéressante au travers de ses coroutines
et une légèreté syntaxique très appréciable. Notamment à travers l’utilisation
des Data classes, et le fait que cela soit un langage “sûr”, avec une mécanique
de Null Safety efficace et simple à mettre en place.
Spring Boot a été utilisé, permettant un démarrage de projet accéléré, avec un backend
CRUD 1 fonctionnel très rapidement, notamment grâce à la présence d’un Spring Initializr [9]
en interne. Son utilisation a cependant imposé plusieurs points :
(1) Utilisation d’un Router réactif[21] pour gérer les différentes routes, très peu répandue
donc difficile à utiliser de manière exotique. Cependant, les avantages restent intéressants,
voir list. 3.1. Le Router possède une lecture simple et concise grâce à son arbre syntaxique,
on peut clairement comprendre ce que font chaque route avec un nom de fonction clair. Une
action est liée à une route et une fonction du Handler de l’application. Ainsi, quand la route
demandée respecte le prédicat, la fonction associée du Handler est exécutée. Le routeur du
backend contient 8 routes, et la lecture reste limpide sur 15 lignes.
1 fun router ( sosdataHandler : SosdataHandler ) = router {
2 ( accept ( MediaType . APPLICATION_JSON ) and " / product " ) . nest {
3 GET ( " / " , sosdataHandler :: getProduct )
4 POST ( " / " , sosdataHandler :: createProduct )
5 PATCH ( " / " , sosdataHandler :: changeProduct )
6 DELETE ( " / " , sosdataHandler :: deleteProduct )
7 ( accept ( MediaType . APPLICATION_JSON ) and " /{ reference } " )
. nest {
8 POST ( " / " , sosdataHandler ::
createProductWithReference )
9 GET ( " / comments " , sosdataHandler :: getComments )
10 GET ( " / comments / types " , sosdataHandler ::
getCommentsTypes )
11 }
12 }
13 ( accept ( MediaType . APPLICATION_JSON ) and " / products " ) . nest {
14 GET ( " / " , sosdataHandler :: getProducts )
15 }
Listing 3.1 – Exemple de Router réactif.
Visible grâce à la fonction router(), l’architecture est très différente du système d’anno-
tations dans un projet Spring habituel. Par exemple, pour préciser un paramètre de chemin,
il faut préciser la variable voulue entre accolade (voir ligne 7). Les paramètres de requêtes
se gèrent dans les fonctions du Handler.
1. Create, Read, Update et Delete ou Créer, Lire, Mettre à jour, Supprimer.Vous pouvez aussi lire
