Modern Data Stack : L'adopter c'est faire plus avec moins de ressources

0:14 Bonjour à tous, ravie de faire ce meet-up avec vous et surtout ravie d'accueillir Julien et Thomas pour leur première prise de parole Tech.Rocks. On va commencer par un tour de table, tout simplement, chacun va se présenter et on commence avec Julien. Bonjour tout le monde, moi c'est Julien comme a dit Marie. Pour faire un petit tour de qui je suis, j'ai à peu près 15 ou 20 ans d'expérience dans la tech, avec surtout des expériences au niveau d'éditeur de solutions métiers, dans des domaines un peu différents, dans la santé, ressources humaines, e-commerce. Et j'ai rejoint Fivetrain il y a à peu près un an, plus dans un domaine analyse de données. Et pour ceux d'entre vous qui ne connaissent pas Fivetrain, Fivetrain c'est une solution qui crée des pipelines ou des ETL ou ELT si ça vous parle. Et donc on est dans le mouvement de données, surtout dans des...

1:17 Dans des problématiques d'analyse de données et aussi comment utiliser ces données de meilleure façon et en tirer de la valeur. Voilà pour moi, donc je pense que le suivant sur la liste c'est Thomas. Yes, merci Julien et bonjour à tous. Ravi aussi d'être avec vous pour ce meet-up. Merci pour l'invitation. Donc moi, Thomas Laporte, je suis le CTO France de Devoteam G Cloud. On a un cabinet de conseil et d'expertise 100% focus autour des technologies Google Cloud. On a plus de 10 ans d'existence maintenant. Et donc moi, j'ai un rôle qui est d'un côté interne de CTO, qui est globalement autour de l'expertise des équipes, l'organisation des équipes, de la montée en compétences, la définition des sujets et la détection des enjeux aussi chez nos différents clients pour se préparer globalement à ces différentes problématiques, que ce soit sur les sujets d'infrastructure, de data, d'IA par exemple. Et... Bien qu'on soit à 100% nous concentrer sur l'expertise Google Cloud, on s'enrichit aussi d'un écosystème de partenaires, dont Five3 fait partie.

2:19 Donc, on a quelques partenaires bien sélectionnés avec qui on travaille pour porter globalement ces projets, ces stratégies, ces stratégies cloud. Et donc, on travaille beaucoup conjointement avec Five3 chez certains de nos clients pour accélérer ces projets de plateforme data. Voilà, et puis donc moi j'interviens aussi en tant que solution architect chez mes différents clients sur ce sujet. Merci beaucoup Thomas. Et donc, moi, c'est Marie. Je travaille aujourd'hui en tant que Head of Data chez Choose. Choose, pour ceux qui ne connaîtraient pas, c'est une application mobile qui vous propose des marques sous forme de ventes flash, des ventes qui vont durer environ 7 jours et qui ont été sélectionnées avec beaucoup de soin par les équipes selon différents critères, soit leur impact positif, le made in France, les nouvelles tendances, etc. Voilà, et ça fait un mois et demi que je mets les mains dans la data d'autre chose.

3:25 Alors, le thème d'aujourd'hui, c'est« Modern Data Stack». L'adopter, c'est faire plus avec moins de ressources. Encore faut-il savoir ce que c'est la« Modern Data Stack». Je voudrais vous proposer de répondre rapidement à un petit sondage que vous trouvez dans l'onglet« Polls». Là sur la droite, juste pour savoir un petit peu qui parmi vous travaille déjà dans la data, qui n'est pas dans la data du tout. N'hésitez pas à commenter aussi dans le chat si vous voulez, pour se rendre compte juste à quel point Julien va aller dans le détail pour vous introduire les concepts de la modern data stack. Pendant que vous répondez, je passe la main à Julien, justement, qui va nous expliquer un petit peu qu'est-ce qu'on entend par Modern Data Stack, pourquoi ce mouvement, à quel besoin ça répond, et on pourra ensuite attaquer un petit peu les différentes questions qu'apporte cette stack. Merci Marie.

4:29 Donc en fait, par rapport au moderne data stack, avant d'arriver au moderne, il faut peut-être d'abord parler un petit peu du data stack et qu'est-ce qu'on essaie de faire avec un data stack. Et la mission, on va dire, globale du data stack, c'est de pouvoir répondre à des questions qui sont posées par différentes équipes ou différentes personnes dans une entreprise et faire cela d'une manière assez rapide et également donner une réponse qui est la plus précise possible. Donc c'est un peu la mission. Ça peut paraître simple, on va dire, au premier abord. C'est un sujet sur lequel beaucoup d'entreprises ont déjà passé beaucoup de temps et mis beaucoup d'efforts. Et donc, pour ceux qui l'ont déjà fait, on n'a plus se rendre compte que de la complexité. Mais du coup, avant d'aller dans le modern data stack, je pensais que ce serait bien de faire un petit peu un tour de... Des complexités de créer un stack. Ce que j'ai mis ici comme un peu l'effet iceberg, c'est qu'il est facile d'avoir des préjugés un petit peu sur tout, mais aussi sur un stack.

5:38 Et se dire que c'est facile. Une fois, par exemple, transférer des données d'un système à un autre, on peut considérer que c'est juste copier, on va dire, d'un système A à un système B, donc rien vraiment de compliqué. Construire des vues, des rapports, encore une fois, on a des entreprises qui ont quand même pas mal d'analystes qui ont des compétences assez poussées sur ces sujets et ça ne devrait pas non plus poser trop de problèmes. Et dernier point sur la modélisation de données, évidemment, SQL a un peu la réponse à tout, bien qu'il y ait aussi d'autres outils qui peuvent être utilisés pour la modélisation. Donc en fait, c'est facile de se dire, oui, de toute façon, on a déjà des choses qui fonctionnent aujourd'hui, c'est simple, on a ce qu'il nous faut. Après, il y a quand même... Lorsqu'on pousse un petit peu les choses et qu'on essaie de développer ou d'agrandir son stack, on va introduire des problématiques. Par exemple, au niveau transformation, ce n'est pas forcément si facile de modéliser des données. Ça peut prendre... potentiellement des mois ou des trimestres, à aboutir à un modèle qui est correct. Parce qu'il y a des éléments qui sont compliqués à mettre en place.

6:40 Chaque source de données a ses propriétés. Donc, mettre en place un système où la donnée est rapidement intégrée dans le stack peut être un problème. Des changements de schéma. Il y a plein de variables qui, si vous êtes dans le monde de la donnée, vous comprenez et vous comprendrez une fois que ça arriverait sur ces problématiques. Mais il y a beaucoup de choses qui sont là et qui posent des problèmes. Et du coup, il y a une grosse partie de l'iceberg qui est non visible. Et donc, du coup, beaucoup de choses qui sont à traiter. D'un point de vue un petit peu différent, au niveau peut-être plus procédure, lorsqu'on a un utilisateur au bout de la chaîne qui a besoin d'une réponse à une question, il doit passer par pas mal d'étapes. Il doit demander son analyse de lui créer ce rapport. Et l'analyse, lui, il se dit qu'il n'a pas la métrique. Donc, il doit demander la métrique au DBA. Le DBA, lui, n'a pas ces données. Donc, il doit remonter à l'ingénieur pour que l'ingénieur puisse extraire ces données de la source. Revenir du bas de la chaîne jusqu'en haut de la chaîne.

