Le problème que personne ne nomme
Voici un scénario que nous avons observé des dizaines de fois en 20 ans de conseil — en Europe d'abord, en Afrique ensuite. Un directeur général valide un projet de Business Intelligence. Le budget est signé. Un cabinet de conseil est mandaté. Et puis le projet entre dans la machine.
en moyenne
fonctionnelles
livrés
utilisés après 6 mois
Ces chiffres sont des ordres de grandeur, pas des statistiques publiées. Ils reflètent ce que nous avons observé de manière récurrente sur des dizaines de projets BI menés chez des opérateurs télécom européens, des institutions financières, des groupes industriels. Les études Gartner et Forrester confirment la tendance générale : entre 60% et 85% des projets BI ne produisent pas la valeur attendue, selon la période et la méthodologie de mesure. Ce qui nous intéresse ici n'est pas le chiffre exact — c'est le pattern. Et le pattern se répète avec une régularité déconcertante : le DG voit le premier dashboard au mois 9 du projet. À ce moment-là, ses priorités ont changé. Les données ont évolué. Le consultant a spécifié un système qui répond aux questions de janvier alors qu'on est en octobre.
Le DG regarde le dashboard, dit "c'est intéressant", et le lendemain matin, appelle quand même son directeur financier pour avoir le chiffre dont il a besoin. Par téléphone. Ou par WhatsApp.
Le projet est officiellement "réussi" — livré dans les temps, dans le budget, conforme aux spécifications. Mais fonctionnellement, il est mort-né. Et personne n'a intérêt à le dire : ni le cabinet qui a facturé, ni le DSI qui a porté le projet, ni le DG qui a signé le budget.
Un dashboard que personne n'utilise n'est pas un échec technique. C'est un échec méthodologique. La technologie fonctionne. C'est le chemin entre la technologie et la décision qui est cassé.
Pourquoi 12 mois ? Parce que c'est rentable — pour le consultant
La durée d'un projet BI n'est pas dictée par la complexité technique. Power BI peut se connecter à une base de données et produire un dashboard fonctionnel en quelques heures. La durée est dictée par le modèle économique du cabinet : plus le projet dure, plus il facture de jours. Un cadrage de 2 mois n'est pas nécessaire techniquement — mais il justifie 40 jours-homme de consultant senior à 1 200 € la journée.
Nous ne disons pas que le cadrage est inutile. Nous disons que le cadrage traditionnel — interviews de 15 directions, ateliers de spécification, document de 80 pages validé en comité — est un processus conçu pour minimiser le risque du consultant, pas pour maximiser la valeur pour le client. Le consultant se protège derrière des spécifications signées. Si le dashboard ne correspond pas aux besoins réels, ce n'est pas sa faute — il a respecté les specs.
Notre rupture : le sprint de 6 semaines
Après 20 ans à observer ces échecs — et à en avoir été complices dans nos vies précédentes chez les grands cabinets — nous avons conçu une méthodologie qui inverse le modèle. Le premier dashboard opérationnel est livré en 6 semaines. Pas un prototype. Pas une maquette. Un dashboard en production, alimenté par des données réelles, utilisé par de vraies personnes pour prendre de vraies décisions.
Voici le déroulé exact.
L'entretien du décideur
Avant tout diagnostic technique, on s'assoit avec le décideur final — le DG, le Ministre, le Secrétaire Général — et on lui pose une seule question : « Quelle est la décision que vous prenez le plus souvent avec le moins de visibilité ? » Pas "quels KPIs voulez-vous." La décision. Parce qu'un dashboard n'a de valeur que s'il change une décision. Si le DG dit "je ne sais jamais si mes postes budgétaires sont dans les clous avant la fin du trimestre", on sait exactement quoi construire en premier.
Cartographie data — 5 jours chrono
On ne produit pas un audit de 40 pages. On cartographie trois choses : où sont les données aujourd'hui (Excel, ERP, bases Access, papier), quelle est leur qualité réelle (on ouvre les fichiers, on compte les cellules vides, les doublons, les formats incohérents), et quel est le chemin le plus court entre ces données et la première décision du DG. Le livrable : une maquette cliquable du futur dashboard, construite sur des données réelles.
Un exemple vécu : chez un opérateur télécom européen, le DSI était convaincu que le principal problème était l'absence de data warehouse. La semaine 1 a révélé autre chose. Le directeur commercial recevait chaque lundi un fichier Excel de 14 onglets consolidé à la main par un analyste. Ce fichier contenait tout ce dont il avait besoin — mais il arrivait le mardi soir, 24 heures trop tard pour la réunion du lundi matin. Le problème n'était pas l'absence de données, c'était le timing. Le premier dashboard a automatisé exactement ce fichier, avec rafraîchissement à 7h le lundi. Pas de data warehouse. Pas de modèle en étoile. Juste le bon chiffre, au bon moment, pour la bonne personne.
De la source brute au modèle fiable
On construit le flux : source → nettoyage → modèle → dashboard. En Microsoft Fabric ou en Power BI directement selon la complexité. La règle : si le chiffre du dashboard est à moins de 5% d'écart avec le chiffre Excel que le DAF produit manuellement, on avance. Ce test de réconciliation est la clé : c'est lui qui construit la confiance du DG dans le système. Tant que le DG ne fait pas confiance aux chiffres, le dashboard est un meuble.
Construction avec le métier, pas pour le métier
Le dashboard est construit en sprints quotidiens avec un référent métier — pas le DSI, quelqu'un de la direction qui utilisera réellement l'outil. Chaque soir, une version est publiée. Chaque matin, le référent dit ce qui marche et ce qui ne parle pas. On itère. On supprime ce qui est joli mais inutile. On ajoute ce qui manque. Les graphiques en 3D disparaissent. Les 47 filtres deviennent 5. Les titres en jargon BI deviennent du langage métier.
Le test d'autonomie
Le référent métier doit, seul, sans aide, ajouter un nouveau visuel au dashboard, modifier un filtre, et expliquer un chiffre à son directeur. Si c'est réussi, le premier dashboard est officiellement vivant. Si ce n'est pas réussi, on reste une semaine de plus. Le contrat ne prévoit pas un nombre de jours — il prévoit ce résultat. Notre KPI n'est pas la livraison. C'est l'autonomie.
Le modèle classique face au sprint : les chiffres
Le projet de 12 mois
Le dashboard en 6 semaines
Ce que le sprint ne fait pas — et pourquoi
Le sprint de 6 semaines ne couvre pas tout. Il ne produit pas un data warehouse complet. Il ne connecte pas 15 sources de données. Il ne déploie pas un modèle de gouvernance à l'échelle de l'entreprise. Et c'est délibéré.
Le sprint fait une seule chose : il met en production le premier dashboard qui change une décision réelle. Ce premier succès crée trois effets qui rendent tout le reste possible. Premièrement, la confiance : le DG a vu le système fonctionner, il y croit. Deuxièmement, l'appétit : les autres directions veulent leur propre dashboard. Troisièmement, le financement : le DG qui a vu son premier dashboard en 6 semaines est beaucoup plus enclin à financer la phase 2 que celui à qui on demande de signer pour 12 mois supplémentaires sur la base d'un PowerPoint.
En 20 ans de conseil, nous avons appris une chose : un projet BI qui ne produit pas de valeur visible dans les 60 premiers jours ne produira probablement jamais de valeur. Le sprint de 6 semaines est conçu pour forcer cette échéance.
Le protocole d'ancrage : ce qui se passe après la semaine 6
Le plus grand risque d'un dashboard n'est pas l'échec technique — c'est la mort lente. Le dashboard fonctionne, mais progressivement les données ne sont plus mises à jour, les filtres ne sont plus pertinents, et le DG revient à ses anciens réflexes. Nous avons vu ce scénario trop souvent pour le laisser se reproduire.
Notre protocole d'ancrage comporte quatre mécanismes concrets.
résilience organisationnelle
détection du décrochage
recalibrage continu
le vrai KPI de succès
Le binôme formé signifie deux référents, pas un. Parce que dans toute organisation, la première personne formée sera mutée, promue ou partira dans les 12 mois. Si le savoir repose sur une seule tête, le dashboard meurt avec son départ. Deux référents, c'est de la résilience organisationnelle.
Le cahier de vie du dashboard enregistre qui l'utilise, quand, pour quelle décision. Pas un document administratif — un outil de pilotage qui permet de détecter le décrochage avant qu'il ne devienne irréversible. Si le nombre de connexions baisse de 30% sur un mois, c'est un signal d'alerte.
Le check-up trimestriel : une demi-journée, 4 fois par an, pour recalibrer le dashboard avec l'évolution des besoins. Les questions du DG changent. Le dashboard doit changer avec elles. Ce check-up est inclus dans l'engagement NJIADATA pendant la première année.
Le test de vitalité à 12 mois : un an après le déploiement, on mesure trois indicateurs — fréquence de connexion, nombre de rafraîchissements de données, nombre de modifications apportées par le référent. Si les trois sont en zone verte, le projet est vivant. C'est notre vrai KPI de succès.
D'où vient cette méthode
Nous n'avons pas inventé le sprint de 6 semaines dans un laboratoire. Nous l'avons forgé sur le terrain, projet après projet, pendant 20 ans en Europe. Chez des opérateurs télécom où les directions marketing voulaient un dashboard de churn en 4 semaines, pas en 4 mois. Chez des groupes industriels où le CFO voulait voir l'impact d'une acquisition sur ses ratios consolidés avant la prochaine assemblée générale — pas au trimestre suivant. Chez des institutions financières où le régulateur imposait un reporting en J+1 et où "le projet est en phase de cadrage" n'était pas une réponse acceptable.
C'est cette exigence européenne — livrer vite, livrer juste, sur des organisations complexes avec des enjeux réels — qui a structuré notre méthode. Et c'est cette même exigence que nous apportons maintenant aux organisations africaines. Pas pour adapter un modèle au rabais. Pour transférer le meilleur de ce que 90 ans d'expérience cumulée nous ont appris.
Le sprint n'est pas une méthode pour les projets simples. C'est une méthode pour les projets urgents. Et en Afrique, tous les projets BI sont urgents — parce que la décision ne peut pas attendre 12 mois.
Pour qui cette méthode fonctionne — et quand elle ne suffit pas
Le sprint de 6 semaines n'est pas universel. Il fonctionne quand trois conditions sont réunies.
Premièrement, un décideur engagé. Pas un sponsor de façade qui signe le budget et disparaît — un dirigeant qui accepte de consacrer 2 heures à l'entretien initial et qui revoit le dashboard chaque semaine pendant le sprint. C'est la condition la plus exigeante : si le DG délègue à un chef de projet intermédiaire, on retombe dans le piège du data-first où les spécifications s'éloignent progressivement du besoin réel.
Deuxièmement, un référent métier disponible. Quelqu'un de la direction utilisatrice (pas du service informatique) qui peut consacrer 2 heures par jour pendant les semaines 4 et 5 pour itérer avec nous. C'est cette personne qui garantit que le dashboard parle le langage du métier. Si personne n'est disponible, le risque est de construire un outil technique que le métier ne s'appropriera pas.
Troisièmement, des données qui existent, même imparfaites. Fichiers Excel désorganisés, bases Access, ERP partiellement renseigné — on sait travailler avec du « good enough ». En revanche, si les données n'existent tout simplement pas (pas de suivi budgétaire, pas de base client, pas de comptabilité structurée), le sprint ne peut pas créer la matière première qu'il est censé transformer. Dans ce cas, le premier chantier est la structuration des données, pas la BI — et nous le disons avant de signer.
Le sprint ne convient pas non plus à tous les périmètres. Il produit 1 à 3 dashboards ciblés, pas un data warehouse unifié ni une plateforme d'entreprise. C'est un point d'entrée — le premier succès qui démontre la valeur et qui justifie la suite. Les organisations qui ont besoin d'une transformation data globale d'emblée (refonte d'ERP, consolidation de 15 systèmes, migration cloud complète) ont besoin d'un programme plus structuré. Mais même dans ce cas, nous recommandons de commencer par un sprint : rien ne construit la conviction du comité de direction aussi vite qu'un premier dashboard opérationnel en 6 semaines.
Le secteur ne change pas la méthode. Ce qui change, c'est la décision qu'on cible. Pour un ministère, c'est l'exécution budgétaire. Pour un groupe agroalimentaire, c'est la marge par produit et par filiale. Pour une ONG, c'est le taux de décaissement par bailleur. La question de départ est toujours la même : quelle décision ce dashboard va-t-il changer ?
À propos de NJIADATA
NJIADATA est un cabinet de conseil spécialisé dans les solutions Microsoft pour les marchés africains, basé à Paris et Abidjan. 4 fondateurs seniors, 90+ ans d'expérience cumulée chez des opérateurs télécom, des institutions financières et des groupes industriels européens. Notre mission : apporter l'exigence du conseil international sur le continent, tout en transférant les compétences aux équipes locales.
De la source au sens.