DataGouvernance des donnéesAsset & Wealth ManagementBanque

Comment JPMorgan Chase a structuré ses contrats de données pour maîtriser la gouvernance inter-domaines

JPMorgan Chase a déployé une architecture de contrats de données à grande échelle pour résoudre un problème récurrent dans les grandes organisations : qui possède quoi, et selon quelles règles. Voici ce que cette expérience enseigne aux CDO qui gèrent des domaines multiples et des parties prenantes aux intérêts divergents.

En 2021, JPMorgan Chase gérait plus de 4 000 systèmes de données internes, répartis entre ses branches Retail Banking, Asset Management, Corporate & Investment Bank et ses fonctions support. Chaque domaine avait ses propres définitions de « client actif », ses propres règles de rétention, ses propres équipes techniques. Lorsqu'un analyste risque demandait des données à une équipe produit, il recevait un fichier sans contexte, sans garantie de fraîcheur, sans responsable identifié en cas d'anomalie. Le même constat se posait pour les régulateurs : lors des exercices de stress test exigés par la Fed, les équipes passaient des semaines à réconcilier des définitions contradictoires entre divisions.

La direction data de la banque, sous Lori Beer (Global CIO) et les équipes de gouvernance associées, a formalisé un programme d'ownership par domaine adossé à des contrats de données. L'objectif déclaré : transformer des échanges informels de fichiers en engagements formels, auditables, avec des obligations claires de part et d'autre.

Les trois composantes du modèle de contrats de données de JPMorgan

La banque a structuré son approche autour de trois composantes.

La première est la désignation de Data Owners par domaine métier. Chaque domaine (crédit à la consommation, gestion des risques de marché, paiements, etc.) a nommé un owner nommément responsable de la qualité, de la définition sémantique et du cycle de vie des datasets qu'il produit. Ce n'est pas un rôle purement technique : l'owner est un cadre senior capable de prendre des décisions sur les priorités et les compromis. JPMorgan a publiquement évoqué ce modèle dans ses présentations à des conférences sectorielles comme Money20/20 et dans des entretiens accordés à des publications comme MIT Technology Review.

La deuxième composante est le contrat de données lui-même. Un contrat de données chez JPMorgan spécifie, pour chaque dataset partagé entre domaines : le schéma et la sémantique de chaque champ, la fréquence de mise à jour et le SLA associé (par exemple, données actualisées sous deux heures pour les flux de trading, sous 24 heures pour les données clients CRM), les règles de qualité mesurables (taux de complétude minimum, plage de valeurs acceptables), et les conditions d'accès et les obligations du consommateur. Ce dernier point est important : le contrat engage les deux parties. Le consommateur de données s'engage à ne pas modifier la donnée reçue sans accord, à signaler toute anomalie détectée, et à ne pas réutiliser la donnée hors du périmètre déclaré.

La troisième composante est technique : un catalogue de données (construit en partie sur des outils internes, complété par des solutions du marché) expose ces contrats de manière lisible et interrogeable. Les pipelines de données peuvent vérifier automatiquement la conformité au contrat à chaque exécution.

Sanction graduée en cas de violation de SLA

JPMorgan a opté pour une approche graduée. Une première violation de SLA déclenche une alerte et une réunion entre owners. Une violation répétée remonte au Data Council de la division concernée, avec inscription au registre des risques opérationnels. Cette inscription a un effet concret : elle entre dans les reportings internes utilisés lors des revues de performance des managers. Ce mécanisme de gouvernance, sans être punitif au sens légal, crée une pression suffisante pour que les engagements soient tenus.

Quels résultats les contrats de données ont-ils donnés chez JPMorgan ?

Les chiffres publiquement disponibles sur ce programme restent partiels, ce qui est normal pour une banque sous surveillance réglementaire stricte. Voici ce qui est connu ou raisonnablement inférable.

JPMorgan a déclaré lors de sa présentation à l'Investor Day 2023 avoir réduit le temps de réconciliation des données lors des exercices réglementaires. Sans chiffre précis publié, des sources sectorielles (notamment des anciens employés cités dans des podcasts Data Council et le rapport Gartner sur la gouvernance des données financières de 2024) estiment que ce type de programme réduit le temps de préparation des reportings réglementaires de 30 à 50 % dans les grandes banques. Attribuer ce chiffre exclusivement à JPMorgan serait inexact : il s'agit d'une fourchette sectorielle.

