Gouvernance des données et analytics pour la finance

En 2018, l'équipe finance d'Unilever a découvert que ses opérations mondiales suivaient la « marge brute » d'au moins onze façons matériellement différentes. Certaines unités déduisaient les dépenses promotionnelles ; d'autres les enfouissaient dans le marketing. Certaines affectaient le fret au COGS ; d'autres à la distribution. Chaque définition se défendait localement. Ensemble, elles faisaient du chiffre consolidé une fiction, une moyenne pondérée de onze vérités incohérentes. L'entreprise avait dépensé des millions en plateformes d'analytics et en data lakedata lakeUn data lake est un référentiel centralisé qui stocke de grands volumes de données brutes dans leur format d'origine, des tables structurées aux fichiers non structurés, jusqu'à ce qu'on en ait besoin.Voir la définition complète →. Rien de tout cela ne comptait, parce que la machine calculait fidèlement une moyenne de bruit.

C'est la leçon inconfortable que tout CFO finit par apprendre : vos ambitions en IA n'échoueront pas parce que vos modèles sont faibles. Elles échoueront parce que votre gouvernance des données est faible. Un modèle de prévision entraîné sur des définitions de revenus incohérentes ne produit pas une prévision légèrement décalée ; il produit une prévision faussement assurée, à grande échelle, avec un vernis d'autorité quantitative. Les déchets sont désormais automatisés, plus rapides, et plus difficiles à contester parce que « l'algorithme l'a dit ».

Avant d'approuver un nouvel investissement en analytics, vous devez comprendre ce qui détermine réellement s'il crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée de la valeur. Ce déterminant n'est pas le modèle. C'est le socle sur lequel il repose.

Le principe de la gouvernance d'abord : pourquoi les modèles amplifient tout ce qu'on leur donne

Le machine learning possède une propriété que le reporting traditionnel n'a pas : il *industrialise* votre qualité de données, pour le meilleur ou pour le pire. Un analyste humain qui prépare un board deck remarquera que le chiffre d'affaires d'un client semble impossible et enquêtera discrètement. Un modèle ingérera l'anomalie, la pondérera et la propagera dans une prédiction qui touche la planification des stocks, les décisions de crédit et les prévisions de covenants. L'humain applique son jugement comme filtre qualité. Le modèle supprime ce filtre au nom de la vitesse.

Cela inverse la séquence habituelle d'un programme d'analytics. L'instinct, renforcé par chaque démo de fournisseur, consiste à commencer par la couche excitante : le dashboard, le modèle prédictif, le copilote d'IA générative qui répond en langage naturel à des questions sur votre P&L. Mais la hiérarchie de valeur fonctionne dans l'autre sens. Voyez-la comme une stack :

• Couche 1, Définitions : que *signifie* précisément chaque métrique, partout ?
• Couche 2, Propriété : qui est responsable de l'exactitude de chaque domaine de données ?
• Couche 3, Qualité : les données sont-elles complètes, à jour, cohérentes et traçables en lineage ?
• Couche 4, Analytics & IA : modèles, prévisions, détection d'anomalies, génération de narratifs.

Chaque euro de valeur produit par la couche supérieure est *multiplié* par l'intégrité des trois qui la soutiennent. Si votre couche définitionnelle est cohérente à 60 % et votre couche qualité fiable à 70 %, aucun modèle, aussi sophistiqué soit-il, ne récupère les 58 % perdus. Vous composez des fractions.

L'erreur du CFO est de traiter la gouvernance comme un projet d'hygiène informatique à déléguer. Ce n'en est pas un. Les définitions de données sont des décisions de politique financière. Quand vous décidez si les contra-revenues sont déduites des ventes ou reportées séparément, vous posez un jugement qui façonne chaque métrique, chaque incentive et chaque prévision en aval. C'est une décision de CFO, pas de data engineer.

Construire le socle : propriété, définitions et qualité

Propriété : nommer l'humain responsable

L'échec de gouvernance le plus courant est la responsabilité diffuse. Tout le monde touche aux données clients de référence ; personne n'en est propriétaire. Alors quand le « nombre de clients actifs » diverge entre le CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → et le système de facturation, trois départements affirment chacun que l'autre se trompe, et l'équipe analytics en choisit un discrètement et passe à autre chose.

La solution est un modèle de propriété des données avec deux rôles distincts :

• Les Data Owners sont des cadres dirigeants responsables de l'*adéquation à l'usage* d'un domaine. Le propriétaire des « données de revenus » peut être le VPVPFormulation claire des bénéfices apportés par votre produit, des problèmes qu'il résout et des raisons pour lesquelles les clients doivent vous choisir plutôt qu'une alternative.Voir la définition complète → Revenue Operations rattaché à la finance. Il ne gère pas la tuyauterie ; il est responsable de la réponse à « est-ce juste, et peut-on miser la prévision dessus ? »
• Les Data Stewards sont les mains opérationnelles, des analystes qui surveillent la qualité, résolvent les exceptions et font respecter le standard au quotidien.

