Webinaire – Exploration des données n° 1 – Le grand débat sur l'architecture des médaillons

Merci à tous d'être venus. C'est un plaisir pour moi d'être l'hôte de cette soirée.

Je suis évangéliste en chef chez Actian. Je m'appelle Ole Olesen-Bagneux et dans le cadre de ce grand débat sur les médailles, je vais interviewer Piethein Strengholt, l'auteur de « Building Medallion Architectures » (Construire des architectures médailles). Martin est également présent pour nous mettre au défi.

Chesbrough, est-ce que cela se prononce correctement Chesbro ? Oui, c'est parfait. Chesbrough Chesbrough Et c'est en partie grâce à lui que nous avons ce débat aujourd'hui, car j'écrivais sur les architectures en médaillon sur LinkedIn, et mon post est devenu viral car j'ai touché un point sensible en disant que je ne pensais pas que les architectures en médaillon disparaîtraient un jour.

Quelle que soit la modernité de nos architectures de données, nous disposerons d'architectures en couches afin de préparer les données à une utilisation analytique. Sans plus attendre, l'ordre du jour de cette réunion, ou de cet événement, est que je vais interviewer Piethein. J'ai préparé quelques questions détaillées sur son nouveau livre récemment publié chez O'Reilly, Building Medallion Architectures.

C'est un excellent livre et cela prendra environ 20 à 25 minutes pour que vous appreniez tout sur l'architecture Medallion. Et je poserai quelques questions critiques. Mais l'idée est que Martin se joigne au débat dans environ 20 à 25 minutes.

Il a préparé une liste très détaillée et très précise des points critiques qu'il aimerait examiner concernant l'architecture du médaillon et les avantages et inconvénients de cette architecture. Nous entrerons donc davantage dans le débat plus tard dans la conversation. Et tous les participants à la conférence téléphonique sont bien sûr les bienvenus pour poser des questions.

Donc, sans plus attendre, et je pense qu'à ce stade, Martin, oui, j'allais justement dire que je pense que les instructions aux participants devraient être qu'ils posent leurs questions via la boîte de questions-réponses en bas de leur fenêtre Zoom, puis nous reprendrons ces questions lorsque nous entrerons dans le débat. C'est bien ça ? Exactement.

Oui, parfait. Merci.

À ce moment-là, je désactiverai ma vidéo, je vous laisserai mener votre interview, et je reviendrai plus tard, à moins que je n'aille me coucher. Restez éveillés, s'il vous plaît. Prenez un café bien chaud.

Bon, fort, bon, fort café là-bas. J'ai mon café, oui. Désolé.

Parfait. Merci beaucoup. Je veux vraiment, la raison de la blague, c'est que c'est le matin pour moi et je viens de descendre d'un avion.

Ce n'est donc pas par ennui ou quoi que ce soit d'autre, je suis en fait fasciné par cette conversation, alors vas-y. Je ne te remercierai jamais assez d'être ici, Martin, merci beaucoup. Et reste éveillé, s'il te plaît.

Nous aurons besoin de vous pour le débat plus tard. D'accord Peter, j'ai préparé beaucoup de questions. Comme vous l'avez vu lors de la préparation de cette réunion, j'ai relu votre livre, je l'ai lu très, très attentivement.

J'ai donc préparé beaucoup de questions différentes, mais je souhaite rester à un niveau relativement élevé. Certaines d'entre elles entreront dans les détails et correspondront au niveau de détail de votre excellent livre. Mais pour les personnes qui participent à cette conférence téléphonique, à ce webinaire, commençons par la question la plus évidente.

Pourquoi avez-vous voulu écrire ce livre, Peter ? Qu'est-ce qui vous a motivé à l'écrire et pourquoi ? Oui, avant de répondre, permettez-moi de me présenter rapidement.

Oui, évidemment. Je suis bien sûr l'auteur de ce livre, qui traite de la construction d'architectures en médaillon et du suivi de l'ensemble de la conversation. J'ai également écrit un autre livre intitulé « gestion des données grande échelle ».

Certaines personnes que je vois dans le chat me connaissent peut-être grâce à Microsoft, où j'ai travaillé aux Pays-Bas en tant que directeur des données. J'ai longtemps travaillé pour ABN AMRO. J'ai récemment rejoint une autre entreprise appelée NN Group, une grande compagnie d'assurance nationale.

Pour revenir à votre question, pourquoi écrire un livre sur les architectures médalliennes ? Ce sujet m'a fasciné lorsque je travaillais chez Microsoft. De nombreux clients viennent chez Microsoft parce qu'ils souhaitent tirer davantage de valeur de leurs données, n'est-ce pas ?

Hum, et souvent, la réponse est : « Eh bien, si vous souhaitez vous lancer dans l'exploitation des données et générer de la valeur, la première chose à faire est de créer une plateforme. » Donc, un service de données, un service de plateforme. Et ensuite, la question suivante se pose.

Alors, que dois-je faire ? Eh bien, développer cette architecture. Et la meilleure pratique souvent recommandée est de chercher à développer une architecture Medallian.

Mais souvent, honnêtement, c'est là que s'arrêtent les conseils. Les entreprises reçoivent donc des conseils de haut niveau sur la nature de ces couches. Il existe des niveaux bronze, argent et or, ainsi que des conseils normatifs de haut niveau.

Mais en substance, cela revient vraiment à trouver les bonnes nuances. Et oui, il y a aussi l'empathie, et les gens ont beaucoup de mal à interpréter ces modèles de conception de manière précise. C'est donc parce que j'ai constaté un manque de conseils dans ce domaine que j'ai décidé d'écrire un livre.

Et pour écrire ce livre, avant de commencer à écrire, j'ai interrogé de nombreux lecteurs potentiels pour savoir ce qu'ils voulaient entendre de ma part. La difficulté réside dans le fait qu'il y a tellement d'attentes différentes. Et c'est aussi une architecture très subjective.

Je l'ai donc fait de cette manière. Il y a donc une partie plus théorique. Qu'est-ce qu'un médaillon et d'où vient-il exactement, les couches, etc.

Il y a ensuite un tutoriel, un guide pratique qui vous accompagne pas à pas dans la conception réelle, avec des extraits de code, des captures d'écran, des instructions et la manière exacte de construire cette architecture en médaillon. Il y a ensuite des études de cas, dans lesquelles je travaille avec différents clients issus de différents secteurs et de différentes tailles. Vous apprendrez ainsi pourquoi ils ont mis en œuvre et comment ils ont conçu leurs architectures en médaillon.

