La Grosse Conf 2024 - La recette secrète pour échouer vos projets de data

Marine Dussaussois est convaincue que c’est par l’échec qu’on retient le plus de leçons. Le titre de sa présentation n’a pas été choisi au hasard, elle nous parle bien de projet data et non de produit data. Mais pourquoi cela ? En effet, depuis 2010, l’approche produit est largement adoptée dans le développement de produits numériques mais assez peu dans nos écosystèmes data. Alors, est-elle adaptée au monde de la data ? Dans un premier temps elle va confronter l’approche projet et l’approche produit. Ces 2 approches ne sont pas nécessairement opposées, le choix est à définir en fonction du contexte. D’après Marty Cagan, gourou du Product Management, la différence entre projet et produit se résume à l’objet sur lequel l'équipe va se concentrer. Dans le cas du produit on se concentre sur l’utilisateur et dans le cas du projet sur le métier. Marine insiste sur le fait que se concentrer sur l’utilisateur n'exclut pas la prise en compte du business model de l’entreprise mais considère plutôt que la valeur apportée à l'utilisateur bénéficiera à celui-ci.

Projet versus Produit : Quelles différences?

Temporalité :

• Projet : Début, milieu et fin bien identifiés. Phase de cadrage suivie de la livraison, mais pas d'itérations.
• Produit : Début et milieu identifiés, mais la fin n'est pas déterminée. Phase de cadrage, delivery, phase d’itération tant que des demandes d'évolution existent, puis phase de run.

Mesure de la réussite :

• Projet : Respect de la timeline et réponse à la demande initiale.
• Produit : Résultat basé sur les métriques définies en amont avec les métiers, atteignant le niveau attendu.

Ressources utilisées :

• Projet : Ressources bien définies car le périmètre est clairement délimité.
• Produit : Les ressources varient car les fonctionnalités ou évolutions à développer sont évolutives. Par exemple, en fonction du retour utilisateur, le choix de développer une fonctionnalité plutôt qu'une autre peut nécessiter des ressources supplémentaires.

Finalement, la première erreur que l’on pourrait faire est d'utiliser la mauvaise approche. Marine propose un exemple concret pour illustrer ses propos.

Dans ce cas fil rouge, nous nous situons dans le secteur de la grande distribution avec une entreprise fictive, Food4People, qui opère plusieurs supermarchés à travers la France. L'entreprise a lancé sa transformation digitale il y a trois ans, avec pour objectif de démontrer la valeur de l'IA dans ce secteur. Le directeur de l'innovation vise à améliorer les performances économiques en rendant les employés "augmentés" par l'IA.

Le premier cas d’usage sélectionné concerne les chefs de rayon des supermarchés. Chaque chef de rayon, responsable d'un rayon spécifique du magasin, est chargé non seulement d'animer son rayon, mais aussi de gérer les stocks. Les analystes ont révélé que le stock dormant et les frais de pénurie représentent environ 5% du chiffre d'affaires annuel de chaque magasin. L'enjeu majeur est donc d'anticiper au mieux les ventes de chaque article pour ajuster les commandes et optimiser les stocks disponibles. Et quoi de mieux qu’un modèle de ML pour prédire tout ça ?

Marine a eu l'occasion de voir de nombreux projets data. Cela lui a permis de déduire les facteurs de réussite clés, mais aussi d'échec. Avec humour, elle nous présente donc sa recette secrète pour échouer un projet data.

Concevoir la solution en ne prenant pas en compte le quotidien de l’utilisateur:

Contexte du cas fil rouge : Un cadrage avec les chefs de projet et les experts techniques a permis d'imaginer la solution. Après 10 mois de delivery, les équipes ont réussi à implémenter un modèle de forecasting de stock. Ce modèle a été mis à disposition au travers d’une application sur les nouveaux smartphones des chefs de rayon qui n’étaient jusqu’à présent pas équipés de téléphones. Le premier chef de rayon reçoit son nouveau smartphone mais il n’arrive pas à se connecter à l’application car il n’y a pas de connexion dans la réserve. Les équipes n’ont pas pris en compte les contraintes du quotidien de leurs utilisateurs dû à la distance physique entre les équipes de dev (situées à Paris) et le chef de rayon (situé en Gironde). Pour ne pas reproduire ces erreurs, que faut-il faire ?

