Laurent HAUSERMANN

Faire des "releases" (des libérations de versions, en bon français), plus régulièrement, plus souvent et en améliorant leur état de "stabilité" (c'est à dire l'absence de bug) est une nouvelle donnée de l'industrie du Logiciel. On peut s'interroger sur cette évolution des mentalités des sociétés éditrices et des communautés OpenSource, tant elle tranche avec l'ancienne "politique" " 1 version par an".

Tout d'abord, la pression vient de leur "clients" :

- Les sociétés et constructeurs, subissent une pression constante pour modifier leur produit afin de l'adapter aux différents clients. Aujourd'hui, il n'est plus possible de vendre, le même produit à l'ensemble de ces clients. C'est même souvent un "must" pour remporter une affaire que de savoir personaliser, adapter son produit aux souhaits et aux spécificités de ses clients. Cette tendance étant d'autant plus lourde, si le client est un "grand compte". Ainsi, même des industriels des technologies de masse, comme la téléphonie mobile, doivent personaliser, internationaliser, traduire, bref, adapter leur produit.

- Les communautés OpenSource, subissent aussi des demandes répétées de la part de leur utilisateur. Ainsi, Linux Torvals, a déclaré vouloir donner aux utilisateurs du noyau Linux, de nouvelles fonctionnalités sur un rythme plus élevé. Il fallait auparavent attendre 2 ans pour que la communauté "Noyau Linux" fige ses développements et "libère" une nouvelle version... Désormais, les utilisateurs des distributions stables devraient pouvoir profiter plus rapidement de nouveautés au sein du noyau Linux.
Je pourrais aussi vous parler du projet Gnome, qui est passé dans un mode "Time based releases" où le projet s'oblige à sortir une nouvelle version tous les 6 mois. Cela permet d'assurer une animation continue et un cycle de vie dynamique. Cela le prémunie aussi contre des echecs lors de l'intégration d'une version, où un sous projet, une fonctionnalité va retarder la sortie de nombreuses autres.

Finalement, on en revient aux concepts sous jacents des méthodes agiles et itératives, comme eXtreme Programming ou RUP par exemple. Il s'agit alors de de fournir une visibilité importante aux clients et aux utilisateurs des logiciels et de prendre en compte leurs souhaits et leurs demandes. Plus encore, étant donné que nous changeons tous d'avis et de priorités ("changement de plan !", voir les pubs IBM, celle-ci n'y figure pas), il faut prendre en compte le risque majeur de dérive : avoir de petites itérations, de petites releases permet d'ajuster sans cesse son produit et de fonctionner par essai / erreur.

Il est sûr qu'on ne peut pas batir un politique produit et d'innovation sur ce type de méthode, mais pour répondre aux exigences "clients", il faut parfois user sans abuser de petites releases, contentant les bonnes fonctionnalités !