7:45 Donc c'est compliqué, évidemment on ne va pas faire disparaître ces procédures du jour au lendemain, mais c'est une problématique qui existe et qu'il faut aussi essayer d'améliorer. En plus, on va dire de l'ancienneté du data stack, et ce qui est aujourd'hui, en fait, il y a aussi un buzz qui se passe. On entend souvent parler d'intelligence artificielle, de machine learning, tout ça, c'est très excitant. Donc, il y a beaucoup plus maintenant d'équipes, beaucoup plus de gens qui sont intéressés par ces problématiques ou par ces... Par ces domaines et du coup ça veut dire qu'il y a encore plus de demandes. Donc on se retrouve en plus dans un cercle vicieux où déjà c'était compliqué et maintenant on a encore plus de demandes ce qui complique encore plus les choses. Et du coup la moderne data stack, pour commencer un peu à l'introduire, c'est essayer de moderniser les choses, de centraliser les données,

8:51 des mots un peu comme démocratisation de la donnée aussi qui apparaît souvent lorsqu'on parle de stack. Et le modern data stack a un peu ce but de ne pas forcément résoudre tous ces problèmes, mais au moins d'essayer d'en adresser une certaine partie. Et le plus on évoluera dans le temps, le plus on aura de réponses à ces problématiques. Donc le MDS, c'est une solution qui est cloud, qui a fortement évolué dans les dix dernières années, qui a pour but d'avoir peu de configurations techniques. Donc on délègue un peu certaines de ces complexités à... à des outils cloud et des équipes aussi qui sont très spécialisées dans ces certains domaines. Et du coup, ça ouvre l'entrée à beaucoup plus d'utilisateurs que seulement des utilisateurs techniques. En quelques mots, en quelques étapes, quelles sont les caractéristiques clés du MDS?

9:54 Encore une fois, c'est du cloud. Donc, on simplifie le côté un peu... infrastructures qui devraient être mises en place dans vos locaux. Il y a aussi un côté ETL et ELT qu'on va peut-être approfondir un peu plus tard, où il y a une transition dans la méthode d'extraction des données, où on essaie de récupérer les données brutes et ensuite de les modéliser. Ça simplifie évidemment le côté pipeline, parce qu'on a moins besoin de trifouiller les différentes sources, de comprendre comment les API fonctionnent, etc. Pour extraire la donnée. Et aussi, c'est un avantage, c'est qu'au niveau des analystes, ils ont vraiment toute la donnée dispo pour pouvoir modéliser comme il le faut. SQL based, encore une fois, SQL c'est un langage qui est quand même assez connu et qui existe depuis la nuit des temps. Et ensuite c'est entièrement managé. Donc encore une fois, il n'y a pas besoin d'être un expert en...

10:59 En serveur, en base de données, etc. Pour pouvoir commencer avec un MDS. De manière plus concrète, pour arriver un petit peu plus dans le dur du sujet. C'est une visualisation du MDS et des différents acteurs ou différentes solutions qui peuvent faire part du MDS. Je vais toujours commencer par la droite de ce schéma, c'est Data Outcomes, c'est plutôt la question qui est posée. Donc, c'est les différentes équipes, dépendamment du domaine. Donc, quand on parle de santé ou qu'on parle de finance ou qu'on parle de, peu importe, on va dire, le domaine de l'entreprise en question, il y a des questions qui sont posées. Ces questions peuvent être... Commune entre ces différents domaines. Il y a aussi des questions qui sont très spécifiques à certains domaines et même certains produits. Donc, on va dire que les questions viennent de la droite et les données qui sont utilisées pour répondre à ces questions sont complètement sur la gauche.

11:59 En fait, c'est les sources de données ou des applications qui sont utilisées par les différentes équipes. Donc, au niveau des sources, ça peut être des bases de données. Mais ça peut être aussi des choses plus modernes, comme des applications SaaS comme Salesforce ou des applications e-commerce de type Shopify, des sources qui font des événements. Des notifications, donc un utilisateur clique ici, un utilisateur regarde cette vidéo, donc plutôt des choses plutôt marketing, mais bon, une quantité, on va dire, d'applications qui ne fait que grandir et qui répond vraiment à des besoins spécifiques, qui elles-mêmes sont intégrées de manière... De manière, ça dépend on va dire l'intégration entre ces différentes applications, mais il est facile de savoir, de comprendre que des choses analytiques sont intégrées à des sites e-commerce par exemple. Mais du coup on a des données dans cette source et ensuite on a plutôt un côté pipeline ou un gestion. Où Fytran fait un petit peu partie.

13:00 donc la récupération des données et l'écriture dans les warehouses, dans les destinations, de manière brute. Puis une couche de transformation qui est encore faite par des outils très spécifiques de type DBT ou Dataform, selon ce que vous utilisez ou ce que vous voulez utiliser, pour atterrir sur un modèle ou des données modélisées. Donc à partir de ce moment-là, une fois qu'on a des données modélisées, des outils de visualisation, ou des outils de partage, en fait, peuvent être... Peuvent être plugués sur cette donnée et finalement donner la réponse à la question de départ. Merci pour cette intro, Julien. Moi, il y a une question qui saute un peu aux yeux quand je vois ce diagramme. On parle de moderne data stack aujourd'hui sous l'angle faire plus avec moins de ressources. Or, là, ce qui saute aux yeux, c'est énormément de solutions spécialisées qu'il faut choisir, intégrer, etc.

14:03 Alors, c'est quoi ton avis là-dessus? Est-ce que la moderne data stack, elle permet vraiment de faire plus de choses avec moins de ressources? Oui, on va essayer quand même de répondre au sujet principal, tu as raison Marie. C'est vrai qu'en fait, quand on regarde cette image, en tous les cas, on voit beaucoup de choses. Je pense que pour répondre un peu à sa question, quand on regarde un petit peu le passé et le présent, quand on essaie de faire un peu une comparaison, dans le passé, il y avait des systèmes qui étaient... ou un système primaire, on va dire, qui était installé dans nos locaux. Et on avait vraiment tout, enfin l'ingénieur, il avait vraiment tous les pouvoirs. Il pouvait créer des nouveaux blocs dans cette application, il pouvait faire ce qu'il voulait en fait. Et c'est vrai que d'une manière, on va dire, visuelle, on avait l'impression qu'il n'y avait qu'un système, mais au final, il y avait quand même beaucoup, beaucoup de customisation qui était faite. Et il y avait de la complexité parce que là, au niveau, je n'ai pas vraiment de visualisation ici, mais si on pense un peu à l'intérieur, intégration de ces différents blocs dans une seule application ou qui est une application qui vient d'un seul provider c'était très compliqué en fait donc c'est vrai que

