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 #5 : interactions quotidiennes.

Clients, équipes analytiques et opérations doivent travailler ensemble tous les jours tout au long du projet. J’ai bien dit : « tous les jours » ! Ce qui signifie être prêt à recevoir des feedbacks réguliers et à livrer des versions intermédiaires. Ce qui vous conduira également à terme à automatiser au maximum ces processus (Continuous Integration/Continuous Deployment ou CI/CD, le domaine, parfois obscur et réservé, de nos chers data engineers).

Dans un contexte DataOps, les silos ne sont plus tolérables. L’un des principes fondamentaux du DataOps Manifesto est que les interactions quotidiennes entre parties prenantes favorisent l’alignement continu, la transparence et une compréhension partagée des besoins et des contraintes.

Pourquoi ce principe ? Parce que dans un projet analytique traditionnel, les cycles longs et séparés (ex. conception, développement, livraison) créent des décalages de compréhension, des pertes de temps et des livrables qui ne correspondent pas aux besoins réels des utilisateurs. Avec des interactions fréquentes l’équipe évite les malentendus, réduit les travaux inutiles et accélère la mise en valeur des données.

La collaboration quotidienne ne signifie pas forcément de longues réunions, mais plutôt des points courts, efficaces et structurés où les équipes métiers, data engineers, BI developers et ops échangent sur les priorités, les obstacles et les retours utilisateurs. Cela favorise un cycle itératif de feedback continu, permettant d’ajuster rapidement les pipelines, les modèles et les visualisations.

Mais pourquoi donc doit-on rappeler que ce cycle itératif et vertueux, qui devrait être la norme, est trop souvent oublié ?

D’une part, parce que le développement logiciel (quel qu’il soit) hérite du bon vieux cycle en V (on spécifie, on développe, on livre et on s’aperçoit au final que le livrable ne correspond pas aux attentes). Sur le papier, ça fonctionne. Dans la réalité, le client est un expert de son domaine, pas un expert en spécifications ! Rien ne garantit qu’il sache exprimer son besoin de manière claire, précise et exhaustive.

D’autre part, les équipes Data (et surtout BI !) ont la fâcheuse tendance d’oublier dans leur estimation de projet toutes les phases « non productives ». A quoi bon chiffrer le temps passé en réunions avec le client ainsi que les éventuels livrables intermédiaires ? Si tout va bien, il ne sera pas nécessaire de perdre ce précieux temps, non ? (spoiler alert : ça ne se passe jamais aussi bien. Jamais !)

Dans Power BI, adoptez des revues de reporting régulières avec les utilisateurs finaux (hebdomadaires ou bi-hebdomadaires). Avant de mettre en production un nouveau dashboard, organisez une session où les métiers présenteront leurs objectifs du moment et où l’équipe BI montrera des prototypes, permettant des commentaires immédiats et actionnables.

Ainsi, au lieu de longues validations séparées ou de développements isolés, l’équipe intègre les changements et besoins métier en continu, ce qui réduit les dérives et augmente la qualité des insights. Gardez en tête que cette démarche sera pertinente si et seulement si les échanges réguliers (et le temps passé en réunions et en livraisons intermédiaires ou prototypage) sont pris en compte dans le chiffrage du projet. Le budget sera forcément plus important mais, au final, votre client vous en remerciera si la qualité du livrable est au rendez-vous.

Règle d’or #5 : rencontres quotidiennes, feedback continu. C’est la clé pour éviter les malentendus et accélérer la valeur.