Data et systèmes analytiques

Un projet data commence facilement par un inventaire : quelles bases avons-nous, quels exports pouvons-nous récupérer, quels systèmes pouvons-nous connecter ?

Ce n’est pas forcément le bon point de départ.

Nous préférons commencer par ce que le système doit permettre : suivre une activité, comparer des scénarios, détecter une anomalie, alimenter une interface métier, automatiser une décision ou donner du contexte à un modèle d’IA.

À partir de cet usage, on peut remonter vers les données nécessaires, leurs sources, leur niveau de qualité attendu et la manière dont elles devront être servies.

Cela évite notamment de passer des mois à centraliser des informations dont personne ne sait encore quoi faire. Centraliser toute la donnée n’est pas une stratégie data : une plateforme utile commence par les usages qu’elle doit rendre possibles.

Collecter une donnée et la déplacer d’un système à un autre n’est qu’une partie du problème.

Pour qu’elle devienne réellement exploitable, plusieurs couches doivent fonctionner ensemble.

Les problèmes les plus difficiles ne sont pas toujours techniques.

Deux équipes peuvent disposer exactement des mêmes données et produire deux chiffres différents parce qu’elles ne mettent pas la même réalité derrière un mot comme « client », « revenu », « produit actif » ou « conversion ».

Une plateforme data doit donc aussi établir un langage suffisamment explicite autour de l’information : quelle est la définition d’un indicateur, quelle source fait référence, comment ce chiffre a été calculé, de quelle donnée initiale il provient et qui peut y accéder.

Sans cette couche sémantique, une organisation peut disposer d’une excellente infrastructure tout en continuant à débattre de la fiabilité de ses chiffres.

La traçabilité compte pour la même raison : lorsque quelque chose paraît incorrect, il faut pouvoir remonter de l’information affichée jusqu’à sa source et comprendre les transformations qui ont été appliquées.

Un système data est souvent pensé depuis son infrastructure : warehouse, lake, pipelines, transformations.

Son architecture doit aussi être pensée depuis l’autre extrémité : qui va consommer cette information, et comment ?

Un analyste qui explore librement des données, un commercial qui doit prendre une décision en trente secondes et un agent IA qui a besoin d’un contexte précis n’ont pas les mêmes besoins.

Cela détermine directement le niveau d’agrégation, la fraîcheur nécessaire, la latence acceptable, les droits d’accès, les APIs à exposer et la manière dont l’information est préparée et présentée.

C’est une des raisons pour lesquelles nous considérons les systèmes analytiques comme des produits à part entière, et pas uniquement comme de l’infrastructure. L’interface compte autant que le pipeline lorsqu’elle constitue le point de contact entre la donnée et le métier.

Les progrès récents des modèles de langage peuvent donner l’impression qu’il devient possible d’interroger n’importe quelle information sans avoir à la structurer auparavant.

Ils déplacent surtout le problème.

Un modèle peut faciliter l’accès à une information complexe, rapprocher des sources ou produire une synthèse. Mais il doit toujours savoir quelles données utiliser, lesquelles sont fiables, auxquelles l’utilisateur a droit et dans quel contexte les interpréter.

Plus un système IA devient capable d’agir à partir de la donnée de l’entreprise, plus ces questions deviennent importantes.

C’est le lien direct avec notre expertise IA appliquée et agents : le modèle apporte une nouvelle capacité d’interaction ou de raisonnement, mais la qualité du système dépend largement de la donnée métier qui l’alimente.

Une pipeline qui fonctionne aujourd’hui n’est pas terminée.

Les sources évoluent. Des champs disparaissent. Les volumes augmentent. Les définitions métier changent. De nouveaux usages apparaissent.

Un système data doit donc permettre de comprendre rapidement qu’une source ne se met plus à jour, qu’une transformation produit un résultat inhabituel, qu’un volume évolue brutalement, qu’un traitement devient trop lent ou trop coûteux, ou qu’un changement a modifié un indicateur important.

L’observabilité n’est pas là pour produire un dashboard supplémentaire. Elle permet de savoir si la donnée sur laquelle l’organisation s’appuie mérite encore sa confiance.

C’est également ici que le sujet rejoint notre expertise architecture et engineering produit : automatisation, environnements reproductibles, déploiement, sécurité, supervision et documentation sont aussi nécessaires aux systèmes data qu’aux applications qui les consomment.

Comme pour l’architecture logicielle, nous ne croyons pas à une stack data universelle.

Une organisation n’a pas systématiquement besoin d’un data lake, d’une plateforme temps réel ou de dizaines de pipelines indépendants.

La bonne architecture dépend de la fréquence à laquelle les données changent, du volume traité, du nombre de sources, des usages attendus et des conséquences d’une information incorrecte.

Certains besoins se satisfont parfaitement d’un système relativement simple. D’autres nécessitent une chaîne beaucoup plus structurée. Le rôle de l’engineering est de savoir distinguer les deux.

La sophistication d’une plateforme data doit être proportionnée aux usages qu’elle sert.

Ces problématiques reviennent dans plusieurs projets Vezero, sous des formes très différentes. Les contextes changent, mais la question reste la même : comment transformer les données disponibles en un système suffisamment fiable pour que le métier s’en serve ?

Nous évaluons finalement un système data moins à la quantité d’informations qu’il stocke qu’à sa capacité à rendre ces informations exploitables.

Les utilisateurs trouvent-ils la bonne information ? Comprennent-ils ce qu’elle signifie ? Peuvent-ils lui faire confiance ? Peut-elle alimenter correctement une application, une décision ou un modèle ? Et lorsque quelque chose change, l’équipe est-elle capable de comprendre pourquoi ?

Une bonne plateforme data ne cherche pas à tout centraliser. Elle rend les bonnes données disponibles, compréhensibles et fiables au moment où elles deviennent utiles.