Pourquoi les plateformes analytiques internes vont mourir

Data

François Vaillant

Pourquoi les plateformes analytiques internes vont mourir

Dans le précédent article, nous avions vu que de nombreux acteurs se sont engagés dans le développement de leur propre plateforme interne. Ce n’est sans doute pas une bonne idée. Mais pourquoi cela ne peut-il pas marcher ?

L’utopie de la méthode bambou

La méthode bambou, c’est espérer construire sur le long terme un outil générique en se servant de projets successifs. Chaque nouveau projet permettant de construire un nouveau segment qui vient enrichir et compléter l’ensemble.

Malheureusement, cela ne marche pas comme ça dans la vraie vie. Cette méthode peut certes être intéressante lorsqu’un marché est balbutiant, quand il n’existe pas encore d’outil de référence. Mais sur tous les segments matures (ERP, CRM, CMS…) on constate l’abandon de ces projets/plateformes internes au profit de produits de référence sur le marché.

Pourquoi ces plateformes internes ne sont-elles pas viables à long terme ?

Cela tient à deux raisons principales :

  • Une plateforme construite ainsi ne produit pas un produit cohérent et stable
  • Sa charge de maintenance/évolution explose

Vous plantez un bambou, il pousse un buisson d’épines

La supériorité du bambou sur les projets Data, c’est qu’ils poussent toujours dans la même direction. Chaque tronçon s’aligne bien avec le précédent et contribue à faire grandir l’ensemble.

Inversement, lorsque vous développez une plateforme projet après projet, il manque la cohérence d’ensemble. Chaque projet tire dans sa direction et demande des adaptations qui dévient le produit de sa route initiale. La spécificité ajoutée pour projet3 n’est pas cohérente avec le reste de l’outil, elle n’est pas compatible avec la verrue ajoutée pour projet2. Et d’ailleurs projet2 continue à évoluer et fait grossir sa verrue indépendamment du reste.

L’ajout de nouvelles fonctionnalités ne conduit pas forcément à un ensemble cohérent et stable

Souvent également le Product Owner, quand il y en a un, n’est pas à temps plein. Normal, puisque cette activité d’édition de logiciel n’est pas la raison d’être de son initiateur : c’était une simple opportunité projet ou marketing.

Le résultat c’est qu’irrémédiablement les rustines s’ajoutent aux rustines, les verrues poussent dans tous les sens, l’édifice devient fragile. Chaque modification menace de faire effondrer l’ensemble. C’est la différence entre un « outil bambou » et un produit géré par un éditeur.

La valeur n’est plus dans les composants mais dans leur assemblage

Une idée sous-jacente lorsqu’une entreprise développe sa propre plateforme, c’est que les composants élémentaires font déjà tout : je fais mon marché chez AWS/Azure/GCP ou des plateformes bas niveau. Il suffit d’instancier les services et ils scalent automatiquement.

C’est vrai, ces composants simplifient beaucoup les choses. Mais la valeur ne réside plus tellement dans des composants accessibles et faciles à déployer, mais dans « le liant » : dans la capacité à offrir des fonctionnalités « sans couture » dans un environnement cohérent. Plus le produit est complexe, plus la valeur est dans l’assemblage. Il y a ainsi une grande différence de valeur entre un moteur automobile fiable et une série de composants (bougies, calculateur, sonde lambda..) aussi performants soient-ils.

D’autant que cette valeur n’est pas uniquement technique. Elle réside aussi dans la manière dont l’outil favorise les bonnes pratiques ou guide les utilisateurs, dans l’expertise du secteur dont elle bénéficie, dans la vision qui sous-tend le développement du produit.

Le vrai défi : la maintenance de l’ensemble

La maintenance de ce « liant » devient de plus en plus importante avec la complexité du système. Il faut sans cesse incorporer de nouveaux composants plus performants, garantir leur intégration dans l’ensemble, garantir la rétrocompatibilité avec les projets précédents, ajouter de nouvelles fonctionnalités, etc. Toutes ces tâches représentent une charge croissante difficile à assumer en interne.

Opération de maintenance d’un composant central

Inversement, l’éditeur d’une plateforme a la grande force de pouvoir mutualiser cette charge sur l’ensemble des utilisateurs de la plateforme, c’est-à-dire à l’échelle d’un marché et non simplement à l’échelle de quelques clients.

Se concentrer sur les bénéfices plutôt que sur la technique

L’enjeu des nouvelles générations de plateformes dédiées à la donnée est que l’éditeur garantisse la cohérence et la fiabilité de l’ensemble. Il prend à sa charge les tâches fastidieuses de « gestion de la tuyauterie », et de maintenance de l’ensemble.

Déchargés de ce fardeau, les utilisateurs de ces plateformes (cabinets de conseil, intégrateurs ou DSI) peuvent se concentrer sur leur spécialité : mettre rapidement en place des projets Data qui apportent de la valeur au métier, aident au pilotage de l’activité, permettent d’optimiser les opérations.

Une Démo