Pourquoi des équipes data techniquement excellentes échouent encore

• La valeur d’une équipe data ne vient pas du volume de pipelines, de schémas ou de dashboards produits, mais du changement dans les décisions de l’organisation ; entre les données et l’action, il faut une couche d’interprétation : la perspective
• Data-Perspective-Action est un modèle opérationnel qui consiste à construire des données fiables, à les interpréter selon le contexte business, puis à proposer en continu des actions concrètes
• Dans le 2026 AI & Data Leadership Executive Benchmark Survey, 93 % des leaders data et IA ont cité la culture et la conduite du changement comme principaux obstacles à l’adoption, contre seulement 7 % pour la technologie
• En instaurant des documents hebdomadaires d’une page, un système d’indicateurs clés, une co-conception avec les parties prenantes et la règle d’associer une recommandation d’action à chaque analyse, on peut transformer la perspective en habitude et la relier à de vraies décisions
• À mesure que l’IA génère des pipelines, des analyses initiales et des dashboards, la connaissance métier et la confiance deviennent différenciantes ; les équipes data doivent donc aller au-delà de la livraison de résultats exacts pour construire une réalité partagée

---

Pourquoi Data-Perspective-Action est nécessaire

• La valeur d’une organisation se crée dans les décisions, pas dans les livrables data ; entre la sortie brute et l’action réelle, une couche d’interprétation, la perspective, est nécessaire
• Même une équipe techniquement compétente, avec des données exactes, peut devenir déconnectée des décisions de l’organisation si elle optimise uniquement le volume produit : traitement des demandes, clôture des tickets, livraison de dashboards
• Même des systèmes data bien conçus peuvent être relégués dans les priorités, perdre leur budget ou disparaître lors d’une réorganisation si le lien entre travail et décisions n’est pas ancré dans les habitudes
• Data-Perspective-Action est un framework qui répète délibérément le passage des données à une interprétation assumée, puis à une décision concrète

Le point de départ du framework

• Dans une agence de publicité, le reporting mensuel prenait quatre semaines à produire et était déjà obsolète au moment de sa livraison ; en automatisant le workflow en environ une journée, le temps gagné a été consacré à des modèles prédictifs
• Le modèle n’était pas complexe, mais il montrait les résultats attendus selon les transferts de budget entre canaux, permettant aux clients de voir à l’avance le rendement attendu et de lancer des changements de canaux et des expérimentations
• Cette expérience a fait émerger une séquence allant des données à l’interprétation puis à une décision précise, modèle ensuite appliqué dans plusieurs organisations

Étape 1 : des Data fiables

• La couche Data comprend l’infrastructure, la fiabilité, la cohérence, les flux d’information, les pipelines, les schémas, les modèles et les dashboards ; l’essentiel du quotidien des data engineers et analytics engineers se situe à ce niveau
• On ne peut pas construire de perspective à partir de données non fiables, mais si le travail s’arrête à réception de la demande → traitement → clôture du ticket, la charge d’interpréter des données exactes est transférée à des parties prenantes qui n’y sont pas préparées
• Une équipe avait construit 200 dashboards avec des pipelines et des schémas sophistiqués, ainsi qu’une logique de mise à jour validée, mais seuls 10 étaient consultés avant de vraies décisions
  • Les 190 autres avaient été créés sans accord entre l’équipe data et les parties prenantes sur la décision qu’ils devaient servir
  • Les dashboards inutiles ont été supprimés, mais la cause profonde était l’absence de définition commune de l’objectif du travail
• Si l’on reste dans la couche Data, le backlog et la charge de travail peuvent se maintenir, mais la distance avec les vraies décisions augmente, ce qui rend plus probable la baisse de priorité de l’équipe

Étape 2 : Perspective

• Perspective est la couche qui transforme une équipe qui fournit de l’information en une équipe qui influence l’organisation ; le cœur en est la connaissance métier, qui permet de juger si les métriques suivies conviennent à une décision donnée
• Dans le 2026 AI & Data Leadership Executive Benchmark Survey, 93 % des dirigeants data et IA ont choisi la culture et la conduite du changement comme principal défi d’adoption, contre 7 % pour la technologie
  • Écart entre culture/conduite du changement et technologie : {b:93,7}
  • Il s’agissait du plus grand écart observé en 15 enquêtes annuelles, et la culture ainsi que la conduite du changement sont apparues de façon récurrente comme des obstacles plus importants que la technologie tout au long de la période étudiée
  • Même lorsqu’une organisation investit dans l’infrastructure et les talents, ses résultats restent limités si elle manque de capacité d’interprétation et d’exécution du changement