Et enfin, j'avance rapidement et j'essaie de faire le lien avec d'autres domaines de gestion des données de l'IA. Voilà donc en gros comment le livre a été structuré. Oui, j'adore cette structure.

En lisant le livre, c'est comme si on vous expliquait comment vous devriez procéder, puis on vous disait « allons-y ». Ensuite, vous voyez comment les autres s'y sont pris. Et enfin, le livre se dissout en quelque sorte dans un modèle plus complexe, avec plusieurs architectures en médaillon qui font des choses différentes et évoluent différemment.

Et moi, je préfère nettement cette dernière partie. Et je suppose, vous savez. Et bien sûr, Piethein, je suis désolé de ne pas vous avoir présenté plus officiellement.

Je suppose simplement que tout le monde ici vous connaît.

Évidemment, tout le monde ne vous connaît pas, mais vous êtes un auteur très connu, O'Rielly, avec beaucoup de lecteurs. Bon, plongeons-nous un peu dans l'architecture du médaillon elle-même. Quelles sont les trois couches, bronze, argent et or, expliquées brièvement ?

Oui, brièvement, il est important de préciser d'emblée que ces couches doivent être interprétées comme des couches logiques. Il s'agit d'un modèle de conception logique. Une erreur que je constate souvent dans les entreprises avec lesquelles j'ai travaillé est qu'elles considèrent ces couches comme des couches physiques.

Ce n'est donc pas correct. Il s'agit de couches logiques, qui permettent d'organiser vos données de manière logique. Elles supervisent donc une architecture de bout en bout, mais à l'intérieur de ces limites logiques, elles s'alignent sur certaines responsabilités et préoccupations.

Dans la première couche, je vois qu'il s'agit principalement de capturer les données, les données brutes, de valider les données, de les archiver dans la couche suivante, en argent, je vois principalement. Il s'agit donc de normaliser les données, de nettoyer les données, de corriger légèrement les données, de les rendre conformes. Mais là, vous voyez, beaucoup de discussions commencent déjà à avoir lieu.

Avez-vous déjà besoin de combiner et de joindre ces données entre les systèmes sources ? Créez-vous data products, par exemple, dans cette couche ? Cela dépend donc beaucoup.

Oui. Et puis, en or, cette couche que je vois là, c'est là que vous adaptez les données à l'usage prévu. Donc pour la consommation finale.

Donc, l'utilisation commerciale des données, là encore, eh bien, ça fait l'objet de nombreuses discussions. Avez-vous besoin d'une couche d'intégration classique ? Si vous avez des préoccupations qui se recoupent dans différents groupes d'utilisateurs, ou est-ce que vous les séparez ?

Quel est le rôle des data products en quoi consistent-ils ? Encore une fois, ces questions font l'objet de nombreuses discussions. Mais c'est en gros ainsi que je vois les choses.

Oui, oui, tout à fait. C'est très clair quand on lit le livre. Donc, pour ceux qui ne connaissent pas bien l'architecture en médaillon, juste pour planter le décor, quand vous dites que ces couches sont logiques et non physiques, qu'est-ce que cela signifie concrètement ?

Quel type d'architecture en résulte ? La question est-elle claire ? Oui, la question est claire.

La mise en œuvre physique peut donc être très différente de l'abstraction logique, c'est-à-dire de la manière dont vous organisez vos données à travers ces trois couches. Vous pouvez, par exemple, opter pour un modèle, en supposant que vous ayez trois couches physiques mises en œuvre. D'accord ?

Un autre modèle de conception pourrait être, par exemple, maintenant que j'ai plus de couches physiques, je découple à nouveau certaines préoccupations au sein de ces couches. Ainsi, la première étape consiste, par exemple, pour le bronze, à capturer ces fichiers bruts et à les conserver dans leur format d'origine.

Ensuite, toujours dans le bronze, vous copiez vers une autre couche interne, et vous transformez les données dans le format de données. Peut-être ensuite, vous les copiez à nouveau vers une autre couche où vous les fusionnez avec des données préexistantes, qui sont encore brutes et techniques, mais à ce stade. Il s'agit donc d'un exemple de trois couches physiques au sein d'une couche verticale.

Oui. Merci de le souligner. C'est exactement ce que je demandais, car je pense qu'au moins une partie de l'architecture en médaillon devient très controversée parce que les gens ne pensent vraiment pas à cette distinction entre la couche logique et la couche physique.

Parce que si vous, si vous mettez, et je devrais vous poser des questions, mais je viens de dire, n'est-ce pas, dans quelle mesure seriez-vous d'accord avec cette hypothèse selon laquelle les gens comprennent mal ce point, mais ensuite, oui, Pour moi, la motivation pour écrire ce livre, j'ai participé à de très nombreuses discussions avec des clients, lorsque je travaillais chez Microsoft, où les gens interprétaient l'architecture Medallian comme étant simplement trois couches physiques. Oui, j'ai vraiment dû leur ouvrir les yeux. Eh bien, non, il s'agit de dissocier les préoccupations.

Et donc, vous pouvez avoir autant de couches que vous le souhaitez. Permettez-moi de vous poser quelques questions sur les couches elles-mêmes. Tout d'abord, pourquoi, j'ai donc une question pour chaque couche.

Pourquoi ne devriez-vous pas requête couche de bronze ? Pourquoi ne devriez-vous pas requête ? Je veux dire, beaucoup de gens y pensent, mais pourquoi ne devriez-vous pas le faire ?

Vous pourriez, mais c'est brut et vous êtes donc étroitement lié à la structure d'origine des systèmes sources que vous avez, disons, à gauche de votre architecture. Ainsi, si ces structures du côté du système source changent soudainement , cela pourrait avoir des effets perturbateurs sur la structure de cette couche bronze. Si vous commencez à opérationnaliser des rapports et des agents sur votre couche bronze, vous aurez des difficultés à suivre tous ces changements.

Donc, encore une fois, la meilleure pratique serait de vous dissocier de la structure des systèmes sources, puis de passer à la couche suivante qui concerne cette question. Deux questions se posent donc à propos de la couche argentée. Tout d'abord, pourquoi la couche argentée est-elle simple ?

Vous, vous appelez cela simple tout au long du livre. Et deuxièmement, pourquoi principalement comme un ML et les ingénieurs en IA, pourquoi veulent-ils requête couche argentée ? Je dis simple parce que je recommande de ne pas déjà croiser les systèmes sources commencer à combiner et mélanger et l'intégrer.

Les préoccupations doivent donc être très largement adaptées à ce que vous trouvez au niveau du système source. À mon avis, il faut nettoyer et corriger les données à ce niveau. Donc au niveau du système source.

