Projet B.I Solution Upgrade

Un outil de pilotage devenu un obstacle

Nexans, acteur mondial du câble, pilote son activité commerciale depuis un fichier Excel de dix-huit pages. Le système est lent, illisible, et n'absorbe plus l'évolution des besoins. Il faut parfois une calculatrice pour retrouver un chiffre que le tableau devrait donner.

Les temps de chargement atteignent trente minutes. Les sauvegardes et mises à jour quotidiennes deviennent une corvée à part entière. À plusieurs reprises, des business units entières se retrouvent à l'arrêt, incapables d'ouvrir le fichier. Après des remontées répétées, la direction décide de migrer vers une solution Power BI.

Transformer l'Excel en un outil moderne. Réduire les temps de chargement. Voilà ce qu'on me demandait de regarder.

Posé ainsi, c'est un problème de migration technique : porter des données existantes vers une meilleure interface, avec de meilleurs temps de réponse.

On savait tout afficher, et rien décider

J'avais un accès complet aux utilisateurs — directeurs de business unit, managers commerciaux, commerciaux terrain — pour de la recherche qualitative et quantitative. Ce qui remonte des entretiens est plus troublant qu'un problème d'ergonomie.

Les utilisateurs peinent à formuler leur besoin. Pas par incompétence : parce que l'outil les a formés à consulter des chiffres, jamais à poser des questions. La complexité du système a créé une déconnexion — beaucoup l'évitent purement et simplement, et ceux qui l'utilisent y cherchent une information sans savoir ce qu'ils en feront.

Côté produit, la rigidité de l'architecture rend chaque demande d'évolution coûteuse. Côté métier, ajouter une vue ou intégrer un jeu de données représente un investissement tel que la business unit y renonce. Le système est figé et cher, et chaque itération le fige davantage.

Mais le motif commun, à tous les niveaux, est ailleurs. On avait construit un outil qui part de la donnée disponible et cherche ensuite à quoi elle pourrait servir. Jamais l'inverse. Personne ne s'était demandé quelles décisions cette organisation devait prendre, ni de quoi elle avait besoin pour les prendre.

On ne concevait pas un outil de décision. On concevait un affichage de données, en espérant que les décisions suivraient.

Le déplacement tient en une bascule : passer d'une approche data-driven à une stratégie business-centered, data-informed. On ne part plus de ce qu'on peut mesurer, mais de ce que l'activité a besoin de trancher — et la donnée redevient un moyen au lieu d'être le sujet.

Les Atomic Metrics, ou comment faire dire aux gens ce qu'ils cherchent à savoir

Le problème pratique était le suivant : si les utilisateurs ne savent pas exprimer leur besoin en données, on ne peut ni les interroger frontalement, ni décider à leur place.

D'où la méthode des Atomic Metrics. Chaque métrique reçoit une carte d'identité qui pose quatre questions : à quoi elle sert, comment elle se construit, à quoi elle se relie, comment elle pourrait se visualiser. En atelier, les participants complètent ces cartes ensemble — et ce faisant, ils rendent visibles leurs priorités, les relations entre les indicateurs, et les questions qui comptent vraiment pour eux.

Le résultat n'est pas une liste de KPI. C'est une base partagée à partir de laquelle se dessinent les pages du BI, sa navigation et sa logique de données. Une carte dit non seulement ce qu'on veut mesurer, mais où cette mesure doit apparaître et comment on interagira avec elle.

On ne demande pas aux gens quelles données ils veulent. On construit avec eux ce qu'ils cherchent à savoir.

Une métrique seule finit toujours par mentir

Concevoir depuis les décisions plutôt que depuis les données fait surgir un problème que l'ancienne approche masquait : une bonne métrique ne se contente pas de mesurer, elle oriente. Et dès qu'elle oriente, elle devient une cible — donc elle se dégrade.

C'est la loi de Goodhart : quand une mesure devient un objectif, elle cesse d'être une bonne mesure. Ce n'est pas un accident, c'est une propriété. Dès qu'un indicateur devient le point de focalisation unique, les équipes trouvent des moyens de l'optimiser — souvent au détriment de la qualité, de l'éthique ou du long terme.

La réponse que j'ai construite ne consiste pas à trouver la métrique parfaite, mais à ne jamais en laisser une seule décider.

Un moteur seul avance sans direction ; une boussole seule indique sans avancer. Ce qui produit la justesse n'est ni l'un ni l'autre, mais la tension entretenue entre les deux. C'est ce couple qui structure les cartes de métriques, et à travers elles, tout le système.

Un outil que les équipes s'approprient, et qui grandit avec elles

La refonte s'est traduite par une architecture d'information qui suit les décisions plutôt que les tables de données : cinq pages centrales communes à tous, et trois pages adaptées aux besoins propres de chaque business unit. Une hiérarchie de l'information lisible, un filtrage puissant, et la fin des tableaux encombrés au profit d'une vue d'ensemble immédiate.

Côté produit, une V1 conçue pour se répliquer : la structure s'adapte à chaque business unit sans être reconstruite, les fonctionnalités sont priorisées selon les besoins réels, et la structure de données a été reprise pour rester utilisable dans la durée.

Au-delà des chiffres, le changement le plus notable est ailleurs : les équipes ont cessé de subir l'outil. Les goulots d'étranglement opérationnels ont disparu, les coûts liés au traitement des données ont baissé, et la qualité de la donnée s'est améliorée d'elle-même — parce que chacun savait enfin à quoi elle servait.