Comment construire une stratégie data pour de meilleures décisions

La plupart des documents que l’on appelle « la stratégie data » se révèlent, à l’examen, être une liste de courses d’outils avec une diapo de vision en haut. Un nouvel entrepôt, un nouvel outil de BI, un nouveau pipeline ELT, un nouveau catalogue, parfois une passerelle LLM, le tout sous un titre qui parle de « devenir data-driven ». Le document ne répond jamais vraiment à la question qui décide si tout cela produit de la valeur : quelles décisions l’organisation veut-elle améliorer, et que faudrait-il que ses données soient pour que cela arrive.

Le résultat est un schéma récurrent. Les outils sont achetés. Les tableaux de bord sont construits. Le volume de reporting monte. Les vraies décisions métier, celles qui font bouger le chiffre d’affaires, les coûts, le risque ou les résultats de mission, continuent à être prises de la même façon qu’avant, sur les mêmes intuitions et les mêmes informations partielles. Une vraie stratégie data part de plus en amont : des décisions que l’organisation essaie d’améliorer, et remonte vers les données, les systèmes et les capacités qui rendraient ces décisions plus tranchantes.

Cet article est la version leadership de cette conversation. Il s’associe à l’article sur les symptômes d’architecture de base, qui catalogue les signaux d’ingénierie qu’une couche de données demande de l’attention ; ici, l’angle est la couche stratégique au-dessus, où la première décision à prendre est de savoir à quoi sert la donnée.

Cinq questions, tranchées par écrit et au bon niveau hiérarchique, séparent une stratégie d’une short-list d’outils.

La première : quelles décisions essayons-nous de mieux prendre, et à quelle fréquence. Une stratégie data qui ne peut pas lister les décisions sur une seule page n’est pas encore une stratégie. Des décisions de pricing prises tous les mois. Des décisions de capacité prises tous les trimestres. Des décisions d’allocation de programmes prises tous les ans. Des décisions de segmentation client qui pilotent les dépenses marketing. Chacune a une cadence, un propriétaire, et une définition de « meilleur » que la donnée est censée soutenir. Sans cette liste, chaque tableau de bord est plausible et aucun n’est essentiel.

La deuxième : que faudrait-il que la donnée soit pour que ces décisions soient plus tranchantes. Parfois la réponse est « on l’a, mais on ne peut pas lui faire confiance ». Parfois c’est « on en a des morceaux dispersés sur cinq systèmes ». Parfois c’est « on ne la collecte pas du tout ». La réponse honnête est rarement « on a un problème d’outillage » ; c’est généralement un problème de source, de propriété ou de définition.

La troisième : qui possède chaque jeu de données, de bout en bout. Pas « l’équipe data », mais une fonction ou une personne nommée qui est redevable de l’exactitude, de la fraîcheur, des définitions et de l’accès au jeu de données. La plupart des plaintes « la donnée est fausse » sont en réalité des plaintes « la donnée n’a pas de propriétaire ».

La quatrième : dans quoi nous n’investissons délibérément pas. La stratégie qui dit oui à tout est une liste de souhaits. Une vraie stratégie nomme les domaines de données qui n’auront pas d’attention cette année, les tableaux de bord qui ne seront pas construits, les intégrations qui n’auront pas lieu, pour que le travail qui se fait ait la capacité dont il a besoin.

La cinquième : comment saurons-nous que ça a marché. Les meilleures décisions sont difficiles à mesurer directement, mais les indicateurs avancés, eux, ne le sont pas. À quelle vitesse un dirigeant obtient-il la réponse à une question récurrente. À quelle fréquence une décision est-elle reportée parce que la donnée n’est pas prête. À quelle fréquence les mêmes chiffres sont-ils demandés par e-mail au lieu d’être tirés d’un tableau de bord. Ce sont les métriques qui disent si la stratégie data fait son travail.

L’erreur la plus courante au niveau leadership, c’est de commander des tableaux de bord avant que la décision qu’ils soutiennent ait été nommée. L’ordre inverse est celui qui fonctionne.

Pour chaque décision que la stratégie liste, trois artefacts ferment la boucle. La décision elle-même, écrite en une ou deux phrases, possédée par un rôle nommé, avec une cadence (mensuelle, trimestrielle, à la demande). L’input dont la décision a besoin, écrit comme le plus petit ensemble possible de chiffres ou de signaux qui changeraient réellement la décision. Et la surface de livraison, qui peut être un tableau de bord, une alerte automatisée, un digest e-mail, ou un point d’ordre du jour de cinq minutes en réunion ; la bonne surface dépend de la décision et de la cadence, pas des défauts de l’outil.

Cette séquence attrape les tableaux de bord qui paraissent impressionnants et qui ne servent à personne. Si aucune décision ne change quand le chiffre du tableau change, le tableau est de la décoration. La correction est rarement un meilleur tableau ; c’est de prendre du recul et de retrouver la vraie décision que l’équipe pensait soutenir, ou de retirer le tableau.

