Le changement de domaine : faire passer la gouvernance des données du triage des produits à l’investissement dans les infrastructures

Dans un article précédent sur le mandat en matière de données pour 2026, la loi européenne sur l’IA, la loi sur la cyber-résilience et la loi sur les données poussent les organisations à adopter des mandats structurels pour passer d’une conformité réactive à une gouvernance systémique par conception. Cependant, traduire cette intention architecturale dans les opérations commerciales quotidiennes introduit un goulot d’étranglement pratique : une fois les contrôles de gouvernance intégrés dès la conception, comment une organisation mesure-t-elle leur efficacité ?

Ayant travaillé dans des environnements où la gouvernance s’applique à des dizaines de produits plutôt qu’à des centaines, j’ai passé du temps à cartographier l’évolution du modèle opérationnel à mesure que le portefeuille se développe. La transition n’est pas linéaire. Ce qui fonctionne proprement à petite échelle commence à échouer à moyenne échelle, et à l’échelle de l’entreprise, cela échoue complètement. L’idée qui a résolu la tension ne concernait pas du tout les produits individuels. Il s’agissait de domaine. En entreprise, un domaine fait référence à un domaine d’expertise, de responsabilité ou d’orientation spécifique, tel que les finances, les ressources humaines, les achats, etc. Un mode d’échec courant observé dans les programmes d’entreprise consiste à traiter les produits individuels comme l’unité d’analyse principale, plutôt que le domaine plus large qui les englobe.

Le modèle opérationnel par défaut : le tri continu

La majorité des entreprises mettent déjà en œuvre des programmes formels de gouvernance. Pourtant, l’existence structurelle ne garantit pas la santé opérationnelle. Une étude de Gartner met en garde que jusqu’à 80 % des initiatives de gouvernance des données et des analyses devraient échouersouvent parce qu’ils traitent la gouvernance de manière réactive plutôt que de la relier à des résultats commerciaux évolutifs.

L’écart d’exécution est visible dans l’outillage. Données provenant d’évaluations de l’industrie publiées le Talénode confirme que cet écart d’exécution est dû à des goulots d’étranglement opérationnels, notant qu’environ 53 % des équipes de gouvernance des données s’appuient toujours sur des processus manuels comme les systèmes de billetterie et les feuilles de calcul pour gérer l’application des politiques. Le résultat est un modèle opérationnel par défaut qui suit un modèle reconnaissable.

Prenons l’exemple d’une équipe de gouvernance gérant 60 produits de données dans cinq domaines d’activité. À chaque sprint, les responsables travaillent dans une file d’attente : évaluent un produit, vérifient l’exhaustivité des métadonnées, signalent une configuration RBAC manquante, enregistrent une action, passent au suivant. L’ordre du jour du conseil de gouvernance devient un grand livre de tickets de produits individuels. La conversation reste réactive : quel produit est bloqué, lequel est presque certifié, lequel est bloqué au-delà des frontières organisationnelles.

Cette activité au niveau micro satisfait à une liste de contrôle de conformité. Il ne met pas à l’échelle un programme de gouvernance. Le coût cumulé est important : environ 45 % des professionnels des données signalent un épuisement professionnel, l’énergie étant consommée par des frictions isolées plutôt que par une amélioration structurelle. Avec 60 produits, c’est gérable. À 200 ans, cela devient un travail à temps plein. À 500, il cesse complètement de fonctionner. C’est un tri sans stratégie.

Isolation au niveau du produit et modèles au niveau du domaine

Lorsque la gouvernance opère exclusivement au niveau du produit, les modèles structurels au sein de l’organisation restent cachés. La résolution produit par produit s’attaque aux symptômes localisés plutôt qu’aux causes architecturales profondes.

Considérons le même problème vu sous deux angles différents :

L’objectif du produit : Cinq produits de données répartis dans trois domaines d’activité sont tous présents avec des configurations RBAC (Role-Based Access Control) manquantes. Une vue au niveau du produit présente cinq défaillances indépendantes et isolées attribuées à cinq responsables différents.

L’objectif du domaine : L’agrégation de ces vues révèle que le déploiement de RBAC échoue de manière uniforme dans plusieurs environnements. Ce n’est pas une question de gestion. C’est une panne d’infrastructure.

Cette distinction devient tangible lorsque les normes de gouvernance sont appliquées simultanément à plusieurs fonctions commerciales. Par exemple, la définition de normes de métadonnées dans tous les domaines vous montrera quelque chose que l’évaluation au niveau du produit oublie systématiquement : les mêmes lacunes apparaissent indépendamment dans les équipes sans propriété partagée, sans outils partagés et sans connaissance des problèmes de chacun. Étiquettes de propriété manquantes, modèles d’accès non documentés, conventions de dénomination incohérentes : tout cela apparaît à plusieurs reprises dans chaque fonction comme s’il s’agissait d’échecs distincts. Ce n’est pas le cas. C’est un échec exprimé quatre fois.

La lentille du domaine regroupe ces quatre conversations distinctes en une seule. Corrigez la norme une fois, au bon niveau, et la correction se propage à chaque fonction qu’elle touche.

Pour les décisions d’allocation de ressources, le domaine est l’unité d’analyse correcte et non le produit individuel.

Présentation de modèles avec une carte thermique de maturité de domaine

Une approche structurée pour rendre visibles ces dépendances architecturales est une Carte thermique de maturité du domaine: une grille cartographiant les domaines d’activité (lignes) par rapport aux piliers de gouvernance définis (colonnes), où chaque cellule indique le pourcentage de produits de ce domaine qui franchissent actuellement une porte de conformité spécifique.

