Un distributeur de pièces automobiles à Casablanca fait construire huit écrans Power BI : ventes par famille de produits, marge par client, rotation du stock, encours clients. La recette est signée sans réserve, la formation dure deux heures, chacun repart avec ses accès. Six semaines plus tard, le directeur commercial prépare encore sa réunion du lundi à partir d’un export Excel qu’il retouche à la main, et le contrôleur de gestion a ressorti son propre fichier de marge.
Le cas est composite, reconstitué à partir de situations fréquentes plutôt que tiré d’un client précis, mais le mode d’échec est bien réel. Les projets BI ne meurent presque jamais sur un défaut technique. Ils meurent parce qu’au bout de quelques semaines, plus personne n’a de raison impérieuse d’ouvrir l’outil.
Les quatre causes qui reviennent le plus souvent sont identifiables avant la signature, et chacune se traduit soit par une clause de devis, soit par un contrôle à faire trente jours après la mise en production.
Trois mois après la mise en production, Excel est de retour
Le retour au tableur ne se fait pas d’un coup. On commence par « vérifier » un chiffre du tableau de bord dans Excel, puis on garde le fichier de vérification parce qu’il est plus rapide à filtrer, puis la réunion se tient sur le fichier. Au bout d’un trimestre, le tableau de bord sert à une seule chose : rassurer la direction sur le fait qu’il existe.
Ce qui rend ce glissement difficile à détecter, c’est qu’un tableau de bord délaissé ne produit aucun ticket. Le prestataire n’entend plus parler de rien et prend le silence pour une réussite. Pendant ce temps, une connexion tombe, un filtre par défaut reste bloqué sur l’exercice précédent, une famille d’articles créée dans l’ERP n’est rattachée à aucun regroupement. Personne ne le signale, parce que personne n’en dépend.
Le choix de l’outil n’y change pas grand-chose. Le débat Excel ou Power BI se joue avant le projet. Quand le tableur revient après la livraison, le problème n’est plus un problème d’outil.
Le livrable n’est pas le tableau de bord, c’est la décision
Si l’on cherche sérieusement pourquoi un tableau de bord échoue, la réponse se trouve presque toujours dans la phrase qui n’a jamais été écrite dans le cahier des charges : quelle décision cet écran doit-il permettre de prendre, qui la prend, et à quel moment de la semaine ou du mois.
Une formulation utile ressemble à ceci : « lundi 9h, en comité commercial, décider quels clients relancer en priorité cette semaine ». Cette phrase contraint tout le reste. Elle impose des données à jour le lundi matin, pas le mardi. Elle impose une liste de clients classée, pas une courbe de chiffre d’affaires. Elle désigne un utilisateur précis plutôt que « la direction ».
L’inverse est vrai aussi : un indicateur qui n’alimente aucune décision identifiée n’a pas besoin d’être construit. C’est désagréable à entendre quand on a passé trois ateliers à le définir, mais il coûtera plus cher à maintenir qu’il ne rapportera.
Erreur n°1 : construire la demande au lieu de la décision
Un client demande « le chiffre d’affaires par commercial et par mois ». Le prestataire le livre, correctement. Sauf que la question réelle derrière la demande était : quels commerciaux sont en retard sur leur objectif annuel, et combien de temps leur reste-t-il pour se rattraper. Ce n’est pas le même écran. Le premier donne un historique, le second suppose un objectif, un prorata temporel et un écart.
Un prestataire expérimenté pose donc la question deux fois : ce que vous voulez voir, puis ce que vous ferez différemment selon ce que vous voyez. Quand la deuxième réponse n’existe pas, il faut le dire pendant le cadrage, pas pendant la recette.
Erreur n°2 : personne n’est responsable du tableau de bord après la livraison
Dans la plupart des devis BI, la responsabilité du prestataire s’arrête à la signature du procès-verbal de recette. Côté client, elle n’a souvent jamais commencé. Résultat : quand le plan comptable évolue, quand un commercial quitte l’entreprise, quand l’ERP ajoute un champ ou qu’une nouvelle gamme apparaît, personne n’a le mandat de mettre le modèle à jour.
Le propriétaire doit être une personne interne nommée, avec un nom dans le devis ou dans le compte rendu de cadrage. Son rôle tient en quatre choses : valider les chiffres une fois par mois, arbitrer les demandes d’ajout d’indicateurs, faire remonter au prestataire les écarts qu’il ne peut pas expliquer, et supprimer les écrans que personne n’utilise. Ce n’est pas un poste à temps plein, plutôt une heure par mois assumée par quelqu’un de légitime sur le sujet.
Un contrôleur de gestion fonctionne généralement mieux qu’un responsable informatique dans ce rôle, parce que la question qui tue l’adoption est une question de définitions, pas de requêtes.
Erreur n°3 : les chiffres ne correspondent pas à ceux que chacun calcule déjà
C’est la cause la plus brutale. Le jour où le directeur commercial voit 4,2 MMAD sur l’écran et 4,35 MMAD dans son fichier, il ne cherche pas l’explication : il retourne à son fichier. Et il a raison de se méfier, parce qu’un seul écart non expliqué suffit à discréditer les sept autres écrans.
Dans la quasi-totalité des cas, l’écart n’est pas une erreur de calcul mais une différence de définition. Le chiffre d’affaires est-il facturé ou encaissé ? Les avoirs sont-ils déduits du mois de la facture initiale ou du mois de l’avoir ? Les remises de fin d’année sont-elles provisionnées dans la marge mensuelle ? Les factures en devise sont-elles converties au cours du jour ou au cours de clôture ? Prend-on la date de facture ou la date de livraison ?
La contre-mesure est un document ennuyeux et décisif : un dictionnaire des indicateurs, une ligne par KPI, avec la définition en français, la source, la règle de calcul et les exclusions. Puis une étape de réconciliation : sur trois mois clôturés, l’écran et le fichier historique doivent tomber sur le même montant, ou l’écart doit être expliqué par écrit. C’est exactement le travail de définition qu’un audit qualité des données devrait révéler avant la construction, et c’est aussi là que se logent la plupart des surprises de délais sur l’intégration des sources.
Erreur n°4 : trop d’indicateurs, aucune hiérarchie
Un tableau de bord d’entreprise au Maroc n’a pas besoin de quarante KPI pour être utile, et il devient illisible bien avant d’y arriver. Quand un écran affiche vingt chiffres de la même taille, le lecteur ne sait pas lequel regarder en premier, donc il ne regarde rien.
La règle qui tient dans la durée : une première page avec cinq à sept chiffres maximum, ceux qui déclenchent une action, chacun accompagné d’une comparaison (objectif, mois précédent, même mois de l’an dernier). Le reste vit dans des pages de détail que l’on atteint en cliquant. Les ateliers de cadrage produisent naturellement une liste de trente indicateurs ; le travail du prestataire est de la réduire, pas de la livrer telle quelle.
Un test rapide : si vous ne pouvez pas dire, sans réfléchir, ce que vous feriez le lendemain matin selon la couleur d’un indicateur, il n’a pas sa place sur la première page.
Adoption tableau de bord : ce qu’il faut écrire dans le devis
Ces quatre points se négocient avant la signature, et le plus souvent à budget constant, parce qu’ils déplacent de l’effort plutôt qu’ils n’en ajoutent. En plus des points habituels à contrôler quand vous lisez un devis IT avant de signer, voici les éléments à faire figurer noir sur blanc :
- la liste des décisions à servir, avec pour chacune l’utilisateur, le rituel (réunion du lundi, clôture mensuelle) et la fraîcheur de données nécessaire ;
- un propriétaire interne nommé, et un interlocuteur nommé côté prestataire plutôt qu’une adresse support générique ;
- un dictionnaire des indicateurs livrable et validé, plus une réconciliation sur trois mois clôturés face aux fichiers existants ;
- une contrainte de hiérarchie écrite : une page d’entrée, sept indicateurs maximum, détail en second niveau ;
- une revue d’adoption à trente jours, chiffrée dans le devis, appuyée sur les chiffres d’usage réels ;
- le traitement des évolutions de sources (nouveau champ ERP, changement de nomenclature) : forfait, régie ou inclus dans la maintenance ;
- la propriété du modèle de données et des rapports, et la procédure applicable si vous changez de prestataire.
Si le budget bloque, mieux vaut livrer deux écrans utilisés que huit écrans corrects. Le budget d’un projet BI au Maroc se tient beaucoup mieux quand le périmètre est défini par les décisions à prendre que par le nombre de rapports promis.
Les signaux à vérifier trente jours après la mise en production
Si le projet est déjà livré, l’adoption se mesure, elle ne s’estime pas. Power BI, Looker Studio et Metabase exposent tous des statistiques d’usage. Demandez-les, puis posez cinq questions.
- Combien d’utilisateurs distincts ont ouvert le rapport la semaine dernière (pas depuis la mise en production) ?
- Qui refait encore un export manuel, et pour quelle réunion ?
- Combien de remarques « ce chiffre est faux » ont été remontées, et combien ont reçu une réponse écrite ?
- Un écran a-t-il été supprimé depuis la livraison ? Si rien n’a jamais été retiré, personne ne gouverne l’outil.
- La décision cible a-t-elle été prise au moins une fois en réunion à partir de l’écran, sans export préalable ?
Deux utilisateurs actifs réguliers sur une population de cinq décideurs valent mieux que trente comptes créés et jamais ouverts. L’adoption BI dans une PME se joue sur quelques personnes, et ces personnes se nomment.
Si le tableau de bord est déjà livré
Un rapport délaissé est rarement à refaire entièrement. Dans beaucoup de cas, une semaine de travail suffit pour reconstruire la première page autour de deux décisions, écrire le dictionnaire des indicateurs et réconcilier les montants avec les fichiers de référence. C’est la façon dont nous cadrons chez Arrowlancer les prestations data (tableaux de bord, pipelines, BI, qualité des données) : les décisions d’abord, un propriétaire nommé avant la mise en production, et un point d’adoption à trente jours inclus dans la mission. Si vous avez un devis BI sur la table ou un tableau de bord que plus personne n’ouvre, parlons-en.