Luko choisit Snowflake comme pivot central pour sa stratégie data

0:02 Et bien maintenant, nous accueillons Julien Gigoi, qui est Chief Actuary Officer chez Lupo, et qui va nous expliquer pourquoi il a fait le choix de Snowflake pour l'exploitation de ces données. Il discutera également de ses bonnes pratiques. Bref, plein de conseils intéressants pour vous. Bonjour Julien, Johan Zervi, bonjour à tous. Je suis responsable commercial chez Snowflake et merci Julien de nous rejoindre. Avant peut-être de démarrer l'échange sur la data, ça va nous animer pendant les 20 prochaines minutes, est-ce que tu pourrais te présenter Julien pour les personnes qui ne te connaissent pas encore et peut-être présenter l'activité de Luko? Oui, merci Johan de m'avoir invité. Bonjour à tous. Alors, je m'appelle Julien Gigoi, je suis Chief Actuary chez Luco. Luco, aujourd'hui, c'est la première néo-assurance en France avec plus de 100 000 clients. On est à l'Incherté qui connaît la plus forte croissance en Europe. L'objectif de l'UQO, c'est vraiment de réinventer l'assurance habitation et notamment de mettre au cœur de nos priorités la responsabilité sociale et la prévention.

1:11 D'un point de vue plus personnel, je suis chief actuary, donc je m'occupe de tout ce qui est assurance, activité d'assurance chez nous. Est-ce que tu pourrais nous représenter un petit peu l'organisation de Luko? Je sais que tu m'avais présenté l'organisation la dernière fois qu'on avait échangé avec les différentes tribes, je trouvais ça intéressant. Et comment tu positionnes peut-être le dispositif? que tu animes toi autour de la BI, en fait, de mémoire et de transverse, j'aimerais bien que tu reviennes sur ces points. Très bien. Donc, LUKO, comme beaucoup de startups, s'appuie sur énormément de gens à côté tech, des devs, et on est full agile. Donc, du coup, notre organisation, elle est par ce qu'on appelle chez nous des tribes. Donc, on va avoir une tribe qu'on appelle Grows, qui va générer la croissance, une tribe NPS pour la satisfaction du client avec toutes les opérations à l'intérieur. Une tribe chez nous, qui est très à part, qu'on appelle Protect. En fait, on est en train de développer nous-mêmes de l'IoT pour pouvoir rendre des services à nos clients et mieux faire de la prévention.

2:21 Ensuite, on va avoir une tribe central dans laquelle on va notamment trouver mon équipe, l'assurance. C'est assez marrant de voir que finalement, aujourd'hui, on vend quand même principalement de l'assurance chez Nuko et finalement, l'assurance est une petite tribe parmi d'autres dans notre organisation. Au niveau de la data, on a voulu avoir une orgue transverse. Du coup, on va trouver des analystes data au sein de chaque tribe et on va avoir une guild data. On se réunit, là c'était juste avant, on se réunit au moins une fois par semaine. On a en moyenne deux, entre deux. une et deux personnes par tribe qui font de la data analyse. Et on se réunit une fois par semaine pour se coordonner et vérifier qu'on a tous les mêmes outils, la même méthode de travail. Excellent. Et alors, comment vous différenciez un petit peu de vos concurrents? Parce qu'il y a l'ancien monde et il y a le nouveau monde avec des acteurs comme LUKO. Alors, nous, on est full cloud.

3:25 Notre méthode de fonctionner est ultra collaborative. Et surtout, notre objectif, c'est d'être complètement data-driven. Et donc, le rôle des analystes data, c'est à la fois de créer des analyses que les gens du business n'ont pas le temps, peut-être même parfois la capacité aussi de faire, parce qu'on va relativement loin dans les analyses, mais aussi d'être capable de délivrer, d'apporter de la data à tout le monde pour qu'il n'y ait aucune décision qui soit prise sans data derrière. Et donc, en fait, l'enjeu, il est vraiment de démocratiser l'usage de la data, de rendre la data facile et de l'apporter sur un plateau aux utilisateurs finaux. Nos clients finaux, finalement, quand on fait de la data, ce sont les gens de l'entreprise. C'est la personne qui va piloter l'acquisition, qui va, comme moi, par exemple, piloter la tarification ou des choses comme ça. D'accord, ok. Super. Et si tu peux juste nous rappeler un petit peu le contexte qui t'a amené, parce qu'on échange depuis maintenant un peu plus d'un an, et je me souviens que tu n'étais pas encore arrivé, tu étais en cours en fait.