Parce qu'il conserve le contexte authentique. Il est idéal pour créer des agents opérationnels et des ports B opérationnels, car le contexte est très similaire à celui que vous verriez dans votre système source. Si, à mon avis, vous commencez déjà à ce stade à combiner et à intégrer des données provenant de différents systèmes sources, vous devez conformer le contexte.

Et oui, vous perdrez le contexte authentique ou le contexte original tel que vous l'attendriez du côté du système source. Et cela rend les choses difficiles. Donc, oui, si vous souhaitez opérationnaliser ou créer un rapport opérationnel, vous devez revenir au contexte original, disons.

Ce n'est pas idéal. Je recommanderais donc aux auditeurs de reporter cette préoccupation à un stade ultérieur. Oui.

Et encore une fois, c'est là que vous voyez beaucoup de Je fais également un commentaire, Je vous en prie, continuez. Désolé. Oui, donc certaines personnes préconisent, par exemple, d'appliquer des erreurs de données au sein de cette couche argentée, ou déjà à ce moment-là, de combiner et de croiser les systèmes sources pour commencer à intégrer vos données.

Oui, cela dépend, encore une fois, alors examinez vos propres exigences, vos propres besoins. Ce n'est ni faux, ni vrai.

Mais oui, je préfère le modèle de conception dont nous avons discuté. Donc oui, mettez de côté l'intégration des systèmes sources croisés et reportez cela au dernier lien vers l'or. Oui.

D'accord. D'accord. Eh bien, je ne veux pas dire que je suis d'accord, parce que je ne suis pas sûr d'être d'accord là-dessus, mais en tout cas, c'est ce que vous soutenez dans le livre qui me convient.

Hum, donc, à propos de la couche dorée, ma question à la couche dorée est la suivante : vous dites que c'est extrêmement compliqué, surtout par rapport à la couche argentée. Pourquoi est-ce compliqué ? Pourquoi la couche dorée est-elle compliquée ? Oui, parce que je constate souvent qu'il y a des préoccupations contradictoires.

Vous souhaitez donc harmoniser les données, peut-être au niveau de l'entreprise ou pour un certain périmètre, afin de garantir cohérence données dans les différents cas d'utilisation. Il faut ensuite rendre les données très spécifiques pour cas d'usage du cas d'usage . Donc oui, là encore, vous êtes face à un dilemme.

Ces préoccupations ne sont pas faciles à concilier. Ensuite, il y a ce besoin de distribuer des données à travers différents domaines, différentes équipes et à des consommateurs de données externes. Ils comptent sur des données stables et hautement réutilisables.

Une fois encore, vous voyez cette préoccupation. Ainsi, lorsque vous avez un cas d'usage vous souhaitez être flexible et apporter spontanément de nombreux changements, cela contraste avec la nécessité de fournir des données réutilisables hautement fiables à différents consommateurs. C'est pourquoi je constate souvent, dans le cadre de Gold, que vous commencez à séparer à nouveau ces différentes préoccupations, et que vous pouvez donc voir, une fois encore, différentes couches physiques au sein de cette couche Gold unique.

Absolument. Passons maintenant à la partie du livre que j'ai préférée, et je pense que nous aurons le temps d'en discuter, c'est la quatrième partie du livre, et c'est là que vous vous ouvrez vraiment, car je pense qu'une autre chose que les gens n'aiment pas dans l'architecture médaillon, c'est qu'ils la considèrent comme une sorte d'autoroute de transport de données à l'échelle de l'entreprise à laquelle chaque cas d'usage se conformer et passer par là afin de fournir des cas d'utilisation pour l'analyse, n'est-ce pas ? Et donc ce que j'aime vraiment dans la quatrième partie de votre livre, c'est que vous vous ouvrez vraiment et que vous dites, tout comme dans votre premier livre, gestion des données grande échelle, vous offrez cette perspective de flexibilité et évolutivité, qui sont vraiment au cœur de toute architecture de données moderne, voire de toute architecture logicielle, n'est-ce pas ?

Vous vous ouvrez donc vraiment et dites : « D'accord, nous pouvons avoir plusieurs architectures de médailles dans une même entreprise. » Et en fait, vous admettez même que la plupart des entreprises ont plusieurs architectures de médailles. L'une des couches qui m'intéresse particulièrement dans ce contexte est celle que vous appelez la couche de conception et de distribution des produits.

Je te pose donc des questions très détaillées ici. J'espère que tu te souviendras de tout cela, Piethein. Peux-tu nous en dire un peu plus sur ce qu'est cette couche ?

Parce que je pense que c'est une couche très prometteuse. Oui. Pour revenir à votre remarque précédente, je ne pense pas que ce soit une hypothèse.

Lorsque vous êtes une grande entreprise, vous disposez certainement de nombreuses architectures de type médaillon. La conception de ces architectures varie en fonction de la taille, du nombre de systèmes sources, et selon que vous soyez davantage orienté fournisseur ou consommateur. Dans mon livre, je définis donc différents archétypes en fonction de la nature du domaine et de la meilleure façon de vous organiser et de vous aligner, y compris sur ces différentes couches.

Mais dans cette architecture multi-médailles, lorsque vous commencez à partager des données de manière transparente, vous souhaitez pouvoir compter sur des données de haute qualité, réutilisables et stables. Et donc, à mon avis, votre modèle de données devient davantage un modèle d'interface. Et c'est là qu'intervient la couche de produits de données.

Il faut donc fournir des données robustes et stables, et c'est là que de nombreuses directives de conception de modélisation des données entrent en jeu, comme la manière de traiter les données de référence. Pour donner un exemple simple, imaginez que vous ayez plusieurs domaines, plusieurs architectures Medallian, et qu'ils travaillent tous de isolement, remanient leurs structures de données et fournissent ces problèmes de données. Mais vous ne vous alignez sur aucune norme de données ni aucune donnée de référence.

Il sera alors très difficile pour les consommateurs, au final, de combiner facilement les données , car ils devront composer avec différentes valeurs de référence locales et des types de données non conformes, par exemple. Dans mon domaine, il faudrait donc fournir de nombreuses directives en matière de modélisation des données à toutes ces différentes équipes. Elles modélisent et reformulent ainsi leurs données d'une certaine manière.

Toutes ces différentes équipes peuvent facilement interpréter ces données, les exploiter, les combiner, etc. Oui, vous l'avez appris dans le livre, c'est assez complet. Il devrait donc y avoir beaucoup de conseils à ce sujet.

