J’étais récemment à une conférence avec un des fondateur de Business Objects, qui racontait ses réussites, mais aussi ses échecs, notamment un qui faillit tuer BO alors en pleine ascension. Cette histoire résonne avec d’autres entendues ces dernières années.

Bernard Liautaud racontait l’histoire de Business Objects au Stanford Club of France. Les réussite mais aussi les échecs. Un d’entre eux était très intéressant : un an ou dix-huit mois après l’entrée en bourse, qui avait valorisé BO à une centaine de millions de dollars, l’entreprise cotait à 1 G$. C’est à ce moment là qu’une nouvelle version technologique a été ouverte aux utilisateurs, alors que l’entreprise était en pleine croissance. Ce fut une catastrophe, car la technologie était très buggée. Ceux qui comptaient adopter BO stoppèrent leur investissement. La valeur en bourse retomba à 100 M€. Au même moment, car « les emmerdes », comme disait Jacques Chirac, « ça vole toujours en escadrille », il y eut un lourd contentieux contractuel avec un gros client, occasionnant une forte perte. L’effet combiné de l’un et de l’autre faillit faire mourir l’entreprise.

Dans d’autres contextes, des collègues m’ont expliqué comment des décisions prises au démarrage de leur entreprise ont été rendues irréversibles une fois en plein décollage.

Quelle conclusion peut-on tirer ?

D’abord, une première question : pourquoi changer une base technologique si tout le monde achète, signe que la technologie existante plaît au marché ? S’il n’y a pas de péril lié à la performance, pourquoi ne pas attendre ?

Ensuite, et sauf à avoir une architecture logicielle modulaire et reconfigurable à chaud, on ne peut pas se permettre de changer de système alors que l’appel des clients est très fort.

Il faut bien faire la différence entre les technologies d’alors et celles d’aujourd’hui. A l’époque, bo était une solution « boîte », c’est à dire que c’était comme oracle, in logiciel que les entreprises utilisatrices installaient sur leurs serveurs à grand renfort de compétences issues de SSII, en architecture technique, en architecture applicative, en MOA et en parametrable et développement.

Faire évoluer sa solution imposait pour les clients des choix plus ou moins cornéliens en fonction de leur situation : s’ils avaient déjà la solution en Vn depuis plus ou moins longtemps, fallait il installer la Vn+1 ?
Ou s’ils n’avaient rien, fallait-il choisir la Vn éprouvée mais moins évoluée ou la Vn+1 plus moderne, riche, performante, mais par nature moins éprouvée ?
Sachant que les éditeurs ne donnaient pas forcément toujours le choix aux clients. « C’est la dernière version ou rien ». La logique est incontournable. Si on ne force pas le passage à la nouvelle version, personne ne l’adoptera, surtout si l’ancienne est satisfaisante.

Aujourd’hui les choses ont radicalement changé. La plupart des éditeurs vendent maintenant des services en SaaS multi ou mono tenant, plus en packages logiciels à installer sur ses serveurs.
L’évolution du produit est incrémentale et à chaud, pour tout le monde en même temps, ou par groupes d’utilisateurs
Lorsqu’il y a une évolution majeure, il devient parfois nécessaire de changer de produit, mais en assurant la coexistence entre le nouveau et l’ancien. Par exemple, quand Google crée inbox, Gmail continue d’exister, et tous les deux agissent en concurrence sur le même compte de messagerie.

Cela permet de gérer en douceur et dans la durée la plus grande des ruptures : celle de l’expérience utilisateur.

Il est donc bien plus simple aujourd’hui à notre époque du SaaS de faire évoluer un produit qu’à l’époque des « boîtes » figées.

Sauf… Si l’entreprise utilisatrice a branché d’autres services informatiques, propres ou tiers, sur le SaaS en question. Il redevient alors nécessaire de faire évoluer avec le SaaS les Systemes qui y sont connectés, mais de manière moins critique car en generale les SaaS s’enrichissent plus qu’ils ne font disparaître des fonctions et données. L’évolution des autres SI branchés sur ce SaaS n’est donc pas toujours obligatoire.

Un éditeur de SaaS qui fait donc évoluer intelligemment son produit en annonçant sa roadmap à ses utilisateurs à donc infiniment plus de libertés.

Il reste à se poser la question de la pertinence de faire de telles évolutions majeures sur son produit alors que des Clients payants s’en servent et que des Prospects se posent la question de l’acheter. Pourquoi détourner les énergies de cette montée en puissance, au risque de les décevoir en diminuant le soin mis à la qualité du produit et au support des Clients, pour des évolutions techniques et fonctionnelles, peut-être indispensables, mais aussi reportables à un moment moins critique qu’une montée en charge ?