Reprendre un projet Power BI quand le prestataire est parti : par où commencer ?
Le prestataire est parti, la documentation est inexistante, et les reportings tombent en production. Voici la démarche que je suis pour reprendre la main sans casser l'existant.
Reprendre un projet Power BI quand le prestataire est parti est l'une des situations les plus inconfortables qu'une équipe data puisse traverser. Pas de documentation, des reportings critiques en production, et chaque semaine qui passe rend l'environnement plus opaque. La bonne nouvelle : il existe une démarche claire pour reprendre la main sans tout casser.
1. Stabiliser avant tout
La première erreur que je vois est de vouloir tout refaire. C'est rarement la bonne décision. Avant toute optimisation ou refonte, il faut sécuriser ce qui tourne. Concrètement :
- Inventaire des workspaces, des datasets et des rapports critiques.
- Vérification des refresh planifiés, de leur fréquence et de leur taux de succès sur les 30 derniers jours.
- Identification des comptes de service et des passerelles de données utilisés.
- Cartographie des sources : ERP, SQL, API, fichiers Excel critiques référencés en source.
2. Reverse engineering du modèle
Une fois l'environnement sécurisé, on attaque le cœur : le modèle de données. C'est là que se cache la complexité. Un dataset hérité peut contenir plusieurs centaines de mesures DAX, des relations bidirectionnelles non maîtrisées, et des colonnes calculées qui s'empilent.
L'objectif n'est pas de tout comprendre en une journée, mais de produire une cartographie lisiblequi permettra à l'équipe de prendre des décisions :
- Tables, relations, cardinalités, sens de filtre.
- Mesures DAX organisées par domaine fonctionnel (finance, ventes, opérations…).
- Étapes Power Query, sources, transformations critiques.
- Dépendances entre datasets, dataflows et rapports.
3. Documenter pour exister sans dépendance
La documentation produite à cette étape doit être tenable dans le temps. Elle doit pouvoir être lue autant par un profil métier que par un développeur BI. Les éléments que je documente systématiquement :
- Liste des indicateurs critiques avec leur formule métier (en français), leur formule DAX (en code) et leur source.
- Schéma du modèle, avec les choix d'architecture justifiés.
- Procédure de refresh : ordre, dépendances, points de fragilité.
- Procédure d'onboarding pour un nouveau développeur.
4. Optimiser ce qui en vaut la peine
Une fois la phase de stabilisation et de documentation terminée, on peut envisager l'optimisation. Mais attention : optimiser sans avoir compris, c'est introduire des régressions. Mes priorités à cette étape :
- Refactor des mesures DAX les plus utilisées et les plus lentes.
- Rationalisation des datasets en doublon.
- Optimisation des requêtes Power Query : repli vers la source, réduction du volume chargé, types de données.
- Mise en place d'une gouvernance simple : conventions de nommage, workspaces dédiés, accès.
5. Et après ?
À ce stade, l'environnement est sain et transmissible. L'équipe peut continuer à le faire évoluer en interne, ou s'appuyer sur une TMA cadrée pour absorber les évolutions sans recréer de dette.
La clé d'une reprise réussie n'est pas la vitesse. C'est la rigueur dans l'ordre des étapes : stabiliser, comprendre, documenter, puis optimiser.
Une situation similaire chez vous ?
Décrivez votre contexte, je reviens vers vous sous 1 jour ouvré.