Non, mais en effet, je considère cette couche comme vraiment importante pour les personnes qui souhaitent adopter des approches plus décentralisées pour l'ensemble des architectures de données. N'est-ce pas ? Oui.

Peut-être, peut-être, je pense que nous avons le temps pour une dernière question, car avant de passer le micro à Martin, je vais rester devant ma caméra et je dirai peut-être un mot ou deux, mais je veux vraiment laisser Martin répondre à ses questions. Elles sont excellentes. Donc, ma dernière question est la suivante : vous avez un concept que vous appelez le « medallion mesh ».

Nous pouvons en parler brièvement avant que je passe la parole à Martin. Qu'est-ce que le « medallion mesh » ? Vous connaissez data mesh?

Euh, c'est ça ? Donc, avec une architecture fédérée distribuée, différentes équipes exploitent chacune leur propre architecture de données, disons, à petite échelle, et elles distribuent les données lorsque vous stratifiez vos données selon la stratification en médailles dont nous venons de parler. Et toutes ces équipes procèdent de manière similaire.

C'est ce que j'appelle une architecture en maillage médaillon. Mais ce qui est important ici, et je pense que ce n'est pas tant une question de stratification en soi. Je pense que cela se situe davantage au niveau de l'entreprise que de la stratification.

C'est un modèle de communication. Et je constate souvent que les choses tournent mal parce que les équipes interprètent chacune à leur manière la manière dont la superposition est effectuée au sein de ces différentes architectures. Il est donc préférable, par conséquent, que je recommande d'utiliser la superposition en médaillon comme modèle de communication.

Toutes ces équipes adhèrent donc davantage à la même manière d'organiser leurs données au sein de ces différentes architectures, ce qui facilite la distribution et le partage des données entre ces différentes petites architectures. Je pense que c'est une excellente remarque pour passer la parole à Martin. Martin et moi sommes toujours éveillés.

Le café a-t-il fait effet ? Oui, oui, je suis là. Merveilleux, Martin.

Je me contentais de rester en retrait. C'était donc une excellente série d'entretiens. Une excellente série de questions.

Tout d'abord, je tiens à remercier Ole de m'avoir invité. Pour commencer, je tiens à dire que je suis honoré d'être en présence de deux auteurs O'Reilly. Vous savez, vous êtes très honorés et vous êtes tous des personnalités invitées dans le monde des données.

Euh, je pense que, vous savez, je suis ici architecte de données travaillant pour un petit cabinet de conseil en ingénierie à Melbourne, en Australie. Et je vais simplement endosser le rôle de représentant des architectes de données profanes dans tout cela. Oui.

Hum, j'espère pouvoir répondre de manière satisfaisante aux questions qui pourraient être posées. Pour replacer les choses dans leur contexte, je voudrais commencer par dire que lorsque Ole a fait l'éloge du livre de Piethein sur LinkedIn, je lui ai répondu, à moitié sur le ton de la plaisanterie, dans un commentaire : « Oh, je pense que je vais devoir avoir une conversation sérieuse avec toi. Ole, je respecte ton opinion, et j'espère que tu pourras me convaincre du contraire. »

Mais les architectures en médaillon ont été ma plus grande frustration en tant qu'architecte de données depuis maintenant une vingtaine d'années. C'est pour mettre les choses en perspective. Et il y avait un aspect sérieux à cela, ainsi qu'une sorte de poussée, j'espère pouvoir vous appeler mon ami, vous voyez ?

Hum, et je pense que c'est là que j'ai pensé au livre de Piethein, parce qu'ensuite j'ai envoyé ça sans avoir lu le livre de Piethein, n'est-ce pas ? Alors je me suis dit que je ferais mieux de lire le livre pour que, vous savez, une fois que vous avez commencé à mordre à l'hameçon et à dire « oui, nous ferions mieux d'avoir un débat à ce sujet ». Hum, et j'ai trouvé que c'était un excellent livre.

Vous savez, en fait, comme vous le dites, je ne pense pas qu'il existe beaucoup de livres expliquant les architectures en médaillon. Et en réalité, cela vient du monde Databricks et du monde Lakehouse. Ou, pour être plus précis, probablement plutôt du monde des lacs de données.

Et je pense que cela a été l'un des défis, c'est qu'il est interprété de différentes manières par différentes personnes. Et il n'y a pas vraiment de forum pour en débattre. Et ce livre nous offre un forum pour en débattre.

En vous écoutant, Ole Piethein, je me rends compte qu'une autre amélioration possible pour le livre serait peut-être d'intégrer certaines des différentes façons dont le médaillon est utilisé, un peu comme une approche de type « modèles » et « anti-modèles ». Oui.

Parce que je suis sûr que nous pourrions probablement nous mettre d'accord sur certains des anti-modèles que nous observons. Oui. Mais quoi qu'il en soit, j'allais, à titre d'introduction, vraiment concentrer ma discussion autour de trois grands axes.

Et, surtout, il s'agit davantage de regarder vers l'avenir que de regarder vers le passé. N'est-ce pas ? Ainsi, plutôt que d'expliquer comment nous en sommes arrivés là, ce que le livre de Piethein fait très bien selon moi, commençons par réfléchir à la direction que nous allons prendre à partir de maintenant.

Oui. Étant donné que, vous savez, nous savons que les organisations sont confrontées, je pense, à des défis plus importants que jamais pour essayer de trouver comment faire évoluer leurs architectures. Et je pense qu'une partie de ces défis réside en fait, et c'est assez intéressant, dans le fait que le mot « données » a pris plus d'importance parce qu'il est associé à l'IA.

Je le constate même au sein de ma petite société de conseil en ingénierie : tout à coup, j'ai toute une équipe d'ingénieurs logiciels ou d'ingénieurs qui veulent créer des applications d'IA, puis qui se demandent : « Bon, comment vais-je obtenir les données nécessaires ? » Ils ont donc besoin d'une source. Permettez-moi de résumer mes trois arguments pour commencer.

Mon premier argument était donc une critique générale des architectes en couches, des architectures en couches en général, et n'avait pas vraiment de rapport avec Medallion. Et en fait, je suis d'accord avec vous, Ole, dans le sens où je pense que l'architecture en couches ne se démodera jamais. Mais je pense que ce que je veux dire, c'est que si l'on regarde l'espace applicatif, je me souviens, vous savez, je suis assez âgé pour me souvenir des architectures client-serveur, puis nous sommes passés à trois couches.

