Partager sur

LinkedIn Facebook Twitter

Au départ de leur démarche d’expérimentation, les entreprises peuvent être amenées à tester de légères modifications sur leur site web, telles que la conception d’un CTA ou d’autres petits changements, dans le but de déterminer leurs performances et leur impact sur des KPIs tels que le taux de conversion et le nombre de transactions.

Cependant, à mesure qu’un programme d’expérimentation se développe, les entreprises sont susceptibles de s’intéresser à des types de testing de plus en plus sophistiqués, qui requièrent plus d’expertise mais aussi un outil plus perfectionné.

C’est à ce moment-là que de nombreuses entreprises sont prêtes à passer de l’expérimentation client-side à l’expérimentation server-side.

Dans cet article, nous examinerons le moment opportun pour passer au server-side et nous reviendrons sur l’importance d’effectuer ces types de tests, à l’aide de différents scénarios dans lesquels les expérimentations server-side sont les plus appropriées. 

Le testing client-side et server-side

Avant d’approfondir le testing server-side, nous allons rapidement souligner les différences entre le testing client-side et le testing server-side afin de comprendre pourquoi vous avez besoin de ces deux types de tests au fur et à mesure que votre programme d’expérimentation et d’optimisation évolue.

Avec le testing client-side, l’expérimentation a lieu sur l’interface client par l’intermédiaire de Javascript qui s’exécute depuis le navigateur. Les outils client-side vous permettent donc de créer des variations de vos pages en modifiant le contenu envoyé par votre serveur aux utilisateurs dans leur navigateur web. L’utilisateur reçoit alors une variation de votre contenu modifié en fonction de vos règles de ciblage.

En d’autres termes, tout le travail se fait au niveau du navigateur grâce à Javascript. C’est pourquoi le testing client-side est généralement mieux adapté aux modifications de surface telles que la mise en page, la conception et les couleurs, afin de mesurer leurs performances et leur impact sur les principaux KPIs.

En revanche, tout le travail de testing server-side s’effectue au niveau du serveur et non du navigateur. En d’autres termes, c’est votre serveur qui envoie au hasard à un utilisateur la variation modifiée. Par conséquent, l’outil d’expérimentation travaille sur le serveur et non dans le navigateur de l’utilisateur. 

L’un des principaux avantages du testing client-side est qu’il est facile à mettre en œuvre et qu’aucune expertise particulière n’est requise pour exécuter les différents tests sur le front-end du site web.

Cependant, en raison de leurs caractéristiques avancées, les tests server-side requièrent une expertise technique et des compétences en matière de codage, de sorte que les développeurs sont généralement ceux qui les exécutent sur le back-end.

Quels sont les avantages du testing server-side ?

Avant d’aborder la question de l’utilisation du testing server-side, nous allons présenter quelques-uns de ses avantages afin de mieux comprendre les cas d’utilisation qu’il recouvre.

L’expérimentation omnicanale

Les solutions client-side sont généralement limitées aux appareils dotés d’un navigateur web, qu’il s’agisse d’un ordinateur de bureau, d’un téléphone portable ou d’une tablette. Cela signifie que vous ne pouvez pas mener d’expériences sur des applications mobiles ou des appareils connectés.

Les solutions server-side, quant à elles, vous permettent d’expérimenter sur plusieurs canaux, y compris les applications mobiles, ce qui élargit considérablement votre champ d’action et vous offre de nombreuses possibilités de testing au-delà des navigateurs web, afin de couvrir toutes vos bases.

Des performances optimisées

L’un des principaux avantages du server-side est peut-être l’absence d’effet flicker, qui est souvent un inconvénient majeur associé aux solutions client-side.  

L’effet flicker se produit lorsque la page d’origine se charge et est remplacée par la variation du test, ce qui est généralement perçu par l’utilisateur.

Contrairement aux outils client-side qui nécessitent l’ajout d’un tag Javascript à vos pages, vous n’avez pas besoin d’ajouter ce tag dans les outils server-side. En effet, les expérimentations sont exécutées sur le serveur avant d’être envoyées au client, de sorte que tout le travail se fait au niveau du serveur et n’est donc pas perceptible par le client. 

En d’autres termes, lors d’un test server-side, la variation est extraite du serveur et transmise au navigateur de l’utilisateur. Par conséquent, aucune modification n’a lieu sur le front-end ou le navigateur, et il n’y a donc pas d’effet flicker.

Des possibilités de test infinies

Vos équipes ont beaucoup plus de possibilités de développement lorsqu’il s’agit de testing server-side, car il vous permet de modifier tous les aspects de votre site.

Comme les tests server-side sont exécutés à partir du serveur back-end, vous pouvez tester des contenus dynamiques plus complexes, contrairement aux tests client-side où il n’est pas facile de tester de tels contenus. Ces tests peuvent même nuire à l’expérience de l’utilisateur s’ils sont effectués sur le client-side. 

En d’autres termes, vous pouvez construire des tests beaucoup plus complexes qui vont plus loin dans votre tech stack et au-delà de la portée de l’interface utilisateur ou de changements purement esthétiques, afin d’ouvrir un tout nouveau monde d’expérimentation. 

