Être propriétaire du tableau de bord, pas locataire.

Le défi

Les tableaux de bord destinés aux clients de Brambles étaient construits de deux façons, et aucune des deux ne nous appartenait vraiment. Certains vivaient dans Power BI, fonctionnels mais jamais tout à fait adaptés à la manière dont les clients de SCI travaillaient réellement. Le reste tournait sur Brix, un système de tableaux de bord interne construit sur le backend d'un fournisseur tiers, et les frais de ce fournisseur avaient fini par atteindre un niveau que l'entreprise n'était plus disposée à payer.

C'est une forme de problème bien connue : une capacité dont dépend l'entreprise, adossée à une relation fournisseur qui n'a plus de sens commercial. La véritable opportunité n'était pas seulement de « le construire moins cher ». C'était d'utiliser la fenêtre de renouvellement du contrat fournisseur comme le moment pour construire une expérience de tableau de bord que les clients pourraient réellement façonner eux-mêmes, avec nos données, notre frontend, par paliers d'abonnement, plutôt qu'un produit figé livré par un fournisseur.

Avant que cette reconstruction ne puisse commencer, il y avait d'abord un travail plus court et plus restreint à faire : passer les tableaux de bord Brix existants en marque blanche pour leur donner l'apparence propre à SCI, afin que les clients vivent un produit cohérent pendant que le véritable système se construisait en coulisses. J'ai piloté cette transition, en la gardant rapide et visuellement cohérente avec SCI, précisément pour qu'elle n'ait pas à devenir une histoire à part entière. Cela a acheté le temps dont la vraie construction avait besoin.

L'opportunité n'était pas un tableau de bord moins cher. C'était un tableau de bord que nos clients pouvaient réellement construire eux-mêmes.

Mon rôle

J'ai dirigé le design produit du système de tableaux de bord personnalisables pour SCI, en travaillant avec les équipes UX, recherche, implémentation et relation client, ainsi que directement avec l'ingénierie, pour le faire passer des briques de base à un produit livré et par paliers.

Cela couvrait le socle du système de design sur lequel repose toute la construction : les composants de graphique, de tableau et de métrique à partir desquels les tableaux de bord sont assemblés, les flux de création, d'édition et de personnalisation d'un tableau de bord, et la fonctionnalité qui détermine ce qu'un client donné est réellement autorisé à construire, selon son palier d'abonnement. Avec une échéance serrée, j'ai fait venir Dmytro, l'un des designers les plus solides avec qui j'ai travaillé, sur les composants de visualisation de données comme collaborateur proche plutôt que comme simple passation ; nous avons co-créé cette partie ensemble, et travaillé étroitement avec les équipes d'implémentation et de relation client pour valider ce dont les utilisateurs sur le terrain, au bureau comme à l'usine, avaient réellement besoin qu'un tableau de bord leur dise d'un coup d'œil.

Chaque tableau de bord SCI, quel que soit le palier ou l'audience pour lequel il est construit, est assemblé à partir du même ensemble de composants sous-jacent : blocs de graphique, blocs de tableau et blocs de métrique, chacun avec son propre ensemble de variantes selon le type de donnée et le niveau d'urgence qu'elle porte. Un responsable de chaîne d'approvisionnement qui scrute un problème a besoin d'une lecture différente de celle de quelqu'un qui prépare une synthèse de performance mensuelle pour une réunion client, la bibliothèque de blocs devait donc servir les deux sans devenir deux systèmes distincts.

C'est là que je me suis le plus appuyé sur des outils assistés par l'IA, non pas pour remplacer la réflexion de design, mais pour accélérer le pur volume de variantes dont a besoin une véritable bibliothèque de composants. Vu l'échéance, j'ai fait venir Dmytro pour co-créer avec moi les composants de visualisation de données, et ensemble nous avons utilisé des outils assistés par l'IA pour développer les blocs de graphique, de tableau et de métrique dans Figma, afin qu'une petite équipe puisse produire un ensemble de briques de base réellement large, avec leurs états, dans le temps que l'échéance du contrat permettait réellement.