15:09 peut-être qu'avant on avait un seul logo on va dire sur la page mais on se disait bah c'est simple on a un fournisseur qui nous fait tout mais derrière c'était pas forcément si si si si propre que ça, il y avait beaucoup de customisation, donc il y avait beaucoup d'efforts à faire pour maintenir, pour créer du flux de données. Donc je pense que de ce point de vue, bien que là on montre quand même une image qui est pleine de logos, ces différentes particules ou ces différents topiques ou procédures dans le flow, elles existaient déjà, mais elles n'étaient pas spécialement cachées en fait par le fait que ce ne soit qu'un seul fournisseur. Ok. Bon, alors on ne va pas passer chacune des solutions dans l'écran, évidemment, en revue, mais ça peut être intéressant de s'attarder sur les plus grandes questions qu'on va avoir en tant que DevData, LeadData, VPN, etc. Les étapes principales. La première, c'est l'ingestion, les sources de données. Je pense que la plupart des personnes ici qui travaillent dans la data sont confrontées à des demandes plus ou moins nombreuses d'aller récupérer des informations dans différents systèmes.

16:21 On a nos DB internes, mais on a aussi tous nos outils. CRM, sales, marketing, etc. Et l'une des promesses de cette moderne data stack étant de pouvoir croiser des informations intelligemment dans tous les sens et les mettre très vite, très facilement à disposition des utilisateurs finaux. Mais encore faut-il d'abord rassembler toutes ces données. Alors, comment est-ce qu'on peut faire justement tout ça, faire plus qu'avant, avec moins de ressources, Julien, puisque c'est un petit peu votre spécialité? Oui, on peut essayer de faire ça. C'est vrai que tout à l'heure, quand je montrais un peu cette complexité des différentes équipes, analystes, DBA, ingénieurs, on a l'impression que c'est toujours là. On ne veut pas faire ça disparaître. Mais bon, il y a un côté où... Où on peut réduire les étapes qui sont quotidiennes, par exemple des pipelines qui cassent tous les jours, c'est quelque chose qu'un ingénieur peut passer la plupart de son temps dessus, au lieu de travailler sur des sujets, des problématiques qui sont importantes pour l'entreprise.

17:25 Et ce que je peux faire ici, c'est peut-être montrer un petit peu comment, avec Fystra, dans tous les cas, on peut... On peut en l'espace de quelques minutes créer un pipeline et voir comment ça peut évoluer avec le temps. Et je permets de, pendant que Julien partage son écran, je permets d'insister. On a vu dans le petit sondage qu'il y avait à peu près 25% des personnes qui sont en train de nous écouter qui ne travaillent pas forcément directement dans la data. Donc, n'hésitez surtout pas à poser vos questions sur le chat. S'il y a des termes qui ne sont pas clairs, s'il y a des concepts que vous voulez qu'on précise. On est là pour ça. Donc, ne soyez pas timide. Super. Donc là, je pense que j'ai un peu agrandi l'écran, donc j'espère que vous voyez bien le contenu. Mais ce qu'on voit à l'écran, en fait, c'est une pipeline. Enfin, c'est plusieurs pipelines. On a deux pipelines à l'écran, là. Donc, on a une pipeline entre Twitter et la warehouse que j'ai créée, que je vais vous montrer dans une seconde. Et aussi une pipeline de Facebook.

18:28 Donc ça veut dire qu'on récupère des données de ces deux systèmes et qu'on les écrit dans la destination. La destination dans ce cas-là, c'est une destination BigQuery que j'ai configurée avant l'appel pour ne pas trop perdre de temps non plus sur ça. Mais si je vous montre rapidement. Cette destination, donc c'est une BigQuery, évidemment il y a une intégration native entre cette plateforme ETL qui a quand même pour but de simplifier les choses, donc quand on se connecte à BigQuery, vraiment c'est remplir un formulaire avec les informations qui nous permettent d'écrire dans BigQuery, donc le service account qui est en gros un utilisateur technique de GCP, et le projet dans lequel on va écrire. Donc, c'est un formulaire qu'on remplit, pas besoin d'être un ingénieur pour faire cette étape. Maintenant, si je reviens à mes pipelines, je peux en ajouter une autre. Il y a un bouton ici qui s'appelle Add Connector, je peux cliquer dessus, ça me donne une liste de mes différentes destinations, je vais choisir celle que j'ai définie pour...

19:30 cet événement et là on voit une liste d'applications qui sont nativement supportées par l'outil. Le côté application, ça c'est très fort dans cet outil parce que les applications, ça généralement ça utilise des API, donc l'utilisation d'un API est assez standard. Bien que ces applications, bien sûr, ont généralement des fonctionnalités de créer des éléments custom. ça reste récupérable par API dans la plupart des cas. Bref, pour revenir à mon exercice, je vais rajouter une source LinkedIn. Donc je peux juste la sélectionner ici et écrire Setup. Et encore une fois, c'est une page, on va dire, un formulaire assez simple. Il n'y a pas encore besoin de comprendre ce qui se passe derrière, mais on me demande juste d'autoriser l'accès aux données de LinkedIn. Donc en fait, ce qui va se passer, c'est que ça va me rediriger vers LinkedIn. Pour créer la connexion entre mes données LinkedIn et Fivetran, et aussi BigQuery.

20:42 Je vais juste chercher le mot de passe. Rapidement donc on fait une autorisation de linkedin pour pour donner accès aux données Et du coup, la connexion a été faite. Dans le background, on a récupéré des tokens qui identifient ce compte. Et à partir de là, je peux juste cliquer Save and Test. Et ça va créer la pack. On fait quelques validations, qu'on a bien un accès aux API. Et que tout est en place pour récupérer les données. Mais une fois qu'on clique Save and Test et que cette étape est finie, la pipeline est créée et on commence à récupérer des données de LinkedIn vers BigQuery. Donc, c'est une étape importante du process qui, a priori, d'après ce que je vous montre ici, ça reste assez simple. Ce n'est pas la fin de l'exercice, on va dire évidemment, on est juste ici en train de bouger des données de droite, d'une application à un data warehouse, le côté modélisation, le côté visualisation de la donnée, elle reste aussi à faire.

21:52 Donc encore une fois, il y a des intégrations assez pointues entre les différents outils. Qui sont dans le stack. Par exemple, l'intégration avec DBT, qui est un outil de transformation qui permet d'écrire des modèles en SQL ou des modèles en Python qui peuvent être exécutés à la suite que la donnée soit arrivée dans le Bicory, mais ça reste une partie du process. Maintenant, rapidement, pour vous montrer le résultat final, ici, je peux commencer la récupération des données. Ça va prendre quelques minutes. On peut juste... Pour regarder, en attendant que ça se fasse, les informations par exemple que j'ai récupérées plutôt sur Facebook, on va sur BigQuery, donc ça c'est l'interface de GCP pour BigQuery. Ça a automatiquement créé des datasets et des tables et les champs nécessaires, on va dire, pour la structure d'arriver dans BigQuery. Et si j'étends ça et que je fais un juste... Si je regarde un peu la quinte, et qu'on regarde un peu les données qui sont arrivées, on se rend compte qu'en fait les données sont arrivées de manière assez brute.