4:30 D'arriver. Exactement. D'arriver chez LUKO. Est-ce que tu peux juste nous rappeler un petit peu le contexte et pourquoi vous avez décidé de mettre Snowflake au sein de LUKO? Oui, alors l'idée, c'est que moi, j'ai eu la chance d'arriver chez LUKO. Sur un terrain vague quasiment, il y avait beaucoup de choses qui avaient été faites et déjà on commençait à très bien collecter la data et à très bien l'utiliser, mais c'était fait un peu en silo. Et donc l'objectif, Moi, quand je suis arrivé, ça a été de créer une utilisation de la data qui soit partagée par tout le monde, très collaborative et donc de casser les silos. C'était vraiment l'objectif de départ et c'est pour ça qu'on a choisi Snowflake. Pour nous, l'objectif, c'était d'avoir une plateforme unique dans laquelle on allait pouvoir intégrer l'intégralité de toutes nos sources de données, que ce soit des sources de données propriétaires, parce que chez LUKO, on a des ambitions assez élevées, on veut vraiment complètement changer la façon de faire de l'assurance habitation, et donc on développe tous nos outils internes, ce qui veut dire que tous nos outils de gestion des contrats, des sinistres, des choses comme ça, sont développés chez nous.

5:41 Donc ça va être des bases de données qui sont propriétaires, on va toutes venir les dispatcher à l'intérieur de la plateforme de data unique, qui est donc Snowflake. Mais on va aussi avoir des plateformes qui vont être un peu plus standardisées. C'est très bête, mais par exemple, on va avoir, le truc le plus bête, ça va être du Google Sheet. On va avoir, par exemple, je ne sais pas si je peux citer des noms, mais Intercom, qui est notre outil pour faire du chat. Et en fait, pour toutes ces choses-là, on va passer par des intégrateurs. Je crois que j'ai le droit de dire les noms, donc on utilise Fivetran chez nous. Avec qui ça fonctionne vraiment super bien. Fivetran a des connecteurs qui sont mis à jour en permanence, ce qui fait qu'en fait, en cinq minutes, mais je ne rigole pas, en cinq minutes, j'avais toute la data d'Intercom dans Snowflake et je pouvais la piloter. Et je pouvais faire tous les tableaux de bord que je voulais. Parce que j'ai branché Fivetran. Et Fivetran, j'abuse 5 minutes de travail. Je crois que ça a mis une heure le premier load. Et une heure après, j'avais toute ma data dans Snowflake. Et donc, du coup, dans Snowflake, on va retrouver vraiment l'intégralité de la data.

6:44 Il n'y a pas une data chez nous qu'on va utiliser qui ne va pas être dans Snowflake. Et donc, in fine, tous les gens de ma guild BI vont avoir un accès à Snowflake et on va tous pouvoir travailler dans le même univers. Et effectivement, il y a Fivetran qui est l'ETL, ce que tu appelles intégrateur, mais c'est un ETL, voire même un ELT, je crois. Quels sont les autres outils que tu utilises d'ailleurs, si tu peux un petit peu exposer? En fait, c'est presque de l'EL, Fivetran chez nous, parce que ma vision assez personnelle des choses, c'est que je veux un outil centralisé pour la partie transformation de la data, et en l'occurrence, c'est Snowflake. Et donc, du coup, comment ça fonctionne? On va avoir plein de bases de données un peu partout, comme je l'ai dit. On va toutes les passer par Fivetran pour faire l'EL, donc l'extraction et le load dans Snowflake. Une fois que les datas sont dans Snowflake, on les stocke au format prod, si je peux dire, donc le format de base, et on va les transformer.

7:44 Pour les transformer, on va utiliser du code sous Snowflake. Le processeur, ça va être le processeur de Snowflake, mais on va piloter les codes de Snowflake via dbt. L'intérêt pour nous de travailler par DBT, c'est qu'on veut encore une fois faire du travail collaboratif et donc ça nous permet de travailler sous Git en étant avec DBT et donc d'avoir un espace de travail, de pouvoir faire chacun sa branche, merger sur la branche de prod, etc. Donc, c'est ultra pratique. En m'entendant parler, je me rends compte de tout le chemin parcouru. Moi, je suis actuaire, je n'avais jamais fait ça de ma vie, je ne suis pas du tout un dev. Et en un an, je suis capable de parler comme ça. C'est assez dingue pour moi. Et ça vient juste du fait que j'ai pris des outils qui sont très, très simples à utiliser. Et donc, pour finir, dans Snowflake, on va avoir à la fois toutes les bases de ce que j'appelle de prod. On va les transformer pour créer ce que j'appelle un data mart.

