On demande souvent à l’Analytics Engineer de « livrer les données ». La formule est pratique, mais elle cache l’essentiel. Personne ne veut vraiment des données : on veut une réponse, une décision plus sûre, une réunion qui ne tourne pas au débat sur la bonne définition du chiffre d’affaires.
Les UX Designers connaissent bien ce décalage. Leur travail commence rarement par l’écran ; il commence par une personne, une situation et un problème souvent mal formulé. Cette façon de penser, que l’on regroupe sous le nom de Design Thinking, a beaucoup à offrir à ceux qui construisent des modèles de données.
Un modèle de données est une interface
Une table finale, un tableau de bord, une métrique partagée : tous ont des utilisateurs. Ils les lisent, les interprètent, les combinent, parfois de travers. Chaque nom de colonne est un libellé. Chaque description est une microcopie. Chaque jointure ambiguë est une friction.
Vu sous cet angle, une table de cent quarante colonnes n’est pas « complète » : elle est difficile à utiliser. Une métrique sans définition écrite n’est pas « flexible » : elle est fragile.
« Personne ne veut vraiment des données. On veut une réponse, et la confiance d’agir. »
La différence ne tient pas aux outils. Elle tient au moment où l’on se pose la question de l’usage : avant d’écrire la première ligne de SQL, ou après la troisième réunion de clarification.
Cinq étapes, deux métiers
Les étapes classiques du Design Thinking se transposent presque mot pour mot au travail de modélisation. Le tableau ci-dessous n’est pas une méthode figée ; c’est une grille de lecture.
| Étape | En UX Design | En Analytics Engineering |
|---|---|---|
| Empathie | Observer et interroger les utilisateurs | Comprendre qui lira le modèle, et pour quelle décision |
| Définition | Formuler le problème à résoudre | Écrire la question métier avant la requête |
| Idéation | Explorer plusieurs pistes | Comparer plusieurs grains et plusieurs structures de tables |
| Prototype | Maquetter rapidement | Livrer une première version restreinte, sur quelques métriques |
| Test | Observer l’usage réel | Vérifier que le modèle est compris, et réellement utilisé |
La documentation comme microcopie
En design d’interface, un bon libellé évite un ticket au support. En Analytics Engineering, une bonne description évite le message « tu peux m’expliquer cette colonne ? ». Des outils comme dbt permettent de documenter chaque modèle et chaque colonne à côté du code. Encore faut-il écrire pour le lecteur, et non pour soi.
version: 2
models:
- name: fct_commandes
description: >
Une ligne par commande validée. Sert à suivre le
chiffre d'affaires net, jour par jour, par canal.
columns:
- name: commande_id
description: Identifiant unique de la commande.
data_tests:
- unique
- not_null
- name: montant_net_eur
description: >
Montant payé par le client, hors taxes et après
remises, en euros. Commandes annulées exclues.Rien de spectaculaire ici. Seulement deux choix : dire ce que représente une ligne, et préciser ce qui est exclu. Ce sont exactement les questions que se posera la personne qui utilisera la table.
Ce que l’on gagne
Penser comme un designer ne ralentit pas le travail ; cela déplace l’effort. Un peu plus d’écoute au début, beaucoup moins de corrections ensuite. Et la conversation avec le métier change de nature : on ne parle plus de colonnes, on parle de décisions.
Le meilleur Analytics Engineer n’est peut-être pas celui qui connaît le plus de fonctions de fenêtrage. C’est peut-être celui qui sait poser la bonne question, au bon moment, à la bonne personne.
« Une réflexion à partager ? »
Votre message est envoyé directement à l’auteur. Il n’est jamais publié.
