Construire sa data plateforme : les 10 défis à anticiper (1/2)

Depuis plusieurs années, les entreprises se dotent d’outils informatiques pour automatiser et optimiser des tâches diverses. Des sites web pour communiquer et faire du commerce à grande échelle, des outils de monitoring de production pour tracker la performance, des outils de reporting pour gérer la finance, etc. Tous ces outils génèrent et stockent de la donnée, souvent inexploitée.

L’objectif d’une data plateforme est de centraliser les données provenant de tous ces outils, et de les mettre à disposition des différentes équipes métiers. Ainsi, chaque équipe peut prendre connaissance des performances des autres segments de l’entreprise, et adapter ses décisions en conséquence.

Savoir qu’il y a une panne en production peut permettre aux achats de négocier une livraison plus tardive moyennant une réduction de prix. Savoir qu’il y a une hausse de traffic sur le site internet peut permettre aux équipes de production de mieux anticiper une hausse de la demande. Plus généralement, avoir toutes ces informations à disposition permet à chacun de considérer le contexte global, et de prendre des meilleures décisions. Une étude de HBR a montré que les entreprises qui utilisaient des données dans leur prise de décision ont une croissance supérieure de 12 points.

Comment la performance de votre organisation a changé sur les dernières années ? Pourcentage de réponses indiquant une augmentation significative ou légère. (Source)

Par le passé, beaucoup d’entreprises ont investi dans des data warehouses ou data lakes permettant de stocker les données et de les mettre à disposition d’une équipe data, qui peut ensuite construire des dashboards pour des utilisateurs internes ou externes. Une plateforme data va encore plus loin, pour mettre ces données directement à disposition d’un maximum d’utilisateurs, avec une forte mobilisation et contribution des équipes métier pour construire des données qui ont du sens.

Les défis techniques

D’un point de vue technique, la mise en place d’une data plateforme semble assez simple. Les technologies nécessaires sont assez connues et maîtrisées par les ingénieurs, et même si certains outils apparaissent et deviennent la norme (DBT, Airbyte, ...), les fondations du data engineering restent sensiblement les mêmes qu’il y a 5 ans (SQL, Python, Airflow, ...).

Pourtant, la mise en place de ces plateformes demande parfois des ressources et des efforts considérables, et des années d’itérations pour arriver à un résultat semi-satisfaisant. En effet, le contexte de chaque entreprise est unique, et selon les contraintes techniques, la tâche peut s’avérer beaucoup plus lourde que prévue. Quels sont donc ces défis techniques à anticiper ?

Ingérer la donnée

La première étape dans la création d’une data plateforme est l’ingestion de données : on souhaite récupérer la donnée présente dans un outil spécifique (ex: SAP, Hubspot, etc.), et la stocker dans des tables pour pouvoir la visualiser et l’exploiter facilement. Pour cela, on peut utiliser des outils dédiés comme Airbyte, Fivetran, Talend, ou bien créer des solutions 100% custom.

La difficulté ici est qu’il faut toujours s’adapter aux différentes sources de données : en fonction du format des données exposées, l’intégration d’une nouvelle source peut prendre quelques heures à plusieurs semaines. Dans l’idéal, toutes ces sources sont des tables formatées, optimisées, et auxquelles on a déjà les accès. En réalité il est fréquent de se retrouver face à des sources particulièrement complexes, avec des données dé-normalisées (au format json par exemple), stockées dans des dizaines de fichiers, sur des ressources difficiles d’accès (SFTP, bucket). On se retrouve alors contraint de mettre en place des flux très customisés, et donc très chronophages, sur l’implémentation comme la maintenance.

Dans des organisations plus matures, il faudra également réaliser plusieurs fois les mêmes ingestions pour gérer différents environnements de développement. Il faut ensuite identifier comment gérer chaque nouveau batch de données : on peut vouloir écraser les données existantes avec les données ingérées (overwrite), les ajouter au fur et à mesure (append), ou même mettre à jour directement les données qui ont été modifiées (append + overwrite). Ce choix, comme souvent en Data Engineering, est un équilibre à trouver entre les coûts récurrents et la complexité d’implémentation.

