Dans les coulisses

De l'intuition à la culture de l'essai

Christian Sager
18/9/2020
Traduction: traduction automatique
Photos: Thomas Kunz
Co-auteur: Christoph Glaser

Dans le développement de logiciels, nous prenons des décisions basées sur des données. Les tests A/B nous y aident. Nous n'étions pas satisfaits de l'outil de test externe.

Depuis plus de trois mois, les clients de digitec et Galaxus peuvent faire leurs achats sans impact sur le climat. C'est possible
la compensation climatique dans le check-out. Mais toute la clientèle n'a pas pu compenser dès le début. Au cours des deux premières semaines, nous avons effectué un essai A/B. Une partie des shoppers voyait dans le check-out la variante A connue sans option de compensation carbone. L'autre partie a trouvé dans le check-out la variante B qu'ils ne connaissaient pas encore, avec l'option de compenser leurs émissions de CO2. Nous voulions ainsi savoir comment notre clientèle réagissait à la fonction de compensation des émissions de CO2.

Des tests A/B de ce type sont devenus des outils bien établis dans le développement de logiciels pour mesurer l'efficacité de nouvelles fonctionnalités. Selon Google, à peine 30% des essais A/B sont positifs. Cela signifie que si vous ne testez pas, il y a 70% de chances que vous fassiez une modification qui aura un impact négatif.

Citation de W.E. Deming «Without data you're just another person with an opinion.»
Citation de W.E. Deming «Without data you're just another person with an opinion.»

Plus facile à dire qu'à faire

Même si le principe de base de l'A/B testing est vite compris, le sujet recèle une certaine complexité : à commencer par une hypothèse de test solide, en passant par un set-up et un tracking corrects, jusqu'à l'évaluation et l'établissement d'hypothèses de suivi. C'est la raison pour laquelle il existe de nombreux outils de test sur le marché qui simplifient certains aspects des tests A/B pour les équipes logicielles, voire les éliminent complètement. Jusqu'à présent, chez Digitec Galaxus, nous utilisions également un outil de test externe. Avec l'expérience croissante en matière de test et la courbe d'apprentissage globale de notre équipe d'ingénierie, nous sommes arrivés à un point où les équipes de développement ont rencontré divers problèmes avec l'utilisation de l'outil précédent. C'est là que le bât blesse :

  • Les exigences élevées en matière de performance des pages : nous voulons éviter autant que possible que le testing ait un impact sur le temps de chargement et donc sur l'expérience des utilisateurs.
    - L'outil utilisé jusqu'à présent était une boîte noire pour nous : nous n'avions pas de visibilité détaillée sur les méthodes utilisées pour générer les résultats des tests.

Et nous ne voulions pas non plus faire de compromis sur notre culture de l'expérimentation : Nous souhaitons être maîtres de la diffusion de nos tests A/B et proposer à nos utilisateurs des tests aussi rapides que possible.

Une solution rapide

En très peu de temps, nous avons réuni un groupe compact et motivé pour s'attaquer au problème. Le groupe était hétéroclite : des ingénieurs logiciels, un analyste, des chercheurs UX et des Product Owners ont abordé le thème avec motivation.

Nous avons commencé par nous demander quelles étaient nos options :

  • Résoudre les problèmes de l'outil existant
  • Evaluer un nouvel outil
    - Construire notre propre outil
Différents points de vue réunis au sein d'une équipe>
Différents points de vue réunis au sein d'une équipe>

Avec deux experts externes en A/B testing, nous nous sommes penchés sur les problèmes de performance et avons réalisé un petit audit. Nous nous sommes rapidement rendu compte qu'il n'était pas sorcier de construire notre propre outil selon nos exigences. De plus, cela nous permettrait d'avoir une visibilité et un contrôle total sur l'outil et de le faire évoluer à l'avenir en fonction de nos besoins.

L'outil de test doit également être testé

Le développement du nouvel outil a ensuite commencé. Les développeurs n'ont pas tout laissé tomber, mais ont investi de temps en temps quelques minutes à côté de leur travail principal. Et voilà qu'en l'espace de trois semaines, le premier prototype était prêt pour un premier essai. Nous avons ensuite validé la plausibilité des données et des résultats des tests par le biais de divers essais (tests AA). Après avoir coché la case verte derrière la validation, nous nous sommes lancés dans le premier essai pour le client final après six semaines au total. Nous étions tous impatients de voir les premiers résultats et de savoir si le nouvel outil allait tenir la route. Mais à notre grand soulagement, nous n'avons pas eu de mauvaises surprises et le premier essai s'est déroulé sans encombre !

La tension était à son comble avant le premier essai en clientèle finale.
La tension était à son comble avant le premier essai en clientèle finale.

Cinq mois se sont écoulés depuis et nous avons déjà fait tourner des dizaines d'essais sur notre outil. Il y a encore des défis à relever. Mais le fait d'avoir le contrôle total de notre outil nous permet de réagir rapidement et de le faire évoluer en fonction des besoins de nos équipes. Au fil du temps, l'équipe d'ingénierie hétéroclite et motivée s'est transformée en un groupe bien établi qui continue à faire avancer le thème des tests AB au sein de l'entreprise.

Rejoindre l'équipe

Vous aussi, vous avez envie de résoudre des problèmes en toute simplicité ? Alors consultez nos offres d'emploi:nos offres d'emploi

Cet article plaît à 25 personne(s)


User Avatar
User Avatar

Apprendre rapidement en faisant de petits pas précieux est la clé de produits réussis.

Ces articles pourraient aussi vous intéresser

  • Dans les coulisses

    Lego et iPhone : les plus fréquentes recherches de la clientèle

    par Manuel Wenk

  • Dans les coulisses

    Notre stratégie pour plus de durabilité

  • Dans les coulisses

    Une histoire d’amour entre un ingénieur logiciel et la logistique

    par Tiago Santos Baranita

Commentaire(s)

Avatar