• À mesure que l’IA permet de créer par prompt des pipelines, des premières analyses et des dashboards, le goulet d’étranglement se déplace de la construction vers la confiance
  • Plus le volume de sorties augmente, plus les garde-fous comme la qualité des données, la gouvernance et une définition claire de la vérité deviennent importants
  • Mick Dreeling, de Netflix, estime que dans un environnement où les parties prenantes interrogent directement des agents, la responsabilité de garantir les bonnes réponses et de relever continuellement les standards incombera probablement à l’équipe de data engineering
  • Shridhar Iyer, de Meta, considère que même si les agents absorbent des connaissances générales, l’expertise métier restera une propriété intellectuelle qui ne disparaîtra pas
• Les professionnels qui développent systématiquement la Perspective gagnent en valeur à mesure que les outils d’IA progressent, tandis que les tâches cantonnées à la couche Data deviennent plus faciles à automatiser

• Le piège de l’objectivité

  • Les spécialistes data peuvent avoir l’impression qu’apporter une interprétation empiète sur le rôle de quelqu’un d’autre, et tomber dans une passivité qui consiste à ne pas ajouter de contexte à l’analyse
  • Les parties prenantes, avec un temps limité et de multiples priorités, finissent par interpréter elles-mêmes des dashboards à moitié compris ou par s’appuyer sur leur intuition
  • Les données ne parlent pas d’elles-mêmes ; si l’équipe data ne les interprète pas avec prudence à partir du contexte et de son expertise, quelqu’un d’autre le fera à sa place

• Le problème de ne pas regarder au-delà de la livraison

  • Même si le pipeline tourne, que le dashboard s’ouvre et que les tests passent, les parties prenantes peuvent télécharger un CSV, l’ouvrir dans Excel, ajouter des colonnes et des formules, puis recréer l’analyse à chaque besoin
  • Ce type de système peut être techniquement sain tout en étant contourné dans la pratique
  • En demandant à cinq parties prenantes quelles décisions elles prennent actuellement et où se situent leurs incertitudes, on peut trouver des problèmes résolubles en un ou deux jours
  • La confiance accumulée en résolvant proactivement de petits problèmes devient la base qui permet à l’équipe data d’être invitée aux réunions avant la décision, et non après

• Entraîner la perspective avec une page hebdomadaire

  • Chaque semaine, rédiger une page en trois parties
    • Résumer en un paragraphe les faits montrés par les données
    • Interpréter en un paragraphe, avec une opinion, ce que cela signifie pour le business actuel
    • Proposer en une ou deux puces concrètes ce qu’il faut faire ensuite
  • Partager cette page avec un manager, un collègue ou un interlocuteur business, puis obtenir un feedback ; répéter ce cycle pendant 3 mois modifie l’intuition sur les données qui comptent vraiment pour les décideurs
  • Le travail le plus important commence avec la proposition d’action ; même si c’est inconfortable, il faut s’entraîner à former sa propre opinion

• Indicateurs macro et micro

  • Les indicateurs macro sont un petit nombre de chiffres clés qui répondent à la question de la santé de l’entreprise ; les indicateurs micro sont les mesures d’entrée qui expliquent les mouvements des macros
  • Monisha Kanoth, d’Apple, considère qu’un indicateur North Star solide, partagé par tout le business, est le fondement de la confiance
  • Pour un responsable marketing qui recevait des données de dizaines de sources, le système de reporting a été reconstruit autour de 3 indicateurs macro et de 5 signaux micro
  • En un trimestre, il est sorti d’une situation où il ne savait pas quels chiffres croire et a pu expliquer précisément, lors des échanges avec le conseil d’administration, ce qui tirait la croissance et ce qui ne le faisait pas
  • Le fait de choisir les indicateurs importants et de prioriser leur intégrité a aussi amélioré la qualité des questions et des réponses de l’équipe data

• Co-concevoir avec les parties prenantes

  • Le lancement de la version 0.8 consiste à montrer le résultat avant qu’il soit terminé et à faire participer les parties prenantes aux 20 % restants de la construction
  • La co-création crée un sentiment d’appropriation, et ce sentiment transforme les livrables en engagements d’action réels
  • Une partie prenante avait listé 100 questions vraiment importantes, et la plupart des questions apparues au cours des années suivantes figuraient dans cette liste
  • Cette liste a servi à la fois de roadmap de construction et d’outil de maîtrise du périmètre
  • Lorsqu’une nouvelle demande arrivait, la question n’était plus de l’accepter ou de la refuser, mais de la comparer aux éléments déjà convenus pour savoir si elle était plus importante

