Bruno:
Dans les années 80, un petit plombier moustachu nous a enseigné une vérité fondamentale de l'informatique. Si tu sautes dans le bon tuyau, tu ressors exactement là où tu voulais. Sauf que nos papelines de données, eux, ressemblaient longtemps au niveau aquatique de Mario, c'est-à-dire qu'on nage à l'aveugle, un truc nous bouffe et personne ne sait vraiment d'où vient la fuite. Mais alors, comment faisait-on avant quand un seul chiffre faux suffisait à faire Game Over sur toute la boîte ? Comment est-ce qu'un bon vieux Select peut-il encore universellement être présent aujourd'hui ? Et surtout, maintenant qu'on réécrit tout en Rust, est-ce que nos pipelines vont finir par rouiller ? Pour répondre à ces questions de plomberie, je ne reçois pas Mario, mais il s'y connaît en tuyau. Jérémy, bonjour.
Jeremy:
Bonjour.
Bruno:
Alors Jérémy, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Jeremy:
Oui, avec plaisir. Alors, c'est Jérémy, je suis Product Manager, Principal Product Manager, chez DBT Labs, qui était récemment fusionné avec FiveTrend aussi mais on n'a pas déjà un nom pour la nouvelle boîte on va le trouver pendant le prochain mois j'espère, mais je suis chez DBT depuis longtemps, depuis un peu plus de 8 ans, 8 ans et demi avant ça j'ai étudié quelque chose pas du tout tech mais assez technique, c'était le lettre classique, le grec ancien et le latin qui me fournit peut-être avec la capacité pour créer et aussi lire beaucoup de SQL qui est plus facile que ça parce que c'est plutôt anglais, qui est ma langue maternelle peut-être évidemment mais je parle français avec un petit accent marseillais parce que je viens de Marseille maintenant je l'habite mais plutôt avec un accent très fort anglophone americano.
Bruno:
Ça va encore, Sur ce podcast, forcément, on a été amené à parler quelques fois de cette notion de pipeline. Alors forcément, on s'adresse plutôt à être développeur et développeuse. Donc ces notions de pipeline, en général, on les voit plutôt sur des populations qui sont plutôt orientées data. Mais donc forcément, nous, en tant que dev, ce sont les sujets qui nous concernent aussi. De ma compréhension, aujourd'hui, en gros, un pipeline de données, c'est une manière de transformer de l'information, enfin de la donnée d'un point A à un point B, donc une notion de conversion, de mise à jour de ce genre de choses, est-ce que c'est un peu plus enfin j'imagine qu'il y a peut-être un peu plus de finesse que ça ou...
Jeremy:
Oui oui oui je peux définitivement ça c'est une définition qui marche assez bien pour le ETL qui était la manière de le faire un peu, maintenant on peut dire ancienne c'était plutôt le cas dans les années peut-être 2000-2010 où il y avait besoin de, extracté ou prendre toutes les données du système de source, et mettre dans une base de données où les équipes de données, les data analystes, mais aussi peut-être les équipes de métier finance, marketing, comme ça, peuvent lancer une, enquête vers cette base de données et fournir leur reportage ou leurs questions exploratoires, on peut dire ça. Mais les gens qui ont fait ça, qui étaient le métier de data engineer, on fait en même temps à la fois le mouvement de données, la circulation du système de source vers la base de données analytique et aussi les définitions, transformations, nettoyage, toutes ces logiques qu'on appelle les logiques business logic. Les règles de le business qui sont propres, sont spécifiques, à cette boîte et pas que le problème problématique général de comment prendre les données de Salesforce et mettre dans une base de données Postgres. Parce que ça c'est un problème technique aussi mais c'est pas un problème différencié pour chaque boîte c'est un problème général générique. Mais on peut dire qu'à la fois à l'époque c'était le travail de faire à la fois, l'extraction le mettre en place, la mise en place et aussi la transformation des données, tout ensemble. Et probablement dans un job Scala ou Spark ou quelque chose d'assez technique, assez inaccessible pour les gens downstream qui font leur enquête ou qui font les définitions. Et ça marche avec les technologies qui étaient disponibles à l'époque, mais il y a un problème peut-être évident, sinon je vais expliquer, qui est, le personne ou le persona qui fait toutes les définitions de cette transformation, et la personne qui connaît très très bien les besoins du business et même les règles du business. C'est quoi un client pour nous comment est-ce qu'un utilisateur devient un client les différences entre peut-être annulation ou. Attrition on peut dire tout ça c'était pas très accessible au dead engineer qui, fait tout le travail donc s'il y avait un problème avec les définitions et oui c'est tout le genre parce que le moment où tu donnes des données à quelqu'un, il y aura deux, trois, cinq questions. Est-ce qu'on peut... C'est quelque chose en plus ou est-ce qu'on peut le regarder mais maintenant, avec un filtre, avec une vue différente, ça prend beaucoup, beaucoup de temps d'avoir cette... Je ne sais pas comment dire exactement en français mais en anglais on dit « throwing something over the fence ». C'est toujours lancer les questions mais Mais on ne sait pas où, on ne sait pas à qui, on n'est pas une relation très proche et personnelle entre le data ingénieur et le genre de métier. Donc, c'était avec le changement de ce système ETL vers un système ELT, c'est-à-dire qu'il y a un système pour l'extraction et loading, circulation, de ces données, et un système séparé pour définir les transformations, et la possibilité de les définir en SQL, qui est une langue beaucoup plus accessible. C'est pas dire moins technique, mais plus lisable pour les gens des métiers. Peut-être s'ils sont data analystes, ils ont déjà une connaissance pas mal, spécialement avec écrire select en enquête pour savoir quelque chose. Qui s'adéviant possibles à séparer ces deux problèmes. Le problème de comment accéder les données dans les systèmes de source et le problème de comment donner le pouvoir aux gens qui, ont le plus de contexte, le meilleur contexte, à définir ou transformer ce contexte dans une langue technique spécifique pour préciser, toutes les règles du business dans une manière déterministique.
Bruno:
Ok. Alors, est-ce que du coup, cette évolution vers une logique de pipeline, est-ce qu'elle est du coup simplement due à une... À une évolution, on va dire, du métier et donc du besoin dans la manière dont les données sont manipulées, ou est-ce que cette évolution elle est aussi due à des évolutions technologiques parce que les bases données et surtout la manière dont on stocke les données, le format des données, il y a beaucoup de choses qui ont drastiquement évolué. Est-ce que du coup c'est aussi une mutation technique qui a nécessité tout ça ? Et alors je te préviens juste, pendant que tu fais ta réponse je vais devoir aller manipuler ta caméra parce qu'il y a encore des petits problèmes d'image donc je te laisse faire ta réponse, et donc les gens qui nous voient sur Youtube je suis désolé il y a eu quelques bugs de caméras mais je vais les corriger pendant que Jérémy nous répond.
Jeremy:
Ok ça va donc je peux commencer par dire au début, on est dans 2015-2016 au début c'était une innovation technique ou technologique c'était. Le lancement de bases de données analytique. Et quand j'ai dit analytique, la signification est plutôt avec stockage de données à la colonne. Qui rendent possible demander des questions analytiques, questions comme combien de clients ont fait, quelque chose comme ça, qui ont commandé cet article le mois dernier, maintenant, l'an dernier, l'an dernier, mais que en France, métropolitaine et pas les autres régions, par exemple. Toutes ces enquêtes sont très chères et très consomment beaucoup, beaucoup, de calcul d'énergie pour une base de données transactionnelle, comme Postgres mais c'est beaucoup plus facile pour une base de données à la colonne comme Redshift et après Redshift BigQuery, Snowflake, Spark ou Databricks, et ces autres systèmes, offrent aussi la possibilité d'avoir un système distribué avec des stockages et calculs qui sont séparés et qui peuvent être, à l'échelle séparée.
Bruno:
Alors parce que du coup tu t'évoques un point et en fait je réalise que ça fait longtemps qu'on ne l'a pas évoqué sur le podcast, et donc peut-être qu'il y a des développeurs ou développeuses qui nous ont rejoint récemment et qui n'ont pas forcément écouté ces anciens épisodes parce que donc effectivement tu parles de stockage en colonne parce qu'effectivement dans les moteurs de base de données on a les stockages en rang classique, c'est ce qu'on a dans les bases de données relationnelles, type Postgre, MySQL et autres et effectivement parfois certains moteurs de base décide de stocker l'information, En gros, on a un fichier qui contient toutes les valeurs d'une colonne, plutôt que d'avoir... C'est ça à peu près le...
Jeremy:
Oui, et toutes les valeurs d'une colonne sont localisées ensemble. Et le fichier contient des méthodonnées au début et aussi parfois à la fin, pour décrire cette colonne est localisée ici. Et ce fichier contient une valeur de cette colonne entre min et max, ou entre quelques dates et quelques autres dates et comme ça c'est possible quand on fait une requête comme, combien de clients ont fait quelque chose le moins dernier le moteur peut comprendre, on veut juste le moins dernier donc on peut, trouver des fichiers qui correspondent au mois dernier et jeter tout le reste. Pas jeter dans la bubelle, mais pour ces moments, oui. Et après, si on veut savoir que produits et. Compte, nombre de gens qui ont fait quelque chose comme ça, on peut regarder que les colonnes qui correspondent au produit et pas toutes les autres colonnes. Et comme ça, le parti le plus cher de faire des ranquets comme ça, C'est la découvrabilité, trouver et après lire les données qui correspondent aux repenses. Donc si on peut aider cette base de données à lire que les données qui sont, à propos ou qui correspondent à la question, on peut avoir une réponse beaucoup plus rapide et moins chère. Donc ça c'était l'ennovation mais l'autre ennovation c'était que toute cette base de données analytique. Ont adopté SQL comme leur langue de manipulation. Alors on était avant dans une période avec Mango et les autres bases de données modernes qui étaient côté NoSQL, anti-SQL un peu, mais avec Redshift, Snowflake, spécialement Snowflake, BigQuery avec le temps parce qu'ils ont adopté SQL plus en plus, c'était pas vraiment SQL au début. On est arrivé dans une période où SQL est roi, pas que pour les développeurs qui écoutent pas que pour les manipulations très classiques en post-cré mais aussi pour faire des transformations et faire leur enquête très très grande et très puissante, dans ces bases de données analytiques, parce que SQL est accessible aux audiences et c'est.
Bruno:
C'est un langage déclaratif, donc il est facilement compréhensible, même potentiellement par des gens qui ne sont pas forcément hyper formés au sujet. Il est assez lisible.
Jeremy:
Oui c'est idiosyncratique aussi mais plutôt déclaratif, 80% le même dans toutes les bases de données qui, l'adoptent mais peut-être on peut parler sur ça après les 20% des différences c'est très intéressant parce qu'il n'y a pas une SQL qui existe dans le sens qu'il y a en Python en Rust il n'y a pas en, SQL c'est un langage, différenciés ou un peu l'idée d'une abstraction qui est différente dans ces implémentations variées. Mais à cause de tout ça, DBT, qui était notre util à l'époque, peut dire que toutes les transformations de données doivent être après les mettre en place par les outils en gestion et en interaction, et toutes les transformations de données doivent être écrites en SQL. Et c'était possible, parce que ces bases de données analytiques existaient et amélioraient beaucoup avec chacun. Et c'était sur cette vague crescente, peut-être on peut dire, que DBT était le surfeur glissant, sur leur tendance.
Bruno:
Alors de ce que je comprends, ce que tu dis c'est qu'en fait il y a des certes il y a des technos qui ont évolué, il y a des besoins qui ont évolué, qui du coup ont nécessité en fait d'adapter le simple fait de juste transformer la data d'un point A à un point B, de par aussi une solution de complexité, mais en quoi est-ce que le fait d'avoir, un pipeline permet de simplifier parce qu'au final t'as quand même une complexité, la complexité elle a pas disparu en tant que telle, c'est à dire que t'as toujours ces sujets là à traiter.
Jeremy:
Dans un sens, DBT a fait le travail ou la mission de faire la transformation de données. À la fois, c'est devenu moins technique et plus technique. Parce que c'est devenu moins technique dans le sens que ça peut être écrit en SQL et accessible aux gens qui ne doivent pas être experts en Spark ou en Scala. Mais c'est vrai que notre mission à l'époque et toujours aujourd'hui, c'est d'apprendre aux gens qui peuvent écrire un petit peu de SQL dans un query editor très simple. Ou peut-être ils ont l'habitude de sauvegarder ma requête préférée .SQL dans le desktop et ouvrir tout le genre pour relancer. Ça c'est ma requête très importante à moi personnellement, qui appartient à moi. Notre mission c'était d'apprendre à 16 utilisateurs ou 16 data analysts, tu dois apprendre le principe fondamental du logiciel et de software engineering. C'est-à-dire, tu vas apprendre Git, tu vas apprendre les concepts de testing et de documentation. Et tout ton travail va être dans une repositoire. Dans un contrôle de version. Et ça, c'était... Ah oui, c'était chaud, c'était intéressant. Parce qu'on avait des équipes qui, étaient très très chaudes de le faire et aussi des équipes qui ont dit non, ce n'est pas notre travail, on n'est pas de software engineering. Mais oui, le concept d'avoir une pipeline qui est reproduisable, reproductible, qui est dans une version control, qui a des testings, qui a beaucoup de documentation, ça c'était évident dans le sens qu'on a, on a pris du travail qui était anciennement par le Data Engineer dans Spark dans Scala, c'était la même chose maintenant en SQL et utilisant le framework tbt, mais on a aussi pris le travail qui était avant dans les desktops dans l'Excel, Google Sheets, dans les outils BI, et on a formalisé, et on a dit, non ça c'est vraiment le travail de software engineering et le travail de créer et maintenir une pipeline, Avec un environnement de développement, avec un framework inutile de CI-CD, avec le besoin de faire le debugging quand il y a quelque chose qui semble mauvais, comme tu as dit, le plombage pour trouver la fuite de données. Et tout ce travail, je crois à professionnaliser et aussi faire une promotion, de le travail qui était avant pas assez bien, respecté ou assez bien vu spécialement par les ingénieurs par les data engineers, qui a dit, oh non, mais ça c'est juste écrire des enquêtes ad hoc et rien en plus, le data analyst qui parfois ont, pris le titre d'analytics engineer peuvent dire non, on a créé une vraie pipeline une vraie data pipeline utilisant DBT.
Bruno:
Ce que je trouve intéressant c'est du coup une des évolutions que tu évoques c'est la mise en place du testing, du versionning tous ces outils qui on utilisait déjà depuis un petit moment, côté software engineering et c'est marrant parce qu'il y a quand même eu une tendance on a vu ça, on a vu aussi ça côté infra, avec l'infra ASCODE, avec le DevOps effectivement, enfin il y a cette manière de travailler semble s'être généralisée à beaucoup d'aspects de la tech, Et du coup, en tentant d'en le dire, je ne sais pas pourquoi, je me suis demandé, mais est-ce que c'est une bonne chose ? J'ai pas envie de débattre sur est-ce que le versionning est utile ou pas, ou est-ce que le testing est utile ou pas, parce qu'il n'y a pas de débat là-dessus. Mais du coup, je me dis, est-ce que c'est que nos méthodes étaient intrinsèquement bonnes, et du coup, elles se généralisent à toute la tech ? Et du coup, est-ce que ça pourrait aller plus loin que la tech ? Et peut-être qu'en 2050, on parlera de la finance, qui utilise aussi une version de Git un peu différente pour soumettre les comptes ou je ne sais pas quoi. Ou est-ce qu'on est en train de généraliser des méthodes qui sont certes efficaces mais peut-être pas les meilleures. Pourquoi est-ce que ces méthodes là et en plus ce qui est marrant c'est que le testing, j'en discutais la semaine dernière avec un autre invité les tests, les développeurs et les développeuses n'ont jamais aimé faire les tests et du coup ne font jamais de test alors que dès qu'il n'y a pas de test on gueule, en disant c'est nul il n'y a pas de test mais on ne veut jamais les faire et que maintenant qu'on a des IA, qui sont capables de générer du code à la volée, malgré tout, on ne fait toujours pas de tests. Parce qu'en fait, on demande... Ça coûte trop cher en token. Il y a des tas d'excuses qu'on se prend. Mais on ne demande toujours pas à l'IA de générer des tests. Est-ce que du coup, dans le monde de la data, vous, vous générez quand même un peu mieux vos tests ou est-ce que vous êtes comme nous à ne pas vouloir en faire ?
Jeremy:
Beaucoup de questions intéressantes. Je peux commencer par dire quand on a commencé, on n'a pas trop demandé est-ce que les dernières décennies de software engineering sont bons ou mal c'est plutôt pour apprécier qu'il y avait beaucoup de gens et beaucoup de travail, qui nous amènent à ce point d'avoir Git d'avoir le concept de testing le concept de documentation, Et c'était très facile pour nous pour dire qu'on est inspiré par les, principes de software engineering pour décrire, pour avoir une vision pour le futur et l'avenir de comment faire l'analytique, comment faire le travail de données. En même temps, il y a une différence très, très importante entre le travail de logiciel traditionnel et le travail de données, que les données sont beaucoup plus lures. Il y a beaucoup plus de gravité avec les données parce que ça coûte très cher, de faire de circulation, de faire de mouvements de données. Ça prend du temps, ça prend beaucoup, beaucoup de calculs. C'est beaucoup plus facile d'avoir... J'ai une app, je veux avoir une autre version de cette app. Je l'ai parce que j'ai fait un petit changement d'une ligne de code et si soit un site qui est publié par Vercel ou une app qui, est gérée par Superbase ou par notre propre utile ça ne coûte pas beaucoup d'avoir plusieurs versions, la chose la plus chère peut-être c'est savoir c'est quoi le changement qu'on doit faire et ça c'est les dessins les conversations avec les clients mais, les questions d'architecture comment on peut créer quelque chose qui est pliable pour le changement qu'on ne sait pas encore. Qu'est-ce qu'on va faire mais avec les données c'est un peu plus clair que pour avoir beaucoup de versions ça coûte, ça coûte de temps ça coûte, d'argent d'avoir les calculs Donc, la problématique pour nous avec DBT, c'est de prendre les principes de logiciel, comme les environnements dev déployés. Et traduire pour une application donnée. Et dans DBT, il y a l'idée de environnement dev et environnement deploy, bien sûr, mais c'est aussi très très important de trouver des manières comment est-ce qu'on peut créer des environnements dev le plus efficaces et le plus vite possible. Si je fais changement dans cette enquête, cette modèle ici, on n'a besoin que de recréer cette modèle et pas toute l'application. Pas toutes les dagues c'est plutôt un. Build system un système de construction ou de bâtir dans ce sens, mais ça c'est ma première pensée c'est aussi vrai dans le testing parce que, oui on est inspiré par le testing qui existe pour le logiciel on a le testing end to end mais on a, aussi le testing unitaire c'est à dire les inputs pour ces modèles sont les requêtes ou les sources de données ou les modèles qui sont juste au-dessous, juste les parents on peut dire, ou les racines de ce modèle si on peut faire les mock data pour ces racines et on peut lancer la requête pour ces modèles est-ce que, c'est logique créer la bonne réponse ou pas ok, testing unitaires, très bien, mais le je crois que le... Les enjeux d'être incorrect ou d'être injuste dans les données sont beaucoup plus élevés que dans les logiciels. Parce qu'on écrit des tests dans les logiciels pour savoir si je change ces components. Ça va détruire tous les autres components ou pas plus vite que d'essayer de, faire une run totale ou de créer toute l'application. Et arriver au point d'erreur runtime. Ça aide la productivité, ça aide l'efficacité pour trouver tous les cas de coin, tous les edge cases. Mais enfin, si l'appli. Ça marche, ça marche. On va trouver si ça marche à runtime. Mais avec les données, tous les modèles, toutes les enquêtes, toutes les DAG, on dit, le graphe écyclique et directé, comment on dit ça ? Dirigé. Dirigé, oui, dans un sens. Tout ça peut fonctionner. Et fournit les données dans quelques dashboards ou quelques reports, et après, quelqu'un le voit et dit « ça c'est ridicule, notre revenu n'est pas doublé dans les derniers mois ». Mais on n'a pas su pendant juste le processus de lancer l'enquête dans les bases de données. Et ça détruit la réputation et la confiance qui existent dans pas que le système mais aussi l'équipe de données c'est vraiment une question de fiabilité pour eux, donc je pense que le testing est un peu plus courant dans les données et dans le DBT peut-être dans les autres applis spécialement les applis VibeCoded récemment, parce que c'est vraiment une question de réputation et de fiabilité pour les gens qui présentent les chiffres avec leur nom signé en bas.
Bruno:
Alors justement cette notion de fiabilité, parce qu'il y a un autre sujet aussi, c'est que le volume des données devient de plus en plus important. La quantité des différents départements, des différentes personnes qui manipulent ces données est aussi de plus en plus importante. Comme tu le dis, il y a un sujet de fiabilité, parce que effectivement donner de la mauvaise information à une personne ça peut être extrêmement critique mais dans cette notion de fiabilité, tu as aussi une notion de performance dans des contextes avec des données qui explosent complètement comment tu fais pour maintenir cette, est-ce que tu es obligé de choisir l'un versus l'autre.
Jeremy:
Non c'est une bonne question il y a quelques types de quantités qui sont différents selon moi il, y a la question des quantités de données on a des clients qui ont beaucoup de données qui viennent de sensors qui viennent de clickstream les sources de données qui sont volumineuses, Mais en même temps, la plupart des requêtes analytiques sont moins de 1 Mb, 5 Mb. Même qu'il y a des us-case très très intensifs dans le sens de quantité de données, les questions sur combien de clients on a, ce n'est pas assez intensif. Mais il y a les quantités de données, il y a aussi les quantités de types de questions qu'on demande et la quantité de gens. Qui participent dans la définition des modèles, la définition des règles de business. Donc pour nous, il y a plusieurs manières d'attraper ces questions. Pour les problèmes techniques de comment on peut, gérer une grande quantité de données, mais vraiment c'est une question de comment on peut exploiter les, capacités incroyables de la data plateforme moderne, des Snowflake ou BigQuery ou Databricks ou les autres, Athena, parce qu'ils ont des capacités incroyables, mais un peu difficiles, à trouver ou comprendre, spécialement pour les gens un peu moins techniques. C'est pour ça que DBT offre des abstractions, comme les modèles incrementaux, comme stratégie différente pour faire les updates très précis mais ok, Le problème de collaboration, c'est plutôt, spécialement maintenant, la question du contexte et comment on peut partager le contexte sur quels sont les bons modèles, quels sont bien gérés, qui est le propriétaire de ces modèles, de ces définitions. Les dernières fois qui étaient mises à jour le. Fraîcheur de données et aussi évidemment le statut de test, qui sont exécutés sur ces modèles tout ça, tout ce contexte est très utile pour les humains mais quand même plus utile pour les LLM qui essayent de trouver, de traduire une question en langage naturel vers une enquête SQL vers les bases de données, peut-être juste données brutes, sans nettoyage sans gouvernance, sans rien dessus, alors, on veut pas ça, on veut que l'LLM va utiliser le même modèle que l'équipe de données ou l'équipe de métier on investit ici pas mal de temps pas mal de coûts de calcul et temps de leur travail, pour dire oui c'est le bon source de formation sur nos clients nos ordres, nos systèmes de comptabilité comme ça. Mais avec les LLM c'est devenu plus et plus accessible à écrire le pipeline comme ça et aussi, demander des questions comme ça c'est le rêve éternel de self-serve analytics, et t'as dit par exemple est-ce que l'équipe de finance va, travailler dans cette manière de pipeline et de software engineering dans l'avenir, c'est vrai que l'équipe de finance chez DBT a travaillé comme ça depuis 2, 3, 5 ans presque, ils ont utilisé DBT pour faire les finances trimestrielles des DBT, je pense qu'il y avait une autre partie des questions que j'ai...
Bruno:
Non parce qu'en fait on parlait effectivement de cette conciliation entre la notion de fiabilité et de performance donc si je comprends bien, l'aspect fiabilité vous y répondez au travers du versionning, du test control de toute cette solution qui permet de garantir que ton pipeline, en fait, il est testé, il est fiable et que si jamais il y a un problème, on peut revenir en arrière. La performance, de ce que je comprends, t'évoques plutôt, il faut se baser sur des outils comme Snowflake et autres qui apportent une performance et des volumétries, qui peuvent tenir extrêmement longtemps. Mais t'as évoqué un autre terme aussi dans ta réponse sur laquelle j'aimerais revenir. T'as évoqué la notion de gouvernance. C'est vrai que quand on parle de data, la notion de gouvernance elle est quand même primordiale, encore plus depuis, quelques années où il y a des vraies notions aussi de souveraineté, on veut être sûr de, qu'est-ce qu'on a comme informations est-ce qu'elles sont disponibles comment y accès tout ça, cette gouvernance aujourd'hui dans DBT on a des outils, pour la traiter ou ça aussi c'est plutôt un truc qu'ils vont faire ailleurs.
Jeremy:
Il y a deux types de gouvernance il y a les types formels on peut dire c'est, Qui doit avoir le droit de voir quel type de données ? Données personnelles, sur les gens, sur les employés par exemple ?
Bruno:
Donc toute la compliance avec RGPD en fait, c'est simple.
Jeremy:
Exactement, c'est ça. Pour ça, c'est un peu comme avec les conversations sur les performances à l'échelle, on utilisait plutôt, la capacité qui existe déjà dans les bases de données, dans les data plateformes, qui est très très avancé et dans les catalogues plutôt par exemple les catalogues Iceberg mais les catalogues, Unity pour Laris Horizon c'est un autre sujet, qui avance très vite mais c'est assez nouvel aussi, l'idée d'avoir une couche de contrôle d'accès universel pour toutes les données soit tu vas, n'importe quel calcul ou quel outil de enquête tu veux utiliser. Mais, ok, ça c'est la gouvernance formelle qui est plutôt concernée avec la sécurité et avec prévenir accès par quelqu'un qui ne doit pas avoir accès. Il y a aussi la gouvernance dans le sens que fiabilité. Gouvernance c'est-à-dire, est-ce que ça c'est la bonne source d'information pour ces sujets. Et ça devient très important avec, comme j'ai dit, le self-serve analytique fourni par les LLM. Mais le balance à trouver, c'est important aussi parce qu'il ne faut pas, fermer toutes les portes et dire que l'équipe de données centrale a le droit de lancer leur enquête pour savoir combien de clients ont fait quelque chose le mois dernier. Moi, je ne suis pas parti de l'équipe de données centrale, je suis product manager. Il y a beaucoup de choses que je dois savoir sur le produit, peut-être des choses que je viens de penser dans les dernières cinq minutes. Je dois avoir le droit de lancer des enquêtes pour savoir, combien de gens ont cliqué sur ces boutons ou qui utilisaient cette feature en combinant avec cette autre feature c'est quoi l'interaction avec les versions de notre util qu'ils utilisent etc, donc il y a une distinction importante entre le reportage, le donné qui est bien gouverné présenté et signé par l'équipe de données centrales donc ça c'est notre revenu. Il faut avoir un seul chiffre, ne pas avoir trois différentes versions de revenus de la boîte entière. Et aussi, il y a les questions, les enquêtes exploratoires. Et, le but, c'est de fournir le genre de métier, comme l'équipe de produits par exemple, avec la capacité de faire assez d'exploration pour savoir directionnellement, ce qui s'est passé dans notre coin de business récemment. Et pour formuler des questions bien informées pour après intégrer dans le reportage central. DBT comme inutile qui est... À la fois pour le développement et pour les itérations très vite, avec les définitions et leurs enquêtes bien. Intégrées avec les autres, et aussi pour le déploiement des choses bien gouvernées dans une version control avec beaucoup de testing, beaucoup de documentation. Il y a un voyage, je ne sais pas dire, des maturités, qu'une question peut commencer comme juste une question dans ma tête, deviant, requête, modèle DBT, select quelque chose qui est bâti au-dessus des autres modèles qui existent déjà. Et après, j'ouvre un pull request pour l'équipe de données à réviser. Après, on l'intègre dans le reportage central. Après, ça devient quelque chose d'ancré et bien établi comme vérité pour toute l'entreprise.
Bruno:
Comme je te disais sur le compilé, je pense que ça peut être intéressant de l'évoquer ici j'ai fait quelques équipes data j'ai l'impression que partout dans toutes les équipes data les gens, ne jurent que par DBT j'ai l'impression que c'est une espèce de techno qui se répand comme une traînée de poudre qui est un peu un truc un truc un truc universel, comment est-ce que toi t'expliques, est-ce que c'est moi qui me trompe et en fait vous avez que quelques clients et j'ai eu la chance d'arriver au bon endroit. Mais comment est-ce que tu expliques qu'il y ait autant de personnes côté data, qui apprécient autant cet outil ?
Jeremy:
C'est une bonne question. Ça me rappelle aussi la question avant sur est-ce qu'ils ont bien fait ou pas pour utiliser le standard ou les principes qui viennent du logiciel, qui viennent du stuff for engineering ? C'est-à-dire, est-ce que Git, c'est la meilleure version de version control, imaginable ou faisable dans le monde, qui est gouverné par ces lois de physique ? Ah non, probablement pas. Probablement, on peut imaginer quelque chose encore mieux et je pense qu'il y avait pas mal de gens qui ont essayé. Mais pas avec grande réussite. Parce que même si Git n'est pas parfait, c'est standard. Et c'est plus utile pour une équipe de software, d'engineering en général, d'utiliser la chose standard que la chose parfaite. C'est un peu comme ça avec TBT. On avait notre détracteur pendant le temps qui nous a dit mais DBT n'est pas très très fort avec le modeling incremental où il n'y a pas le testing unitaire avant de, l'ajouter grâce à ce feedback, grâce à ce retort. Ou DBT est trop lente parce que c'est écrit en pisson et. DBT Core version 1, le premier commit c'était 10 ans avant nos jours maintenant, donc c'est un peu legacy non ? Ok, tout ça c'est vrai il y a des évidences pour tout et quand même les équipes adoptent DBT parce que c'est devenu le standard, le référence pour comment faire les transformations des données et c'est devenu le standard grâce à, tous les changements que j'ai décrits, les changements technologiques les changements socio-technologiques, les équipes de données. Qui sont devenues plus techniques eux-mêmes, mais aussi le fait que DBT Core est open source, et open source depuis le premier jour, avec une licence très très permissible, qui dit « tu peux, comme data analyst, analytics engineer, data engineer », N'importe ton rôle, tu peux utiliser des bêtises toi-même sur ton ordi sans nous parler, sans nous demander rien. C'est une question de licence, mais aussi d'accessibilité et facilité à manipuler, utiliser. Et on a fait ça aussi. On a fait pas mal de travail, mais aussi pas mal de chance pour créer quelque chose qui est assez évident. Et assez efficace à attaquer un problème qui existait partout dans les équipes de données. Et je sais que ça existait partout parce qu'il y avait pas mal de gens qui nous ont dit on a créé notre propre DBT, notre propre outil interne, mais, ça manquait quelque chose, ça manquait les documentations, ou le testing, ou la manière de faire les stratégies incrementales. Et DBT était à la fois très, très permissible, très familière, le standard. Pour ça, les équipes ont changé de son propre outil vers DBT, et aussi assez flexible, extensible, pour que ton meilleur idée dans ton propre outil, probablement, tu peux recréer dans le contexte DBT.
Bruno:
Ok, je vois. Donc tu nous disais au début que toi tu as rejoint DBT il y a 8 ans, ce qui veut dire 2018 à peu près, ce qui veut dire que tu as rejoint DBT avant la frenzy qu'on connaît depuis quelques années, des LLM, de l'IA, à tous les étages. Dans un contexte d'un outil très orienté data, tu as parlé plusieurs fois de création de modèles et de ce genre de choses qu'est-ce que cette frenzy, qu'est-ce que l'IA a changé que ce soit dans DBT dans l'outil en tant que tel ou dans la manière dont vous le créez aujourd'hui ?
Jeremy:
Bonne question, Oui, j'ai été chez DBT bien avant cette frenzy de LLM, mais aussi bien avant la frenzy de... Pas exactement avant la frenzy de Big Data, mais il y avait une frenzy 2020-2021 de tous les écosystèmes des outils de données, qui était. La chose avant que l'IA était devenue la chose. Donc, on a créé DBT pour nous-mêmes, parce qu'à l'époque, on était une boîte de conseils. Ah oui, on était une petite boîte de huit, neuf personnes qui payent le loyer, grâce à des projets avec les autres startups pour faire leur analytique, pour faire leur dashboard d'amortisation de finances ou, conversion de visiteurs de sites web vers clients payants comme ça, et on a utilisé DBT comme outil en termes avec l'idée un peu fou de aussi poster sur GitHub avec une licence open source on sait jamais. Maintenant on sait c'était grâce à ça c'était une bonne idée mais c'était 2020 qu'on a changé de boîte de conseils vers vraiment, entreprise de logiciel B2B SaaS, moi personnellement j'ai changé de data analyst, consultant vers quelqu'un qui travaillait dans le produit, mais c'était rien d'expérience comme product manager, c'était que mon expérience à utiliser le produit, avoir des opinions et. Le reste c'était pendant le travail, formé à la ligne, peut-être on peut dire, Mais on avait un voyage intéressant depuis ça parce qu'on avait beaucoup de réussite avec la démocratisation des données dans les grandes boîtes, qui avaient le désir d'adopter DBT et qui avaient besoin d'aide avec ça. Aide-com, c'est trop difficile pour nos analyses de données, pour nos équipes, d'utiliser quelque chose qui est dans le CLI ou d'apprendre Git ou faire le déploiement utilisant une ultime comme Airflow, par exemple. Airflow est orchestrateur très classique. Donc, on a créé beaucoup de produits dans notre produit commercial qui, s'appelle DBT Platform pour aider ces gens moins technique à adopter cette manière de travail comme on a dit avant c'est à la fois plus technique et moins technique qu'avant, et ça marchait très très bien et maintenant avec LLM c'est devenu beaucoup plus facile qu'avant d'utiliser les utiles sur les CLI les LLM adorent le version control. Dans le même sens que si on a 10 personnes qui contribuent à le même projet, ou si on a 100 agents qui contribuent à le même projet, c'est un peu le même problème. On n'est pas une seule contributeur qui tu gères. Ok, mais le problème pour nous, ou l'opportunité, c'est de revendiquer un peu, ou retrouver, cette idée au début que TBT doit être un utile, assez technique et à la fois assez accessible. C'est un outil qui est basé à la CLI, qui est nativement capable de faire le testing, la documentation, le contexte qui est critique pour les agents. On est très chanceux. Maintenant d'avoir fait dix ans d'expliquer aux gens, oui, vraiment, il faut documenter tes modèles de données. Parce que maintenant, ça c'est la chose la plus importante pour fournir la possibilité de self-serve Analytics utilisant les LLM. Donc, on est chanceux. Et aussi, on a créé des choses plus UI ou GUI qui sont un peu moins utiles maintenant. C'est le rétrospectif qui est vent sur vent. Je ne sais pas si je vois.
Bruno:
Top. Merci beaucoup, Jérémy, pour toutes tes discussions. C'était passionnant. J'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditoristes ?
Jeremy:
J'ai lu récemment un livre qui, je pense que c'était en français, avant que la traduction dans l'anglais que j'ai lue je crois que ça s'appelle Chose, une histoire des années 60 par Georges Perrec, qui est assez classique peut-être, assez connu, mais j'avais récemment l'expérience d'avoir un appartement vide, essayer de trouver des choses de mettre dedans et, ça m'a parlé un peu d'une vie qui... Comme quelqu'un assez minimaliste, comme philosophie, mais aussi pratique, de me lancer dans le monde de choses, ça, m'a rappelé quelque chose.
Bruno:
Ok, canon. On mettra un lien, bien évidemment, en description pour que les gens puissent le retrouver facilement. Dernière question, et la plus importante de ce podcast. Jérémy, tu es plutôt espace ou tabulation ?
Jeremy:
À tabulation, bien sûr, et avec des fichiers configuration dans VS Code. Les tabulations doivent être deux espaces dans les fichiers YAML et quatre espaces dans les fichiers SQL et tout ça. Le seul problème que je peux admettre, c'est quand tu fais le code block dans Notion et faire des tabulations, et après copier-coller dans GitHub, ça ne marche pas du tout. Donc il y a une uscase légitime pour les espaces, à la doigt manuel ça marche.
Bruno:
Merci beaucoup Jérémy merci et merci à tous d'avoir suivi cet épisode effectivement les papels de data c'est quelque chose qu'on retrouve beaucoup, c'est agréable de voir que les méthodes qu'on essaye en tout cas d'appliquer chez nous prennent, et se déploient un peu partout et sont parmi les raisons pour lesquelles, les outils ont autant de succès parce que vraiment moi j'ai vu pas mal d'équipes d'attaque qui utilisent beaucoup DBT. Donc c'est cool de savoir qu'il y a des raisons liées à tout ça. Comme toujours, je vous remercie de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.
