Contexte
Back-office e-commerce, secteur Retail. La contrainte de départ : faire évoluer le produit sans jamais couper le service à ceux qui l'utilisaient déjà tous les jours.
realisations/3:Project
Lumen Retail
- Client
- Back-office e-commerce
- Secteur
- Retail
- Stack
- Angular · .NET
Résultat clé-62%temps de saisie
Le projet
Back-office Angular repensé autour du parcours opérateur, avec .NET & SQL Server.
Notre approche
Back-office Angular repensé autour du parcours opérateur, avec .NET & SQL Server.
Résultats
-62% sur « temps de saisie ». Derrière ce chiffre : une base de code couverte par des tests, une documentation à jour dans le dépôt, et une équipe interne capable de reprendre la main.
Stack technique
Réalisé avec Angular, .NET, sur une chaîne d'intégration et de déploiement continue montée avec le projet. Les technologies ont été choisies pour ce contexte-là, pas parce que nous les préférons.
Le problème d'ingénierie
Un back-office se juge sur une seule chose : le nombre de gestes nécessaires pour accomplir la tâche la plus fréquente. Tout le reste — l'esthétique, la richesse fonctionnelle, la modernité de la technologie — est secondaire pour quelqu'un qui traite le même écran deux cents fois par jour.
Le piège classique est de refondre en partant des fonctionnalités existantes, puisqu'elles sont documentées et rassurantes. On obtient alors la même application en plus joli, avec le même nombre de gestes. La refonte n'a servi à rien et coûte le prix d'une refonte.
Les décisions qui ont compté
Observer avant de dessiner
Nous regardons des opérateurs travailler avant de proposer quoi que ce soit, et cette observation contredit presque toujours ce que la direction décrit. Les gens développent des contournements — un second onglet ouvert en permanence, un tableur parallèle, un ordre de saisie non prévu — et ces contournements sont la meilleure spécification qui existe.
Ce qu'on cherche est le geste répété, pas la fonctionnalité manquante. Une fonctionnalité manquante se réclame ; un geste inutile répété deux cents fois par jour ne se réclame jamais, parce qu'on a fini par le considérer comme normal.
Le clavier avant la souris
Sur un poste de saisie, chaque passage à la souris coûte plus qu'il n'y paraît : il faut quitter le clavier, viser, revenir, retrouver sa position. Un parcours entièrement praticable au clavier n'est pas une exigence d'accessibilité seulement, c'est une exigence de débit pour la personne qui l'utilise à longueur de journée.
Cela impose des choix qui vont à l'encontre des habitudes du web grand public : un ordre de tabulation pensé, des raccourcis, une validation qui enchaîne sur la ligne suivante plutôt que de revenir à un tableau. Et cela rend l'application accessible par construction, sans qu'on ait eu à en faire un chantier séparé.
Ne pas confondre rapidité perçue et rapidité mesurée
Une opération qui répond en trois cents millisecondes mais qui vide l'écran pendant ce temps paraît plus lente qu'une opération d'une seconde qui laisse tout en place et signale son avancement. La perception dépend de la stabilité visuelle autant que du temps réel.
Nous appliquons donc la mise à jour optimiste sur les actions dont l'échec est rare et réversible : l'écran réagit tout de suite, et corrige si le serveur refuse. Sur les actions à conséquence, jamais : là, l'attente explicite est préférable à l'annulation d'un affichage auquel l'utilisateur a déjà cru.
Ce que ce type de projet apprend
- Les contournements des utilisateurs sont la meilleure spécification disponible.
- Un parcours clavier complet sert le débit avant de servir l'accessibilité.
- La stabilité visuelle pèse autant que le temps de réponse mesuré.
- Refondre à fonctionnalités constantes produit la même application en plus joli.
Ce que le chiffre annoncé mesure
Les 62 % portent sur le temps de traitement d'un dossier par un opérateur formé, sur la tâche la plus fréquente. C'est un gain sur un geste précis et répété, pas sur l'ensemble du travail : les tâches rares n'ont pas été optimisées, certaines ont même été rendues un peu plus longues au profit des fréquentes, ce qui était l'arbitrage voulu. Le chiffre ne dit rien non plus de la période d'apprentissage, pendant laquelle un opérateur habitué à l'ancien écran est temporairement plus lent.
Et ce qu'il ne mesure pas. Un indicateur qu'on n'explique pas ne vaut rien.
Continuer:Project[3]
Autres réalisations
Un projet en tête ? Donnons-lui vie.
Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.