Suivre la chaîne d’approvisionnement mondiale, trajet après trajet.

Le défi

Un repère sur cette carte n’est jamais un simple point. C’est une palette de vaccins, un conteneur de produits frais qui court contre la montre, ou une pièce qui arrête une chaîne de production si elle n’arrive pas à temps.

Brambles déplace des actifs physiques à travers plus de chaînes d’approvisionnement que presque toute autre entreprise au monde. Supply Chain Illumination (SCI), la plateforme pour laquelle je conçois, existe pour répondre à une question réellement difficile à cette échelle : où se trouve un actif donné en ce moment, respecte-t-il son planning, et reste-t-il dans un état acceptable, à travers plus de 300 000 chaînes d’approvisionnement et 348 millions d’unités physiques dans plus de 60 pays.

Il a toujours été juste de montrer l’ensemble du réseau en un coup d’œil. Cacher cette échelle aurait été malhonnête sur ce que le produit fait réellement. Le problème le plus difficile, celui pour lequel j’ai réellement dû concevoir, était la rapidité : à quelle vitesse quelqu’un pouvait passer de « voici tout le réseau » à « voici la poignée d’actifs, de sites et de trajets qui ont besoin de moi maintenant ». C’est la même tension que j’ai conçue sur le cas d’étude Discovery : ce qu’un écran montre et ce dont un utilisateur a réellement besoin de savoir sont rarement la même chose, et c’est dans cet écart que se situe le vrai travail de conception.

Montrer l’ensemble du réseau était la partie facile. Le rendre rapide à filtrer jusqu’à l’essentiel était le vrai problème de conception.

Mon rôle

Je porte l’UX des surfaces Carte réseau, Trajets, Visibilité des actifs et Sites sur SCI, en tant que Designer produit principal chez Brambles.

Cela couvre le design d’interaction pour les écrans individuels, les résumés de trajet, les graphiques d’état, les chronologies, les tiroirs de détail des actifs et des sites, ainsi que les règles sous-jacentes qui font tenir le système à grande échelle : ce qu’est un cluster, quand il se décompose lorsqu’un utilisateur zoome, ce que la couleur communique sur l’état d’un actif, et comment ces règles restent cohérentes, qu’on regarde un seul trajet ou l’ensemble du réseau.

Le système de cartographie lui-même a dépassé le cadre de SCI. C’est désormais le langage cartographique partagé derrière cinq produits Brambles, maintenu par 21 membres de l’équipe UX plutôt que par le fichier de conception d’une seule personne : la preuve la plus claire que j’aie qu’un pattern résolvait réellement un problème réel, plutôt que de simplement répondre au cahier des charges d’une seule équipe.

Les cartes de SCI reposent sur Mapbox comme moteur cartographique principal, choisi pour une carte de base stable, de solides performances à grande échelle et un style flexible prenant en charge les thèmes clair et sombre. Mapbox gère le panoramique, le zoom et la fenêtre d’affichage par défaut. Tout ce qu’un utilisateur reconnaît réellement comme « la carte SCI », les repères, les clusters, les lignes de trajet, les panneaux latéraux, est un composant que je conçois et spécifie par-dessus cette base, construit pour rester cohérent avec le Design System de Brambles plutôt que d’hériter des styles visuels par défaut de Mapbox.

J’ai aussi construit ces composants en code, à l’aide d’outils assistés par l’IA, pas seulement dans Figma, afin que lorsqu’un nouvel écran ou une nouvelle fonctionnalité était exploré, sur SCI ou sur un tout autre produit, l’équipe qui puisait dans le système travaillait à partir de quelque chose qu’elle pouvait réellement intégrer et tester, pas une référence statique. Le fichier Figma de référence et la base de code sont maintenus synchronisés délibérément : mettre à jour l’un sans l’autre annule l’intérêt même d’avoir un design system.

Les trois règles ci-dessous, ce qu’est un cluster, ce qu’est un repère, et ce que signifie la couleur, sont le socle sur lequel tout le reste de la carte est construit, ce sont donc celles qui méritent d’être détaillées ici. Le système, dans son ensemble, va bien plus loin : comportement de la fenêtre d’affichage, recherche, les mini-filtres et le panneau de filtres complet, une légende dynamique qui n’affiche jamais que ce qui est réellement visible à l’écran, et les composants de détail des actifs, des sites et de la chronologie que ces repères et clusters ouvrent, sont tous documentés et componentisés de la même façon.

Qu’est-ce qu’un cluster ?

