La promesse

L'expression « tableau de bord unique » est l'une des plus courantes dans le domaine des logiciels d'entreprise. L'argument de vente est simple et séduisant : toutes vos données, regroupées en un seul endroit, accessibles à tous. Plus besoin de passer d'un système à l'autre. Finis les silos d'informations. Une seule vue, une seule source de vérité, un seul écran.

On dirait la solution miracle à tous les problèmes de coordination. Et pour un ensemble restreint de cas d'utilisation — tableaux de bord de direction, surveillance en temps réel de systèmes homogènes —, cela fonctionne. Lorsque tous les membres de l'équipe ont besoin de consulter les mêmes indicateurs avec le même niveau de détail, une vue unique et unifiée s'avère pertinente.

Le problème, c'est que la plupart des organisations ne fonctionnent pas ainsi. Et certainement pas dans le cadre des opérations sur le terrain.

Là où l'hypothèse s'effondre

Le concept de « tableau de bord unique » part du principe que la transparence est toujours bénéfique — que le fait de mettre davantage d'informations à la disposition d'un plus grand nombre de personnes produit de meilleurs résultats. Cela est vrai jusqu'à un certain point, mais au-delà, cela cesse d'être vrai et devient dangereux.

Séparation concurrentielle. Lorsque plusieurs entrepreneurs travaillent sur un même projet d'infrastructure, ils doivent pouvoir accéder à des couches de base communes : tracés de câbles, emplacements des poteaux, réseau de conduits. Ils n'ont pas besoin d'accéder aux travaux des autres. Le fait que l'entrepreneur A puisse voir l'avancement des travaux de l'entrepreneur B, l'affectation des équipes et la consommation de matériaux constitue une fuite d'informations concurrentielles, et non un gain de productivité. Une interface unique qui affiche toutes les informations pour tous rend ce type de séparation impossible par conception.

Informations adaptées au rôle. Un technicien de terrain chargé de l'installation de câbles doit pouvoir consulter ses missions, la section correspondante de la carte et le matériel qu'il est autorisé à récupérer. Il n'a pas besoin de voir les rapports de validation du contrôle qualité, les calculs de paiement ou les bons de travail attribués à d'autres équipes. Lui montrer tout cela ne l'aide pas à mieux travailler. Cela alourdit sa charge cognitive, sème la confusion et augmente le risque qu'il agisse sur la base d'informations qu'il n'était pas censé voir.

Contraintes réglementaires et contractuelles. Dans les secteurs réglementés — services publics, infrastructures publiques, activités liées au secteur de la santé —, la visibilité des données n'est pas une simple option. C'est une obligation légale. Certains utilisateurs ne doivent pas avoir accès à certains enregistrements. Certaines données ne doivent pas franchir certaines limites. Un système conçu selon le principe que tout le monde a accès à tout doit intégrer ces restrictions a posteriori, et ce sont justement ces restrictions ajoutées a posteriori qui finissent par échouer.

Approche opérationnelle. Lorsqu’un chef de projet examine un projet de déploiement de fibre optique sur une centaine de kilomètres, il a besoin d’informations sur l’avancement global, l’état d’avancement du calendrier et les écarts budgétaires. Lorsqu’un chef d’équipe sur le terrain examine ce même projet, il a besoin de connaître les missions du jour, les rapports de la veille et la disponibilité des matériaux pour la semaine. Lorsqu’un auditeur l’examine, il a besoin du journal des transactions et de la chaîne d’approbation. Offrir la même vue d’ensemble aux trois ne rend service à aucun d’entre eux. Chacun a besoin d'une partie différente des mêmes données, présentée avec le niveau de détail adapté à son rôle.

Le véritable problème que le « Single Pane of Glass » cherchait à résoudre

L'intérêt d'une interface unique ne réside pas réellement dans la visibilité. Il tient plutôt à deux problèmes plus profonds auxquels les organisations sont véritablement confrontées.

Les silos de données. Lorsque les informations sont réparties dans cinq systèmes différents qui ne communiquent pas entre eux, la coordination devient impossible. L'équipe SIG utilise un outil, l'équipe de gestion des tâches en utilise un autre, l'équipe chargée des stocks en utilise un troisième et l'équipe financière en utilise un quatrième. Personne n'a une vue d'ensemble, car les données sont dispersées dans différentes bases de données sans clé commune. Le « tableau de bord unique » promet de remédier à ce problème en regroupant toutes les informations en un seul endroit.

Une vérité incohérente. Lorsqu’un même fait — le nombre de mètres de câble installés mardi — figure dans trois systèmes différents et que chacun indique un chiffre différent, personne ne sait lequel est le bon. Le « tableau de bord unique » promet de remédier à ce problème en servant de source unique de vérité.