8:45 Donc, dans le data mart, en fait, on va avoir des tables qui vont contenir les datas de la prod, mais dans un format différent. Avec parfois des nouvelles colonnes, parfois des colonnes enlevées, parfois des colonnes reformatées, des observations qui vont être un peu transformées. L'objectif d'avoir le Data Mart, c'est que le Data Mart contient un format qui est directement utilisable par les utilisateurs. Et en gros, du coup, on va brancher un outil de data vise qui est chez nous, Looker, directement sur le data mart. Et du coup, c'est très, très, très facile derrière de faire des analyses parce que le cœur, c'est ultra intuitif. C'est l'objectif. Et du coup, si on met le cœur entre les mains de gens qui ne sont pas des data analystes, mais si on a fait un bon data mart derrière et qu'on a bien documenté le cœur, n'importe qui est capable de faire son travail. Pour ceux qui sont un peu moins tech, c'est comme si je vous donnais un fichier Excel avec un énorme tableau croisé dynamique, super bien documenté, et que je vous disais maintenant, tu n'as plus qu'à faire un tableau croisé dynamique. Si je comprends bien, d'ailleurs, de nos derniers échanges, au final, c'est tout le monde qui est branché sur Looker, peu importe le rôle, que ce soit la tribe call center, la tribe MRR, enfin grosse, tout le monde est branché, donc tout le monde, finalement, se branche via Looker.

9:55 On n'a pas un compte par employé, parce que les comptes Looker, il faut les payer, donc on n'a pas un compte par personne. Il y a des gens qui ont juste besoin d'avoir des rapports statiques. Pour ces gens-là, par exemple, on va exporter des rapports statiques looker, mais effectivement, il doit y avoir un bon tiers des employés looker qui a un compte looker pour pouvoir analyser ce qu'ils ont à faire dans leur ligne de métier. Et donc, du coup, derrière, tout le monde a accès à la donnée et cette donnée est puisée directement, centralisée en tout cas sur Snowflake. Exactement. Tu parlais d'une notion qui était importante tout à l'heure, on ne l'a pas évoquée, mais au final, c'est le time to market, c'est la facilité à mettre en place finalement cette solution. Est-ce que tu as des retours à nous faire sur ton arrivée chez Snowflake et justement la mise en place de cette stack qui est la tienne aujourd'hui, qui est celle de Louco? Oui, je n'ai pas envie de trop comparer avec ce que je faisais avant parce que c'est des outils différents. Mais c'est vrai que moi, mon travail, c'est d'analyser de la data en tant qu'actuaire. Je ne fais que ça. Je passe 100% de mon temps à analyser de la data.

10:57 On dit souvent que le travail d'un actuaire, c'est 80% de son temps à cligner de la donnée et 20% de son temps à l'analyser. C'est assez frustrant. Je pense qu'on comprend assez rapidement qu'il y a un gain de temps assez incroyable à faire. Là, en un an, avec une équipe, alors maintenant, on est huit personnes dans la guild, mais il y en a cinq qui viennent juste de nous rejoindre. Donc, globalement, on a été trois personnes pour monter toute cette pipe. Donc, la pipe, pour moi, c'est Five Tram, Snowflake avec DBT, Hooker. On a été trois personnes, dont des personnes Personne plutôt junior, tu connais Rinal, que je peux citer avec plaisir, et Pilou, qui ont fait tout le projet depuis le début. On n'est pas des data engineers, on n'avait jamais fait ça de notre vie. Comme on dit dans les boîtes, il n'y a personne de l'IT avec nous, on est des gens du business. On nous a donné des outils qui sont en fait ultra faciles à prendre en main. En trois mois, on avait déjà tout dessus. Après, ce qui prend beaucoup de temps, c'est de créer le data mart. Mais le data mart, on le crée une fois.

