Spécification technique Power BI : Plan, Ship, Analyze avec des critères Gherkin

Série : Automatiser Power BI avec Claude AI — Épisode 4/12 Temps de lecture : 11 min Public cible : BI Engineers, Project Managers, Product Owners Data, Consultants
TL;DR : Le framework Plan/Ship/Analyze structure une spec BI en 3 sections : ce qu’on construit (6 User Stories, 27 critères Gherkin avec valeurs réelles), comment on le construit (16 scope items, atlas de 27 mesures DAX), et comment on vérifie (12 critères pondérés, scoring automatisable). Résultat : la spec d’environ 500 lignes du projet client a été produite en 1 jour au lieu de 3, et sert de base aux tests automatisés.

Pourquoi la spec BI est-elle souvent le maillon faible ?

La spécification technique est soit absente, soit un document Word de 40 pages que personne ne relit après le kick-off. Résultat : des itérations infinies, des malentendus sur les KPIs, des corrections en production, des PV de recette qui traînent 3 semaines.
Dans la plupart des projets BI, la spec remplit mal ses fonctions. On a cherché un format qui soit : 1. Compréhensible par le client (pas trop technique) 2. Exploitable par Claude pour générer du code 3. Utilisable comme base de tests automatisés 4. Maintenable dans le temps
Le framework Plan / Ship / Analyze répond à ces quatre contraintes.

Comment fonctionne le framework Plan / Ship / Analyze ?

Ce framework est simple. Trois sections, trois questions :
  • PLAN : Qu’est-ce qu’on construit, pour qui, selon quels critères ?
  • SHIP : Comment on le construit, avec quoi, en combien de temps ?
  • ANALYZE : Comment on sait que c’est bon ?
La spec du projet fait environ 500 lignes. Voici ce qu’elle contient.

PLAN — Comment définir le “quoi” et le “pour qui” ?

Comment rédiger des User Stories avec données réelles ?

6 User Stories couvrent le MVP. Chaque User Story suit le format standard :
En tant que [rôle], je veux [fonctionnalité] afin de [bénéfice métier].
Mais on y ajoute deux éléments que les User Stories classiques omettent souvent :
Les données de référence : Au lieu de “je veux voir les KPIs projets”, on écrit “je veux voir les 34 projets actifs avec leurs 64 022 kEUR d’AO”. Les valeurs réelles de Mars 2025 sont dans la spec. Ça évite les “mais les chiffres ne correspondent pas” en recette.
Les contraintes de rôle : Chaque User Story précise ce que voit le rôle demandeur — et ce qu’il ne voit pas. Un Responsable Infra Local ne voit que ses projets. Un Visiteur CODIR voit tout mais ne peut rien modifier.

Pourquoi utiliser le format Gherkin pour les critères d’acceptation ?

27 critères d’acceptation, au format Gherkin (Given / When / Then). Le Gherkin est un langage semi-formel, lisible par un humain non-technique, et parsable par un LLM pour générer des tests automatisés.
gherkin
Feature: Filtrage par statut de projet Scenario: Filtrer les projets "En cours" Given l'utilisateur est connecté avec le rôle "Direction Infra" And la page Vue d'ensemble est chargée avec les données de Mars 2025 When il sélectionne le filtre "Statut = En cours" Then la liste affiche exactement 23 projets And le KPI "Projets actifs" se met à jour à 23 And le montant AO se recalcule en excluant les avant-projets
Ce niveau de détail a deux effets :
Sur la relation client : Le client valide chaque critère. Si “23 projets” est la bonne valeur pour Mars 2025, il le confirme en signant la spec. Plus d’ambiguïté en recette.
Sur Claude : Quand on demande à Claude de générer une mesure DAX pour “projets en cours”, il peut se référer à ce critère pour vérifier que sa mesure renvoie 23 en Mars 2025.

Comment structurer une matrice de rôles et permissions ?

5 rôles, 7 pages, 3 niveaux d’accès (Lecture, Lecture + Filtres, Lecture + Export) :
Rôle
Vue d’ensemble
Projets
Achats
Conformité
Litiges
Admin
R+F+E
R+F+E
R+F+E
R+F+E
R+F+E
Direction Infra
R+F+E
R+F+E
R+F
R+F
R
Resp Infra Central
R+F
R+F
R+F
R+F
Resp Infra Local
R+F*
R+F*
R*
R*
Visiteur CODIR
R
R
  • Limité à son périmètre géographique via RLS
