Près de 50% des projets data ne sont jamais utilisés ou restent au stade du POC. Qu’est-ce que cela dit de notre façon de faire de la data aujourd’hui ?
Dans beaucoup d’organisations, la data est encore pensée par et pour les équipes data, avec une approche très technologique. On a une tendance à empiler des outils, des dashboards, des solutions, qui deviennent finalement des applications supplémentaires, sans réel ancrage dans le quotidien métier. Le succès est encore trop souvent mesuré à la livraison technique, et pas à l’usage réel ou à l’adoption. On investit énormément, mais on peine à démontrer un ROI tangible.
Pourquoi l’approche produit semble-t-elle être la bonne grille de lecture pour adresser ces sujets d’adoption ?
Dès qu’on parle produit, on parle automatiquement d’utilisateur et d’expérience. Un produit n’existe que s’il est utilisé. Il n’y a pas d’autre critère de succès. Cela nous oblige à nous poser des questions simples mais fondamentales : à qui s’adresse-t-on ? Quels problèmes concrets cherche-t-on à résoudre ? À quel moment du process métier intervient-on ? Penser la data comme un produit, c’est accepter que la data n’a pas de valeur intrinsèque, mais qu’elle en crée par l’usage. Cela nous rapproche des logiques déjà bien maîtrisées côté digital et produit, mais encore peu courantes côté data.
Si on applique l’UX à la data, de quoi parle-t-on concrètement ?
Quand on parle d’UX en data, ce n’est pas simplement pour faire joli ou avoir une belle interface. C’est pour rendre la donnée compréhensible, accessible et surtout actionnable dans le quotidien d’un utilisateur. L’objectif n’est pas que l’utilisateur fasse de la data pour le plaisir, mais qu’on l’aide à mieux faire son métier grâce à la donnée.
Cela implique plusieurs choses : oublier le jargon data (clusters, modèles, scores) et adapter le wording au langage métier. Il faut aussi simplifier les parcours. Personne n’a envie d’un outil où il faut cliquer cinquante fois là où deux suffiraient. L’idéal, c’est de réussir à ne quasiment rien changer à la façon de travailler de l’utilisateur.
Quel constat as-tu fait sur la data chez Accor à ton arrivée ?
Chez Accor, et notamment à la centrale d’achat où j’interviens, comme dans beaucoup d’entités, il y avait une forte dépendance à la data, mais une réelle difficulté à démontrer le retour sur investissement généré. L’idée a été de changer d’angle d’attaque : passer d’une logique de projet data à une logique d’usine qui pense et fabrique des produits et des applications, avec de vraies règles d’utilisabilité.
Ces règles étaient simples : des applications créées en moins de 5 mois pour ne pas perdre le fil du besoin, des coûts de développement inférieurs à 60 000 euros, un point mort de rentabilité atteint en 6 mois et, surtout, un use case avec un retour sur investissement mesurable. Sans cela, l’initiative est stoppée et on passe à la suivante.
Comment identifiez-vous les bons cas d’usage ?
Quoi qu’il arrive, il faut qu’il y ait un besoin métier exprimé, extrêmement tangible, qui s’inscrive dans un process opérationnel existant. L’exemple que j’utilise souvent : les équipes commerciales ont besoin de data non pas pour de la data, mais pour mieux vendre, mieux cibler leurs clients, mieux les closer. C’est vraiment dans les process existants que viennent s’inscrire nos applications pour aider à faire mieux les choses, sans rien changer autour.
Quel rôle jouent les métiers dans la conception des data products ?
On a systématiquement un Owner Data et un Owner Business. En co-construction, les deux sont également responsables du succès du produit. C’est une vraie co-responsabilité. Les deux avancent ensemble. Et en bout de course, on peut intégrer un designer qui vient travailler les interfaces, fluidifier l’expérience ou simplifier encore l’accessibilité de l’outil. C’est un double chantier : un co-ownership en matière de construction, et une simplification à l’extrême de la partie interfaçage.
Une fois le data product conçu, comment travaillez-vous son adoption ?
Ma source d’inspiration, ce sont les applications mobiles. On construit des écosystèmes sur des périmètres d’applications extrêmement réduits et simples, avec l’idée de créer des synergies entre elles. On a une vraie logique de vie du produit : on publie des nouvelles, des release notes concises pour expliquer ce qu’on ajoute au fur et à mesure. On fait vraiment vivre l’application dans le temps.
Peux-tu nous donner un cas emblématique ?
Dans les équipes commerciales d’une centrale d’achat, les clients envoient des jeux de factures et demandent de prouver que vous êtes moins cher que leurs fournisseurs actuels. Une facture de 100 à 150 lignes peut prendre entre 3 et 4 heures de travail, et les commerciaux en reçoivent des dizaines par an. On avait estimé que ce type de tâche consommait jusqu’à 10 000 heures de travail par an par commercial.
On a répondu avec une application qui permet d’importer automatiquement une facture, d’en extraire le contenu, de calculer les économies potentielles pour le client s’il travaillait avec nous, et même de lui proposer des recommandations d’optimisation. À la fin, l’écran affiche le montant d’économie que le client va réaliser. Résultat : entre 10 000 et 15 000 heures économisées par an.
Et il y a même une V2 en préparation ?
Exactement. Aujourd’hui, les équipes commerciales priorisent les plus gros clients. Demain, l’idée est de rendre cette application accessible en self-care sur le web, pour que chaque client puisse faire ses propres simulations et constater qu’en travaillant différemment, il pourrait économiser. Cela nous permettra de capter de nouveaux leads, de récupérer de la donnée marché, de construire des benchmarCs, et de créer ce fameux cercle vertueux. Et tout cela ne fonctionne que s’il y a une UX simple, accessible, qui facilite l’usage.
👉 Suivez Christophe sur Linkedin
