Le cloud et l’avenir des vendeurs d’outils indépendants

Il y a 25 ans, si vous étiez une organisation grande ou petite et que vous vouliez créer un système informatique, il fallait acheter des outils, des tas d’outils : un système de base de données, un bus de messages, un système d’exploitation, un compilateur C, des outils de monitoring…

À cette époque, la très grande majorité des outils étaient propriétaires et payants.

Les développements internes étaient souvent lents et hasardeux, il était donc souvent préférable d’acheter un logiciel, même si son utilité était faible, plutôt qu’essayer de le redévelopper soi-même.

L’open source s’est fait une place dans le paysage.

Les grosses organisations, habituées aux fonctionnalités très spécifiques de produits propriétaires, continuent souvent à en utiliser.

Cependant pour certains besoins, l’open source a commencé à les remplacer ou à les compléter : Hudson (désormais Jenkins) s’installe et à la place d’Oracle il devient possible d’utiliser PostgreSQL ou MySQL (même si c’est plutôt pour pour les projets périphériques). Les usages critiques de l’open source sont généralement couverts par un support payant, fourni par l’éditeur ou une entreprise tierce.

Dans les organisations plus petites, l’open source est la norme : Linux, Apache, php… Quand les besoins se complexifient, on pourra préférer aménager sa manière de travailler ou faire des développements maison plutôt que de migrer vers des outil propriétaires à mauvaise réputation. Quand la criticité des systèmes augmente, on pourra acheter du support mais sans changer de technologie.

Dis autrement : je pense que beaucoup d’entreprises fondées après 2005 ne deviendront jamais client d’un vendeur comme IBM ou Oracle, en tous cas en l’état actuel des choses.

Les besoins plus spécifiques à valeur ajoutée sont toujours achetés, mais leur pré carré diminue.

Une startup qui démarre aujourd’hui le fera probablement sur le cloud, tous ses outils seront soit fournis par son hébergeur de cloud soit gratuits.

Les outils des hébergeurs sont souvent peu chers et d’une couverture fonctionnelle équivalente voire supérieures aux solutions d’éditeurs classiques.

Ils sont souvent assez bien intégrés avec le reste de leur écosystème, par exemple pour la gestion des droits ou le monitoring.

S’appuyant sur des capacités techniques et financières importantes, ils sont capables d’évoluer rapidement quand un nouveau besoin émerge.

La situation classique buy vs. build se transforme en buy from cloud provider vs buy from another vendor vs build : qu’une solution soit fournie ou pas par le fournisseur de cloud devient important dans le choix.

Les services sont de plus managés, limitant les besoins d’expertise.

En résumé : ces organisations n’achètent que très peu de logiciels directement, et ne le feront peut-être pas plus, ou pas beaucoup plus à l’avenir.

Les organisations existantes qui migrent sur le cloud sont attirées par ce modèle, la capacité à avoir une excuse pour échapper à certains éditeurs est parfois un argument puissant pour sauter le pas.

Il est possible de trouver une niche à valeur ajoutée pour laquelle l’éditeur sera tranquille.

Le problème : il s’agit d’une niche, et donc d’un marché structurellement limité.

Et si, coup de chance, la niche s’élargit trop, le risque est d’attirer la concurrence d’un fournisseur de cloud, profitant de sa capacité de développement supérieure et de son positionnement comme “guichet unique” pour les clients.

Le plan de sortie est alors de se faire racheter par un autre vendeur qui ne veut pas rester à la traîne et qui est prêt à payer pour cela.

C’est l’approche de beaucoup d’éditeurs de solutions open source : distribuer sa solution gratuitement et gagner de l’argent sur l’accompagnement. Cela porte souvent le nom de Professional Services.

L’entreprise était souvent alors une société de services qui se servait du produit comme point d’accroche.

C’est un marché qui n’intéresse pas directement les vendeurs de cloud car il n’offre pas d’effet de levier : pour augmenter le chiffre d’affaire il faut embaucher plus de personnes.

Par contre ils peuvent copiner avec des entreprises sur ce modèle : eux fournissent la technologie, l’entreprise la force de travail. Cette situation peut être intéressante car le fournisseur de cloud peut agir comme un apporteur d’affaire. Le risque est que le fournisseur vous remplace par une autre entreprise ou décide de faire lui-même s’il décide que finalement le jeu en vaut la chandelle.

L’autre danger, c’est le niveau de développement moyen des clients qui m’a l’air de monter, et qui pourraient préférer faire eux-même pour limiter leur dépendance, plutôt que de payer et de dépendre d’une entreprise tierce.

D’après ce que je lis dans des white papers, c’est le nouveau hype des éditeurs depuis quelques temps : jouer sur la peur du lock-in avec un éditeur de cloud pour vendre des solutions multi-cloud.

Ce qu’en autre temps on appelait le FUD. Cela donne ce genre de discours :

Bien entendu, cela passe souvent par un lock-in avec la solution en question.

Il y a quelques années, des vendeurs de solutions proposaient la même chose pour s’isoler des bases de données : et si demain vous vouliez passer d’Oracle à PostgreSQL ?

Les cas dont j’ai entendu parler montrent que c’était en règle générale une très mauvaise idée :

Je ne sais pas si l’histoire se répétera, mais quand je vois le peu d’alternatives possibles aux éditeurs, je me dis que beaucoup vont pousser cette solution autant qu’ils le peuvent.