Comment Deliveroo a reconstruit sa chaîne de données autour du stack ELT moderne

En 2021, Deliveroo opérait dans une dizaine de pays avec des pipelines de données construits par accumulation successive. Chaque équipe produit avait ses propres scripts de transformation SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.Voir la définition complète →, souvent déposés dans des dépôts Git disparates, sans documentation ni tests. Les data analysts passaient une partie significative de leur temps à corriger des incohérences entre les métriques affichées dans différents tableaux de bord, notamment sur des indicateurs aussi basiques que le nombre de commandes ou le taux d'annulation. Le problème n'était pas la puissance de calcul ni le volume de données : c'était l'absence de couche de transformation standardisée et traçable.

À cette époque, plusieurs entreprises de la même génération technologique, comme Gousto ou Farfetch, traversaient des difficultés analogues. Ce qui distingue le cas Deliveroo, c'est la décision explicite de traiter l'architecture de données comme un produit d'ingénierie à part entière, avec les mêmes exigences de qualité qu'un produit logiciel destiné aux utilisateurs finaux.

Ce que Deliveroo a fait

La refonte s'est construite autour de trois composants distincts, chacun assumant un rôle précis.

Pour l'ingestion, Deliveroo a déployé Fivetran (éditeur de connecteurs d'ingestion managés, dont les données d'adoption sont à prendre dans ce contexte commercial) pour répliquer les données sources depuis PostgreSQL, Salesforce et plusieurs APIs partenaires vers BigQuery. Le choix de Fivetran repose sur un calcul simple : maintenir des connecteurs maison pour des dizaines de sources coûte plus cher en temps ingénieur que l'abonnement SaaS. Cette logique s'applique dès lors que l'équipe data ne dépasse pas une vingtaine de personnes dédiées à l'infrastructure.

Pour les transformations, l'équipe a adopté dbt (Data Build Tool, édité par dbt Labs). dbt permet d'écrire les transformations en SQL pur, versionné dans Git, avec des tests de non-nullité, d'unicité et de cohérence référentielle intégrés directement dans le projet. Chaque modèle devient un objet documenté, testé et traçable. Deliveroo a structuré ses modèles selon la convention désormais largement répandue : une couche staging qui normalise les données sources sans les enrichir, une couche intermédiaire qui effectue les jointures métier, et une couche mart exposée aux analystes et aux outils BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète →. Cette séparation force la discipline : on ne mélange pas la logique de nettoyage avec la logique métier.

Pour l'orchestration, l'entreprise a utilisé Apache Airflow, déployé sur Google Cloud Composer. Airflow permet de définir des DAG (Directed Acyclic Graphs) qui enchaînent les ingestions Fivetran, les runs dbt et les exports vers les outils de visualisation. C'est ici que réside souvent la complexité sous-estimée : un pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → ELTELTELT (Extract, Load, Transform) is a data integration pattern where raw data is loaded into a target system first, then transformed inside it using the platform's compute power.Voir la définition complète → bien conçu n'est pas simplement une séquence linéaire. Certaines transformations dbt dépendent de données fraîches issues de plusieurs connecteurs Fivetran, et l'orchestrateur doit gérer ces dépendances avec des SLA clairement définis.

Un point rarement mentionné dans les retours publics : Deliveroo a investi parallèlement dans un contrat de données interne ("data contract"), un document formalisé qui spécifie pour chaque modèle dbt l'équipe propriétaire, la fréquence de mise à jour attendue et les règles de qualité minimales. Sans cette couche organisationnelle, les outils seuls ne résolvent pas le problème de confiance dans les données.

Les résultats

Les chiffres précis publiés par Deliveroo sur ce chantier restent limités dans les communications publiques disponibles, et il convient de ne pas extrapoler au-delà de ce qui est documenté. Ce qui ressort des témoignages d'ingénieurs de l'équipe data sur des conférences comme dbt Coalesce (2022 et 2023) :

• Le temps de résolution d'une discordance de métrique entre équipes est passé de plusieurs jours à quelques heures, grâce à la traçabilité des modèles dbt et à la documentation générée automatiquement.
• Le nombre de tests automatisés dans le projet dbt a atteint plusieurs milliers, couvrant des modèles critiques comme les revenus par restaurant et les délais de livraison.
• L'onboarding d'un nouvel analyste sur l'environnement de données, autrefois estimé à deux à trois semaines de découverte informelle, s'est réduit grâce au catalogue de modèles généré par dbt docs.

Ces éléments qualitatifs correspondent à ce que Gartner (cabinet d'analyse indépendant) documente comme gains typiques d'une migration vers une architecture ELT avec transformation déclarative : réduction du toil d'ingénierie et amélioration de la confiance des utilisateurs métier dans les données.

Ce qui s'applique ailleurs, et les limites

Plusieurs décisions prises par Deliveroo méritent d'être extraites comme principes transférables.

La séparation stricte entre ingestion, transformation et orchestration n'est pas une préférence esthétique : elle permet de remplacer chaque composant indépendamment. Si Fivetran devient trop coûteux à mesure que les volumes augmentent, il peut être remplacé par Airbyte (open source) sans toucher aux modèles dbt.

Les contrats de données sont la condition de succès réelle. Un projet dbt sans propriétaire défini par modèle devient rapidement un nouveau silo, simplement mieux présenté. La question de gouvernance précède la question d'outillage.

Cela dit, le contexte Deliveroo n'est pas universel. L'entreprise disposait d'une équipe data engineering structurée, d'un budget cloud significatif et d'une direction produit sensibilisée à la valeur des données. Dans une organisation avec une équipe data de deux ou trois personnes, le coût de maintenance d'Airflow, même via Cloud Composer, peut dépasser les bénéfices. Des solutions comme Prefect ou Dagster offrent une courbe d'entrée plus douce, et dbt Cloud (éditeur dbt Labs, offre commerciale) intègre une orchestration légère qui suffit à de nombreux contextes mid-market.

L'autre variable souvent ignorée : la maturité SQL des équipes métier. dbt ne sert à rien si les analystes qui doivent s'en emparer n'ont pas les bases pour lire un modèle et en valider la logique. La formation reste un investissement non délégable à l'outillage.

Le stack ELT moderne ne réduit pas la complexité, il la déplace vers un endroit plus visible et plus gérable. C'est ce déplacement qui crcrThe percentage of visitors or prospects who complete a desired action (purchase, sign-up, contact form), calculated as conversions divided by total opportunities.Voir la définition complète →ée de la valeur organisationnelle. Pour un CDO en phase de modernisation, la priorité n'est pas de choisir entre Fivetran et Airbyte, c'est de définir qui possède chaque donnée et à quelle condition elle peut être considérée comme fiable.