Charles Ngando Black – Fondateur et Président iDAIp et Marc Vengadabady – Cofondateur et CTO Yavantha
Dans beaucoup d’organisations, la conformité se prouve encore à la main, audit après audit. Le risque se pilote encore sur des données dont la fiabilité n’a pas été établie en amont. Et transformer les données en information utile, en connaissance opérationnelle, en décisions éclairées ? Cela se fait — mais de manière non cadrée et non fiable.
La gouvernance existe. Elle pilote les données. Rarement les décisions qui s’appuient sur elles.
Pourquoi ? Parce que la manière dont elle a été conçue, et dont elle est déployée, ne lui permet pas de devenir ce qu’on attend d’elle.
Ce que nous avons construit jusqu’ici
Depuis une quinzaine d’années, la gouvernance des données s’est structurée autour d’un modèle dominant : identifier les données critiques, définir des responsabilités, documenter les règles, outiller les processus. Le RGPD a accéléré le mouvement côté conformité. BCBS 239, Solvabilité II, DORA l’ont imposé côté régulation financière et assurantielle.
Le résultat est visible : des organisations mieux conscientes de leurs données, des catalogues plus fournis, des rôles mieux définis.
Mais regardons l’autre face : des programmes qui durent trois, quatre, cinq ans sans produire de valeur mesurable. Des Data Offices qui peinent à démontrer leur ROI. Des équipes métier qui contournent les processus de gouvernance parce qu’ils les ralentissent.
La réponse dominante a longtemps été cohérente avec son époque. Quand les organisations ont commencé à prendre conscience de leurs données, l’urgence était de les recenser, d’en établir la traçabilité, d’en encadrer l’usage. La conformité réglementaire a renforcé cette logique : documenter, tracer, contrôler. C’était nécessaire.
Mais un dispositif de contrôle a une limite structurelle : il regarde en arrière. Il vérifie ce qui a été fait. Il ne prépare pas ce qui doit être décidé. Or piloter, c’est précisément préparer des décisions — pas auditer des données.
La gouvernance des données a été pensée comme un dispositif de contrôle. Elle devrait être pensée comme un dispositif de décision. Le dispositif de contrôle produit de la documentation. Il ne produit pas de la confiance dans les décisions.
Ce que « levier de pilotage » veut dire
Une gouvernance devient un levier de pilotage lorsqu’elle permet de définir les conditions dans lesquelles une décision peut être prise, de vérifier que ces conditions sont satisfaites, et de démontrer a posteriori pourquoi cette décision pouvait être considérée comme fondée. Tant qu’elle se limite à documenter les données sans organiser explicitement leur contribution aux décisions, elle améliore la connaissance du patrimoine informationnel — sans transformer réellement la capacité de pilotage de l’organisation.
Première rupture : concevoir à partir des décisions, pas des données
La conception classique de la gouvernance part des données : quelles sont-elles, qui en est responsable, comment les qualifier, comment les stocker. C’est une logique de patrimoine.
Or une organisation ne pilote pas un patrimoine. Elle prend des décisions.
La vraie question n’est pas « quelles données avons-nous ? » mais « quelles décisions devons-nous prendre, et de quelles données ces décisions ont-elles besoin pour être fiables ? »
Ce renversement n’est pas sémantique. Il change tout à la conception du dispositif :
— Les exigences de qualité ne sont plus génériques — elles sont indexées sur les décisions qu’elles servent.
— Les règles de transformation ne sont plus des contraintes techniques — elles sont des garanties de cohérence entre la donnée et le raisonnement qui la mobilise.
— Le glossaire n’est plus un dictionnaire de termes — c’est le socle d’un langage commun entre la donnée et la décision.
— Les KPI de gouvernance ne mesurent plus la complétude d’un catalogue — ils mesurent la confiance dans les décisions.
Ce que la mauvaise conception coûte vraiment
On sous-estime rarement le coût financier ou technique d’un programme de gouvernance mal conçu. On sous-estime presque toujours son coût organisationnel.
Quand la gouvernance est pensée autour des données plutôt que des décisions, chaque partie prenante la lit à travers le prisme de son propre périmètre. La DSI y voit un projet d’infrastructure. La direction des risques y voit un outil de conformité. Les métiers y voient une contrainte supplémentaire. La direction data y voit un programme transverse dont personne ne veut vraiment assumer la charge.
Le résultat est prévisible : des comités de gouvernance où l’on débat de définitions pendant des mois. Des arbitrages sur la propriété des données qui opposent des directions sans qu’aucune ne se sente vraiment légitime. Des projets pilotes qui avancent dans leur coin et produisent des référentiels incompatibles. Des équipes métier qui, lassées d’attendre, construisent leurs propres solutions en dehors du programme officiel.
Ces frictions ne sont pas des problèmes de personnes. Elles sont des problèmes de conception. Quand le dispositif est centré sur les décisions, les périmètres se clarifient naturellement : chaque direction sait quelles décisions elle prend, de quelles données elle a besoin, et à quelles conditions elle peut leur faire confiance. Le débat se déplace — de ce qu’il faut gouverner à comment le gouverner. C’est un débat beaucoup plus productif.
Cette première transformation produit un second effet. Dès lors que la gouvernance est conçue à partir des décisions, une partie croissante du dispositif devient structurable, transmissible et réutilisable. Les décisions critiques, les exigences qui les encadrent, les règles qui les soutiennent, les données qu’elles mobilisent — tout cela cesse d’être des artefacts propres à une organisation. Ils deviennent les éléments d’un socle que d’autres organisations peuvent adopter puis adapter.
Ce que « levier de transformation » veut dire
Une gouvernance devient un levier de transformation lorsqu'elle peut être déployée, adoptée et exploitée dans des délais compatibles avec les attentes de l'organisation. Tant que sa mise en œuvre exige plusieurs années de travaux préparatoires, une mobilisation continue des métiers et des efforts importants de documentation avant de produire les premiers résultats, son adoption reste fragile. La gouvernance cesse alors d'être perçue comme un accélérateur de transformation et devient elle-même un objet de transformation. Un véritable levier de transformation réduit les délais, les frictions et les coûts d'adoption afin de permettre à l'organisation de concentrer ses efforts sur l'exploitation de la gouvernance plutôt que sur sa construction.
Deuxième rupture : déployer sur un socle, pas sur une page blanche
Il y a une distinction que les programmes de gouvernance font rarement, et qui coûte cher : la différence entre construire pour la première fois et reconstruire dans des conditions déjà connues.
Partir d’une page blanche est légitime quand le problème est inédit. Ce n’est pas le cas de la gouvernance des données dans la plupart des secteurs. Les exigences réglementaires sont documentées et relativement stables. Les décisions critiques d’un métier sont connues. Les règles de qualité qui s’y attachent, les transformations nécessaires, les indicateurs de surveillance — tout cela a déjà été construit, quelque part, par quelqu’un.
Repartir de zéro dans ce contexte, c’est ignorer délibérément l’expérience accumulée. Pourtant c’est ce que fait chaque programme : chaque consultant redocumente les mêmes exigences, chaque équipe métier redéfinit les mêmes règles, chaque organisation réinvente le même socle.
Le coût n’est pas seulement temporel. Il est humain. Les équipes qui passent dix-huit mois à construire un référentiel avant de pouvoir l’utiliser arrivent à la phase de déploiement épuisées, convaincues que la gouvernance est synonyme de lourdeur. L’adoption part perdante.
La prochaine génération de gouvernance reposera davantage sur l’adoption et l’adaptation que sur la reconstruction systématique des mêmes fondations.
Préconfigurer ne veut pas dire imposer. Cela signifie fournir aux organisations un socle intelligible, adapté à leur secteur, couvrant les dimensions clés du dispositif — exigences, règles, termes, indicateurs — et leur permettre de l’adopter, de le compléter, de le personnaliser sans repartir de rien. Un programme qui démarre avec ce socle gagne plusieurs mois d’effort initial. Surtout, il produit des résultats visibles tôt — et des résultats visibles tôt produisent de l’adhésion.
Plus important, les organisations peuvent consacrer davantage d’énergie à l’exploitation de leur gouvernance qu’à sa construction. Le sujet cesse progressivement d’être la production de connaissance et devient sa mobilisation effective dans les décisions.
Refermer la boucle
Revenons à la définition posée plus haut.
Une gouvernance devient un levier de pilotage lorsqu’elle permet de définir les conditions dans lesquelles une décision peut être prise, de vérifier que ces conditions sont satisfaites, et de démontrer a posteriori pourquoi cette décision était fondée.
Aucun de ces trois actes n’est possible si le dispositif n’a pas été conçu à partir des décisions. Aucun n’est tenable à l’échelle si le dispositif a été construit de zéro, à bout de souffle, sur des bases que personne n’a eu le temps de stabiliser.
Ensemble, ces deux transformations poursuivent des objectifs différents mais complémentaires. La première transforme la gouvernance en levier de pilotage en reliant explicitement les données aux décisions qu'elles doivent soutenir. La seconde transforme la gouvernance en levier de transformation en réduisant les délais, les frictions et les efforts nécessaires à son déploiement et à son adoption.
L'une permet de mieux décider. L'autre permet d'y parvenir plus rapidement et plus durablement. C'est de leur combinaison que dépend la capacité des organisations à faire de la gouvernance autre chose qu'un dispositif de contrôle ou de documentation : un véritable outil de pilotage et de transformation.
La gouvernance existe. Elle pilote les données. Rarement les décisions qui s’appuient sur elles.
Pourquoi ? Parce que la manière dont elle a été conçue, et dont elle est déployée, ne lui permet pas de devenir ce qu’on attend d’elle.
Ce que nous avons construit jusqu’ici
Depuis une quinzaine d’années, la gouvernance des données s’est structurée autour d’un modèle dominant : identifier les données critiques, définir des responsabilités, documenter les règles, outiller les processus. Le RGPD a accéléré le mouvement côté conformité. BCBS 239, Solvabilité II, DORA l’ont imposé côté régulation financière et assurantielle.
Le résultat est visible : des organisations mieux conscientes de leurs données, des catalogues plus fournis, des rôles mieux définis.
Mais regardons l’autre face : des programmes qui durent trois, quatre, cinq ans sans produire de valeur mesurable. Des Data Offices qui peinent à démontrer leur ROI. Des équipes métier qui contournent les processus de gouvernance parce qu’ils les ralentissent.
La réponse dominante a longtemps été cohérente avec son époque. Quand les organisations ont commencé à prendre conscience de leurs données, l’urgence était de les recenser, d’en établir la traçabilité, d’en encadrer l’usage. La conformité réglementaire a renforcé cette logique : documenter, tracer, contrôler. C’était nécessaire.
Mais un dispositif de contrôle a une limite structurelle : il regarde en arrière. Il vérifie ce qui a été fait. Il ne prépare pas ce qui doit être décidé. Or piloter, c’est précisément préparer des décisions — pas auditer des données.
La gouvernance des données a été pensée comme un dispositif de contrôle. Elle devrait être pensée comme un dispositif de décision. Le dispositif de contrôle produit de la documentation. Il ne produit pas de la confiance dans les décisions.
Ce que « levier de pilotage » veut dire
Une gouvernance devient un levier de pilotage lorsqu’elle permet de définir les conditions dans lesquelles une décision peut être prise, de vérifier que ces conditions sont satisfaites, et de démontrer a posteriori pourquoi cette décision pouvait être considérée comme fondée. Tant qu’elle se limite à documenter les données sans organiser explicitement leur contribution aux décisions, elle améliore la connaissance du patrimoine informationnel — sans transformer réellement la capacité de pilotage de l’organisation.
Première rupture : concevoir à partir des décisions, pas des données
La conception classique de la gouvernance part des données : quelles sont-elles, qui en est responsable, comment les qualifier, comment les stocker. C’est une logique de patrimoine.
Or une organisation ne pilote pas un patrimoine. Elle prend des décisions.
La vraie question n’est pas « quelles données avons-nous ? » mais « quelles décisions devons-nous prendre, et de quelles données ces décisions ont-elles besoin pour être fiables ? »
Ce renversement n’est pas sémantique. Il change tout à la conception du dispositif :
— Les exigences de qualité ne sont plus génériques — elles sont indexées sur les décisions qu’elles servent.
— Les règles de transformation ne sont plus des contraintes techniques — elles sont des garanties de cohérence entre la donnée et le raisonnement qui la mobilise.
— Le glossaire n’est plus un dictionnaire de termes — c’est le socle d’un langage commun entre la donnée et la décision.
— Les KPI de gouvernance ne mesurent plus la complétude d’un catalogue — ils mesurent la confiance dans les décisions.
Ce que la mauvaise conception coûte vraiment
On sous-estime rarement le coût financier ou technique d’un programme de gouvernance mal conçu. On sous-estime presque toujours son coût organisationnel.
Quand la gouvernance est pensée autour des données plutôt que des décisions, chaque partie prenante la lit à travers le prisme de son propre périmètre. La DSI y voit un projet d’infrastructure. La direction des risques y voit un outil de conformité. Les métiers y voient une contrainte supplémentaire. La direction data y voit un programme transverse dont personne ne veut vraiment assumer la charge.
Le résultat est prévisible : des comités de gouvernance où l’on débat de définitions pendant des mois. Des arbitrages sur la propriété des données qui opposent des directions sans qu’aucune ne se sente vraiment légitime. Des projets pilotes qui avancent dans leur coin et produisent des référentiels incompatibles. Des équipes métier qui, lassées d’attendre, construisent leurs propres solutions en dehors du programme officiel.
Ces frictions ne sont pas des problèmes de personnes. Elles sont des problèmes de conception. Quand le dispositif est centré sur les décisions, les périmètres se clarifient naturellement : chaque direction sait quelles décisions elle prend, de quelles données elle a besoin, et à quelles conditions elle peut leur faire confiance. Le débat se déplace — de ce qu’il faut gouverner à comment le gouverner. C’est un débat beaucoup plus productif.
Cette première transformation produit un second effet. Dès lors que la gouvernance est conçue à partir des décisions, une partie croissante du dispositif devient structurable, transmissible et réutilisable. Les décisions critiques, les exigences qui les encadrent, les règles qui les soutiennent, les données qu’elles mobilisent — tout cela cesse d’être des artefacts propres à une organisation. Ils deviennent les éléments d’un socle que d’autres organisations peuvent adopter puis adapter.
Ce que « levier de transformation » veut dire
Une gouvernance devient un levier de transformation lorsqu'elle peut être déployée, adoptée et exploitée dans des délais compatibles avec les attentes de l'organisation. Tant que sa mise en œuvre exige plusieurs années de travaux préparatoires, une mobilisation continue des métiers et des efforts importants de documentation avant de produire les premiers résultats, son adoption reste fragile. La gouvernance cesse alors d'être perçue comme un accélérateur de transformation et devient elle-même un objet de transformation. Un véritable levier de transformation réduit les délais, les frictions et les coûts d'adoption afin de permettre à l'organisation de concentrer ses efforts sur l'exploitation de la gouvernance plutôt que sur sa construction.
Deuxième rupture : déployer sur un socle, pas sur une page blanche
Il y a une distinction que les programmes de gouvernance font rarement, et qui coûte cher : la différence entre construire pour la première fois et reconstruire dans des conditions déjà connues.
Partir d’une page blanche est légitime quand le problème est inédit. Ce n’est pas le cas de la gouvernance des données dans la plupart des secteurs. Les exigences réglementaires sont documentées et relativement stables. Les décisions critiques d’un métier sont connues. Les règles de qualité qui s’y attachent, les transformations nécessaires, les indicateurs de surveillance — tout cela a déjà été construit, quelque part, par quelqu’un.
Repartir de zéro dans ce contexte, c’est ignorer délibérément l’expérience accumulée. Pourtant c’est ce que fait chaque programme : chaque consultant redocumente les mêmes exigences, chaque équipe métier redéfinit les mêmes règles, chaque organisation réinvente le même socle.
Le coût n’est pas seulement temporel. Il est humain. Les équipes qui passent dix-huit mois à construire un référentiel avant de pouvoir l’utiliser arrivent à la phase de déploiement épuisées, convaincues que la gouvernance est synonyme de lourdeur. L’adoption part perdante.
La prochaine génération de gouvernance reposera davantage sur l’adoption et l’adaptation que sur la reconstruction systématique des mêmes fondations.
Préconfigurer ne veut pas dire imposer. Cela signifie fournir aux organisations un socle intelligible, adapté à leur secteur, couvrant les dimensions clés du dispositif — exigences, règles, termes, indicateurs — et leur permettre de l’adopter, de le compléter, de le personnaliser sans repartir de rien. Un programme qui démarre avec ce socle gagne plusieurs mois d’effort initial. Surtout, il produit des résultats visibles tôt — et des résultats visibles tôt produisent de l’adhésion.
Plus important, les organisations peuvent consacrer davantage d’énergie à l’exploitation de leur gouvernance qu’à sa construction. Le sujet cesse progressivement d’être la production de connaissance et devient sa mobilisation effective dans les décisions.
Refermer la boucle
Revenons à la définition posée plus haut.
Une gouvernance devient un levier de pilotage lorsqu’elle permet de définir les conditions dans lesquelles une décision peut être prise, de vérifier que ces conditions sont satisfaites, et de démontrer a posteriori pourquoi cette décision était fondée.
Aucun de ces trois actes n’est possible si le dispositif n’a pas été conçu à partir des décisions. Aucun n’est tenable à l’échelle si le dispositif a été construit de zéro, à bout de souffle, sur des bases que personne n’a eu le temps de stabiliser.
Ensemble, ces deux transformations poursuivent des objectifs différents mais complémentaires. La première transforme la gouvernance en levier de pilotage en reliant explicitement les données aux décisions qu'elles doivent soutenir. La seconde transforme la gouvernance en levier de transformation en réduisant les délais, les frictions et les efforts nécessaires à son déploiement et à son adoption.
L'une permet de mieux décider. L'autre permet d'y parvenir plus rapidement et plus durablement. C'est de leur combinaison que dépend la capacité des organisations à faire de la gouvernance autre chose qu'un dispositif de contrôle ou de documentation : un véritable outil de pilotage et de transformation.
Les auteurs
Charles Ngando Black – Fondateur et Président iDAIp
iDAIp est un cabinet de conseil spécialisé dans la conception et le déploiement d’initiatives de gouvernance des données. iDAIp est éditeur des contenus préconfigurés de la plateforme de gouvernance YavanthaTM.
Marc Vengadabady – Cofondateur et CTO Yavantha
Yavantha est un éditeur de plateforme de gouvernance des données, couvrant intelligence des données, cadrage des données et pilotage par les données.
iDAIp est un cabinet de conseil spécialisé dans la conception et le déploiement d’initiatives de gouvernance des données. iDAIp est éditeur des contenus préconfigurés de la plateforme de gouvernance YavanthaTM.
Marc Vengadabady – Cofondateur et CTO Yavantha
Yavantha est un éditeur de plateforme de gouvernance des données, couvrant intelligence des données, cadrage des données et pilotage par les données.