22:58 Mais pour quelqu'un qui comprend la structure de Facebook Ads, dans ce cas-là, qui arrive dans BigQuery, il va avoir une certaine compréhension des données qui sont affichées. Donc voilà, Marie, j'espère que ça répond un peu à la question de la simplicité, en fait, faire plus avec moins dans le sens où, finalement, sans la connaissance technique de créer une pipeline, on peut tout de même créer une pipeline. Oui, c'est clair. On a lancé un mini-sondage que vous pouvez retrouver dans le dernier onglet, juste pour savoir qui parmi vous utilise une solution d'ingestion de données. Si oui, est-ce que c'est un outil du marché comme celui qui vient d'être présenté? Ou est-ce que c'est une solution développée in-house? Ou est-ce que non, vous traitez les demandes du business au cas par cas? Quand il faut s'intégrer à Hotspot, vous prenez ça dans votre backlog.

24:02 Et si trois mois plus tard, il faut s'intégrer à Intercom, vous faites un nouveau projet pour ça, etc. Je vous laisse répondre. Tout à l'heure, pour information, on avait 25% qui ne travaillaient pas dans la data, 75% qui travaillaient dedans. Mais même si vous n'êtes pas dans la data, peut-être que vous êtes dans la tech et que vous connaissez la réponse à cette nouvelle question. Pour terminer sur cette partie ingestion, Julien, très rapidement, comme vous êtes au cœur du sujet avec Faitran, est-ce qu'on peut avoir un exemple de client sur l'avant-après, avant une solution comme ça? après une solution comme ça, qu'est-ce que ça a changé pour eux ? Qu'est-ce que ça leur a fait gagner? Est-ce que ça leur a permis de faire plus de choses avec moins de ressources? Oui, c'est un peu l'objectif, mais c'est vrai que c'est toujours bien peut-être d'avoir quelques retours ou un exemple en tous les cas, ou plus. Mais si, en fait, on a... Je vous présente le rôle. box donc qui sont également dans un sujet qui est qui fait le buzz depuis quelques mois quelques années en tous les cas c'est le côté voiture électrique l'électricité plutôt que le pétrole

25:12 et du coup ce qui s'est passé pour eux ils ont donc c'est une entreprise qui crée des connectés pas des connecteurs mais des chargeurs pour véhicules électriques Et ça a explosé. Leur entreprise a grandi dans l'espace de 2 à 3 ans. Ils sont passés de 50 à 1 000 employés, ce qui veut dire que derrière, ils ont augmenté leur base de clients. Ils ont dû s'adapter à cette... À ce qui s'est passé en fait dans l'entreprise en développant leur stack du côté applicatif surtout pour commencer parce que pour gérer plus de clients, pour gérer plus d'employés, pour créer des produits qui sont plus divers et plus compliqués, il faut des outils derrière. Et donc là par exemple, Leur stack a inclus des choses niveau ads par exemple, pour vraiment faire du marketing par rapport à leurs produits, mais aussi des outils comme Salesforce pour gérer leur clientèle, des outils comme Jira pour créer leur développement, leur procédure interne, etc.

26:16 Ici, c'est juste un exemple des sources qu'ils ont développées. Ils se sont retrouvés dans une situation où ils avaient toutes ces données qui étaient dispersées. Et ne s'en servaient pas du tout en fait. Du coup, quand ils ont commencé à... à travailler avec le NDS, ils ont réussi vraiment à unifier ces données, ils ont réussi à apporter en gros des réponses à des questions qui étaient critiques pour l'évolution de leur business. Ils ont automatisé les analyses pour améliorer l'efficacité des opérations en interne. Et vraiment, le MDS, on va dire, était au cœur de cette solution parce que ça n'aura pas mis une implémentation rapide. Parce qu'encore une fois, c'est dans le cloud. Ils n'ont pas eu besoin, on va dire, de... De créer des équipes vraiment de A à Z qui comprennent comment créer un warehouse, comment créer des outils de transformation. Ils ont pu aussi prendre ce qu'il y avait sur l'étagère et faire ça très rapidement. Juste pour conclure peut-être sur des chiffres un peu plus flagrants, on va dire, pour donner une idée de ce qui a pu être fait.

27:22 Donc, on a Canva qui a réussi à réduire les coûts d'ingénierie. On ne parle pas forcément, on ne parle pas que, surtout on ne parle pas de réduire la... Le nombre d'ingénieurs, on peut en parler aussi au niveau d'infrastructures, ça peut coûter cher d'avoir des choses hébergées, des serveurs, etc., qui doivent tourner. En gros, ils ont réduit en tout à peu près 200 000 dollars lors de l'implémentation du MDS. On a PubSockets qui a réussi à doubler le retour sur l'investissement des publicités. Et on a Glossier qui a augmenté de 36%. leur retour sur investissement au niveau marketing. Donc voilà quelques chiffres en fait et quelques retours d'expérience. Merci beaucoup Julien. Chose intéressante, il y a 60% des personnes qui ont répondu jusqu'à présent qui n'utilisent pas de solution pour l'ingestion des données. Donc, encore une fois, n'hésitez pas à poser vos questions si vous avez des doutes sur la bonne stratégie à adopter, si vous voulez aussi juste partager quels sont vos pain points du moment par rapport à l'ingestion depuis plusieurs sources.

28:34 Maintenant, est-ce qu'on peut retourner sur le schéma global? Merci beaucoup. Sur l'une des étapes suivantes, une fois qu'on ingère des données, etc., il y a la question de la transformation de ces données pour les préparer, les croiser, les mettre en forme pour qu'elles puissent être utilisables. Et puis, la question de la mise à disposition de ces données. Personnellement, une question qui m'est souvent adressée, soit dans les entreprises où j'ai été à Top Data, soit via des réseaux data, c'est est-ce que c'est vraiment une bonne idée d'utiliser des solutions cloud hyper flexibles, hyper scalable comme BigQuery? Et pourquoi on me pose cette question? Souvent parce que les gens ont très peur de ce côté scalabilité non maîtrisée, donc des coûts. Il y a pas mal de petites histoires qui se racontent d'une boîte à l'autre sur... J'ai laissé telle data sur Bitcoin. Il y a des gens qui ont eu full accès, qui ont fait des requêtes un petit peu par erreur ou qui ont lancé des boucles de requêtes.

29:39 Je me suis retrouvée avec 10 000 euros de facturation Bitcoin sur une journée. Et bien, plus jamais, on s'est retiré de la solution, on n'y mettra plus les pieds. Thomas, chez Devotim, j'imagine que des questions comme ça, vous en avez souvent. C'est quoi un petit peu ton point de vue là-dessus? Quels sont les risques? Quelles sont les opportunités? Quelles sont les stratégies pour... tirer la meilleure partie de ces solutions. Yes, effectivement, nous, on est en plein dedans. On travaille avec ces questions au quotidien. Et puis, quand on parle de cloud, on parle de tech, on parle de beaucoup d'autres choses qui sont autour, des questions d'organisation, de process, de gouvernance, de finops et de gestion des coûts d'optimisation. Donc, ça en fait partie. Et si je reviens un petit peu sur les chiffres aussi que tu montrais, Julien, et je trouve que le résultat du sondage est intéressant aussi, il y a souvent cette question de, quand on construit, quand on compose sa stack, sa plateforme d'Alta, ou même au sens plus large, ces environnements du build versus buy, est-ce qu'on construit nous-mêmes?

