Big Data: la taille n’est pas toujours faite d’octets !

Si toutes les entreprises s’accordent à dire que le phénomène Big Data, cette croissance exponentielle de la masse des données est clairement observable, elles sont encore peu nombreuses à être en mesure de l’exploiter.

Le traitement de la donnée est depuis quelque temps, le sujet majeur de réflexion au cœur de nos entreprises. Pour autant, si toutes s’accordent à dire que le phénomène Big Data, cette croissance exponentielle de la masse des données est clairement observable, elles sont encore peu nombreuses à être en mesure de l’exploiter.

Cette problématique existe depuis l’adolescence de l’informatique et des systèmes d’information. Le travail scientifique de fond théorique des « Pères Fondateurs » de la discipline comme Von Neumann, Turing, ou Codd, s’est rapidement dissipé en une préoccupation de support technologique avancé. Si la démarche scientifique se préoccupait de comprendre les besoins du monde réel en y proposant des solutions technologiques basées sur des études mathématiques, l’évolution technologique moderne s’est  elle orientée vers un fonctionnement binomial, entre rustines et modes, pour répondre à la culture des caprices de l’instantané.

Ce mode de fonctionnement s’observe clairement depuis les années 80 au sein de l’ingénierie des langages de programmation : l’orienté-objet a triomphé parce qu’il allégeait la tâche des développeurs, sans se préoccuper de savoir si les architectes des systèmes d’information allaient pouvoir trouver des concepts tels que des classes, de l’encapsulation, de l’héritage, de la surcharge ou du polymorphisme dans le monde réel à modéliser.

Au contraire, ces concepteurs se sont vus contraints d’intégrer a posteriori ces paradigmes dans leurs modèles d’architecture. Et naquit l’Universal Modelling Language (UML) avec ses milliers de pages de recommandations parfois confuses, voire contradictoires. Imaginons un architecte du bâtiment devant apprendre à dessiner des plans avec un modèle ne reflétant pas toujours les contraintes que l’on retrouve dans une maison…

La comparaison entre UML, bébé à l’accouchement difficile des années 90, et le modèle relationnel de Codd est un cas d’école.

D’un côté, vous trouvez 2 000 pages de descriptions et de recommandations sur comment dessiner un diagramme pour un possible « cas d’utilisation », avec une constante préoccupation (et donc de mises à jour) pour coller aux dernières évolutions des langages de programmation.

De l’autre, un modèle mathématique concis et démontré sur une petite vingtaine de pages écrites dans les années 70, prouvant comment obtenir la meilleure structure de données au sein d’une base, assistée d’un « langage algébrique » pour pouvoir la manipuler.

De ces 20 pages est issu tout ce qui rend notre vie moderne si confortable, puisque tous nos services du quotidien reposent ultimement sur des bases de données relationnelles. On peut également noter que ce « vieux » modèle est complètement agnostique à l’évolution technologique des langages de programmation et que l’on conçoit des bases de données relationnelles avec la modélisation « Entité‑Association » qui s’apprend elle en quelques heures…

« Mathematics rules » Ou comment les règles mathématiques permettent des bases théoriques formelles et leurs mises en application informatique.

Ce constat est d’autant plus vrai si l’on fait un lien avec Big Data, car il lève deux challenges :
D’une part Le stockage et le traitement de vastes quantités de données non structurées (langage naturel, image, son, vidéo, etc.) en grande partie générées par les activités « sociales » d’un web X.0 (avec X ≥ 1)

D’autre part, un problème de combinatoire
Je laisse de côté le premier point, qui est le plus souvent discuté, pour me concentrer sur le second :
Prenons l’exemple d’un petit supermarché de ville, avec 300 références produits sur ses rayons. La quantité de données générée ne ferait normalement pas partie de Big Data, qui s’entend souvent dans la zone du tera voire du pétaoctet.

Et pourtant, si l’on essaie d’y faire une analyse de vente croisée, dite de « règles d’association » sous la forme : « Si le client achète le produit X Alors il/elle achète le produit Y » l’analyste va devoir construire une simple matrice avec les clients en ligne et les produits en colonnes. Dans ces colonnes, il n’y aura que deux valeurs possibles : «Oui» ou «Non» puisque le client aura acheté le produit ou pas.

De cet exemple extrêmement simplifié, puisqu’il ne prend pas en compte la dimension temporelle, on observe que le nombre de combinaisons possibles par client (par ligne) vaut 2^300 ≈ 10^90 . À titre de comparaison, le nombre d’atomes dans l’univers connu peut s’estimer à 10^82 .
Cette échelle est bien sûr gigantesque et ne peut être directement traitée par l’humain ni par nos ordinateurs de manière directe.
Et il ne s’agit là que de 300 produits : imaginons l’échelle « hypermarché» ou « géant de l’e-commerce » !

C’est donc aussi dans ces cas (courants) que nous pouvons parler de Big Data et que nous avons besoin d’algorithmes en conséquence, qui nécessitent une éducation de niveau ingénieur. Dans ces niveaux de combinatoire, l’analyse statistique, qui repose sur « poser une question » pour en explorer l’espace des réponses, se heurte au nombre dantesque des possibilités.

Les mathématiques doivent de nouveau venir à la rescousse pour trouver des techniques de réduction de l’espace combinatoire, sans perte d’information, pour pouvoir traiter cette simple question dans un temps possible pour un ordinateur, et pour l’organisation qui attend des réponses rapides.

Dans le cas du panier de la ménagère, ces techniques relèvent de l’optimisation algorithmique et de la théorie des graphes.