En juillet 2009, quand Gmail, le service d’email de Google est enfin sorti de sa version beta, cinq après son lancement, il avait déjà trente millions d’utilisateurs. A cette époque, c’était le troisième service d’email gratuit derrière Yahoo et Hotmail et sa croissance était plus rapide que celle de ses deux concurrents1. Pour les usages personnels, Gmail était pourtant déjà devenu l’adresse email principale d’une grande partie de ses utilisateurs.
La mention beta sur le logo, qui indiquait que le service était un prototype expérimental, était devenue le sujet de tellement de plaisanteries que quand il a finalement été retiré, l’équipe projet a ajouté, ironiquement, une fonction « retour en beta » qui permettait de retrouver l’ancien logo. Cette fonction était en fait intégrée à Gmail Labs, un ensemble de services qui permettaient aux utilisateurs d’accéder à des fonctionnalités expérimentales. En proposant des expérimentations continues, Gmail avait en réalité transposé l’idée d’éternelle beta.
Aujourd’hui, c’est devenu une pratique courante : tous les services accessibles sur le web comportent des structures permettant de mener des expérimentations grandeur nature au sein même du site de production ou de l’application mobile (et même au-delà, dans les API2 ouvertes aux programmeurs). Quelques fois, ces expérimentations sont même visibles par les utilisateurs. En plus des fonctions en test qui permettent aux utilisateurs de garder une longueur d’avance, la plupart des services offrent une version « stable » qui leur permet de continuer – temporairement – à utiliser les anciennes fonctions. Les meilleurs produits utilisent l’éternelle beta pour offrir à leurs utilisateurs des fonctions toujours plus riches et puissantes au lieu de mettre en place un processus d’analyse des usages du service et d’avoir toujours un train de retard. La rétro-compatibilité n’est plus un impératif sacro-saint et se limite à quelques cas indispensables.
Si vous n’avez pratiqué que des modèles en cascade, l’exemple de Gmail répond à la question que vous avez sur les lèvres : Comment un projet ambitieux mené par des informaticiens individualistes et bornés avançant dans la direction de « l’appétence maximale » qui est la plus imprécise qui soit, tout ceci sans recourir ni à une vision d’ensemble ni à l’écoute des « besoins clients », peut-il se terminer un jour ?
La réponse est qu’il n’est jamais terminé. Mais, contrairement à ce qui se passe dans le modèle en cascade, cela ne signifie pas pour autant que le produit est incomplet. Cela veut dire que la vision est incomplète. On ne lui met pas de limites et on la fait évoluer en permanence au fil des expérimentations. Quand ce principe fonctionne bien, ce que les techniciens appellent la dette technique peut se transformer en ce que nous appellerons un surplus technique3. Les parties du projet qui ont du mal à trouver leur place dans le plan d’ensemble offrent le champ à une innovation rapide. Du point de vue fonctionnel, les « trous dans la raquette » sont autant d’occasions de coups de chance permis par la sérendipité. (Si vous êtes utilisateur de Gmail, n’hésitez pas à parcourir les différentes sections des « Labs », il se peut que vous y trouviez des pépites de sérendipité : des fonctions auxquelles vous ne pensiez pas existent peut-être déjà en version non officielle).
La signification la plus profonde de cette culture de l’éternelle beta dans le logiciel passe souvent inaperçue : à l’ère industrielle, les labos de recherches d’où sortaient les expériences et les produits nouveaux étaient souvent situés dans des bâtiments imposants. A l’ère du numérique, les labos de recherche sont de simples parties à l’intérieur de produits impressionnants. Ceux qui déplorent le lent déclin de labos de recherche comme les Bell Labs ou le Xerox Parc oublient souvent que des labos encore plus impressionnants émergent à l’intérieur même des produits les plus modernes et de leurs écosystèmes.
Le principe de l’éternelle beta est tellement ancré dans les esprits que les utilisateurs attendent des bons produits qu’ils aient une évolution rapide et créative en testant leur capacité à apprendre et à s’adapter. Ils considèrent que les dysfonctionnements passagers en constituent le prix à payer. Dans les années 1990, les premiers sites web statiques affichaient ostensiblement des panneaux « en construction » et cela a débouché sur des sites web dynamiques qui étaient effectivement en permanence « en construction ». Les logiciels ont suivi et sont en perpétuelle évolution.
Tout comme le consensus approximatif permet à la conception d’aller vers « l’appétence maximale », les méthodes agiles permettent aux projets d’aller vers la plus grande incertitude opérationnelle, dans laquelle les erreurs ont la plus grande chance de se produire. Dans les projets modernes bien menés, non seulement ce résultat est accepté, mais, au surplus, il est activement recherché. Les modifications sont souvent introduites intentionnellement et apparemment au moment où nous en avons le moins besoin. Intuit, un éditeur de logiciels de comptabilité, est bien connu pour son habitude de procéder à de nombreux changements et mises à jour en pleine période de déclaration de revenus.
Les conditions dans lesquelles se produisent les erreurs ne sont pas mises à part pour être évitées à l’avenir ; elles sont délibérément et systématiquement recréées et étudiées plus en profondeur. Certains automates sont même programmés pour créer délibérément des erreurs dans des systèmes en production. C’est exactement ce que fait ChaosMonkey4, un système développé par Netflix, qui permet de tester la charge du réseau en faisant sauter aléatoirement des serveurs en production. Ce qui oblige le système à s’auto-réparer, faute de quoi il échoue purement et simplement.
Ce que les utilisateurs voient de l’amélioration continue n’est que le devant de la scène, le gros des expérimentations se faisant en coulisses.
Cette démarche n’est ni perverse ni masochiste : elle est nécessaire pour découvrir au plus tôt les risques cachés des idées innovantes et pour résoudre rapidement les problèmes en analysant les données.
Les racines de cette habitude bizarre sont à chercher dans le principe RERO5, souvent attribué à Linus Torvalds, le concepteur de Linux. L’idée parle d’elle-même : publier l’application aussi tôt que possible, aussi souvent que possible, alors qu’elle est toujours en évolution.
Si cela est possible dans le logiciel, c’est qu’en la matière les erreurs sont rarement mortelles6. C’est pourquoi il est souvent plus rapide et moins coûteux d’apprendre par l’erreur que de chercher à anticiper en s’adaptant à grands renforts de plans d’actions détaillés. Bien souvent d’ailleurs, le principe RERO est reformulé par la négative : échouez au plus vite.
RERO est devenu un véritable état d’esprit et il est si important qu’aujourd’hui des entreprises aussi connues que Facebook et Etsy7 encouragent les nouveaux embauchés à effectuer dès leur premier jour dans la société des changements mineurs sur des parties vitales du site. Le contraste est frappant avec les entreprises qui s’appuient sur des modèles en cascade : les nouveaux ingénieurs doivent passer des années à tourner sur plusieurs postes avant de disposer d’une réelle autonomie.
Pour prendre la pleine mesure du caractère contre-intuitif du principe RERO et pourquoi il inquiète les ingénieurs traditionnels, imaginez un constructeur automobile qui se précipiterait à mettre en production tous ses concept cars, en prévoyant de découvrir les problèmes au fil des accidents. Ou encore des contremaîtres dans des usines qui débrancheraient – ou mieux, qui casseraient – au hasard des machines en plein pic de production. Dans l’industrie, même les méthodes de lean management ne vont pas aussi loin. Parce qu’ils tirent leurs origines du paradigme de la rareté, les méthodes de lean management ne font, au mieux, qu’améliorer les problèmes des modèles en cascade. Les méthodes réellement agiles font mieux : elles cristallisent l’abondance.
Alors que dans les autres domaines techniques, les ingénieurs tentent de diminuer le nombre de versions, le principe RERO a dans le logiciel une conséquence inattendue : les ingénieurs font tout leur possible pour maximiser la fréquence des nouvelles versions. Ici l’analogie avec le monde industriel relèverait d’un scénario de science-fiction : un stagiaire lancerait tout un programme spatial juste pour envoyer un tournevis à l’équipage d’une station orbitale.
Ce principe est totalement dénué de sens dans les modèles en cascade mais pour les méthodes agiles, c’est une nécessité. Dans l’exécution, la seule façon de suivre les changements d’orientation du consensus approximatif quand il pivote, c’est d’augmenter la fréquence des versions. Les expériences ratées peuvent être arrêtées plus tôt et à moindre coût. Au contraire, celles qui réussissent peuvent être intégrées au produit dès que les risques cachés ont été éliminés. La direction générale du projet en est allégée – un consensus approximatif – et suffisante. Plus besoin de poursuivre une vision utopique qui s’éloigne à mesure qu’on s’en approche.
Tout ceci soulève une question intéressante : que se passe-t-il quand les opinions divergent au point de briser le consensus approximatif ?
Précédent | Remonter | Suivant
[1] Cf. cet article de Cnet (http://www.cnet.com/news/yahoo-mail-still-king-as-gmail-lurks/). En 2015 Gmail compte environ un milliard d’utilisateurs.
[2] Application Programming Interface, un système qui permet à des développeurs externes d’interagir avec un produit.
[3] La dette technique est une notion introduite par Ward Cunningham (l’inventeur de la notion de wiki) en 1992. Le concept de dette technique reprend le principe de la dette au sens économique du terme. En général cela fait référence au travail qui reste à faire, par exemple remplacer des bricolages par des solutions idéales ou « refacturer » pour améliorer l’efficacité d’un code structuré de manière inefficace. Cette « dette » est ce qui sépare une version idéale d’une fonctionnalité de sa version réellement développée. Plus largement, dans les méthodes en cascade, cela désigne les fonctionnalités imposées par les visions autoritaires et livrées non terminées, c’est-à-dire existantes à un stade embryonnaire dans le code du logiciel ou dont les spécifications fonctionnelles ne sont pas encore implémentées. Dans le contexte des méthodes agiles, au contraire, tout dette de ce genre, créée parce qu’une opportunité s’est présentée ou parce que la fonctionnalité n’est pas terminée, n’est pas forcément un travail « à faire ». Si une fonctionnalité expérimentale n’est en fait pas adoptée par les utilisateurs, ou bien a été rendue obsolète par un mouvement de pivot, il n’y aura pas lieu de remplacer un bricolage par une solution idéale. Par analogie, les surplus techniques peuvent être vus comme des opportunités de croissance inattendues (on peut aussi le prendre au sens de Nassim Taleb dans Antifragile) créées par des utilisateurs qui font des fonctions existantes un usage créatif ou non prévu. De telles opportunités réclament de revoir la vision d’ensemble. Le surplus intègre la valeur additionnelle des usages non anticipés. Tout comme en économie, un projet dont la dette technique est forte est fragilisé et s’expose à la zemblanité. Un projet dont le surplus technique est élevé atteint un stade « antifragile » et s’ouvre à la sérendipité.
[4] Voir https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey (ndt).
[5] Litt. Release Early, Release Often, ce qui se traduit par « publiez tôt, publiez souvent ». Nous conservons ici l’acro-nyme dans sa langue d’origine (ndt).
[6] Ce n’est naturellement pas vrai de tous les logiciels : le développement des logiciels les plus cruciaux se fait différemment. Ces logiciels-là évoluent généralement moins vite et ont souvent entre dix et trente ans de retard. C’est une des raisons qui font qu’on a toujours l’impression que les applications mineures dominent le monde : c’est toujours plus long de mettre à jour du code critique dans une application vitale.
[7] Moins connu qu’eBay, Etsy est un site de vente en ligne dédié aux créations artisanales (ndt).