30:41 Se dotent, parce qu'on s'équipe d'une solution qui peut le faire pour nous. Ce que tu as illustré, Julien, à travers le Five Trans, c'est pour une petite partie de tout ce cycle vie de la donnée, pour la partie d'ingestion, il y a des outils qui sont très spécialisés sur une partie de cette chaîne, qui vont en quelque sorte retirer la responsabilité du build, du run de ces choses-là, pour permettre justement de libérer l'engineering pour se concentrer sur les cas d'usage qui ont de la valeur pour le business. Je redisais ça pour revenir un petit peu sur cette slide-là, ce landscape, quand on dit la modern data stack, finalement, et revenir un peu sur la définition initiale, ce n'est pas une... Ce n'est pas une stack en tant que telle, il y a un côté une collection d'outils et d'un côté une collection d'outils. qui vont être assez spécialisés, plutôt que d'essayer de tout faire, ils vont choisir d'adresser une partie de cette chaîne-là, et aussi très modulables, qui vont travailler ensemble, plus un certain nombre de pratiques, tu en as cité certaines, il y a beaucoup de ces outils-là qui vont répondre aux...

31:48 À une des composantes que tu dis cloud first ou cloud based, qui tire parti des capacités du cloud, et c'est là qu'on arrive à cette partie coût. L'avantage que ça a, c'est cette capacité à s'adapter, à scaler, à être élastique en fonction du besoin. Et d'avoir un coût qui est très associé à ça. Une des caractéristiques du cloud, en soi, c'est le pay-as-you-go. On est facturé pour ce qu'on utilise, et du coup, pour uniquement ce qu'on utilise, et puis à l'inverse, on ne paye pas pour des choses qu'on n'utilise pas. Et donc ça, c'est une opportunité en soi, parce que ça permet et de commencer, tout petit, donc avec des coûts qui sont très moins très contrôlés, tout en ayant accès à une capacité technologique, que ce soit des capacités de scalabilité, des services à forte valeur, des services d'IA, des choses comme ça, sans pour autant avoir besoin de faire des gros investissements en amont. J'ai des boîtes demain matin, je n'ai pas forcément grand-chose à investir upfront dans la tech, je ne sais pas encore où je vais, etc.

32:56 Par contre, j'ai d'entrée de jeu accès à tout un panel d'outils. qui ne vont pas me coûter très cher au début, et au fur et à mesure que mon besoin va évoluer, la facture va évoluer avec. Et je pense que tu as un peu répondu à une partie de la question quand je l'ai posée, je ne sais plus exactement comment tu l'as dit, tu as parlé d'évolution de coûts non maîtrisés, il y a cette partie de maîtrise qui répond en partie, parce qu'en soi, le fait que sa facture cloud, de service cloud, augmente, a priori c'est censé être une bonne nouvelle. C'est-à-dire que, en tout cas, ce qu'on fait là tous, de manière générale, on va revenir dans l'IT, c'est mettre de la tech au service de besoins métiers qui vont avoir une valeur business pour sa boîte. Et du coup, si j'ai une... Augmentation de ma consommation à IT, a priori, elle devrait suivre, si tout va bien, une accélération du business parce que j'ai une augmentation du trafic sur mon service, j'ai des nouveaux produits, des choses comme ça.

33:58 Donc, si ça va dans ce sens-là, en général, c'est plutôt une bonne chose. On peut démarrer petit sans de gros investissements en ayant accès à une stack technologique complète qui est exactement la même que des gros qui ont démarré peut-être il y a 10 ans, qui ont investi énormément dans leur techno. Et ensuite, si c'est bien maîtrisé, ça va suivre l'évolution de mon business. Si le business accélère, j'ai une facturation qui va suivre avec, etc. Si je prends l'autre côté de la pièce, comme tu disais, ce qui peut faire peur aussi, c'est que du coup, si ça peut grandir comme ça, potentiellement à l'infini, comment est-ce que je m'assure que ça reste contrôlé et je ne me retrouve pas dans des situations où j'ai une facture surprise, gigantesque, et c'est le cas, ça arrive encore très souvent pour différentes raisons. Et il y a cette partie effectivement de maîtrise et de définition du cadre. Je pense qu'il y a un premier sujet, on en fait beaucoup avec nos clients, dans quasiment tous les projets,

35:00 cloud au sens large, il y a une partie tech, et en particulier pour les boîtes qui sont encore dans cette phase d'adoption, il y a une partie, encore une fois, people, compétences, organisation, prothèse, qui va avec, on va dire, tout ce qu'on pourrait mettre sous une enveloppe de conduite du changement, qui va être... Déjà sensibiliser, former les gens à ce que c'est que de travailler sur du cloud, qu'est-ce que c'est que d'utiliser les outils cloud, toutes les opportunités que ça apporte, mais aussi ce qu'il faut comprendre, avoir en tête les contrôles qu'il faut mettre en place pour prendre les décisions en toute connaissance de cause. Parce que les risques qu'on peut avoir qui pourraient faire exploser la facture, ça pourrait être par exemple... Un mauvais choix d'architecture. J'ai pris des composants qui n'étaient pas forcément adaptés. Le cloud, c'est génial. On peut directement déployer une stack hyper scalable, multi-région, hyper résiliente, etc. Mais peut-être que ça, c'est complètement décorrélé du besoin business qui est associé.

36:01 Donc c'est une prise de sensibilisation, une prise de connaissance de ça. Et souvent, quand on démarre sur le cloud, souvent il y a un étonnement qui vient, je trouve, des équipes tech aussi, c'est qu'on parle tout le temps de coûts. Et cette notion de coûts, c'est vrai qu'elle est remise au cœur des questions, par exemple, d'architecture, quand on va architecturer une solution. La question de coût est importante. Qu'est-ce que ça veut dire en termes de coût aujourd'hui? ça va évoluer et quels sont les différents scénarios que je vais pouvoir mettre en place dans mon marché. Donc voilà ce que je veux dire, il y a un côté très conduit du changement, formation, sensibilisation à cette question-là. Il y a une notion importante aussi de... Du coup, si le... Si l'ingénieur, si le tech, si le dev peuvent eux-mêmes provisionner des infrastructures qui génèrent un coût, qui portent la responsabilité du suivi de ces coûts-là, qui est important à définir.

37:03 Et puis ensuite, il y a un cadre technique aussi à poser. C'est comment est-ce que je me protège contre... Je disais le mauvais choix d'architecture, une erreur ou un bug, tout simplement, tu as une boucle infinie qui lance des requêtes, chaque requête va avoir un petit coup qui va s'additionner. Comment je me protège contre ça? Globalement, on définit des fondations, c'est un socle solide qui va mettre des garde-fous. Et en amont, pour s'assurer qu'on ne puisse pas commettre ce genre d'erreur en définissant par exemple des limites, en définissant des quotas, en étant précis sur la manière dont on gère les droits d'accès, qu'est-ce que je suis autorisé à faire en tant que mon rôle, qu'est-ce que je suis autorisé à déployer. Je dirais qu'aussi l'approche un peu globale qu'on a avec du GitOps, ça facilite aussi beaucoup ça. On a tendance à, aujourd'hui, tout ce qu'on veut déployer, aujourd'hui particulièrement dans le cloud, on évite de... de se dire, je vais aller dans la console, lancer des instances, etc. On va plutôt s'orienter vers des approches type infrastructure, Ascode, etc.

