Data Agilité : Comment le big data devient agile !

En 2001, les initiatives historiques autour de l’agilité se fédèrent avec le Manifeste Agile, qui couvre désormais toutes les activités d’une organisation. L’agilité est devenue un mot clé plus seulement limité au périmètre des projets. C’est la solution idéale vers laquelle toute organisation s’oriente pour répondre aux enjeux et contextes à venir.

Parallèlement, l’apparition ces dernières années des big data et surtout la prise de conscience de leur potentiel a poussé les géants de l’informatique à mettre en œuvre des architectures de stockage assez complexes, massivement distribuées, capables d’engloutir des données toujours plus nombreuses et variées. Les entreprises traditionnelles de leur côté, se retrouvent devant une jungle d’outils estampillés big data, avec des problématiques qui leurs sont propres, mais sans aucune promesse de connaître un jour le succès des GAFAS et autres NATU (Netflix, Airbnb, Tesla, et Uber).

Dans un tel contexte, il devient crucial de savoir concilier deux besoins : d’une part, celui de disposer d’une architecture de données (moyens – technologies – logiciels – infrastructure, contenus, politique) robuste et, d’autre part, celui de répondre rapidement (le « juste à temps ») et de façon agile à des besoins métier (use case). Cet article propose une définition de la Data Agilité.

La Data Agilité, c’est répondre aux enjeux du Big Data, proposer une architecture robuste, c’est-à-dire vérifiant un ensemble de qualités telles que performance, sécurité, lisibilité, traçabilité et résilience. Pourtant, dans la réalité, la construction d’une telle infrastructure échappe souvent à la vigilance des entreprises. Certaines s’engouffrent dans une phase architecturale longue, quasi bureaucratique, au délai non adapté et aux lacunes variées. D’autres, au travers de projets dits novateurs, se retrouvent avec des architectures non pérennes se transformant en goulot d’étranglement, et au final le ROI n’est plus assuré.

Pire, une fois l’architecture aboutie, celle-ci devient non conciliante, car à la recherche de la norme absolue de représentation des données, niant ainsi la richesse des différents points de vue et des différentes maturités à considérer sur les données. Son contenu accuse alors un retard continu dans la prise en compte des évolutions, intrinsèques au contexte de toute entreprise. Finalement, la construction d’une telle architecture accumule les reproches que l’on retrouve dans des projets plus classiques de type datawarehouse d’entreprise.

Le projet est fragilisé : il s’appuie sur des données non maîtrisées, qui dégradent les fonctions visées. A terme, l’architecture finit par reconstituer des silos de données et aboutit à un stockage « dépotoir » avec le retour des problématiques de cohérence / écarts du fait de l’utilisation de données « non fiables  » ou non contrôlées.

Un récent sondage réalisé par le CRIP autour du Big Data annonce que 50% des CTO français estiment que l’un des principaux freins aux projets Big Data est l’insuffisance de compétences au sein des DSI. Pourtant, les compétences ne sont pas les seules à entrer en jeu : l’un des freins majeurs, selon nous, est le manque d’alignement entre la démarche agile et l’architecture de données sous-jacente aux projets Big data.

Premier point, la Data Agilité pose les briques essentielles d’un projet à succès car elle répond à une logique de capacités et non à un besoin précis : alimentation de données, représentations des données, fonctions d’exploitation de ces données, contrôle et gouvernance des données… Plus précisément, on cherche à mettre à disposition une architecture ayant la capacité à répondre à N besoins que l’on ne connait pas à l’avance. L’architecture est un cadre structuré facteur d’accélération, de préservation et de capitalisation des travaux antérieurs sur les données.

Deuxième point, cette capacité couverte par l’architecture de données relève d’une construction incrémentale alignée avec les projets. Cette démarche itérative sur le plan de l’architecture doit rejoindre celle que l’on retrouve dans un projet data science :

Data Agilité : Démarche de Data Science

  • Mise en place du socle – construction de l’architecture de données : cette première étape vise à initier la structure data agile en esquissant une vision macroscopique de la partie modélisation des données (à l’aide d’un modèle d’objet métier par exemple) et en chargeant les premiers jeux de données bruts sur une infrastructure de base. On privilégiera lors de cette étape des outils de stockage « ouvert » ou des solutions de data virtualisation, les scénarios variant bien sûr selon l’existant IT.
  • Itération X – «  réponses » agiles au use case data : la seconde phase vise quant à elle à développer l’architecture initiale selon les uses case data que l’on souhaitera aborder. La modélisation du macro-modèle pourra être détaillée, de nouvelles briques d’architecture ajoutées ou étendues…

Troisième point, l’architecture doit également accorder une autonomie vitale aux nouveaux acteurs et organisations data (CDO, data scientist, datalab, data manager…) en apportant d’une part le « juste à temps » grâce à sa rapidité de mise en œuvre et d’exploitation immédiate et, d’autre part une structuration / représentation des données à l’usage et non a priori. Le data shadow IT (excel, mail d’échanges de données…) coté métier est de son côté réintégré dans l’architecture et encadré par l’autonomie apportée. Enfin, l’intégration de nouveaux composants dès le premier incrément, renforce cet esprit d’agilité, de « juste à temps » et d’autonomie. On distinguera notamment une chaîne de composants support aux démarches agiles :

  • Les « ETL visuels » : venant compléter les ETL classiques (Extract-Transform-Load) dont la fonction initiale est l’extraction (avec des connecteurs par sources de données), la transformation de données (filtre, enrichissement, fusion, jointure de données) et la création / alimentation d’une nouvelle source (un dataset). La nouveauté de ces outils est la « programmation » visuelle et dynamique qu’ils apportent à ces différentes étapes ainsi que leur facilité à combiner différentes sources (de la simple jointure à la mise en œuvre d’algorithme avancé de matching), en plus d’intégrer des fonctions avancées de calcul ou de pré-traitement/préparation des données.
  • Les bacs à sable : qui constituent une solution de stockage « libre », dans un espace dédié, sans perturbation des stockages dits industriels. Plus généralement, un bac à sable est conçu comme un environnement non opérationnel où les analystes et les scientifiques de la donnée peuvent tester des idées, manipuler les données et le modèle sans imposer une charge de calcul excessive sur les processus opérationnels de base. Il a une espérance de vie limitée et les découvertes associées sont soit incorporées dans l’entrepôt de l’entreprise soit abandonnées.
  • Les stockages de type NoSQL, Hadoop… libérant des contraintes de structuration a priori, par leur implémentation de modèles à la volée. Leur vocation est de répondre à la problématique de stockage des données en étant non-relationnelle, distribuée (réplication élévée), open-source et horizontalement évolutives.
  • Le « self BI », les fonctions de data discovery : c’est-à-dire la capacité de construire une couche d’abstraction sur des données sources de façon dynamique, à l’aide notamment de fonctions de navigation dans les données. Cette approche libre-service permet aux utilisateurs finaux de créer des rapports personnalisés et des requêtes analytiques dans un cadre structuré permettant de concilier industrialisation et expérimentation.

Quatrième et dernier point, n’oublions par enfin que la Data agilité c’est également la reprise de méthodes de travail agiles, dont la pertinence n’est plus à démontrer. On retiendra notamment la possibilité qu’elles offrent en terme de maturation métier au fur et à mesure de la progression du projet, mais aussi la prise en compte des évolutions, naturelles au contexte des projets data.

Alliée au phénomène data, la Data Agilité propose un cadre de travail robuste qui convaincra tous les acteurs de la donnée.

Auteurs : Joël BIZINGRE et Elkhader FATNI

Observatoire CONIX de la Donnée

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *