Catégorie : Test and learn

Comment lancer de la meilleure manière une nouvelle version de site ou un nouveau service digital sans froisser ses clients fidèles ?

Pour toute entreprise présente sur la toile, un tel lancement doit nécessairement prendre en compte la base existante d’utilisateurs afin de minimiser le risque de rejet – et au bout du compte le risque financier. Un des meilleurs moyens de maîtriser ce lancement est de mettre en œuvre une phase pilote au sein du projet digital, avant le lancement de nouveaux services majeurs.

Dans ce contexte délicat de changement, il est très important de comprendre les principales dynamiques et les éléments clés de la phase pilote afin de la valider avec succès avant tout lancement définitif – non accepté par les clients ou difficilement rattrapable.

À propos de la Phase Bêta, petit rappel historique

Dans le développement de logiciels, une phase bêta (ou bêta test) est la deuxième phase de tests métier, dans laquelle un échantillon du public ciblé essaie le produit. A l’origine, le terme « alpha test » signifiait la première phase de tests dans un processus de développement de logiciels. La première phase comprend les tests unitaires, les tests de composants, et les tests fonctionnels.

Le bêta test peut être considéré comme un test de « pré-sortie », très orienté client. Il ne s’agit en aucun cas de focus group ou d’études techniques ou marketing, car les testeurs doivent avoir accès au nouveau service dans des conditions proches du réel (depuis leur domicile, depuis un réseau d’entreprise, sur une tablette … ).

Le digital constitue réellement un apport inestimable pour les phases bêta, sur le recrutement, l’animation client, le recueil des feedbacks, et la réactivité globale du dispositif prévu pour la production.

Pourquoi une phase bêta à l’heure où tout va très vite dans le digital ?

Lors du lancement d’un nouveau produit ou service, le but recherché de toute société commerciale est que le lancement soit réussi, et que le produit se vende ou que le service soit utilisé de manière optimale.

A l’heure actuelle, peu de produits sont lancés sans une base client déjà installée. Cette base, plus ou moins grande, a déjà pris un certain nombre d’habitudes dans l’expérience client digitale : par exemple, une présentation du catalogue online par usage, un tunnel d’achat en 4 étapes, des réponses apportées par le service client en moins de 24 heures.

Tous ces repères inconscients constituent un acquis qu’il sera difficile, voire dangereux, de remettre en question dès lors que l’on déploie des évolutions. Malgré toutes les études marketing, un service vraiment nouveau pourra dérouter les clients actuels même s’il est le meilleur, voire être l’objet de rejet s’il n’est pas compris. Par exemple, le PMU avait un réel enjeu de ne pas perdre ses clients sur les paris hippiques dans sa diversification vers les paris sportifs lors de l’ouverture du marché en 2010.

Le principe du bêta-test est de réduire les risques par une validation client avant tout lancement officiel.

Le bêta test est à la croisée des chemins entre la conduite du changement qui a été menée à bien tout du long du projet et qui a pris en charge les aspects organisationnels, humains et procéduraux du nouveau service et le développement des nouveaux outils ou supports de vente, et l’intégration dans le système d’information de l’entreprise.

Des risques principaux lors d’un lancement produit/service, bien qu’ils soient spécifiques à telle ou telle entreprise, peuvent être identifiés :

• Risque de non-adhésion des clients ;
• Risque de fuite à la concurrence ;
• Risque de perte financière ;
• Risque de dégradation d’image et de la marque ;
• …

L’amélioration de la qualité est souvent le but principal du bêta test, mais il y a beaucoup d’autres objectifs auxquels un bêta test peut répondre :

Les objectifs d’une phase bêta :

• Mesurer et améliorer les performances du nouveau service dans des environnements réels ;
• Évaluer et améliorer la facilité d’utilisation du service ou du produit en obtenant des retours très différents de la part des clients, par rapport à ceux obtenus dans des conditions de laboratoire (par exemple les focus groups) ;
• Évaluer la documentation utilisateur ;
• Accroître la sensibilisation pour un produit à venir ;
• Signaler les erreurs ou bugs gênant l’achat ou l’utilisation du produit ;
• Tester l’intégrité globale du SI qui supportera le produit ;
• Roder les équipes nouvellement formées aux outils ;
• Identifier les besoins du marché pour les futures versions ;