Sur la carte réseau, un cluster regroupe plusieurs actifs ou sites situés à proximité les uns des autres, afin que la carte se lise en un coup d’œil plutôt que de se noyer dans des repères individuels. Les clusters utilisent une iconographie représentant ce qu’ils contiennent réellement, un magasin, un site de fabrication, un mélange de types d’actifs, plutôt qu’un simple point générique, et cette iconographie devient plus précise à mesure que l’utilisateur zoome. En zoomant davantage, les clusters se décomposent en repères individuels d’actifs et de sites, ou en clusters plus petits et plus spécifiques au sein du cluster d’origine.

Que signifie la couleur sur la carte réseau ?

La couleur indique à l’utilisateur dans quel état se trouve un cluster ou un repère avant même de cliquer dessus. Le bleu signifie des actifs en mouvement. Le violet signifie des actifs immobilisés à un site connu et attendu. Le rouge signifie une immobilisation non identifiée, un actif se trouvant quelque part sans raison de l’être, ce qui est souvent le premier signal d’une perte ou d’un vol. C’est délibérément un langage de couleur différent de celui utilisé sur Trajets, car la carte réseau répond à « où se trouve tout et dans quel état », et non à « cet envoi précis est-il dans les temps ».

Qu’est-ce qu’un repère ?

Un actif individuel en mouvement reçoit son propre halo ou repère pulsant, un signal visuel indiquant que quelque chose est en direct et en transit. Une fois qu’un actif cesse de bouger, que ce soit à un site connu ou non identifié, il se regroupe dans un cluster avec le repère de site concerné plutôt que de rester sur la carte comme un point isolé. Nous explorons aussi le dimensionnement des repères d’immobilisation selon la durée pendant laquelle un actif est resté immobile, afin que la carte elle-même puisse un jour répondre à « lequel de ceux-ci est resté trop longtemps », mais ce n’est pas encore livré : c’est une piste que nous testons activement, pas une règle en production.

Qu’est-ce qui change lorsqu’un trajet est affiché individuellement ?

Afficher un seul trajet fait apparaître un niveau de détail que le langage cluster-et-repère ci-dessus laisse délibérément de côté : la ligne polygonale elle-même, des flèches directionnelles le long de celle-ci, un site de départ, des repères de sites d’arrêt, un repère du dernier site vu ou un cercle mobile, des bulles d’information et des repères d’étape. Rien de tout cela ne remplace les règles ci-dessus, c’est le même langage visuel avec le volume monté, car lire un envoi est une tâche différente de lire trois cent mille d’entre eux, et cela nécessite le détail supplémentaire pour être à la hauteur.

Ce ne sont pas des décisions d’interface accessoires. Ce sont les règles qui permettent au même composant de carte de fonctionner qu’il affiche 12 actifs ou 12 000, et elles sont documentées une seule fois, en tant que référence de design system, précisément pour qu’un designer rejoignant une autre surface SCI, ou un tout autre produit Brambles, hérite de la même logique plutôt que de la réinventer.

Les couches, et construire pour la prochaine fonctionnalité avant qu’elle n’existe

Le panneau Couches contrôle ce que la carte affiche. Par défaut, les couches d’actifs et de sites sont toutes deux activées. Désactiver une couche supprime tout ce qui y est associé en une seule action : repères, clusters, filtres, résultats de recherche et entrées de légende, de sorte que la carte n’affiche ni ne filtre jamais des données qu’un utilisateur a délibérément masquées. J’ai depuis prototypé en code une couche dédiée aux immobilisations non identifiées, afin qu’un utilisateur puisse isoler exactement les actifs qui nécessitent le plus une investigation sans d’abord filtrer tout le reste, et Trajets est le prochain type de couche logique à concevoir une fois cela livré.

La version la plus récente des Couches a livré une bascule de projection globe et carte plane : une véritable fonctionnalité d’accessibilité, pas une fioriture visuelle. Certains utilisateurs ressentent une sensibilité au mouvement face à un globe en rotation, et certaines tâches logistiques, planifier un itinéraire, évaluer des distances, sont tout simplement plus faciles sur une projection plane, tandis que d’autres, comprendre la couverture d’un réseau longue distance, se lisent mieux sur un globe. Les deux états sont clairement étiquetés, accessibles au clavier et adaptés aux lecteurs d’écran, et le choix de projection persiste sur toutes les cartes du produit jusqu’à ce que l’utilisateur le change à nouveau. Il en va de même pour le style de carte : quel que soit le style de base choisi, Clair, Sombre, Plein air ou Satellite avec rues, il est retenu comme préférence et reporté sur toutes les autres surfaces cartographiques de SCI, afin que l’utilisateur n’ait pas à le réinitialiser écran par écran.

