Bpifrance mise sur une plateforme de données « 100 % » temps réel

Une architecture en médaillon 100 % Cloud

Nizar Salhaji,
responsable du domaine architecture,
Bpifrance

En 2018, un projet de remplacement est lancé. L’idée est de se doter d’un véritable entrepôt de données moderne. Une architecture conçue selon l’architecture en médaillon avec les couches Raw, Bronze, Silver et Gold. Des modèles de données sont organisés par comptoirs correspondant aux grands métiers de la banque. « Dans ce modèle, nous sommes capables d’exposer des API pour les usages dits opérationnels », explique l’architecte. « Pour les usages de reporting, des extractions de données devaient être réalisées à partir de ces comptoirs, avec, à chaque fois, une nouvelle base de données dotée de son propre modèle de données dédié au reporting ».

Quelques années plus tard, un volet quasi-temps réel est ajouté à cette architecture. Bpifrance a déployé en production Apache Kafka. La plateforme est portée par un cloud public et met en œuvre de nombreuses solutions managées d’AWS. Si elle répond aux exigences lors de sa conception, Nizar Salhaji, responsable du domaine architecture chez Bpifrance en souligne les limites : « Nous n’avons pas réussi à décentraliser les compétences, nous conservons toujours des équipes qui vont être un point de contention dans le développement », déclare-t-il. « Pour chaque nouvelle donnée à gérer, cela implique un développement spécifique ».

De même, l’architecture par comptoirs ne permet pas d’obtenir une vue à 360 degrés sur toutes les données. « Nous devions aussi anticiper une grosse évolution de notre SI en termes de diffusion d'informations et d'utilisation de la donnée, et nous imaginions très mal que ça allait être suffisant pour pouvoir répondre aux enjeux de cette refonte », poursuit-il.

L’approche « Data In Flight » privilégie le temps réel

En 2023, une nouvelle approche est mise à l’étude, l’architecture « Data In Flight ». Elle implique la bascule vers une approche majoritairement en temps réel. Kafka deviendrait alors l’unique diffuseur des données dans l’organisation. « Il s’agit, pour nous, de l'unique moyen de découpler à l'émission de temps réel. La seule chose qu'on demande aux producteurs de données, c'est de diffuser leurs données dans des topics Kafka [N.D.L.R. Des groupes logiques de messages] », explique Christophe Jalady. « De leur côté, tous les consommateurs doivent consommer des données telles que les producteurs les ont diffusées ».

Les équipes agiles disposent d’une base de données MongoDB avec leurs propres données et des données consommées auprès de Kafka pour leurs applications. Elles diffusent également les flux à destination de cette plaque tournante des données. Outre ce volet purement technique, cette approche sensibilise le producteur de données, car il est responsable de ce qu’il expose aux autres équipes.

Pour qu’une telle approche puisse fonctionner, il a fallu adapter le volet de la gouvernance. Le propriétaire d’une donnée ne peut évidemment pas arrêter de manière unilatérale sa source. S’il veut apporter une modification, il doit livrer une nouvelle version tout en maintenant les autres sur le principe du « dual run » tant que des consommateurs continuent de s’y connecter.

L’accès aux données est simplifié par un graphe

Christophe Jalady, architecte, Bpifrance

En parallèle à cette architecture de type temps réel, l’équipe « Data » a construit un service transverse baptisé « Knowledge In Flight », alias KIF. Celui-ci permet d’effectuer des recherches sur l’ensemble des données diffusées sur l’architecture, dès qu’elles sont rendues disponibles par leur propriétaire. « Un composant de type graphe a pour rôle de consolider cette vision à 360 degrés sur les données », indique Nizar Salhaji. « Cela joue un rôle d’autodécouverte : tout le monde peut faire des recherches dans ce graphe afin de trouver des objets métiers », détaille-t-il. Son deuxième rôle est de garder un historique de toutes les données et consulter, par exemple, toutes les versions d’un contrat. Le graphe compte aujourd’hui 1,5 milliard de nœuds, 450 millions de documents dans MongoDB, soit 250 Go. Actuellement, le taux de couverture de ce graphe est de l’ordre de 70 à 80 % de l’ensemble des données de Bpifrance.

L’accès aux données n’est bien évidemment pas ouvert à tous. Une gestion très fine des droits a été mise en place pour gérer les autorisations. Là encore, c’est le responsable d’une donnée qui doit attribuer les droits d’accès aux consommateurs. Nizar Salhaji précise : « Sur la partie graphe, nous sommes capables de filtrer pour un utilisateur les objets métiers auxquels il a accès de manière générale, mais aussi sur des critères beaucoup plus précis. Le consommateur doit faire une demande de droits et si elle est acceptée, il verra les données dans le graphe. »

Cette approche a permis de proposer une plateforme de gestion de données en libre-service. Les métiers peuvent directement chercher les données et les consommer de manière complètement autonome, sans solliciter les producteurs de données. En outre, disposer de l’historique complet de toutes les données est un atout en termes de conformité. C’est un point clé dans le secteur bancaire. Un auditeur peut très facilement accéder à l’ensemble des contrats sur une période spécifique. Avec, en prime, la garantie de disposer de données impossibles à falsifier. Les données transitant par Kafka sont réputées immutables « by design », explique Nizar Salhaji.

Avec des alternatives open source, le choix de MongoDB et Kafka et Java est un choix réversible et ces technologies permettent de trouver plus simplement des compétences sur le marché.

Parmi les défis qui attendent l’équipe Data figurent des projets d’analytique avancée et d’IA sur ces données, la mise en place d’un lineage automatique et bien évidemment le décommissionnement des deux autres systèmes, toujours en production. Un plan a été lancé en ce sens en 2024 avec, dans un premier temps, une cartographie de tous les usages et leur portage progressif vers la nouvelle architecture.