Dans un monde de plus en plus axé sur les données, leur gestion est devenue un enjeu crucial pour les entreprises. Les besoins en business intelligence, en analytique et l’émergence de l’IA génèrent en particulier des projets que nous allons qualifier de data. Malgré la diversité des sujets, ces projets data ont des spécificités communes stratégiques et organisationnelles dont la prise en compte sera un facteur de réussite. Nous aborderons ensuite les enjeux typiques que sont la gouvernance des données et le cycle de vie du produit du projet data.
Stratégie et pilotage des projets data
Étapes de maturité pour de l’analyse data
Vous avez des données et vous voulez maximiser leur utilisation. Cependant, il ne faut pas brûler les étapes. Chaque type d’analyse ne peut être menée à bien que si la précédente est maitrisée sur le même périmètre. Listons-les:
- L’analyse descriptive (que se passe-t-il ?)
- L’analyse diagnostique (pourquoi cela se passe-t-il ?)
- L’analyse prédictive (que va-t-il se passer ?)
- L’analyse prescriptive (que dois-je faire ?)
Par exemple, un projet data peut avoir pour objectif un rapport automatisé d’analyse sur les causes explicatives de variation de la marge mais si la définition de la marge n’est pas actée et suivie de la même manière par tous les intervenants, il y aura de fortes dissonances aux résultats du rapport.
Un cinquième type d’analyse existe. L’analyse cognitive se base sur l’IA, les algorithmes de traitement automatique de langage naturel (NPL) et d’apprentissage profond (Deep Learning). Elle va permettre de collecter et d’analyser les données non-structurées tels que des documents avec texte, des fichiers vidéo ou audio. Attention cependant à la pertinence des réponses et des analyses fournies. Gagnez en maturité sans sauter les étapes y compris avec l’IA.
Indicateurs clé (ROI, KPI)
L’identification des indicateurs clés de performance (KPI) et les calculs de retours sur investissement (ROI) respectent les règles classiques de projet informatique. Efforcez vous de suivre des indicateurs quantifiables. Une des métriques les plus efficaces est le gain de temps sur la tâche préprojet. N’oubliez pas d’évaluer les gains corolaires à votre projet comme l’amélioration de la qualité de données.
L’analyse exploratoire des données, un levier fort de pilotage data
L’analyse exploratoire des données est une étape très importante d’un projet data. Elle va permettre de challenger et d’améliorer vos spécifications. Les résultats pourront même influencer la priorisation des livrables voire des projets data, souvent en ajoutant un chantier de qualité de données.
Approche agile versus waterfall/cycle en V
Quelle approche est la meilleure ? Réponse rapide : Cela dépend de votre projet data, des pratiques de votre organisation comme l’adoption d’un framework SAFe et des inconvénients que vous êtes prêts à gérer pour en atténuer les effets.
Dans les sujets data, le risque de démarrer de manière agile est de devoir remanier sa copie de nombreuses fois à chaque nouvel acteur intégré et d’avoir du mal à obtenir à un consensus sur les métriques. De même, un nouveau besoin peut fortement impacter les choix techniques déjà faits. Cependant, les méthodologies de type SCRUM sont très adaptées aux projets d’analyse data nécessitant un processus de maturation du besoin.
Dans le cas d’un cycle en V, et malgré une analyse exploratoire des données, il y a fort à parier que des découvertes produiront des décalages dans le planning initial. Dans ce cas, faites attention au découragement des utilisateurs qui se sont impliqués fortement dans la rédaction des règles de gestion. Cette approche est pourtant la meilleure pour adresser la transversalité des projets data.
Un projet conséquent peut aussi se penser avec une méthodologie différente suivant ses phases. Par exemple, cycle en V pour l’initialisation d’une plateforme et analyse exploratoire des données puis passage en agile pour la déclinaison opérationnelle subséquente.
Le code
Dans un projet classique, le code est vu comme une métrique forte d’avancement du projet. Dans un projet data, l’incrément qualitatif n’est pas dans le code mais plutôt dans la donnée elle-même. Ne vous inquiétez pas si une partie doit être retravaillée. Cela n’est pas forcément un signe de régression ou de non-qualité. Gardez à l’esprit les objectifs du projet et les indicateurs clés permettant de les atteindre.
La gestion organisationnelle d’un projet data
Les projets data sont, dans leur grande majorité, transverses. La cohérence d’un projet data va nécessiter l’implication et la validation de tous les acteurs clés du périmètre fonctionnel. De nombreux métiers de toute la chaîne de valeur de l’entreprise peuvent être impliqués dans un projet data même s’il apparait comme simple.
Horizontalité
Il faut prêter attention à des acteurs qui auraient a priori les mêmes processus. Il y a fort à parier que des subtilités sont apparues. Elles n’empêchent pas l’opérationnel mais vont avoir un impact fort lors de la convergence des données. Les règles de gestion devront être définies, validées et intégrées par toutes les parties prenantes pour maximiser l’adoption du projet. Un projet data est une très belle opportunité pour uniformiser et industrialiser les processus métier.
Verticalité
Le projet nécessite un sponsor qui a le pouvoir d’impliquer l’intégralité du périmètre fonctionnel. Il doit être garant de la conduite du changement lié au projet data. La non-implication d’une business unit qui va rester sur son tableur historique peut amener à de nombreuses erreurs lors de la consolidation de données pour le management. Il faut cependant faire attention à des choix unidirectionnels qui feraient perdre de l’adhésion au projet aux utilisateurs.
Décisionnel vs Opérationnel
Les sujets data dans leur dimension décisionnelle sont un point de liaison entre management stratégique et management opérationnel. Des arbitrages cohérents doivent être faits. La récupération de données sur le terrain peut avoir un coût opérationnel non justifiable et inversement un manque de données pourrait rendre caduque la création d’un rapport décisionnel.
Charge
Il est tentant de gérer un projet data à la marge de l’opérationnel. Mais si le temps nécessaire n’est pas dédié, le projet a de forts risques de prendre du retard. Ce retard à son tour renforcera négativement la perception du projet data et risquera de provoquer une perte d’adhésion. Investissez le temps nécessaire de vos ressources.
Les profils d’expertise data doivent être intégrés durant les moments pertinents du projet. Rares sont les ressources cumulant les compétences pour construire un projet de bout en bout. Il faudra donc s’assurer de la fluidité des transitions et passations d’information.
La transmission et l’historisation des décisions/règles de gestion passe par une bonne documentation et sa mise à jour. Là encore les ressources adéquates doivent y être affectées avec un temps dédié. Sur le long terme, l’entreprise s’y retrouvera. Une migration ou la recherche d’une anomalie peut rapidement s’apparenter à de l’archéologie.
Le data product owner, ce mouton à 5 pattes
Un data product owner doit avoir une vision produit qui va synthétiser les attentes de toutes les parties prenantes du projet. Il doit être capable de mobiliser les interlocuteurs pertinents et de les mettre autour de la table. Il doit pouvoir comprendre les conséquences de bout en bout de tous les choix faits et les éventuelles incohérences. Son travail permettra souvent de débusquer et de formaliser les règles implicites utilisées dans l’entreprise.
Bref, le product owner de votre projet data aura fort à faire. Il lui faudra avoir une vision sur tous les aspects du projet, l’accès aux différents acteurs et à la documentation adéquate.
La gouvernance de la donnée, le guide du projet data
Qualité de données (GIGO)
« Garbage In Garbage Out ». Il n’y a pas de magie, un projet data dépendra de la qualité de données. Le sujet ne peut être ignoré pour aboutir à l’attendu du projet data. Cependant, il est souvent sous-estimé et retardé. Plus le chantier peut être anticipé mieux c’est. Il est parfois dommage de perdre plusieurs mois de construction d’un historique sain.
Ne criez pas forcément au sabotage ou à la négligence. Si l’on sort d’une autoconsommation des données, c’est-à-dire que l’utilisateur en charge de l’entrée de ces données en est aussi le consommateur direct, on se retrouve souvent face à un historique à reprendre et de nouvelles pratiques à mettre en place. De même, le hacking d’une interface logicielle pour répondre à l’évolution de besoins fonctionnels peut aboutir à des données dégradées.
Le projet data doit être l’occasion de fiabiliser toutes les sources de données et cela dans le temps, avec par exemple des audits de données réguliers et la désignation de data owners portant la responsabilité de la qualité des données de leur périmètre.
La sécurité et le respect des contraintes légales
Le risque fort est de se concentrer sur la qualité de données et de survoler tous les autres aspects. Bien sûr, tout le monde sait qu’il faut respecter le RGPD mais Il est nécessaire de construire dès le début du projet data les documents de gouvernance adéquats. Ils devront accompagner toutes les décisions suivantes et évoluer en fonction des choix faits. Si l’entreprise est peu mature sur le sujet, il est d’autant plus nécessaire de démarrer ces sujets. Acceptez un document non exhaustif qui va grandir à chaque nouveau sujet.
Un projet data a pour nature de transmettre de l’information en dehors des sources où celle-ci a été générée. Au cours de la vie du projet, il sera tentant de se simplifier la vie pour gagner du temps ou débloquer une situation que ça soit par exemple sur des droits d’accès ou l’anonymisation de jeux de données en disant qu’on traitera le point après. C’est une erreur qui peut avoir des conséquences extrêmement fâcheuses. Ne faites pas de votre responsable sécurité et votre responsable juridique des ennemis mortels.
Cycle de vie du produit d’un projet data
Pérennisation de la valeur acquise
On peut considérer que si l’on dépasse la quinzaine d’utilisateurs des outils data, il est nécessaire d’avoir en interne une référence pour répondre aux questions transverses et garante des impacts sur toute la chaine. Les rôles de data stewards et de data owners permettront de fiabiliser dans le temps les usages data. La maintenance de la base documentaire est vitale pour rendre votre projet pérenne. La connaissance personnelle d’un collaborateur ne peut s’y substituer même si elle est redondante entre plusieurs individus. L’IA générative peut vous assister sur le sujet.
Maintenance en conditions opérationnelles
Les projets data sont propices à subir les conséquences d’évolutions des éléments qui les constituent que ce soient les outils informatiques (directement ou dans leur manière d’être utilisés), leurs connecteurs, les sources de données externes. La maintenance en conditions opérationnelles peut être externalisée. La clé est encore une fois la documentation qui doit s’enrichir à la suite des résolutions d’incidents.
Suivi du coût de fonctionnement
Le cloud a un coût de démarrage de stockage et de puissance de calcul très accessible. Mais il est nécessaire de suivre et prévoir l’évolution de ses coûts car les usages et les volumes iront croissants. Une stratégie de distinction des données chaudes ou froides peut par exemple permettre de mettre en place une rationalisation de ces coûts. Dans les plus grandes structures, les opérations financières (finops) impliqueront les différents services dans la responsabilisation et la prise en charge des coûts du cloud.
Évolutions
Un projet data est fortement sujet aux évolutions. D’une part, le besoin va souvent murir avec le temps. Par exemple, un rapport d’analyse descriptive bien utilisé amènera souvent le besoin d’inclure des éléments d’analyse diagnostique. C’est une preuve que votre rapport est réussi. D’autre part, la vie de l’entreprise amènera la nécessité de modifications telles que l’ajout d’une nouvelle ligne de production à suivre, une nouvelle segmentation marketing ou une nouvelle réglementation comme l’IA act. Prévoyez un budget pour que vos projets data restent pertinents.
Conclusion
Un projet data reste fondamentalement un projet informatique. Sa transversalité et les enjeux sur les données nécessitent une gestion rigoureuse pour assurer son succès. Les sujets abordés dans cet article n’ont été qu’effleurés, c’est la limite de l’exercice. Cependant, l’application de ces bonnes pratiques de projet data à votre contexte et vos objectifs devrait vous éviter quelques écueils dans la valorisation des données pour votre entreprise.
Merci à Horacio Lassey-Assiakoley, Architecte Data chez Komeet Technologies pour une discussion qui m’a amené l’idée de cet article.
