Discuter de l'entreposage de données pour le secteur des services financiers avec Vincent Rainardi

Avec le lancement de Astera Constructeur DW Juste au coin de la rue, nous avons discuté avec certains des plus grands leaders d'opinion du secteur pour connaître leur point de vue sur le secteur tel qu'il se présente, comment il évolue et où ils voient l'automatisation des entrepôts de données s'intégrer dans une perspective plus large.

Pour notre deuxième interview de cette série, nous nous sommes entretenus avec Vincent Rainardi, un vétéran de longue date dans le domaine de l'entreposage de données. Il a travaillé sur des projets pour des clients tels que Barclays, Lloyds Bank, Toyota et Avery Dennison. Vincent a également beaucoup écrit sur l'entreposage de données et la BI, auteur d'un livre Création d'un entrepôt de données: avec des exemples dans SQL Server et un populaire blogue sur le sujet.

Dans cette discussion, nous avons plongé en profondeur dans les expériences et les idées variées de Vincent sur l'entreposage de données, avec un accent particulier sur le secteur des services financiers, où il a acquis une expertise substantielle au fil des ans.

Pouvez-vous me parler un peu de votre implication dans l'entreposage de données? Quand avez-vous commencé à travailler sur ces projets et quels rôles avez-vous joué dans le processus de développement au fil des ans?

J'ai commencé à travailler dans l'entreposage de données en 1996, en construisant un entrepôt de données et BI pour un constructeur automobile. A cette époque, DW & BI s'appelait DSS et EIS / MIS (Decision Support System and Executive / Management Information System). J'ai ensuite quitté DW / BI pendant quelques années, mais je me suis de nouveau impliqué dans cet espace en 2005 lorsque j'ai lu le livre de Ralph Kimball sur l'entreposage de données. (The Data Warehouse Toolkit) et en est devenu très passionné. Après cela, j'ai écrit de nombreux articles sur le sujet pour divers sites Web et mon blog. En 2007, j'ai publié un livre couvrant plusieurs de mes idées sur l'entreposage de données.

Depuis 2005, j'ai travaillé sur plusieurs projets d'entreposage de données, développant des entrepôts de données pour les banques, les gestionnaires d'actifs, les assureurs, les fabricants, les prestataires de soins de santé, les détaillants et les entreprises de commerce électronique. Lors des implémentations, mes principales responsabilités sont en tant qu'architecte d'entrepôt de données, c'est-à-dire concevoir l'architecture des flux de données, les modèles de données et les plates-formes physiques, notamment SQL Server, Oracle, Teradata, Hadoop, Azure.

J'ai également occupé divers autres rôles, notamment en tant qu'analyste commercial (exigences commerciales, spécifications fonctionnelles), concepteur BI (définition de tableaux de bord et de visualisations), développeur BI (travaillant avec des plates-formes telles que QlikView, Spotfire, Tableau, SSRS, SSAS , ProClarity, Business Objects, Strategy Companion), développeur ETL (SSIS, Informatica, utilitaires Teradata, SQL), testeur et chef de projet.

Vous avez déjà parlé un peu des différences entre l'entreposage de données et la BI - comment pensez-vous que ces deux concepts se complètent et en quoi diffèrent-ils en principe?

En pratique, ils sont utilisés de manière interchangeable, mais en réalité, ils sont différents. La BI est le frontal (tableaux de bord, rapports, visualisations) et l'entrepôt de données est le backend (base de données, stockage, ETL, fichiers). Cependant, ils se complètent et, dans la pratique, ils sont utilisés ensemble. Aujourd'hui, le backend n'a pas besoin d'être un entrepôt de données; cela peut être un lac de données. Et le frontal n'a pas besoin d'être BI; cela peut être un apprentissage automatique.

Vous avez une riche expérience dans les services financiers. Selon vous, quels sont les cas d'utilisation les plus courants que vous rencontrent des organisations dans des secteurs comme l'assurance ou la banque d'investissement?

Les cas d'utilisation en assurance impliquent de nombreuses analyses complexes. Ainsi, généralement, les organisations chercheront à répondre aux questions sur les types de primes brutes gagnées de plus haut niveau, les primes émises, la couverture des risques, le coût du risque, les ajustements de sinistres, les délais de réclamation, les pipelines de ventes, la rentabilité des clients, la souscription, les taux actuariels, les risques de réassurance, et les flux de trésorerie.