11:57 Là, c'est parce qu'on est tout nouveau. Mais quand on aura fini de créer le data mart, normalement, la deadline, ça devrait être à peu près la fin du mois. Il y a tout qui roule. Et donc, on s'est vraiment lancé au mois de mars avec Snowflake. Je crois que c'était début mars qu'on a commencé Snowflake. Et en mois de juin, déjà, on avait tous les tableaux de port qui sortaient globalement de Looker et qui nous permettaient de suivre l'activité. Ce n'était pas ultra détaillé, on avait commencé par les priorités, mais aujourd'hui, on a tout à l'intérieur. Donc, clairement, en termes de time to market, je dirais que ça équivaut à ce que j'ai vu dans d'autres entreprises. À trois en un an, on a fait peut-être ce que je voyais faire à cinq en trois ou quatre ans, je dirais à peu près. D'accord, ok. Intéressant. Et alors peut-être la… Oui, vas-y. Je voulais dire, et vraiment pour moi, la révolution, c'est que j'ai souvent bataillé dans mes anciens postes à essayer de démocratiser la donnée et à donner la capacité aux gens du métier

13:00 à faire eux-mêmes le travail de data engineering et de préparation de la data. Parce que finalement, ce sont les gens du métier qui souvent ont des compétences techniques qui sont suffisantes. Il suffit de savoir coder en SQL, il n'y a pas besoin de... Ce n'est pas Rocket Science. Et eux, ils ont les compétences et ces gens-là, souvent, ont la visualisation, ils arrivent à comprendre précisément comment le data mart doit être créé. Et le problème, c'est que dans la plupart des entreprises, les gens du métier vont dire voilà le data mart que je veux et ils vont devoir aller expliquer ce qu'ils veulent à des gens qui, eux, ne comprennent pas du tout le métier. Et donc, du coup, il va y avoir une énorme perte d'information et énormément de pertes de temps à expliquer à d'autres personnes ce qu'ils doivent créer. Alors que là, avec les outils qu'on a mis en place chez LUKO, c'est directement des gens qui ne sont pas des data engineers, ce sont des gens du métier qui ont créé eux-mêmes tous les data marts. Et donc, on a gagné un temps faramineux avec ça. Excellent, excellent. Merci pour le retour. D'ailleurs, justement, en parlant de métier, c'était la question que j'allais te poser. Quels sont finalement les cas d'usage que vous avez mis en place sur Snowflake, en tout cas que vous déployez, ce que tu peux dévoiler évidemment, mais je sais qu'il y a pas mal de choses en fonction des tribes que vous avez déployées.

14:04 Est-ce que tu peux nous en parler? Oui, bien sûr. Comme tu dis, je ne vais pas tout te donner, mais globalement, les premières choses que je regarde, je vais parler de mon équipe très personnelle, la partie assurance. Les premières choses qu'on regarde quand on fait de l'assurance, ça doit être la tarification. Ça va être, pour faire du suivi de tarification, on regarde le pilotage de la conversion. tout simplement pour 100 prospects qui viennent chez nous et qui demandent un tarif, combien convertissent, etc. Et donc là, j'ai un exemple qui est très parlant, parce que je l'ai fait hier soir. Je voulais faire une analyse sur un segment que je n'avais jamais analysé encore. Depuis que je suis arrivé chez LUKO, et puis hier soir, je me suis dit, tiens, je n'ai jamais regardé, et j'aimerais bien voir si sur ce segment-là, les gens qui sont dans les différents clusters ont des comportements différents au moment de la conversion. Et en fait, je l'ai fait en trois secondes. Je l'ai vraiment fait en trois secondes parce que j'avais déjà mappé la data dans mon data mart.

15:11 Ça, ça m'avait pris du temps. Ça m'avait pris peut-être deux semaines de bien créer toute ma base de devis dans mon data mart. Ensuite, deux autres semaines pour préparer des rapports intelligents sur LUKO. Qui fonctionne bien comme il faut. Donc, je dirais que j'avais mis à peu près un mois tout préparé. Et je ne me rappelais pas à quel point j'avais été assez jusqu'au boutiste à l'époque et j'avais tout mappé, tout mappé. Et donc, du coup, hier, je suis allé dans le club. En trois secondes, j'ai pris un rapport qui existait. J'ai changé la variable que je voulais étudier et j'avais mes résultats. Et là où c'est très fort, c'est que c'est quand même des bases de données qui sont assez lourdes. On parle de centaines de milliers de lignes avec des centaines de colonnes quand on regarde les devis. Et en général, pour parler là où je travaillais avant, ça prenait vraiment beaucoup de temps. On était sous SAS, il fallait faire tourner en local. Donc, j'aurais mis au moins deux heures ne serait-ce qu'à faire tourner le code. Et puis, j'aurais dû exporter, refaire l'analyse, remettre dans un joli format en Excel, etc. Hier soir, en fait, c'est comme je disais tout à l'heure. En fait, j'étais devant un tableau croisé dynamique. Ma colonne était déjà préexistante, elle était déjà mise à jour.