• Faire du récit, pas du lien, le livrable

  • Partager seulement une requête SQL, une feuille de calcul ou un lien vers un dashboard revient à transférer à l’utilisateur le travail d’interprétation le plus difficile
  • Rédiger un récit, même bref, oblige à choisir ce qui compte, à assumer une interprétation précise et à produire un livrable susceptible de recevoir des feedbacks, des objections et des corrections
  • L’IA générative peut servir à affiner les phrases, mais il ne faut pas lui déléguer la réflexion elle-même
  • Écrire est un processus de pensée, et l’IA ne peut pas développer à votre place une perspective propre
  • Si l’on transmet tel quel un récit produit par l’IA sans s’impliquer directement dans la réflexion, on saute la couche Perspective qui s’accumule avec le temps

Étape 3 : Action

• L’écart est important entre une recommandation et sa transformation en vraie décision organisationnelle, et les équipes data ont tendance à sous-estimer le travail nécessaire à cette transition ainsi que leur propre responsabilité
• Le vide entre l’analyse et la réunion de décision doit être comblé par des recommandations claires, une estimation de la taille de l’opportunité et un travail de soutien continu
• Si l’équipe data ne participe pas à cet espace, les interprétations, les intérêts et les calendriers des parties prenantes le rempliront, et l’équipe cédera le contrôle de la partie la plus importante du travail

• La règle : ne pas présenter seulement des données

  • Toute analyse doit inclure une action recommandée ; les données ne doivent pas être présentées seules
  • La contrainte de devoir recommander quelque chose à la fin change le périmètre du travail dès le départ
    • On enquête autour d’une question précise
    • On instrumente les métriques liées à la décision
    • On réfléchit aux informations nécessaires pour faire bouger les dirigeants
  • Dans le cas d’un modèle qui quantifiait une opportunité de croissance mais n’a pas débouché sur une action du leadership, le problème n’était pas l’exactitude de l’analyse, mais le manque de recommandation et de contexte partagé
  • Sauter directement de Data à Action laisse de côté la construction de la relation, la co-création et la confiance, si bien que la recommandation peut rester sans exécution

• Taille de l’opportunité et soutien continu

  • Lorsqu’une analyse fait émerger une hypothèse, l’équipe data doit quantifier elle-même la valeur de l’opportunité et expliquer pourquoi elle doit être priorisée
  • Même si l’estimation peut être fausse, un chiffre concret donne aux décideurs un objet à contester ; une estimation discutable mène plus facilement à une décision qu’une direction floue
  • Une présentation unique ne suffit pas à l’inscrire dans la roadmap, et atteindre la couche Action peut prendre plusieurs mois
  • Il faut maintenir un learning agenda pour suivre les recommandations exécutées et non exécutées, présenter des chiffres actualisés pour les points qui restent importants et continuer à les défendre
  • Si l’on arrête le travail de suivi parce que la première présentation n’a pas été acceptée, on abandonne le travail essentiel qui relie l’analyse à la décision

La structure organisationnelle qui soutient le framework

• L’unité de base idéale consiste à affecter un analytics engineer et un analyste à un domaine business précis
  • L’analytics engineer est responsable de la robustesse du système
  • L’analyste prend en charge le récit, la relation avec les parties prenantes et les recommandations d’action
• Un ingénieur sans partenaire responsable du récit risque de construire pour la complétude plutôt que pour la décision ; un analyste sans partenaire système fiable aura du mal à produire des preuves convaincantes
• Les organisations existantes n’ont pas besoin d’être réorganisées immédiatement : elles peuvent affecter ces deux rôles à un domaine business pendant un trimestre pour valider le modèle, puis l’étendre
• Si le travail d’infrastructure absorbe la majeure partie de la capacité de l’équipe, comme dans une jeune entreprise, on peut, au lieu de créer un duo, protéger du temps pour partager la perspective
  • Organiser chaque semaine une revue business
  • Tenir chaque mois une démo pour des équipes dont on n’est pas directement responsable
• Plus que l’organigramme lui-même, c’est l’habitude de répéter la Perspective qui compte

Un rythme opérationnel qui s’accumule dans la durée

• En répétant chaque semaine le travail de création de perspective et de soutien à l’action, les effets s’accumulent sur des mois et des années
• Plus on participe au processus de décision, mieux on distingue les pipelines dont la raison d’être est floue, les alertes qui relèvent presque du bruit et les investissements d’infrastructure qui seront réellement nécessaires plus tard
• Le rôle de l’équipe data est de construire une réalité partagée dans laquelle les membres de l’organisation peuvent avoir confiance collectivement sur la situation actuelle et ce qu’elle signifie
• Data-Perspective-Action est un modèle opérationnel qui rappelle constamment que le but du travail technique est de meilleures décisions ; les pipelines et les schémas existent eux aussi pour ces décisions