Vous avez l'impression d'être un cobaye permanent au service des éditeurs de logiciels et de fabricants de matériel ? Votre intuition est la bonne : vous avez en effet payé pour l'obligation de tester le produit… et le droit de recevoir quelques mises à jour par la suite pour régler ses principaux bogues.
Des développements plus agiles à l'heure d'internet
Le modèle de la « bêta permanente » est indissociable de l'émergence d'internet, un réseau qui favorise la collaboration en masse, le retour utilisateur immédiat et direct, et la distribution directe de nouvelles itérations. Des mots qui évoquent les méthodes agiles de développement, ou en tout cas les méthodes « itératives-incrémentales-adaptatives », qui émergent justement au début des années 1990.
Il ne fait aucun doute que les développeurs web ou de logiciels libres qui ont les premiers adoptés cette mentalité l'ont fait sans une structure aussi rigide que les méthodes RAD ou Scrum, sans même parler de l'Extreme Programming. Mais force est de constater leur proximité, au moins dans l'esprit, du grand pragmatisme à la bonne réactivité en passant par l'organisation autour des besoins et remarques de l'utilisateur.
Les méthodes agiles sont d'abord et avant tout dédiées au monde de l'entreprise et la gestion des projets d'envergure : il paraît donc normal que des développeurs indépendants ou de petits groupes ne les aient pas adoptées stricto sensu, même si l'on retrouve certains de leurs aspects dans leur façon de travailler.
La constitution de start-ups devenues multinationales de l'internet au tournant du XXIe siècle a néanmoins provoqué un glissement qui provoque parfois la confusion. Voici que de grands groupes fonctionnent comme de petits développeurs et adoptent des méthodes agiles, c'est-à-dire plus souples que les méthodes traditionnelles, sans pour autant être agiles, au sens des méthodes RAD, Scrum, et des autres. Un entre-deux très peu formel et donc débarrassé de nombreuses contraintes entravant des cycles rapides d'innovations constantes.
Un monde en bêta permanente
Inspirée par les cycles de développement très rapides du web et du logiciel libre, et poussée par leur concurrence directe, Google fait partie des premières sociétés à adopter de manière organique le modèle du ship first, fix later. On ne compte plus le nombre de produits de la firme de Mountain View qui ont gardé pendant des années l'étiquette « bêta », à la fois excuse pour les quelques pannes et facilitateur des évolutions très rapides, par petites touches, de ces services.
De manière générale, le web a été un formidable terrain d'expérimentation, d'itérations et d'adaptations constantes — l'utilisation d'outils statistiques (Google Analytics, Mint, les heatmaps, etc.) permettant de toujours affiner les propositions. Facebook a construit son succès sur des évolutions constantes de son site : certaines consistent à décaler un bouton de quelques pixels pour qu'il soit plus facile à cliquer, d'autres renversent totalement l'interface pour favoriser de nouveaux usages.
Cette pratique s'est peu à peu étendue au logiciel, sous la double impulsion de la rencontre du web et du natif via les services et de l'émergence des app stores, qui facilitent les mises à jour. Apple a mis un pied dans la bêta publique avec iWork.com, et ce sont aujourd'hui la plupart de ses produits qui sont concernés. Il n'y avait plus qu'un pas pour que le matériel soit lui aussi soumis à ces cycles, et c'est aujourd'hui indubitablement le cas.
La méthode d'Apple a néanmoins l'avantage de la clarté : la firme de Cupertino a recyclé la stratégie tick-tock d'Intel. Le tick d'Apple, c'est l'incorporation de nouveautés radicales, soit dans un produit existant, soit par le biais d'un nouveau produit — avec les risques de fiabilité et de stabilité que cela comporte. La pression du calendrier oblige à commercialiser des logiciels voire des OS auxquels il manque des fonctions évidentes, compromettant parfois leur cohérence. Le manque de stabilité des processus industriels naissants provoque des taux de déchets élevés, ou des problèmes de fiabilité sur les premières séries.
Le tock, c'est la stabilisation de ces nouveautés. Le retour utilisateur permet de savoir ce qui manquait et ce qui n'est finalement pas nécessaire. Les statistiques d'utilisation permettent d'améliorer certains processus, de renforcer un point chancelant ou de boucher une faille. Le travail sur les chaînes de production permet d'augmenter la cadence et la fiabilité. Le mythe de la « Rev. A » n'est pas uniquement une théorie du complot : il se base sur des faits bien tangibles.
Une nécessité industrielle : s'adapter ou mourir
Pourquoi accepter un OS X Lion moins stable et moins cohérent qu'un OS X Mountain Lion, un MacBook Air 2010 à la charnière plus fragile que le MacBook Air 2011, un iPhone 4 qui capte moins bien qu'un iPhone 4S, un iPad de troisième génération qui est plus chaud que son successeur ne le sera ? C'est tout simplement une nécessité industrielle : à l'heure où tout le monde adopte le ship first, fix later, il faut s'adapter et adopter les mêmes cadences, ou mourir.
Windows Phone est sans conteste un excellent système d'exploitation mobile, mais s'il ne perce pas, c'est aussi parce que Microsoft a adopté un rythme extrêmement lent d'itérations, laissant iOS et Android faire la course en tête. Les systèmes d'Apple et de Google sont peut-être un peu moins cohérents et un peu moins stables, mais ils sont revus de manière très régulière pour corriger leurs faiblesses et ajouter peu à peu des nouveautés.
Nokia et RIM ont aussi été rayés de la carte, non pas parce qu'ils ont été incapables de répondre à Apple, mais parce qu'ils n'ont pas su répondre à Apple vite. Et ensuite se dépêcher de répondre bien. Si la part de marché de Firefox s'érode, c'est aussi parce que Chrome, avec son cycle de développement extrêmement rapide, a donné l'impression d'être largement plus innovant.
Avec son modèle « innovation / stabilisation », Apple a su répondre à cette fuite en avant, tout en la temporisant de manière régulière. Le problème de certaines méthodes agiles est en effet le manque de contrôle qualité, et ce sont les boulons parfois mal serrés qui provoquent cette impression d'être un bêta-testeur permanent. Force est de constater que si le modèle d'Apple n'est pas le moins fiable de tous, il reste encore largement imparfait.
La capacité d'Apple et de ses concurrents à multiplier les itérations tout en garantissant leur stabilité et leur fiabilité sera sans conteste un défi particulièrement ardu à relever. En attendant, le remède sera parfois pire que le mal : au nom de l'ajout de fonctions pour l'utilisateur, on continuera à souvent lui imposer des solutions bancales.
