En 2015, nous présentions le Big Data en nous inquiétant : « Le Big Data, si c’était aussi simple… » (LeMarson Tendances Informatiques 2015).

Cinq ans après, non seulement nous ne retirons pas un mot de nos inquiétudes, mais nous pouvons affirmer que notre diagnostic était le bon.

Rappelons-le : « Contrairement à ce que veulent faire croire les tenants du « yakafokon », la mise en œuvre d’un projet «  big data » est avant tout une affaire technique, qui nécessite de disposer de compétences diverses, que l’on ira chercher dans d’autres domaines, celui de la qualité des données, des frameworks d’interfaçage, de la gestion de fichiers adossée à des architectures de clusters, voire d’algorithmique de parallélisation des traitements. Au risque de refroidir les ardeurs de quelques responsables de TI, le temps semble venu de se remettre les idées en place !!! ».

C’est le même constat que nous faisons aujourd’hui. Le Big Data, sauf cas extrêmes et très particuliers est un leurre et si les prévisions de MarketsandMarkets, qui évalue le marché à 229,4 milliards $ en 2025 (remarquez la décimale…), combien de ces dollars auront réellement servi à quelque chose.

« Depuis que le constructeur X utilise notre solution Y de Big Data, il fait 45 % de bénéfices en plus ». Le constructeur X étant un grand industriel allemand…

Outre que si cela était vrai, on le saurait depuis longtemps, il faudrait faire attention à ne pas dire n’importe quoi, car il se pourrait que certains usagers tombent dans le panneau et ne se rendent pas compte que pour l’essentiel, le Big Data est un concept théorique, un tissu de contre-vérités, d’autant plus difficiles à contrer qu’elles sont impossibles à vérifier.

On est en plein dans un délire marketing entretenu où tout le monde est complice, les fournisseurs de solutions qui promettent monts et merveilles, mais ne tiennent pas leurs promesses et surtout les consultants qui ont trouvé là un fromage pour pouvoir s’exprimer, sans qu’en général il ne sorte grand-chose de leurs interventions.

Retour aux sources

La grande idée du Big Data, vendue et archi-vendue, est que l’on dispose d’un patrimoine gigantesque de données que l’on n’exploite pas à sa juste mesure, voire pas du tout. Comme si on avait un trésor sous nos pieds, mais que nous ne nous en rendions pas compte.

Et évidemment, il faut absolument corriger cette anomalie et amener les entreprises à se mettre en ordre de bataille pour tirer profit de cette manne providentielle.

Malheureusement, quoiqu’en disent les gourous bien informés (auprès de qui ?), le Big Data n’est pas une réalité en 2020 et il passera encore beaucoup d’eau sous les ponts avant qu’il commence à donner des résultats probants.

Tout au plus peut-on considérer qu’il n’est qu’une extension du BI, dans la mesure où dans la quasi-totalité des cas, il ne porte que sur des données structurées, relationnelles le plus souvent, mais avec des volumes plus élevés.

Comme en plus, les « marketers » prennent soin de l’associer à la « transformation digitale », un autre concept fumeux sur lequel nous reviendrons, l’arnaque est complète et gare au patron de TI qui ne se lancerait pas dans l’aventure. Son avenir risquerait de devenir incertain, tant les directions générales, incompétentes sur le sujet, ont été éblouies par les promesses du concept.

Le plaidoyer à charge

La première chose qui vient à l’esprit quand on évoque le Big Data, c’est qu’il ne traite pas les données textuelles, vidéos et autres clips sonores, qui normalement devraient constituer son terreau et lui permettre de faire la différence. Si on revient à l’origine du concept, c’est sur Internet que le Big Data devait trouver ses informations, mais aussi dans les rapports de bureautique, les comptes-rendus de réunions, les présentations Powerpoint, tout ce fatras textuel qui s’empresse de tomber dans les oubliettes, dès lors qu’il a été créé.

Or, ce n’est pas ce qui se passe.

Internet n’est pas fiable et une part importante des données qu’il contient sont des « fake news », des informations produites pour nuire et travestir la vérité.