Dans la banque d'investissement, ces analyses couvriront les risques de marché, l'exposition aux positions, les activités commerciales, les rapports réglementaires, les études de marché, la liquidité, les garanties, les pipelines d'opérations, les comptes clients, la lutte contre le blanchiment d'argent, les contreparties, la détection des fraudes, la gestion de portefeuille et les tests de résistance des fonds propres. .

Nous avons constaté une augmentation significative du volume et de la variété des données transitant par les entreprises au cours de la dernière décennie. Comment voyez-vous le soi-disant entrepôt de données traditionnel évoluer pour répondre à ces exigences?

Ainsi, l'entreposage de données traditionnel a évolué pour intégrer les technologies de lac de données et de big data. Les données non structurées sont stockées dans des lacs de données, y compris des documents, des images, des vidéos, de l'IdO et des flux de médias sociaux, tandis que les données structurées (données stockées sous forme de tableau) sont stockées dans l'entrepôt de données. Les lacs de données sont généralement construits sur le système de fichiers Hadoop par rapport à l'entrepôt de données, qui est généralement construit sur des bases de données relationnelles. Les entrepôts de données modernes intègrent également NoSQL, comme des bases de données de graphiques et de documents, car certaines données sont plus adaptées à ces types de formats. Cela couvre le peu de variété.

En ce qui concerne le volume, dans les premières années de l'entreposage de données, les bases de données MPP comme Teradata, Oracle Exadata et Microsoft PDW étaient un moyen populaire de gérer de gros volumes de données tout en gardant les données relationnelles. Mais de nos jours, les technologies du Big Data sont beaucoup plus largement utilisées.

Quelle est votre opinion sur le lac de données? A-t-il sa place dans le système BI moderne? Complète-t-il l'entrepôt de données ou s'agit-il d'une alternative viable?

Oui. Les entrepôts de données modernes utilisent des lacs de données comme zone de transit qui permet aux utilisateurs et aux technologies frontales de ML d'accéder aux données brutes. Tant que vous ne cherchez pas à intégrer des données, le lac de données est une alternative viable. Ce type de cas d'utilisation est souvent observé dans les projets où les données sont cloisonnées (séparées des autres fonctions) et le temps de développement est minime, auquel cas les lacs de données sont très efficaces. Un bon exemple pour cela serait un projet de détection de fraude basé sur l'apprentissage automatique dans une banque ou un projet où une exigence réglementaire spécifique en matière de rapports doit être remplie dans un délai de trois mois. Lorsque ces silos sont supprimés ultérieurement (c'est-à-dire lorsque d'autres fonctions d'entreprise doivent accéder au résultat de la prédiction), la sortie du modèle peut être stockée dans l'entrepôt de données pour les utilisateurs en aval.

Cependant, dans la plupart des scénarios d'entreprise, vous devrez intégrer des données. Par exemple, un assureur ou un gestionnaire d'actifs devra créer un vue unifiée à partir de données sur les titres, les émetteurs, les politiques et les clients pour développer une image précise de leur entreprise.

Vous avez dit dans le passé que la compréhension de l'entreprise pourrait être la partie la plus critique du développement d'un entrepôt de données. Comment feriez-vous pour vous assurer que les exigences de l'entreprise sont fidèlement traduites dans l'architecture des données?

Oui, la compréhension des affaires est très importante. Vous ne pouvez pas concevoir un bon modèle de données sans une bonne compréhension de l'entreprise. Imaginez si vous étiez chargé de concevoir un entrepôt de données ESG (environnemental, social, gouvernance), mais que vous n'aviez aucune idée de ce qu'était l'ESG. Ou un data mart de souscription, mais vous n'avez jamais travaillé dans l'assurance. Vous ne pouvez pas savoir à quoi devraient ressembler les tables de faits et de dimensions. Un bon architecte de données doit s'intéresser à l'essentiel de l'entreprise. Supposons que vous conceviez un centre d'attribution de performance pour un gestionnaire d'investissement. Il est essentiel que vous vous renseigniez sur la différence entre les rendements arithmétiques et géométriques, les courbes de rendement et les facteurs d'interaction. Malheureusement, certains architectes de données ne sont pas intéressés par ces détails commerciaux essentiels. Ils sont plus intéressés par les aspects techniques.

