À l'ère du Big data et plus encore de l'IA générative et agentique. Livrer un projet ne suffit plus. Les organisations doivent repenser l'ensemble de leurs processus pour livrer en continu, au rythme de l'évolution des besoins métiers.
Il arrive trop souvent que des dashboards soient livrés, puis ouvert à peine 2 fois et tombent finalement dans l'oubli. Pourquoi ? La raison est simple : Ces dashboards répond à une demande figée dans le temps et conçu comme un livrable ponctuel.
C'est un vrai problème car les données utilisés pour créer ces indicateurs deviennent rapidement obsolètes. Ainsi, les équipes métiers renouvellent les mêmes requêtes et les divisions techniques croulent sous les demandes et ne sont en mesure de livrer dans les temps.
C'est un cercle vicieux. On est dans un véritable goulot d'étranglement, tout le monde s'épuise et la valeur de de la donnée s'érode progressivement.
Le Data Product Management : une nouvelle manière de travailler
Grâce aux récentes innovations technologiques issus du Machine Learning notamment, de nombreux outils (Power BI, Looker...) ont désormais la capacité d'analyser de larges volumes de données provenant de nombreuses sources.
Ainsi, l'enjeu principal pour les organisations était de construire toute l'infrastructure permettant d'ingérer toutes ces données en grande quantité puis de les transformer afin de les optimiser pour l'analyse de données.
Une fois ces nouvelles données ingérées, que fait-on ? Eh bien, il faut tout simplement valoriser la donnée. En effet, une donnée brute n'a de valeur que si elle éclaire une décision. Concrètement, que les métiers comprennent ce qu'ils regardent, qu'ils fassent confiance à la donnée, et qu'ils sachent en tirer une décision.
Ces trois conditions ne se décrètent au moment de la livraison. Elle se construisent dans la durée.
C'est tout l'enjeu du data product management. On ne construit plus livrables mais des produits. C'est-à-dire que la mise en production n'est plus la fin du projet, mais le début d'un cycle du produit.
Les caractéristiques d'un Data Product
Contrairement à un livrable, un produit possède plusieurs propriétés indissociables :
- Il répond à un usage et un besoin identifié qui existe parce qu'une décision ou une action en dépend et non pas parce qu'une requête a été formulée un jour.
- Il a un responsable, généralement un Product Owner qui arbitre les évolutions et porte sa valeur
- Il est fiable, les données utilisées sont documentées, à jour et leur qualité est vérifié en continu.
- Il est trouvable, c'est à dire que l'ensemble des utilisateurs savent qu'ils existent, où le trouver..
- Il est mesuré, son adoption est suivie au quotidien ainsi que sa valeur réelle
- Il a une feuille de route, il peut aussi être retiré quand il ne sert plus.
Ensemble, ces caractéristiques forment un véritable contrat de confiance entre équipes techniques et équipes métiers. Chacun sait ce qu'il peut attendre de l'autre : les demandes redondantes disparaissent, et les échanges gagnent en transparence.
L'IA et les métiers, deux forces qui imposent le virage produit
L'accélération de l'IA pousse les entreprises à repenser leurs processus dans leur globalité.
D'une part, les techniques d'apprentissage issues du Machine Learning sont de plus en plus gourmandes en données. La performance d'un modèle d'IA dépend directement des données qui l'alimentent : un volume massif ne sert à rien si la donnée est incomplète, mal documentée ou obsolète.
L'IA exige une donnée fiable, disponible et entretenue dans la durée. Autrement dit, elle exige des produits, pas des livrables.
D'autre part, les métiers souhaitent moins dépendre des équipes techniques. Concrètement, les directions imaginent leurs propres cas d'usage et réclament en parallèle un accès direct à la donnée. Sans cadre, on multiplie les versions concurrentes d'un même indicateur et plus personne ne sait à quel chiffre se fier.
Les challenges de l'adoption du Data Product Management
Adopter le Data Product Management ne se décrète pas : la transition est progressive et se heurte à plusieurs obstacles.
Les organisations savent lancer et clôturer des projets mais expriment de difficultés quand il faut faire vivre un produit qui n'a pas de date de fin définie au préalable.
De plus, les budgets sont souvent pensés en enveloppes projet, alors qu'un produit coûte en run, en maintenance et en évolution.
L'absence de responsable d'un produit qui porte le besoin entraîne l'échec du développement continue du produit. Mesurer sa valeur est tout aussi complexe : il est en effet beaucoup plus difficile de prouver qu'ils changent les décisions.
Enfin, le Data Product Management fait appel à des compétences hybrides : il faut des profils capables de dialoguer à la fois avec les métiers, les équipes techniques et la gouvernance.
En conclusion, le Data Product Management s'est imposé en réponse à l'accélération de l'IA et à la demande d'autonomie des métiers. Son intégration dans les processus internes représente un défi aux multiples visages : culturel, financier et organisationnel.
Mais ce défi en dit long sur sa nature. Adopter le Data Product Management ne consiste pas à renommer des projets en produits ni à créer un nouvel intitulé de poste. Il s'agit de changer de regard sur la donnée : la considérer non plus comme un livrable que l'on remet, mais comme un actif que l'on fait vivre.