Vous savez, vous avez une interface utilisateur, une logique métier et une couche de stockage de données ou quelque chose comme ça. Et puis, vous savez, ça existe toujours. Vous savez, si je regarde la plupart des projets GitHub des gens, ou les projets Git que nous construisons comme Everest, il y aura probablement trois couches dans la structure des fichiers.

Oui. Et vous pouvez les voir, clairement, vous êtes interpellé. Mais il est intéressant de noter que, même si cela est déjà intégré, je pense qu'en tant que développeurs d'applications, nous sommes allés au-delà.

Nous avons dit, d'accord, oui, oui, écoutez, nous avons les trois couches. Hum, vous savez, elles ne nous intéressent pas vraiment, car ce qui nous intéresse, c'est peut-être l'architecture hexagonale, l'architecture propre, peut-être, vous savez, nous nous intéressons davantage à certaines, disons, les brevets d'applications d'entreprise de Martin Fowler, les brevets d'applications d'architecture d'entreprise, ou nous nous intéressons à un style d'architecture d'application bien conçu par AWS ou Azure. Et puis il y a un débat sur, vous savez, toutes ces nuances du modèle d'architecture, qui ensuite, afin de résoudre le problème, où les conversations ont en quelque sorte dépassé la couche.

N'est-ce pas ? Ce n'est pas une conversation où il faut choisir entre l'un ou l'autre. C'est un « oui et », n'est-ce pas ?

Et c'est, je pense, la conversation que nous devons avoir au sujet des données, ce que vous suggérez d'ailleurs dans votre livre, Piethein, où vous abordez le premier des trois exemples, qui sont tous excellents. Je pense que les études de cas méritent que tous ceux qui lisent le livre les parcourent, car ce sont des exemples concrets d'entreprises qui utilisent l'architecture en médaillon. Oui.

Mais je pense que derrière ces études de cas, il y a une sorte de discussion « oui et ». Oui, nous avons des médailles, mais, pardon, pas « mais », et nous voulons faire plus et offrir une plus grande valeur, et comment allons-nous faire cela ? Oui.

C'était donc en quelque sorte le numéro du marché. C'était vraiment sympa. Euh, j'ai beaucoup aimé les interviewer parce qu'ils utilisaient l'architecture mendélienne, mais ils ont aussi rapidement compris qu'il fallait la compléter avec beaucoup d'autres éléments. Il y a donc l'architecture orientée événements.

Nous aimerions intégrer des applications et développer des applications à forte intensité de données. Comment cela s'harmoniserait-il avec l'architecture Medallian ? Où fixer les limites entre une application et la distribution des données entre différentes équipes ?

Oui, j'ai eu une conversation très agréable avec eux. Oui, parfaite. Je veux dire, et c'est en fait l'application que j'utilise, c'est la conversation que j'ai avec les entreprises, à savoir : d'accord, vous avez peut-être installé Databricks ou Snowflake ou Azure, mais ensuite, comment allez-vous intégrer tout cela dans la couche applicative ?

C'est là que vous tirez profit de vos données, car vous avez pris des décisions et vous les mettez réellement en œuvre. Oui. Et oui, j'ai un modèle préféré, comme le modèle inversé.

Eh bien, oui, parfois, c'est l'inverse de l'ETL, mais c'est juste l'intégration, si vous voulez, de la prise de décision, appelons cela la partie décisionnelle et la partie opérationnelle. Oui. Oui.

Hum, c'était donc mon premier argument. Le deuxième argument était en fait celui de l'IA. Et cela nous ramène à ce dont nous parlions un peu au début.

Et cela m'amène à penser que, dans beaucoup d'entreprises que je vois aujourd'hui, les responsables des données sortent soudainement de l'ombre des services technologiques, car le PDG veut soudainement que quelque chose se passe dans le domaine de l'IA. Ils veulent, je ne sais pas, des agents IA ou quelque chose comme ça, n'est-ce pas ? Et la première question qui se pose, en fait, comme je l'ai déjà dit, c'est celle du développeur d'applications : où puis-je trouver les données ?

C'est ça ? Comment je fais, tu sais, tu m'as dit que je devais faire un rack. Comment je construis ce rack ?

N'est-ce pas ? D'où vient le contexte de l'organisation ? N'est-ce pas ?

Le contexte est stocké quelque part dans la couche de données. Donc, plutôt que d'avoir, disons, un monolithe sur le site, géré uniquement par un nombre restreint d'équipes chargées des données, on a l'impression qu'il est intégré dans l'architecture applicative de l'entreprise. Je pense donc que cela nous éloigne d'une structure purement médaillée et nous amène davantage à réfléchir à la manière dont les plans opérationnel et analytique d'une entreprise commencent à s'intégrer afin de servir l'IA.

Et puis, le troisième argument, c'est, vous savez, le bon vieux argument de l'alignement des produits data mesh . Et en fait, vous avez abordé ce sujet dans le livre quand j'ai finalement pris le temps de le lire. Donc, dans la quatrième partie du livre, vous avez en fait un chapitre, je crois, c'est le 12, 13 ou quelque chose comme ça ?

Hum, 12, non, je pense que c'est 13. Non, non, 13 correspond à IA générative, et peut-être que 11 correspond à la mise à l'échelle, où vous commencez à parler de data mesh. Et je pense que vous commencez en fait à mettre le domaine et la structure fédérée au premier plan et la structure en couches à l'arrière-plan, dans une certaine mesure, vous répondez en fait à ma question, car vous dites soudainement, vous savez, vous dites en quelque sorte, eh bien, peut-être que l'un des futurs que nous pouvons envisager est celui où le produit de données et une architecture de modélisation de données de type polyglotte commencent en quelque sorte à dominer au sein des organisations.

Et en fait, dans une certaine mesure, on constate pratiquement cela dans beaucoup de grandes organisations. Oui. Voilà donc mes trois arguments, qui sont principalement axés sur l'avenir. C'est un peu comme si nous voulions apprendre le médaillon parce que je pense que c'est une partie importante de notre histoire, mais je ne pense pas que nous voulions trop nous orienter vers le médaillon.

Absolument. Oui. En y réfléchissant, je pense que dans le dernier chapitre où j'ai présenté la partie sur l'IA, je pense que je le réécrirais probablement complètement différemment aujourd'hui, sachant que les choses évoluent à une vitesse folle.

Mais l'une des découvertes que j'ai faites, et nous en avons brièvement discuté auparavant, c'est que, dans l'organisation où je travaille actuellement, nous expérimentons déjà avec des agents. Nous avons un certain nombre d'agents en production, mais nous distinguons deux types d'agents, ceux que j'appelle les agents plus orientés données. Il s'agit donc de chatbots ordinaires ou d'agents qui, je ne sais pas, explorent une base de données ou effectuent des recherches ou examinent un profil historique, par exemple, ou utilisent Customer 360.