Une stratégie data qui ne nomme pas un système de référence pour chaque fait important n’est pas encore applicable. « Le nombre de clients » vient de quelque part. « Le chiffre d’affaires de ce trimestre » vient de quelque part. « Les utilisateurs actifs la semaine dernière » viennent de quelque part. Quand la réponse est « ça dépend à qui tu demandes », l’organisation a un problème de gouvernance, pas un problème d’outillage.

Une gouvernance utile au niveau leadership est étroite et concrète. Pour chaque métrique business critique, nommez le système source, le propriétaire, la définition (actif veut dire quoi, exactement), la cadence de rafraîchissement, et le chemin que prennent les copies de la métrique à travers le reste de la stack. Deux métriques avec le même nom et des définitions différentes dans différents tableaux de bord est la cause la plus courante de méfiance des dirigeants envers la data, et c’est un problème de définitions qu’aucun entrepôt ne corrigera.

L’autre moitié, c’est l’accès. Qui peut lire un jeu de données, qui peut changer sa définition, qui peut publier un tableau dérivé, et quel processus de relecture s’applique. Un accès trop large produit cinq versions contradictoires de la même réponse. Un accès trop strict produit une file d’attente devant l’équipe data. Le bon réglage est entre les deux, et c’est une décision leadership, pas une décision technique.

Une stratégie data qui ignore la capacité que l’organisation a réellement est une liste de souhaits. Trois questions honnêtes font généralement remonter l’écart.

Quels rôles l’équipe a-t-elle besoin qu’elle n’a pas aujourd’hui, et lesquels parmi eux faut-il recruter, externaliser ou former. La plupart des organisations sur-recrutent des constructeurs de tableaux de bord et sous-investissent dans le rôle d’analytics engineer qui fait le pont entre les systèmes sources et la surface où les décisions se prennent.

Quel outillage l’organisation achète-t-elle versus construit-elle. Le défaut de tout acheter a des coûts cachés (verrouillage fournisseur, taxe d’intégration, données qui quittent l’organisation par des chemins inattendus) ; le défaut de tout construire a d’autres coûts cachés (feuille de route pluriannuelle, capacité d’ingénierie rare, l’équipe qui devient une équipe d’outillage). La bonne réponse est rarement le tout-l’un ou le tout-l’autre.

Qu’est-ce que l’organisation opère aujourd’hui, et qu’est-elle prête à opérer demain. Une stratégie qui dépend d’un entrepôt auto-hébergé, d’un catalogue auto-hébergé, d’un outil de BI auto-hébergé et d’un reverse-ETL auto-hébergé s’engage à opérer quatre produits. La plupart des organisations ne le peuvent pas, et devraient être honnêtes là-dessus au stade de la stratégie plutôt qu’au stade de l’incident.

Un nombre étonnant de stratégies data traitent le reporting et l’analytics comme la même activité. Ce ne sont pas la même, et les confondre est la manière dont les organisations finissent avec un outil de BI qui est mauvais sur les deux.

Le reporting répond à des questions connues sur une cadence connue. Le rapport hebdomadaire des ventes. Le scorecard exécutif mensuel. Le fichier trimestriel pour le régulateur. Le public est large, les questions sont stables, et la barre de fiabilité est haute. Le bon outil pour le reporting est celui qui livre des sorties cohérentes, rafraîchies dans les délais, aux personnes qui en ont besoin, avec aussi peu de temps d’analyste sur mesure que possible par cycle.

L’analytics répond à de nouvelles questions. Pourquoi le chiffre d’affaires a-t-il baissé sur ce segment le mois dernier. Qu’est-ce qui a changé dans le funnel après la refonte. Quels comportements client prédisent le churn. Le public est petit (un ou quelques enquêteurs), les questions ne sont pas stables, et la valeur vient de la rapidité avec laquelle on passe de la question à une réponse crédible. Le bon outil pour l’analytics est celui qui soutient l’exploration : SQL ad hoc, notebooks, itération rapide sur l’entrepôt.

Une stratégie qui nomme les deux métiers séparément, avec un outillage séparé et une propriété séparée, produit moins de compromis qu’une qui demande au même outil de faire mal les deux.

Une stratégie data n’est pas une liste d’outils, une présentation de vision, ou une migration d’entrepôt. C’est le document qui décide quelles décisions l’organisation essaie de mieux prendre, ce que la donnée devrait être pour que cela arrive, qui possède chaque morceau, et ce dans quoi l’organisation choisit délibérément de ne pas investir cette année. Les organisations qui obtiennent une valeur mesurable de leur data ne sont pas celles avec le plus de tableaux de bord ; ce sont celles dont la stratégie est suffisamment précise pour qu’on puisse réellement être en désaccord avec elle, et dont l’ingénierie et la gouvernance sont dimensionnées pour la délivrer vraiment.

Le contexte plus large, dont les décisions d’ingénierie et opérationnelles qui transforment une stratégie data en quelque chose qui tourne en production, est rassemblé dans le cluster systèmes de données et performance. Et lorsque la question passe de « il nous faut une stratégie data » à « nous en avons une et il nous faut maintenant quelqu’un pour concevoir les tableaux de bord, les workflows analytiques et la gouvernance qui la font vivre », c’est exactement ce sur quoi mon accompagnement analyse de données et aide à la décision est centré.