Cette matrice est directement utilisable pour configurer le Row Level Security dans Power BI.

Pourquoi un dictionnaire des KPIs est-il indispensable ?

Chaque KPI a une fiche complète. Ce dictionnaire résout le problème le plus fréquent en BI : deux personnes qui utilisent le même mot pour des choses différentes.
  • Nom : Montant AO Total
  • Définition : Somme des montants des appels d’offres lancés, hors projets annulés
  • Formule DAX cible : CALCULATE(SUM(Contrats[Montant_AO]), Contrats[Statut] <> "Annulé")
  • Valeur de référence Mars 2025 : 64 022 kEUR
  • Format d’affichage : “XX XXX kEUR”
  • Seuil d’alerte : N/A

SHIP — Comment définir le “comment” et le “combien” ?

Comment estimer les Scope Items MVP ?

16 items de scope MVP, estimés à 5 jours ouvrés :
ID
Scope Item
Effort
Priorité
S001
Connexion Dataverse + modèle de données
0.5j
P0
S002
Page Vue d’ensemble
1j
P0
S003
Page Projets
1j
P0
S004
Page Achats
0.5j
P0
S005
Page Conformité
0.5j
P0
S006
Système de navigation
0.25j
P0
S007
Bookmarks (3 états)
0.5j
P1
S008
RLS par rôle
0.5j
P0
S009
27 mesures DAX
0.75j
P0
3 items Post-MVP (3 jours supplémentaires) : - Intégration carte géographique interactive - Export PDF automatisé - Page Juridique / Litiges avancée
La distinction MVP / Post-MVP est critique pour la gestion des attentes client.

À quoi sert un atlas des mesures DAX ?

27 mesures DAX identifiées avant d’écrire une ligne de code :
Mesure
Page(s)
Formule type
Complexité
Projets Actifs
Vue d’ensemble, Projets
COUNTROWS + FILTER
Faible
Montant AO Total
Vue d’ensemble, Achats
SUM + CALCULATE
Faible
Économies %
Vue d’ensemble, Achats
DIVIDE + CALCULATE
Moyenne
Taux Avancement Moyen
Projets
AVERAGEX
Moyenne
Contrats En Retard
Conformité
COUNTROWS + DATEDIFF
Élevée
Cet atlas remplit deux fonctions :
Éviter les doublons sémantiques : Sans atlas, deux développeurs écrivent deux mesures différentes pour “montant contractualisé”. Avec l’atlas, il y a une mesure, un nom, une définition.
Guider Claude : Quand on demande à Claude de générer une mesure DAX, on lui fournit l’atlas. Il sait quelles mesures existent déjà, et lesquelles il doit créer.

Comment décrire la structure des pages ?

7 pages décrites avec leurs visuels, leurs positions, et leurs interactions :
plain text
Page: Achats Dimensions: 1280 x 720 px Thème: Client_Theme_v2 Visuels: [1] Scorecard "Montant AO" — position: x=20, y=80 — mesure: [Montant AO Total] [2] Scorecard "Contractualisé" — position: x=220, y=80 — mesure: [Montant Contractualisé] [3] Scorecard "Économies" — position: x=420, y=80 — mesure: [Économies %] [4] Donut "Répartition fournisseurs" — position: x=20, y=200 [5] Histogramme "Historique 5 ans" — position: x=400, y=200 [6] Table "Détail contrats" — position: x=20, y=480 Bookmarks: N/A Filtres: Pays, Période, Fournisseur, Statut Contrat
Ce niveau de détail permet à Claude de générer les fichiers PBIR directement.

ANALYZE — Comment définir le “est-ce que c’est bon” ?

Quels sont les 12 critères de conformité pondérés ?

