Attention, cet article a désormais quelques années… Il se peut que toutes les informations qu’il contient ne soient plus pertinentes.

J’ai eu la chance de découvrir au cours de l’année écoulée pas mal de choses en lien avec la méthodologie LEAN, notamment en me rendant à des ateliers ou des conférences organisés par la Cantine numérique rennaise et son Annexe. Je conseille d’ailleurs à tous les gens intéressés par les nouvelles technologies et les techniques entreprenariales innovantes de faire un tour à la Cantine et de découvrir le programme d’ateliers de l’Annexe (si vous habitez dans la région rennaise bien entendu).

La méthodologie LEAN, très souvent appliquée dans le monde des startup (d’où le terme qui revient souvent : LEAN STARTUP) est une méthodologie basée sur l’apprentissage rapide et le test en continu. L’idée est donc de créer un premier produit avec très peu de fonctionnalités et de tester ces premières fonctionnalités auprès des utilisateurs. Le but étant alors d’avoir des retours de ces utilisateurs pour ajuster les fonctionnalités du produit suivant leurs besoins précis. Et ainsi de suite avec chaque nouvelle fonctionnalité du produit. Cela permet donc de gagner du temps et de valider les étapes une par une correctement. On ne passe plus 6 mois à développer quelque chose de très poussé dans son coin, mais on montre régulièrement des versions intermédiaires qu’on teste et valide avec l’utilisateur final (On avance pas à pas, comme sur la photo).

Je ne suis pas un spécialiste de la méthodologie LEAN, mes quelques explications précédentes sont un peu succinctes et les puristes trouveraient surement à redire. Mais je souhaite partager ici avec vous un petit quelque chose que je propose à mes clients dans le cadre de développement d’applications en ligne, qui plait et fonctionne bien : Le Lean Startup Bouton !

Mes clients me demandent régulièrement de nouvelles fonctionnalités pour les applications en ligne que nous avons pu leur développer. De temps en temps, ces nouvelles fonctionnalités amènent une certaine rupture dans l’utilisation de l’application. Par exemple, la mise en place d’un paiement en ligne, l’informatisation d’un processus complet et parfois lourd, etc. Ces fonctionnalités demandent des développements importants et donc coûteux. Je ne me le cache pas, j’aime bien développer de nouvelles choses pour mes clients (développements importants = facturation importante). Mais je n’aime pas développer des choses qui ne seront pas utilisées. Je trouve que personne n’y gagne. J’ai l’impression d’avoir travaillé pour « rien », le travail réalisé est difficilement valorisable, et le client a investi dans des développements qui ne lui seront pas rentables, ce qui peut le freiner à engager de futurs frais de développements.

L’idée est donc d’installer dans l’application, à un endroit bien choisi, un simple bouton mentionnant l’action de la nouvelle fonctionnalité. Si le client veut installer un nouveau module de paiement en ligne, le bouton pourrait s’intituler « Payer en ligne ». Si l’utilisateur final de l’application clique sur ce bouton, un message lui indique que la fonctionnalité est en cours de développement et que celle-ci sera bientôt disponible. Bien entendu, il faut comptabiliser et suivre tous les clics sur ce bouton. Quelques métriques intéressantes :

  • Combien de clics au total ?
  • Combien d’affichages du bouton = Combien de fois la ou les pages qui contiennent le bouton ont été affichées ?
  • Qui a cliqué dessus ?

Le dernier point est très intéressant car cela va permettre de contacter ensuite cet utilisateur final pour lui demander pourquoi il a cliqué sur ce bouton et quelles étaient ses véritables intentions ? Curiosité ? Volonté réelle d’achat ? Etc.

On a donc installé un simple bouton dans l’application (coût de développement proche de zéro) et cela permet de récupérer des informations très intéressantes sur l’envie et le besoin des utilisateurs finaux vis à vis de cette nouvelle fonctionnalité. Si le bouton est cliqué tous les jours de nombreuses fois, par des utilisateurs aux profils différents, c’est sans doute que la fonctionnalité est très attendue, et les développements peuvent commencer. A l’inverse, s’il est très rarement cliqué ou s’il n’y a qu’un type d’utilisateur que ça intéresse, peut être que la fonctionnalité est à repenser ou à adapter pour certains utilisateurs, etc. Il faut en tous cas ne pas hésiter à discuter avec les utilisateurs qui ont cliqué sur le bouton, pour bien comprendre ce qu’ils attendaient en cliquant dessus. En effet, ce bouton ne remplace pas la communication avec les utilisateurs finaux, mais la complète. A l’inverse, on peut des fois avoir des utilisateurs, quand on leur propose une nouvelle fonctionnalité qui diront : « Ah oui, génial, c’est sûr que je l’utiliserais ça ! ». Et la réalité est parfois différente, car la fonctionnalité peut avoir été présenté en dehors du contexte d’utilisation de l’application (temps passé sur l’application, temps de réalisation de la tâche, contrainte d’initialisation, etc.). Je serais donc partisan de ne pas communiquer aux utilisateurs la mise en place du bouton, en leur disant par exemple « Nous préparons une nouvelle fonctionnalité » , « Nous testons quelque chose » , etc. S’ils tombent dessus sans aucun avertissement, ils auront plus tendance à réagir « naturellement » et donc apporter un feedback de valeur.