Transformer la donnée

Une fois la donnée ingérée et stockée dans des tables, il faut la transformer - la corriger, l’uniformiser, la filtrer et l’agréger - pour la mettre en qualité et la rendre utilisable par les métiers.

Chez Sicara, on utilise principalement la medallion architecture, qui consiste en 3 couches :

• bronze pour les données brutes ingérées
• silver pour les données nettoyées et enrichies
• gold pour les données agrégées - ce sont en général ces données qu’on exposera aux utilisateurs

La medallion architecture (Source)

Entre chaque couche, il y a donc des transformations qui permettent d’affiner la donnée et la rendre de plus en plus proche des besoins utilisateurs.

La difficulté dans l’implémentation de ces transformations vient d’abord des règles de calcul, souvent fournies par les équipes métier de manière approximative. Il faut généralement plusieurs itérations avant d’obtenir le résultat souhaité, ce qui nécessite une bonne agilité. Puis, selon le contexte, c’est l’implémentation qui peut poser problème.

Prenons l’exemple d’une entreprise B2C qui souhaite rassembler tous ses contacts dans une seule Customer Data Plateforme, afin de mettre à jour et exploiter les données client les récentes. Pour certains cas d’usages, on souhaitera avoir une synchronisation en temps réel, et pour d’autres (ex: création de segments pour le marketing), une mise à jour quotidienne est suffisante. Il faut donc gérer ces données clients à la fois en streaming, en incrémental, et en full refresh. Cela nécessite de faire certaines transformations 3 fois, car chaque mode requiert une méthode de calcul différente et parfois même une techno différente (SQL pour le full refresh vs. spark pour le streaming). Il faut donc jusqu’à 3 fois plus de temps pour développer et tester le comportement souhaité.

Il faudra parfois gérer le provisionnement de ressources pour les calculs liés à ces transformations. Certains outils (Snowflake, BigQuery, ...) facilitent cette tâche en prenant en charge la gestion des machines pour un coût supplémentaire. Il faudra donc encore une fois savoir arbitrer entre les coûts récurrents et le temps d’implémentation.

Exposer la donnée

Maintenant que nos données sont propres, qu’elles ont du sens, il faut les mettre à disposition des équipes métier. Selon la maturité data de ces équipes, on choisira en général des les exposer dans un outil de Business Intelligence comme PowerBI, Looker, Tableau, Qliksense, etc. Le choix et la mise en place de ces outils sont relativement standards, et bien que cela prenne un peu de temps, il y a rarement des surprises.

Il nous reste cependant encore des défis à adresser :

• la gestion des droits et des accès, en particulier pour les données sensibles
• la documentation des données, afin qu’elles soient compréhensibles pour tous

Sur certains type de données, il est important voire obligatoire d’avoir des restrictions sur les accès. C’est le cas notamment pour les données personnelles de clients, ou des données financières de l’entreprise comme les salaires. Ces restrictions peuvent être chronophages à mettre en place et configurer selon l’outil, le type de restriction (limiter les accès à des tables / des colonnes vs. création de vues anonymisées) et la taille de l’organisation. Cela nécessite également un flux bien identifié pour octroyer (et mettre à jour) les bons droits aux personnes concernées. Une solution classique est le contrôle d’accès à base de rôles (RBAC) qui permet de définir les permissions de chaque utilisateur via l’attribution de rôles prédéfinis.

Nos utilisateurs ont donc maintenant accès aux données qui les concernent, mais il faut s’assurer qu’ils sont en mesure de les exploiter. Il est essentiel de comprendre comment elles ont été créées, transformées, et comment elle doivent être utilisées. Il faut donc prendre le temps de documenter et mettre à disposition ces informations. Certaines solutions clés en main sont déjà présentes dans les outils classiques de Data Engineering et de BI (ex: data catalog), mais peuvent ne pas être adéquates pour une utilisation des équipes métier. On pourra alors se tourner vers des outils plus orientés projet (Notion, Excel, etc.) pour favoriser l’adoption, avec comme désavantage qu’ils requiert plus de temps pour tout garder à jour.

Maîtriser les coûts

