Pourquoi les DSI ne comprennent (souvent) rien au #BigData ?

Et pourquoi ne peut-on pas leur en vouloir ?

[ update 05/10/16 : je ne suis pas le seul à prôner l’accompagnement des DSI cf www ]

Ma femme, ma mère, mon frère me répètent à l’envi que provoquer le dialogue n’implique pas forcément de provoquer ses interlocuteurs. Ils ont raison.

Quelques mots sur moi, afin de situer le contexte. Je suis data scientist depuis 2005, à une époque où le traitement de données massif était l’apanage de quelques GAFA et des laboratoires de recherche exploitant les grands instruments. En bon petit soldat de la physique de la fusion nucléaire par confinement magnétique, j’analysais des monceaux de données expérimentales : bruitées, manquantes, biaisées et d’interprétation complexe. Je travaille maintenant à mon compte (OceanData.io) depuis 18 mois, pour des PME et quelques grands groupes.

Je vais donc (tenter de) vous expliquer pourquoi les DSI/CTO ne comprennent rien au #BigData. Ce qui va donc faire râler mon frère, ma mère, ma femme, qui aiment autant avoir raison que j’aime les contredire.

#BigData #SmartData #CleanData

Bonne nouvelle : vous n’êtes pas Google, ni Amazon, ni Facebook, ni Apple, ni Microsoft. A moins d’avoir une activité extrêmement spécifique basée sur l’exploitation massive d’énormes bases de données, vous n’êtes donc très probablement pas concernés par le #BigData dont les médias parlent. Quand je dis “énorme”, il faut entendre nettement au delà du To (1024Go) de données alphanumériques à analyser. Notez que je pourrais m’arrêter là.

Le concept a pris, si fumeux soit-il, et il convient donc de s’y intéresser: les grandes entreprises veulent faire du #BigData, c’est un fait. Je ne sais pas si elles en ont toutes un impérieux besoin, mais mon petit doigt me fait remarquer qu’en terme de communication, il serait suicidaire de faire l’impasse sur le sujet. En étant volontairement très schématique, cette mode s’est cristallisée autour d’une double prise de conscience :

• les entreprises ont beaucoup d’informations, de données : sur leurs clients, sur leurs processus internes, sur leur propre fonctionnement etc
• ces données sont sous-exploitées, au meilleur cas, et il est possible de les valoriser.

Suivant la loi de Moore sur la puissance de calcul, la technologie a permis de stocker cette data de manière peu onéreuse. Et l’avènement du net et des réseaux sociaux a mis en évidence cette tendance qu’à l’homme a remplir des bases de données. La nature a horreur du vide.

BigData is not about the data

Comme le dit bien mieux que moi Gary King, political scientist à Harvard, ce qui importe vraiment dans cette révolution #BigData n’est pas la data: elle est généralement donnée (! … disons présente) et le problème ne vient pas de là. Répliquée, sauvegardée et rendue accessible par des bases de données adéquates, elle ne pose habituellement pas de soucis majeurs. Un service IT sait très bien héberger ces bases et gérer l’infrastructure qui va autour.

Toute la problématique est dans le travail de cette donnée. Après l’identification d’un besoin (marketing, opérationnel, stratégique, que sais-je) et des données nécessaires, comment effectuer le traitement adéquat? Comment analyser ces informations? Comment les traiter? On sent bien qu’on ne se lancera pas dans l’inventaire exhaustif de la faune sous-marine du Pacifique avec un masque, un tuba, une épuisette et deux barres Granola. C’est ici qu’est l’articulation: les outils classiques, même orientés Business Intelligence, ne suffisent plus ; MS Excel n’est pas adapté pour afficher 37 millions de ventes sur l’année, et encore moins pour en proposer une segmentation marketing.

Et ce n’est qu’une étape. En supposant qu’on dispose d’un outil pour analyser les données, il faut avoir eu les moyens de les observer, de les nettoyer, de les mettre en forme et de les sélectionner ; soit, au bas mot 30% de l’activité technique d’un data scientist. Ces outils de manipulation des données nécessitent des compétences parfois complexes, qui ne se limitent pas à de l’export de base ou quelques commandes SQL.

Le #BigData, c’est certes de la data, mais c’est d’abord de nouveaux outils. Et des algorithmes.

Complexité algorithmique

Le mot est lâché.

C’est la raison qui fait que les DSI/CTO et les gens des bases de données sont largués [*]. Loin de moi l’idée de vous mettre la tête sous l’eau, ni l’envie d’être désagréable, mais il va vraiment falloir passer la main aux spécialistes. Ou vous mettre à niveau.