D’un point de vue développement ?

Intégrer un bouton dans une application, c’est « facile », mais compter les clics sur ce bouton, c’est vrai que ça peut être un peu plus compliqué. Je vais essayer de vous donner ici quelques pistes de travail.

Tout d’abord le modèle des données, il va falloir en effet enregistrer toutes les informations des clics dans une table. Elle pourrait se composer de la façon suivante :

  • id est la clé primaire.
  • bouton_id est l’identifiant du bouton, utile si on place plusieurs boutons au sein d’une même application, d’un même site. Inutile sinon.
  • created qui va enregistrer la date et l’heure du moment où le bouton a été cliqué.
  • user_id qui contient l’identifiant de l’utilisateur connecté sur l’application au moment du clic. Dans le cas d’un espace où l’utilisateur n’est pas connecté, ce champs n’est pas forcément nécessaire non plus mais peut être remplacé par une autre donnée permettant de caractériser l’utilisateur (adresse ip, etc.).

Au niveau du code HTML du bouton, si on utilise bootstrap, on peut avoir tout simplement quelque chose de ce style là :

<!-- Le bouton, un simple lien <a> -->
<a href="#" class="btn btn-primary btn-lean-startup" data-id="3">Intitulé de mon bouton</a>

<!-- Et une modal plus loin qui apparaitra au clic -->
<div class="modal fade" id="modal-3" tabindex="-1" role="dialog" aria-labelledby="myModalLabel" aria-hidden="true">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <button type="button" class="close" data-dismiss="modal"><span aria-hidden="true">×</span><span class="sr-only">Close</span></button>
        <h4 class="modal-title" id="myModalLabel">Action au clic</h4>
      </div>
      <div class="modal-body">
       <p>Cette fonctionnalité est en cours de développement.</p>
      </div>
    </div>
  </div>
</div>

Ensuite, un peu de javascript pour attacher un événement sur le bouton, qui permettra d’ouvrir la modal et de lancer un appel ajax, en considérant qu’on utilise jQuery :

$('.btn-lean-startup').click(function() {
   var id = $(this).attr('data-id');
   $('#modal-'+id).modal();
   var url = '/clics/add/'+id;
   $.ajax({
  url: url
}).done(function(data) {
 // Code de retour
});
});

L’url à appeler peut vraiment être différente selon le langage ou le framework que vous utilisez. Nous utilisons principalement CakePHP dans nos développements et le dernier bout de code va donc présenter l’enregistrement du code dans ce framework. On se trouve donc dans un ClicsController :

public function add($idBouton) {
        
        $this->layout = 'ajax'; // On utilise un layout simplifié pour les requêtes ajax

        if ($this->request->is('ajax')) { // Sécurité de CakePHP qui permet de s'assurer qu'on vient bien d'une requête Ajax
        
        // Volontairement, je ne mets aucune vérification sur le format de $idBouton, mais dans un cas réel, il faudrait s'assurer qu'on est bien en présence d'une valeur numérique, voir même d'un identifiant de bouton qui existe
        
        $clic = array('Clic' => array(
           'bouton_id' => $idBouton,
           'user_id' => $this->Auth->user('id')
           // On a pas besoin de gérer le champ created, CakePHP le gère de lui même, selon ses conventions
        ));
        
        $this->Clic->create();
        if($this->Clic->save($clic))
           $this->set('operation' , 'success');
        else
           $this->set('operation' , 'fail');
           
        }
        else
           $this->set('operation' , 'fail');
    }
// Le code du layout ajax.ctp
echo $this->fetch('content');

// Le code de la vue Clics/add.ctp
echo $operation;

Désormais, tous les clics sur le bouton enregistreront une ligne dans la table « Clics ». On aurait pu aller plus loin, en enregistrant par exemple la session de l’utilisateur, pour déterminer facilement s’il a cliqué plusieurs fois sur le même bouton au cours de la même session ou s’assurer qu’il n’y ait pas plusieurs entrées si l’utilisateur clique plusieurs fois d’affilée sur le bouton. Si le bouton se trouve sur plusieurs pages, cela peut être intéressant d’enregistrer, via un second paramètre de la fonction add, le nom ou un identifiant de la page, pour voir quelle page provoque le plus grand nombre de clics sur le bouton. On pourrait même afficher aléatoirement des intitulés de boutons différents, enregistrer cet intitulé au clic, et voir quel intitulé génère le plus de clics. On arrive ici sur la thématique des tests A/B, qui est un vaste sujet très intéressant et qui fait aussi partie de la méthodologie LEAN.


Aller plus loin

Je vous invite à découvrir d’autres ressources associées au contenu de cet article en suivant les quelques liens ci-dessous. Et n’hésitez pas à partager l’article. Merci beaucoup 🙂

Publié par Arthur Weill

Directeur de l’agence rennaise Web and Cow, directeur digital du Groupe Valorex, impliqué dans l'informatique et la programmation depuis plus de 10 ans.