BO sans BO ?

Le rapport est prêt. Il est juste, il est à jour, il est dans BO. La personne qui doit le lire n’a pas de licence. C’est à cet instant précis que se décide la façon dont vos données vont circuler.

Dans la plupart des organisations, une poignée de gens travaillent dans la plateforme décisionnelle et beaucoup d’autres en consomment les résultats. La direction générale, le DAF, les chefs de service, les élus, parfois un partenaire extérieur. Ils n’ont pas de licence, ils n’en auront pas, et ils ont besoin des chiffres.

La solution retenue ne sort pas d’un comité d’architecture. Elle est choisie dans l’urgence, par la personne chargée de fournir les chiffres.

Le PDF du lundi matin

C’est la solution la plus répandue, de loin. Elle ne coûte rien et fonctionne immédiatement.

Le fichier est figé à l’export : il est déjà périmé lorsqu’il arrive. Ce point est connu. Le réflexe qu’il installe l’est moins : comme personne n’a envie de refaire douze versions du même document, on exporte large. Toutes les entités, toutes les lignes, tout le détail, au cas où. Quelqu’un qui voulait trois indicateurs se retrouve avec l’intégralité du périmètre dans sa boîte mail.

Le fichier circule ensuite librement : transféré à un collègue, enregistré sur un poste, imprimé, déposé dans un répertoire partagé. Six mois plus tard, il est impossible de dire combien d’exemplaires existent ni où ils se trouvent.

L’export Excel

Les mêmes limites que le PDF, avec un fichier cette fois réexploitable : il se retravaille, se recoupe, se combine avec d’autres.

Le coût principal se paie en réunion. Le rapport officiel annonce un chiffre, le classeur retravaillé en annonce un autre, et la séance se consacre à les départager plutôt qu’à décider.

Acheter des licences

Sur le plan de la gouvernance, la solution est irréprochable : chaque lecteur est identifié, ses droits sont ceux qui lui ont été attribués, ses consultations sont tracées, et la donnée ne quitte pas la plateforme.

La difficulté est ailleurs. Une licence coûte le même prix pour celui qui construit les univers et pour celui qui consulte un tableau de bord trois minutes par mois. S’y ajoutent la création des comptes, la gestion des habilitations et l’accompagnement d’utilisateurs occasionnels. Dans les faits, cette option dépasse rarement un cercle restreint, ce qui conduit à la suivante.

Recopier les données ailleurs

Un outil de visualisation tiers est alimenté par un extrait, les tableaux de bord y sont reconstruits, et des accès en consultation sont ouverts à l’ensemble des lecteurs. L’interface est moderne, les utilisateurs sont satisfaits, le sujet semble traité.

Ce que cette solution apporte avec elle :

• une deuxième copie des données à sécuriser, sauvegarder et garder cohérente avec la première ;
• un deuxième annuaire d’utilisateurs, avec ses propres droits, généralement moins fins que ceux d’origine ;
• une chaîne d’alimentation supplémentaire, qui devient un point de rupture de plus ;
• un éditeur supplémentaire, avec ses conditions, ses tarifs et parfois un hébergement qu’on ne maîtrise pas.

Surtout, la sécurité au niveau ligne, les profils et la traçabilité — tout ce qui a été paramétré côté BO — ne franchissent pas l’export. Ce qui arrive dans l’autre outil est un jeu de données nu, dont les règles d’accès sont entièrement à réécrire.

La cinquième option

Ces quatre solutions reposent sur le même présupposé : pour montrer un tableau de bord à un utilisateur sans licence, la donnée devrait sortir de la plateforme, dans un fichier ou dans un autre outil.

Ce présupposé peut être levé. N4V Publisher génère, depuis un rapport WebI et sur votre infrastructure, un tableau de bord HTML5 publié sur un serveur web : filtres, navigation et graphiques restent à la main du lecteur. Sans licence SAP supplémentaire et sans recopie dans une plateforme tierce.

Le rapport reste maintenu dans WebI, avec vos univers et vos calculs. Ce qui est diffusé en est généré. Rien de nouveau n’entre dans le parc applicatif.

Les cinq options côte à côte

Publier plutôt qu’envoyer

La différence avec les quatre solutions précédentes ne tient pas à la qualité du rendu. Elle tient au fait qu’il n’y a rien à envoyer.

Le tableau de bord est généré en HTML et mis à disposition sur un serveur web. Le lecteur ouvre une adresse, comme il ouvrirait une page de l’intranet. Ce n’est pas une pièce jointe, c’est une publication.

Les conséquences sont concrètes. Il n’existe qu’une version : pas d’exemplaires dispersés dans des boîtes aux lettres, pas de copies oubliées sur des postes. Cette version se met à jour au rythme du rapport qui la produit, donc personne ne raisonne sur les chiffres du mois dernier. Et lorsqu’un accès n’a plus lieu d’être, il suffit de dépublier la page — il n’y a pas à courir après des pièces jointes déjà transférées trois fois.

L’accès, lui, relève de votre infrastructure : le serveur, le réseau, les règles d’authentification que vous y appliquez. Les mêmes que pour n’importe quelle application interne.

Le périmètre diffusé se définit à la génération : on publie ce dont le destinataire a besoin, pas l’intégralité du détail. Reste donc une décision à prendre en amont, celle du découpage des publications par population. C’est le seul vrai travail de cadrage que demande la méthode.

Ce que révèle un état des lieux

Lorsque nous menons cet état des lieux avec un client, deux chiffres surprennent presque toujours : le nombre de personnes qui lisent les indicateurs sans jamais ouvrir la plateforme, et le nombre d’exports planifiés qui partent chaque semaine vers des destinataires dont plus personne ne tient la liste.

Aucune des quatre solutions décrites plus haut n’est une erreur : ce sont des réponses raisonnables à un besoin réel. Elles n’ont simplement jamais été chiffrées. Et il existe une cinquième voie, qui évite d’arbitrer entre le confort des lecteurs et le contrôle des données.

×