« Pouvez-vous me montrer, en une page, quelles données sont critiques pour votre stratégie ? » Quand je pose cette question, j’ai généralement un silence. « On a un catalogue. On a des dashboards. Mais une page… » , est fréquemment la réponse que je reçois. Cette incapacité n’est pas un aveu d’incompétence. C’est un symptôme beaucoup plus répandu qu’on ne veut bien l’admettre. Ce constat est largement partagé : selon Gartner, près de 80 % des initiatives de gouvernance des données échouent, principalement en raison d’un manque d’alignement entre IT et métier.

Les entreprises dépensent aujourd’hui des budgets considérables en gouvernance des données. Data catalogs, data quality tools, Master Data Management, plateformes de lineage, Chief Data Officers, comités de gouvernance — l’arsenal est impressionnant. Et pourtant, la donnée ne sert toujours pas la stratégie. Elle sert les reportings. Elle sert la conformité. Rarement le futur.

Ce n’est pas un problème d’outil, c’est vraiment un problème d’approche du sujet qui généralement se fait généralement par le tech. Comme le souligne McKinsey, les programmes de gouvernance des données échouent lorsqu’ils sont traités comme une fonction IT de support plutôt que comme un levier de création de valeur métier.

La tech passe par le bas alors qu’aujourd’hui, elle devrait passer par le haut, car notre monde est technologique et s’organise autour de la data.

Peindre les données en digital ne suffit pas

Dans mon article De l’économie de produits à l’économie de flux, j’écrivais que nous confondons trop souvent la vitesse et la direction — que nous empilons des solutions sans nous demander à quelle structure invisible elles se rattachent. La gouvernance des données illustre parfaitement cette confusion.

On a importé les méthodes de la qualité industrielle dans le monde de la donnée. On certifie, on trace, on audite. C’est nécessaire. Ce n’est pas suffisant. Parce que cette démarche répond à la question comment — comment gouverner la donnée — avant même d’avoir répondu aux questions qui la précèdent : quelles données et au service de quoi.

C’est l’équivalent de peindre les murs avec soin, avec méthode, avec les bons outils — sans avoir les plans de l’architecte. Le résultat est propre. Il ne tient pas la stratégie.

Un distributeur alimentaire que j’ai accompagné il y a quelques années avait déployé un outil de data governance reconnu par Gartner, avec des processus rigoureux de certification de la donnée produit. Résultat : des données parfaitement gouvernées… sur des références que la direction avait décidé d’abandonner six mois plus tôt. L’outil ne savait pas ce que l’entreprise était en train de devenir. Il savait ce qu’elle avait été.

Le vrai problème : on gouverne les données de ce qu’on fait, pas de ce qu’on veut devenir

On cherche trop souvent à résoudre des problèmes plutôt que de créer le futur

Une organisation n’est pas un entrepôt de données. C’est un système de capabilities — des capacités métiers élémentaires, stables, répétables, qui produisent de la valeur. La capability gérer les retours, la capability décider un crédit, la capability assurer la disponibilité stock en omnicanal — ce sont ces engagements métiers qui consomment la donnée, qui lui donnent son sens, qui lui confèrent sa criticité.

Or, la gouvernance des données telle qu’elle est pratiquée dans la plupart des organisations ne part pas de là. Elle part des systèmes. Elle gouverne ce qui transite dans les tuyaux, sans cartographier les besoins en amont — sans jamais répondre à la question fondamentale : quelle capability se nourrit de cette donnée, et quel est son poids dans la création de valeur de l’entreprise ?

J’ai développé ce point dans mon article récent L’IA agentique explose, la gouvernance reste une illusion technique : l’unité de gouvernance pertinente n’est pas le workflow, ni le modèle, ni l’agent. C’est la capability. Cette conviction ne date pas de l’IA agentique — elle est le fondement de trente ans de travail sur l’alignement Business ↔ SI. L’agentique l’a simplement rendue urgente.

Sans Business Capability Mapping, la gouvernance des données est aveugle. Elle voit les données. Elle ne voit pas ce pour quoi elles existent.

Ce que le Business Capability Mapping change

Le BCM n’est pas un outil IT. C’est une décision de direction. C’est le moment où une organisation assume l’architecture de son propre business model — où elle dit explicitement : voici ce que nous faisons vraiment, voici ce qui est différenciant, voici ce qui est périphérique.

Cette cartographie change radicalement la gouvernance des données pour trois raisons.

Elle crée une hiérarchie de valeur. Toutes les données ne se valent pas. Une capability différenciante — disons, pour un retailer spécialisé, la personalisation de l’offre au niveau de la maille client — mérite une gouvernance rigoureuse, des investissements en qualité de donnée, une surveillance active. Une capability commodité — disons, la gestion des notes de frais — mérite une gouvernance standard, sans plus. Sans BCM, on gouverne tout avec la même intensité. C’est-à-dire, en pratique, qu’on ne gouverne rien vraiment.

