Comment BlaBlaCar conduit l’ingestion de ses données marketing

La configuration des API freinait les opérations analytiques de BlaBlaCar. Le département Data a trouvé chez Rivery les moyens d’automatiser l’ingestion de ses données marketing.

Sur sa place de marché de mobilité partagée, BlaBlaCar rassemble une communauté de 100 millions de membres dans 22 pays. Ses utilisateurs, 25 millions de voyageurs par trimestre, font du covoiturage ou montent dans les BlaBlaBus (depuis le rachat de Ouibus en 2019).

Pour convaincre les usagers, l’entreprise française se rend visible à travers les réseaux sociaux au cours de campagnes marketing. Problème, les données statistiques générées par Google, Facebook et Bing Ads ne sont pas aussi facilement accessibles qu’il y paraît. Surtout à cette échelle.

Il fallait développer manuellement des scripts Python. Cela prenait a minima deux semaines.

Il y a un peu plus d’un an, l’équipe marketing a donc fait appel au département Data, et plus particulièrement à l’équipe en charge du déploiement des outils de traitement de données.

« Mon équipe est transverse au sein du département Data. Elle fournit les outils nécessaires pour les autres équipes », explique Antoine Lefebvre, Data Engineering Product Owner chez BlaBlaCar. « Nous gérons l’outillage pour l’ingestion des données, l’entreposage, les infrastructures data science, etc. », ajoute-t-il.

« Chez BlaBlaCar, nous ne sommes pas là pour développer des API, mais pour organiser des covoiturages et des trajets en bus. Nous ne voulions pas développer une grosse machine chez nous pour récupérer des données. »
Antoine LefebvreData Engineering Product Owner, BlaBlaCar

En l’occurrence, ces scripts ciblaient des API pour alimenter des tables BigQuery sur Google Cloud, elles-mêmes utilisées pour nourrir des analyses réalisées à l’aide de la plateforme BI Tableau.

« Nous avions régulièrement des problèmes de maintenance parce que ces API évoluaient fréquemment », indique Antoine Lefebvre. « Cela nous prenait du temps à nous connecter à de nouvelles API puisqu’il fallait écrire les connexions manuellement ».

Les data engineers perdaient du temps, et les projets prenaient du retard. « Chez BlaBlaCar, nous ne sommes pas là pour développer des API, mais pour organiser des covoiturages et des trajets en bus. Nous ne voulions pas développer une grosse machine chez nous pour récupérer des données », informe le product owner.

Il fallait donc trouver une solution avec suffisamment de connecteurs pour accéder aux différentes sources de données.

« Nous avons réalisé une étude de marché, puis évalué plusieurs solutions », poursuit-il. « Au départ, nous cherchions du côté des outils spécifiques au marketing, puis nous avons rapidement étendu le périmètre de notre recherche à des solutions génériques ».

L’équipe avait notamment identifié Adverity, un outil spécialisé dans le traitement des données marketing. Parmi les outils génériques, plusieurs solutions ont retenu l’attention, dont Airbyte et Rivery.

« Airbyte est très utilisé, mais il n’était pas suffisamment mature pour nos usages », constate l’expert.

BlaBlaCar a ainsi jeté son dévolu sur Rivery. « Ce qui nous a convaincus, c’est que l’outil permet de gérer des connexions génériques sur des API », explique le product owner. L’éditeur revendique plus de 190 connecteurs.

« Une fonctionnalité détecte automatiquement le schéma de données au moment de récupérer les données. Il n’est plus nécessaire de préciser à la main quels champs nous souhaitons récupérer. C’est un gain de temps énorme ».

Avec Airbyte, cela demandait encore une instrumentation manuelle. Avec Rivery, il y a peu de code à écrire, remarque-t-il. De même, la pagination est automatisée : il n’y a pas besoin de stipuler l’URL à appeler pour récupérer les données suivantes, quand il y a beaucoup de données à extraire.

Après trois semaines de test, l’entreprise a signé le contrat avec l’éditeur.

La configuration pour se connecter aux systèmes de BlaBlaCar a été très fluide, selon le product owner. Lors de cette première phase, il y avait tout de même des questions concernant la mise en place des flux de données, appelés « rivières » chez Rivery.

« Au début, il fallait s’habituer à l’outil, nous avons posé un certain nombre de questions au support de Rivery à travers un canal sur Slack », indique Antoine Lefebvre. « Mais rapidement, les équipes sont devenues assez autonomes et ont pu gérer leurs pipelines ».

Trois équipes data ainsi qu’une équipe métier utilisent l’outil. En sus des données marketing, l’ELT/ETL est utilisé pour récupérer les informations de localisation des bus. « Ce n’est pas en temps réel », souligne immédiatement le chef de projet. « Cela nous permet d’analyser la ponctualité de nos bus et la performance lors des trajets après coup ».

De même, les tickets ouverts au support de BlaBlaCar – qui utilise Zendesk – sont ingérés dans BigQuery à l’aide de Rivery, tout comme les données en provenance du CRM Salesforce.

