Après la phase de Data Anarchy, où les données sont gérées de manière décentralisée et décousue, l'arrivée d'une équipe Data dans une organisation peut conduire à un phénomène que l'on pourrait qualifier de "Data Monarchy". Ce concept permet de mettre en avant la transversalité et la maîtrise des flux d’information de l’équipe data, ce qui lui confère rapidement une position centrale dans une organisation.
Par sa position transverse et son accès privilégié à l’information, la nouvelle équipe data va progressivement avoir une propension à jouer un rôle centralisateur au sein de l’organisation. Cela ne signifie pas que l'équipe Data prend le contrôle total de l'entreprise, mais que cette dernière doit passer par une étape de transition pour imposer des changements importants dans la manière de gouverner ses données. L’objectif est clair : permettre à l’organisation de prendre des décisions structurantes pour le business, fondées sur des données fiables.
A ce sujet, je pense à l’équilibre qu’un souverain doit trouver pour asseoir son autorité tout en conservant une forte popularité. C'est particulièrement délicat, car cela implique de concilier deux sources de légitimité qui peuvent entrer en tension : l’autorité institutionnelle et le consentement populaire.
D’un côté, l’autorité souveraine repose sur la capacité du dirigeant à incarner la stabilité, à faire respecter les règles et à garantir l’ordre, ce qui exige parfois des décisions impopulaires ou des mesures contraignantes. Si le souverain s’appuie exclusivement sur cette autorité sans tenir compte de l’opinion et des attentes du peuple, il risque de tomber dans l’autoritarisme et de perdre complètement l’adhésion populaire.
De l’autre côté, la popularité du souverain découle de sa capacité à représenter la volonté générale, à écouter et intégrer les aspirations du peuple, à justifier ses décisions par des explications claires, raisonnées, pour obtenir le consentement de la majorité. Cependant, une autorité fondée uniquement sur la recherche de l’approbation populaire peut conduire à un manque de vision, à une perte de crédibilité, à de l’instabilité, et surtout à l’incapacité de prendre des décisions difficiles mais nécessaires à long terme.
Nous explorerons ici les différents aspects de la Data Monarchy, ses avantages potentiels mais aussi les risques qu'elle comporte. L'objectif est de voir comment bien amener cette phase de transition, de manière constructive et collaborative.
L'avènement de la Data Monarchy
La Data Monarchy émerge souvent dans un contexte où l'organisation prend conscience de l'importance stratégique de ses données et décide d'investir dans la mise en place d'une équipe dédiée. Cette équipe arrive avec une vision moderne de la gestion des données et l'ambition d'amener des pratiques "data-centric" dans l'entreprise.
Centraliser des décisions liées aux données
La plateforme data centralise, agrège et met en relation toutes les données essentielles de l'entreprise. Bien que située en bout de chaîne, la plateforme data commence par consommer une grande variété de sources de données. Il y a donc à la fois un large spectre d'évaluation des données et une forte dépendance aux données sources. Cette situation implique donc qu'une grande partie du travail de l'équipe data se construise autour de la modélisation des données à un niveau global de l'entreprise, tout en intégrant qualité et documentation.
Ce rôle d'évaluateur est important, cependant il peut rapidement être perçu comme irritant s'il n'est pas basé sur des conseils constructifs. Son but est d'orienter et d'encourager l'amélioration, en expliquant avec pédagogie les erreurs et les leviers d'amélioration à l'aide des principes de data gouvernance et de data quality. Le point essentiel est la collaboration des différentes équipes, aussi bien tech' que non tech', pour que tout le monde puisse s'approprier petit à petit les standards de qualité que doit respecter une plateforme data.
L'arrivée de projets Big Data introduit des technologies plus spécialisées et des méthodes de travail souvent peu connues par les software engineers. On peut parler des outils de traitement de données massives (comme Spark, Flink, BigQuery, Snowflake ou DataBricks), des Data contracts, des Data catalog ou des orchestrateurs (comme Airflow ou Kestra).
Et inversement, il faut noter que des compétences essentielles issues du software engineering sont essentielles au data engineering : produire du code SOLID, utiliser le versioning (Git) et le CI/CD, appliquer des principes de clean code, maîtriser les tests automatisés. Ce sont des atouts majeurs pour garantir la vélocité des développements et la résilience des pipelines de données.
Au même titre que le mouvement DevOps a redéfini les frontières entre développement et exploitation en imposant des pratiques transversales, la mise en place d’une solution Data induit l’introduction de pratiques globalisantes qui touchent l’ensemble de l’organisation. Une plateforme data moderne ne se limite pas à collecter et stocker des données : elle impose des normes de qualité, de traçabilité, de documentation, de gouvernance et de partage.
DataOps, une culture du décloisonnement
DataOps (pour Data Operations) est une méthodologie collaborative de gestion et de gouvernance des données, conçue pour optimiser la communication, l’intégration et surtout l’automatisation des flux de données entre les différents acteurs d’une organisation, notamment les gestionnaires et les consommateurs de données.
DevOps et DataOps partagent une philosophie d’automatisation, d’agilité et de collaboration, mais s’appliquent à des domaines différents : DevOps optimise la livraison logicielle, DataOps optimise la chaîne de valeur de la donnée, en mettant l’accent sur la qualité, la gouvernance et la conformité des données.
Comme le DataOps fusionne métier, produit et ingénierie, il peut bousculer les habitudes et susciter différentes réactions de la part des équipes existantes :
- Curiosité et intérêt : Certains collaborateurs verront l’arrivée d’une équipe data comme une opportunité de monter en compétence, d’accéder à de nouveaux outils ou de résoudre plus efficacement des problématiques complexes grâce à l’analyse de données.
- Adhésion progressive : Une fois les premiers succès concrets visibles (par exemple, un dashboard simple qui apporte une valeur directe), l’adhésion s’accélère si la direction soutient activement la démarche et que les bénéfices sont clairement exposés.
- Réticences et résistances : le changement peut générer des craintes. Peur de perdre le contrôle sur certains périmètres, d’un bouleversement des processus établis, ou sentiment que l'expertise de l'un ou de l'autre est remise en question. Ces résistances peuvent arriver lors de l’introduction de nouvelles expertises ou de la nécessité de casser les silos entre métiers et IT.
- Incompréhension des rôles : Il peut y avoir des interrogations sur la répartition des responsabilités et des périmètres. C'est pourquoi il est important de rapidement définir des data owners, des politiques d'accès et de partage des données grâce notamment aux data stewards. La data peut révéler de l'incohérence dans les processus globaux de l'organisation, ce qui peut être mal vécu et donner l'impression aux équipes d'avoir mal fait leur travail.
- Intégration et transversalité : Comme l'approche de la plateforme data est globalisante, cela met en avant bien plus facilement les problèmes de silos des projets et de leurs données. Il est parfois délicat de remonter le grand nombre de problèmes d'architecture, d'incohérence de modélisation ou de manque de qualité de données. L' approche doit toujours être bienveillante et orientée solution.
DataOps est donc une approche méthodologique et culturelle qui vise à rendre la gestion des données plus rapide, fiable, collaborative et alignée sur les besoins métiers, en s’appuyant sur l’automatisation, l’agilité et la gouvernance. Ce n’est pas une technologie, mais un ensemble de bonnes pratiques et d’outils permettant d’optimiser la chaîne de valeur de la donnée dans l’entreprise.
Si la méthodologie DataOps présente de nombreux avantages en facilitant la collaboration entre les équipes métier, produit et ingénierie, elle peut amener un risque de dilution des rôles et des responsabilités. Sans cadre, il peut y avoir des zones grises où les responsabilités ne sont pas bien attribuées.
Respect du périmètre et des responsabilités
L’équipe data a pour mission principale de transformer les données de l’entreprise en informations exploitables. Elle intervient sur l’ensemble du cycle de vie de la donnée : collecte, structuration, traitement, analyse, restitution et archivage, tout en accompagnant les métiers dans la prise de décision grâce à des analyses fiables et pertinentes.
Comme l'équipe data dispose de toutes les données, il peut être tentant de prendre un raccourci et lui faire porter des développements opérationnels. Du fait qu’elle ait un accès privilégié aux données, une expertise technique et une bonne vision transverse, beaucoup de «demandes business » s'avèrent en fait être des développements produits.
Détecter rapidement les symptômes du “data empire”
Pourquoi est-il tentant de faire porter de plus en plus de sujets par l'équipe data ?
- Accès rapide aux données : les équipes data ont déjà quasiment tous les flux de données et la maitrise des modèles du système d'information. Ils peuvent itérer rapidement.
- Compétences techniques et fonctionnelles élevées : des data engineers ou analytics engineers sont capables de faire du code quasi-produit (APIs, dashboards…) tout en ayant une vision globale des sujets de l'entreprise.
- Culture “delivery” et “dead-line driven” : le management veut aller vite, peu importe les moyens mis en oeuvre. Et les équipes data aiment souvent débloquer les sujets. Le backlog produit est bien engorgé, l'équipe data va savoir se rendre “disponible” pour ces sujets prioritaires et sera “rapide” avec toutes les données dont elle dispose. Mais à force de trop débloquer, avec ce rôle central et valorisant, elle se retrouve à faire le boulot de tout le monde.
Il est essentiel que l’équipe data n’empiète pas sur les prérogatives des autres équipes. Elle doit agir en partenaire, et non se substituer à la gestion opérationnelle propre à chaque spécialité. S’arroger des responsabilités qui ne relèvent pas de son champ d’action sera contre-productif : la data produit des scripts ou des APIs qui finissent en production sans cadre clair (shadow IT / produits parallèles). Moins de tests, manque progressif de scalabilité par accumulation de “quick wins” qui deviennent de la dette technique. L’équipe data devient un goulot d’étranglement et les autres équipes se déresponsabilisent. Les équipes métiers ou produit ne prennent plus vraiment la responsabilité des logiques fonctionnelles, tout passe “chez la data”. Le produit demande de plus en plus à la data de « bricoler » au lieu d’intégrer les besoins en bonne et due forme et de créer des produits solides et efficients.
Il faut mettre chaque responsabilité et technologie au bon endroit :
- Si un workflow marketing est dans un modèle dbt, c’est un anti-pattern : il doit être dans l’outil de marketing automation.
- Si un process de comptabilité fait l'objet d'un workflow d’alerte dans Airflow, ça sent le bricolage. Il doit être remonté directement dans les outils comptables, même si on doit adapter ou enrichir leur modélisation / APIs.
Pourquoi les empires chutent-ils ?
- Trop centralisés, ils étouffent la périphérie : Quand tout dépend du centre, les équipes locales perdent en autonomie.
- Expansion trop rapide = perte de contrôle : À force de vouloir tout couvrir, on gère mal les frontières. Les priorités se diluent, la dette s’accumule, les fissures apparaissent.
- Déconnexion du terrain : Le centre croit savoir mieux que les autres ce qu’il faut faire. Mais sans feedback réel, la réalité opérationnelle est implacable.
- Fatigue : De tout porter, l’empire croule sous sa propre grandeur.
Au contraire, chacun doit continuer à capitaliser sur ses points forts. Et l’équipe data se concentre sur l'aspect analytique et la cohérence globale des systèmes, tout en laissant les développements opérationnels à qui de droit.
Data monarchy : gouverner pour structurer
First things first, il faut bien comprendre le contexte et les besoins de l'entreprise.
« Donnez-moi six heures pour couper un arbre, et je passerai les quatre premières à aiguiser ma hache. » — Abraham Lincoln
Cette citation illustre parfaitement que pour réussir une tâche complexe, il faut se concentrer sur une bonne préparation. Le data architect est le premier maillon de la chaîne, car il conçoit l’infrastructure qui va structurer, sécuriser et organiser la donnée avant même que les autres spécialistes n’interviennent. Son rôle est de comprendre les besoins métiers, d’évaluer l’existant, puis de recommander et mettre en place des solutions adaptées, évolutives et conformes aux exigences.
Un bon data architect garantit que les données seront accessibles, fiables et exploitables par tous, tout en assurant la performance, la sécurité et la conformité du système. Il doit posséder à la fois des compétences techniques pointues, une vision globale, et une capacité à collaborer avec des profils variés (métiers, logiciels, produits). Sans cette expertise en amont, l’architecture risque d’être inefficace, coûteuse ou source de blocages pour les projets futurs, d’où l’importance de placer ce profil au cœur de toute démarche data structurée.
« La politique consiste à rendre possible ce qui est nécessaire. » — Richelieu
Je pense à Richelieu dans sa capacité à structurer, anticiper et gouverner avec une vision d’ensemble et une rigueur implacable. Comme le cardinal, qui a su centraliser le pouvoir, renforcer l’État et poser les fondations de la France moderne, le data architect conçoit une architecture solide, cohérente et évolutive, capable de servir durablement les intérêts de l’organisation. Il sait que chaque décision technique façonne l’avenir, que la méthode importe autant que l’exécution, et que la prévoyance est la clé pour éviter les crises futures.
“Le meilleur chef est celui dont les hommes disent, une fois la tâche accomplie : ‘Nous l’avons faite nous-mêmes.’” — Lao Tseu
Un royaume est centralisé, mais d'abord fédéré. La data centrale devient un corps d'experts dans le domaine Data qui forment, conseillent, outillent, mais ne font pas tout à la place.
Chaque province (équipe, domaine) gère ses propres données (ownership clair), avec une auto-discipline sur les pratiques devenue naturelle :
- data contracts
- SLAs
- Processus de gouvernance et de gestion du cycle de vie
- Gestion des incidents et escalade
- Standards de modélisation et de documentation
- Normes de qualité et d’intégrité des données
Pour ancrer durablement une culture data dans l’organisation, il est essentiel de créer des instances et des dynamiques qui favorisent l’appropriation collective. Un "data council" inter-domaines permet de faire émerger les priorités stratégiques et les arbitrages nécessaires.
En parallèle, il est judicieux d’identifier des data champions dans chaque équipe produit ou métier : ces relais locaux jouent un rôle clé dans la diffusion des bonnes pratiques, la remontée des besoins, et l’alignement des usages avec les capacités techniques.
Enfin, pour entretenir une dynamique vivante, des rituels internes doivent être instaurés : formations régulières, ateliers et revues de gouvernance, ou encore démos sont autant de leviers pour favoriser la montée en compétence et l’alignement continu autour des enjeux data.
Conclusion
La Data Monarchy, bien que potentiellement bénéfique pour moderniser rapidement les pratiques de gestion des données d'une organisation, comporte des risques significatifs si elle est appliquée de manière trop abstraite. La clé du succès réside dans une approche collaborative, où l'équipe Data favorise la participation, l'acculturation et la responsabilisation de l'ensemble des collaborateurs.
A partir du moment où tous les membres de l'organisation ont compris les grands principes de travail pour construire et maintenir une plateforme data cohérente, on peut alors évoluer vers une véritable démocratie des données. Chacun pourra alors contribuer à la création de valeur avec une forte autonomie. Dans le dernier article de cette série, nous aborderons les principes de "Data Mesh" et de "Shift Left" pour décentraliser la gestion des données, responsabiliser les équipes dans la production, la gouvernance et la qualité des données.
