Commencer la BI par un rapport, pas par un entrepôt de données
Un programme BI qui démarre par l'architecture met un an avant de servir à décider. Partir du premier rapport utile inverse l'ordre, et le risque avec lui.
Le réflexe est compréhensible : avant de produire des rapports, il faut bien des données propres, donc un entrepôt, donc une architecture, donc un schéma cible. Chaque étape découle de la précédente, et personne ne voit à quel moment le raisonnement dérape.
Il dérape au début. Un programme BI qui commence par l’architecture demande un an avant qu’un décideur voie quoi que ce soit - et pendant cet an-là, le budget se dépense contre une promesse.
Ce que « commencer par un rapport » veut dire
Pas produire un rapport bâclé sur des données douteuses. Choisir une question à laquelle quelqu’un doit répondre chaque semaine, et remonter depuis elle jusqu’aux données qu’elle exige.
Cette question borne tout le reste. Elle dit quelles sources sont concernées, quelle fraîcheur suffit, quelle qualité est nécessaire - et surtout, tout ce qui n’est ni l’un ni l’autre et peut attendre. Une architecture construite de cette façon grandit sous la pression de rapports réels, jamais d’hypothèses.
L’ordre inverse produit des modèles complets et magnifiques dont personne ne consomme la moitié.
Ce que ça donne dans la durée
Sur le cas dont je tire cette note, la BI a été montée depuis zéro dans l’infrastructure du client, puis des demandes sont venues, une par une, au fil des besoins d’ajout et d’évolution. Aujourd’hui : plus de vingt rapports Power BI en service, une gestion des accès par rôle (RLS), et des tableaux de bord qui couvrent l’ensemble de l’organisation.
Aucun de ces rapports n’était prévu dans un plan initial. Chacun a été chiffré et facturé séparément, au forfait. Il n’y a jamais eu de contrat de régie à consommer - le client revient parce que le précédent rapport a servi, pas parce qu’un budget court encore.
Pourquoi un prix par rapport, et pas au forfait global
Parce que ça vous laisse partir.
Un rapport, un périmètre, un prix. Vous pouvez vous arrêter après le premier : rien ne vous engage sur les suivants. Ce détail change la nature de la décision - commencer ne demande plus d’être convaincu du programme entier, mais d’un seul sujet utile.
Et pour moi, ça impose une discipline saine : si le premier rapport ne sert pas, il n’y en a pas de deuxième. Le modèle me rend responsable de son utilité, pas seulement de sa livraison.
Sur Power BI, et sur ce qui n’en dépend pas
C’est l’outil que je maîtrise le mieux, et le moins cher quand vous êtes déjà sous licences Microsoft. Si votre parc dit autre chose, le travail en amont ne change pas : collecte, modèle, qualité des données. La couche de restitution est la partie visible, elle n’est pas la partie longue.
La question de la sécurité, à poser tôt
Le RLS - la restriction des lignes visibles selon le rôle de l’utilisateur - n’est pas un raffinement de fin de projet. Il détermine la façon dont le modèle est construit, et le rétro-ajouter sur un modèle qui l’ignorait coûte une refonte.
Si vos rapports concernent des personnes, des sites ou des clients dont tout le monde ne doit pas tout voir, cette question vient avant le premier rapport, pas après le dixième.