L’ingestion de données est la première étape de tout pipeline de données. Elle désigne le processus consistant à collecter des données depuis des systèmes sources et à les transférer vers un data warehouse, un data lake ou une plateforme d’analyse où elles peuvent être interrogées.

Lorsque l’ingestion de données échoue, vous obtenez des Dashboards obsolètes, des rapprochements comptables erronés et des modèles de machine learning entraînés sur des données incomplètes. Pire encore, de mauvaises données peuvent avoir un impact direct sur vos résultats financiers. Plus de 25 % des organisations déclarent perdre 5 millions de dollars américains ou plus chaque année en raison d’une mauvaise qualité des données.

Nous allons examiner plus en détail ce qu’est l’ingestion de données, les principaux modèles d’ingestion, les cas d’usage qui motivent la majorité des investissements dans les pipelines, ainsi que les défis auxquels les équipes sont confrontées.

Points clés

• L’ingestion de données permet de déplacer les données des systèmes sources vers un environnement où elles peuvent être stockées et interrogées. Le modèle retenu par une entreprise détermine le niveau d’actualisation des données.

• Une ingestion fiable repose sur deux éléments : l’exhaustivité (c’est-à-dire que tous les enregistrements attendus sont bien présents) et l’actualisation (c’est-à-dire que les données arrivent avant qu’elles ne soient utilisées).

• Un prestataire de paiement moderne peut synchroniser les données directement vers des destinations telles que Snowflake, Redshift et Amazon S3. Cela permet aux entreprises d’accéder à l’ensemble de leur historique de transactions sans développement d’ingénierie spécifique ni recours à des fournisseurs de connecteurs tiers.

L’ingestion de données est le processus consistant à extraire des données depuis des systèmes sources et à les charger dans une destination où elles peuvent être stockées, interrogées et exploitées. Elle alimente les data warehouses, les data lakes et les plateformes d’analyse.

Dans le domaine des paiements, l’ingestion de données peut permettre de regrouper des données issues de différentes sources, telles que des systèmes de point de vente (POS), des sites web d’e-commerce et des passerelles de paiement.

Quels sont les principaux types d’ingestion de données ?

Le niveau d’actualisation nécessaire pour vos données, ainsi que le seuil à partir duquel des données obsolètes ne sont plus exploitables, déterminent la méthode d’ingestion la plus adaptée à votre entreprise.

Voici les principales méthodes à envisager.

Ingestion par lots

L’ingestion par lots récupère les données selon un calendrier planifié et les transfère en masse. La latence se mesure en heures ou en jours, ce qui est adapté à de nombreux cas d’usage. Les clôtures financières, les rapports exécutifs hebdomadaires et les analyses de tendances historiques (par exemple, l’analyse de l’attrition) peuvent généralement tous s’appuyer sur ce type de données.

Ingestion en continu

Les processus d’ingestion en streaming traitent les événements au fur et à mesure de leur production, ce qui réduit la latence à quelques secondes ou moins. Cette approche repose sur une infrastructure plus exigeante : vous utilisez généralement des systèmes tels qu’Apache Kafka ou des solutions cloud natives équivalentes, et vos applications consommatrices doivent être capables de gérer des événements hors ordre ainsi qu’une livraison au moins une fois. Elle est généralement pertinente lorsque la valeur des données dépend de signaux de fraude, d’un inventaire en temps réel ou d’une personnalisation en temps réel.

Capture des données en cas de modification

La capture des changements de données (CDC) lit le journal des transactions d’une base de données source et ne transmet que les changements, avec une latence de l’ordre de quelques minutes, sans le coût lié à des lectures complètes de la table de manière répétée. Il se positionne entre le traitement par lots et le streaming, à la fois en termes de complexité et d’actualité des données, et il est particulièrement utile lorsque vous avez besoin d’une précision en quasi temps réel (NRT) à partir d’un système relationnel.

Quels sont les cas d’usage les plus courants de l’ingestion de données ?

L’ingestion de données sert à alimenter un processus en aval. Le modèle retenu dépend fortement de la manière dont les données sont utilisées.

Voici les cas d’usage les plus courants de l’ingestion de données :

• Veille stratégique (BI) : les revenus, la conversion, l’attrition et le volume de support alimentent des Dashboards consultés quotidiennement par les équipes. Le niveau d’actualisation de l’ingestion détermine à quel point ces données sont à jour.

• Déclaration financière : les clôtures mensuelles et trimestrielles reposent sur des données de transaction complètes et exactes, disponibles dans un data warehouse où les équipes financières peuvent exécuter leurs requêtes. L’exhaustivité est aussi importante que l’actualisation dans ce contexte.

• Analyses clients et produits : les données d’événements comportementaux, combinées aux données du système de gestion de la relation client (CRM) et aux données de transactions, donnent aux équipes produit et de développement une vision complète. L’ingestion est ce qui relie ces systèmes sources et rend le jeu de données combiné exploitable en requêtes.

• Surveillance de la fraude : une décision prise sur des données âgées de 12 heures repose souvent sur des informations déjà obsolètes. La détection de la fraude est l’un des cas où le streaming ou le CDC en quasi temps réel justifie l’effort supplémentaire.

• Machine learning : les pipelines d’entraînement ont besoin de données historiques en volume, tandis que les pipelines d’inférence nécessitent des variables récentes. L’ingestion répond aux deux besoins : l’ingestion par lots peut être utilisée pour les jeux de données d’entraînement, et des approches à faible latence peuvent alimenter les feature stores.

À quoi ressemble une bonne ingestion de données ?

Lorsque les données arrivent complètes et dans les délais, les analystes peuvent arrêter de douter de leurs chiffres et de réaliser des contrôles de rapprochement avant chaque déclaration.