La meilleure façon de s'assurer que les exigences métier sont bien intégrées dans le modèle de données consiste à exécuter divers scénarios métier, en testant si chaque scénario peut être satisfait en interrogeant le modèle de données à l'aide d'une simple requête SQL. Si pour cela, vous avez besoin d'une requête complexe, le modèle de données n'est pas bien conçu. Il s'agit généralement de la chute d'un lac de données; ils ne satisfont pas aux scénarios commerciaux compliqués. Et c'est le nœud de tout cela: bien écrire ces scénarios; vous devez avoir une bonne compréhension de l'entreprise.

Dans un article de blog précédent, vous avez décrit le nombre d'organisations de services financiers qui utilisent encore Excel pour générer des rapports et des analyses. Voyez-vous cette pratique changer avec des outils de visualisation plus sophistiqués devenant monnaie courante, ou allons-nous continuer à voir ce processus dans un avenir prévisible?

Les sociétés de services financiers continueront à utiliser Excel pour leurs analyses et leurs rapports. C'est la nature humaine car les employés dans ce domaine ont tendance à avoir de fortes compétences Excel. J'ai vécu cette préférence directement dans diverses banques et sociétés d'investissement. Même les organisations utilisant des plates-formes comme Tableau, Qlik ou Power BI ont demandé une fonction «d'exportation vers Excel» pour une analyse plus approfondie.

Bien que les rapports et tableaux de bord standard produits par les outils de visualisation soient importants (ils contiennent des données formalisées dans un format facilement assimilable), les utilisateurs doivent dans de nombreux cas effectuer leur propre analyse. Pour cela, ils demandent les données brutes derrière ces tableaux de bord dans un outil avec lequel ils sont beaucoup plus familiers - Excel. Avec les données brutes à portée de main, ils peuvent regrouper les données différemment, appliquer certains filtres, etc., le tout en fonction de leurs besoins.

Rappelez-vous, ce sont des analystes financiers, des gens intelligents et avertis - analyser les données et analyser les chiffres, c'est ce qu'ils font. La consommation de rapports statiques ne satisfera jamais l'ensemble de leurs besoins, c'est pourquoi il n'est généralement pas judicieux d'essayer de répondre à tous les besoins possibles dans l'outil de BI.

Il y a eu une forte poussée pour commencer à déplacer les entrepôts de données vers le cloud sur des plates-formes telles que Google BigQuery ou Amazon Redshift ces dernières années. Quelle est votre opinion sur les avantages du déploiement dans le cloud? Recommanderiez-vous toujours de vous en tenir aux bases de données sur site dans certains cas?

Les principaux avantages sont l'externalisation des ressources humaines et la flexibilité des ressources informatiques. Avec un entrepôt de données cloud, vous n'avez pas besoin de payer beaucoup de personnel en interne pour maintenir les serveurs, le stockage, le réseau, la sécurité, la sauvegarde et les processus de reprise après sinistre. Si vous avez besoin d'un nouveau serveur de base de données, vous n'aurez pas besoin d'attendre trois semaines pour acheter, configurer, installer, attacher du stockage, etc. Au lieu de cela, vous obtenez une capacité de serveur accrue à la demande et vous payez à l'heure.

Cette proposition de valeur n'est pas seulement intéressante pour les petites entreprises, mais aussi pour les grandes entreprises qui se demandent souvent «sur quelles activités dois-je me concentrer?» Que vous soyez un détaillant, une société de télécommunications ou une société financière, la réponse n’est certainement pas «l’activité serveur» ni «l’activité infrastructure informatique». Vous sous-traitez donc. Avec l'infrastructure cloud, vous pouvez augmenter et réduire la puissance de calcul et la mémoire en fonction de vos besoins. Vous désactivez les serveurs de test et de développement lorsqu'ils ne sont pas utilisés la nuit et vous payez à l'heure.

En ce qui concerne les puissants serveurs d'entrepôt de données, le coût de leur configuration en interne (sur site) est prohibitif. Les compétences requises des employés sont également prohibitives, car de nombreuses compétences spécialisées différentes sont requises, du SAN à la sécurité, de Docker à Yarn. Je recommanderais donc un déploiement basé sur le cloud plutôt qu'un entrepôt de données sur site. C'est l'argument pour utiliser Google BigQuery, Amazon Redshift et Azure Dedicated SQL Pool (anciennement SQL DW, PDW, APS).

