Agilité Et Recherche Du Risque

Cette semaine nous publions la 3ème partie de l’essai Breaking Smart, essai écrit par Venkatesh Rao, et supervisé par Marc Andreessen. Vous pouvez également retrouver la première partie avec l’intervention de Stéphane Distinguin Fondateur de FABERNOVEL ici et la deuxième partie avec l’intervention de Dominique Piotet ici. A la fin de cet extrait du 2ème chapitre,  vous pourrez lire ci-dessous un commentaire de Habib Guergachi, CEO de Zengularity.

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 ChaosMonkey, 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 RERO (Release Early, Release Often), 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 mortelles. 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 Etsy 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.

Saison 1 dans sa version intégrale en cliquant ici

Commentaire de Habib Guergachi, CEO de Zengularity

La Bêta gracieuse  

« Dans la culture d’une DSI traditionnelle, une version bêta rime quasi automatiquement avec instabilité technique et fonctionnelle. Son déploiement est pourtant souvent le résultat d’un processus de tests laborieux pour découvrir et résoudre le maximum de bugs. Les tests effectués par les utilisateurs finaux sont l’ultime moyen pour corriger les bugs résiduels et figer une version dite stable. La version bêta est ainsi subie et non pas choisie. Le qualificatif « version bêta” reste ainsi une connotation négative au sein de la DSI conventionnelle. Il est même souvent usé et abusé comme bouc émissaire pour justifier la faible qualité et le manque de performance de l apremière version d’un logiciel.

Il en est tout autrement dans une entreprise ayant adopté les méthodes moderne en fabrication logicielle. On y parle de « bêta éternelle ». La culture du tout bêta est une réalité quotidienne et naturelle. Cette pratique est le fondement même de la progression en mode  test & learn. Derrière ce concept de « bêta éternelle” se cachent toutefois des principes complexes de construction de logiciels ultra sophistiqués, des procédés industrielles d’un niveau encore inconnu dans les DSI conventionnelles et surtout des pratiques de management de rupture avec le modèle appliqué dans les entreprises traditionnelles.

Les géants du web ont inventé et adopté la bêta perpétuelle comme arme pour faire face aux contraintes draconiennes de leurs propres modèles d’affaires. Leurs plateformes ne peuvent jamais être arrêtées. Les idées de fonctionnalités réellement différenciantes surgissent soudainement des retours voire réclamation urgentes des internautes. Les évolutions fonctionnelles doivent être implémentées très rapidement pour être testées et bénéficier du feedback tant qu’il est encore temps. Les réactions aux innovations de la concurrence ainsi qu’aux failles de sécurité doivent être opérées dans des délais records. Le tout dans des quantités titanesques des codes sources et de composants logiciels.

Malgré la complexité de leur mise en oeuvre opérationnel, les principes de construction logicielle moderne restent suffisamment simples pour être compris par toutes les parties prenantes d’une équipe dédiée à la conception et développement de logiciels : architecte, développeurs, ux designer, technical lead ou product owner. On dénombre sept principes fondamentaux éprouvés et dont le respect a été sacralisé par les pionniers de la « bêta perpétuelle ».  

OCP (Open Close Principle), principe selon lequel tout logiciel qui fonctionne déjà en production est définitivement fermé à toute évolution par modification mais ouvert uniquement pour subir des extensions. “Non mutabilité », principe interdisant toute mise à jour des données existantes et n’autorisant que l’insertion de nouvelles données. “Dégradation gracieuse”, principe selon lequel toute fonction livrée doit avoir été conçue et réalisée pour ne jamais subir des dysfonctionnements sévères mais rester toujours utilisable à minima. “Livraison continue”, principe qui rend la livraison d’un logiciel en production un non évènement, ainsi que la “dé-livraison” pour un retour arrière. « AB/Testing”, principe selon lequel les utilisateurs ont tous à tout moment accès à des fonctionnalités différenciées et testent ainsi des parties différentes d’un même logiciel. “Refactoring”, principe qui consiste à restructurer régulièrement le code source des applications pour l’améliorer et repousser ainsi les limites de son extensibilité. « Néguentropie », principe selon lequel plus les logiciels évoluent et s’enrichissent plus leur complexité et l’enchevêtrement sont maîtrisés et les développeurs et sachants sont à l’aise pour agir sereinement.

Mais le véritable secret de réussite de l’adoption du concept de “bêta perpétuelle” chez les pionniers du web pour construire des logiciels aussi complexes et sophistiqués ne réside pas que dans l’application strictes de ces principes. Il prend ses racines dans le déploiement de pratiques de management fortement centrées sur la singularité des individus, qui se regroupent librement en squads et en tribus pour délivrer des fonctionnalités pour des utilisateurs qui ne savent pas ce qu’ils veulent ni comment l’exprimer. Ils construisent ainsi une machine de management vertueuse qui séduit les meilleurs développeurs, les recrute , les passionne et les fidélise. Ils deviennent les porteurs de mémoire de la complexité de ces plateformes, qui ambitionnent de fonder un nouvel ordre économique si ce n’est sociétal.  

A contrario, les entreprises conventionnelles achètent des outils d’abord, budgètent des jours-hommes, imposent des méthodes, recrutent des profils stéréotypés pour combler des cases vides dans la hiérarchie, complètent les ressources par des régies issues de SSII, passent des contrats au forfait sur un périmètre flou et des délais fixes, pour in fine livrer des logiciel en versions bêta “boguée” à des salariés qui n’ont d’autre choix que de les utiliser pour remplir leurs objectifs business.

Le contraste est saisissant. La disruption s’impose donc. Pour la réussir, il faut mettre l’humain au coeur de la stratégie et non par l’acquisition d’outil ou le déploiement d’ersatz de principes et concepts. La « bêta perpétuelle” n’a jamais été une « version bêta” qui dure le temps de corriger les bugs. »