Nous contacter au +33 1 84 20 44 13

Pourquoi réaliser des tests de montée en charge ?

Faire des tests de montée en charge… Pas si utile que ça ? Bien au contraire. Les bons tests réalisés à des périodes clés, voire de manière récurrente,  peuvent vous éviter d’importantes déconvenues. On vous explique en deux points simples pourquoi réaliser des tests de montée en charge est indispensable.

_

Parce qu’ils ne sont souvent jamais réalisés, ni par l’équipe projet, ni par

les hébergeurs

_

Dans les entreprises qui ont fait développer leur site (ou application, outil, etc.) en externe, une idée est largement répandue : « les équipes de mon prestataire auront forcément réalisé des tests de montée en charge, pour s’assurer qu’il reste accessible en cas de pic d’affluence. » C’est faux ! En fait, les développeurs ne réalisent quasiment jamais ces tests. Leur mission consiste à mettre à disposition un site en fonction de besoins exprimés (et c’est déjà une tâche conséquente !) Mais il ne leur est pas demandé de faire en sorte que l’infrastructure ou les lignes de codes  « tiennent le choc » en cas de forte hausse de fréquentation.

Dans le cas où une entreprise fait développer son site en interne, le problème est sensiblement le même. Par défaut, l’équipe projet a uniquement un engagement de résultat sur les besoins exprimés et l’application mise à disposition. Si ce n’est pas demandé, les tests de montée en charge ne seront pas réalisés.

Alors… suffirait-il de demander à ses développeurs de réaliser ces tests pour être tranquille ? Pas exactement. Car les batteries de tests mis à leur disposition sont des outils de stress tests  qui bombardent les frontaux de requêtes http et qui ne feront que vérifier l’adéquation de l’infrastructure avec le cahier des charges. En clair, ces tests (utiles) vont contrôler des facteurs tels que : le pourcentage d’utilisation de la mémoire vive du serveur, l’utilisation du disque dur, de la bande passante… mais en aucun cas la perception du site par un vrai internaute, du point de vue end-user.

Alors peut-être est-ce de la responsabilité de l’hébergeur de vérifier qu’un site supporte le choc créé par une foule d’internautes s’y connectant en même temps ? Non plus. Dans le meilleur des cas, et si c’est prévu dans le contrat qui la lie à son client, l’entreprise hébergeuse pourra vérifier via des stress tests que l’infrastructure est conforme au cahier des charges. Mais pas que l’application reste accessible dans les meilleures conditions et à tout moment, y compris en cas de forte affluence.

_

Pour éviter un perte de business, d’image, ou de crédibilité…

Alors quelles conséquences si ni l’équipe projet, ni les hébergeurs ne réalisent les bons tests de montée en charge ? Cela peut aboutir à une fâcheuse mésaventure, comme cela a été le cas pour un grand groupe de e-commerce. Le jour des soldes d’été, catastrophe : leur site est indisponible. Son accès est resté inopérant durant 48 heures, puis dégradé pendant une semaine. La note a été salée : plusieurs centaines de milliers d’euros de manque à gagner. Pourtant, ce groupe pensait avoir agi de façon prudente. Leur hébergeur avait réalisé des stress tests permettant de vérifier que l’infrastructure pouvait théoriquement supporter une hausse brutale de fréquentation. À l’issue de ces tests, tous les indicateurs étaient « au vert ».

Mais contre toute attente, le jour des soldes, le site était bien inaccessible. Pourquoi ? Car les tests réalisés ne reproduisaient pas à l’identique de la réalité un internaute qui allume son ordinateur, ouvre une session entre le poste client et le serveur, se connecte à un navigateur puis au site de e-commerce… En somme : les tests réalisés n’ont pas reproduit le parcours d’un internaute en conditions réelles.

Pour aider cette entreprise à affronter les soldes suivantes sereinement, CloudNetCare a réalisé une campagne de tests de montée en charge, mais en reproduisant cette fois des parcours clients réels. Cette stratégie a permis de déceler bon nombre de points de contention, qui n’avaient pas été repérés lors des précédentes campagnes. Par exemple, un blocage à 500 sessions simultanées a été identifié, tout comme un affichage anormalement lent d’une carte de points-relais, mesuré à plus de 40 secondes. Grâce à ce travail, les soldes d’hiver se sont déroulé parfaitement.

On s’aperçoit donc que si des tests sont parfois réalisés en vue de prévoir des hausses de fréquentation, ce ne sont souvent pas les bons ou ils ne sont pas suffisants. Les stress tests réalisés par les hébergeurs ou par les développeurs sont très utiles, mais uniquement pour vérifier la solidité de l’infrastructure. Ils seront en revanche insuffisants pour contrôler la qualité de l’expérience utilisateur. Cette nuance peut donner un faux sentiment de sécurité, qui volera hélas en éclat lors d’un véritable pic d’affluence.  

Les dernières actualités

Comment assurer l’UX sur vos applicatifs ?

L’UX (User Experience) passe par la disponibilité de votre site internet ou de vos applicatifs tout au long du parcours de l’utilisateur. Vous avez certainement mis en place des clauses ou des objectifs minimums d’accessibilité. Mais comment s'assurer de la viabilité de l'application sur son environnement de production ?

ESSAYER GRATUITEMENT
2018-07-26T14:21:40+00:00