Et très rares sont les entreprises qui font appel à des modules d’IA, quand ils existent, pour faire le tri entre « le bon grain et l’ivraie » et détectent celles qui manifestement sont des manipulations.

La tâche, il est vrai, est très délicate et nous ne sommes pas à maturité, loin de là, en termes d’Intelligence Artificielle, pour effectuer ce travail pourtant indispensable, sans lequel le Big Data perd l’essentiel de son intérêt.

La deuxième raison tient, si l’on se limite aux données structurées traditionnelles, à leur manque de qualité. Quand on les regarde de près, on se rend compte pour X raisons, qu’elles contiennent des attributs erronés, de l’ordre de 10 % du volume total, ce que tous les spécialistes de DQM/MDM (Data Quality Management/ Master Data Management) savent bien. Par attributs erronés, on entend le nombre d’enregistrements qui contiennent au moins un attribut faux.

Quant à nettoyer les bases, encore faut-il que la direction soit d’accord et en 2020, bon nombre de responsables ne veulent pas investir dans les équipes et outils chargés de la qualité, partant du principe que si les données sont stockées, c’est qu’elles ont passé les filtres du codage et qu’elles sont exactes. Grave erreur.

En termes de moteur de bases de données, SBBD (« DBMS »), le compte n’y est pas non plus. Certes les modèles Oracle, remarquablement conçus et parallélisés ou ceux d’IBM, peuvent faire illusion, mais ils ne font que reculer l’échéance.

Ce sont des systèmes conçus pour traiter des volumes de données à « taille humaine » et sont inexorablement dépassés dès lors que l’on aborde les vrais chiffres du Big Data, qui s’expriment en petabytes, plutôt qu’en giga ou terabytes.

Ce n’est d’ailleurs pas de leur faute, car le modèle relationnel est ainsi fait et imaginé qu’il s’impose ses propres règles, telles que la référence ACID (Atomicité Consistance Isolation et Durabilité), très difficiles à satisfaire quand on cumule les deux handicaps des bases relationnelles, le volume et la complexité des schémas.

Pour ce qui est des volumes, on peut estimer qu’il y a deux catégories, en deça des 100 terabytes et au-delà. Sachant qu’avec 100 terabytes, on aura quand même intérêt à s’appuyer sur un SGBD performant pour « tenir la route ». Quant à la complexité, elle est impossible à modéliser et tout dépendra de la nature de l’application à servir, le transactionnel n’étant évidemment pas à ranger dans la même catégorie que l’asynchrone.

Toujours est-il que pour garantir un fonctionnement acceptable d’un SGBD relationnel en mode Big Data, tel que nous le décrivons, il faudrait bien autre chose que ce dont on dispose actuellement.

Les vendeurs de solutions nous disent que justement le mode NoSQL est fait pour palier aux insuffisance du relationnel, mais là encore le compte n’y est pas.

Car encore faut-il que les sujets s’y prêtent. Les bases graphes ne sont pas faites pour traiter du relationnel standard, de même que les « time-series » sont en dehors du « scope ». Et on pourra dire la même chose des bases colonnes ou clef-valeurs, qui elles non plus ne remplacent pas le mode relationnel.

D’où blocage.

_{Malgré les rodomontades des fournisseurs, le Big Data n’est pas une réalité. Hormis quelques réalisations spectaculaires réservées aux très grands comptes, il continue de souffrir de maux endémiques que l’on n’est pas prêt de résoudre. Il est temps de revenir sur terre.}

Le problème du stockage

D’une manière générale le Big Data requiert des ressources machines très importantes, aussi bien en termes de stockage que de calcul.

Parmi les difficultés rencontrées, le stockage « tout bête » des fichiers, la gestion de fichiers physiques proprement dite, quel que soit le modèle logique implémenté dessus, n’est pas résolu.

Hadoop d’Apache, pourtant une référence, n’est pas un succès, loin de là. Et les autres gestionnaires de données distribuées en clusters ont du mal à sortir des universités et catalogues des fournisseurs.

