Rouvrir une application métier de 1998 à ceux qui n'osaient plus s'en servir.
Une refonte complète de l'outil de requêtes de la supply chain Renault, conçue pour tenir dans les systèmes existants sans développement back-end supplémentaire.
- 1998
- l’année de lancement de l’application encore en service au moment de la refonte
- Sans aide
- le critère d’arrêt : les profils qui évitaient l’outil exécutaient une requête complexe seuls
- Développée
- l’application a été développée conformément à la conception, puis déployée
Le contexte
Les équipes supply chain de Renault ont besoin d’interroger la flotte de véhicules en permanence : gérer les stocks, suivre la production et les livraisons, repérer les besoins de maintenance ou de rappel. Une requête type ressemble à ceci : tous les véhicules d’un modèle donné, dans une couleur de carrosserie donnée, avec ou sans une garniture intérieure, destinés à un pays, entre deux dates.
Pour cela ils utilisaient Pilotage Web, une application lancée en 1998 et toujours en service. Au fil des années elle était devenue si difficile à manier que la productivité en souffrait. Le travail se faisait dans une mosaïque de petites fenêtres qui se recouvraient, héritée des interfaces de son époque.
L’objectif tenait en une phrase : refondre l’application pour améliorer son adoption et la productivité de ceux qui s’en servent. Avec trois contraintes. Des utilisateurs aux besoins et aux niveaux d’expertise très éloignés. Un délai court. Et surtout, une conception qui devait s’intégrer aux systèmes existants sans développement back-end supplémentaire : je pouvais réorganiser l’accès aux données, pas les données.
Deux profils, un seul outil
Avant d'interroger qui que ce soit, j'ai appris à me servir de l'outil moi-même.
La phase d’immersion n’était pas une formalité. Après une formation pratique, je savais construire une requête complexe. Sans cela, je n’aurais pas pu observer un utilisateur travailler et comprendre ce qui le bloquait, ni discuter d’égal à égal avec des gens qui font ça tous les jours.
Six entretiens individuels, en présentiel, en deux temps chacun. D’abord des questions sur le profil, l’expérience de l’outil, les besoins et les difficultés. Ensuite une requête complète à exécuter sur l’application, en pensant à voix haute, que je reprenais étape par étape pour récolter ce qui ne sort jamais d’une question directe.
Deux profils se sont détachés nettement, et c’est le résultat qui a orienté toute la conception.
Le débutant se sent perdu et délègue
« Je me sens perdu parmi les multiples fenêtres et options. » Il peine sur les requêtes simples, demande de l'aide dès que ça se complique, et finit par éviter l'outil en confiant ses requêtes à un collègue.
L'expert y arrive, et paie pour tout le monde
« Je suis habitué à cette interface, mais elle reste frustrante. » Il sait tout faire, et passe une part de ses journées à former et dépanner les autres. Le goulot d'étranglement n'était pas seulement l'outil, c'étaient les quelques personnes capables de s'en servir.
J’ai restitué cette recherche en cartes d’empathie plutôt qu’en personas. Avec six entretiens et un délai court, elles permettaient de montrer les constats recueillis sans prétendre décrire toute la population. Elles se lisent en une minute et sont restées le support de la conception.
Les décisions qui ont fait la refonte
Trois décisions structurelles, prises pour répondre à ce que les entretiens avaient montré.
Une requête se lit de gauche à droite, sur un seul écran
J'ai d'abord identifié les quatre étapes réelles de construction d'une requête, puis posé la mise en page dans cet ordre chronologique. Plus de fenêtres qui se recouvrent : la construction reste fixe à gauche, le tableau de résultats occupe la droite et s'ajuste à l'écran, avec un mode plein écran quand il faut lire les données.
Les conditions logiques deviennent des objets qu'on manipule
C'est là que les utilisateurs échouaient. Inclusion, exclusion, addition étaient des concepts abstraits enfouis dans des menus. Elles deviennent des blocs visuels, empilés et reliés, qu'on assemble à la main. La même liste de critères produit alors des requêtes différentes selon la façon dont on les combine, et cette différence se voit.
Un UI kit créé de zéro, minimaliste, en deux fonds
L'interface était visuellement datée, ce qui pesait surtout sur les débutants. J'ai créé l'identité et les composants, et divisé l'écran en deux registres : la construction de la requête sur fond blanc, les résultats sur fond sombre. Deux fonds, deux activités : on sait toujours de quel côté on travaille.
Sélection des données
- Choix de la table à interroger
- Recherche dans les champs disponibles
Filtrage et conditions
- Filtres sur toute la requête
- Inclusion, exclusion, addition
- Facultatif
Configuration des colonnes
- Choix des colonnes à extraire
- Préréglages réutilisables
Résultat
- Lecture du tableau
- Vue plein écran
- Export
Tests, validation et suivi
À partir des premiers wireframes, j’ai enchaîné des tests rapides et itératifs sur un prototype interactif : une requête à exécuter, des retours, une correction, un nouveau test. Le critère d’arrêt n’était pas mon avis sur les maquettes, c’était le débutant. J’ai finalisé la refonte quand les différents profils, y compris ceux qui évitaient l’outil, exécutaient la requête sans aide.
Le concept a ensuite été présenté aux équipes de direction et de développement, qui l’ont approuvé, puis transmis aux développeurs pour implémentation.
Je ne me suis pas arrêté à la passation. Déjà intégré à ma mission suivante chez Renault Digital, j’ai continué à mi-temps pendant deux mois sur Pilotage Web pour suivre le développement avec les développeurs et le Product Owner, et veiller à ce que l’implémentation reste fidèle à la conception. À l’issue de ces deux mois, l’application était développée conformément au design, puis déployée.
Ce que j'en retiens
Le problème n’était pas que l’application soit laide ou vieille. Il était qu’elle avait créé une dépendance : une poignée d’experts portaient les requêtes de tout un service, et le reste de l’équipe avait renoncé. Une refonte qui aurait seulement modernisé l’apparence n’aurait rien changé à ça.
Ce qui a réglé le problème, c’est d’avoir rendu visibles les opérations logiques que l’ancienne interface demandait d’imaginer. Le débutant n’a pas eu besoin d’apprendre l’inclusion et l’exclusion : il les a vues, et il les a déplacées.
C’est aussi la mission où j’ai commencé à rester après la remise des maquettes. Deux mois à mi-temps à côté des développeurs, des années avant mes premiers prototypes React. Sur cette mission, ce suivi a permis de vérifier que l’implémentation restait fidèle à la conception.