Être un outil de conduite du changement en interne, en faisant office de répétition générale avant la commercialisation, et d’adhésion des collaborateurs à un produit.

 

Quelles sont les attentes d’une phase bêta ?

Les attentes à court terme : les quickwins

Une phase bêta va générer beaucoup de commentaires en retour. En principe, ils sont pertinents et constructifs. Il est indispensable d’avoir un canal de communication qui fonctionne bien avec les testeurs et un système pratique pour les rapports de bugs.

Les commentaires reçus doivent être collectés, évalués et traités. Généralement les derniers bugs mineurs qui n’auraient pas été corrigés lors de la phase de recette sont identifiés très rapidement par les testeurs, il s’agit surtout des améliorations qui sont liées à l’affichage du site et dans une moindre mesure, sur les fonctionnalités. Ces modifications font partie des « quick wins », des gains rapides que d’une phase bêta peut fournir. Par exemple, il n’avait pas été défini de moyen de communication dédié dans les situations critiques entre le PMU et son partenaire gérant les risques, une soirée livebetting durant la phase bêta a fait émerger le besoin vital de mettre en place un téléphone rouge disponible 24h/24.

Un autre atout de la phase bêta à court terme est qu’il peut fournir le même environnement, expérience en tant que conditions de vie réelles.

Les attentes à long terme : les futures évolutions du produit et de sa commercialisation

Elles sont multiples :

• Augmenter la qualité du produit par l’identification d’erreurs (conception, usages envisagés, marketing…) ;
• Enrichir les futures versions du produit en identifiant les points d’amélioration en moyen terme : nouvelles fonctionnalités dans l’expérience de vente mais aussi dans le SAV, dans l’utilisation du produit en lui-même…
• Fournir une meilleure compréhension du marché cible ;
• Et parfois, comme une cerise sur le gâteau, les clients font émerger d’eux-mêmes des usages non prévus du service par le marketing produit. Par exemple, préparer un achat immobilier en regardant les vis-à-vis potentiels d’un appartement devient un jeu d’enfant avec Google Streetview.

Par exemple, lors de la bêta de son service innovant de réservation de train, l’objectif du site Capitaine Train était que le site atteigne une qualité suffisante pour pouvoir l’ouvrir au public. Lorsqu’il a été atteint, le site est passé en production.

Définir le degré d’ouverture de la bêta et recruter les testeurs

La phase de préparation devient incontournable et implique de faire des choix, notamment sur les participants lors du recrutement. Le service en version bêta est soit disponible à tout le monde pour les tests (c’est ce qu’on appelle une phase bêta ouverte – les testeurs sont volontaires, la bêta récente de Capitaine Train demandait juste de s’inscrire sur le site) soit à un groupe contrôlé et fermé de testeurs (c’est la phase bêta fermée – le recrutement des testeurs est basé sur invitation, les testeurs sont volontaires mais triés sur le volet, à l’image de Spotify qui a lancé une bêta fermée en mars 2013 à ses propres clients anglais pour tester la version web de leur application musicale).

De toutes les données créées pendant cette phase (compte clients, interactions, achats, utilisation du service…), doit on en garder certaines ? Il est indispensable de choisir si la bêta est jetable ou non jetable. Derrière ces termes abrupts se situe un choix tactique fort pour l’entreprise car les moyens sont très différents :

Une phase bêta jetable offrira un bac à sable, selon l’expression chère aux développeurs, à l’entreprise et aux testeurs, qui permet de lever un certains nombre de contraintes : pas de reprise des données dans les systèmes en production, qualité des données récoltées moins importante pendant la bêta, pas de prise en compte des données comptables dans le SI, sans compter les contraintes réglementaires s’il y en a. De plus, une phase bêta jetable peut être opérée sur des systèmes de préproduction, et ainsi ne pas gêner la production en cours.

Une phase bêta non jetable impliquera une préparation accrue, notamment car elle se jouera sur des systèmes en production : tous les nouveaux clients créés lors de la phase bêta devront intégrer le référentiel client et les flux comptables prendre en compte le nouveau service alors qu’il n’est pas lancé officiellement, …