Ce qui est documenté directement : la banque a multiplié par trois le nombre de datasets avec un owner identifié entre 2021 et 2023, selon des déclarations faites lors de conférences internes relayées dans la presse spécialisée. Le nombre de contrats de données actifs dépassait 1 200 en fin 2023, toujours selon des sources indirectes. Ces chiffres n'ont pas été audités indépendamment.

L'effet le plus tangible, rapporté par plusieurs dirigeants de la banque dans des interviews publics, est culturel : les équipes métier ont commencé à poser la question de l'ownership avant de lancer de nouveaux projets data, plutôt qu'après avoir rencontré des problèmes de qualité.

Ce qui est transposable hors d'une banque de 4 000 systèmes

Quatre éléments du modèle JPMorgan sont transposables indépendamment de la taille de l'organisation.

Commencer par les flux inter-domaines les plus douloureux, pas par une cartographie exhaustive. JPMorgan n'a pas tenté de gouverner 4 000 datasets simultanément. Les premiers contrats ont couvert une dizaine de flux critiques entre la banque de détail et la gestion des risques.

Ancrer l'ownership dans une responsabilité managériale, pas uniquement technique. Un data owner sans pouvoir de décision ne peut pas tenir un contrat. Le rôle doit être formalisé dans les fiches de poste et les objectifs annuels.

Rédiger des contrats de données asymétriques au départ : le producteur porte l'essentiel des engagements initiaux, le consommateur s'y ajoute progressivement. Demander trop d'obligations aux consommateurs dès le départ freine l'adoption.

Lier les violations à un mécanisme existant, risque opérationnel, RACI projet, ou revue de performance, plutôt que de créer une bureaucratie parallèle.

Deux points de divergence méritent attention. JPMorgan dispose d'une capacité d'ingénierie interne que la plupart des organisations n'ont pas, et peut construire des outils sur mesure. Une entreprise de taille intermédiaire s'appuiera davantage sur des solutions du marché comme Atlan, Collibra ou Monte Carlo (éditeurs de catalogues et d'outils de qualité des données, dont les affirmations commerciales restent à croiser avec des retours d'expérience indépendants). Par ailleurs, la pression réglementaire qui a accéléré le programme à JPMorgan n'existe pas nécessairement dans tous les secteurs : l'urgence doit être construite différemment, souvent à partir d'un incident de qualité visible.

Un contrat de

Questions fréquentes

Que contient un contrat de données chez JPMorgan Chase ?

Un contrat de données JPMorgan précise, pour chaque dataset partagé entre domaines, le schéma et la sémantique de chaque champ, la fréquence de mise à jour et son SLA, des règles de qualité mesurables et les conditions d'accès. Les SLA varient selon l'usage : deux heures pour les flux de trading, 24 heures pour les données clients CRM.

Qui est responsable d'un dataset dans un modèle d'ownership par domaine ?

Un Data Owner désigné par domaine métier (crédit à la consommation, risques de marché, paiements) porte la qualité, la définition sémantique et le cycle de vie des datasets produits. Chez JPMorgan, ce rôle est tenu par un cadre senior capable d'arbitrer priorités et compromis, pas par un profil uniquement technique.

Le consommateur de données a-t-il aussi des obligations ?

Oui, le contrat engage les deux parties. Chez JPMorgan, le consommateur s'engage à ne pas modifier la donnée reçue sans accord, à signaler toute anomalie et à ne pas la réutiliser hors du périmètre déclaré. En pratique, les contrats démarrent asymétriques : le producteur porte l'essentiel des engagements initiaux pour ne pas freiner l'adoption.

Par où commencer un programme de contrats de données dans une entreprise plus petite ?

Par les flux inter-domaines les plus douloureux, pas par une cartographie exhaustive. JPMorgan n'a pas gouverné ses 4 000 systèmes d'un coup : les premiers contrats ont couvert une dizaine de flux critiques entre banque de détail et gestion des risques. Les violations doivent ensuite s'accrocher à un mécanisme existant (risque opérationnel, revue de performance) plutôt qu'à une nouvelle instance.

Pour aller plus loin

Les leçons qui prolongent cet article, en accès libre.

  1. 1Data contracts : le nouveau standard des accords de qualité entre équipesData governance & compliance
  2. 2Data ownership, stewardship et responsabilité dans l'organisationData governance & compliance
  3. 3CDO dans les services financiers : quand la réglementation devient votre architectureData strategy et rôle du CDO
  4. 4Data lineage & metadata management : savoir où vos données sont néesData governance & compliance
  5. 5Data mesh : principes, conditions de succès et critiquesArchitecture data moderne

Vous avez lu cet article ?

Validez votre lecture pour gagner de l’XP et alimenter votre radar.