Les blocs de tableau et de métrique suivaient la même logique : un composant, plusieurs densités et états, plutôt qu'un tableau sur mesure construit pour chaque écran. Une tuile de métrique qui affiche un seul chiffre doit se comporter de la même façon qu'elle rapporte la livraison à temps d'un seul site ou d'un flux entier, donc les états, correct, à risque, en infraction, ont été conçus une fois et réutilisés partout où un chiffre devait porter un verdict, pas seulement une valeur.

Rien de tout cela n'était de la construction de composants pour le plaisir. Chaque bloc existait parce que les équipes d'implémentation et de relation client avaient validé un vrai besoin utilisateur derrière lui, en travaillant directement avec les personnes qui construisent au quotidien des tableaux de bord pour Walmart, Costco et Tesco, et avec les archétypes à l'autre bout de la chaîne : un analyste de bureau qui a le temps d'explorer un tableau, et quelqu'un sur le terrain d'une usine qui a besoin d'un seul chiffre pour lui dire, d'un coup d'œil, s'il doit agir.

Voici la bibliothèque complète, chaque variante de métrique, de tableau et de graphique, leurs tailles et leurs états, exactement comme documentés dans Figma. Cliquez dessus et utilisez le défilement ou le pincement pour zoomer, glissez pour vous déplacer.

Les clients n'étaient pas censés partir de rien. Selon leur palier d'abonnement, un client pouvait se voir remettre un tableau de bord de départ déjà construit, puis le personnaliser, ajouter une tuile, en retirer une, remplacer un graphique par un tableau, ou en construire un entièrement nouveau à partir de la même bibliothèque de blocs. En interne, les account managers disposaient de la même capacité de construction, de sorte qu'un tableau de bord dont un client avait un besoin urgent n'avait pas à attendre un ticket d'ingénierie.

La segmentation par paliers n'a pas été ajoutée après coup. Ce qu'un client donné pouvait construire, partir d'un modèle plutôt que construire de zéro, un ensemble limité de blocs plutôt que la bibliothèque complète, faisait partie intégrante de la conception des flux dès le départ, car c'est ce qui a permis à l'entreprise de proposer un produit véritablement différencié à chaque niveau d'abonnement, plutôt qu'une seule expérience de tableau de bord verrouillée derrière un mur payant.

Modifier un tableau de bord existant suivait la même logique de briques de base, mais à l'envers : sélectionner une tuile, changer ce qu'elle affiche, la redimensionner, ou la supprimer, sans jamais quitter le tableau de bord lui-même pour un écran de configuration distinct. Cela comptait plus qu'il n'y paraît. Un client en pleine conversation avec ses propres parties prenantes devait pouvoir remodeler ce qu'il regardait sur l'instant, pas soumettre une demande et attendre.

Tout ce qui précède est le résumé. Voici ci-dessous les deux flux Figma complets qui s'y cachent, chaque état, cas particulier et annotation, exactement comme ils ont été conçus. Cliquez sur l'un ou l'autre et utilisez le défilement ou le pincement pour zoomer, glissez pour vous déplacer.

Une fois les briques de base Figma en place, produit, UX et ingénierie travaillaient directement à partir d'elles, en construisant le frontend en React, en utilisant Claude dans VS Code pour transformer rapidement un composant documenté en code fonctionnel : construis-moi une page, ajoute cette tuile, connecte ce flux. C'est ce flux de travail qui a permis à la bibliothèque de blocs de devenir un vrai produit en semaines plutôt qu'en mois, sans l'écart habituel entre ce qui était conçu et ce qui était livré.

Ce flux de travail est devenu encore plus rapide une fois que la bibliothèque de composants Figma elle-même a été synchronisée avec une bibliothèque de composants de code équivalente à l'intérieur du même AI Playground. Chaque bloc de graphique, de tableau et de métrique du Chapitre 01 existait déjà comme un pattern nommé et documenté des deux côtés, design et code, si bien qu'ajouter l'un d'eux à une page de tableau de bord a cessé d'être une petite tâche de construction pour devenir un simple prompt : ajoute un graphique en barres ici, remplace cette tuile par une carte de métrique, ajoute un tableau en dessous. Le Playground ne devine pas à quoi ce composant doit ressembler. Il lit le même bloc que celui déjà défini par le système de design.