Concevoir cette bascule a signifié écrire les critères d’acceptation avant même que la fonctionnalité n’existe : ce que « vue globe » et « vue plane » devaient signifier pour un lecteur d’écran, comment le focus devait se déplacer, ce qui devait ou non se réinitialiser lorsqu’un utilisateur bascule. C’est la même discipline que derrière les règles de clusters et de repères ci-dessus : décider du comportement du système une seule fois, par écrit, afin que chaque équipe qui construit dessus hérite du même standard.

Un trajet suit le voyage le plus récent d’un actif : son site de départ, chaque immobilisation entre les deux, et son site final ou actuel. C’est une tâche différente de celle de la carte réseau, donc elle utilise un langage visuel différent. Les lignes de trajet entre les immobilisations sont bleues par défaut, et passent à l’affichage des segments en infraction contre optimaux dès qu’un utilisateur active l’état, afin qu’un client puisse voir exactement où sur l’itinéraire un problème s’est produit, pas seulement qu’il s’en est produit un. Les repères de site sur un trajet suivent la même logique : noirs par défaut, passant au rouge dès qu’une infraction est enregistrée à cette immobilisation précise, que l’actif soit resté immobile ou en mouvement entre deux points.

La page de résumé du trajet a été conçue pour que les deux questions les plus importantes, où se trouve cet envoi, et reste-t-il dans un état acceptable, soient toutes deux répondues sans un seul clic. Itinéraire, point de départ, dernier site vu, durée, et état de température et de choc en direct se trouvent sur le même écran. Le même composant s’adapte ensuite à un résumé compact pour une ligne de tableau, et s’étend à la vue de détail complète du trajet : un seul pattern, plusieurs densités, plutôt qu’un second design construit de zéro pour chaque contexte.

Quand quelque chose a réellement mal tourné, ces mêmes données de température et de choc alimentent le graphique d’état ci-dessous : le trajet complet tracé par rapport à des bandes de seuil optimal, à faible risque et à haut risque, avec un curseur de plage de dates et des contrôles de zoom pour sauter directement au moment où la ligne a été franchie plutôt que de parcourir tout un voyage à l’œil nu. Un pic de choc peut signifier un freinage brusque ou une collision, une montée lente de température peut signifier une unité de réfrigération défaillante ou une porte laissée ouverte sur un long itinéraire, et les mêmes appareils intelligents peuvent signaler un changement inattendu de lumière ou de poids sur une palette stationnaire, un signal que quelque chose a été ouvert ou retiré pendant l’arrêt. Insights on Arrival, un module SCI distinct, répond à la question connexe mais différente de l’état d’un envoi à son arrivée à destination finale, en utilisant ces mêmes données sous-jacentes.

Chronologie du trajet

La vue chronologie répond à « que s’est-il réellement passé sur ce trajet » avec une carte d’itinéraire, des arrêts numérotés, le temps d’immobilisation à chacun, et des repères d’incident placés directement sur la carte plutôt qu’enfouis dans un journal. Une vue journal séparée existe pour lorsque quelqu’un a réellement besoin de la séquence brute des événements, mais la carte reste le moyen principal de comprendre un voyage, car un itinéraire avec un repère rouge dessus raconte une histoire plus rapide qu’un tableau ne le fera jamais.

La chronologie verticale sur la carte a aussi un équivalent horizontal, une bande routière compacte qui se trouve directement sous le graphique d’état sur l’écran de résumé du trajet. Même logique d’immobilisation et de site, disposée de gauche à droite plutôt que de haut en bas : une barre violette marque la durée d’immobilisation à chaque arrêt, et une icône de camion marque la position actuelle de l’actif, bleue en mouvement, violette immobilisée, verte une fois livrée, phares allumés uniquement quand il est réellement en transit. C’est un petit composant, mais c’est ce qui permet à quelqu’un lisant un pic de température sur le graphique ci-dessus de voir, du même coup d’œil, si l’actif était garé à un arrêt ou réellement en mouvement quand cela s’est produit.

Un trajet est aussi composé de tronçons, le chemin entre deux sites quelconques sur celui-ci, et explorer les tronçons décompose l’itinéraire en ces segments individuels, Tronçon 1, Tronçon 2, Tronçon 3 et ainsi de suite, chacun portant son propre statut en infraction ou conforme plutôt qu’un seul verdict pour tout le trajet. Un trajet avec un seul mauvais tronçon sur six ne devrait pas se lire comme un trajet qui a échoué du début à la fin. Sur la carte, un tronçon est marqué par son propre repère carré, positionné au centre de la ligne polygonale de ce tronçon plutôt qu’à un site, afin qu’un utilisateur puisse identifier d’un coup d’œil quel segment il regarde. Sélectionner un tronçon garde la carte et la liste chronologique synchronisées, afin qu’un utilisateur puisse passer d’un tronçon sur l’itinéraire à son détail dans la liste sans perdre sa place.