Là, je pense que l'architecture médallienne pourrait avoir du sens. Nous avons donc défini une orientation dans laquelle nous prévoyons des agents et autour du temps qui se situent à proximité de l'architecture mendélienne, mais nous voyons également des agents susceptibles de se situer à proximité des systèmes sources opérationnels, avec, au sein du domaine d'application. Et nous appelons ces agents des agents alignés sur les opérations.

Et celles-ci sont sensibles au contexte et fonctionnent avec une faible latence et des volumes élevés. Et là, je pense que nous avons besoin d'un autre type d'architecture. Vous avez donc probablement besoin de magasins de données opérationnelles ou d'applications gourmandes en données.

Donc, d'autres modèles et c'est un risque que je vois. Et, et c'est peut-être une bonne chose que vous ayez mentionné cela et nous devrions en conclure que les lecteurs ou les auditeurs pourraient interpréter cela. Eh bien, l'architecture en médaillon fait tout cela, et je pense que c'est un faux argument.

Il couvre un certain domaine, mais vous devez le compléter avec ce que vous avez déjà mentionné. Oui. D'accord.

Non, c'est tout à fait logique. Euh, je veux dire, l'une des choses que j'ai également réalisées en suivant votre raisonnement, c'est que, vous savez, la plupart des gens, la plupart des implémentations que j'ai vues, c'est qu'au sein de la couche argent, il y a une combinaison de contextes. Je veux dire, vous appelez peut-être cela un anti-modèle, mais j'ai vu plus souvent qu'à mon tour, vous savez, la combinaison de différents contextes.

Et vous appelleriez cela un anti-modèle ? Oui, je pense que c'est une occasion manquée si vous ne préservez pas le contexte authentique sous une forme historisée. De nombreux cas d'utilisation nécessitent que les données authentiques soient historisées dans une dimension qui évolue lentement car vous souhaitez entraîner pour l'apprentissage automatique opérationnel par exemple, ou pour des rapports opérationnels.

Si vous commencez trop rapidement à combiner et à intégrer, vous perdez cette opportunité, ce qui peut bien sûr être surmonté grâce à un stockage de données opérationnelles supplémentaire. Vous transférez les données vers une autre architecture. Mais je pense qu'il y a là une opportunité, et non, cela ne répondra certainement pas à tous ces besoins opérationnels, mais vous pourriez l'utiliser, euh, à cet égard, et je propose donc de reporter cette action de combinaison et d'intégration des systèmes sources croisés à la dernière couche.

Mais vous avez raison, je vois beaucoup d'organisations qui, déjà dans Silver, commencent à combiner , fusionner et intégrer. Vous pouvez aussi faire les deux, n'est-ce pas ? Vous pouvez donc construire ce type de base de données plus opérationnelle et les conserver dans votre Silver, et à côté de cela, vous avez cette intégration, l'intégration classique.

C'est très bien. Au moins, vous en tirez des leçons et vous répondez à ces préoccupations. C'est vrai.

Cela donne l'impression que c'est particulièrement, vous savez, je pense que vous avez mentionné précédemment ou vous avez mentionné coffre-fort de données, vous savez, on a l'impression que la couche argent est l'endroit où se trouve coffre-fort de données, ou du moins que la partie principale du coffre-fort de données peut-être le coffre-fort de l'entreprise. Diriez-vous que le coffre-fort de l'entreprise est alors la couche or ? Oui.

Il s'agit davantage de la couche d'or, et le coffre-fort ou la couche d'intégration est ce que l'on voit souvent dans l'argent. Euh, honnêtement, je ne suis pas vraiment fan du coffre-fort de données. Non pas à cause de la méthodologie ou des principes de conception.

Ils vous offrent certes une grande flexibilité, mais c'est l'architecture technologique sous-jacente qui ne facilite pas vraiment ce type de modélisation des données. Chez Lakehouse, nous fonctionnons donc avec une architecture distribuée stockée, et le calcul est découplé les uns des autres. Ainsi, si vous créez des milliers, voire des millions de petits parquet répartis sur tous ces serveurs dans le centre de données, vous allez certainement vous heurter à un problème de réseau.

Dans le cadre de mes fonctions précédentes, j'ai travaillé avec de nombreuses entreprises qui avaient initialement opté pour la conception basée sur les données, mais qui ont dû abandonner cette approche car elles n'ont pas réussi à surmonter les défis liés au réseau. Bien sûr. C'est intéressant.

Je veux dire, oui, tu veux intervenir avec certaines des questions que tu vois, Ole ? Euh, désolé. Je pense qu'il y a juste une ou deux secondes de retard.

Euh, désolé. Excusez-moi de vous avoir interrompu, Martin. Euh, continuez, je vous prie.

J'ai parcouru les questions posées dans le chat, et elles sont incroyables. Merci à tous pour ces discussions détaillées, ces conseils et ces points de vue. Il est évident que tout le monde ici n'est pas d'accord, ce qui me réjouit beaucoup.

Je pense que nous devrions rester en retrait, mais Martin, je ne voulais pas vous interrompre. Alors, voulez-vous poser d'autres questions ou devrions-nous passer aux questions ? Ça va ?

Non, non. Toi, tu prends la relève, Ole. D'accord.

D'accord. Donc, pour faire suite à cela, je pense avoir une question à poser en conclusion de votre conversation, Martin, avec Piethein. J'aimerais connaître les limites de l'architecture médaillon, c'est-à-dire ce qui se trouve en dehors de l'architecture médaillon. J'aimerais que cela soit défini plus clairement, mais nous terminerons peut-être par cette question.

Je pense que certains des participants à cette conférence téléphonique méritent de poser leurs questions. Ainsi, par exemple, Anyana, j'espère que je prononce correctement son nom, demande si nous avons vraiment besoin d'une zone d'atterrissage avant la couche bronze. Quels sont les scénarios possibles ?

Nous devrions peut-être réfléchir à la zone d'atterrissage avant même d'entrer dans le bronze. Oui. Fais ça.

Vous insistez sur ce point dans votre livre, vous en discutez. Oui, tout à fait. Il y a même de nombreuses pages où vous décrivez les nuances et les compromis à ce sujet.

Il s'agit d'abord de questions d'interprétation. Parfois, certaines personnes ont intégré la zone d'atterrissage dans l'architecture de leur médaillon. D'autres la dessinent et la positionnent clairement à l'extérieur.

