Nous avons mis en avant Microsoft Clarity comme un produit conçu pour répondre à des cas d'utilisation concrets, par des experts produits qui comprennent les défis rencontrés par des entreprises comme Switas. Des fonctionnalités telles que la détection des clics indésirables et le suivi des erreurs JavaScript se sont révélées précieuses pour identifier les frustrations des utilisateurs et les problèmes techniques, permettant ainsi des améliorations ciblées qui ont eu un impact direct sur l'expérience utilisateur et les taux de conversion.
ETL
L'ETL (Extraction, Transformation, Chargement) désigne le processus qui consiste à extraire des données de systèmes sources, à les convertir en une structure cohérente et à les charger dans une destination telle qu'un entrepôt de données. Il constitue l'infrastructure sous-jacente à l'analyse de données, et sa fiabilité détermine la confiance que l'on peut accorder aux rapports construits à partir de cette infrastructure.
Chaque étape présente des difficultés spécifiques. L'extraction doit récupérer des données provenant de systèmes non conçus pour être interrogés de l'extérieur, en gérant les limitations de débit des API, la détection des modifications incrémentales et les sources qui ne permettent pas d'identifier avec certitude les changements. La transformation doit harmoniser les formats incohérents, les identifiants différents, les définitions contradictoires et les valeurs manquantes. Le chargement doit gérer le volume de données, conserver l'historique et traiter les enregistrements arrivant en retard ou dans le désordre.
La variante ELT inverse les deux dernières étapes : elle charge les données brutes dans la destination et les transforme sur place. Cette approche est devenue courante car les plateformes d'entrepôt de données modernes disposent d'une capacité de traitement suffisante pour une transformation efficace sur site, et parce que la conservation des données brutes permet de réviser et de réappliquer les transformations sans avoir à les extraire à nouveau des sources. De plus, les erreurs de logique de transformation sont ainsi récupérables et non irréversibles.
Le traitement incrémentiel est une nécessité pratique qui complexifie la plupart des implémentations. Retraiter toutes les données historiques à chaque exécution est simple, mais devient impraticable à mesure que le volume augmente. Les pipelines doivent donc identifier les modifications intervenues depuis la dernière exécution. Les sources sans horodatage fiable des modifications, les enregistrements mis à jour rétroactivement et les suppressions sans trace rendent cette tâche plus difficile qu'il n'y paraît, et une logique incrémentielle incorrecte produit des données incomplètes sans avertissement.
La gestion des défaillances détermine si un pipeline est adapté à la production. Les pipelines échouent régulièrement car les systèmes sources modifient leurs schémas, les identifiants expirent, les services en amont sont indisponibles ou des données inattendues arrivent. Il est essentiel que les défaillances soient détectées immédiatement, que les exécutions partielles ne laissent pas la destination dans un état incohérent, que les réexécutions produisent le même résultat sans dupliquer les enregistrements et qu'une personne soit notifiée avant que la défaillance ne soit découverte par hasard, suite à l'affichage d'un rapport anormal.
La validation de la qualité des données doit être intégrée au processus de traitement, et non effectuée après. Vérifier le nombre de lignes par rapport aux attentes, s'assurer que les champs clés sont renseignés, confirmer que les valeurs se situent dans des plages plausibles et tester la cohérence référentielle permet de détecter les erreurs dès leur saisie. Sans ces tests, les données erronées se propagent dans les rapports et influencent les décisions, et elles ne sont généralement découvertes que des semaines plus tard, lorsqu'une personne remarque une valeur incohérente.
La planification et la gestion des dépendances déterminent la cohérence du résultat. Les pipelines s'exécutent rarement de manière isolée ; un traitement en aval qui démarre avant la fin de son traitement en amont produit des résultats partiels qui semblent complets. Des outils d'orchestration permettent d'exprimer explicitement ces dépendances, et les pipelines enchaînés par hypothèse de synchronisation plutôt que par dépendances déclarées présentent des défaillances intermittentes difficiles à reproduire.
La documentation et la traçabilité sont essentielles car les pipelines survivent à leurs concepteurs. Il est indispensable de connaître l'origine de chaque champ, les transformations appliquées et les règles métier sous-jacentes pour comprendre la forme d'une donnée et évaluer l'impact d'une modification du système source. Les pipelines non documentés deviennent des systèmes que personne n'ose modifier, ce qui conduit les organisations à se retrouver avec des pipelines parallèles produisant des résultats contradictoires.
Étant donné que la fiabilité, et non la sophistication, détermine la valeur ajoutée, la rigueur de l'ingénierie appliquée aux pipelines doit être identique à celle appliquée aux logiciels de production. En pratique, les pipelines sont construits et exploités par le développement de produits ou la Département IT, la logique de transformation encodant les définitions métier est spécifiée avec Analyse des données, et il est préférable de convenir des règles de validation avant la mise en place du premier pipeline plutôt que de les ajouter après le premier incident.
Switas vu sur
