Que ce soit pour ses activités retail ou CIB, le groupe BPCE s’appuie sur une stack technologique en mode service pour répondre aux besoins de ses métiers et gouverner les usages comme les domaines. Mode d’emploi par Florian Caringi, manager big data et data architecture.
>> Cet article est extrait du carnet d’expériences à télécharger : Modernisation des plateformes de données : les meilleurs accélérateurs des grandes entreprises.
Le data mesh chez BPCE, qu’est-ce que cela signifie en termes de projets et de trajectoire ?
Florian Caringi manager big data et data architecture BPCE
Sur la partie retail, l’intérêt pour le data mesh se traduit par la migration d’un historique big data on-premise Hadoop vers GCP. Ce chantier technique amène à une réflexion complète et à penser les données en mode comptoir. Cela signifie que les données sont rattachées à des domaines, qui en assurent également la mise à disposition.
Les usages, notamment en matière de data science et d’analytics, s’appuient ainsi sur les comptoirs. Cette trajectoire de transformation est l’illustration d’une volonté de s’inscrire dans une démarche de type domaines métier, comme prônée par le data mesh. La migration sur GCP est un facilitateur. Elle permet de tirer profit des fonctionnalités fournies par BigQuery.
Sur un plan technologique, BigQuery est un moyen d’exposer des comptoirs de données pour répondre à des besoins.
L’activité corporate & investment banking (CIB) suit-elle une même trajectoire ?
La plateforme de CIB a été conçue en 2016, en amont de l’émergence du data mesh. Néanmoins, avec une organisation IT structurée par domaines métier, nous avons nativement construit une mise à disposition des données selon une même approche par domaine. En conséquence, ingestion et ownership IT de la donnée ont nativement été organisés en cohérence avec le data mesh.
Sur la base d’un principe d’exposition des données par domaine, chaque application exposait la donnée et la consommait dans le domaine correspondant. Nous avons ajouté par la suite du data as a service pour des cas d’usage spécifiques sans lien avec un IT métier. Dans ces cas de figure, des zones sont créées.
De façon sous-jacente, on retrouve alors une gouvernance data, qui s’est montée au fil du temps. On peut prendre l’exemple de la workforce, qui englobe les bâtiments, la vision RH et celle des contrats externes. Afin de structurer une vision workforce globale, il faut réunir trois domaines IT métier. Le mindset data as a service est mis en œuvre dans le cadre d’une zone spécifique. Et lui est attaché un domain data owner, qui définit les cas d’usage. Mais in fine, cette zone s’appuie sur trois comptoirs de données distincts et sur une gouvernance IT.
À l’image de Michelin, le point de départ, c’est donc une organisation IT sur laquelle est venue s’adosser une gouvernance data plus traditionnelle ?
Sur le retail, c’était un peu différent à l’origine, mais l’approche est totalement repensée à travers l’adoption de GCP.
Sur le retail justement, où en sont les comptoirs de données ?
Ils sont en cours de construction actuellement. Ces comptoirs seront de l’ordre de la dizaine. L’objectif est de les rendre accessibles aux consommateurs de données, courant 2023. La plateforme technologique est ici un facilitateur pour la gouvernance.
Le data as a service est né de la plateforme, à laquelle nous avons progressivement intégré des services destinés à faciliter le requêtage, l’accès, et éviter que les utilisateurs n’exposent la donnée à l’extérieur. C’est la raison pour laquelle les usages se sont développés. Exposition et consommation s’effectuent en un même point.
En quoi cette unification est-elle importante ?
C’est un point critique. Et c’est un inconvénient récurrent des plateformes data. La donnée est souvent exposée sur d’autres systèmes, ce qui empêche de conserver une approche mesh et une consistance des domaines.
La volonté dès le départ a donc été de concevoir une plateforme intégrant des services, justement pour réconcilier exposition et usages. Sur le retail, le cloud et les opportunités technologiques associées permettent d’atteindre cet objectif.
Sur CIB, les briques big data ont été déployées en 2016 et en mode on-premise. Quelles évolutions depuis ?
La plateforme n’est pas figée. Services mis à disposition, urbanisation, facilitation de l’accès… Les améliorations sont constantes et déployées de manière itérative. Nous avons, par exemple, intégré un moteur de BI comme Indexima, afin de supporter les usages décisionnels.
Nous sommes en cours de déploiement d’un moteur analytique, Starburst, pour pouvoir accéder plus facilement et plus rapidement à la donnée. De la même manière, des options de conteneurs sont intégrées. La finalité est de faciliter des usages comme la fourniture de datalabs à la demande.
La plateforme se développe par itération. Elle a d’abord servi un premier besoin, puis d’autres. Des cas d’usage supplémentaires s’ajoutent au fur et à mesure. Ses caractéristiques contribuent à attirer les utilisateurs et les projets, qui peuvent réutiliser données et outils existants.
Tout projet n’a pas nécessairement besoin d’une infrastructure big data. En revanche, les projets data trouvent un intérêt à être en proximité avec d’autres applications data. On observe un véritable effet boule de neige.
Les produits, les croisements et réutilisations sont fondamentaux dans le data mesh. Où en êtes-vous sur ce pilier ?
Nous ne sommes pas encore totalement matures sur ce point. Nous ne disposons pas à strictement parler d’un catalogue de produits data. Chaque application met à disposition de la donnée avec son contrat d’interface. On peut y voir les prémices d’un produit data. Chacun des domaines, finance, client, comptabilité, met à disposition des données dans son propre couloir.
Là où le résultat s’apparente le plus à des produits data réels, c’est pour les référentiels. Sur la plateforme sont disponibles des golden copy des référentiels. Elles sont clés dans l’organisation, mais aussi pour unifier autour de la plateforme.
En matière de valorisation des données, le rapprochement avec les métiers et leurs besoins est jugé critique. Quelle est votre approche ici ?
Les IT métiers CIB sont mes points de contact en tant qu’asset owner de la plateforme. Il peut arriver que le métier nous contacte directement. Dans tous les cas, nous opérons à trois, avec l’IT et le métier, pour faire évoluer la stack. Starburst est ainsi une réponse à une limite que nous avions identifiée sur l’accès aux données.
Le métier a-t-il l’ownership des données et leur connaissance ou est-ce le rôle de l’IT ?
Auparavant, c’est véritablement et exclusivement l’IT métier qui remplissait cette fonction. Petit à petit, ont été mises en place les chaînes métier, financement, trade, etc. Avec l’IT, le métier copilote l’organisation. Il a ainsi plus de visibilité sur les projets data et peut influer sur les priorités des domaines. Mais la responsabilité se partage à 50/50. Le pilotage repose sur des trains dans le cadre de la méthode SAFe.
Cela, c’est pour CIB. En ce qui concerne le retail, ce sont les product owners qui vont assurer l’écoute auprès des métiers. Ils sont les garants de la prise en compte des besoins, avec une orchestration au niveau du data office.
CIB et le retail ont chacun leur méthode. Cependant, on retrouve de fortes similarités entre les deux univers en matière de méthodes et de pratiques.