
Au cours des dix dernières années, le Test and Learn s’est imposé comme une pratique fondamentale au sein de l’écosystème startup. C’est sans nul doute un progrès, car l’enchaînement des cycles d’expérimentation Plan-Do-Check-Act permet de confronter ses idées à la réalité du terrain. Pour autant, tous les tests sont-ils bons à mener ?
Prenons un exemple sur le terrain. Le nouveau responsable marketing d'une startup présente à l'un de ses investisseurs son plan pour l'année à venir : une liste d'une vingtaine de tests à mener sur une variété de supports tels qu'Instagram, Facebook, Google, des affichages en point de vente, etc. Son plan nécessite de nombreux développements informatiques et un investissement important pour analyser les données générées chaque jour. L'investisseur, qui dirige depuis des années une grande agence marketing, est surpris. Pourquoi considérer Facebook et Google de la même manière, alors que Google est davantage utilisé lorsque le prospect est déjà en phase de recherche ? Pourquoi cet exemple d'article ne comporte-t-il pas de "call to action" ? Plus il avance dans la présentation, plus il presse le responsable de questions: "Qui sont tes clients ? Où se trouvent-ils ? Quels sont les messages que tu souhaites leur passer ? Quelle est ta stratégie de relation presse ?" Le responsable marketing se défend : "Je n'ai pas encore creusé ces sujets, c'est justement pour les découvrir que je veux mener tous ces tests !" Après quelques minutes, il explique à l'investisseur qu'il suit une démarche de Test and Learn. Il mène des expérimentations "pour découvrir ce qui fonctionne, dans une logique scientifique".
Dans la même période, le Chief Technology Officer d'une autre startup explique à son dirigeant comment il prévoit d'améliorer la qualité de ses systèmes. Le volume de défauts a en effet connu une forte croissance au cours des derniers mois, à tel point que de nombreux clients ont mis en pause le déploiement du produit. Le plan du CTO consiste à utiliser la majeure partie de son équipe pour assembler une "task force" chargée de réparer les défauts — au prix d'un gel des nouveaux développements pendant plusieurs semaines. Quand l'entrepreneur lui demande comment il prévoit de s'y prendre pour que ses équipes introduisent moins de défauts à l'avenir, le CTO évoque l'idée d'expérimenter la mise en place de tests automatiques et l'utilisation d'un langage de programmation à typage fort, c'est-à-dire un langage qui offre une vérification accrue des paramètres passés aux fonctions. Le dirigeant est surpris : "Ce sont des approches largement connues depuis au moins 20 ans, pourquoi n'avez-vous pas fait cela dès le départ ?" Le CTO lui explique qu'il essaie de nombreuses approches dans une logique de Test and Learn.
Dans les deux cas, ces responsables décident de dépenser des sommes très importantes pour financer leurs expérimentations. Mais est-ce une utilisation intelligente des ressources de l'entreprise ? S'agit-il d'apprentissage ou de gaspillage ? Test and Learn, ou Try and Pray ?
Bien entendu, ce ne sont pas les praticiens lean qui vont remettre en question le bien-fondé de l'expérimentation. Taiichi Ohno, reprenant le proverbe Japonais selon lequel "même les voleurs ont raison une fois sur trois", faisait remarquer que les honnêtes gens ont au mieux raison une fois sur deux. Chacun devrait donc confronter ses idées à la réalité du terrain pour distinguer les bonnes idées des fausses.
Pour autant, l'expérimentation n'est pas une alternative à l'étude des théories déjà validées. L'erreur classique consiste à utiliser le cycle d'expérimentation du Plan-Do-Check-Act pour tester un grand nombre d'actions en espérant tomber sur celle qui fonctionne. Dans le cas de ces deux startups, ces expérimentations sont très coûteuses et pourraient menacer la survie de l'entreprise à moyen terme.
L'essence du raisonnement scientifique, qui sous-tend la démarche du Test and Learn, est le test d'hypothèse, pas le test d'action. Il s'agit d'établir une théorie du fonctionnement du système étudié puis valider ou invalider cette théorie. Mais rien n'oblige à partir d'une mauvaise théorie !
Le responsable marketing pourrait commencer par clarifier sa théorie de ce qui conduit ses prospects à l'achat. Les facteurs qui déterminent le comportement d'achat ont été étudiés de long en large en économie comportementale, pourquoi les ignorer ? Par exemple, on sait qu'il faut communiquer régulièrement et sur la durée pour créer un sentiment de familiarité et renforcer la confiance envers la marque. Faut-il démontrer cela à nouveau ? On sait aussi que l'achat est un acte émotionnel. Quelles émotions souhaite-t-il créer chez le prospect, et quels sont les leviers connus pour créer cette émotion ? Les points clefs de la réussite des annonces, sur différents supports, ont eux aussi été étudiés. Ce travail de recherche préparatoire permettrait de concentrer l'effort de test sur des questions plus spécifiques.
De son côté, le CTO pourrait établir sa théorie d'un code robuste. C'est un domaine du génie logiciel lui aussi largement exploré. L'utilisation du typage fort, les contrôles de pré- ou post-conditions, les différentes stratégies de gestion des erreurs, les avantages et inconvénients des différents types de tests automatiques… Tous ces sujets ont été étudiés et pourraient aider le CTO a construire sa propre théorie. L'analyse des causes racines des défauts pourrait alors l'aider à affiner cette théorie au fil du temps.
Les deux responsables tireraient deux bénéfices de ce travail. D'une part, ils apprendraient bien plus rapidement que par la seule expérimentation. D'autre part, ils éviteraient de coûteuses expériences à leur entreprise. Plus largement, notre écosystème startup produirait davantage d’acteurs solides.
Négliger le savoir accumulé jusqu'ici n'est pas la marque d'un esprit d'innovation : c'est un gâchis de talent. Pour aller vite, il faut gérer son savoir, rechercher des modèles mentaux éprouvés, s'enrichir du travail de ceux qui nous ont précédé. C'est à ce moment que nos propres expérimentations prennent leur sens : pour faire avancer la connaissance, pas pour réinventer la roue.
Régis Medina
Téléchargez cet édito en PDF
Cet article Le “Test & Learn” pour réinventer la roue ? est apparu en premier sur Institut Lean France.
A lire aussi
-
Quand une organisation a-t-elle pigé ?
Publié le 26/08/2015
Cher Gemba coach, J’ai formé des équipes au Lean, d’abord de manière...
-
Pourquoi rendre visible les activités ?
Publié le 10/10/2017
Visualiser n’est probablement pas le bon terme – mieux vaut employer...
-
Publié le 16/11/2017
Derrière l’image plan-plan de fast follower que présente Toyota se cache une...
-
Des opérations Commando… pour surtout ne rien apprendre !
Publié le 04/02/2021
Il y a quelques semaines, j’ai eu un échange avec un directeur régional au sujet...
-
Une stratégie Lean signifie apprendre quoi améliorer
Publié le 02/03/2021
CHRONIQUE – La stratégie signifie choisir ce qui doit être amélioré,...
-
Quels sont nos points critiques du procédé ?
Publié le 23/02/2018
Votre précédent post a soulevé des questions de fond pour moi et mon équipe de...
-
On apprend vraiment mieux en résolvant des problèmes
Publié le 02/11/2021
Nous avons souvent l’impression d’avoir tout juste inventé la gestion de...
-
Et si on arrêtait de vouloir faire le bonheur des gens !
Publié le 02/06/2023
Imaginez un produit qui améliorerait le travail quotidien, demanderait moins...
-
Revenir au Toyota Production System
Publié le 29/08/2016
Que penser de la théorie des contraintes ? Du Six Sigma ? Des Toyota Katas ?...
-
Poser les bonnes questions. Bien-sûr, mais comment ?
Publié le 15/07/2021
RESUME – Cet article de Michael Ballé et Agnès Nicolas, paru dans...