L’approche Agile appliquée à la Data
Un projet de transformation numérique ne se gère pas comme un programme informatique traditionnel. Il fait appel à de nouvelles compétences et fait émerger par nécessité des formes nouvelles d’organisation. La Fonction SI doit travailler au plus près des Métiers, en mode agile et sur des cycles courts. L’équipe SI doit s’appliquer à développer la transversalité et donner les moyens aux équipes IT de mieux comprendre et anticiper les besoins autour de la data, les impacts sur les métiers de l’entreprise et les enjeux de transformation associés, et y répondre vite tout en étant le garant de la cohérence et de la robustesse de l’écosystème IT. Cela implique de faire évoluer les échanges avec les métiers sur la valeur des projets de transformation autours de la DATA. (Ref : Cigref : « Réussir le numérique »)
Les projets ou initiatives de transformation numérique impliquent des modes de fonctionnement différents de ceux appliqués aux projets classiques.
Adapter Agile aux projets Data
Concrètement la méthode Agile doit être adaptée dans le contexte d’un projet autour de la Data. Prenons l’exemple d’un projet de Data Science qui dans un contexte Agile impliquera un effort d’adaptation important. La différence fondamentale entre un projet Data (type DS) et un projet Java (par exemple écriture d’une IHM en JAVA ), réside principalement dans le fait qu’un projet Data comporte une phase exploratoire très importante similaire à ce qui se pratique dans les projets de R&D. L’absence de résultat dans cette phase est un résultat en soit. En d’autres termes, ce qui caractérise souvent un projet Data c’est l’absence d’un résultat convenu à l’avance.
Comme dans un contexte R&D, le départ d’un projet repose souvent sur une hypothèse de travail qui doit être validée / vérifiée ou invalidée concrètement dans les données en obtenant un résultat ou une « piste » exploitable par les métiers.
L’itération, une posture méthodologique essentielle dans un projet Data
Le cadre des projets Data implique une phase d’exploration des données relativement importante comparativement à un projet logiciel. Dans la mesure où les pistes intéressantes proviennent rarement de la première requête, il sera nécessaire de penser très tôt, avant même l’apparitions des premiers résultats tangibles, à confronter les résultats de cette première phase exploratoire avec le terrain et par conséquent, de solliciter régulièrement les retours des sachants métiers.
Dans cette phase itérative, il est essentiel de documenter les travaux réalisés et de partager cette documentation (même à l’état de « draft » ) avec l’écosystème élargi du projet. Le diagramme ci-dessous présente un processus de type Agile autour d’un projet Data. Ce processus comporte deux boucles itératives, la première concerne la partie exploratoire du projet. L’exploration des données permet d’opérer un sondage ayant pour objectif d’appréhender les données et de comprendre leur organisation et niveau de qualité. Cette phase est généralement très chronophage (elle peut représenter 90% du temps passé sur le projet) et permet de garantir la possibilité d’un résultat final exploitable. C’est dans cette phase que peuvent surgir les difficultés majeures en ce qui concerne la compréhension des données et leur exploitabilité.
Cette étape doit donc donner lieu à des arbitrages visant à réorienter les recherches sur d’autres corpus de données si l’exploration s’avère infructueuse. Bien entendu, l’orientation appliquée à la phase exploratoire et notamment la question du choix des sources de données à explorer, doit être une décision collégiale basée sur l’écoute et la prise en compte de l’avis des métiers, de l’équipe IT et de l’équipe data.
A ce stade, il me semble important de préciser que, de la connaissance des données dépendra la qualité et la valeur des résultats finaux. Pour garantir un bon niveau de résultat il est impératif de mettre en place bien en amont du projet une équipe data dédiée. Dans certaines entreprises (notamment certaines administrations américaine) il existe un rôle clé autours des projets Data : le Data facilitator*. Ce rôle est un rôle transverse dédié à la réussite des projets de ce type. Les champs d’action de ce rôle sont multiples et décisifs à la réussite des projets.
Champs d’actions du « Data facilitator » :
- Connaissance des données (donner un sens)
- Accompagnement des équipes métier
- Médiatisation des données (formation et circulation de l’information sur les data)
- Usages, conseil sur les usages et « best practices »
- Qualité des données
- Outillage et technique, connaissance des techniques d’exploration des données
Faciliter la connaissance des données avec le dictionnaire
Dans l’entreprise, lorsque le corpus des données devient conséquent (des centaines voire des milliers de champs et variables), l’équipe data, l’IT, le Data facilitator et les métiers devront pouvoir s’appuyer sur une documentation fiable et à jour. Une bonne pratique consiste à maintenir un dictionnaire des données qui doit devenir la base des connaissances orientées data de l’entreprise. Le dictionnaire en question doit se matérialiser sous la forme d’un portail et peut ainsi devenir le socle à toutes interrogations autour des données de l’entreprise.
Le maintien et l’alimentation de ce dictionnaire doit être fréquent et concerner l’ensemble du corpus des données exploitées. Dans beaucoup d’organisation, le dictionnaire des données n’est qu’un amas de connaissance technique et descriptif de la nature des champs. Cette approche n’est pas opérante et ne permet pas de maintenir un niveau de connaissance exploitable dans le cadre d’un projet orienté donnée. Il est donc nécessaire d’enrichir le dictionnaire des données avec les connaissances fonctionnelles et organisationnelles de l’écosystème, à savoir pour chaque champ :
- Le nom du responsable de cette donnée
- Les processus générant cette donnée
- Le nom du responsable de ce processus
- Les processus et objets consommant cette donnée
- Description fonctionnelle de cette donnée
- Nature technique de la donnée
- Fréquence de mise à jour
- Règles de gestion
- etc …
La collecte des informations ci-dessus permettra à l’entreprise ou à l’organisation de garder une connaissance et une maîtrise du corpus des données, de plus, ce type de base de connaissance est un accélérateur de projet dans la mesure où le dictionnaire permet aux nouveaux membres des équipes de monter plus rapidement en compétence sur la connaissance de l’entreprise et de son organisation. Il est également important de noter que, la création d’une base de connaissance orientée data permet de garder la maîtrise du sens des données présentes dans les bases du SI.
En effet, il n’est pas rare de rencontrer des situations où des données sont utilisées depuis parfois des années dans les processus métier de l’entreprise et où personne ne sait comment est calculée cette donnée bien qu’elle soit utilisée dans de nombreux process. C’est une situation fâcheuse qui fait porter sur le système d’information deux risques importants : la perte de maîtrise du SI et l’obsolescence.
En complément de la maîtrise du sens des données dans le temps, le dictionnaire pourra faciliter la mise à jour de la conformité avec les exigences du régulateur et notamment avec le RGPD et facilitera ainsi la production des livrables exigibles par la CNIL.
La deuxième boucle du processus d’un projet data concerne l’affinage de la problématique, c’est à ce stade que l’équipe data pourra se rendre compte de la valeur métier (via les ateliers de présentation des résultats aux métiers) et affiner (améliorer) l’exploitabilité des résultats obtenus dans la phase exploratoire.
Points de vigilance: pour une Data Agile
Dans la réalité, l’organisation et les moyens matériels limitent l’application de la méthode. Très peu de projets informatiques sont développés intégralement (« full agile ») ou partiellement (« pseudo-agile ») selon les principes et avec les outils de la méthode préconisée.
En effet, plusieurs types d’obstacles se dressent entre l’intention réformatrice et le système d’information réel, dans ses dimensions organisationnelles et technologiques. La proximité entre les différents spécialistes (concepteurs, développeurs, sachants etc.) peut favoriser la constitution « d’équipes pluridisciplinaires », réunies en un même lieu et prêtes à s’engager dans la mise en œuvre de la méthode malgré les obstacles inhérents à tout changement* dans une organisation.
| Points de vigilance et limites | Concrètement |
|---|---|
| Difficulté à mettre en place les nouveaux modes de fonctionnement propres à un projet de transformation numérique autour de la data (agilité, DevOps…) | Une tension existe entre l’organisation et la créativité.
|
| Sous-estimer le délai d’appropriation de ces nouvelles méthodes et leur coût de généralisation (Agile at scale – safe) | Ne pas réussir la montée en compétences sur les méthodes propres aux projets de transformation numérique orientés data.
|
| Ne pas parvenir à impliquer les métiers à la hauteur de leurs rôles | Appropriation des méthodes par l’IT au détriment des métiers (pas de partage et de capitalisation méthodologique) |
La data gérée comme actif de l’entreprise
La transformation numérique dans les entreprises implique un changement culturel et méthodologique dont la conséquence principale est l’évolution du mode projet de type cycle en V vers un mode produit de type « continuous delivery » directement issu des approches agiles.
De même que, en ce qui concerne l’appréciation de la valeur économique des projets de transformation numérique, le CIGREF (Ref : Cigref : « Réussir le numérique ») propose un nouveau cadre d’analyse, Il est intéressant d’avoir une approche comparable pour l’actif « Data ».
L’approche orientée « Actif d’entreprise » permet d’envisager la gestion des projets DATA de la même manière que la gestion d’un nouveau produit (un nouvel actif ).
| Approche orientée Actif d’entreprise |
|---|
| Gérer les données comme des Actifs, pour maintenir ou développer leur valeur dans le temps |
Implique la gestion de cet actif
|
Identifier l’ensemble des coûts impliqués dans le cycle de la vie de l’actif Data.
|
Abandonner ou purger certains domaines de données
|
Conclusion
Définition particulière des livrables dans un projet Data
Dans le cadre d’un projet Data, il est nécessaire de qualifier rapidement la nature des livrables souhaités. En effet, alors que dans le contexte de développement Agile d’un applicatif, la nature du livrable est définissable en amont (par exemple une interface homme / machine en JAVA), la nature des livrables finaux dans un projet data n’est pas déterminable avant les phases exploratoires.
Au début d’un projet de Data Science par exemple, les experts de la donnée ne peuvent pas encore définir la forme des livrables. Ainsi, les seuls livrables définissables à ce stade sont la documentation exploratoire autrement dit, les processus d’expérimentation et les résultats intermédiaires. La méthodologie Agile exige la production de livrable c’est sur cet aspect qu’il convient de bien faire comprendre aux décideurs du projet que le processus d’expérimentation est un livrable en lui-même et que le résultat final peut ne jamais être finalisé au sens d’un livrable exploitable par l’entreprise. Il est donc nécessaire dans cette typologie de projet Agile de sensibiliser en amont les décideurs du projet de la possibilité d’absence de résultats exploitables qui pour autant auront mobilisé des ressources humaines et financières.
0 commentaire