Il faut donc d'abord se mettre d'accord sur la manière d'interpréter la livraison de l'architecture Medallion, mais dans certains cas, j'ai constaté que si vous ne disposez pas de modèles d'ingestion robustes ou sécurisés, il peut être judicieux de stocker temporairement ou de transférer ces données quelque part avant de les transférer vers la couche Bronze officielle. Encore une fois, cela dépend de la manière dont vous concevez la couche Bronze, mais c'est une motivation pour de nombreuses organisations que je vois. Avoir cette zone de transfert intermédiaire supplémentaire.

Ce n'est pas obligatoire. C'est plutôt facultatif. Il est donc bon de le mentionner.

Absolument. Oui. Continuons.

Il y a donc une question de John O'Gorman qui a été intégrée dans la séance de questions-réponses. Je me demande donc si nous devrions établir un ordre de priorité pour les questions qui seront abordées ou si vous préférez Non, non, je vous en prie. Prenons-les en fonction de leur intérêt.

Passons à la question de John O. C'est formidable qu'il soit là. Il demande si l'existence de l'architecture en médaillon repose sur l'utilisation continue des processus ETL.

En d'autres termes, une architecture alternative telle que l'architecture centrée sur les données combinée à l'utilisation de l'IA pour créer des applications va-t-elle jouer un rôle important ? Je dois avouer que je ne comprends pas très bien la question, mais ce n'est pas mon cas.

Tu veux prendre Piethein ? Je pense que la superposition, à mon avis, sera toujours là, et ce n'est pas nouveau. D'accord.

J'ai également expliqué au début du livre que nous venons des entrepôts de données d'entreprise classiques traditionnels. La stratification existe pour de bonnes raisons, et cela ne changera pas, cette partie ne disparaîtra pas. Vous pourriez bien sûr vous demander si cela pourrait se faire virtuellement, en temps réel.

Que signifiera à un moment donné l'IA pour la stratification ?

Peut-on ignorer une certaine partie ? Je ne sais pas. Mais les choses vont certainement changer.

C'est peut-être mon point de vue sur la réponse à cette question. Je veux dire, votre travail actuel avec les agents, avec les agents IA, répond, je pense, à la deuxième partie de la question de John. Oui.

Ce qui n'est pas vraiment le cas, car je considère les agents comme de nombreuses applications, vous savez, ce sont de nombreux morceaux de code qui peuvent extraire des données d'une architecture Medallion, mais ils peuvent très bien extraire des données directement d'une application ou d'un système source. Si vous avez besoin des données les plus précises, vous irez bien sûr directement au système source, n'est-ce pas ? Vous appellerez un point de terminaison API et ne consommerez pas les données de l'architecture médaillon.

Mais pour des cas d'utilisation de type asynchrone, vous pourriez très bien envisager d'utiliser ces données. Encore une fois, cela comporte de nombreuses nuances. Mais cette partie n'a pas vraiment été très bien décrite dans le livre.

J'ai dû me limiter et me conformer à un maximum de 300 pages. Oui. Oui.

300 En fait, eh bien, c'était l'autre conversation que nous avons eue juste avant que tout le monde ne se joigne à nous, à savoir que si vous vouliez vraiment aborder tous les aspects du médaillon, vous devriez écrire un livre de peut-être 600 pages. Oui. Oui.

Et ce n'est pas pratique pour O'Reilly de publier cela. Oui. Non, non.

Il y a tellement de choses qui pourraient aussi... Je suppose que c'est un défi d'écrire un livre sur la technologie qui ne devienne pas, qui ne soit pas, très vite obsolète. Et je suppose que plus c'est long, plus c'est difficile.

Mais il y a une question de Tia, j'espère que je prononce bien son nom. En tant que product owner de données product owner une organisation, nous avons dû partir du bronze pour construire un médaillon, car l'argent n'existait pas. Puis ils ont lancé l'argent et ont changé les noms des choses pour des noms plus adaptés aux entreprises.

Après deux ans passés à développer notre produit de données, nous avons fait une découverte majeure concernant la refonte du magasin de finalité vers Silver. Cela en valait-il la peine ? Tu as bien copié la question, Piethein ?

C'est encore une question difficile, mais oui, c'est vrai. Je suis désolé d'apprendre cela. Euh, oui, j'espère que les choses ont été plus faciles pour vous, mais, encore une fois, veuillez consulter les conseils et essayer de suivre autant que possible les meilleures pratiques et recommandations qui y sont mentionnées.

Mais, oui, utiliser l'or comme couche directe pour l'entrée directe de data products, personnellement, je ne suis pas fan, car vous êtes à nouveau étroitement lié aux structures du système source, l'application que vous trouverez à gauche comme entrée. Je suis donc beaucoup plus favorable au découplage. Encore une fois, avoir une couche supplémentaire, puis extraire les données de la couche argent.

Et en ce qui concerne data products, là encore, comme je l'ai écrit dans le livre, il existe différents types de data products. Je distingue donc data products alignés sur les opérations. Je pense que Silver est un candidat idéal pour cela.

Et vous avez davantage data products de data products de type analytique data products les données sont combinées et accessibles, organisées et susceptibles d'être les couches d'or candidates pour cela.

Oui, je trouve que la question de Tia est excellente. Je voudrais ajouter ici que si je travaillais avec Tia, j'essaierais de me concentrer sur la collaboration au sein de l'organisation plutôt que d'être strict sur les médailles d'or, d'argent et de bronze. Tout simplement parce que, vous savez, il semble que le défi consiste moins à respecter une architecture qu'à apporter de la valeur commerciale aux parties prenantes.

Peut-être que je lis entre les lignes, mais c'est l'impression que j'ai. Oui. Et c'est aussi ça le dilemme.

Je considère également cela comme un dilemme. J'ai commencé par dire dans le premier chapitre qu'il y a une pression constante de la part de l'entreprise pour que ces choses soient livrées rapidement. Et au contraire, nous aimerions concevoir correctement, documenter nos modèles et bien faire les choses, découpler, etc.

Et oui, ces deux éléments ne vont pas de pair. C'est pourquoi je vois souvent des équipes prendre des raccourcis pour faciliter leur activité malgré leurs exigences élevées. Pour faire suite à cela, Piethein, voici une question de Floris qui développe vraiment ce que vous venez de dire.

Comment réagiriez-vous face aux défis organisationnels, en particulier aux changements au niveau du conseil d'administration, liés à la mise en place d'une architecture de type « medallion » ? Comment vendriez-vous cette idée ? Je sais que cela est parfois considéré comme trop simpliste, comme du simple marketing.