Marine Dussaussois - PO Data chez OCTO Technology à la Grosse Conf’

• Concevoir autour des utilisateurs ici les chefs de rayon, et être proche des utilisateurs de façon générale.

Marine nous expose 3 méthodes de conception centrées sur les utilisateurs issues du monde de l’UX design que tous les profils data devraient savoir utiliser.

• L’entretien : Une méthode qualitative qui permet d’échanger avec l’utilisateur sur son environnement, son contexte afin de comprendre ses besoins, ses frustrations et ses contraintes. L'idée est de poser des questions ouvertes aux utilisateurs.
• Le questionnaire est une technique de collecte de données quantifiables qui se présente sous la forme d’une série d’items auxquels les interrogés doivent répondre. Ces items peuvent être des questions, mais aussi des affirmations à catégoriser.
• L'expérience map et le blueprint consistent à représenter tous les parcours utilisateurs d’un produit pour avoir une vision holistique de l’écosystème. Nous pouvons utiliser ces méthodes pour comprendre les processus quotidiens des utilisateurs, leurs irritants et leurs besoins.

Ces 3 méthodes nous permettent de favoriser l’utilité et l’utilisabilité de nos produits dès la phase de cadrage. Mais elles ne sont bien sûr pas suffisantes pour garantir l’utilisation de nos produits.

• Livrer de la valeur de façon incrémentale à vos utilisateurs et prendre en compte leurs retours au fil de l’eau.

La deuxième raison qui a mené au premier retour du chef de rayon, est liée à la façon dont les équipes tech ont mené le delivery. Les équipes se sont uniquement basées sur les éléments de cadrage pour développer et valider les développements sans jamais faire de test utilisateur. Si les utilisateurs avaient été intégrés dans la phase de delivery nous ne serions pas passés à côté de certaines précisions du besoin et d’évolution de demande pertinente.

Concevoir un produit data en ne prenant pas en compte l'utilisabilité du produit

Contexte du cas fil rouge : Une fois le réseau rétabli dans la réserve, le chef de rayon qui peut maintenant utiliser son application de prédiction de stock se rend compte qu’il ne comprend pas ce que représentent les prédictions ni comment elles ont été obtenues. Il est sceptique et a du mal à faire confiance à ces chiffres puisqu’il ne les comprend pas. Le manque de confiance pourrait amener à ce qu’il n’utilise pas cette application. Pour ne pas reproduire ce cas de figure il faut :

• Fournir des explications supplémentaires autour des résultats du modèle de ML qui améliorent la compréhension de l’utilisateur (ce que représentent les données, comment ont été obtenues les prédictions, etc.)
• Accompagner les utilisateurs une fois la solution livrée, par exemple lorsqu’ils ont des questions ou des retours.

Pour ne pas reproduire cet échec, il est important de distinguer utilité, utilisabilité et utilisation. Un produit doit d’abord être pensé en fonction de son utilité, mais cela ne suffit pas :

”Pour que cette utilité soit réalisée, il faut qu’il soit utilisé, et pour qu’il soit utilisé, il est préférable qu’il soit utilisable.”

