Focus : les standards, seule réponse à l’accélération des cycles de développement

L’accélération du cycle de développement des logiciels gêne le monde des entreprises. En effet, nombre d’entre elles s’appuient sur des outils tiers pour mettre au point leurs progiciels. Lorsque ces solutions externes arrivent en fin de vie, l’ensemble des produits développés en interne doit être réécrit.

Évidemment, ce problème était moins critique il y a quelques années, lorsque les outils en question (des suites bureautiques, pour l’essentiel) avaient une durée de vie atteignant facilement les dix ans. Les choses sont plus complexes aujourd’hui, l’application servant de base aux progiciels étant le navigateur web. Or, les plus utilisés des butineurs évoluent à une vitesse folle. Avec Chrome, les nouvelles moutures poussent ainsi régulièrement les anciennes vers la sortie, sans autre forme de procès. C’est également le cas depuis peu pour Firefox, dont la version 5 remplace purement et simplement la 4, qui passe en fin de vie… seulement trois mois après sa sortie.

De quoi affoler les entreprises, mais également les utilisateurs, dont certains hurlent contre cette multiplication des versions. La principale critique mise en avant par les internautes est que la fondation Mozilla souhaiterait tout simplement suivre Google, pour des raisons purement politiques. La réalité est tout autre. En fait, ce changement de stratégie est issu du monde des applications web. Ces dernières ne connaissent pas de ruptures technologiques majeures, mais évoluent au fil de l’eau, sans numéro de version. Ce mode de développement permet de lisser les évolutions, mais aussi de les mettre plus rapidement à la disposition des internautes. C’est le principe de la rolling release, bien connu des utilisateurs Linux. Évidemment, ce concept d’évolution continue n’est pas appliqué stricto sensu (d’un point de vue des outils de production, cela serait presque impossible). En fait, il se compose en général d’une succession de microversions, très rapprochées dans le temps.

Avec un modèle traditionnel, nous disposons de plusieurs moutures majeures d’un logiciel, qui sont très distinctes en terme de fonctionnalités (plusieurs années séparant chacune d’entre elles). Internet Explorer 7, 8 et 9 sont ainsi très différents. La contrepartie est qu’il est difficile de forcer les utilisateurs à passer à la nouvelle version de ce butineur. Ainsi, les équipes de Microsoft sont contraintes de fournir des correctifs de sécurité pour IE7, IE8 et IE9, les trois moutures de ce logiciel étant vues comme des produits différents et séparés. Avec un cycle de développement rapide, les nouveautés sont moins nombreuses entre chaque version, un temps plus court les séparant. Il est donc envisageable d’abandonner le support de la mouture précédente lors d’une nouvelle sortie. Pour Chrome, le numéro de version est ainsi vu comme le numéro de révision d’un unique produit. C’est exactement ce choix qu’a fait la fondation Mozilla pour Firefox, à compter de la version 4 du logiciel. Pour preuve, Firefox 5 a rapidement succédé à Firefox 4… qu’il a remplacé. En résumé, avec le modèle classique nous empilons des versions de produits, alors qu’avec le modèle rapide nous multiplions les évolutions d’un même produit. Une nuance importante.

Le seul problème avec cette stratégie de développement est que si les avancées sont rapidement mises à la disposition des utilisateurs, ces dernières arrivent au fur et à mesure (et non pas en masse, une fois toutes les ‘x’ années). Les utilisateurs ont ainsi l’impression que le logiciel n’évolue pas. Une fausse impression. Pour prendre un exemple concret, les performances de Firefox seront relevées cette année de probablement plus de 30 %. En 2010, elles n’avaient pas bougé d’un iota, puisque seule la branche 3.6 – dont la stratégie de développement interdisait toute rupture technologique – était disponible.

Reste le problème des entreprises. Là encore, c’est un faux problème. De fait, le cycle de développement rapide des outils de base, qui est vu comme une limitation, n’empêche pas les professionnels d’adopter des offres SaaS ou PaaS. Et pourtant, des produits comme Gmail ou Windows Azure peuvent voir leurs composants changer à n’importe quel moment. Comme nous le signalait récemment Tristan Nitot, président de Mozilla Europe, l’approche à adopter lors de la mise au point d’un progiciel est de s’appuyer sur des standards et non pas des produits. Cela règle bien évidemment tous les problèmes, à condition toutefois que le standard utilisé soit bien posé et documenté (ce qui sera le cas de l’HTML5, mais ne l’était pas avec ses prédécesseurs), mais aussi correctement implémenté par les butineurs. C’est le pari que devront relever les concepteurs de navigateurs web s’ils ne veulent pas subir la (légitime) colère des professionnels.