38:10 Qui font que tout changement que je vais apporter à mes environnements va passer par, globalement, un commit de code qui va donc déclencher des checks, des tests, des validations, des reviews. Et à ce moment-là, on est déjà capable d'estimer un impact que ça peut avoir en termes de coûts et aussi potentiellement bloquer les choses. C'est-à-dire que ce n'est pas compliant par rapport à des guidelines qu'on a définis dans l'entreprise. Donc définir globalement des guerres de fonds en amont pour bloquer les choses avant qu'elles se produisent. Et puis surtout, de manière plus large, on avale sur les environnements existants qui tournent, avoir une capacité d'observabilité de ces environnements et techniques, et du coup aussi sur l'aspect coût qui est vachement important. Être capable de détecter, par exemple, rapidement, d'un jour à l'autre, j'ai une augmentation ou une accélération de mes coûts. j'en suis déjà alerté, je suis au courant, qu'est-ce que ça veut dire, quelle action prendre, est-ce que c'est normal ou non, voire potentiellement aussi automatiser des actions de remédiation.

39:12 Donc le risque globalement il est là, tu allais poser une question? Non, non, non, vas-y, finis. Et je pense que le plus important, alors ce n'est pas forcément d'en avoir peur, mais par contre, c'est d'en avoir quand même bien confiance et le considérer vraiment comme un élément important. de sa plateforme cloud, de sa plateforme data, et qu'il faut construire les pratiques et le cadre qui va autour de ça. Pour justement pouvoir retourner vers ce qu'on disait au début, ce modèle de facturation à l'usage qu'apporte le cloud. Ça reste une énorme opportunité, une capacité à innover très vite, au début à petite échelle, et puis ensuite grandir au fur et à mesure de ces besoins, si ça porte encore une fois un besoin de business. Donc voilà un petit peu l'approche. Je dirais peut-être un autre point aussi, parce que c'est pareil, c'est un truc qu'on croise encore trop souvent, il y a un aspect sécu aussi là-dedans, sécurité. Et on comprend bien, je pense, dans le cloud, et quand on parle de data, la sécurité, c'est un pilier assez majeur.

40:15 Qu'on soit sur le cloud ou non, un des risques de sécurité, c'est exfiltration de données, par exemple, des données sensibles qui sortent de l'entreprise ou qui tombent dans les mains de personnes qui ne devraient pas y avoir accès. Mais il y a un autre aspect qui est, encore une fois, qui est très lié au coût. On voit très souvent, je ne sais pas, une fuite de clés de service à 40, un secret qui est publié, par exemple, sur un repo GitHub. Et hop, d'un coup, j'ai une personne extérieure qui a accès à mes environnements et qui est capable de... Popper 200 VM avec plein de CPU pour faire par exemple du cryptomania, ça arrive encore très fréquemment. Donc ça pareil, important, il ne faut pas voir ça comme un risque incontrôlable, important de l'avoir en tête et de définir le cadre qui permet d'éviter que ces situations arrivent par des techniques. Et à mon, dans ce cas-là, ça peut être encore une fois la durée de vie des jetons, l'incapacité depuis certains périmètres à accéder à certaines données, être très précis sur... qu'est-ce qu'un compte technique, quel périmètre auquel il peut avoir accès, et puis Aval est capable de continuer de contrôler, d'observer ces environnements pour pouvoir réagir à des situations potentiellement anormales.

41:28 Ok, alors énormément, énormément. J'espère que ceux qui nous écoutent arrivent à absorber un petit peu toutes les leçons, parce qu'il y en a énormément. Si on essaye de résumer sur la partie appréhension par rapport au coût cloud, pas forcément spécifiquement sur le data warehousing, mais comme tu l'as dit, on peut aussi provisionner des machines. Les conseils principaux, c'est donc tout ce qui est pédagogie, bien responsabiliser les équipes. Et ça, ce qui peut aider au-delà de juste en parler, mettre le sujet au centre de la table, c'est du reporting, de la visualisation, que chacun voit un petit peu qu'est-ce qui est consommé sur le cloud, quelles équipes ont fait popper quoi, etc. Il y a la partie aussi contrôle, comme tu le disais. Il y a des outils qui permettent de mettre des limites, de mettre des alertes, etc. Et puis plus globalement, il y a cette question d'architecture qui se recoupe avec, là, ton deuxième point sur les bonnes pratiques, la sécurité, etc.

42:29 Et là-dessus, pour moi, il y a un énorme challenge. C'est-à-dire que je trouve quand on est dans le vif du sujet, dans nos entreprises, on voit tous ces talks, tous ces schémas sur la moderne data stack et des fois... Ça nous fait un petit peu sourire en quoi? En se disant, oui, il est mignon, votre schéma d'architecture, parfait, tout linéaire, tout va bien. Mais dans la vraie vie, souvent, ce n'est pas exactement ça. Et pour illustrer, en toute transparence, je vais vous montrer. À quoi ça ressemble l'archi aujourd'hui chez... Chez Choose, est-ce que vous voyez le schéma ici? Yes, c'est bon. Alors, je ne vais pas vous le commenter en détail. Ce n'est pas l'idée. C'est plutôt dire, en fait, c'est comme beaucoup de grands paradigmes. Il y a l'idée qui est très belle, parfaite, où ça résout la plupart des problèmes, etc. Et puis après, il y a le terrain. Et sur le terrain, les gens vont avoir beaucoup de bonne volonté, ils vont vouloir prendre ces idées, etc.

43:33 Mais ils sont aussi confrontés à l'historique de l'entreprise, aux spécificités techniques de leur business, du reste de la stack tech, etc. Des idées des différents membres de l'équipe, des gens qui sont peut-être partis, d'autres personnes qui arrivent avec d'autres idées, etc. Et encore, vous voyez, cette stack-là, cette architecture, elle est beaucoup plus complexe que ce qu'on voyait avant. En tout cas, elle n'est pas du tout linéaire. Et encore, très franchement, ils ne sont pas si mal lotis. J'ai vu beaucoup d'autres entreprises où dessiner le schéma d'architecture rien que de la data était un vrai, vrai cauchemar. On dit tout que là, ce qu'on voit là, c'est encore vraiment pas si mal. Pourtant, vous voyez des effets de boucle. On a de la donnée qui part sur PubSub, pour faire simple, une technologie de streaming. Les événements ensuite sont dépilés, sont stockés quelque part. sont réinjectés dans du BigQuery, On fait des transformations avec des BT sur Bitcoin.