Le travail du CFO est d'exiger que **chaque domaine de données financières critique, revenus, coûts, clients, fournisseurs, produits, hiérarchie d'entités, ait un propriétaire *nommément désigné*, pas un comité**. La propriété se dissout dès qu'elle est partagée. Quand Procter & Gamble a construit ses salles de décision « Business Sphere » pilotées par les données, la discipline sous-jacente n'était pas la mise en scène des murs d'écrans qui a fait la couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → médiatique ; c'était l'attributionattributionUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète → impitoyable d'une responsabilité à propriétaire unique pour chaque élément de master data alimentant ces écrans.

Action concrète pour lundi matin : construisez un RACI d'une page pour vos dix principaux domaines de données financières. Si une case indique « tout le monde » ou « l'équipe data », vous avez trouvé une ligne de faille.

Définitions : la couche sémantiquecouche sémantiqueUne couche de définitions métier partagée entre données brutes et rapports, pour que chacun calcule revenu, churn ou marge de la même manière.Voir la définition complète → comme politique financière

Le problème de marge brutemarge bruteLa marge brute est la part du chiffre d'affaires qui reste après déduction du coût direct de production des biens ou services, exprimée en pourcentage du chiffre d'affaires.Voir la définition complète → d'Unilever est un échec *sémantique*, le même mot portant des sens différents dans l'entreprise. L'antidote est un glossaire métier (parfois appelé couche sémantique ou catalogue de métriques) : un référentiel unique, faisant autorité et versionné, définissant chaque métrique en termes non ambigus et calculables.

Une définition correcte n'est pas « marge brute = chiffre d'affaires moins coût des marchandises vendues ». C'est une reformulation de manuel. Une définition gouvernée précise :

• Les champs sources et systèmes exacts
• Les règles d'inclusion et d'exclusion (le fret entrant compte-t-il ? Les retours sont-ils déduits ? À quel moment le revenu est-il « reconnu » ?)
• La granularité d'entité et de temps
• Le propriétaire et la date de dernière validation

La discipline ici est qu'une métrique n'existe pas tant qu'elle n'est pas définie et attribuée. Si quelqu'un construit un dashboard à partir d'une métrique non définie, ce dashboard n'est pas autorisé. Cela paraît bureaucratique jusqu'au jour où vous assistez à un conseil d'administration où deux dirigeants se disputent vingt minutes parce que « churn » signifiait churn de logos pour l'un et churn de revenus pour l'autre.

L'outillage moderne rend cela applicable. Une couche de métriques centralisée signifie que lorsque le CEO demande au copilote IA « quel était le revenu net du T3 en EMEA », **le système le calcule à partir de l'*unique* définition gouvernée, et non de la jointure bricolée par un analyste à 23 h**. C'est la différence entre une IA qui réduit les litiges et une IA qui en génère plus vite.

Qualité : les quatre dimensions et le coût de l'erreur

Une fois la propriété et les définitions en place, la qualité devient mesurable plutôt qu'anecdotique. Tenez vos données critiques à quatre dimensions :