Gouverner c’est choisir, choisir un investissement, et de plus en plus en temps réel, le faites-vous sur vos data, sur vos applications ?

La cartographie rend visible la responsabilité au bon niveau. Dans un Codir, personne ne revendique la propriété d’un dataset. Tout le monde revendique la propriété d’une capability. Le BCM transforme la gouvernance des données en conversation métier — non plus en arbitrage technique. C’est exactement le glissement que j’évoquais dans mon article sur l’agentique : basculer d’une gouvernance technique à une gouvernance par le métier.

Elle anticipe le futur, pas seulement le passé. Une capability est stable dans le temps — même si son implémentation change. Gérer la relation client est une capability permanente, qu’on l’exécute avec un CRM, un agent IA ou un conseiller humain. Gouverner les données d’une capability, c’est gouverner pour ce que l’entreprise veut devenir — pas seulement pour ce qu’elle est aujourd’hui.

Trois questions à poser avant tout projet de data governance

Je les pose systématiquement. Elles déstabilisent. C’est leur rôle.

Peut-on lire votre stratégie dans votre modèle de données ? Si votre business model a basculé vers le service, vers la personnalisation, vers la relation — et que votre modèle de données décrit encore des flux produits et des transactions liés à un modèle de distribution, vous n’avez pas un problème de qualité de données. Vous avez un problème de désalignement fondamental.

Vos équipes data connaissent-elles vos capabilities différenciantes ? Dans la plupart des organisations que j’accompagne, la réponse est non. Les data engineers connaissent les pipelines. Les data stewards connaissent les référentiels. Personne ne sait, dans l’équipe data, pourquoi telle capability vaut plus que telle autre pour la création de valeur de l’entreprise. C’est comme construire une cathédrale sans en connaître la liturgie.

Quand vous investissez en data quality, sur quelle capability investissez-vous réellement ? Cette question est la plus déstabilisante. Elle révèle que, dans la majorité des cas, les investissements en gouvernance des données ne sont pas pilotés par la valeur. Ils sont pilotés par la complexité technique perçue, ou par la pression réglementaire. Ce n’est pas la même chose.

La gouvernance des données à l’ère de l’IA : un enjeu désormais existentiel

Nous vivons, comme je l’écrivais dans De l’économie de produits à l’économie de flux, dans un monde où la donnée est devenue la nouvelle énergie — et où chaque organisation qui ne maîtrise pas sa circulation est condamnée à la subir. Cette assertion prend aujourd’hui une nouvelle dimension avec l’IA générative et les agents autonomes.

Les modèles d’IA se nourrissent de données. Mais ils ne font pas la différence entre une donnée critique pour votre stratégie et une donnée anecdotique. Ils amplifient ce qu’on leur donne. Si vous leur donnez des données mal gouvernées — ou bien gouvernées mais déconnectées de vos capabilities différenciantes — vous n’amplifiez pas votre avantage compétitif. Vous amplifiez votre désalignement. C’est ce que je résume depuis longtemps par une formule simple : amplifier du vide reste un exercice futile.

Le BCM devient ainsi la précondition de toute gouvernance sérieuse à l’ère de l’IA. Non pas parce que c’est une nouvelle mode managériale. Parce que sans lui, vous n’avez aucun moyen de répondre à la question que tout agent IA vous posera, implicitement, à chaque décision : au service de quelle intention métier dois-je opérer ?

Ce qu’il reste à faire — et c’est maintenant

La bascule n’est pas technique. Elle est de gouvernance, au sens le plus fondamental du terme.

Maîtriser ses invariants — définir explicitement les capabilities qui fondent votre modèle économique, celles qui sont différenciantes, celles qui sont commodités, celles qui sont à risque.

Gouverner par la valeur — aligner chaque investissement en data quality sur une capability identifiée, mesurable par un outcome métier, portée par un propriétaire humain.

Aligner Business et SI autour d’un langage commun — le BCM est ce langage. Il ne remplace ni l’outil de gouvernance, ni la plateforme data. Il leur donne une direction.

Depuis trente ans, j’ai accompagné l’introduction de chaque grande vague technologique dans les organisations. Java, le cloud, l’IoT, le machine learning. Chaque fois, le même schéma : les organisations qui ont maîtrisé leurs fondations ont amplifié leur avantage. Les autres ont amplifié leur désalignement.

La gouvernance des données n’échappe pas à cette règle. Elle l’illustre avec une précision redoutable.

La donnée sans capability est du bruit. La capability sans donnée est aveugle. La gouvernance sans Business Capability Mapping est les deux à la fois.