Développez facilement votre propre plateforme analytique. Vraiment ??

Business

François Vaillant

Développez facilement votre propre plateforme analytique. Vraiment ??

On rencontre fréquemment des acteurs qui ont de facto choisi de développer leur propre plateforme analytique, grâce au miracle de la « méthode bambou ». Pas sûr que ce soit le sens de l’histoire.

« Regardez, nous avons créé une plateforme data. J’ai intégré la brique X avec l’outil de data visualization Y, le tout emballé grâce à des scripts Z ». Bravo, vous avez créé votre propre « plateforme analytique ».

Cela ne s’est pas fait en une nuit, mais résulte généralement d’un enchaînement :

  • Au premier projet, on choisit des composants et l’architecture, l’équipe découvre les nouvelles technologies et essuie les plâtres.
  • Au deuxième projet, on se dit que ce serait bien de capitaliser sur l’existant. D’autant qu’on commence à maîtriser lesdits composants.
  • Au troisième projet, il est décidé que l’idéal serait qu’un script automatise le tout, au lieu de repartir de zéro à chaque projet.
  • Au quatrième projet, cette « plateforme » est maintenant marketée dans tous les PowerPoints internes comme la grande réussite de ces dernières années.

Et voici comment vous vous retrouvez l’heureux propriétaire d’un « environnement » ou d’une « plateforme » ou d’une « usine à projets » à réutiliser obligatoirement sur tout nouveau projet.

Sur le papier, la « méthode bambou » a tous les avantages

Le concept est particulièrement intéressant. La plateforme se développe comme un bambou : chaque projet ajoute son segment. La plateforme se construit projet après projet, chacun ajoutant sa richesse fonctionnelle et bientôt elle rivalise avec les solutions les plus abouties.

Cerise sur le gâteau, le développement est quasi-gratuit : ce sont les budgets des projets successifs qui payent la création de cette plateforme.

Valeur générée en progression constante, coût proche de zéro, rentabilité tendant vers l’infini. C’est vraiment une belle histoire !

Et puisqu’on parle histoire, rappelons celle des CMS (Content Management System). Dans les années 90, créer un site internet consistait à choisir différentes briques (un serveur web, un langage de scripting, etc.) et à les assembler. Chaque nouveau site était un développement spécifique.

A l’orée des années 2000 est apparu le concept de CMS : un outil qui permettait d’accélérer le développement du site et faciliter l’administration de son contenu. Les plus connus aujourd’hui se nomment Drupal, WordPress, Jahia, etc.

La création de sites Internet prenant de l’ampleur, tout le monde s’est mis à construire son CMS maison. Chaque Web Agency, chaque agence de Communication, chaque cabinet de conseil ou SSII : tout le monde a développé son propre CMS selon la méthode bambou. Initialisé à l’occasion d’un projet, il grandissait tronçon par tronçon au gré des nouveaux projets.

Spoiler alert : à la fin, ils meurent tous

Aujourd’hui, utiliser un CMS est la norme, ne pas en utiliser l’exception. Mais aucun de ces CMS développés en mode bambou n’a survécu. Les seuls CMS restants sont ceux développés comme des produits indépendants avec une logique d’éditeur.

L’histoire est en train de se répéter avec les plateformes analytiques. Ceux qui se sont lancés le plus tôt dans le Big Data (grands groupes, SSII, Data Agencies…) ont développé leur plateforme, dont le niveau de complexité va de « collection de bouts de codes copiés-collés d’un projet à l’autre » à des solutions à l’architecture complète et très aboutie.

Même des cabinets de conseil en stratégie comme McKinsey ou le BCG, inquiets de se faire déborder sur ce sujet porteur par des prestataires plus « data native », recrutent actuellement des DevOps et construisent leur propre plateforme maison !

Tous ont en tête la martingale de la méthode bambou.

Le sens de l’histoire va vers l’adoption générale des PaaS analytiques

Bien sûr ceux qui développent une solution ne sont pas partis de rien : ils s’appuient sur une multitude de services comme les proposent AWS, Azure ou GCP, et/ou sur des PaaS généralistes, et/ou sur des distributions Hadoop. Mais une plateforme n’est pas une simple juxtaposition de services, aussi performants soient-ils, sa valeur réside autant dans la manière d’interconnecter et de piloter le tout.

L’histoire des CMS (mais aussi celle des CRM, des ERP, et autres TLA) laisse à penser que ces plateformes développées en interne en mode bambou ne tiendront pas leurs promesses de flexibilité, de coût, etc. : elles disparaîtront. D’ici quelques années, la grande majorité des projets en production autour de la donnée utiliseront très probablement des plateformes analytiques gérées comme des produits par des éditeurs. C’est bien sûr la conviction qui nous anime chez ForePaaS.

Nous reviendrons plus en détail sur les raisons qui expliquent pourquoi ces solutions maison ne peuvent, par nature, perdurer. Mais globalement cela dépend de la maturité du marché. Il est logique et rentable pour des acteurs pionniers de développer leur propre solution dans un marché balbutiant. Cela perd son sens quand des éditeurs ont identifié la problématique et créé des produits spécialisés pour y répondre de manière efficace et industrialisée.

Bien sûr il existera toujours des entreprises ou des intégrateurs qui n’utiliseront pas un PaaS analytique. Certains pour de bonnes raisons. Quant aux autres, ce sont les mêmes qui se disent que « après tout, un CRM ce n’est qu’une base de données et quelques écrans. Redéveloppons notre propre CRM, c’est l’affaire d’un mois »

Contacter un expert