L’un des derniers projets en date implique l’usage de Webhooks pour extraire et charger des messages HTTP en provenance d’une application tierce.

Chez BlaBlaCar, Rivery fait du covoiturage avec Apache Airflow

Pour l’instant, Rivery est davantage utilisé comme une solution d’ingestion et de chargement de données par BlaBlaCar. « Notre structure de transformation de données était déjà en place », précise Antoine Lefebvre. « Mais je pense que pour de petites entreprises, Rivery permet de faire beaucoup de choses dans le maintien de pipelines ETL/ELT de bout en bout ».

Pour ces traitements de bout en bout, avec transformation donc, BlaBlaCar a mis en place Apache Airflow, un orchestrateur open source de flux ELT. « Nous utilisons Airflow pour orchestrer les transformations SQL que nous effectuons depuis BigQuery ».

Ici, les data engineers de BlaBlaCar s’appuient sur la modularité de Rivery – qui est moins une plateforme qu’une collection de modules – pour raccorder les « rivières » à son architecture existante. « À travers l’API de Rivery, nous lançons les rivières directement depuis Airflow. Dès que les données sont copiées avec Rivery, nous pouvons enchaîner l’exécution de nos transformations », explique Antoine Lefebvre.

« Une fois que les données sont dans BigQuery, les analystes peuvent créer des tableaux de bord pour les équipes marketing et produits. Les cas d’usage sont nombreux », ajoute-t-il.

Actuellement, quinze à vingt flux Rivery sont exécutés quotidiennement par les équipes de BlaBlaCar. La fréquence d’extraction des données varie selon les sources. Depuis Zendesk, Facebook et Google Ads, les équipes concernées récupèrent une dizaine de types de données différents (ou rapports) par jour. « Depuis certaines sources, nous récupérons les données toutes les heures, tandis qu’un des flux est configuré pour s’exécuter toutes les dix minutes », indique le product owner.

Comme pour beaucoup d’ELT/ETL en mode SaaS, c’est souvent la fréquence d’utilisation et le volume de données « transportées » qui conditionnent le modèle tarifaire.

Dans Rivery, l’unité de coût s’appelle RPU. « Par défaut, cela correspond à une exécution et 100 Mo de données copiées. Cela permet de faire un certain nombre de choses », évoque Antoine Lefebvre.

Or dans certains cas, cette unité n’était pas suffisante. « Sur certaines rivières les plus fréquemment exécutées, nous avons demandé une mise à jour du volume pour ne pas dépasser notre quota ».

Toutefois, le prix de la solution a convaincu BlaBlaCar d’utiliser Rivery. « Certains éditeurs calculent leur tarif en fonction du nombre de flux et du volume de données transféré. D’autres ne comptent que le volume de données », résume le product owner. « D’après nos estimations, Rivery s’est présenté comme une des meilleures solutions en matière tarifaire ».

Mais ce qu’économise principalement BlaBlaCar, c’est du temps, selon le responsable. « Nous mettons beaucoup moins de temps pour développer un nouveau pipeline. Cela permet donc d’accélérer la livraison de projets ». Ainsi, la configuration des API prend généralement deux jours quand la conception d’un pipeline prend une demi-journée.

Des fonctionnalités attendues

Il y a tout de même des limitations communes à Rivery, Airbyte et d’autres produits, signale le product owner.

En l’occurrence, pour itérer sur la récupération des données de trajets de bus, il faut combiner l’identifiant de chaque véhicule et sa date de circulation. « Cela nous demande de faire des boucles au niveau de la logique des API. Ce scénario n’est pas encore pris en charge nativement par les outils du marché ».

Le département Data de BlaBlaCar discute avec Rivery pour faciliter la mise en place de ce scénario.

« Nous attendons une fonctionnalité qui n’est pas encore disponible nativement pour récupérer des données depuis BigQuery ».
Antoine LefebvreData Engineering Product Owner, BlaBlaCar

Rivery promeut la possibilité d’exécuter une fonction dite « reverse ETL ». Celle-ci vise à extraire les données depuis un entrepôt de données vers une application métier.

« Nous avons considéré un de ces scénarios, mais ce n’est pas quelque chose que nous utilisons aujourd’hui », répond Antoine Lefebvre. « Nous attendons une fonctionnalité qui n’est pas encore disponible nativement pour récupérer des données depuis BigQuery ».

Un autre usage de Rivery consiste à copier les bases de données en production. « Nous nous sommes posé la question, mais c’est un sujet que nous maîtrisons bien au sein de notre département en matière d’optimisation et de coût. Nous avons conservé notre solution », renseigne-t-il.

Le département Data s’intéresse à DBT, un autre outil de transformation de données qui gagne en popularité. « DBT pourrait apporter une couche d’abstraction, c’est quelque chose que nous allons explorer au cours des prochains mois », anticipe le product owner.

L’équipe d’Antoine Lefebvre recommande des outils, mais ne les impose pas. « Pour autant, l’usage de Rivery est déjà plus important que nous l’avions prévu au départ. L’outil est simple d’utilisation », conclut-il.

Pour approfondir sur Middleware et intégration de données

Close