Avec des capacités d’expérimentation aussi poussées, les équipes peuvent tester en profondeur toutes les facettes d’un produit pour évaluer ses fonctionnalités, notamment ses caractéristiques sous-jacentes, ses algorithmes et sa logique back-end. 

La section suivante passe en revue les différents cas d’utilisation pour lesquels vous devriez plutôt envisager d’exécuter des tests server-side.

Quand est-il judicieux de passer au testing server-side ?

Comme nous l’avons mentionné, les tests server-side sont généralement utilisés pour exécuter des types de tests plus avancés et expérimenter en profondeur au sein de votre tech stack afin d’explorer en détail le fonctionnement d’un produit.

Pour faire simple, les solutions d’expérimentation server-side permettent aux équipes de mener des expériences plus robustes et plus sûres, axées sur la modification des fonctions d’un produit. 

Voici quelques cas d’utilisation où le server-side est recommandé par rapport au client-side :

• Exécutez des expérimentations sur votre application mobile

Comme mentionné précédemment, l’un des principaux avantages des tests server-side est de permettre une expérimentation omnicanale et multiplateforme.

Comme les solutions client-side reposent sur Javascript et les cookies, il n’est pas possible de les utiliser pour tester des applications mobiles natives et vous êtes limité aux appareils dotés d’un navigateur web par défaut.

Cela signifie que vous aurez besoin d’une solution de testing server-side plus avancée pour gérer les technologies des applications mobiles, qui sont plus complexes et très différentes des technologies web. 

De plus, comme les tests server-side fonctionnent à la fois sur les applications web et les applications mobiles, vous pouvez effectuer le même test sur les mêmes variations, quel que soit le canal utilisé. Cela vous permet de comparer les données de chaque canal et d’optimiser en conséquence l’expérience de l’utilisateur sur les différents points de contact. 

Enfin, si vous utilisez des feature flags pour effectuer des tests server-side sur des applications mobiles, vous pouvez contourner l’approbation fastidieuse et chronophage des app stores. En d’autres termes, les feature flags vous permettent d’activer ou de désactiver des fonctionnalités à distance sans avoir à redéployer le code dans les app stores et à attendre leur approbation, ni à attendre que toutes les modifications soient prêtes en même temps pour publier vos changements.

• Testez vos algorithmes de search

Les A/B tests server-side sont efficaces pour tester des modifications plus profondes liées au backend et à l’architecture de votre site web.

C’est le cas des algorithmes de search qui nécessitent une modification du code existant. Les sites e-commerce se tournent généralement vers le testing server-side pour s’assurer que les clients peuvent facilement naviguer sur leur site et trouver le produit qu’ils recherchent. 

Les algorithmes de search sont essentiels pour permettre aux clients de trouver le bon produit en leur offrant une expérience de recherche transparente qui les incite finalement à acheter.

Par exemple, vous pouvez tester ce qui est affiché aux clients dans leurs résultats de recherche, si cela doit être basé sur le prix, la popularité ou les avis, ou si vous devez prioriser les produits en fonction de ce que les clients ont acheté/aimé/vu dans le passé. 

Le testing server-side vous permet de créer des scénarios et des règles complexes afin de fournir aux clients des recommandations plus personnalisées et d’optimiser leur expérience de recherche sur votre site. Ces tests sont plus difficiles à réaliser à l’aide de solutions client-side, car les pages de recherche sont basées sur la commande de recherche et sont donc affichées de manière dynamique.

Les tests server-side sont donc plus complets et permettent d’expérimenter plusieurs algorithmes en modifiant le code existant.

• Optimisez vos recommandations produit

De même, grâce à des outils server-side, vous pouvez tester plusieurs algorithmes de recommandations produit, qui se trouvent généralement au bas des pages produit, afin de déterminer quel type de présentation génère le plus de ventes ou augmente la valeur du panier moyen. Par exemple, est-il préférable de promouvoir des produits similaires, les produits les plus populaires ou ceux qui ont été récemment consultés ?

Ces recommandations sont basées sur une variété de critères, comme l’historique de navigation, votre propre système PIM (Product Information Management) et d’autres sources de données. Le server-side vous permet de tester ces multiples algorithmes afin de découvrir la sélection de produits recommandés la plus performante.

• Tester des pages sensibles au niveau des données

Le testing server-side est parfait pour tester des pages où la protection des données est vitale, car il permet de s’assurer que les données restent en sûreté à l’intérieur du serveur sans avoir à s’inquiéter d’une menace pour la sécurité.

C’est l’idéal pour tester les pages de paiement e-commerce ou des applications bancaires par exemple, ou bien toute autre page web ou application contenant des données sensibles.

Vous pouvez également utiliser les feature flags pour tester une nouvelle méthode de paiement sur un sous-ensemble d’utilisateurs et voir comment ils s’y adaptent avant de l’étendre à tous les autres.

• Déterminer la longueur idéale des formulaires