Dans un sens, oui, mais ce que j'ai appris au fil du temps, c'est que ça marche vraiment. Donc à ce niveau, je pense qu'on pourrait parler de manière abstraite de différentes couches, de préoccupations, on pourrait développer des personas, argumenter en faveur de bons gestionnaires, par exemple, travailler davantage dans l'argent, peut-être dans l'or. Alors que les analystes commerciaux se pencheraient sur l'or, par exemple.

Il s'agit donc d'étiquettes adaptées aux entreprises, n'est-ce pas ? Bronze, argent, or. Cela remplace toutes les différentes conventions de dénomination que nous avions pour les couches classiques, comme l'environnement de staging, la zone d'atterrissage, la couche organisée, la couche d'intégration.

C'est plus favorable aux entreprises. C'est exactement l'autre question que je voulais poser, n'est-ce pas ? Parce qu'il y a ce que j'ai vu dans le texte et que je voulais demander.

Euh, où est-ce ?

Euh, euh, oui, cela vient de Heni. Je suis un fervent défenseur du modèle architectural, mais j'essaie de comprendre l'intérêt croissant pour l'architecture en médaillon et en quoi elle diffère des couches traditionnelles d'entrepôts de données, telles que la couche de préparation, la couche fondamentale et la modélisation des données. Pourriez-vous donc développer un peu ce que vous disiez déjà, Piethein ?

C'est une excellente question. Honnêtement, cela ne diffère en rien de ce que nous faisions auparavant avec le stockage des données d'entreprise ou de la manière dont nous gérions un lac de données. Il s'agit plutôt du fait que ces fournisseurs encouragent l'utilisation de ces étiquettes conviviales pour les entreprises.

Et ils travaillent avec les cadres et au niveau de la direction. Et vu de loin, cela semble résoudre tous les problèmes, car nous disposons désormais de labels favorables aux entreprises et ces préoccupations sont bien alignées. Mais dans la pratique, cela ne diffère en rien du travail acharné que vous avez dû fournir pour créer un entrepôt de données fantastique, par exemple.

Oui. Comme vous le souhaitez, Martin, allez-y. J'allais intervenir car j'ai vu cela se produire dans la pratique lorsqu'un certain fournisseur arrive et dit : « Non, vous savez quoi ?

Vos architectes de données font tout de travers. Ils ont ces couches intermédiaires et tout ça, ça devrait être médaillon, bronze, argent, or, non ? Laissez-nous envoyer nos consultants pour prendre le relais.

Et, vous savez, du moins dans l'exemple spécifique auquel je pense, j'ai trouvé cela très irrespectueux envers les membres de l'organisation qui étaient, j'étais d'ailleurs consultant externe, n'est-ce pas ? Donc, vous savez, en jugeant de manière générale, mais je n'étais pas très satisfait de ce fournisseur en particulier. Nous combinons également maintenant ce que je vois, par exemple, dans mon organisation, nous avons de nombreuses architectures Medallian différentes.

Nous utilisons donc les étiquettes adaptées au monde des affaires, de manière abstraite, pour décrire le type de préoccupations et ce qui se passe. Et puis, en dessous, il y a des couches plus physiques, qui ont des noms différents. Il y a une zone brute, une zone organisée, une zone enrichie, une zone intégrée, etc.

Et nous laissons aux ingénieurs techniques le soin de décrire ces préoccupations à un niveau plus physique. Oui. Je vois que nous approchons de la fin de l'heure, encore une fois, le temps a passé plus vite que ce à quoi je m'attendais.

Je veux dire, il s'agit évidemment d'une discussion technique, et je pensais que nous aurions le temps d'aborder d'autres sujets que ceux que nous avons déjà abordés. Mais le temps est écoulé. Je veux dire, avant de clore la séance, Ole, j'aimerais aborder une question qui n'est pas vraiment une question sur les médailles, mais qui vient de Juan Cecada, qui oppose l'urgent à l'important, le court terme au long terme.

C'est le grand dilemme : comment mettre en place les bonnes structures incitatives ? Comment amener les gens à manger leurs légumes et à aller à la salle de sport ? Et j'allais suggérer une réponse à cette question.

A, vous savez, une sorte d'approche par petites habitudes. Oui. Et l'idée que, vous savez, on ne peut pas perdre 20 kilos du jour au lendemain.

Vous pouvez perdre 20 kilos si chaque jour vous augmentez ou, vous savez, pratiquez de bonnes habitudes, de bonnes habitudes alimentaires, de bonnes habitudes d'exercice, etc., et presque chaque jour, vous recommencez. Et donc, vous savez, je pense que c'est la réponse à beaucoup de questions, des choses comme une réponse générique pour dire d'accord, vous ne résolvez pas votre problème de médaillon en jetant tout simplement tout. Et en recommençant à zéro et en disant, maintenant nous allons suivre un nouveau régime de remise en forme.

N'est-ce pas ? Vous, résolvez les problèmes par de petites habitudes quotidiennes. Essayez de mieux expliquer et d'améliorer votre discipline dans la façon dont vous faites les choses.

Mieux réfléchir à la manière dont cela va s'adapter à l'avenir.

Au moins, c'était ce que j'allais dire pour essayer de clore ce débat. Merci beaucoup. D'accord.

Merci à tous. Il y a un peu de retard. Je suis désolé de ne pas vous couper la parole, Piethein, et ce n'est qu'une partie de la journée.

Merci, Juan, pour ce dernier commentaire. Excellent. Et merci, Martin, d'avoir attendu pour nous rejoindre si tard dans la nuit chez vous.

C'est très aimable de votre part. Merci beaucoup pour vos questions détaillées. Et bien sûr, Piethein, merci beaucoup d'avoir pris le temps d'être avec nous aujourd'hui et d'avoir répondu à nos questions.

J'espère que ça a suffisamment chauffé. Sinon, les gens sont invités à continuer en ligne. Euh, Jano, veuillez poser votre question.

C'est un plaisir de vous retrouver. Et à tous ceux qui participent au chat, n'hésitez pas à nous contacter. Nous sommes présents sur LinkedIn, Medium, Substack, Piethein et moi-même, Martin bien sûr.

Alors Piethein, merci beaucoup. Merci Ole d'avoir organisé ça, merci beaucoup. De rien.

Merci. Merci à vous deux et à tous les participants à cette conférence téléphonique. Merci.

Santé. Merci beaucoup. Santé.

Au revoir. Courage, vas-y.