Refondre un outil interne que ses utilisateurs connaîtront toujours mieux que moi. Le produit est sous accord de confidentialité ; le raisonnement, lui, se raconte entièrement.
Confidentialité : aucun écran, aucun nom et aucun détail du produit ne figurent sur cette page. Ce qui suit ne décrit que des activités de conception.
Un outil interne conçu à la fin des années 2000 et jamais vraiment repensé depuis, utilisé tous les jours par un petit nombre de personnes formées. Pas de nouveaux arrivants à convaincre, pas de tunnel d’acquisition : des gens qui ouvrent le même écran chaque matin et qui savent exactement où cliquer.
Le produit est couvert par un accord de confidentialité. Ce qui suit ne décrit ni ce qu’il fait, ni pour qui : uniquement les décisions de conception, qui sont les mêmes sur n’importe quel outil de ce type.
Le premier réflexe face à un écran chargé, c’est de retirer. Sur un outil d’expert, retirer coûte cher : ce qui paraît du bruit à un œil neuf est souvent l’information que l’utilisateur cherche en premier. J’ai commencé par comprendre pourquoi chaque élément était là avant d’en enlever un seul.
Ces utilisateurs ont des automatismes construits sur quinze ans. Déplacer une commande, c’est leur faire réapprendre un geste. J’ai changé la forme sans déplacer les repères : mêmes emplacements, même vocabulaire, même ordre de lecture.
Un écran ouvert quarante fois par jour ne se juge pas à la première impression mais à la centième. Ce qui compte, c’est le nombre de clics d’une tâche répétée, pas l’accueil du nouvel arrivant.
Sur un outil métier, les cas limites ne sont pas des exceptions : ce sont des situations quotidiennes. Chargement, résultat vide, saisie incomplète, erreur récupérable. Je les ai dessinés au même niveau de soin que les écrans nominaux.
Impossible de refondre un outil d’expert depuis un fichier Figma. La conception a commencé par des sessions d’observation et des entretiens avec les utilisateurs, pour relever ce qu’ils font réellement plutôt que ce que la documentation décrit. C’est là qu’on découvre les contournements, et un contournement est toujours le symptôme d’un manque.
Un outil ancien porte des contraintes qu’on ne voit pas depuis l’interface. Les ateliers ont servi à trancher ce qui était modifiable, ce qui ne l’était pas, et ce qui pouvait attendre une deuxième étape. Chaque arbitrage a été documenté, pour qu’on sache pourquoi une décision a été prise six mois plus tard.
Composants documentés avec leurs variantes, leurs états et leurs règles d’usage, remis directement aux développeurs. Puis recette des écrans intégrés et suivi des corrections jusqu’à la mise en service.
Un parcours complet repris de bout en bout, sans déplacer les repères des utilisateurs. Des composants documentés remis aux développeurs, les états et les cas limites compris. Un suivi jusqu’à la mise en service.
Une refonte menée du cadrage à la recette, sur un outil dont les utilisateurs n’avaient rien demandé et tout à perdre. La réussite ne se mesurait pas à l’effet produit, mais à une absence : celle de la période où l’on est moins efficace qu’avant.