Le modèle évite les scores composites et les moyennes subjectives, en se concentrant sur la validation des contrôles binaires. Soit un domaine a un contrôle qui fonctionne, soit ce n’est pas le cas.

Lorsqu’un parc d’entreprise est visualisé à travers cette grille, deux réalités structurelles émergent généralement.

Stabilité composée : Les domaines matures affichent une conformité cohérente dans toutes les colonnes. L’investissement historique et la propriété explicite se sont consolidés dans des pratiques d’ingénierie reproductibles. Les cellules vertes se regroupent parce que les fondations ont été construites délibérément.

Regroupement en colonnes : Dans les domaines en développement, les échecs surviennent rarement au hasard. Les non-conformités sont regroupées au sein de piliers spécifiques dans des domaines entièrement distincts. Dans l’exemple ci-dessus, Lineage et RBAC sont rouges simultanément pour les RH et les Achats. Ce ne sont pas des problèmes de RH ou des problèmes d’approvisionnement. Il s’agit de lacunes d’infrastructure à l’échelle de l’organisation qui font surface à deux endroits à la fois.

Ce regroupement est le principal signal de diagnostic. Si le traçage des données n’est pas conforme dans plusieurs unités commerciales en même temps, cela indique des défauts de conception du pipeline, des limitations des outils ou une ambiguïté des politiques systémiques, et non la performance de chaque gestionnaire.

Redéfinir la question de l’allocation des ressources en matière de gouvernance

Le déplacement de l’analyse analytique des produits individuels vers les piliers du domaine modifie la façon dont les dirigeants évaluent où déployer les ressources.

Si le suivi automatisé du lignage échoue dans six unités commerciales, affecter six responsables pour cartographier manuellement les pipelines constitue une utilisation inefficace du temps et du budget. L’approche systémique nécessite d’impliquer l’équipe principale de la plateforme de données pour identifier pourquoi les outils de collecte de métadonnées ne parviennent pas à produire des traces complètes. Le résoudre au niveau de la plate-forme corrige simultanément l’état de conformité de tous les domaines dépendants.

À l’inverse, si un seul domaine n’est pas conforme dans presque tous les piliers, cela indique un déficit de maturité fondamental : la propriété n’est pas claire, les normes n’ont pas été appliquées et les produits dans ce domaine sont loin d’être certifiés. L’intervention requise est un programme dédié d’amélioration du domaine pour établir la propriété et les normes de base des données. En pratique, cela pourrait ressembler à ceci :

• Premièrement : établir une propriété claire des données afin que chaque produit ait un humain responsable
• Deuxièmement : appliquer les métadonnées de base et les normes de documentation avant que les portes de certification ne soient appliquées.
• Troisièmement : effectuer une évaluation légère de l’état de préparation pour comprendre quels contrôles sont véritablement manquants ou simplement non documentés.

Une fois les bases établies, la certification au niveau du produit devient un exercice productif.

La question qui mérite d’être posée avant chaque réunion du Conseil de gouvernance

Avant d’examiner l’état d’un produit individuel ou le retard d’un projet, il convient de se poser une question en premier :

« Quels sont les piliers de la gouvernance qui échouent dans plusieurs domaines ? »

Un pilier défaillant dans plusieurs domaines mérite l’attention du conseil avant tout produit individuel. Donner la priorité à une défaillance systémique d’un pilier plutôt qu’à un retard au niveau du produit garantit que la fonction de gouvernance agit comme un investissement dans les infrastructures plutôt qu’une porte de contrôle de qualité. Il fait passer le modèle opérationnel de la résolution d’une file d’attente réactive à l’établissement des conditions techniques dans lesquelles des domaines entiers peuvent évoluer et se conformer de manière organique.

Ce que la Heatmap ne vous dit pas

La vue du domaine identifie où un système est défaillant. Cela n’explique pas pourquoi. Un domaine signalant une faible conformité en matière de traçabilité des données peut être dû à plusieurs causes profondes distinctes :

• Les outils d’ingestion automatisés sont déconnectés des pipelines du domaine.
• L’architecture de données sous-jacente n’est pas standard, ce qui empêche la collecte automatisée de métadonnées.
• Les rôles de propriétaire des données n’ont pas été officiellement attribués au sein de cette unité commerciale.

Le pourcentage semble identique dans chaque scénario. Considérons deux domaines affichant tous deux 15 % de lignée. Dans l’un d’entre eux, l’outillage n’est tout simplement pas connecté – une solution d’une journée. Dans l’autre, personne n’a cartographié les flux de données parce que la propriété n’a jamais été établie – un programme de travail de plusieurs semaines. La Heatmap ne fait pas de distinction entre eux. Un spécialiste doit le faire.

Ce qu’il remplace, c’est l’agenda subjectif. Des réunions du conseil où personne ne s’accorde sur le domaine à prioriser ou sur les contrôles les plus importants ce trimestre. Avec une vision de la maturité du domaine, toutes les personnes présentes dans la salle travaillent à partir de la même image objective du patrimoine de données de l’entreprise avant même que le premier produit ne soit discuté.

La gouvernance comme infrastructure

Une gouvernance au niveau du produit est nécessaire. Ce n’est pas suffisant. Les programmes qui mûrissent et évoluent le plus rapidement sous la pression de la réglementation moderne ne sont pas ceux qui examinent le plus grand volume de billets individuels. Ce sont eux qui prennent du recul, examinent les modèles au niveau du domaine, corrigent d’abord les lacunes architecturales systémiques et regardent les mesures au niveau du produit s’améliorer en conséquence naturelle.

---

Avant de partir…

Suivez-moi pour ne manquer aucun nouveau message que j’écrirai à l’avenir ; vous trouverez plus de mes articles sur ma page de profil. Vous pouvez également me contacter sur LinkedIn ou X!