Fonctionnel (40 %) - Tous les KPIs MVP affichent les valeurs correctes (Mars 2025) - La navigation entre pages fonctionne sans erreur - Les filtres croisés fonctionnent correctement - Les bookmarks commutent les états attendus
UX / Design (25 %) - La charte du client est respectée (couleurs, typographie, logo) - La hiérarchie visuelle est claire - Le responsive mobile est fonctionnel - L’accessibilité (contraste, lisibilité) est respectée
Performance (20 %) - Chargement initial < 5 secondes - Réponse aux filtres < 2 secondes - Drill-down < 2 secondes
Sécurité (15 %) - RLS fonctionnel par rôle - Aucune donnée non-autorisée visible par rôle restreint - Paramètres de connexion non exposés

Comment fonctionne le scoring ?

Chaque critère est évalué Oui / Non / Partiel (0 / 1 / 0.5).
  • Score MVP : >= 75 % → Livrable pour UAT
  • Score Production : >= 90 % → Livrable en production
Sur ce projet, le PV de recette automatisé a mesuré un score MVP de environ 78 % — au-dessus du seuil, mais avec deux anomalies critiques à corriger.

Comment Claude génère-t-il cette spec en pratique ?

Le processus n’est pas “donnez tout à Claude et il produit la spec”. C’est une collaboration structurée en 4 étapes :
Étape 1 : Digestion des inputs. On fournit à Claude les documents bruts : brief client, notes de réunion, maquette PDF existante, liste des tables Dataverse. Claude extrait les User Stories candidates et les KPIs identifiés.
Étape 2 : Structuration. Claude organise les User Stories en format standard, génère les critères Gherkin pour chacune, identifie les cas limites. L’humain valide et corrige.
Étape 3 : Estimation. Claude propose une estimation des Scope Items en jours. L’humain ajuste selon son expérience (Claude tend à sous-estimer les tâches de setup et d’intégration).
Étape 4 : Finalisation. Claude génère le document complet. L’humain relit, complète les valeurs de référence, et le soumet au client pour validation.
Temps total : ~1 jour (contre 3 jours en méthode classique).

Quel prompt utiliser pour initialiser une spec BI ?

plain text
Tu es un BI Engineer senior. Je vais te donner les éléments suivants : - [Brief client] - [Liste des tables de données] - [Rôles utilisateurs] - [Maquette visuelle ou description des pages] Génère une spec technique structurée en trois parties : PLAN : - 5 à 8 User Stories au format "En tant que [rôle], je veux [action] afin de [bénéfice]" - Pour chaque User Story, 2 à 4 Acceptance Criteria au format Gherkin avec les valeurs de données réelles que je vais te fournir - Matrice des rôles et permissions SHIP : - Liste des Scope Items MVP estimés en jours - Atlas des mesures DAX (nom, page(s), formule type, complexité) - Structure des pages avec leurs visuels ANALYZE : - 10 à 15 critères de conformité répartis en 4 catégories (Fonctionnel, UX, Performance, Sécurité) - Pondération et méthode de scoring Sois précis, concis, et utilise les valeurs réelles que je te fournis.

FAQ — Spec technique BI et critères Gherkin

Qu’est-ce que le format Gherkin et pourquoi l’utiliser en BI ? Le Gherkin est un langage semi-formel (Given/When/Then) lisible par un humain non-technique et parsable par un LLM. En BI, il permet d’écrire des critères d’acceptation testables avec des valeurs réelles — “Then il voit 34 projets actifs” plutôt que “Then il voit le bon nombre”.
Le framework Plan/Ship/Analyze est-il spécifique à Power BI ? Non. Il s’applique à tout projet BI (Tableau, Qlik, Looker, Metabase). La section SHIP s’adapte à l’outil cible — les mesures DAX deviennent des calculs LOD pour Tableau, par exemple.
Comment Claude gère-t-il les estimations de temps ? Claude tend à sous-estimer les tâches de setup (connexion Dataverse, configuration RLS) et d’intégration. L’humain doit ajuster les estimations selon son expérience projet.
La spec Gherkin peut-elle servir de base aux tests automatisés ? Oui. C’est l’un de ses principaux avantages. Les critères Gherkin du projet client ont été directement utilisés par Claude Chrome pour générer le PV de recette.

Des questions sur cette méthode ? Vous voulez adapter ce framework à votre organisation ? Parlons-en.