Pourquoi les projets BI échouent : le problème commence avant le tableau de bord

DONNÉES & DÉCISION

Reprenons Sylvain, le DSI fictif de la première version de cet article. Il arrive dans une PME et son patron lui annonce : « Nous avons beaucoup de projets informatiques, mais ce que j’attends surtout, c’est la BI. J’ai besoin de voir mes chiffres. »

Sylvain pense outils, modèles de données et tableaux de bord. Puis il rencontre les responsables de service. Le commerce suit les commandes. La finance regarde les factures. Les opérations comptent les livraisons. Tous parlent de chiffre d’affaires, mais pas de la même chose.

Le projet a déjà été lancé plusieurs fois. Personne ne fait vraiment confiance aux résultats. Et pourtant, on envisage un nouvel outil.

C’est le point de départ que je veux garder : un projet de business intelligence peut produire de beaux rapports sans donner à l’entreprise une base commune pour décider.

L’échec d’un projet BI n’est pas toujours une panne technique

Les problèmes techniques existent : flux incomplets, calculs erronés, performances insuffisantes ou droits mal gérés. Il faut les traiter. Mais un tableau de bord peut aussi être techniquement juste et inutilisable pour l’organisation.

Par exemple, la marge affichée n’intègre pas les mêmes coûts que celle attendue par la DAF. Les retours sont comptés sur une autre période. Le client est regroupé différemment selon les services. Chacun finit par conserver son fichier Excel « pour vérifier ».

Je ne chercherais pas à résumer cette diversité par un grand taux d’échec universel. Avant de changer d’outil, je demanderais plutôt : quel désaccord empêche aujourd’hui d’utiliser l’information ?

Premier piège : commencer par les données sans définir la décision

« Nous voulons tout voir » n’est pas un besoin suffisamment précis pour démarrer. Voir quoi, pour décider quoi, à quelle fréquence et avec quel niveau de détail ?

Un responsable qui doit réapprovisionner un magasin n’a pas nécessairement besoin du même indicateur qu’un CODIR qui arbitre un investissement. La fraîcheur des données, le périmètre et la tolérance à l’erreur peuvent être différents.

Je propose de partir de quelques décisions récurrentes. Pour chacune, identifiez l’information manquante et ce que son utilisateur fera autrement lorsqu’elle sera disponible. Vous aurez un premier périmètre utile, au lieu d’un entrepôt de données construit dans l’espoir que les usages apparaissent ensuite.

Deuxième piège : personne ne porte la définition du chiffre

Un indicateur doit avoir une définition que les personnes concernées comprennent et acceptent. Prenons les ventes : commandes passées, commandes payées, produits expédiés ou factures émises ? Avec ou sans annulations ? À quelle date rattache-t-on un retour ?

Il n’existe pas toujours une seule définition valable pour tous les usages. Plusieurs indicateurs peuvent coexister, à condition de les nommer clairement et de savoir pourquoi ils diffèrent.

La DSI peut construire et maintenir le calcul. Elle ne doit pas inventer seule une règle commerciale ou comptable. Un responsable métier doit pouvoir la valider et arbitrer les exceptions avec les autres services.

Cette distinction entre responsabilité métier et technique rejoint les recommandations de Microsoft sur la propriété et la gestion des contenus BI. Il faut l’adapter à la taille de l’entreprise, pas créer un titre de poste pour chaque règle.

Troisième piège : nettoyer les rapports sans corriger la source

Si une donnée est régulièrement incomplète, on peut ajouter une correction dans le reporting. Puis une autre. Puis demander à quelqu’un de vérifier manuellement avant chaque réunion.

Le rapport devient juste grâce à un travail invisible. Mais l’erreur continue d’être produite dans le processus d’origine. Le jour où la personne manque, la confiance retombe.

Il faut donc remonter jusqu’au moment où l’information est créée : saisie, règles de gestion, référentiel, interface ou changement de statut. Les enjeux du PIM et des données de référence ou des échanges entre logiciels peuvent apparaître ici. Ils restent au service du problème à résoudre.

L’IA ne tranche pas un désaccord sur ce que signifie la donnée

Une interface en langage naturel peut faciliter l’accès à une information ou aider à préparer une analyse. Elle ne dispense pas de définir les indicateurs, les accès et les vérifications attendues.

Si deux sources donnent deux chiffres différents, une réponse fluide ne constitue pas une règle d’arbitrage. La question reste : quelle source utiliser pour cet usage, avec quelle définition et quelle limite ?

Sur une décision importante, je veux pouvoir comprendre d’où vient le résultat et comment il a été obtenu. L’IA peut aider à explorer. La responsabilité du choix reste à organiser.

Relancer le projet avec un périmètre que l’on peut vérifier

Pour repartir, choisissez une décision métier, un responsable et quelques indicateurs. Faites valider les définitions avant de multiplier les écrans. Comparez ensuite les résultats à des cas connus, y compris les exceptions : annulation, retour, changement de période ou donnée manquante.

Préparez aussi la vie du dispositif : qui répond à une anomalie, qui valide une modification et qui vérifie qu’il est toujours utilisé ? La livraison du tableau de bord n’est pas la fin du travail.

Un premier résultat pertinent peut être modeste : une réunion dans laquelle on cesse de débattre du chiffre pour discuter de ce que l’on va faire. C’est un meilleur signal que le nombre de graphiques disponibles.

La BI ne crée pas la confiance à la place de l’organisation. Elle peut rendre cette confiance possible lorsque les définitions, les responsabilités et les contrôles sont enfin clairs.

Quand faut-il reprendre le sujet ?

Si chaque service défend son chiffre, si le reporting dépend d’une personne ou si vous lancez un nouveau projet après plusieurs tentatives, un diagnostic SI peut aider à distinguer les causes. La gouvernance du SI sert ensuite à faire prendre les décisions qui dépassent le seul outil.

Vos données ne vous permettent plus de décider sereinement ? Expliquez-moi la situation.

Article initial conservé à la même adresse et refondu le 14 octobre 2026.

Retrouver les guides du Laboratoire de la décision →