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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Introduction 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. 1
Chapitre 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. 2
Figure 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.3
Figure 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 pour
tous 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. 9
seulement 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 de
la 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 14
geste 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), et
Figure 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 le
premier 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