Ceux-ci n’ont d’ailleurs jamais prétendu constituer la solution, si l’on veut permettre à une transaction d’accéder à des volumes de données vertigineux. Leurs solutions ne sont pas faites pour ça. Pour de l’asynchrone multimédia, oui, mais rien de plus. Stocker une vidéo encombrante, oui et la lire en continu, ça on sait le faire. Mais lancer une analyse BI sur ces données non structurées, sans les avoir au préalable disséquées et avoir exfiltré les données intéressantes, qui les caractérisent, ce qui en soi est déjà un énorme travail, on ne sait pas faire.

Quant aux bases de données hybrides, celles qui prétendent (mode HTAP) marier le mode transactionnel, avec le décisionnel OLAP, ça ne marche pas sur des volumes élevés. D’autant que conceptuellement, beaucoup d’architectes considèrent que l’approche préconisée par HTAP est une erreur de « casting ». Et qu’il ne faut pas la suivre.

Côté infrastructures machines et réseaux, on est évidemment mieux loti, encore qu’il faille se méfier du tout Cloud, voire seulement complémentaire, car les liens entre le Cloud et les installations privées devront être à la hauteur, sans quoi c’est tout le montage qui perdra de son intérêt.

D’autant que l’on ne sera pas maître des ressources et que rien ne dit qu’elles seront en phase avec les enjeux du Big Data. Même s’il y a un SLA à la clé…

La réalité

Si l’on analyse sérieusement le marché et la plupart des « vrais «  observateurs sont d’accord sur ce point, on se rend compte que les réalisations Big Data, outre qu’elles ne sont pas nombreuses, sont la plupart du temps très coûteuses, marquées d’apports fortement propriétaires, avec un gros investissement en développement de la part des utilisateurs.

Le clé en mains n’existe quasiment pas hormis sur des périmètres réduits, qui ne méritent pas d’être mentionnés.

Ces mêmes observateurs constatent qu’une grande déception s’est installée chez les clients, à la hauteur des espoirs imprudemment suscités et que ce n’est pas parce que tel ou tel opérateur télécom effectue une analyse des données véhiculées sur Internet pour se faire une idée du ressenti des clients vis-à-vis d’un nouveau produit ou d’une tendance, parfois en temps réel, que l’on est entré dans l’ère du Big Data. Et ce n’est pas non plus parce que les grands comptes auront pompeusement nommé un CDO (« Chief Data Officer ») pour cette tâche, voire un stewardship, que les difficultés auront été aplanies.

En fait tout se passe comme pour le Loto public. On vous fait choisir 6 numéros parmi 50 possibles et on vous explique que 100 % des gagnants ont joué, en vous faisant miroiter les délices de la fortune. Sauf que l’on oublie que la probabilité de gagner avec ce Loto est d’une chance sur 15,89 millions (nos lecteurs auront reconnu une combinaison au sens statistique du terme).

Pour le Big Data, c’est la même chose. On nous assène à longueur de « news » que c’est le Nirvana, que l’on sera plus performant que nos concurrents et que notre direction sera contente, car l’entreprise sera plus résiliente. Sauf que c’est un mirage et que ce n’est pas en nous présentant des « cas d’usages », toujours les mêmes, qu’il deviendra réel, voire pire en mettant en scène ce que « pourrait » faire le Big Data dans le domaine de la santé, par exemple, la résilience financière, les villes intelligentes, etc. En nous « donnant envie », sans que l’on puisse se fonder sur des bases qui, pour l’instant, n’existent pas.

Dans le futur, avec les progrès de l’IA qui sera (peut-être) de plus en plus pertinente pour décoder des volumes de données textuelles gigantesque et d’en sortir la « substantifique moëlle », il est possible que le Big Data devienne quelque chose de tangible et pas seulement chez les très grands comptes.

Mais la vérité est qu’aujourd’hui ce n’est pas le cas et constitue de notre point de vue, l’une des arnaques les plus marquantes de nos TI modernes.

Mais comme disait un  célèbre politique, les promesses n’engagent que ceux qui y croient…