44:35 Mais on en fait aussi sur une base post-grès. Il y a du Airbyte, donc une solution pour de l'ingestion de données, qui est censée faciliter plein de choses, mais qui reboucle avec d'autres choses aussi. Bref, ça, c'est un petit peu la réalité, je trouve, de la plupart des entreprises. Avec toutes les questions que ça amène de maintenance de beaucoup de systèmes, de connaissances de technologies assez différentes, de maintien de la cohérence. ces données, aussi charge mentale de se rendre compte de tout ce qu'on a à gérer, de toutes les erreurs possibles qui peuvent s'insérer dans la donnée à chacune de ces étapes. Bref, il y a une énorme question d'architecture, tout simplement, que je pense que beaucoup, beaucoup d'entreprises ont aujourd'hui. s'être lancé avec plein de bonne volonté sur des initiatives de DataStack. Comment est-ce qu'on peut bien aborder ces problèmes, Thomas? C'est une question difficile, mais tu as peut-être des conseils à proposer.

45:36 Oui, bien sûr, c'est effectivement une question difficile, vaste sujet. Après, c'est aussi ce que je fais moi au quotidien, donc je peux partager dessus. Honnêtement, je m'attendais à voir un truc aussi un peu plus complexe que ça, beaucoup plus complexe quand tu as partagé ta stack, parce qu'effectivement, souvent, il y a de l'historique, il y a des choses qui ont commencé à être développées d'un côté, puis des trucs parallèles qui commencent à naître, puis on essaie de réunifier ça en partie, mais pas complètement, ça se crée des données, etc. Et on peut se dire que ce n'est pas forcément une belle architecture, mais ça reste une réalité concrète. Ce n'est jamais tout aussi beau qu'à la fin de notre phase d'architecture, on a fait un joli schéma. Mais globalement, ce que je peux dire là-dessus, effectivement, elle est... Cette phase est hyper importante et difficile, du fait aussi qu'elle prend en compte pas mal de... pas mal d'aspects, en particulier aussi dans le cloud, parce que dans le travail d'architecture, il y a une notion de technique, de technicité, mais aussi il y a des aspects

46:40 organisationnels, des notions de coûts, ce genre de choses, comment ça va évoluer dans le temps, comment ça va se caler, etc. Je pense que l'objectif en soi de cet exercice-là, c'est... À comprendre qu'est-ce qu'on essaye de construire. Et c'est pas mal de se poser la question, parce que très vite, en tout cas, si on démarre, quand on démarre, soit d'une page blanche, soit d'un existant qu'on veut peut-être faire évoluer et déplacer, on peut très vite se concentrer sur un petit bout du problème ou sur la fin de la chaîne qui pourrait être un use case particulier par exemple et construire pour ce use case par exemple ou à l'inverse construire ou faire ses architectures vis-à-vis de technologies ce qui n'est pas non plus ce qu'on essaie de faire quand on fait une architecture on essaie de répondre à un besoin encore une fois donc c'est comprendre et ce besoin tel qu'il est à l'instant T où on fait l'exercice, et aussi comment ça s'articule par rapport à la stratégie globale de l'entreprise, où est-ce qu'on veut aller, pour ne pas construire un truc qui réponde pendant six mois et qu'il faille tout reconstruire derrière.

47:43 Donc voilà, il y a cette compréhension du besoin, et avec une projection un peu future, et puis aussi une compréhension du contexte dans lequel on est, qui est l'organisation de l'entreprise, des contextes peut-être de délai, il y a des moments où il y a besoin d'aller vite, il y a des moments où on peut prendre du temps, par contre on a besoin de... être compliant par rapport à certains trucs. Il y a des contraintes technologiques, comme tu disais, qui peuvent être de l'existant. Il y en a une qui est vachement importante aussi, qui est quelles compétences j'ai dans la boîte. Parce que ça va être hyper important pour la suite quand on va vouloir implémenter cette architecture-là. Un exemple, là, on a la stack sous les yeux. On pourrait très bien se dire, je vais construire ma modern data stack. Je vois que pour automation, orchestration, là en bas, j'ai Airflow. C'est le produit qu'il faut prendre. Ce n'est pas évident qu'on ait les compétences en place pour faire ça chez nous. Aussi bien en termes de capacité, ça peut coûter cher, il faut l'opérer, il faut le maintenir, etc. Il faut développer, il faut des skills en Python, ce n'est pas forcément le meilleur outil qui serait adapté à un contexte particulier.

48:51 Donc voilà, il y a encore une fois, qu'est-ce qu'on veut faire et quelles sont les contraintes de l'environnement dans lequel je suis. Et à partir de ça, je pense, un conseil que j'ai qui me paraît extrêmement important, c'est prendre le temps, et ce n'est pas forcément un truc qui est très long et très compliqué, parce que c'est des petites boîtes, mais d'architecturer sa plateforme. Déjà de manière, on va dire, fonctionnelle. On est agnostique de toute technologie, on est agnostique de toute source de données, de tout cas d'usage aussi qu'on va vouloir porter derrière. Qu'est-ce que c'est que ma data platform? Quel rôle elle tient dans l'entreprise? Comment est-ce qu'elle est découpée ? Qui sont les acteurs qu'il y aura autour? Je vais avoir des sources de données, des produits qui vont consommer de la donnée, des équipes métiers qui vont avoir peut-être poussé ou consommé de la donnée au travers de différentes interfaces. Comment tout ça interagit entre eux? Comment je vais l'opérer, etc. Il y a plein de questions qu'on peut se poser, qu'on peut designer sans même aller se poser la question de quel techno je vais utiliser, quel produit, quel service, etc.

50:01 Et je pense que c'est un des premiers points, c'est vraiment le temps de faire ce travail-là pour se dire, si j'ai quelqu'un qui rejoint mes équipes, qui intègre la boîte par exemple, je suis capable de lui montrer mon architecture data de manière fonctionnelle. Et à partir de là, ensuite, on va... Définir comment est-ce que je l'implémente. Et là, on va rentrer des questions de technologie, de produit-service. Et ce qu'on peut voir aussi, ce qu'on peut voir généralement, c'est que ces questions de tech, comment est-ce que j'implémente un truc, quel produit j'utilise à un endroit ou à un autre, c'est quelque chose qui est beaucoup plus changeant avec le temps. On ne peut pas faire des choix à conduisant à un instant T, je disais, parce que là, on a une contrainte d'aller vite. Je vais prendre ce produit-là pour démarrer, et puis plus tard, je vais changer cet outil par un autre, peut-être qui serait plus intéressant, qui répondrait plus à mon besoin, sans pour autant remettre en cause l'architecture fonctionnelle de ma plateforme, en quelque sorte. Parce qu'en fait, pour résumer, on pourrait dire que tout simplement, il faut être proactif sur l'architecture de ces stack data, là où beaucoup d'entreprises, en fait, la subissent.

