Vous connaissez probablement les logiciels suivis de leurs versions V 1.0, V 1.1, V 1.2… Ou alors ceux V1, V2, V3. Car oui, deux nomenclatures s’affrontent afin de pousser l’amélioration d’un logiciel vers la perfection. La simple analyse du schéma du développement d’un logiciel avant sa mise sur le marché peut en dire long sur l’état d’esprit entrepreneuriat de la société éditrice. Décryptage.

Le « versioning » est un étalon de mesure indiscutable dans le milieu du logiciel permettant à l’utilisateur de savoir l’état d’avancement de l’outil informatique qu’il utilise. Pour rappel la version 0 correspond à une version alpha, la version 1 pour Beta, la version 2 pour la version Release Candidate (première version « stable ») et enfin la version 3 qui est la version finale (mise à la disposition du public).

Cette démarche « normée » n’est cependant pas forcement appliqué par tous les éditeurs de solution informatique. Les anglophones ont une tendance à mettre tout de suite à disposition une version bêta en cour de développement auprès des futurs acheteurs, au contraire des Français qui préfère dévoiler un produit stable et éprouvé en interne.

Le rapport à l’échec du développeur et la manière dont il est perçu par l’utilisateur final a une influence indéniable sur le choix de proposer en premier une version Beta contre une version débuggée et stable.
Ce raccourci peut paraitre présomptueux et réducteur, néanmoins il n’est pas totalement dépourvu de sens au vu des réactions que l’on peut observer à l’accueil réservé au moment de la sortie d’un nouveau produit.

Quel est l’impact d’une telle décision en termes de business, d’organisation en interne, les pour, les contres ?

Lancement d’un logiciel en mode beta.

La Beta version est une version qui offre le cœur du produit et ces principales spécificités d’utilisation qui pour certaines peuvent être encore en cours de développement au moment de la présentation au public. Cette démarche s’accompagnait bien souvent d’un prix d’appel engendrant un début de notoriété tout en apportant un chiffre d’affaires.

La deuxième finalité, qui n’est pas des moindres, est de s’assurer d’un retour direct et franc des utilisateurs sur l’ergonomie, le côté ludique et les retours négatifs indispensables à l’adaptation rapide d’un produit sur son marché.

Cette méthode pourrait s’apparenter à l’adage « Action – Réaction » qui demande, selon la taille de l’entreprise, des ressources d’informaticiens polyvalents pour être à la fois en amont sur la R&D et sur le support. Ici, le support à une importance capitale puisse qu’il est le garant de l’image réactive que vont pouvoir observer les utilisateurs de cette version Beta.

Cette méthode a l’avantage de faire un partage des coûts entre ceux liés à la R&D et ceux liés au support. Il est important de souligné que cette formule est très certainement la formule gagnante, si, et seulement si, le produit ne possède que peu de bugs, et que les équipes techniques ont une bonne répartition des charges entre le correctif et le développement. Car dans le cas contraire, cette proposition de valeur peut devenir un gouffre financier avec un réel impact négatif sur le moral des équipes techniques… Sans parler de l’image ternie que pourrait subir la société. Aujourd’hui, dans notre société « zapping », les utilisateurs sont de moins en moins patients. Même pour les plus conciliants

Lancement d’un logiciel en mode Release Candidate, dite Stable

La version Release Candidate, dite stable est, pour sa part, l’aboutissement d’une solution complète et finale. L’utilisateur n’aura pas à attendre les caractéristiques promises sur le papier, et surtout ne devrait pas tomber (sauf cas très rare) sur un bug lui bloquant l’utilisation du produit. Cette version est bien souvent développée en 2 temps : une R&D intense, suivie rapidement de la recherche de défaut à corriger avant la mise en vente. Ici, la méthode pourrait s’allier avec la devise « Perfection sinon rien !», qui axe principalement ses atouts sur un produit fini et achevé sans aucune mauvaise surprise du côté du client final.

Dans ce contexte, l’éditeur du produit doit avoir les ressources financières nécessaires pour maintenir une équipe de développeurs sans rentrée d’argent provenant de la vente du produit. Bien souvent, les start-ups ont une activité de conseil ou de régie. Cela maintient la trésorerie à flot, avec pour effet, une répartition aléatoire du temps des informaticiens sur la R&D du logiciel.

L’inconvénient de cette méthode est de sortir des produits un peu plus tard que les concurrents, qui se lanceraient avec une version Beta tout en entrainant un risque de ne pas satisfaire à 100% le besoin réel identifié au préalable. Le « Plus » indéniable de cette méthode est une minimisation du taux de clients insatisfaits générant ainsi une réduction, des coûts liés au support une fois l’offre officiellement sorti.

Comment choisir ?

La version Beta est parfaite pour une jeune équipe qui se dirige sur des produits grands publics évoluant très vite due aux nouvelles technologies de développement ou tout simplement aux changements des usages. Twitter est l’exemple même d’une solution qui à l’origine n’était pas destiné à faire du micromessage et qui a changé de cap pour devenir ce qu’il est aujourd’hui.

La version Release Candidate est plus adaptée pour des solutions destinées aux entreprises qui investissent généralement pour 3 ans en privilégiant des produits opérationnels et stables. Et minimiser ainsi le risque de discontinuité de leur business.