Cependant, supposons qu'il ne s'agisse pas d'un nouveau projet et que vous deviez améliorer un entrepôt de données existant sur site avec de nombreux systèmes sur site connectés. Dans ce cas, le coût de la migration de tous ces systèmes / applications vers le cloud est énorme. Disons, à titre argumentatif, qu'il en coûterait 2 millions de dollars supplémentaires et trois ans pour mener à bien ce genre de projet. Cela n'a pas de bon sens commercial de dépenser ces 2 millions de dollars pour aucune fonctionnalité commerciale supplémentaire. Gardez-le sur site, effectuez les améliorations sur site et, en attendant, construisez lentement votre nouveau système dans le cloud. Actuellement, environ 25% des budgets informatiques sont consacrés à la maintenance des systèmes et infrastructures existants. Il s'agit du pool dans lequel vous devez puiser pour conduire une migration lente vers le cloud.

Je vous ai déjà vu parler du grand débat ETL contre ELT. Quand il s'agit de charger des données dans l'entrepôt de données, avez-vous une approche préférée? Ou faut-il décider au cas par cas?

Il doit être décidé au cas par cas. Cela dépend de l'infrastructure. Cela dépend du lac de données. Cela dépend de l'outil d'ingestion de données. Et cela dépend de la plate-forme d'entrepôt de données. En fin de compte, peu importe que vous utilisiez ETL, ELT ou ELTLT; vous pouvez procéder à l'ingestion de données de différentes manières. Vous pouvez le mettre en scène une fois, deux fois ou aucun. Transformez-le une fois, deux fois ou aucun. Il vous suffit de choisir l'approche la plus appropriée pour chaque pipeline et chaque situation.

Qu'il s'agisse d'ETL ou d'ELT, le «must have» de l'ingestion de données est le test automatisé. Nimrod Avissar l'explique bien ici. C'est l'approche que je préfère sur ETL / ELT: approche de test automatisé.

En ce qui concerne le processus de développement de l'entrepôt de données lui-même, pensez-vous que l'agilité ou la cascade sont mieux à même de répondre aux exigences de BI en constante évolution ?

Il ne s'agit pas d'agile ou de cascade (agile, bien sûr, qui veut commettre un gros morceau en une seule fois?). Le processus de développement de l'entrepôt de données concerne les opérations de développement. Cette discipline d'ingénierie est maintenant mature. Vous devez disposer d'un pipeline de versions, d'un tableau de sprint, d'un backlog, d'un contrôle de code source, d'un contrôle des modifications, d'une journalisation des erreurs et d'une gestion des incidents. Une équipe de développement d'entrepôt de données doit disposer d'une automatisation DevOps, c'est-à-dire que le processus de publication doit être automatisé, du contrôle à la source, de la demande d'extraction dans la branche de publication, du déploiement dans un test, de l'exécution de tests automatisés et du déploiement en production.

CI / CD était auparavant associé au développement d'applications, pas au développement d'un entrepôt de données. Mais maintenant, c'est un incontournable. Si vous dirigez une équipe de développement d'entrepôt de données sans elle, vous engagez de nombreux coûts supplémentaires chaque mois. Ou pire, sacrifier la qualité de construction de l'entrepôt de données.

Sur votre blog, vous avez écrit sur certains éléments clés qui déterminent l'efficacité de votre entrepôt de données, notamment la disponibilité des données, la sécurité des données, la qualité des données et, bien sûr, les performances de requête / chargement. Selon vous, quel est le facteur le plus crucial?

L'élément le plus important qui détermine l'efficacité d'un entrepôt de données est de savoir s'il répond ou non aux problèmes commerciaux et aux cas d'utilisation. En fin de compte, vous pourriez utiliser votre DW pour créer des rapports clients, des tableaux de bord de gestion, des rapports réglementaires ou des analyses commerciales générales. Pourtant, si cela ne résout pas le problème de votre entreprise, cela n'est tout simplement pas efficace. Dans ce cas, l'échec peut généralement être lié à l'une des trois choses suivantes:

1. Manque de données particulières, par exemple des données sur un produit ou un client important,
2. Problèmes de qualité des données, p. Ex. Données incorrectes,
3. Difficulté à interroger les données, par exemple, les données se trouvent dans l'entrepôt mais n'apparaissent pas dans les rapports.