51:14 On crée des choses pour répondre à des besoins et il n'y a pas de vision d'ensemble, il n'y a pas d'urbanisation des systèmes d'information comme on a appris à le faire dans le reste de la tech. Bien nécessaire et en fait c'est tout autant nécessaire dans la data mais je trouve que c'est un petit peu ce qu'on se répète Depuis des années maintenant, il se passe plein de choses dans l'univers de la data. Au début, la data fait sa vie de son côté, comme en data science, on s'est mis à faire du code et puis on n'a pas testé, on n'a pas fait de bonnes pratiques de dev et tout. Et puis au bout d'un moment, on s'est rendu compte que quand même, c'était vachement nécessaire. Et finalement, l'histoire suit son cours et toutes les big data finissent par bénéficier des mêmes bonnes pratiques que la tech. Il n'y a pas de grande surprise, mais il y a beaucoup de bon sens. On va devoir conclure parce qu'il nous reste 5 minutes. Et je voudrais qu'en conclusion, on puisse donner quelques leçons, conseils clés supplémentaires pour ceux qui nous écoutent. Mais avant ça, j'ai une question ultra rapide, Julien.

52:16 Est-ce que tu peux nous répondre en une minute sur le bout de chaîne? On ne va pas parler de BI, de machine learning, etc. Mais je trouve qu'une demande à laquelle on est fortement confronté dans les équipes d'atteinte, c'est maintenant qu'il y a toutes ces données magnifiques recoupées qui sont vachement intéressantes, nous, on aimerait bien les avoir dans notre outil de CRM, dans notre outil de sales, dans tel outil de marketing, etc. Pour derrière créer plus de valeur, automatiser des choses. Bref, c'est la question du fameux reverse ETL. Chez Fivetron, vous faites la partie ETL. Vous ne faites pas la partie reverse ETL. Pourquoi? Oui, en effet, pardon. C'est quelque chose qu'on a un petit peu investigué. On a essayé de voir. si on voulait le faire, si on pouvait le faire. Et on s'est rendu compte que, en tout cas pour l'instant, c'est quelque chose qui est quand même assez différent. Juste pour soulever peut-être quelques points dans les différences, lorsqu'on va des applications qui sont assez structurées, au niveau des modèles,

53:21 ou au niveau des API, c'est quelque chose, en fait les applications sont vraiment par défaut, elles sont développées pour l'utilisation métier et pas forcément pour tirer des données ou pour en écrire des données. Donc du côté, on va dire, extraire des données de ces applications, ça reste assez simple. Et après, quand on l'écrit dans les webhats, on a ce système un peu d'écrire des données brutes. Du coup, on n'a pas trop de restrictions sur la façon dont on écrit dans les webhats. Donc lire et écrire. C'est évidemment notre métier, donc on considère que c'est simple. Mais aller dans l'autre sens, c'est beaucoup plus compliqué. Il y a plus de restrictions au niveau de comment on doit écrire dans ces applications. Potentiellement, il faut écrire un endroit bien précis, il faut suivre un format de données qui est très spécifique à l'application. Il y a plus de restrictions. C'est l'un des points qui nous a peut-être un petit peu bloqués. Dans cette stratégie. Et aussi, on s'est rendu compte, un peu comme dans le sac, il y a des outils qui sont faits pour ça, en fait.

54:23 Donc, on a des partenaires qui travaillent que sur ça, qui font que du reverse ITL. Et en fait, on s'est rendu compte qu'il fallait mieux qu'on se... Pour tirer des données ou pour en écrire des données. Donc du côté, on va dire, extraire des données de ces applications, ça reste assez simple. Et après, quand on l'écrit dans les webhats, on a ce système un peu d'écrire des données brutes. Du coup, on n'a pas trop de restrictions sur la façon dont on écrit dans les webhats. Donc lire et écrire, C'est évidemment notre métier, donc on considère que c'est simple. Mais aller dans l'autre sens, c'est beaucoup plus compliqué. Il y a plus de restrictions au niveau de comment on doit écrire dans ces applications. On se concentre sur ce qu'on sait faire. Développer, parce qu'évidemment, il y a un nombre de sources qui n'arrêtent pas de s'agrandir. Donc, plutôt être fort sur maintenir le plus de sources possible pour pouvoir permettre à nos clients d'utiliser un outil pour toutes les sources et travailler avec des partenaires pour aller dans le sens inverse. Ok, merci beaucoup Julien. Je tenais à ce qu'on reboucle là-dessus parce que pour moi ça rebondissait sur cette histoire d'iceberg qu'on a eu en introduction. Parfois, les métiers, ils se disent, vous êtes venu chercher de la donnée, ça doit être absolument aussi facile de réinjecter de la donnée derrière. On ne voit pas la difficulté, on ne voit pas pourquoi ça prendrait du temps, etc. Donc là aussi, il y a un travail de pédagogie à faire parce qu'en effet, ce n'est pas si simple. Donc, comme promis, je propose que chacun en essaye de proposer une leçon en une phrase pour conclure ce MUTEP. Thomas, tu veux donner la tienne?

55:28 Oui, moi je vais continuer un peu sur ce que je disais, c'est vraiment prendre le temps de considérer sa plateforme d'attaque comme une plateforme et de l'architecturer en tant que telle, au-delà des considérations techniques de produits, de sources, de use cases qui vont évoluer, qui vont être portées par cette plateforme dans le futur. Génial. Julien, pour toi, la chose à retenir? Pour moi, il y a des choses très intéressantes qui peuvent être faites, comme l'intelligence artificielle, le machine learning, tous ces aspects sont super intéressants, et c'est normal qu'on soit très intéressé par ça. Par contre, il ne faut pas mettre la charrue avant le but, il faut avoir d'abord un stack qui nous répond à des questions sur des choses qui se passent déjà. Pour pouvoir ensuite aller à l'étape d'après et vraiment avoir un data-driven stack. Super. Et moi, pour ajouter ma petite touche, je dirais que ce qu'il faut bien réfléchir, c'est les compétences, les méthodes.

56:30 qu'on va avoir dans notre équipe face à cette architecture. Il n'y a pas, pour moi, une architecture parfaite ou une équipe parfaite. Il faut partir de ce que viennent dire Thomas et Julien, partir des besoins métiers, construire une architecture qui a du sens par rapport à ses besoins et mettre les bonnes personnes en face. Si on a peu de gens ou si on ne peut pas recruter toutes les spécialités, on va peut-être aller sur des solutions. Plus managées, plus coûteuses, mais qui nous évitent un recrutement nécessaire. À l'inverse, sur des plus grosses équipes, on peut se permettre plus de in-house, plus de customisation, etc. Mais vraiment, encore une fois, avoir une démarche proactive et ne pas subir la construction de son équipe et de sa stack, mais décider d'où on veut aller. J'espère que ce meet-up vous a plu. Il n'y a pas eu beaucoup de questions, mais si vous avez envie d'approfondir l'un de ces sujets ou si vous avez gardé vos questions pour vous, on se retrouve sur les tables de networking sur lesquelles vous êtes tirés automatiquement à la clôture du meet-up.

57:33 Et j'ai cru qu'il y avait une demande pour avoir exactement cette slide, mais avoir les noms des outils, pas juste leur logo. C'est vrai que ça, du coup, c'est un peu réservé aux initiés. Et on va essayer, je pense, de vous construire ça avec Thomas et Julien et de revenir vers vous. Merci à tous. Merci Thomas. Merci Julien pour cette prise de parole. C'était super. On se retrouve sur les tables.