1. Complétude, les champs requis sont-ils renseignés ? (Une fiche client sans code secteur fausse silencieusement l'analyse par segment.)
2. Cohérence, le même fait concorde-t-il entre les systèmes ? (Nombre de commandes dans l'ERP vs. dans le data warehouse.)
3. Fraîcheur, la donnée est-elle assez à jour pour la décision qu'elle alimente ? (Un dashboard rafraîchi quotidiennement qui pilote des décisions de trésorerie intraday n'est pas adapté à l'usage.)
4. Lineage, pouvez-vous remonter n'importe quel chiffre jusqu'à sa source, transformation par transformation ?

Le lineage mérite une attention particulière du CFO à cause de votre signature. Quand vous certifiez des états financiers, vous attestez personnellement de chiffres de plus en plus produits par des pipelines automatisés que vous ne voyez pas. Si vous ne pouvez pas retracer un chiffre publié depuis le board deck jusqu'à la transaction source à travers chaque transformation, vous signez par acte de foi. Un lineage auditable n'est pas un raffinement technique ; c'est une exigence de contrôle, et c'est là que les régulateurs et les auditeurs se dirigent vite sur le reporting touché par l'IA.

La discipline pratique consiste à construire des scorecards de qualité par domaine de données et à mettre un *coût* sur l'échec. Ne dites pas à l'organisation « la qualité des données compte », tout le monde hoche la tête et rien ne change. Dites plutôt : « Le trimestre dernier, des doublons de fiches fournisseurs ont provoqué 2,3 M$ de doubles paiements et retardé la clôture de quatre jours. » La qualité devient une conversation de P&L, et elle capte soudain l'attention des dirigeants.

Du socle à la valeur : séquencer le programme d'analytics

Le socle en place, le CFO fait face à la question du séquencement : où déployer réellement l'analytics et l'IA en premier ? La tentation est de courir après le use case le plus impressionnant. La discipline est de **courir après le use case où vos données sont *les plus prêtes* et où la *cadence de décision* est la plus élevée**.

Utilisez une priorisation simple à deux axes :

• Readiness des données (le domaine sous-jacent est-il bien gouverné, complet et défini ?)
• Valeur décisionnelle (à quelle fréquence et avec quelle matérialité cette analyse pilote-t-elle des décisions qui engagent de l'argent ?)

Le quadrant haute readiness / haute valeur est votre point de départ. Pour la plupart des directions financières, ce sera la prévision de trésorerie, l'optimisation du working capital ou la détection d'anomalies dans les transactions, des domaines où la donnée est structurée, volumineuse et liée aux décisions quotidiennes. Le piège séduisant est le quadrant basse readiness / haute valeur : la prédiction stratégique du chiffre d'affaires, par exemple, qui promet une valeur énorme mais repose sur les données les moins gouvernées. Commencez là et vous passerez dix-huit mois et un gros budget à produire un modèle auquel personne ne fait confiance.

C'est aussi là que le CFO doit recadrer le business case de l'IA. Le conseil entend « nous investissons dans l'IA » et attend un modèle. Le cadrage honnête est : « Nous investissons dans le socle de données qui rendra possibles trois générations de modèles. » La couche de gouvernance est un actif durable ; le modèle spécifique est un actif qui se déprécie. Les capacités IA tant citées de JPMorgan reposent moins sur un algorithme unique que sur des années d'infrastructure de données disciplinée, la couche ingrate dans laquelle les concurrents sous-investissent avant de s'étonner que leurs pilotes ne passent jamais à l'échelle.

Le point de contrôle humain

Même avec des données impeccables, l'analytics en finance exige un design human-in-the-loop délibéré. Décidez à l'avance quelles décisions le modèle *recommande* et lesquelles il *exécute*. Un modèle peut signaler automatiquement des écritures comptables anormales pour revue (recommander). Il ne doit pas les passer automatiquement (exécuter) sans seuil de matérialité et sans validation humaine. À mesure que vous montez l'échelle du risque, de la prévision opérationnelle vers tout ce qui touche au reporting externe ou à l'allocation de capital, le point de contrôle humain se resserre.

La question de gouvernance ici est : qui est responsable quand le modèle se trompe ? La réponse ne peut jamais être « le modèle ». Ce doit être un propriétaire nommé qui a compris les limites du modèle et approuvé son périmètre de déploiement. Cela boucle la boucle avec la Couche 2. La propriété ne s'arrête pas aux données ; elle s'étend à l'analytics construit dessus.

Ce que cela signifie pour vous lundi

La gouvernance des données n'est pas le prérequis ennuyeux que vous déléguez avant que le vrai travail d'IA ne commence. Elle *est* le vrai travail. Les modèles se banalisent vite, votre concurrent peut acheter le même moteur de prévision que vous. Ce qu'il ne peut pas copier facilement, c'est une direction financière où chaque métrique critique a une définition, un propriétaire et un lineage traçable. C'est l'avantage durable et cumulatif, et il relève clairement du mandat du CFO parce que chacune de ces définitions est une décision de politique financière déguisée en question technique.

Le CFO qui comprend cela cesse de demander aux fournisseurs « que sait faire votre modèle ? » et commence à demander à sa propre organisation « nos données méritent-elles seulement un modèle ? »

Points clés à retenir

1. Traitez les définitions de données comme une politique financière, pas comme une configuration IT. Prenez personnellement en charge la résolution de vos principales ambiguïtés de métriques (revenu, marge, churn, nombre de clients). Un modèle entraîné sur des définitions incohérentes produit des erreurs assurées, scalables et automatisées.

1. Nommez un propriétaire unique et responsable pour chaque domaine de données critique. Construisez un RACI d'une page cette semaine ; tout domaine détenu par « tout le monde » ou « l'équipe data » est une ligne de faille. Étendez la propriété à l'analytics construit sur ces données, aucun modèle n'est responsable, seules les personnes le sont.

1. Faites de la qualité des données une conversation de P&L. Mesurez complétude, cohérence, fraîcheur et lineage par domaine, et attachez un coût en euros aux défaillances. « La qualité des données compte » ne change rien ; « 2,3 M$ de doubles paiements » change les comportements.

1. Séquencez l'analytics selon la readiness des données, pas selon l'effet produit. Commencez dans le quadrant haute readiness / haute valeur (prévision de trésorerie, détection d'anomalies). Résistez au piège haute valeur / basse readiness qui consomme du budget et produit de la défiance.

1. Recadrez le business case de l'IA devant le conseil comme un socle, pas comme une fonctionnalité. La couche de gouvernance est un actif durable et cumulatif qui rend possibles trois générations de modèles ; un modèle donné se déprécie, et le socle est la partie que les concurrents ne peuvent pas copier.