Ces deux problèmes sont bien réels. Mais la solution au problème des silos de données ne consiste pas à « tout montrer à tout le monde ». Elle consiste plutôt à « tout stocker dans un seul système et à contrôler qui voit quoi ». Et la solution au problème de l'incohérence des données ne consiste pas à « une seule vue pour tous ». Elle consiste plutôt à « un seul ensemble de données, interrogé différemment selon la personne qui effectue la requête ».

Cette distinction est importante, car elle influe sur ce que vous développez. Un système conçu selon le principe « tout le monde voit tout » doit intégrer des restrictions a posteriori — et ces restrictions sont toujours incomplètes, toujours ajoutées après coup, et c’est toujours elles qui tombent en panne lorsqu’une nouvelle fonctionnalité est déployée. Un système conçu selon le principe « la bonne visibilité pour le bon rôle » intègre dès le départ des contrôles de visibilité et en fait la norme, et non l’exception.

À quoi ressemble une vision juste

L'alternative à une vue d'ensemble unique ne réside pas dans les silos d'informations. Il s'agit plutôt d'utiliser les mêmes données, le même système et la même source de vérité, avec une visibilité adaptée à chaque rôle.

Des couches communes, des tâches distinctes. Deux entrepreneurs travaillant sur le même chantier de déploiement de fibre optique ont accès à la même infrastructure de base : poteaux, gaines, tracés de câbles. Chacun ne voit que ses propres ordres de travail, les affectations de son équipe et ses propres rapports d'installation. Les données sont stockées dans un seul système. La vue d'ensemble diffère.

Séparation des droits d'action et des droits d'accès. Un collaborateur sur le terrain peut se voir accorder le droit de modifier des rapports sans pour autant avoir le droit de consulter ceux de ses collègues. Le droit d'effectuer une action et le droit de consulter des informations sont des contrôles indépendants. Cela signifie que vous pouvez accorder à un collaborateur des droits d'édition complets dans le cadre d'une vue dont le champ d'application est clairement défini — ce qui correspond exactement aux besoins des opérations sur le terrain.

Des restrictions imposées au niveau du serveur, et non un simple masquage dans l'interface utilisateur. Lorsqu'un utilisateur ne doit pas voir un enregistrement, celui-ci n'existe tout simplement pas de son point de vue. Il n'est pas masqué derrière un bouton désactivé. Il n'est pas filtré hors d'une liste. Il n'apparaît pas dans la réponse de l'API. Il n'est pas inclus dans une exportation. Les données sont véritablement absentes — car le contrôle de visibilité est appliqué au niveau du serveur avant que les données ne quittent la base de données, et non dans l'interface une fois qu'elles y sont parvenues.

Des tableaux de bord adaptés aux rôles, issus du même ensemble de données. Le chef de projet visualise l'avancement global. Le responsable de terrain consulte les missions du jour. L'auditeur examine le journal des transactions. Tous trois interrogent les mêmes données sous-jacentes. Aucun d'entre eux n'a accès à l'ensemble des informations. Chacun voit exactement ce dont il a besoin.

Le test du fournisseur

Voici un exercice utile pour évaluer toute plateforme qui promet une vue d'ensemble centralisée : demandez-vous ce qui se passe lorsque deux utilisateurs ne doivent pas avoir accès aux données l'un de l'autre.

Si la solution implique des déploiements distincts — bases de données distinctes, environnements distincts —, cela signifie que la plateforme a été conçue pour offrir une visibilité totale et qu'elle ne peut pas gérer une visibilité partielle sans se fragmenter en silos. Vous avez alors remplacé un problème par un autre.

Si la solution passe par un filtrage au niveau de l'interface utilisateur — masquer des éléments de menu, désactiver des boutons, filtrer les listes —, les données sont toujours présentes, tant dans l'API que dans les exportations. La distinction est purement superficielle. Elle résistera à une utilisation courante, mais ne tiendra pas la route face à un examen minutieux.

Si la solution consiste à filtrer au niveau de la couche applicative, point de terminaison par point de terminaison, alors la barrière est bien réelle, mais fragile. Chaque nouvelle fonctionnalité, chaque nouveau point de terminaison API, chaque nouveau format d'exportation constitue une faille potentielle. La barrière sera efficace le jour de son déploiement, mais elle s'affaiblira à mesure que la base de code s'étoffera.

Si la réponse implique des restrictions imposées par le serveur au niveau des champs, appliquées avant que les données ne quittent la base de données, alors la limite est structurelle. Les nouvelles fonctionnalités en héritent. Les exportations la respectent. Les appels API la respectent. Les données n'existent tout simplement pas pour les utilisateurs non autorisés, quelle que soit la manière dont ils tentent d'y accéder.

La question n'est pas de savoir si la plateforme comporte des restrictions. Toutes les plateformes en comportent. La question est de savoir où se situent ces restrictions — et si elles ont été intégrées dès le départ ou ajoutées a posteriori.

Des chiffres différents, mais tous corrects

