Identification des Parties Prenantes en BI

Cas 5 — Qui impliquer et comment prioriser les besoins ?

Groupe 3 · BANSAH Chekinah · EFIA DIEUDONNE · KENKOU DAVE · MENSAH Deborah · OCLOO Emmanuella· TOGBENOU Daniel

24 juin 2026

Sommaire

Partie 1 — Fondamentaux

  • Définition & enjeux
  • Cartographie Pouvoir / Intérêt
  • Départements impliqués

Partie 2 — Collecte des besoins

  • Rôles par département
  • Méthodes de collecte
  • Priorisation MoSCoW

Partie 3 — Gouvernance & Arbitrages

  • Compromis nécessaires
  • Qui décide quoi ?
  • Cas concret Retail

Partie 4 — Synthèse

  • Erreurs à éviter
  • 6 étapes clés
  • Recommandations

Partie 1 — Fondamentaux

Qu’est-ce qu’une Partie Prenante en BI ?

Un projet BI sans parties prenantes bien identifiées, c’est construire un tableau de bord que personne n’utilise.

Définition

Une partie prenante est toute personne ou groupe qui :

  • Influence les décisions du projet BI
  • Est impactée par ses résultats
  • Fournit des données ou de l’expertise

Les 3 Grandes Catégories de Parties Prenantes

Décideurs
DG, DSI, DAF
Valident & financent le projet

Utilisateurs
Analystes, managers
Utilisent au quotidien

Fournisseurs
IT, équipes data
Produisent les données

Cartographie — Matrice Pouvoir / Intérêt

Figure 1

La matrice détermine la stratégie d’engagement — pas tous les acteurs ne méritent le même niveau d’attention.

Les Départements Impliqués

Figure 2

Les Départements Impliqués — Points Clés

IT & Data est le plus critique — architecte technique ET fournisseur de données simultanément.

Direction Générale = sponsor indispensable. Sans validation exécutive, pas de budget ni de légitimité.

Marketing & Ventes = premier utilisateur métier — génère 80% des demandes de rapports.

Partie 2 — Collecte des Besoins

Rôles & Responsabilités

Table 1
Département Besoin BI Rôle
Direction Générale KPIs stratégiques, dashboard exécutif Sponsor
Finance Reporting financier, forecasting Définit KPIs
Marketing Analyse clients, performance campagnes Utilisateur principal
IT & Data Architecture, ETL, sécurité Architecte
RH Turnover, coûts, effectifs Utilisateur
Opérations Stocks, délais, productivité Fournisseur
Audit Traçabilité, conformité RGPD Garant

Chaque département a un besoin différent — le rôle du chef de projet BI est de les réconcilier dans une solution cohérente.

Méthodes de Collecte des Besoins

① Entretiens individuels
One-to-one avec chaque responsable. Idéal pour les besoins sensibles.
30-60 min 1-5 personnes

② Workshops collaboratifs
Sessions de groupe multi-départements. Détecte les contradictions.
2-4h 5-15 personnes

③ Questionnaires
Formulaires standardisés. Rapide mais moins riche en détails.
Rapide 15+ personnes

④ Shadowing (observation)
Observer les utilisateurs au travail. Révèle les besoins implicites.
Long 1-3 personnes

En pratique, on combine :

  • Entretiens → Décideurs (DG, DAF, DSI)
  • Workshop → Équipes métier
  • Questionnaire → Utilisateurs finaux

Ne jamais recueillir les besoins une seule fois — ils évoluent à chaque sprint.

Priorisation des Besoins — Méthode MoSCoW

Figure 3

Priorisation des Besoins — Pourquoi MoSCoW ?

Pourquoi MoSCoW ?

Erreur classique : tout mettre en “Must Have”. Le chef de projet doit forcer la priorisation.

Bénéfice : permet de livrer un MVP utile en 3 mois plutôt qu’un projet parfait en 2 ans.

Partie 3 — Gouvernance & Arbitrages

Les Compromis Nécessaires

Table 2
Conflit Désaccord Arbitrage
Finance vs Marketing Périmètre données clients Dictionnaire de données commun
IT vs Métier Délais vs qualité technique Sprints Agile courts
DG vs Opérations Coûts vs fonctionnalités Roadmap phasée avec MVP
Audit vs Agilité Traçabilité vs rapidité Audit trail dès la V1

4 principes d’arbitrage

  • Transparence — documenter chaque décision
  • COPIL mensuel — arbitrage formel
  • MVP d’abord — satisfaire le Must Have de tous
  • Critères objectifs — impact business, pas poids politique

Gouvernance BI — Qui Décide Quoi ?

Stratégique

Direction Générale
Budget & vision

DSI
Choix technologique

DAF
Validation ROI

Tactique

Chef de projet BI
Coordination & planning

Data Stewards
Qualité des données

Responsables métier
Validation besoins

Opérationnel

Développeurs BI
Rapports & dashboards

Data Engineers
Pipeline & ETL

Utilisateurs finaux
Retours d’usage

Cas Concret — Retail & Grande Distribution

Contexte — chaîne de 200 magasins souhaitant piloter ses performances via une solution BI centralisée.

Table 3
Acteur Besoin Priorité
DG Dashboard national Must
DAF Marge / enseigne Must
Dir. Marketing Promos & CA/segment Should
Dir. Logistique Taux rupture stock Should
DSI Architecture Must
Gérants Ventes locales Could

Déroulement du projet

Sem. 1-2 — Cartographie des stakeholders + matrice P/I

Sem. 3-4 — Entretiens DG/DAF/DSI + workshop métier

Sem. 5 — Atelier MoSCoW → périmètre V1 validé

Sem. 6 — Cahier des charges signé par toutes les parties

Résultat V1 (3 mois) : Dashboard financier national + suivi stocks. Marketing & gérants → V2.

Clé du succès : les gérants de magasin impliqués dès le départ, même si leurs besoins passent en V2.

Partie 4 — Synthèse

Les 5 Erreurs à Éviter

Figure 4

L’erreur n°1 en entreprise : lancer le développement BI avant d’avoir validé les besoins avec toutes les parties prenantes.

Recommandations — Les 6 Étapes Clés

Table 4
# Étape Livrable
01 Identifier toutes les parties prenantes Registre stakeholders
02 Cartographier (Matrice Pouvoir/Intérêt) Matrice P/I
03 Définir le rôle de chaque acteur (RACI) RACI chart
04 Collecter les besoins (entretiens + workshops) Cahier des charges
05 Prioriser avec MoSCoW Backlog V1/V2
06 Valider & documenter les compromis PV signé

Un projet BI réussi = une solution utilisée, pas une solution techniquement parfaite.

Conclusion

Un projet BI est avant tout un projet humain

30% Technologie & Outils

40% Parties Prenantes & Besoins

30% Gouvernance & Adoption

Identifier → Cartographier → Collecter → Prioriser → Gouverner → Livrer