16:12 Et j'ai appuyé sur un bouton. Et trois secondes après, j'avais mon tableau avec mes dix colonnes, mes dix lignes et tous mes résultats de performance. Et donc, ça, c'est un gain de temps qui est exceptionnel. C'est-à-dire qu'une fois qu'on a fait l'analyse une fois pour un segment, on peut la répéter. Je peux répliquer. 30 fois qu'on veut. Là, en l'occurrence, je m'envoie des rapports tous les matins qui arrivent dans ma boîte mail automatiquement. Il n'y a plus rien à faire. Enfin, il n'y a plus rien à faire. Il faut le faire une fois. Une fois que c'est fait une fois, ça tourne tout seul. Donc, voilà, ce que j'ai fait, par exemple, pour moi, ça va être aussi mon suivi de profitabilité. Donc, c'est ce qu'on appelle le loss ratio en assurance. C'est très bête. C'est regarder le coût total des sinistres divisé par le crime qu'on a acquise. Et donc, évidemment, on n'a pas envie d'avoir des segments sur lesquels on a plus de sinistres que de primes. Ça veut dire que sinon, on perd de l'argent. Et donc, il faut continuellement essayer de segmenter le portefeuille pour voir s'il y a une poche de clients sur laquelle on s'est trompé, on a mal tarifé. Et donc, il faut en permanence chercher des nouvelles interactions, chercher des nouveaux segments.

17:16 Et ça, ça prend du temps parce qu'encore une fois, il y a beaucoup de lignes, beaucoup de data, c'est souvent des gigas. Et là, en fait, là, c'est quelques secondes. Le rapport est préparé. Je change ma segmentation. Quelques secondes, ça se rafraîchit. Je peux l'étudier. Et non seulement c'est un gain de temps, mais ça crée aussi des opportunités qu'on ne fait pas. C'est-à-dire que je parle par expérience, si on n'a pas l'opportunité de faire ces analyses très rapidement, en quelques secondes, en fait, on va s'auto-censurer, on ne va pas les faire. Parce qu'on sait que ça va prendre un jour de juste faire tourner un truc pour voir une interaction et on ne va pas la faire. Donc, c'est très intéressant d'avoir ça. Un outil, un cas d'usage aussi qu'on fait, comme beaucoup de startups, là, je pense que ce n'est pas en vrai. lien avec l'assurance et qu'on va piloter notre acquisition. Donc, on a créé des modèles de lifetime value. Donc, on est capable aujourd'hui de savoir quand un client signe chez nous, quelle est la valeur attendue sur la durée de vie qui va avoir chez LUKO. Donc, on est aussi capable, plus ou moins bien, mais quand même plutôt bien, de...

18:21 forecaster, désolé pour les mangards, mais de prédire la lifetime value d'un prospect avant qu'il signe chez nous. Et donc, on va être capable de dire combien je suis prêt à bider sur ce prospect-là pour l'avoir chez moi. Et donc, du coup, on va pouvoir piloter l'acquisition comme ça pour s'assurer qu'on va avoir en permanence un bon ratio de coûts d'acquisition sur la lifetime value. Très intéressant. Très intéressant, merci beaucoup. On arrive sur la fin de l'interview. J'avais juste deux, trois petites questions. La première, c'est par rapport à la sécurité. Il y a un grand jeu de la sécurité autour des solutions cloud. Quel est le feedback que tu as à nous communiquer par rapport à Snowflake? Et je sais que c'est important aussi, évidemment, pour vous, la sécu. Est-ce que tu as des... On est en plein dedans, on a eu la chance d'avoir quelques contrôles ce mois-ci de la part du régulateur français qui se sont en plus très bien passés parce qu'on a, grâce à Snowflake, on a tout centralisé. Donc, qui dit centralisé dit qu'il n'y a qu'une seule source à aller vérifier, à aller cliner en termes de data personnelle, là en l'occurrence.

