← BibliothèqueToutes les vidéos
Meetup Tech.Rocks
Construire un écosystème collaboratif autour de la donnée
- François Aubert (CTO & Co-founder, Pricemoov)
- Hugo Woog (Senior Sales Engineer, Snowflake)
Meetup Tech.Rocks · 2 juin 2022 · 43 min · en français
Résumé
Replay du meetup Tech.Rocks du 2 juin 2022, co-construit avec Snowflake, consacré à la collaboration autour de la donnée. Il présente comment le Data Cloud Snowflake sert de fondation à un écosystème collaboratif autour de la donnée, et comment Pricemoov en tire parti au service du pricing.
Summary
Replay of the Tech.Rocks meetup of 2 June 2022, co-organised with Snowflake, on data collaboration. It shows how the Snowflake Data Cloud serves as the foundation of a collaborative data ecosystem, and how Pricemoov uses it for pricing.
Thèmes : Data
Transcript complet
Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.
Merci beaucoup, Noémie, pour l'intro. Je vais enchaîner avec une petite intro et puis la présentation. Pour compléter ce que disait Noémie, si vous voyez bien mon écran, mon rôle, c'est d'accompagner les entreprises françaises, plus précisément la French Tech, dans les bonnes pratiques data autour de Snowflake. Et je suis accompagné aujourd'hui de François Aubert, je vais dire quelques mots. Bonjour à tous, ravi d'être présent aujourd'hui. On se retrouve juste après la présentation de Hugo. Super. Le point de départ ici, c'est qu'on parle de data collaboration. Mais pourquoi est-ce qu'on en parle? On en parle parce qu'il y a une opportunité business. Donc, on est entre personnes techniques, mais finalement, on est au service du business. Et donc, c'est ce que cette étude relève ici, ce qui est une opportunité de croissance à mieux collaborer autour de la donnée pour toutes les entreprises pour lesquelles vous travaillez.
Mais quand on pense à data collaboration, le premier point, c'est finalement quelles sont les sources de données externes qu'on utilise. C'est une première façon d'y penser. Ça peut être pour les entreprises d'utiliser des données, par exemple, de météo. Ça peut être d'utiliser des données démographiques, essentiellement utiles aux équipes marketing, des données de tendance économique pour les corréler aux évolutions de votre business, ou toutes données finalement que les data scientists ou votre équipe data seraient friands d'utiliser pour enrichir leur modèle et avoir un petit peu plus de matière sur laquelle travailler. Quand on pense à ces datas-là, aujourd'hui, il y en a certainement beaucoup que vous utilisez, mais beaucoup d'autres aussi que vous n'utilisez pas ou que partiellement. Donc, ce n'est pas pourquoi, parce que finalement, vous ne l'utilisez pas ou peu. Ce qui revient souvent de la part de nos clients, c'est que c'est soit trop cher, soit trop complexe, ou que vous n'avez pas les ressources pour les récupérer. Ou tout simplement que vous ne savez pas où aller les chercher.
Ensuite, ces données-là, une fois que vous y avez accédé, souvent vous devez les rendre aussi, ou les rendre accessibles, ou donner accès simplement à des partenaires ou à vos clients. Donc simplement, est-ce que vos clients sont friands d'accéder à vos données? Est-ce qu'ils peuvent facilement le faire? Est-ce que vous êtes en mesure de leur donner accès à vos données? Et quels seraient les bénéfices business si vous, demain, vous étiez en mesure de plus facilement répondre aux demandes du métier autour de donner accès à ces données à vos clients ou partenaires externes? Le point central entre la récupération de données externes ou donner accès à des parties tiers de la donnée, c'est un problème, le problème qui est que toutes ces données sont silotées. Donc, les sources, elles peuvent être web, elles peuvent être dans des systèmes on-premise, dans des applications, dans le cloud, dans des cloud providers différents ou dans des régions différentes.
Vos clients, pareil, ils ont leur propre application, leur propre cloud. Et finalement, c'est le fait que ces données soient dispersées dans tous ces lieux qui empêchent de réaliser la valeur, justement, que je vous ai partagé dans l'étude tout à l'heure. Ça ne veut pas dire que vous n'essayez pas aujourd'hui d'en tirer de la valeur. La preuve, vous mettez en place des mécanismes de récupération de la donnée, des méthodes qu'on qualifie peut-être de traditionnelles, comme des FTP, des API, des pipelines de TL, ou des mécanismes de partage de données au sein d'un cloud provider. Le problème avec ces méthodes-là, c'est qu'elles ne sont pas toujours facilement sécurisables ou sécurisées, qu'elles demandent beaucoup d'énergie à mettre en place, soit du scripting, soit de la maintenance de pipeline. Elles sont assez manuelles. Elles ne correspondent pas toujours à la fraîcheur de la donnée qui est nécessaire au business. Certaines décisions ont besoin d'avoir de la donnée extrêmement fraîche, d'autres au moins. Ces méthodes-là ne sont pas toujours en phase avec ces attentes.
Et puis aussi, bien sûr, des considérations de protection des données qui aussi empêchent ces méthodes finalement de répondre aux besoins initiaux. La réponse qu'on apporte chez Snowflake humblement, c'est un réseau de données qui s'appelle le Data Cloud. Il y a un réseau de données qui rassemble des milliers d'organisations pour collaborer autour de leurs données. Ça peut être une société de logiciels qui va permettre de donner accès aux données de son logiciel à ses clients facilement. Ça peut être des données de santé qui sont accessibles par des entreprises. du monde entier pour comprendre comment une épidémie peut être corrélée à leur business, comment des données macroéconomiques de vente dans un pays plutôt qu'un autre peuvent leur aider à s'implanter dans un autre pays ou à comprendre quel serait l'impact de leur développement, ou simplement des entreprises de collaborer autour de la donnée, par exemple un retailer avec ce supply, étant un exemple assez classique. Ce réseau de données global, il n'est pas né du jour au lendemain et il continue à se développer extrêmement rapidement.
Sur la visualisation que vous voyez là, je ne l'ai pas présentée juste avant, mais je vais le faire maintenant. Vous voyez l'évolution entre avril 2020 et avril 2022 de ce réseau qui se manifeste ici sur cette visualisation par un point étant un compte Snowflake et un trait étant un accès régulier à la donnée entre ces deux comptes. Donc là, on voit qu'il y a de quelques centaines d'organisations et quelques centaines d'accès réguliers. On passe à quelques dizaines de milliers maintenant en avril 2022. Quels sont les bénéfices clés d'adhérer à ce réseau pour vous ? Le premier, c'est que finalement, l'accès à la donnée, il est grandement simplifié. Les données, dès qu'elles sont disponibles chez le fournisseur, par exemple dans votre compte, tous les acteurs de votre écosystème dans ce réseau peuvent bénéficier directement de cette donnée fraîche. Il n'y a pas besoin de mécanisme d'ETL pour qu'ils en bénéficient comme vous. Et ça se fait quel que soit le cloud, quelle que soit la région.
On est bien conscient que vous tous, ici présents, vous avez tous des prérequis ou des besoins de cloud différents. C'est pour ça que ce réseau, lui, il est agnostique finalement de l'infrastructure qu'il a sous temps. Ensuite, ce n'est pas seulement des données brutes ou des données raffinées, ou quelles que soient les données que vous voulez mettre à disposition, auxquelles vous voulez accéder. Ce sont aussi des services autour de la donnée. Pricemoov, par exemple, on en parle un peu plus précisément tout à l'heure, mais on est un très bon exemple. Ils fournissent de la donnée qui a été extrêmement enrichie, dans laquelle une forme d'intelligence a été appliquée pour ensuite délivrer plus que de la donnée brute, mais une réelle information qui ajoute de la valeur à votre business. Et puis, le troisième exemple qu'on retrouve aussi au sein de ce réseau, c'est donc des applications. Par exemple, des algorithmes de machine learning sur différents applicatifs auxquels vous pouvez directement accéder sur ce réseau, encore une fois, sans avoir au souci de l'infrastructure, du cloud, mais simplement
accéder à cette donnée et en retirer tous les bénéfices que vous voulez. Et cela, ça se fait quand même avec une considération de contrôle, bien sûr, en tête. Sans cela, ce serait l'anarchie. Donc, le Data Cloud, c'est un réseau qui est gouverné. Vous accédez à cet ensemble de données auxquelles des mesures de sécurité techniques peuvent être appliquées, comme par exemple du filtrage à l'aiding, aux colonnes, ce qui vous permet ensuite de filtrer dynamiquement les données qui vont s'afficher suivant le compte ou l'utilisateur ou le rôle qui va y accéder. Toutes les opérations qui sont effectuées, encore une fois, qu'elles soient effectuées au sein de votre compte ou par un compte tiers, sont toutes auditable, monitorées, de sorte que vous puissiez garder la visibilité sur ces accès. C'est le deuxième pli de la gouvernance, après le contrôle, l'audit. Comment est-ce que ce réseau a été rendu possible ?
C'est grâce à la combinaison d'une plateforme data, une base de données cloud, ici pour l'ensemble des usages de la data. Je ne vais pas rentrer dans les détails aujourd'hui, mais n'hésitez pas d'ailleurs à poser vos questions dans la partie Q&A. Ensuite, après cette présentation, il y aura aussi un petit breakout où dans les différentes pièces virtuelles, on aura l'occasion d'échanger si vous avez des questions sur cette plateforme. Mais c'est bien entendu aussi des données. Un parallèle que je peux faire, c'est comme le site Amazon, c'est un site Internet qui fonctionne, mais c'est aussi tous les objets du monde auxquels vous voudriez accéder. Finalement, le Data Cloud, c'est un peu ce qu'Amazon au retail, au e-commerce, mais appliqué à la data, c'est la combinaison d'une plateforme et des données. Comment est-ce que vous pouvez accéder aux données si demain vous avez un compte Snowflake ? Vous pouvez aller récupérer les données de la Marketplace. C'est un ensemble de datasets qui sont disponibles publiquement pour tous les clients.
Un peu plus de 200 providers ici et plusieurs centaines de datasets. Vous pouvez aller donner accès à la donnée à un de vos partenaires qui est sur Snowflake aussi, créer un espace. dans lequel plusieurs comptes peuvent accéder à une même donnée, même donner accès à un de vos partenaires qui n'est pas forcément sur Snowflake, un compte managé, ou enfin faire ce même partage de données, mais cette fois-ci sans révéler la logique ou les données en elles-mêmes, mais simplement en les croisant avec vos données de votre partenaire. Pour révéler simplement des données qui leur sont pertinentes sans compromettre la protection des données ou la privacité des données que vous détenez. Ça, ça s'appelle la clean room. C'est un sujet qui mérite d'être creusé. Si ça vous intéresse, on peut en parler plus amplement, comme je le fais régulièrement avec nos clients dans les médias. Je voudrais vous donner ici un simple exemple technique, puisqu'on est entre personnes en charge de la data, technique plus globalement.
Ici, c'est simplement pour illustrer le fait que donner accès à la donnée à un parti tiers, à un compte externe à Snowflake, c'est finalement le même mécanisme, aussi simple que de le faire dans Snowflake. Ici, par exemple, c'est une vue sécurisée où à droite, vous voyez une table de faits, donc simplement des ventes avec des produits et un client auquel appartient, un fournisseur auquel appartient ces produits. Et à gauche, vous voyez une table… je n'ai pas le nom en français, dans TechTomut, on va dire, qui associe ce produit avec le compte, finalement, Snowflake, le nom du compte Snowflake de ce fournisseur. Pour faire en sorte que quand un de ces fournisseurs-là va accéder à la table de faits, et ainsi ce qu'on veut, c'est qu'il voit seulement les produits qui ont été vendus et qui lui sont associés. Pour ce faire, pas besoin de hard-coder finalement certains items ou de séparer une vue ou une table dans différentes vues, comme des data marts qu'on aurait fait traditionnellement.
Ici, on fait simplement une vue sécurisée qui va filtrer sur cet item Customer ID. Et ensuite l'associer au current account. Donc le current account étant la variable qui va récupérer le nom du compte du parti tiers qui accède à la donnée. Donc, c'est complètement transparent pour eux. Ils ont accès à une vue. Mais ensuite, quand ils requêtent Select, disons, sur cette vue-là, ils ne verront que les lignes qui leur sont pertinentes grâce à cette logique. Et ceci, ça se fera dynamiquement pour toutes les données qui vont être ajoutées au fil du temps. Enfin, pour clôturer avant de passer la main à François, je voudrais simplement illustrer le fait que ce réseau de données-là, il s'est verticalisé. Donc aujourd'hui, nos entreprises, au sein par exemple de la verticale finance, mais aussi assurance, par exemple, pour nous citer qu'elle, Échange pour partager des données qui leur sont très spécifiques.
Ça peut être des données de marché pour permettre aux entreprises de financement de mieux comprendre des dynamiques qui vont les inciter à investir dans telle ou telle entreprise ou justement à ne pas le faire. Ça, c'est un premier data cloud dans le système financier. Mais on retrouve la même chose avec des données très spécifiques au système de la santé et de la recherche. Donc, par exemple, comme des fournisseurs comme le Star Schema ou alors Iqvia, qui fournit des systèmes dédiés justement au système de santé, ou simplement les entreprises qui opèrent dans ce domaine-là, qui sont toujours friandes, comme Siemens, Athena Health, d'avoir des partenaires avec qui elles peuvent facilement changer de la donnée. au sein du data club. Dans le domaine des médias et de la publicité, le driver finalement aujourd'hui, pour l'évoquer brièvement, c'est la dépréciation des coûts qui tirent ce parti, qui les invite à compter davantage sur les données first party pour finalement fournir de la valeur aux éditeurs et aux publisheurs pour leur permettre de...
Mieux cibler leur publicité. Et ça, ça se fait typiquement sur un certain nombre d'acteurs que vous voyez listés ici dans le monde. Mais encore une fois, sans pour autant compromettre la prévisité des données force party qui leur ont été confiées. Le retail, c'est aussi un domaine qui est en essor en termes de la collaboration. C'est un des premiers cas d'usage qui a été mis en œuvre. C'est entre les retailers et les fournisseurs, ou les CPGistes, où ces CPGistes-là, les Coca-Cola et consorts, veulent connaître des Sainsbury, Monoprix, Casino, comment leurs clients, les clients des retailers, consomment leurs produits et qui ils sont. C'est à ces questions que le data sharing Snowflake a permis à ces retailers, à ces CPGistes, de répondre. Mais ces logiques de Customer 360, de personnalisation ou d'optimisation de la supply chain, ce ne sont que des use cases parmi d'autres qui sont mis en œuvre sur la plateforme.
Un autre use case de data collaboration qui était mis en œuvre sur le data cloud, c'est le pricing. Et qui de mieux pour en parler que François Aubert, CTO de Pricemoov. À qui je vais maintenant laisser la main. Merci Hugo pour cette présentation. Je crois qu'il y a une question sur... Alors, comment fonctionnent les clean rooms? Alors, je ne sais pas si je peux répondre à cette question. Yeah. Je vais y répondre brièvement, parce qu'encore une fois, c'est un sujet qui mérite d'être creusé. Mais les clean rooms, c'est une combinaison de la technologie data sharing Snowflake, qui permet facilement d'accéder à la donnée entre deux comptes, entre deux entreprises distinctes, et de script, qui permet d'intégrer de la logique pour faire du matching de données, donc matcher les données qui sont chez un éditeur et chez un publisher, sans pour autant révéler la liste complète, c'est forcément toutes les données first party qui sont chez un parti ou chez une entreprise ou l'autre.
Donc, une combinaison de notre technologie fournie Snowflake et de Data Sharing et de Script. Peut-être que je vais te laisser poursuivre, François, et je répondrai peut-être aux questions dans le chat au fur et à mesure. Parfait. Écoutez. Bonjour à toutes et à tous et merci d'être présents. Je vais commencer par me présenter. François, je suis CTO et cofondateur de Pricemoov. Donc Pricemoov, société créée en 2016. Je vais vous parler aujourd'hui de comment nous collaborons autour de la donnée avec des clients et des partenaires, notamment via Snowflake. Alors peut-être pour dire deux mots sur ce qu'on fait, on s'est créé en 2016 dans l'optique de proposer à nos clients une solution qui leur permette d'être plus simplement au pricing. Il faut savoir que le pricing est un sujet complexe, qui est très difficile à appréhender. Beaucoup d'entreprises le gèrent via Excel, et nous on se place comme solution technologique pour leur permettre trois choses.
La première, c'est de les aider à stocker les prix de manière intelligente, de pouvoir diffuser ces prix-là sur des canaux digitaux. La deuxième, c'est de pouvoir s'adapter aux dynamiques de marché. Typiquement, on va aider nos clients à protéger leurs marges, à s'adapter en fonction du prix des concurrents ou à toute la volatilité qui peut exister sur les marchés. Ou encore s'adapter en fonction des niveaux de stock qui sont, on peut le voir parfois, en pénurie. Donc être dynamique face au prix leur permet de gagner assez facilement des points de marge. Et enfin, on a une solution qui permet à des clients plus dans le B2B d'équiper leurs équipes commerciales avec des outils pour faire des devis plus facilement et au meilleur prix. Il faut savoir que les équipes commerciales sont des équipes qui ont beaucoup de turnover, donc avoir un outil qui permette de stocker tout l'historique de la durée de vie d'un contrat, et très pertinent, surtout dans le cadre de ces métiers-là. Aujourd'hui, on est 70, répartis dans plusieurs localisations, à Paris, à Londres, à Amsterdam.
On a également des bureaux à New York, avec mon associé qui y travaille. Depuis quelques mois, et on s'adresse à différents types de clients, dans le e-commerce, dans le retail, mais également dans la distribution spécialisée, dans le transport, ou enfin dans le tourisme. Aujourd'hui, on va voir un use case secteur agnostique, on va dire, de comment on collabore autour de la donnée. Alors, surtout, n'hésitez pas à m'interrompre pendant la session. Je ferai des allers-retours peut-être sur le channel de QA. Donc, n'hésitez pas à poser des questions. Je pourrais y répondre en live ou au contraire, si ça nécessite de rentrer dans les détails, on verra ça à la fin de la présentation. Je crois qu'il y a des rooms qui sont prévus, donc on pourra échanger. Et je serais ravi d'avoir aussi votre point de vue sur comment vous faites. Donc, pour revenir à nos moutons, nous, on a besoin de données pour fonctionner. C'est le nerf de la vie. Typiquement, on va pouvoir accumuler des données commerciales, donc des données de transactions, transactions de vente, des données de stock, des données de concurrence.
On va plutôt chercher chez des partenaires plutôt que des clients. On va aussi compute énormément de données de prévision qui vont aider à prendre des décisions par rapport au prix. On va mettre ça en regard de stock prévisionnel. On va accumuler beaucoup de données par rapport aux clients dans le cadre du B2B. Alors, on est RGPD, donc on n'exploite pas de données personnelles. En revanche, des données liées à des historiques de vente, pour comprendre un peu les sensibilités prix du client, sont des données qu'on a chez nous et qu'on va pouvoir exploiter. Alors dans quel but ? C'est déjà de pouvoir proposer des recommandations de prix, parce qu'on a un outil qui permet de stocker des prix et de mettre à jour des tarifs. On va pouvoir proposer des recommandations via des notions stratégiques tarifaires qu'on a dans notre plateforme. On va pouvoir aussi proposer des outils pour des décideurs, qui sont chez nos clients, des outils de performance, de revue de performance, pour comprendre comment est-ce que la stratégie pricing est appliquée et comment est-ce qu'elle performe. Et enfin, on va évidemment générer tout un tas d'alertes pour que les utilisateurs, parce qu'on est une solution, on n'est pas une API, on a des utilisateurs finaux qui sont soit des pricing experts, donc des gens qui sont responsables du pricing,
via des alertes, ils vont pouvoir collaborer plus efficacement autour du prix en se concentrant sur les prix à changer qui ont le plus d'impact en termes de marge. Donc voilà, juste pour expliquer, on a des forts besoins de données, et donc on s'est tourné vers une solution comme Snowflake pour plusieurs raisons. Alors la première, c'est déjà parce qu'on avait énormément de pipelines de données qui étaient exécutées dans le cloud. Donc historiquement, il y a plusieurs années, on était sur Postgres, on a testé énormément de solutions, on a testé EMR, je ne sais pas si vous êtes familier avec ça, donc plutôt Spark, des solutions comme Redshift qui nous ont demandé pas mal de... De temps pour peaufiner les règles. et pour faire en sorte que ça fonctionne. Donc finalement, on trouvait ça pas assez plug and play, ça demandait trop de ressources en interne. La deuxième raison, c'est que Snowflake propose de plus en plus la capacité d'utiliser le compute qui est disponible chez Snowflake pour faire autre chose que du data processing
en SQL, pour pouvoir par exemple définir des fonctions Python et pouvoir les exécuter directement dans l'environnement Snowflake. C'est une fonctionnalité qui est sortie récemment via Snowpark. Et enfin, on va beaucoup en parler aujourd'hui, c'est cette notion dont a parlé Hugo, qui est le data sharing. Data sharing permet à un producteur de données de la partager à un consommateur sans copie. Donc on réduit énormément le temps d'accès à la donnée. Et ça permet d'apporter énormément de valeur, on va le voir par la suite. Donc comment est-ce qu'on faisait historiquement pour intégrer de la donnée et comment est-ce qu'on fait chez certains clients qui n'ont pas encore Snowflake? Via des solutions classiques, soit via des API, tu l'as mentionné Hugo, mais aussi via des échanges de fichiers sur SFTP, ça demande pas mal de maintenance. On va le voir. Et une fois que c'est dans Snowflake, nous ce qu'on a construit, c'est vraiment un data lake reposant sur Snowflake avec DBT, qui est un outil d'orchestration de requêtes SQL, ce qui permet d'avoir cette donnée raffinée que vous voyez,
tout ce qui est performance commerciale, qui est calculé au fil de l'eau avec parfois des cinquantaines d'étapes de traitement en SQL. Donc nous, on a vraiment choisi cet outil-là pour la simplicité, pour le côté SQL qui est très pratique pour pouvoir faire des requêtes analytiques et pour que nos ingénieurs se concentrent vraiment sur la partie métier et moins sur la partie technique. Alors, si on regarde comment fonctionnait et comment fonctionne chez les clients qui n'ont pas Snowflake, l'intégration de la donnée, alors c'est valable chez un client, mais chez un partenaire de données également. On travaille avec des partenaires qui nous fournissent de la donnée météo, par exemple, de la donnée de concurrents. On va avoir toute cette étape d'extraction qui est extrêmement lourde chez le côté provider. Donc ça peut prendre du temps, surtout quand il y a une grosse volumétrie. Pouvoir leur mettre à disposition un serveur SFTP ou faire en sorte qu'ils déposent directement sur S3 s'ils sont chez AWS.
Je ne l'ai pas mentionné, mais on est chez AWS. Pouvoir maîtriser de notre côté des logiques de lambda, donc potentiellement d'autres technologies comme Terraform pour faire en sorte que tout ça soit déployé convenablement. Donc ça demande quand même pas mal de compétences, du SQL, du Python, du Terraform. Donc c'est lourd et on perd du temps à mettre en place des pipelines. Et nous, on veut se concentrer sur notre valeur ajoutée qui est le pricing. Donc, on veut optimiser ce process-là. Donc, typiquement, ce qui se passe aussi, c'est qu'on duplique la donnée. dans ces cas-là, parce que la donnée est chez le client dans un état, elle se retrouve chez nous dans un autre état, on la extraite, on la transforme, on la recharge chez nous, on duplique le storage, donc ça a un côté pas très satisfaisant. Alors, quel est l'impact métier chez nous? Tout simplement, vous avez vu le process, ça dure parfois plusieurs heures de pouvoir mettre à jour de la donnée à des fins de recommandations de prix ou de génération d'alertes ou les use cases que j'ai.
précédemment. Dans ce cadre-là, qui est un cadre classique en pricing, où on a une accélération de la demande quand on arrive à échéance, typiquement dans les métiers qui proposent... Des produits avec une demande anticipée. Typiquement, si vous louez une voiture pour ce week-end, si vous y prenez demain, vous allez payer plus cher parce que tout simplement, ça s'accélère. Il y a de plus en plus de gens qui vont vouloir réserver à l'avance à la dernière minute. Et donc, il faut pouvoir réagir et pouvoir proposer un prix plus pertinent. Donc, plus on met de temps à mettre à jour la donnée, moins le prix va être pertinent. Donc, pour nos utilisateurs, ça n'a un impact parce que nos utilisateurs vont pouvoir voir des recommandations qui ne sont pas très cohérentes avec la donnée qui est pourtant dans leur RP. Et pour les consommateurs, du B2C, ça peut potentiellement avoir des effets pas idéaux pour les entreprises qui utilisent Pricemoov. Donc l'important, c'est vraiment d'essayer d'optimiser ce processus.
Donc, je l'ai dit, nécessité de mettre des équipes fortement qualifiées pour déployer des pipelines, nécessité de maintenir ces pipelines, et en plus de ça, on arrive avec de la donnée qui n'est pas forcément fraîche tout de suite. Donc la solution avec ça, c'est évidemment, vous l'avez compris, du data sharing. qui nous permet plusieurs choses. Déjà, d'exécuter des requêtes SQL directement dans l'environnement du client. Alors ça, c'est un changement de paradigme total parce qu'à l'époque, les clients ne voulaient pas que des consommateurs puissent accéder à de la donnée puisqu'on allait potentiellement impacter leur performance. Là, vu que Snowflake dissocie le compute du storage, finalement, il n'y a pas de risque en termes de performance. C'est très pratique. On évite de faire de l'ETL ou de l'ELT, plus récemment de l'ELT, en tout cas nous c'est ce qu'on fait, puisque la donnée est directement visible dans notre environnement Snowflake.
Sur l'aspect sécurité, Hugo l'a mentionné, mais c'est possible pour un producteur de données de nous donner un accès très fin en termes de granularité au niveau de cette donnée-là. Donc typiquement, il peut y avoir un filtrage qui se met par colonne, par ligne. C'est des choses qui peuvent être pratiques, notamment lorsqu'il y a de la donnée sensible qu'on ne veut pas partager. Effectivement, on va pouvoir se connecter à différents clouds, à différentes régions. Si un client est haussé chez Google, on va pouvoir se connecter, même si on est chez AWS, sans contrainte. Donc ça aussi, c'est plus pratique qu'avant. Et puis, j'en ai parlé, il y a une gouvernance assez précise des rôles et des utilisateurs via Snowflake. Donc, on peut déterminer un niveau d'accès très, très fin. Ce qui est très pratique. Donc l'impact, en fait, si on passe d'avant, où on avait des ETL sur des data lakes, on va dire, plus classiques, traditionnels, on avait des temps d'intégration qui pouvaient être autour de 4 heures.
Aujourd'hui, se connecter à un partenaire, un client directement via Snowflake, parce que le client, le partenaire utilise Snowflake, nous permet de gagner énormément de temps en termes de ressources humaines, en termes de... d'ingénierie, on passe moins de temps à maintenir, permet de gagner du temps en termes de traitement de la donnée. Donc, notre produit propose à l'utilisateur de la donnée plus fraîche. Donc, c'est gagnant-gagnant. En plus de ça, on voit des améliorations possibles. Aujourd'hui, on est... On est producteur de données, mais la plupart des données qu'on remonte dans notre logiciel viennent de l'extérieur, viennent de notre client ou de notre partenaire. Donc, il y a un vrai enjeu de data quality, de data observability qui est en train d'émerger. Et donc, on se tourne vers des solutions type Monte Carlo, alors qu'on n'a pas encore vraiment implémenté en production, mais on se renseigne sur comment est-ce qu'on peut facilement détecter des changements en amont de distribution, des changements de données.
Et voir quel impact ça aura en aval sur les recommandations qu'on peut générer, sur les alertes qu'on peut générer, etc. Donc ça, c'est plutôt du travail. en cours, mais je serais ravi d'en parler avec vous après cette présentation, pour savoir si vous, vous avez des outils de data quality qui dépassent un peu le cadre de cette présentation, mais je serais ravi d'en parler. Alors, on est... Voilà. Et donc, un autre avantage de Snowflake, c'est l'existence d'une data marketplace. Hugo en a parlé, et ce n'est pas le bon slide, excusez-moi. Donc cette data marketplace finalement qui permet de centraliser tout un tas de sources de données. On travaille avec des partenaires qui nous fournissent de la donnée météo, de la donnée de prix concurrents par exemple qui sont récoltés sur internet. Et donc, avoir tout au même endroit permet de simplifier la recherche de ces données-là et permet surtout d'accéder à la donnée beaucoup plus facilement.
Plutôt que d'aller requêter une API d'un provider de données, prendre le résultat de ces données-là, le stocker dans une database, pouvoir faire ça en développement, en staging, en production. C'est un temps assez coûteux, ça demande de la maintenance. Là, la donnée est disponible directement dans notre environnement Snowflake. On va pouvoir l'exploiter quasiment en production. C'est vraiment quelque chose que je trouve intéressant. Et le fait, ce que Hugo disait, le fait que ça se développe de plus en plus, il y a de plus en plus de providers de données sur cette marketplace, nous pousse à consommer davantage de données et pouvoir... Multiplier le nombre de use case que nous on propose à nos clients. Alors, c'est aussi l'occasion pour nous d'être visible sur cette marketplace parce que déjà, on est visible en tant qu'éditeur de logiciels et on est Powered by Snowflake, on utilise Snowflake en interne. Donc typiquement, si vous allez sur Snowflake, vous allez pouvoir...
Cliquer sur le Pricemoov et potentiellement demander à contacter un sales pour savoir comment est-ce qu'on peut s'intégrer. Il se trouve que, c'est un peu anecdotique, mais c'est vrai que ça fait plus de six ans maintenant qu'on récolte des données aussi par nos propres moyens, des données de prix. Et on a mis à disposition sur Snowflake, sur cette data marketplace, de location de voiture qui sont disponibles, qui sont gratuitement d'ailleurs. Donc si ça vous intéresse, vous pouvez jeter un oeil. Je crois qu'il y a plus de 6 sociétés de location de voiture qui sont référencées sur plus de 6 ans. Donc ça, c'est aussi quelque chose qui nous donne de la visibilité, et sachant qu'il y a de plus en plus de trafic sur cette marketplace, ça nous rend visible en tant que startup. Je ne vais pas repasser sur les avantages qui sont plutôt clairs. On va pouvoir, peut-être quelque chose que je n'ai pas mentionné, mais le fait de pouvoir computer, exécuter des requêtes dans notre environnement Snowflake et générer
de la donnée raffinée va nous permettre aussi en retour, si le client ou le partenaire a de la... Et sur Snowflake, pouvoir lui partager ces données-là très facilement, en sens inverse, ce qui fait qu'on collabore très facilement autour de la construction de pipeline, notamment quand il y a de la logique métier qu'on ne maîtrise pas, parce que la donnée n'est générée par notre client, ça nous permet de faire beaucoup d'aller-retour sans forcément devoir se envoyer des fichiers. Ou autre. Donc c'est quelque chose qui est extrêmement pratique, qu'on fait vraiment dans un sens comme dans l'autre. Alors parfois même, on génère de la donnée qui a tellement de valeur ajoutée pour le client qu'il l'exploite pour des autres fins, qui ne sont pas du pricing, potentiellement pour des raisons financières ou autres, ou marketing. Mais voilà, donc ça, ça peut être quelque chose qui peut être fait en sens inverse de manière très très facile. Donc, pour résumer, l'intérêt finalement de basculer sur ce mode-là de connectivité, alors je ne sais pas, ravi d'en parler peut-être à l'issue de cette présentation, comment est-ce que vous faites vous, si
vous dépendez de la donnée externe, est-ce que vous utilisez des outils de TL, type Airbyte, type Pivtran, je serais intéressé de savoir. En tout cas, avec Snowflake, c'est... C'est le cas pour la plupart de nos clients et pour de plus en plus de nos prospects. Le fait de s'intégrer permet une intégration extrêmement raccourcie. On parlait de semaines avant, on parle plutôt en termes de jours maintenant. On évite de dupliquer de données, donc c'est un côté un peu plus sustainable, on va dire. On va pouvoir échanger de la donnée facilement, échanger sur des logiques métiers, avoir de la donnée plus fraîche en aval, vous l'avez compris. En termes de bénéfices techniques, disons que c'est vrai que ce qu'on a observé, c'est que là où avant, il y a quelques années, on avait besoin de data engineers qui maîtrisaient énormément de technologies type Spark, type SQL, type Python, du Terraform, énormément de sujets. Maintenant, on va plus se concentrer sur des analytics engineers qui maîtrisent SQL, qui sont capables de comprendre
de la donnée du client et qui sont capables de la traiter, de la raffiner sans forcément maîtriser. De technologie. On se concentre vraiment sur notre valeur ajoutée principale qui est le pricing. Là maintenant, ce dont on a déjà parlé, c'est beaucoup plus facile à maintenir. Et puis aussi la maîtrise des coûts. Via Snowflake, c'est assez pratique de monitorer, de vérifier qu'on ne dépasse pas certains seuils, certaines alertes. C'est un mode de consommation par crédit et on peut se fixer des thresholds quand on dépasse certains seuils. On peut même penser à d'autres types de... De business model avec de la refacturation de certaines workloads chez le client. Donc c'est des choses qui sont possibles vu que la ségrégation au niveau du compute peut se faire à NMI très fin. Et donc, côté business, ça nous permet de proposer un outil qui repose sur la donnée fraîche, donc une marge plus importante pour notre client.
Ça nous permet d'écrire des success stories qui sont quand même super avec nos clients, qui sont ravis de pouvoir partager une collaboration via Snowflake. On en a d'ailleurs eu plusieurs témoignages par le passé. Avec certains de nos clients. Et en plus de ça, les clients ont beaucoup moins peur de nous léguer de la logique métier. Ils sont ravis de pouvoir la... la migrer une fois le projet en cours ou réalisé dans leur environnement pour qu'ils puissent la maîtriser à plus long terme. Alors, peut-être en termes d'ouverture, j'ai parlé beaucoup de Snowflake, mais c'est vrai que ce n'est pas la seule brique qu'on a chez Pricemoov. On utilise d'ailleurs beaucoup d'autres technologies comme Postgres, PostgresQL, pour tout ce qui est données transactionnelles. On utilise encore... Du S3, notamment pour avoir des profondeurs d'historique importantes et pouvoir maîtriser les coûts.
Alors c'est très facile de pouvoir basculer de S3 à Snowflake via des commandes copie ou via des connecteurs comme Snowpipe, on rentrera peut-être dans les détails après cette présentation. Et en termes de roadmap, en termes de limitations que je vois aujourd'hui, pour vous partager les chantiers qu'on a en cours, c'est vraiment ces sujets d'observabilité, comment est-ce qu'on rend la qualité de la donnée au centre de notre quotidien. On a beaucoup de clients qui nous fournissent de la donnée qui change dans le temps et on a besoin de mettre des garde-fous. Et des outils type Monte Carlo, on en a parlé, mais je serais intéressé de savoir quels outils vous utilisez pour observer ces changements de distribution. Vous utilisez. D'autres types de chantiers qu'on a en cours, c'est de pouvoir déplacer certaines workloads qu'on... qu'on exécute aujourd'hui dans Postgres, dans Snowflake. Et notamment de bénéficier de fonctionnalités très intéressantes qui sont proposées comme le Row Access Policy, qui permet de filtrer au niveau du rôle de l'utilisateur sur une table.
Donc typiquement, pour des usages de BI, je pense que ça a vraiment beaucoup de sens, puisqu'on va pouvoir mettre dans la main de nos utilisateurs de la BI embarquée, et potentiellement avoir un niveau d'accès qui est différent, en maîtrisant au niveau de la couche physique, au niveau de Snowflake, bel et droit d'accès. Donc ça, je trouve ça vraiment intéressant et beaucoup plus facile à mettre en œuvre qu'avec d'autres technologies. François, je t'interromps, il y a une question pour toi, justement sur ce dont tu parles ici, de Kevin Diagre dans le chat qui demande, le prix à payer de cette visibilité accrue et de ces facilités est aussi d'avoir un couplage fort avec Snowflake. Y voit-tu un risque en tant que CTO? Alors, Oui, c'est vrai que c'est un couplage fort. Après, ça reste du SQL. Donc, disons que pour migrer nos pipelines SQL historiquement sur Postgres, sur Snowflake, Finalement, ça a été très rapide, parce que le dialecte est le même. À côté de ça, Snowflake est multi-cloud.
Donc si demain on veut passer chez Azure ou chez Google Cloud, ce qu'on aura potentiellement envie de faire, on ne sera pas gêné avec un outil comme Snowflake. Alors que si on exécutait sur BigQuery ou sur Athena, ça aurait été une autre histoire. Donc, je dirais que le risque est un petit peu mitigé par ces deux éléments. Je ne sais pas si ça répond à la question. Peut-être que Kevin pourra nous le dire dans le chat. Et pour compléter la réponse de François, François mentionnait la capacité à utiliser un compte Snowflake sur lequel que ce soit le cloud provider et le langage qu'on utilise qui est essentiellement SQL mais qui est aussi Python et qui est très transverse, qui est ANSI, qui est très standard. Donc exécutable sur n'importe quelle plateforme. Et l'autre point, c'est autour de la donnée en elle-même. Est-ce que cette donnée, vous pouvez la sortir aussi facilement? C'est de la même façon. Aujourd'hui, sortir un terabyte de données, ça prend quelques minutes et coûte quelques euros. Et vous pouvez la sortir dans le format que vous voulez.
Toutes vos données, encore une fois, sont accessibles ultra facilement aussi dans Snowflake. Exactement. Et une dernière piste aussi qu'on explore en ce moment, c'est de pouvoir extraire de la donnée de notre backend, qui est aujourd'hui sur, je l'ai dit, tout le transactionnel et sur Postgres, pouvoir l'extraire facilement et l'envoyer sur Snowflake via des outils de TL comme Airbyte, pour que ce soit fait plus simplement. Donc là, ce sont des sujets en cours. Et le dernier que Hugo a mentionné, je crois, c'est Snowpark. C'est une API qui permet de faire du Python dans Snowflake. Donc le compute se fait dans Snowflake, ce qui évite de maintenir des lambdas à côté ou maintenir de l'EKS ou je ne sais quoi. Vraiment, ça limite le nombre de technos et donc ça simplifie un petit peu la vie des data engineers qui bossent sur ces sujets-là ou des data scientists. Voilà, donc c'était à peu près tout de mon côté.
Merci beaucoup de m'avoir écouté et je serais ravi de pouvoir prolonger ces discussions peut-être à côté, soit dans ce chat via la question. Q&A, soit dans les différentes salles qui sont virtuelles aujourd'hui. Et voilà, donc merci beaucoup pour votre accueil. Merci à Snowflake de nous avoir proposé cette présentation. J'espère que ça vous a plu, ou en tout cas, ça pose des questions. Donc là, il y a juste une autre question qui nous demande, aurions-nous accès à la présentation à la fin de ce meet-up? Alors, je ne sais pas, peut-être demander à Noémie, mais je crois que c'est enregistré. Et puis ensuite, la vidéo sera disponible sur YouTube. Autre chose, donc voilà, à partir du moment où on va couper ce meet-up, on pourra tous se retrouver dans les petites salles virtuelles à côté ou par groupe de 3-4, vous pourrez changer directement avec François ou moi-même pour poser davantage de questions. Donc voilà, on va couper notre caméra et le micro et on se retrouve dans les petites salles.
Merci à tous. Merci à tous.