Il existe une variante plus subtile du sophisme du « tableau de bord unique » qui persiste même après avoir admis que différents rôles doivent avoir accès à des données différentes. Il s'agit de l'hypothèse selon laquelle il devrait y avoir un seul chiffre — un seul pourcentage d'avancement, un seul statut, une seule réponse — et que tout écart entre les différentes vues signifie qu'il y a un problème.

Dans la pratique, une même analyse, considérée à différents niveaux d'agrégation, donne des chiffres différents, et chacun d'entre eux est correct.

Un ordre de travail peut être considéré comme terminé. Le technicien a récupéré le matériel, installé le câble et soumis son rapport. Du point de vue de cet ordre de travail, l'avancement est de 100 %. Mais cet ordre de travail était l'un des quatre relevant d'une tâche, et cette tâche n'est achevée qu'à 40 % car les trois autres ordres de travail sont toujours en cours. La tâche elle-même est l'une des vingt tâches d'un projet, et le projet est achevé à 12 %. Trois chiffres de progression différents pour le même tronçon de câble physique — et aucun d'entre eux n'est erroné.

Il ne s'agit ni d'une erreur d'arrondi ni d'un problème de rapprochement. C'est la conséquence naturelle du fait d'observer une même réalité sous différents angles. Le chef de chantier s'intéresse à l'ordre de travail : la mission du jour est-elle terminée ? Le coordinateur de projet s'intéresse à la tâche : cette partie du réseau est-elle dans les temps ? Le responsable de programme s'intéresse au projet : atteignons-nous l'objectif trimestriel ? Chacun d'entre eux a besoin d'un chiffre, et le bon chiffre varie d'une personne à l'autre.

Le principe du « tableau de bord unique » consiste à choisir un seul indicateur et à l'imposer à tout le monde. Dans la pratique, cela signifie soit que le responsable de terrain voit un chiffre de 12 % qui ne lui dit rien, soit que le chef de projet voit un chiffre de 100 % qui ne lui donne aucune indication sur le calendrier global. Aucune de ces deux visions n'est erronée. Mais les forcer à s'inscrire dans le même cadre rend les deux inutiles.

Le même principe s'applique horizontalement. Deux sous-traitants travaillant sur le même projet voient des chiffres d'avancement différents, car chacun ne peut voir que l'état d'avancement de son propre travail. Le sous-traitant A en est à 70 %. Le sous-traitant B en est à 30 %. Le maître d'ouvrage voit les deux chiffres, ainsi que le chiffre global. Ces trois points de vue sont tous exacts. Tous trois sont nécessaires. Aucun d'entre eux n'est le « bon » point de vue qui devrait remplacer les autres.

Un système conçu pour afficher la bonne vue en fonction du rôle concerné gère cela naturellement. Les données sont les mêmes. L'agrégation est différente. Les limites de visibilité sont différentes. Et si les chiffres divergent, ce n'est pas parce qu'il y a un dysfonctionnement, mais parce que les questions posées sont différentes — ce qui est exactement normal.

Résumé

Le concept de « tableau de bord unique » part du principe que la transparence est toujours bénéfique — que le fait de tout montrer à tout le monde produit de meilleurs résultats. Dans les opérations sur le terrain, cette hypothèse se heurte à des limites liées à la concurrence, à la nécessité de fournir des informations adaptées aux rôles, aux exigences réglementaires et à la concentration sur les opérations.
Les véritables problèmes que le « tableau de bord unique » tente de résoudre sont les silos de données et l'incohérence des informations. Ces deux problèmes sont bien réels. Mais la solution réside dans un système unique avec une visibilité contrôlée, et non dans une vue unique sans aucun contrôle.
Un système conçu autour du principe « tout le monde voit tout » doit ajouter des restrictions après coup. Un système conçu autour du principe « la bonne vue pour le bon rôle » fait des contrôles de visibilité son fondement.
L'alternative au « tableau de bord unique » n'est pas les silos d'informations. C'est le même ensemble de données, la même source de vérité, avec une visibilité adaptée au rôle — des couches partagées là où la collaboration est importante, des vues séparées là où les limites comptent.
Les contrôles de visibilité appliqués par le serveur avant que les données ne quittent la base de données sont les seules limites qui s'appliquent à tous les chemins d'accès — interface utilisateur, API, exportations et requêtes directes. Tout le reste n'est que cosmétique.
Un même travail vu à différents niveaux — ordre de travail, tâche, projet — produit des chiffres de progression différents, et chacun d’entre eux est correct. Imposer un seul chiffre à tous les rôles rend chaque vue inutile. Des questions différentes méritent des réponses différentes à partir des mêmes données.
Lors de l’évaluation d’une plateforme, la question n’est pas de savoir si elle comporte des restrictions. La question est de savoir si ces restrictions ont été intégrées dès la conception ou ajoutées a posteriori.