MtoM Mag - Le journal de l'MtoM.

Pourtant, l’infrastructure est un élément tout à fait essentiel pour qui entend réussir sur le long terme. Mais cette infrastructure doit-elle forcément se montrer la plus véloce, la plus puissante, absorbant les plus gros volumes de données en des temps très courts ? En Big Data aussi, l’approche doit être raisonnée, pour des raisons évidentes de coûts, de ROI mais également d’apprentissage et d’adoption progressive.

Des échecs qui refroidissent les ardeurs

Les constats d’échecs sont nombreux dans le Big Data. Il est aisé d’ailleurs de désigner les coupables, ils sont légion. Gouvernance déséquilibrée, manque d’information à destination des équipes, données de piètre qualité, sponsoring peu engagé, objectifs mal définis... à croire que le Big Data est un puits sans fond d’erreurs et d’errances.

Face aux déceptions, les entreprises hésitent à se lancer, en particulier celles de taille intermédiaire. Elles savent que le Big Data présente des opportunités mais aussi un coût et le risque d’une traversée du désert numérique. En d’autres termes, elles optent souvent pour le statu quo, ce qui ne présente pas que des avantages dans une économie construite sur des écosystèmes ouverts.

Il y aurait certainement à blâmer un certain marketing agressif et l’illusion des solutions misant sur l’hyper performance, qui dissimulent l’exigence d’une réflexion longue assortie de prévention. Car les projets Big Data sont d’une extrême diversité, et n’ont en commun que leur nom, et encore. Beaucoup d’entre eux relèvent moins du Big que de la Data et concernent plus volontiers de petits jeux de données, traités à vitesse moyenne, sans grande variété de formats. Ils n’en sont pas moins pourvoyeurs d’informations importantes pour l’entreprise.

Du seul point de vue du volume, la sur-multiplication de la donnée n’est d’ailleurs pas forcément gage d’une bonne gestion et se montre parfois synonyme de dispersion et de visibilité partielle de son patrimoine informationnel. Le risque en revanche, commun à toute entreprise, est de vouloir s’équiper en fonction d’un projet dit « Big Data », qui supposera alors des ressources et des performances bien au-delà des besoins réels.

Le surdimensionnement de l’infrastructure, la plaie des entreprises

On arguera que le choix de technologies puissantes est fait dans une optique d’évolution des besoins, en prévision d’une couverture plus large des cas d’usages à venir. Que dans une dynamique d’innovation, il y a lieu de ne pas contraindre les équipes avec un environnement IT limitant. C’est un argument effectivement recevable, dans la mesure où lesdites équipes sont capables d’embrasser la complexité d’un système destiné à de la datascience ou du deep learning et maîtrisent les bonnes pratiques conditionnées par la démarche. L’expérience en général démontre le contraire, ce qui ne devrait surprendre personne. Le Big Data fait partie de ces paradigmes technologiques requérant une expérience construite progressivement. En d’autres termes, au même titre que l’on exige le permis B avant d’apprendre à conduire un poids lourd, il demeure indispensable de vérifier la réalité des compétences et des expertises disponibles dans l’entreprise avant de s’équiper de l’artillerie lourde.

Cette démarche prudente est pertinente quelle que soit la taille de l’entreprise. Pourtant, les organisations les plus victimes d’un Big Data avorté sont souvent celles qui disposent d’importants budgets. Parce qu’elles ont déjà en vue la valorisation de leurs dépenses à travers de nouveaux modèles économiques, parce que leurs équipes y sont fortement incitées, elles prennent le risque du sur-dimensionnement. Cette décision initiale se traduit par des coûts annuels de licence et d’exploitation monumentaux, assortis de lourdes prestations de consulting et de mise en œuvre. Or le résultat le plus explicite de la démarche reste surtout la constatation d’une sur-estimation des prévisions d’évolution, en coût de serveurs notamment.

Dans le même ordre d’idées, l’expression Big Data rejoint presque toujours la notion de Cloud public dans l’esprit des équipes et du COMEX. Dans un sens, c’est effectivement chez les hyperscalers qu’on trouvera toute l’élasticité, la scalabilité et les ressources de calcul nécessaires à un traitement massif. Mais avant de chercher à satisfaire d’éventuels orgueils à coût de dizaines de milliers d’euros mensuels, il est bon de se souvenir que le mieux est toujours l’ennemi du bien.

Une infrastructure Big Data doit être justifiée

Oui, pouvoir correctement travailler sur un ou plusieurs sets de données disponibles, effectuer quelques recoupements pertinents entre départements producteurs, explorer un, deux, trois cas d’usages identifiés en interne, par les équipes sur le terrain les plus à même de signaler leurs besoins, c’est une démarche pragmatique. Elle donne des résultats exploitables, compréhensibles, endossables ensuite par les collaborateurs.

Prendre la mesure de ses progrès, choisir d’aller plus loin et pour cela faire évoluer en douceur son infrastructure, au rythme des montées en compétence et de l’imprégnation culturelle de l’approche datascience, est une deuxième étape constructive. Conduire l’industrialisation des projets réalisés, maîtriser ses coûts en réévaluant ses choix d’infrastructure, infuser la stratégie pour accélérer une collecte de données dans un objectif précis, voilà en l’occurrence une suite logique.

Bref, se lancer en Big Data est d’abord et surtout une histoire de cadrage initial. Bien choisir ses données, apprendre à les collecter et à les qualifier, savoir les exposer, relèvent d’une étape fondamentale. Dès lors, l’entreprise est en mesure de valider l’expérience à petite échelle. Si dès le départ, il apparaît que le projet requiert plus de ressources, alors oui, il faudra adapter l’infrastructure. Mais tant que le volume considéré, le type de donnée et les temps de traitements restent parfaitement absorbés, il est inutile de se ruiner en ressources technologiques.

Un projet (Big)Data s’apprivoise et grandit avec l’expertise des équipes. Elles auront en effet beaucoup à apprendre, accompagnées ou non. Découvrir toutes les subtilités de certaines requêtes trop gourmandes en ressources, apprendre à utiliser correctement la puissance d’un cluster, effectuer des scans réguliers des datasets, surveiller et modifier l’usage de codes peu ou mal optimisés dans de trop nombreuses solutions d’entreprise, etc... Bien souvent, les bonnes pratiques en Big Data ne sont pas maîtrisées et cette situation conduit en général à l’altération de performances pourtant achetées au prix fort et in fine, à l’abandon d’un projet qui présentait du potentiel.

http://www.cyres.fr/