Chacun son métier : les mecs d’Oracle font de la base de données, les managers gèrent, les décideurs décident, et les data scientists injectent de la data dans des algorithmes de machine learning. Et le machine learning, ou apprentissage automatique, le data mining, les statistiques, parfois la modélisation mathématiques sont nécessaires pour mener à bien ces analyses.

J’irai plus loin: un bon data scientist vous fait gagner de l’argent grâce aux réponses qu’il donne à vos questions business, et aussi grâce à l’argent qu’il vous fait économiser en choisissant le bon algorithme, adapté à votre problème. Algorithme qui ne nécessitera pas d’investir 300k€ dans un cluster de calcul ou une solution Cloud totalement disproportionnée. La première tache d’un data scientist est de s’assurer de la pertinence du traitement : à résultats égaux, ou quasi, un algorithme adapté tournera sur votre portable alors qu’un algorithme naïf nécessitera 3 jours sur un serveur à 10k€/jour et ses 100G de RAM par cœur [**].

La bonne nouvelle, c’est que ces algorithmes existent déjà.
La mauvaise, c’est qu’il faut choisir le bon, les paramétrer et analyser les résultats. En effet, la grande majorité de ces outils fournissent des résultats dans tous les cas : ont-ils un sens? Répondent-ils au besoin?

De la stabilité

Le sel de la révolution #BigData réside donc dans ces outils mathématiques abscons. Ce point n’est pas franchement saillant quand on observe l’offre logicielle du domaine — offre que je ne connais qu’imparfaitement, tant elle évolue vite. Ce qui ne m’empêche pas d’avoir très nettement l’impression que les vendeurs de plate-formes #BigData, de Data Management et autres SaaS etc mettent en avant des solutions visant à intégrer les données des entreprises dans de jolies bases de données forcément noSQL et offrant des possibilités d’utiliser les frameworks de processing à la mode (Hadoop, Spark, HortonWorks, Splunk) sans trop parler de data science. Ou sans aller vraiment dans l’adaptation fine ou la réponse spécifique. C’est sûrement très performant,mais je ne peux parfois m’empêcher de craindre que ce soit bien trop cher.

C’est un domaine où tout va très vite, où la communication est agressive et l’impératif d’innovation puissant. Puisque peu de décideurs comprennent vraiment les problématiques de traitement (cf titre), c’est à se demander si le business model de certains acteurs n’est pas essentiellement dans la réponse apparente à un besoin plutôt que dans l’utilisation réelle des outils proposés — ou vantés — et la valeur créée par les analyses. Je diverge peut-être.

La simplicité est la réussite absolue — Chopin

Si je n’avais qu’une seule recommandation, que vous seriez libres de ne pas suivre, j’invoquerai le principe bien connu du KISS — “keep it simple, stupid” — de la US Navy, du “less is more” de Mies van der Rohe ou plus généralement du rasoir d’Occam.

Pourquoi se compliquer la tâche?

Les analyses sur de larges bases de données sont complexes, et en tirer une valeur commerciale ou opérationnelle n’est pas toujours chose aisée. L’effort doit être mis sur le traitement, nécessairement. Pourquoi se compliquer la tâche avec l’intégration de ses données dans une nouvelle plate-forme de données (ie une autre base), spécifique, pas nécessairement stable et qui ne répondra pas forcément aux besoins en accessibilité ou en performances demandées par l’algorithme? C’est peut-être rassurant, mais est-ce efficace ?

Dans mon travail, je ne choisis ma structuration de données qu’après avoir identifié l’algorithme de traitement et les performances en lecture/écriture nécessaires. Comme j’aime bien les citations, je terminerai ce trop long billet avec undes papes de l’informatique, Donald Knuth, qui osa, en 1974 : “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs […]. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

Je propose de suivre ses conseils, qui s’appliquent dans le développement informatique, l’analyse de données, le choix de la structuration des données … et les offres commerciales autour #BigData.

[*] : je préfère ne pas parler des communicants, évidemment.
[**]: chiffres peut-être fantaisistes, certes, mais vous avez compris l’idée. Et je n’exagère pas. Un algorithme de clustering peut être linéaire avec la taille du data set (~n) ou cubique (~n³) : si vous multipliez par 10 la taille du data set, le premier prendra 10x plus de temps, le second 1000x plus.

LI | OceanData.io | contact@oceandata.io