Lundi matin, clôture du mois. Une centaine de personnes se connectent en même temps à votre outil de gestion, et l’écran se met à tourner. Personne ne comprend : « les tests étaient bons ». Ils l’étaient, mais ils répondaient à une autre question que celle qui compte.

Dans cet article, nous partageons ce que nous avons appris en soumettant une plateforme de gestion multi-clients (un logiciel en ligne partagé entre plusieurs entreprises) à des tests de charge. Nous n’y parlons ni de ses données ni de ses clients, seulement des enseignements, utiles à tout dirigeant qui met un logiciel entre les mains de ses équipes ou de ses clients.

Pourquoi cinq testeurs ne prouvent rien

Lors d’une recette classique, quelques personnes cliquent sur les écrans. Tout est rapide, tout fonctionne. Or certains défauts n’existent que lorsque plusieurs utilisateurs agissent exactement au même moment. Avec un ou cinq testeurs, ils restent invisibles. Ils apparaissent le jour où l’activité réelle les déclenche, c’est-à-dire en production, devant vos utilisateurs.

Un test de charge consiste à simuler ces utilisateurs simultanés avec un outil (nous utilisons k6, gratuit et très répandu) et à mesurer deux choses : le temps de réponse de l’application, et la part de requêtes qui échouent.

Les quatre tests à connaître

Chacun répond à une question différente. Un projet qui ne fait que le premier croit avoir fait les quatre.

Un cas vécu : correcte à quelques utilisateurs, figée à une dizaine

Nous avons testé une plateforme dont la base de données n’accepte qu’un nombre limité de connexions simultanées (le « pool de connexions »). Avec un à cinq utilisateurs, tout était fluide. Quand le nombre d’appels simultanés a atteint la taille de ce pool, l’application s’est figée en entier : les requêtes attendaient une trentaine de secondes avant d’échouer, et même la page d’état de santé ne répondait plus. Le blocage a persisté plus d’une minute après l’arrêt du test.

Ce n’était pas un écran lent : c’était toute l’application. Et le seuil ne dépendait pas d’une charge « élevée » en absolu, mais d’un chiffre précis : le nombre d’appels simultanés égal à la taille d’une ressource partagée. Seul un test conçu pour atteindre puis dépasser ce seuil pouvait le voir.

Pourquoi : l’analogie des caisses

Imaginez un supermarché avec 10 caisses. Chaque client arrive à une caisse et refuse de la libérer tant qu’une deuxième caisse ne s’est pas libérée pour finir ses achats. Avec 9 clients, tout va bien. Avec 10, toutes les caisses sont occupées par des clients qui attendent une autre caisse : plus personne ne sort, et le magasin entier s’arrête, même pour ceux qui n’achètent qu’une baguette.

Dans un logiciel, les caisses sont les connexions à la base de données, et les clients sont les requêtes. Le mécanisme exact, avec le code et la correction, est détaillé dans notre article technique sur le pool de connexions saturé.

Quand les données grossissent

Deuxième enseignement : un système qui tient bien avec quelques milliers de lignes peut devenir lent avec plus de cent mille. Nous avons fait grossir progressivement les données de la même plateforme, avec les mêmes scénarios. Elle n’est jamais tombée : elle a ralenti, et fortement, dès que les listes et les totaux ont dû parcourir de très grandes tables.

La cause n’était plus les connexions mais la base de données : des recherches qui lisaient toute la table au lieu de s’appuyer sur un index (l’équivalent de l’index alphabétique d’un livre). Un index adapté à la requête d’une liste l’a fait passer de quelques centaines de millisecondes à moins d’une milliseconde.

Précision importante : un index mal choisi ne sert à rien. Notre premier essai ne correspondait pas à la requête réellement exécutée et n’a presque rien changé. Il faut regarder la requête réelle avant de décider.

Comment tester sans prendre de risque

1. Un environnement isolé, jamais les données de vos clients.
2. Un jeu de données réaliste, à la taille que vous aurez dans deux ans, pas celle d’aujourd’hui.
3. Une montée progressive avec arrêt automatique si les erreurs ou les lenteurs dépassent un seuil.
4. Des profils d’utilisateurs différents : un administrateur et un collaborateur n’ouvrent pas les mêmes écrans.
5. Prudence en production : uniquement des lectures et une charge faible, jamais un test de saturation sans fenêtre prévue ni équipe présente.
6. Répéter à chaque évolution importante, idéalement de façon automatique.

Nos erreurs de test (et pourquoi nous vous les racontons)

• Un test qui « passait » sans rien vérifier. Il attendait une liste dans un format précis, alors que certains écrans la renvoyaient dans un autre : il contrôlait zéro élément et affichait zéro anomalie.
• Un résultat lu sur la mauvaise instance. Un ancien processus occupait encore le port : nous testions la mauvaise version.
• Un index qui ne correspondait pas à la vraie requête.

La leçon est la même trois fois : un test qui passe ne prouve rien tant qu’on n’a pas vu qu’il peut échouer.

Trois questions à poser à votre équipe ou à votre prestataire

1. Testez-vous avec autant d’utilisateurs simultanés que notre pic réel, et au-delà ?
2. Testez-vous avec le volume de données que nous aurons dans deux ans ?
3. Quand le système est saturé, l’utilisateur voit-il une erreur claire en quelques secondes, ou un écran qui tourne ?

Questions fréquentes

Quelle différence entre test de charge et test de stress ? Le test de charge vérifie que l’application tient la charge attendue. Le test de stress dépasse volontairement cette charge pour savoir où et comment elle cède.

Combien d’utilisateurs simultanés faut-il tester ? Au moins votre pic réel, puis le double. Surtout, testez au niveau des limites techniques (taille des pools, nombre de processus) : c’est là que se cachent les blocages.

Peut-on tester en production ? Prudemment : lectures seulement, charge faible et montée progressive avec arrêt automatique. Les tests qui saturent ou écrivent se font dans un environnement isolé.

Un test de charge coûte-t-il cher ? Les outils sont gratuits. Le travail est surtout de construire des scénarios réalistes et un jeu de données représentatif, un investissement vite rentabilisé par une seule panne évitée.

À quelle fréquence le refaire ? À chaque évolution importante, et idéalement à chaque livraison par un petit test automatique.

En conclusion

Une application qui « marche » n’est pas une application qui « tient ». Entre les deux, il y a un test que presque personne ne fait avant la mise en production. Chez Neologix, nous réalisons des audits de performance et de fiabilité : scénarios de charge, volumétrie, rôles et rapport clair, sans jargon. Si vous préparez une mise en production ou si vous subissez des lenteurs, parlons-en 30 minutes. Pour replacer cette démarche dans une stratégie plus large, consultez notre guide de la transformation digitale au Maroc.