Construire le modèle opérationnel de data governance

Une NAV (Net Asset Value, le prix par part d'un fonds calculé quotidiennement) est publiée 12 points de base trop haut parce que quelqu'un a modifié une provision de frais dans un tableur et que personne n'était propriétaire du changement. Le fonds republie ses comptes. Le client se plaint. Le régulateur demande qui était responsable, et la réponse honnête est : personne, précisément. C'est ce vide que comble un modèle opérationnel de data governancedata governanceLa data governance est l'ensemble des politiques, rôles et processus qui garantissent que les données sont exactes, sécurisées, bien définies et utilisées de façon responsable dans toute l'organisation.Voir la définition complète →.

La governance échoue quand elle vit dans un PDF de politique que personne ne lit. Elle fonctionne quand des humains précis sont propriétaires de datasets précis, se réunissent selon un calendrier et détiennent des droits de décision définis. Cette leçon vous montre comment le mettre en place.

Ce qu'est réellement un modèle opérationnel

Un modèle opérationnel de data governance répond à quatre questions :

• Qui est propriétaire de chaque dataset ? (accountability)
• Qui en maintient la qualité au quotidien ? (exécution)
• Où se décident les litiges et les changements ? (instances)
• Qui peut approuver quoi ? (droits de décision)

Remarquez que rien de tout cela n'est technologique. L'outillage vient après. D'abord, vous désignez des personnes.

Les trois rôles clés

Data Owner. Une personne senior responsable, généralement un responsable métier. L'Owner ne nettoie pas les données. L'Owner en répond. Pour les flux de NAV, l'Owner peut être le Head of Fund Accounting. Pour les grilles de frais, le Head of Product ou le Client Servicing.

Data Steward. Le gardien opérationnel. Les Stewards définissent ce que « correct » signifie pour un champ, exécutent les contrôles et traitent les exceptions. Un steward de benchmark sait que le S&P 500 est rebalancé chaque trimestre et qu'un ajout ou retrait de constituant doit remonter dans le système de portefeuille avant la prochaine date de rebalancement.

Data Custodian. Généralement l'IT ou une équipe plateforme. Les Custodians opèrent les pipelines et le stockage. Ils maintiennent les données en circulation et sécurisées, mais ne décident pas de leur signification métier.

Séparez-les nettement. Quand l'Owner, le Steward et le Custodian se confondent en une seule personne surchargée, l'accountability meurt au moment où cette personne partira.

Affectez des owners à de vrais datasets, pas à « la data »

« Nous sommes propriétaires de la qualité des données » ne veut rien dire. Affectez au niveau du dataset. Voici une carte d'accountability de départ pour un asset manager de taille intermédiaire.

Deux définitions pour les non-techniciens :

• ISIN (International Securities Identification Number) : l'identifiant mondial à 12 caractères d'un titre.
• KYC (Know Your Client) : les contrôles réglementaires confirmant qui est réellement un investisseur.

La carte est l'artefact que vous maintenez à jour. Quand quelqu'un démissionne, vous réaffectez le rôle, vous ne reconstruisez pas la connaissance.

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 →éez les instances

Des rôles sans instances dérivent. Il vous faut des organes de décision permanents avec un périmètre clair.

Data Governance Council. Se réunit tous les mois ou tous les trimestres. Présidé par un sponsor senior (souvent le COO ou un Chief Data Officer). Il approuve les politiques, arbitre les litiges inter-équipes et valide les changements majeurs (nouveau fournisseur de données, nouvelle golden source).

Data Quality Working Group. Se réunit chaque semaine ou toutes les deux semaines. Stewards et custodians passent en revue les exceptions ouvertes, les sujets qui vieillissent et les événements à venir (rebalancements d'indices, changements de frais, lancements de fonds).

Change Advisory. Examine les changements proposés sur les datasets critiques avant leur mise en production. Un changement de grille de frais qui touche la facturation client ne devrait jamais atteindre la production sans approbateur documenté.

Tenez des comptes rendus. Les régulateurs et les auditeurs demandent « qui a décidé cela et quand ». Les comptes rendus sont votre réponse.

Droits de décision : le RACI que vous utilisez vraiment

Écrivez qui est Responsible, Accountable, Consulted et Informed pour chaque type de décision. Exemple pour un changement de grille de frais :

• Responsible : Product Data Steward (effectue le changement)
• Accountable : Head of Product (porte le résultat)
• Consulted : Fund Accounting, Compliance, Client Servicing
• Informed : Data Governance Council

La règle unique qui vous sauve : exactement un Accountable par décision. Deux Accountable, cela revient à zéro.

La governance rencontre la réglementation

Nous sommes dans l'asset management, donc le modèle opérationnel doit se raccrocher à des règles réelles. Nommez-les, pour que vos rôles se rattachent à des obligations.

• RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → (Règlement général sur la protection des données, UE) : encadre les données personnelles, y compris les dossiers investisseurs. Exige une base légale, des limites de conservation et des droits pour les personnes concernées. Une société servant des investisseurs européens a généralement besoin d'un Data Protection Officer (DPO) et d'un registre des activités de traitement.
• UK GDPR + Data Protection Act 2018 : l'équivalent britannique post-Brexit, appliqué par l'Information Commissioner's Office (ICO).
• SEC et Investment Advisers Act (États-Unis) : les conseillers enregistrés aux États-Unis doivent tenir des livres et registres exacts (la « books and records rule »). Des données de NAV ou de frais médiocres constituent un problème de registres, pas seulement un problème d'ops.
• MiFID II (UE) / MiFIR : règles de reporting de transactions qui dépendent de données de référence propres sur les instruments et les contreparties. De mauvaises données ISIN ou LEI cassent le reporting.
• LEI (Legal Entity Identifier) : l'identifiant mondial à 20 caractères des entités juridiques dans les transactions financières.

Rattachez chaque dataset à ses points d'ancrage réglementaires. Les dossiers clients touchent au RGPD. Les données de NAV et de frais touchent aux règles de registres SEC/FCA. Les données de référence de transactions touchent au reporting MiFIR. Votre Owner sait alors pourquoi son dataset compte au-delà du « ça devrait être juste ».

Branchez les contrôles qualité sur les owners

Le modèle opérationnel devient réel quand chaque dataset porte des contrôles automatisés qui alertent son steward. Un simple contrôle de cohérence quotidien de la NAV, exprimé en pseudo-SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète →, pourrait ressembler à ceci :

-- Signale les variations de NAV qui dépassent un seuil par rapport à la veille
SELECT fund_id, nav_date, nav_per_share, prior_nav,
       ROUND((nav_per_share - prior_nav) / prior_nav * 100, 2) AS pct_change
FROM nav_daily
WHERE ABS((nav_per_share - prior_nav) / prior_nav) > 0.05  -- seuil de 5 %
ORDER BY ABS(pct_change) DESC;

Une variation de 5 % sur une seule journée pour un fonds obligataire diversifié est presque certainement une erreur de données, pas un mouvement de marché. Le contrôle est routé vers le Fund Ops Steward, qui confirme ou corrige avant publication. Le seuil lui-même est une décision de governance, portée et documentée.

Exemple chiffré d'un déclencheur de matérialité : si la NAV d'un fonds est de 20,00 et que l'erreur est de 0,02 par part, cela représente 0,10 %, soit 10 points de base. De nombreux administrateurs de fonds utilisent une tolérance d'erreur de NAV autour de 0,5 % (50 bps) comme seuil courant du secteur pour l'indemnisation des investisseurs, même si le chiffre exact varie selon le fonds, la juridiction et le prospectus (à considérer comme une estimation illustrative, pas comme une norme juridique). Votre modèle de governance décide du seuil et de qui valide les dépassements.

Faites-le survivre au turnover

Tout l'enjeu est la durabilité. Trois pratiques font que la governance survit aux personnes qui l'ont construite.

1. Documentez la définition, pas seulement la valeur. Pour chaque champ critique, consignez sa signification, sa source de vérité (« golden source »), son owner et son contrôle. Quand le steward de benchmark partira, la définition de « pondération du constituant à la clôture du rebalancement » reste.

2. Nommez des suppléants. Chaque Owner et chaque Steward a un adjoint nommé. Aucun point de défaillance unique.

3. Exploitez un data catalog. Un catalogue est un inventaire interrogeable des datasets avec owner, steward, source, sensibilité et lineage. Des outils open source comme OpenMetadata ou DataHub le font gratuitement. Quand un auditeur demande « où vit la grille de frais et qui en est propriétaire », la réponse tient en une recherche, pas en une semaine.

Audits : prouvez que le modèle fonctionne

Une governance que vous ne pouvez pas prouver est une governance que vous n'avez pas. Programmez des contrôles légers :

• Revue trimestrielle de l'ownership : vérifiez que chaque dataset critique a toujours un Owner et un Steward actifs.
• Rapport de vieillissement des exceptions : combien de problèmes de qualité sont ouverts, et depuis combien de temps ? Des exceptions qui vieillissent signalent un steward surchargé ou une source cassée.
• Revue des accès : qui peut modifier les grilles de frais ou les inputs de NAV ? Le moindre privilège compte ici.
• Contrôle ponctuel de lineage : remontez d'une NAV publiée jusqu'à ses inputs. Si vous n'y arrivez pas, votre documentation de lineage a des trous.

Points clés

• Affectez au niveau du dataset. « Nous sommes propriétaires de la data » ne veut rien dire. Nommez un Owner et un Steward spécifiquement pour les constituants de benchmark, les grilles de frais, les flux de NAV et les dossiers clients.
• Un seul Accountable par décision. Utilisez RACI, limitez-vous à un unique Accountable, et doublez chaque rôle d'un adjoint nommé pour que le modèle survive aux démissions.
• Instances plus comptes rendus égalent défendabilité. Un Governance Council et un Quality Working Group avec des décisions documentées, voilà ce que vous montrez aux régulateurs et aux auditeurs.
• Rattachez les datasets à des règles réelles. Dossiers clients au RGPD, NAV et frais aux règles de registres SEC/FCA, données de transactions à MiFIR. Les owners doivent connaître leur point d'ancrage réglementaire.
• Branchez les contrôles et un catalogue sur les owners. Des seuils automatisés (comme l'alerte sur une variation de NAV de 5 %) sont routés vers le steward responsable, et un data catalogdata catalogUn inventaire centralisé des actifs de données d'une organisation, enrichi de métadonnées, qui aide chacun à trouver, comprendre et faire confiance aux données dont il a besoin.Voir la définition complète → transforme « qui est propriétaire de ça » en une recherche d'une seconde.