Je dirais que des données incorrectes sont particulièrement dommageables pour l'entreprise, surtout lorsqu'elles ont agi sur la base de ces données. Par exemple, si vous avez utilisé les données de performance de l'entrepôt pour créer une fiche d'information et mal déclaré la performance du fonds, il s'agit à la fois d'un risque de réputation et d'un risque financier énorme. Non seulement cela peut entraîner une pénalité substantielle de la part des autorités financières, mais vos clients pourraient se diriger vers la sortie sur la base des chiffres trompeurs que vous avez cités, provoquant des sorties massives et un avenir commercial globalement sombre.

En comparaison, si une requête d'une heure a duré toute la journée, ce n'est rien, presque aucun dommage financier. De même avec ne pas avoir de données particulières (disponibilité des données), ce n'est pas un risque aussi énorme que des données incorrectes publiées / envoyées aux autorités ou aux clients. D'un autre côté, si les données de vos clients sont volées, cela peut également nuire à la confiance du client, provoquant un exode des clients, ce qui pourrait vous laisser sans affaires dans un avenir prévisible.

Je dirais que la qualité et la sécurité des données sont les deux principaux problèmes contre lesquels vous devez vous protéger.

Vous avez également abordé certaines des étapes critiques de la construction d'un entrepôt de données, à savoir la modélisation des données, la création de processus de chargement et de livraison de données, puis la conception de ces processus pour garantir une efficacité maximale. Selon vous, quelle est la partie la plus difficile du développement d'un entrepôt de données?

La partie la plus difficile du développement d'un entrepôt de données n'est pas la modélisation des données, le chargement des données ou l'efficacité des processus, mais la détermination architecture est le plus approprié.

Si vous avez choisi de créer un lac de données, alors que vous avez vraiment besoin d'un entrepôt de données dimensionnel (en raison de sa nature intégrée), alors vous alliez dans la mauvaise direction dès le départ. Si vous avez décidé d'utiliser une technologie d'ingestion particulière qu'aucun de vos employés n'avait les compétences nécessaires pour faire fonctionner, vous avez fait un investissement important qui a augmenté votre risque et créé des retards évitables dans la mise en œuvre. Si vous décidiez d'acheter un entrepôt de données préconçu, mais que le modèle de données ne vous convenait pas, c'était comme construire un gratte-ciel sur une base faible.

 Ce que nous ne voyons pas dans les coulisses, c'est ce qui fait généralement le succès de l'entrepôt, c'est-à-dire le choix de l'architecture, les opérations de développement et le qualité des données contrôles.

Où voyez-vous l'intégration de l'automatisation de l'entrepôt de données ici? Comment peut-il aider à réduire les efforts et le temps consacrés à certaines de ces tâches? Où voyez-vous la grande valeur d'un outil spécialement conçu à cet effet?

La valeur de l'automatisation de l'entrepôt de données est le chargement automatique. Par exemple, de nombreuses sociétés de gestion d'actifs utilisent des systèmes de gestion de placements prêts à l'emploi largement utilisés pour gérer leurs portefeuilles. Un entrepôt de données dimensionnel qui peut charger automatiquement des données à partir d'eux a beaucoup de valeur. De nombreuses grandes entreprises de fabrication utilisent SAP comme système opérationnel de base. Un entrepôt de données capable de charger automatiquement des données à partir de SAP est précieux car vous n'avez pas à développer les pipelines pour charger les données, ce qui prend beaucoup de temps. Dans tous les cas, vous devez pouvoir modifier le modèle dimensionnel comme bon vous semble.

La meilleure chose à faire est d'essayer d'automatiser l'ingestion de données. L'intégration de plusieurs sources de données dans une dimension est complexe (par exemple, dimension client, dimension entreprise, dimension sécurité), et son automatisation est encore plus difficile. Nous pourrions avoir affaire à des fichiers verticaux ou incrémentiels, des fichiers CSV ou Excel. Nous devons être en mesure de pivoter, d'agréger et de fusionner ces données.

