Cet article fait partie d’une série présentant en détail les principes du DataOps Manifesto et leur application aux services Data Microsoft. Pour une introduction aux principes DataOps, je vous invite à commencer par cette présentation.

Principe #3 : être ouvert au changement.

Les besoins des utilisateurs évoluent ; il faut les accueillir et les intégrer dans le cycle analytique pour garder un avantage compétitif.

Le premier principe du DataOps Manifesto (si vous n’avez pas encore lu mon article, rattrapage par ici) posait déjà les bases d’une démarche agile : votre modèle sémantique doit être pensé pour le futur : le niveau de granularité de la donnée doit, par exemple, être suffisamment détaillé pour satisfaire les futures demandes.

Et bien entendu, des demandes qui évoluent au fil du temps, vous allez en recevoir régulièrement. C’est notre quotidien à tous, et c’est tout naturel.

L’un des défis majeurs dans les projets data est la dynamique des besoins métier. Le marché change, les priorités se déplacent, et les décisions doivent s’adapter en conséquence. Accepter le changement signifie que l’équipe analytique ne doit pas lutter contre ces évolutions mais les intégrer dès qu’elles surviennent, en minimisant le délai entre la demande et la réponse.

Si on prend l’exemple du développement d’applications, on est passé du classique cycle en V (spécifications puis développement) à des démarches agiles basées sur des sprints (livraisons itératives). DataOps adopte une posture identique : on travaille par itérations courtes et on valorise la collaboration continue avec les utilisateurs finaux. Chaque sprint ou cycle d’analyse inclut des revues avec les parties prenantes afin de s’assurer que les besoins restent pertinents.

Facile à dire mais pour une équipe Data le défi est de taille ! Il faut jongler entre la rigueur d’un modèle sémantique bien défini et la modification nécessaire pour satisfaire un nouveau besoin métier. Le sacro-saint Data Warehouse et sa structure figée peut rapidement devenir un gigantesque fourre-tout où se côtoient des données hétérogènes sans aucune gouvernance.

Dans une organisation DataOps, accepter le changement n’est pas seulement une question d’attitude : c’est un processus structuré. On utilise des outils de communication fréquents, des revues régulières et des environnements de développement flexibles qui permettent de tester de nouvelles hypothèses sans risques élevés. Cela renforce la capacité à s’adapter à des priorités fluctuantes, à intégrer de nouvelles sources de données ou à repenser un KPI dès que le contexte métier change.

Pour appliquer ces principes dans Power BI comme dans Microsoft Fabric, la structure de vos pipelines de données et de vos indicateurs doit être la plus modulaire possible. Cela signifie qu’un dashboard en production continue à vivre selon un cycle régulier. Il est amené à évoluer.

A ce sujet, je vous conseille de faire un focus sur les modes de déploiement de vos dashboards. Dans un contexte d’entreprise ayant acquis une (ou plusieurs) capacités Microsoft Fabric, vous vous devez d’utiliser les pipelines de déploiement et de définir une organisation en workspaces pour chaque type d’environnement : développement, test, pré-production, production. Utilisez l’intégration Git de vos workspaces pour versionner vos dahboards (adieu les dashboard_v1, dashboard_v2, dashboard_final !).

Le nombre de workspaces pourra être plus ou moins grand pour certains cas d’usage (un rapport moins critique ou à usage temporaire pourra se contenter de deux workspaces, développement et production) mais chaque cas devra être identifié. Pour apporter du process au sein de l’équipe Data (car oui, un projet BI est avant tout un projet !), pensez dès le début à documenter cette partie (les futurs membres de l’équipe vous remercieront d’avoir pris quelques minutes pour rédiger une SOP – Standard Operating Procedure – qu’ils pourront suivre pas à pas).

L’équipe Data doit également identifier en amont les sponsors et les data owners qui auront un pouvoir de décision sur les futures demandes. Toute demande doit être validée et l’équipe aura pour rôle d’alerter sur les impacts de chaque modification demandée.

Planifiez des revues fréquentes du modèle de données et des transformations avec les utilisateurs, afin de garantir que chaque changement soit accepté, testé et livré rapidement.

Règle d’or #3 : prépare tes pipelines pour le changement : modularité et petits itérations avant tout.