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
-
Publié le 12/11/2015
Je comprends bien que l’Andon est un élément essentiel d’un système Lean,...
-
Publié le 21/01/2016
J’ai entendu parler du Hoshin Kanri, et j’aimerais vraiment essayer de le mettre...
-
Client un jour, client toujours
Publié le 01/06/2023
Rappelons qu’il faut toujours mettre les clients en premier. Michael Ballé...
-
Être un bon manager aujourd’hui – travailler compétence et confiance
Publié le 03/12/2021
Pourquoi sommes-nous si moroses ? C’est la question que se pose le journal...
-
Une supply chain en juste-à-temps pour accélérer l’apprentissage
Publié le 03/11/2020
Nous revoilà en confinement – je souhaiterais avant tout partager une pensée...
-
Publié le 01/08/2016
Cher Gemba Coach, Nous sommes en train d’installer un système d’Andon – à...
-
Accélérer la diffusion des idées..
Publié le 29/08/2016
Le 16 octobre 1846, au « Massachusetts General Hospital » -sur lequel,...
-
Immersion dans une entreprise lean du monde numérique – chapitre 6
Publié le 02/12/2021
RÉSUMÉ – Dans ce dernier article de la série, Catherine Chabiron passe une...
-
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 notre capacité à résoudre les problèmes ne s’améliore-t-elle pas ?
Publié le 20/11/2018
Cher Gemba Coach, Nous travaillons d’arrache-pied sur la résolution de...