Projets data : quatre écueils qui limitent le ROI de la data science

C’est un fait, un trop grand nombre de projets data piétinent au point de ne pas dépasser le stade du proof-of-concept. En cause, quatre dérives récurrentes qu’il est pourtant aujourd'hui possible d’éviter.

Paradoxe : si la data science est aujourd’hui considérée comme un des piliers de la transformation numérique des organisations, les projets data, eux, semblent s’effriter au-delà de l’étape du proof-of-concept (POC). Selon l’institut Gartner, ce sont par exemple 60% des projets big data qui ne franchiraient pas les portes de l’expérimentation. De fait, nous croisons toutes les semaines des projets data à fort potentiel qui peinent à prendre leur essor, voire s’éloignent fortement de leur promesse initiale. En cause, de manière récurrente, quatre types de dérives, voire d’erreurs fatales.

C’est assurément la première raison pour laquelle les projets data piétinent : à force de vouloir être en mesure de traiter les besoins potentiels de manière exhaustive et d’analyser tous les risques potentiels, le projet devient au fil des jours de plus en plus technique.

Résultat, les représentants métiers, associés au projet à son démarrage, tendent à ne plus se reconnaître dans la description du projet et s’en détachent. En d’autres termes, les questions de faisabilité technique, de coûts et de risques prennent le dessus et font passer au second plan le seul sujet qui compte : la valeur métier générée.

Bon nombre de projets de data lake ont suivi cette évolution au point de chercher aujourd’hui, après une longue gestation technique, les cas d’usage métier qui sauront justifier ce long tunnel d’introspection technique… C’est une évidence qu’il faut rappeler : un projet data se perd dès que sa valeur métier est elle-même perdue de vue. Le fait qu’un représentant métier ne se reconnaisse plus dans la formulation du projet et dans les itérations proposées doit résonner comme une alerte.

Bon nombre de projets data renvoient à des enjeux d’innovation pour lesquels les incertitudes sont grandes. D’où l’importance d’avancer à petits pas pour se donner le temps d’assimiler les retours du terrain et d’ajuster en conséquence les prochaines itérations. Une logique de cycles courts qui conduit à privilégier une gestion très agile de ces projets. À défaut, l’enlisement guette…

Les itérations longues se caractérisent souvent par de lourds investissements qui font franchir au projet des points de non-retour. Le projet n’avance plus grâce à la pression (positive) des « feedbacks », mais avec l’inertie des ressources préalablement consommées. Résultat, il n’est plus possible de pointer un échec pour s’autoriser à revenir quelques cycles en arrière et reprendre le travail sur des bases plus saines.

Dommage – voire dommageable –, car l’échec fait partie intégrante du processus de gestation des projets data. Ne pas se donner le temps et les moyens de se tromper revient à vouloir cultiver un projet sur un terreau bien peu fertile.

C’est la contrepartie du POC : pour aller vite, pour donner un premier aperçu concret du projet aux métiers, les artisans du POC ont parfois tendance à oublier qu’il leur faudra passer plus tard à l’étape industrielle. Là encore, la dérive est rapide. Un POC matérialisé à travers une belle datavisualisation peut occulter le fait que les données source ne représentent qu’un échantillon très simplifié des données réelles à venir. La data science sous-estime parfois la complexité de la « data chain »…

Pour éviter un retour au réel pénalisant pour le projet, la solution existe : elle consiste à inscrire, dès les 1ers sprints, dans les cycles courts qui balisent le POC des itérations sur l’intégration de la donnée réelle.

Objectif : évaluer (et ajuster) le plus tôt possible les conditions de l’industrialisation dans l’évaluation des projets et ainsi éviter un douloureux retour à la réalité.

Pour aller vite, recourir aux solutions clés en main peut être tentant, notamment lors de phase d’expérimentation.

Sauf que, là aussi, la réalité reprend vite le dessus. Avec 2 écueils. Primo, la donnée exprime toute la spécificité d’une organisation et d’un métier. Une spécificité parfois à l’étroit dans une solution clé en main. Secundo, la donnée est un actif bien trop précieux pour que l’on prenne le risque d’en être dépossédé d’une manière ou d’une autre – par exemple, parce que la réversibilité (le fait de pouvoir rapatrier ses données) s’avérera complexe et coûteuse. Là aussi, opter pour du « clé en main » suppose une grande vigilance.

Les Modern Analytics Platform – Un changement de paradigme pour accélérer et garantir le ROI de la data science

C’est pour contrer ces quatre dérives que les plateformes dites Modern Analytics s’imposent aujourd’hui sur le marché et sont de plus en plus plébiscitées par les grands groupes.

Adossées à un back office fortement automatisé, elles aident les équipes à rester concentrées sur le développement de la valeur métier des projets tout en proposant dès le début un environnement analytique pérenne.

Nativement mutli cloud, elles offrent aux organisations les moyens de rester maître de leurs données, indépendamment donc de l’infrastructure cloud choisie.

En outre, ces plateformes sont architecturées pour garantir le passage à l’échelle, donc pour passer le cap de l’industrialisation.

Commencer petit sans s’interdire de voir grand, avancer pas à pas pour se donner le droit à l’erreur, anticiper dès le POC les conditions de l’industrialisation et, finalement, garder le cap sur la valeur métier. C’est avec cette combinaison de pragmatisme et d’ambition qu’une majorité de projets data dépassera enfin le stade du POC.