L’utilisabilité est définie selon 3 notions : l’efficacité (capacité à atteindre l’objectif souhaité), l’efficience (capacité à atteindre l’objectif au prix d'une consommation optimale de ressources) et la satisfaction (capacité à atteindre l’objectif de façon agréable).

Voici quelques facteurs clés qui peuvent favoriser cette utilisabilité:

• La compréhension : si je comprends les chiffres affichés sur ma courbe alors j’ai plus de chance d’atteindre rapidement mon objectif. La compréhension peut être également favorisée par l’ergonomie de l’interface (ajout de bulle d’information par exemple).
• La transparence peut être un facteur de compréhension et de confiance : si je comprends les variables sur lesquelles le modèle s’est basé, alors je comprends le résultat et je fais confiance aux prédictions.
• Afin de renforcer cette confiance, privilégions la co-construction avec nos utilisateurs. Cela permet à la fois à l’équipe de s’assurer que le modèle prend en compte les variables qui semblent cohérentes à nos utilisateurs et d’augmenter les chances d’adoption.
• La conduite du changement vient renforcer l'utilisabilité au travers l’accompagnement des utilisateurs via des sessions de Q&A, des formations, des guides d’utilisation, etc.

Concevoir un produit data sans alerting & monitoring

Contexte du cas fil rouge : Quelques jours plus tard, le chef de rayon s’aperçoit que la courbe de prédictions de stock d’aujourd’hui est identique à celle d’hier. En parallèle, l’équipe tech investigue et décide de ne pas informer les utilisateurs du bug car ils risqueraient de ne plus avoir confiance en leur application.

Pour éviter cette situation, on cherche à concevoir une solution fiable. La fiabilité d’un produit passe par de l’alerting et du monitoring. Marine décline l’intérêt de l’alerting et le monitoring selon 3 axes : pour les utilisateurs, pour les équipes tech, par les utilisateurs.

Pour les utilisateurs : l’alerting pour les utilisateurs permet d’alerter les utilisateurs en cas d’anomalie sur les données (ex : fraîcheur de la donnée, disponibilité de la donnée…). Cette transparence, contrairement à ce que nous pourrions penser, est un facteur de confiance pour les utilisateurs.

Pour les équipes tech : l’alerting pour les équipes tech permet aux équipes d’être alertées en cas de bug ou d’anomalie sur les flux de données. Cela permet d’être réactif en cas d’anomalie impactant pour les utilisateurs.

Par les utilisateurs : on peut mettre à contribution nos utilisateurs pour monitorer la pertinence des prédictions. Obtenir du feedback rapidement et régulièrement permet d’anticiper le ré-entraînement d’un modèle d’IA par exemple, mais aussi de détecter une mauvaise compréhension du modèle qui impacterait l’usage de notre solution à terme.

Ne pas piloter l’usage de son produit dès la conception

Contexte du cas fil rouge : Le directeur de l’innovation décide de recontacter le chef de rayon pour confirmer que ce projet est une avancée révolutionnaire pour les chefs de rayon. Mais depuis déjà plusieurs mois plus aucun d’entre eux n’utilise l’application dans le magasin, en partie pour toutes les raisons que nous avons vu précédemment.

” Il faut distinguer un produit utilisé et un produit dit utilisé.”

Le pilotage de l'usage nous permet de :

• Mesurer factuellement l'usage au travers de métriques pertinentes. Par exemple dans notre cas fil rouge le nombre de connexions par jour, les pages les plus consultées, le temps moyen passé sur l'application.
• Détecter les changements de comportement de nos utilisateurs dans l'usage de notre produit. Cela nous permet de rapidement réagir et de demander aux utilisateurs ce qui ne convient plus dans le but de l’améliorer.

Le pilotage de l'usage se base sur des données utilisateurs. Il existe des outils comme Google Tag Manager, Google Analytics, Matomo qui permettent de tracker les utilisateurs. Cependant, attention à bien respecter le RGPD. Finalement, le pilotage de l'usage doit être pensé dès le cadrage de vos solutions puisqu'il nécessite la mise en place de certaines briques techniques.

Take Away

Pour terminer, Marine Dussaussois nous rappelle les points suivants pour assurer que vos produits data soient utiles, utilisables, utilisés et adoptés:

• Tous les profils des équipes de développement doivent être proches des utilisateurs pour comprendre et répondre au mieux à leurs besoins et attentes.
• La mise en place d'une boucle de feedback rapide dans tout le cycle de vie du produit est essentielle pour augmenter l'impact de nos produits et favoriser la co-construction quand le contexte le permet.
• Enfin il faut penser à piloter l'usage même après la phase de delivery pour s'assurer que nos produits évoluent correctement dans le temps.