Un flux est un voyage régulier que le produit d’un client effectue sur nos palettes, une usine vers un magasin, un entrepôt vers un centre de distribution. Un itinéraire est une façon de réellement faire fonctionner ce flux, usine directement au magasin est un itinéraire, usine via un entrepôt puis un centre de distribution est un itinéraire différent pour le même flux, et la plupart des flux en ont plusieurs. Un trajet est une instance unique et achevée de l’un de ces itinéraires, à une date donnée, avec un actif donné. Même couloir d’expédition, trois angles différents : un flux vous dit si le couloir dans son ensemble est sain, un itinéraire vous dit quel chemin à travers celui-ci est le plus rapide ou le plus lent, et un trajet vous dit ce qui s’est réellement passé lors d’un voyage.

Ouvrir un flux le décompose en ses itinéraires, chacun étant le même couloir emprunté d’une manière différente, avec ses propres sites concernés et ses propres temps de cycle et d’immobilisation les plus rapides, les plus lents et moyens. C’est là que se situe la comparaison utile : deux itinéraires desservant le même flux, l’un systématiquement plus rapide, et désormais cette différence est visible et attribuable plutôt qu’enfouie dans une seule moyenne mélangée.

Aucun des deux écrans n’a encore de carte, et c’est délibéré plutôt qu’un oubli, tout ce qui précède reste un travail de liste et de tableau, pas un travail spatial. C’est le prochain défi de conception cartographique sur ce produit : le même langage de clusters, de repères et de lignes de trajet vu plus tôt dans ce cas d’étude, appliqué un niveau au-dessus, afin que les immobilisations d’un itinéraire et un tronçon sous-performant soient aussi visuellement évidents sur une carte que l’infraction d’un seul trajet l’est déjà.

Actifs et Sites existent aussi comme des modules autonomes, des listes recherchables exactement de ce qui est déjà placé sur la carte réseau, pour les utilisateurs opérationnels qui pensent d’abord en liste et ensuite en carte. Aucun des deux modules n’invente un nouveau pattern pour y parvenir : le même langage de recherche, de tri et de filtrage se reporte depuis Trajets et Flux, de sorte qu’un utilisateur ayant déjà appris à travailler avec une liste sait déjà travailler avec celles-ci.

Une ligne dans l’une ou l’autre liste n’est pas une impasse. Cliquer sur un site ouvre le même écran de site qu’un repère sur la carte réseau ouvre, limite, adresse et métriques de mouvement sur une carte en direct. Cliquer sur un actif ouvre directement la chronologie de voyage de cet actif, le même voyage qu’un utilisateur atteindrait en cliquant sur son repère sur la carte. Liste et carte sont deux portes vers les mêmes pièces, pas deux fonctionnalités séparées à construire et maintenir.

Illuminate bascule la carte réseau vers un mode sombre à fort contraste conçu pour regarder de nombreux trajets à la fois plutôt qu’un seul. Chaque trajet à l’écran s’affiche selon son état, en infraction en rouge, optimal en vert, afin qu’un responsable de chaîne d’approvisionnement parcourant l’ensemble du réseau puisse voir où les problèmes se concentrent sans ouvrir un seul trajet pour vérifier. C’est le même langage rouge contre vert que ce cas d’étude utilise depuis une seule ligne de trajet, simplement pointé sur quelques centaines d’envois simultanément plutôt qu’un seul.

Zoomer sur une zone spécifique conserve le même langage de couleur mais ajoute un moyen de l’affiner : un filtre d’état bascule la carte entre les trajets optimaux, en infraction ou tous, et une liste de trajets à droite regroupe tout ce qui est actuellement visible par statut, non expédié, immobilisé, en mouvement, livré, afin qu’un responsable de chaîne d’approvisionnement puisse passer de « où sont les problèmes » à une liste filtrée et dénombrable sans quitter la carte.

Afficher autant de trajets à la fois change ce qu’est réellement la prochaine vue utile. L’étape suivante évidente est la cartographie thermique, regrouper la densité des infractions par géographie afin qu’une région avec un nombre disproportionné de trajets rouges se distingue d’un coup d’œil, le même principe « le repérer avant que ce ne soit un ticket » que le langage de clusters et de repères plus tôt dans ce cas d’étude, appliqué à l’échelle du portefeuille plutôt qu’à un seul envoi. C’est encore précoce, une bascule et un langage de couleur éprouvés au niveau du trajet, pas encore un produit de carte thermique achevé, mais c’est la direction que la carte veut naturellement prendre une fois que des données d’état existent pour chaque trajet d’une chaîne d’approvisionnement, pas seulement celui que quelqu’un a ouvert par hasard.