Une bonne ingestion de données garantit l’exhaustivité. Tous les enregistrements qui devraient être présents le sont. Une couche d’ingestion bien conçue gère la déduplication, le rattrapage des données manquantes et la prise en compte des enregistrements arrivant en retard avant qu’ils ne se traduisent en erreurs de déclaration.

Les données arrivent au moment où elles sont nécessaires. Cela ne veut pas dire le plus rapidement possible, mais qu’elles sont disponibles avant que l’utilisateur n’en ait besoin.

Quels sont les principaux défis de l’ingestion de données ?

L’ingestion de données paraît simple tant qu’elle n’est pas mise en œuvre sur plusieurs systèmes sources. Les défis suivants liés à l’ingestion de données sont ceux qui posent le plus souvent problème.

Sécurité et exposition des données

Le transfert de données sensibles (par exemple des transactions financières, des informations d’identification personnelles ou des enregistrements de paiement) via une infrastructure d’ingestion crée des points d’exposition à chaque étape du processus. Les équipes qui font transiter des données de paiement par un connecteur « extract, transform, load » (ETL) tiers donnent à ce fournisseur un accès à l’ensemble de leur historique de transactions. Le caractère acceptable de ce modèle dépend des contrats avec les fournisseurs, des exigences de conformité et du niveau de tolérance au risque.

Développement

Le volume de données augmente avec le temps. Les changements de schéma dans les systèmes sources peuvent casser les pipelines de manière qui ne se manifeste pas toujours immédiatement. Les stratégies de partitionnement, les chargements incrémentaux et la gestion de l’évolution des schémas sont des problèmes d’ingénierie qui doivent être anticipés avant de devenir des incidents.

Fragmentation

Dans de nombreuses organisations, l’ingestion de données est souvent fragmentée plutôt que conçue comme un système unifié et intentionnel. Par exemple, l’équipe chargée des données peut avoir développé un connecteur pour Salesforce, tandis que l’équipe d’ingénierie en a mis en place un autre pour la base de données de production, et que l’équipe finance s’appuie sur une exportation en CSV téléversée chaque lundi par un utilisateur. Le résultat est un ensemble de pipelines de données dupliqués et incohérents, difficiles à surveiller et encore plus difficiles à fiabiliser.

Défaillances de qualité

Les pipelines tombent parfois en panne de manière évidente : une tâche échoue ou un Dashboard cesse d’afficher des données. Mais certaines défaillances peuvent aussi passer inaperçues. Une modification du schéma en amont peut, par exemple, supprimer une colonne et entraîner des données manquantes dans les tableaux en aval. De même, une limite d’appels d’une interface de programmation d’applications (API) peut provoquer des chargements partiels qui semblent pourtant complets. Sans surveillance capable de contrôler le nombre de lignes, les plages de valeurs et l’intégrité référentielle, ces anomalies risquent de passer inaperçues jusqu’à ce qu’elles provoquent un problème suffisamment important pour être remarqué.

En quoi l’ingestion de données diffère-t-elle de l’ETL et de l’ELT ?

L’ingestion de données, les méthodes ETL et ELT décrivent des éléments qui se recoupent au sein d’un même pipeline, mais ne désignent pas la même chose.

• Ingestion de données : il s’agit du processus consistant à transférer des données d’un système source vers un système cible. L’accent est mis sur le transport et l’acheminement des données. Cela ne tient pas compte d’éventuelles modifications des données pendant le transfert.
  
• « Extract, transform, load » (ETL) : il s’agit d’une architecture dans laquelle les données sont extraites de la source, transformées en amont, historiquement dans un outil de transformation dédié ou un serveur de staging, puis chargées vers la destination dans leur forme finale, prête à être interrogée. La transformation intervient avant l’arrivée des données.
  
• « Extract, load, transform » (ELT) : il s’agit de la même architecture, mais avec les deux dernières étapes inversées. Les données brutes sont chargées directement dans le data warehouse, puis les transformations sont réalisées dans ce même environnement à l’aide du langage SQL (Structured Query Language) ou d’outils comme le data build tool (dbt). Cette approche est devenue viable avec la baisse des coûts et la montée en puissance des data warehouse cloud, aujourd’hui capables de gérer des transformations lourdes à grande échelle. Elle s’impose désormais comme le modèle dominant des suites d’outils de données modernes.
  

Comment un prestataire de paiement facilite-t-il l’ingestion de données ?

Stripe Data Pipeline est une synchronisation directe depuis Stripe vers votre data warehouse ou votre destination de stockage cloud, sans intermédiaire. Il est disponible pour les utilisateurs Stripe existants et se connecte à des destinations telles que Snowflake, Redshift et Databricks. La configuration ne nécessite ni écriture de code ni paramétrage de connecteurs.

Voici comment Stripe Data Pipeline simplifie l’ingestion de données :

• Actualisation des données : les synchronisations s’exécutent en continu, et la plupart des données sont disponibles quelques heures après l’événement sous-jacent.

• Données historiques : lors de la connexion, vous accédez à l’ensemble de votre historique Stripe, et non seulement aux données disponibles à partir de la date de connexion.

• Exhaustivité des données : Stripe Data Pipeline inclut des rapports financiers préconstruits, tels que le rapprochement des virements et le récapitulatif de solde, ainsi que des jeux de données préparés pour des cas d’usage courants comme le revenu récurrent mensuel (MRR) et l’analyse de fraude. Les fournisseurs tiers ne peuvent pas synchroniser ces sources de données et nécessitent des exports manuels ou une reconstruction des données.

• Réduction de l’exposition aux fournisseurs : la synchronisation directe entre Stripe et votre data warehouse permet d’éviter le passage de vos données de paiements par l’infrastructure d’un prestataire tiers.