Tests A/B en Java : comment savoir avec certitude, sans avoir à deviner

Introduction : Pourquoi votre application perd de l'argent sans que vous le remarquiez

Avez-vous déjà pensé au nombre d'utilisateurs qui abandonnent votre application Java à cause d'un bouton "Acheter" mal conçu ? Ou peut-être que votre nouveau système de recommandation, sur lequel vous avez travaillé pendant un mois, a en réalité détérioré le taux de conversion ? Dans le monde du développement, les solutions "évidentes" qui échouent lamentablement sont légion. La seule façon d'arrêter de lire dans le marc de café est de mettre en place des tests A/B en Java.

Dans cet article, nous allons voir comment intégrer un test A/B complet directement dans votre application Java. Vous apprendrez à diviser les utilisateurs en groupes, à mener l'expérience et, surtout, à éviter les erreurs statistiques. Pas de blabla, que du code et de la pratique. C'est parti !

Qu'est-ce qu'un test A/B et pourquoi un développeur Java en a-t-il besoin ?

Un test A/B (ou test fractionné) est une méthode qui compare deux versions (A et B) d'une interface, d'un algorithme ou d'une logique pour déterminer laquelle fonctionne le mieux. En termes simples : vous montrez l'ancien bouton à 50 % des utilisateurs et le nouveau aux 50 % restants, puis vous observez où il y a le plus de clics.

C'est particulièrement pertinent pour les applications Java :

• Logique backend : Modification de l'algorithme de tri des produits, des recommandations, de la tarification.
• API et microservices : Test d'une nouvelle version d'un endpoint sur une partie du trafic.
• Composants d'interface utilisateur : Si votre framework Java (par exemple, Vaadin ou Spring MVC) génère du HTML.

L'idée clé : les tests A/B dans les applications Java permettent de prendre des décisions basées sur des données, et non sur l'intuition. Cela réduit les risques et améliore les métriques du produit.

Architecture d'un test A/B : Penser comme un ingénieur

Avant d'écrire du code, concevons le système. Nous avons besoin de :

1. Un service d'attribution des variantes — qui détermine dans quel groupe se trouve chaque utilisateur.
2. Un stockage des expériences — où sont conservés les paramètres (quelle expérience est active, quel pourcentage de trafic).
3. Un collecteur d'événements — pour journaliser les actions des utilisateurs.
4. Un analyseur — un outil externe ou un script pour calculer les statistiques.

Dans cet article, nous nous concentrerons sur les deux premiers points, car la collecte et l'analyse sont des sujets pour d'autres articles.

Service de randomisation : Surtout pas de bug dans random()

La façon la plus simple de diviser le trafic est d'utiliser Math.random(). Mais ce n'est pas fiable : au redémarrage de la JVM, un utilisateur pourrait se retrouver dans un autre groupe. Nous avons besoin d'une randomisation déterministe basée sur l'identifiant de l'utilisateur.

La meilleure approche est de hacher l'userId et de prendre le reste de la division. Ainsi, un utilisateur verra toujours la même version tant que l'expérience est active.

public class RandomizationService {

    public String assignVariant(String userId, String experimentId, int splitPercent) {        // Utilisation de userId + experimentId pour le déterminisme        String seed = userId + ":" + experimentId;        int hash = Math.abs(seed.hashCode());        int bucket = hash % 100;

        if (bucket < splitPercent) {            return "B"; // Nouvelle version        } else {            return "A"; // Version de contrôle        }    }}

Important : hashCode() peut être négatif, donc on utilise Math.abs(). Il faut également noter que la répartition ne sera pas parfaitement uniforme avec un petit nombre d'utilisateurs, mais pour 1000+ utilisateurs, cela convient.

Exemple concret : Test A/B avec Spring Boot

Supposons que nous ayons une boutique en ligne avec Spring Boot. Nous voulons tester un nouveau modèle de tarification : afficher une réduction uniquement si l'utilisateur a passé plus de 30 secondes sur le site (version B) par rapport à une réduction standard (version A).