19:28 Encore une fois, pour moi, l'avantage, C'est que Snowflake met à disposition de noobs, si je peux me permettre de m'appeler comme ça, tout ce qu'il faut. Et donc, nous, quand on a créé Snowflake, on a créé des rôles. Donc, on peut donner accès, mais c'est quelques clics. Je crée des utilisateurs et je donne des rôles à chaque utilisateur. Et je définis les rôles en disant ce que tu as le droit de voir ou ce que tu as le droit d'écrire. Et voilà, c'est fini. Évidemment, il y a un whitelisting. d'adresse IP. Donc, en fait, on est obligé d'avoir l'adresse IP de Luko pour pouvoir se connecter à la data. Ce qui fait que les gens qui ne sont pas en VPN ne peuvent pas accéder à la data. Donc, on ne peut accéder à la data que si on est chez Hugo. Et encore une fois, même si on a la bonne adresse IP, il faut avoir le bon rôle pour pouvoir accéder à la data. Donc, c'est très simple. Ça a pris, bon allez, il fallait comprendre une demi-journée à comprendre un peu comment Snowflake fonctionnait là-dessus. Et après, c'était terminé. Donc, très, très sécure. Et surtout, encore une fois, très facile à faire pour des gens qui ne sont pas de ce métier-là.

20:29 Super, excellent. Dernière question pour moi, c'est comment tu vois l'avenir, à la fois chez Luko et à la fois avec Snowflake en termes d'usage? Comment tu vois la suite? Cette interview est préenregistrée, mais je pense que le jour où elle sortira, la nouvelle levée de fonds de Luko sera déjà publique. Avec cette levée de fonds, vous avez peut-être entendu parler, chez Luko, on voit l'avenir de façon très positive et on est ravis d'avoir réussi à convaincre des partenaires de nous faire confiance pour changer le monde de l'assurance et apporter des services qui n'existent pas aujourd'hui et transformer tout ça. Chez Luko, l'avenir est plutôt bon et en tout cas, on continue d'avoir beaucoup d'énergie et de motivation pour changer le monde de l'assurance. Nous, clairement, on est très satisfaits de notre pipe data.

21:30 Je pense qu'on est tranquille pour plusieurs années avec ça. Ce qu'on aimerait bien réussir à faire aujourd'hui, c'est intégrer un maximum de sources de données complémentaires à l'intérieur de Snowflake. L'avantage qu'on a aujourd'hui, c'est qu'il y a déjà pas mal de connecteurs qui sont déjà natifs dans Snowflake, qui nous permettent de connecter directement la data. Il y a une option que personnellement, j'ai commencé à regarder, qui m'intéresse, mais là, je pense que je vais avoir besoin de temps parce que c'est beaucoup d'analyse. Moi, j'ai commencé à regarder un peu la data marketplace et j'ai vu par exemple que dessus, on pouvait trouver plein de données météorologiques. Et qu'on pouvait du coup les intégrer directement dans notre base Snowflake. Or, c'est assez évident que quand on fait de l'assurance habitation, les données météorologiques vont nous intéresser. Et donc voilà, de savoir qu'on va pouvoir récupérer directement ces datas-là sans avoir besoin de recoder des choses et que ça va être natif au bon format, automatisé, etc. Ça va être très pratique. Donc ça, c'est le premier point qu'on va faire.

22:32 Alors là, ça va plutôt être, je pense, côté data science que AI. Et la deuxième chose que j'aimerais, c'est en tant qu'assureur, on a beaucoup de partenaires avec qui on travaille et on a beaucoup de partage de données à faire. Parce que parfois, on n'est pas tout seul sur un contrat, on porte le risque avec d'autres personnes, on a des réassureurs, etc. Et donc moi, j'essaie de pousser au maximum. mes partenaires assuranciels à utiliser Snowflake pour pouvoir faire du data sharing. Alors, je sais qu'on peut le faire même sans qu'ils soient partenaires, mais par raison de simplicité, comme je sais qu'ils sont intéressés par le petit Snowflake, tu sais de qui je parle, j'essaie de les pousser parce que l'idée, ça serait même plus besoin d'avoir d'envoyer des fichiers par FTP ou quoi que ce soit et directement avoir comme un petit serveur partagé via Snowflake sur lesquels tu peux aller pousser de la data une fois par semaine, une fois par mois, voire tous les jours d'ailleurs.

23:33 Et eux, ils arrivent à l'intégrer directement dans leur base de données. C'est directement sur le cloud, il n'y a pas besoin de faire un transfert de data. Donc ça, c'est les deux outils que Snowflake a et qu'on va avoir envie de pousser dans les prochains mois. Il y a la partie data science dont je n'ai pas trop parlé, mais je préfère ne pas dire trop de népsie. J'ai Joseph chez moi qui est le master en data science, en machine learning, qui utilise beaucoup Snowflake déjà. Et je suis sûr que tu seras ravi de l'inviter un autre jour. On arrive à la fin de l'échange. Merci à tous de nous avoir regardés. Et la session de Q&A va suivre dans quelques minutes.