Une data plateforme représente un certain coût à mettre en place, mais aussi à maintenir. Pour réduire les coûts récurrents, le moyen le plus simple est de diminuer l’utilisation des ressources de processing, en optimisant les calculs ou bien en diminuant le volume de données traité. Pour optimiser les calculs, on utilisera des techniques comme le partitionnement, le z-ordering, ou le clustering, qui permettent de trier notre donnée et d’accélérer le temps d’opérations comme des recherches ou des jointures.

On pourra également réduire le volume de données traitées, en passant de traitements en full refresh (tout l’historique) à des traitements en incrémental. Sur des projets à très grosses volumétries, on pourra aussi être confronté à des problèmes de ressources de calcul et de mémoire, qui nécessiteront des compétences en DevOps.

Il arrive également d’avoir des coûts de stockage non-négligeables. Pour y remédier, il est recommandé de bien choisir le type et le mode de stockage (ex: le logical storage dans BigQuery coûte 10 fois plus cher que le physical), et de supprimer ou agréger certaines données historiques. Dans certaines entreprises, il est habituel de ne garder que 2 ans d’historique pour la majorité des données, et d’agréger à une granularité quotidienne voire mensuelle les données qui ont besoin d’un historique plus important.

Gérer les aléas de production

Avant de mettre en production notre data plateforme, il faut anticiper certains problèmes d’exploitation : que faire si un process plante ? Comment gérer les données qui doivent être corrigées ? Ces problèmes requièrent des process rigoureux, et des outils pour les résoudre à moindre effort.

En cas d’incident, le strict minimum à avoir est un moyen de comprendre ce qu’il s’est passé : quel chemin la donnée a pris, quel état avait la donnée à chaque étape du flux. Pour favoriser cette investigation, il est souvent nécessaire d’avoir des logs qui recensent les erreurs et warnings. C’est utile notamment pour les process d’ingestion et de validation de données qui font la passerelle entre les sources et la data plateforme, car ces sources peuvent être difficilement accessibles lors du débogage.

Imaginons un cas d’usage : un membre de l’équipe sales a mal saisi le montant d’un nouveau contrat signé la semaine dernière, ce qui a fait virtuellement augmenter le CA de l’entreprise de 150% dans tous les rapports de performance. La donnée source a été corrigée depuis, mais comme nos transformations sont en incrémental (on reprend les données de la veille uniquement), ces données ne peuvent pas être corrigées par le flux normal. Il faut alors avoir une solution pour recalculer les données sur une plage de dates spécifique, ou bien sur tout l’historique. Il faudra également prévoir un moyen de notifier les personnes impactées par ces modifications, surtout si elles utilisent des extracts de données.

Un des aspects les plus complexes de la production reste la gestion des normes en vigueur, et en particulier celles de la RGPD. Celle-ci impose par exemple de supprimer toutes les données personnelles d’une personne qui le demande, ce qui implique d’avoir un process qui permet de

• savoir quelles sont ces personnes
• supprimer les données personnelles correspondantes

Lorsque ces données sont propagées dans des dizaines de tables, le process de suppression peut devenir très lourd à mettre en place. C’est pour cela qu’il faut anticiper cette problématique en rationalisant l’utilisation des données personnelles, et en mettant en place des flux qui simplifient la suppression ou l’anonymisation.

Conclusion

Chaque étape du flux de déploiement d’une data plateforme est relativement simple, mais peut devenir très complexe selon le contexte. Le nombre et la qualité des sources de données sont un facteur particulièrement impactant, ainsi que le volume de données et leur confidentialité. Dans une entreprise soumise à toutes ces contraintes, il faut faire preuve de rigueur et d’agilité pour avancer, et anticiper les potentiels défis.

Dans la prochaine partie, nous parlerons des 5 défis organisationnels à relever lors de la mise en place d’une data plateforme, pour assurer l’adoption de cet outil. En particulier, nous verrons comment mettre en place des process qui permettent de maîtriser la qualité des données, de mettre en place une data gouvernance et devenir une entreprise data-driven.

Si vous cherchez des experts pour mettre en place votre propre data plateforme, contactez nous !