Ceci est particulièrement important pour les entreprises SaaS qui s’appuient sur des formulaires d’essai gratuit et de demande de démonstration pour recueillir des informations auprès de leurs visiteurs. Elles doivent donc déterminer la longueur idéale de ces formulaires sans risquer de perdre des utilisateurs, tout en étant en mesure de recueillir toutes les informations nécessaires sur un prospect. 

Le server-side est la meilleure solution dans ce scénario, car vos formulaires sont directement liés à la structure de votre base de données. Si un champ est obligatoire, vous ne pourrez pas le masquer à l’aide de JavaScript, car la validation du formulaire échouera côté serveur.

Par conséquent, tester la longueur et la complexité d’un formulaire pour obtenir l’impact positif le plus élevé possible sur les taux de conversion doit être effectué via du server-side.

Cela s’applique également à d’autres sites web qui utilisent de tels formulaires, tels que les sites de réservation d’hôtels ou d’assurances. Il convient de noter que les différents secteurs exigeront des informations différentes, plus ou moins nombreuses, en fonction du type et de l’objectif de l’information recueillie.

• Tester la limite de la gratuité des frais de port

Les entreprises de e-commerce doivent être en mesure de déterminer le montant de la commande à partir duquel la gratuité des frais de port est possible. C’est important, car les frais d’expédition sont l’une des principales causes d’abandon de panier.

Les frais d’expédition étant l’un des facteurs déterminants dans la décision d’achat d’un client, les entreprises devraient tester différents seuils de valeur de panier afin de trouver la limite optimale pour la gratuité des frais d’expédition et ainsi améliorer le taux de transaction.  

Les frais de port étant généralement calculés de manière dynamique à partir du serveur back-end, vous devrez les tester grâce au server-side. Toute modification apportée devrait avoir un impact sur toutes les étapes suivantes et devrait être gérée via le server-side.

• Validez vos fonctionnalités

Le testing server-side vous permet d’effectuer des tests de features pour valider les fonctionnalités de votre produit en déployant différentes variations auprès de différents groupes d’utilisateurs et dans le but d’évaluer leurs performances avant de procéder à un release générale. 

À l’aide des feature flags, vous pouvez effectuer des A/B tests server-side et segmenter vos utilisateurs en les orientant vers l’une ou l’autre variation. En cas de problème avec une variation, vous pouvez facilement revenir en arrière en désactivant le flag avant que l’expérience de l’utilisateur n’en pâtisse davantage. 

Enfin, en fonction du retour des utilisateurs, vous pouvez optimiser vos fonctionnalités et les mettre à la disposition de tous les utilisateurs en étant sûr qu’elles répondent aux réels besoins des clients.

Le testing server-side et les feature flags

La meilleure façon d’effectuer des tests server-side est d’utiliser les feature flags. En découplant le déploiement des releases, vous pouvez effectuer des A/B tests server-side en déployant de nouvelles fonctionnalités auprès d’un petit groupe d’utilisateurs. Vous pouvez ensuite mesurer leurs performances sur ce groupe d’utilisateurs avant de les déployer sur tous les autres.

Si le server-side requiert une expertise technique et des compétences en matière de codage, il n’est pas réservé exclusivement aux équipes tech. Souvent, les équipes non « spécialisées » s’accordent avec les équipes produits pour définir les tests qui sont ensuite exécutés par les ingénieurs. Une fois mise en œuvre, une expérimentation peut généralement être contrôlée, surveillée et analysée à l’aide d’un tableau de bord.

Avec la bonne solution de feature management, toutes les équipes d’une même organisation peuvent exécuter des tests server-side à l’aide d’un tableau de bord facile à utiliser, sans avoir à faire face à des difficultés techniques.

Client-side et server-side : l’importance du contexte

En fin de compte, il est important de noter que la question n’est pas de savoir si le server-side est meilleur que le client-side. Il s’agit de deux approches complémentaires et le choix de l’une ou l’autre dépend de ce qui convient le mieux à l’optimisation et aux objectifs business plus larges de chaque l’entreprise.

En d’autres termes, un type de test ne remplace pas un autre. Il s’agit d’examiner le type d’expérimentation que vous souhaitez mener et de déterminer lequel est le mieux adapté à ce contexte particulier et aux équipes qui souhaitent mener l’expérience – les marketers ont tendance à privilégier et à utiliser le plus souvent les tests client-side, tandis que les chefs de produit et les développeurs optent généralement pour du server-side. Cela dépend également des ressources dont disposent les entreprises et de la maturité de leurs programmes d’optimisation.

Pour garantir que votre site web est optimisé et qu’il offre une expérience utilisateur fluide, il est essentiel d’avoir les deux techniques de testing à portée de main pour survivre dans un monde digital compétitif. 

Les deux types de tests sont indispensables pour vous aider à créer des produits de qualité qui vous rapporteront un maximum de revenus. La clé est d’utiliser les deux ensemble pour augmenter la productivité et obtenir un impact maximal.

Partager sur

LinkedIn Facebook Twitter