La force de cela ne tient pas au fait qu'elle supprime l'ingénierie, mais qu'elle supprime l'écart entre un composant validé du système de design et une page fonctionnelle. Une tuile de graphique, de tableau ou de carte de métrique qui signifiait autrefois un petit ticket de construction ne prend plus que quelques secondes, et parce que chaque tuile provient toujours de la même bibliothèque synchronisée plutôt que de code ponctuel, cette vitesse ne coûte pas la cohérence que la construction parallèle du Chapitre 04 a bien failli coûter. C'est la même discipline que pour le reste de cette construction, appliquée un prompt à la fois.

Brambles testait alors le développement accéléré par l'IA de façon plus large, et l'un des volets de ce test a produit une seconde version de la construction du tableau de bord, construite rapidement avec des outils d'IA, mais en dehors du système de design et sans les patterns UX déjà validés et en production. C'est une erreur facile à commettre, précisément parce que l'IA supprime la friction qui obligeait autrefois à un point de contrôle : construire un système parallèle de zéro prenait autrefois assez longtemps pour que quelqu'un se demande s'il devait exister. Avec l'IA, ce n'est plus le cas, si bien que la divergence peut être livrée avant que quiconque ne s'en aperçoive.

Le résultat est arrivé aux équipes d'implémentation comme quelque chose qui semblait terminé mais qui n'était pas utilisable. C'est la preuve la plus claire et la plus directe que j'aie qu'un système, aussi vite qu'il vous permette d'avancer, ne mérite sa vitesse que si ce qu'il produit reste cohérent.

Je m'y suis opposé directement, non pas pour défendre un fichier de design pour lui-même, mais parce qu'une version fonctionnelle et validée existait déjà, et que la reconstruire de zéro à côté coûtait à l'entreprise un temps réel face à une échéance client. J'ai pris la décision de ramener la construction parallèle sous le même système plutôt que de la laisser continuer à dériver, j'ai réuni de nouveau autour de la même table le product owner, le lead engineer et Dmytro, et j'ai obtenu le soutien nécessaire pour combler l'écart rapidement sans faire glisser l'échéance qu'elle avait mise en péril. La solution n'était pas de ralentir le développement assisté par IA. C'était de le pointer vers le système qui fonctionnait déjà.

J'ai dirigé personnellement ce réalignement, en m'impliquant directement dans la construction accélérée par l'IA elle-même plutôt qu'en la relisant après coup, en travaillant aux côtés du product owner et du lead engineer, et avec Dmytro de retour sur les composants de visualisation de données, pour m'assurer qu'elle s'appuyait sur la même bibliothèque de composants, les mêmes blocs Figma et les mêmes patterns UX validés que tout le reste sur SCI. C'est la vraie différence entre l'IA comme raccourci pour contourner un bon processus et l'IA comme accélérateur de ce processus : le même outillage, pointé vers un système plutôt qu'à côté, avec quelqu'un responsable de ce choix.

Une fois ce réalignement effectué, les chiffres avec lesquels l'équipe d'implémentation vivait se sont inversés. Les tableaux de bord qui prenaient jusqu'à six heures à construire, et qui n'étaient toujours pas justes, sont tombés à quelques minutes, parce qu'assembler une page à partir de composants validés et documentés est un travail fondamentalement plus rapide que de rétro-concevoir un pattern UX à partir de zéro à chaque fois, assisté par IA ou non.

La bibliothèque de composants n'est pas non plus restée cantonnée à ce seul projet. Trois autres produits Brambles ont depuis adopté les mêmes composants de tableau de bord et la même UX de personnalisation pour construire leurs propres tableaux de bord, et la bibliothèque elle-même a été intégrée au système de design officiel de Brambles, non pas comme une poignée de composants atomiques tels que des boutons et des champs de saisie, mais comme des patterns complets : les blocs de graphique, de tableau et de métrique, et les flux d'assemblage, d'édition et de personnalisation d'un tableau de bord, à partir desquels d'autres équipes peuvent désormais construire des fonctionnalités directement plutôt que de les concevoir de zéro.