Le nombre nécessaire de testeurs dépend de la taille du projet, un minimum de 10 personnes est nécessaire pour exécuter les scénarios préparés. Dans le cas des produits de consommation qui sont censés avoir un très large public (ex. jeux vidéo), le nombre minimum de testeurs devraient être entre 50 et 200. Parfois, ce nombre peut atteindre des milliers, par exemple : Starcraft 2, le jeu vidéo de Blizzard, avait plus de 20 000 testeurs actifs. Lors du lancement des paris sportifs sur internet par le PMU, 150 bêta testeurs ont été recrutés parmi les collaborateurs, sur 2 mois. Capitaine train a géré 22 000 bêta testeurs pendant 18 mois.

Dans le cas d’une bêta ouverte, le taux de réponses obtenues en termes de participation et d’utilisation réelle d’un programme de bêta varie largement selon plusieurs facteurs, notamment :

• Si le produit est complètement nouveau ou selon sa popularité ;
• Si le produit ou service est fortement attendu ;
• La popularité de l’entreprise (bien connue ou inconnue), et de la capacité de ses réseaux à faire connaitre le nouveau service (notamment via les réseaux sociaux) ;
• L’approche de recrutement (l’approche est-elle assez convaincante et personnelle ?) ;
• L’implication des testeurs : combien de temps et d’efforts le testeur devra t-il fournir lors de la phase bêta ?
• L’incentive : que gagne le testeur en retour ? Quelle est la reconnaissance de l’entreprise dans sa participation ?

Les activités et les phases principales de la phase Bêta

La phase pilote elle-même peut être divisée en trois phases différentes : la préparation, la réalisation et le bilan des résultats.

Phase de préparation

L’un des éléments clés de la réussite de la phase de préparation est d’avoir le cadre, les objectifs, les prévisions et les scénarios (best case/worst case) de tests bien définis. Tous les besoins du test doivent être listés au début de la phase (matériel/RH/outils/process).
Les rôles spécifiques prévus pour les testeurs doivent également être décrits, communiqués et compris.

Les résultats de la phase bêta doivent être mesurables et quantifiables. L’un des meilleurs moyens de procéder est de définir en amont les indicateurs clés de performance (KPI) de la phase pilote. Les KPIs peuvent être les suivants :

• Le nombre de bêta testeurs invités qui ont ouvert l’email d’invitation vs envoi (le taux d’ouverture) ;
• Le nombre de testeurs qui se sont inscrits vs envoi (le taux de transformation) ;
• Le nombre de bêta testeurs invités ayant fait des commentaires vs le nombre total ;
• Le nombre d’anomalies constatées et leur gravité (mineure, moyenne, importante, bloquante) ;
• Le nombre de scénarios joués ;
• Le nombre moyen de feedbacks par scenario ;

Les scénarios de la phase pilote, cœur de l’animation

Le meilleur moyen de piloter une phase bêta est de l’animer au travers de scénarios métier.

Ces scénarios devraient se concentrer sur les cas d’utilisation typique attendus. Les scénarios peuvent également se concentrer sur des aspects spécifiques de fonctionnalités qui nécessitent des tests dans des environnements clients.

Exemples : mettre un produit dans le panier d’achat, effectuer une recherche sur un produit…

Le test scénario idéal a plusieurs caractéristiques :

• Il est basé sur une histoire, sur la façon dont le produit est utilisé ;
• L’histoire est crédible, elle pourrait tout à fait se produire dans le monde réel ;
• L’histoire implique éventuellement une utilisation complexe du produit ;
• Les résultats des tests sont faciles à évaluer du point de vue du testeur (si je clique sur tel élément de navigation, alors telle fenêtre apparait).

Afin d’agrémenter la phase bêta dans la durée, la complexité et le degré de difficulté peuvent évoluer au cours du temps. Dans un premier temps, des scénarios simples permettent de s’approprier le nouvel environnement ou le produit. Ensuite ils seront plus évolués sur des fonctionnalités avancées. Pour finir, des scénarios catastrophes où certains événements ne sont pas fonctionnels (rupture de lien SI, mauvaise foi des bêta testeurs lors d’un appel au service client, … la liste peut être longue). Ces derniers scénarios sont en général les plus instructifs pour la maîtrise du système, autant pour le client que pour l’entreprise qui organise la phase bêta.

L’importance du pilotage lors de la phase de réalisation