De plus, nous ne devons pas supposer que la source de données est un fichier prêt à être traité; il peut être nécessaire de le déchiffrer, de le décompresser, de le renommer ou de le télécharger au préalable. Le cœur de l'intégration de données provenant de sources multiples implique un processus appelé «correspondance de données», et il pourrait s'agir d'une cascade correspondant à plusieurs critères. Le deuxième processus de base est appelé «enrichissement des données», par exemple, si le titre n'a pas de notation S&P, de pays à risque ou de secteur GICS, nous l'enrichissons à partir d'une source externe telle que Bloomberg ou FactSet.

La valeur fondamentale d'un entrepôt de données est la dimension intégrée qui est créée à partir de nombreuses sources. Un outil d'automatisation de l'entrepôt de données doit être capable de construire cette dimension, non pas une dimension pays ou devise, mais une dimension client ou sécurité composée de plusieurs tables source.

Selon vous, quelles fonctionnalités et fonctionnalités sont absolument essentielles pour un outil d'automatisation d'entrepôt de données efficace?

Les fonctionnalités absolument essentielles pour un outil d'automatisation d'entrepôt de données efficace sont:

1. Il doit rester à jour avec ERP, CRM ou IMS (par exemple, SAP, Salesforce ou ThinkFolio) à mesure qu'ils changent de version
2. Il doit avoir la capacité d'intégrer plusieurs sources pour créer des dimensions complexes, c'est-à-dire la dimension client
3. Il doit avoir la capacité de prétraiter les fichiers de données, par exemple pour récupérer ou télécharger des fichiers pour traitement.
4. Il doit permettre des tests et un déploiement automatisés

Enfin, vers quoi pensez-vous que l'entrepôt de données se dirigera dans le futur? Quelles avancées significatives (le cas échéant) prévoyez-vous dans cet espace?

Certaines personnes pensent pouvoir remplacer deux ans de développement d'entrepôt de données par un développement de lac de données de trois mois. Ceci est trompeur car les données client ou produit chargées dans cette dernière architecture ne sont pas intégrées et ne peuvent donc pas être interrogées. Et ils pourraient oublier d'intégrer des contrôles de qualité des données ou de préparation opérationnelle (par exemple, des outils de surveillance) dans le système, ce qui prendrait autrement 30% de l'effort total. Certes, certains projets n'ont pas besoin d'intégration, et dans ce cas, un lac de données peut être utilisé, mais vous devez tout de même créer des contrôles de qualité des données et de préparation opérationnelle.

Ce que je vois venir dans le futur, c'est l'automatisation des tests et l'automatisation des contrôles de qualité des données. Il n'est pas trop difficile de construire un outil qui surveille chaque fichier entrant et effectue des vérifications sur des colonnes spécifiées, en le comparant aux données des derniers jours. L'autre chose qui pourrait être construite est un outil de BI qui est convivial CI / CD, par exemple basé sur XML, afin qu'il puisse être déployé du contrôle de source à la production automatiquement car il est basé sur du texte.

Et enfin, jusqu'à présent, il n'existe pas d'outil de gouvernance des données unique sur le marché capable d'analyser les bases de données, les outils ETL et BI et de créer automatiquement lignage de données des fichiers source au rapport. Il n'est peut-être pas possible de construire cet outil pour chaque base de données, ETL et outil BI, mais il est possible de faire les principaux. L'automatisation est la clé de la gouvernance des données.

Astera DW Builder - Une réponse agile aux défis de développement de votre entrepôt de données

Astera DW Builder est une plate-forme unifiée qui vous permet de déployer et d'utiliser rapidement des modèles de données enrichis de métadonnées en fonction des besoins des utilisateurs finaux.

Le produit offre une gamme de fonctionnalités prêtes à l'emploi que vous pouvez exploiter pour créer un entrepôt de données agile qui répond vraiment aux besoins de votre entreprise. De la mise en œuvre de règles métier et de conventions de dénomination au niveau logique à la création de pipelines de données complexes capables de récupérer automatiquement les données des systèmes source de votre choix, de les transformer en fonction de vos exigences en matière de qualité des données et de les charger dans un cloud ou une base de données sur site de votre choix , tout est rendu possible grâce à notre solution sans code.

Maintenant, nous vous donnons la chance d'avoir un premier aperçu exclusif de la vitesse et de l'intuitivité d'ADWB par vous-même lors d'un événement de lancement de bout en bout qui promet de changer votre vision de l'entreposage de données. Regarder le événement de lancement exclusif ici.