Par vague, les testeurs exécutent les scénarios prédéfinis, et les commentaires commencent à affluer. Au cours de cette phase, l’animation de l’équipe et des testeurs est primordiale, et le suivi un des facteurs clé du succès du pilotage : des réunions régulières doivent être organisées en interne pour le suivi des KPIs et de la progression des scénarios, allant même jusqu’à faire un point journalier de brief/debrief des événements. De manière académique, un point pilotage quotidien sera mis en place pour avoir une vision globale du déroulement de la phase pilote, et ainsi informer les sponsors du projet lors des comités de pilotage du projet.

Quand et quelle durée ?

La phase bêta intervient nécessairement quelques temps avant la mise en production et le lancement commercial. Lancée trop tôt dans le projet, les retours utilisateurs seront concentrés sur les bugs et n’iront pas à l’essentiel de la fonction remplie.
Attention aussi à ne pas lancer une phase bêta trop tard dans le projet – lorsque le produit ou la nouvelle fonctionnalité est presque exempt de bugs. Il est indispensable de se laisser un temps d’adaptation minimum des «quickwins» avant le lancement commercial.

Une durée relativement courte, au maximum 2 mois, permet de tenir en haleine les bêta testeurs et les collaborateurs. Trop longue, les testeurs se désintéresseront du nouveau service et les feedbacks perdront en qualité et en fréquence.

Augmenter la quantité et améliorer la qualité des retours utilisateurs

Le nouveau service ou produit doit impérativement être expliqué aux bêta testeurs : s’ils comprennent le but du test et le mode de fonctionnement du produit testé, leurs remarques seront plus appropriées et pertinentes.

De plus, mettre en place un outil qui autorise les testeurs à communiquer publiquement entre eux permettra d’accroître la participation en créant un cercle vertueux qui motivera les plus timides. Ici aussi, naturellement, s’appliquent toutes les bonnes pratiques de modération de groupes et de community management.

Les leviers pour améliorer le retour utilisateurs sont les suivants :

• Mettre en place et organiser l’animation autour d’une équipe : nommer en interne un gestionnaire de commentaires de la communauté (community feedback manager) pour filtrer des commentaires inutiles ;
• Être réactif ! Répondre à vos testeurs de façon continue et répétitive afin de leur montrer que leur opinion est importante ;
• Indiquez aux bêta testeurs que vous prenez en compte leurs commentaires, et pas seulement que vous les avez reçus ;
• Répondre à tous les messages, quelque soit le point de vue et la nature des réactions des testeurs, comme l’a fait Capitaine Train.
• Ne pas diffuser plusieurs versions du produit en même temps, les testeurs doivent tous tester la même chose ;
• Être agile dans la gestion, ne pas hésiter à questionner plus précisément un testeur qui aurait des difficultés sur un scenario précis : est-ce un bug non identifié ? Une mauvaise compréhension qui pourrait être levée par une meilleure communication ?

La clé du succès de la phase pilote repose sur la capacité de l’entreprise à collecter, organiser, prioriser le nombre énorme de commentaires et les données générées par les participants impliqués. Cela peut prendre la forme de rapports de bugs, demandes de fonctionnalités, résultats d’enquêtes, forums d’utilisateurs, de tâches accomplies, et bien plus encore.

Une fois l’exécution des scénarios d’animation commencée, il faudra, facilement, stocker, organiser et diffuser cette information aux membres appropriés de l’équipe technique. Beaucoup d’entreprises tentent d’organiser cette masse d’informations par e-mail et feuilles de calcul simples. Même si ces outils sont peu coûteux et ne nécessitent pas d’apprentissage, ils ne peuvent pas traiter un grand nombre d’utilisateurs (> 10 participants = problème), ils ne permettent pas la communication entre les bêta testeurs et sont inadaptés pour un environnement d’équipe.

Pour l’équipe interne, il existe des outils d’ingénierie, comme BugZilla, Clearquest, TestTrack Pro,… Ces logiciels présentent une facilité d’adoption interne, une faible courbe d’apprentissage (la plupart des entreprises les ont) et ils offrent généralement une bonne visibilité des encours à l’équipe.

 

Les outils de gestion

Ces programmes sont construits pour le test bêta et sont globalement accessibles. Ils ont une faible courbe d’apprentissage pour les testeurs, mais sont potentiellement coûteux.

Lors de la gestion des commentaires, il faut garder à l’esprit les points suivants :

• Se concentrer sur les détails, la qualité perçue par les testeurs sera un vrai atout dans la réussite de la phase bêta même si le produit est perfectible ;
• Élaborer une stratégie pour gérer les doublons ;
• Répondre rapidement aux besoins de test ;
• S’assurer que les bonnes personnes obtiennent les bonnes données ;
• Déplacer l’effort de qualification de retour des utilisateurs vers les utilisateurs eux-mêmes, notamment via l’outil du forum.

Organisation et dispositif à mettre en place

Un bêta test est un nouveau processus pour les entreprises, en utilisant de nouveaux outils, nécessitant un nouveau circuit de décision et de nouveaux réflexes en général. La phase pilote ne peut être réalisée avec succès que si tout le monde connaît ses tâches et son champ d’autorité. Afin d’assurer l’efficacité, une structure organisationnelle doit être définie pour le projet, en précisant les rôles et les responsabilités de chaque membre de l’équipe. L’équipe bêta se compose généralement des bêta testeurs, d’un pilote, d’un chef de projet, de développeurs (MOE). Elle est chargée de la conduite opérationnelle des travaux.

L’organisation de l’équipe se présente généralement comme suit :

Le rôle d’un pilote est de coordonner le processus de test et la communication entre les gestionnaires de produits, bêta testeurs et développeurs, préparer la documentation du projet et faciliter les problèmes à venir tout au long de la phase bêta entière. Plus précisément, ses tâches sont :

• Qualifier les retours ;
• Prioriser les demandes (d’évolution quickwins) ;
• Gérer les doublons ;
• Gérer les bêta testeurs ;
• Gérer les forums/outils ;
• Traiter la documentation.

Bilan

A l’issue des scénarios de test bêta, toutes les réactions doivent être résumées et les évolutions doivent être classifiées. Nous pouvons définir des « quickwins » (modifications qui peuvent améliorer le produit à court terme) et évolutions à plus long terme (V2,…). Les commentaires utiles doivent être pris en compte, le produit doit être ajusté en conséquence et adapté aux exigences soulevées au cours de la phase de test.

Le bilan se passe aussi du coté des testeurs, où un questionnaire leur sera envoyé afin de recueillir leurs impressions et – aussi – de gagner un goodie ou se qualifier à un concours.

Dernières suggestions

En dernière suggestion, il sera nécessaire de garder une documentation exhaustive de la phase bêta et de communiquer avec les testeurs à travers l’ensemble du projet.
Cette approche permet d’identifier la plupart des questions qui ont été posées au cours de la phase de test. Il est alors impératif qu’aucun commentaire n’ait été oublié. A la fin du projet, il est possible de résumer les leçons apprises dans un retour d’expérience, cela peut être extrêmement utile pour la fois suivante.

Une lettre de remerciement doit également être envoyée aux bêta-testeurs à la fin de la phase de test. Si l’expérience de test est satisfaisante pour vos testeurs, vous pouvez probablement compter sur eux lorsque vous lancerez une future phase pilote.

Enfin, les pièges les plus courants à éviter :

• Choisir / accepter des bêta-testeurs « mal ciblés » ;
• Mauvaise gestion des testeurs et des données de test ;
• Manque de communication sur les attentes de la phase bêta avant et durant la bêta ;
• Une phase bêta trop longue ou trop courte ;
• Un nombre de bêta-testeurs mal calibré ;
• L’utilisation de la version bêta comme un outil de marketing pour faire connaître le nouveau produit.

En conclusion, la planification et l’exécution d’un programme bêta réussi est un véritable enjeu qui nécessite d’être abordé de manière très analytique, alors que les clients sont sur un mode émotionnel (notamment quand une marque s’adresse directement à eux).
En adoptant une approche rigoureuse, méthodique et professionnelle, en travaillant à faire de chaque bêta testeur un ambassadeur, la probabilité d’atteindre les objectifs fixés augmentera. Les axes d’enrichissement fonctionnel et d’usage du produit seront définis pour les prochaines versions, et amélioreront considérablement les chances de succès de votre produit dans le temps .

Sources :

• http://www.technshare.com/heres-the-right-way-to-have-your-software-bêta-tested/
• http://www.exampler.com/testing-com/test-patterns/patterns/pattern-scenario-testing-kaner.html
• http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf
• http://www.epictrends.com/resources/usability/bêtatesting.shtml
• http://www.slideshare.net/centercode/sucessful-bêta-testing-2034042

 

Article paru initialement sur le blog de Soft Computing, co-écrit avec Viktoria Forinda