# Mettre en place un budget de tests de charge avant l’ouverture d’un service public en ligne

> Un test de charge générique rassure sans rien garantir : un budget de test cadré sur le trafic réellement attendu évite les mauvaises surprises à l'ouverture.

- Auteur : Clément Hadrot
- Publié le : 2025-06-25
- Mis à jour le : 2025-06-25
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/budget-tests-de-charge-avant-ouverture-service/

## L’essentiel

- Le budget se calcule sur un scénario réel, pas un chiffre rond arbitraire
- Chaque étape du parcours utilisateur a son propre coût serveur
- Le test doit inclure la marge de dépassement, pas seulement la moyenne attendue

Combien de visiteurs simultanés un service public en ligne doit-il réellement encaisser le jour de son ouverture ? La question paraît simple, mais la réponse la plus fréquente, un chiffre rond choisi sans méthode, du type mille utilisateurs simultanés, ne correspond en général à aucune réalité mesurable du service concerné. Un budget de test mal cadré rassure sur le papier sans garantir grand-chose le jour venu.

Cadrer un budget de test réaliste suppose de partir du scénario d'usage réel attendu à l'ouverture, plutôt que d'un chiffre générique, et de traduire ce scénario en une charge serveur précise, étape par étape du parcours utilisateur.

## Partir du scénario réel, pas d'un chiffre arbitraire

La première étape du cadrage consiste à documenter, aussi précisément que possible, ce qui va réellement se produire à l'ouverture : combien de personnes sont informées de la date et de l'heure exactes d'ouverture, par quel canal, et sur quelle fenêtre de temps ces personnes sont susceptibles de se connecter simultanément. Une ouverture annoncée par une campagne d'e-mails envoyée à heure fixe génère un pic bien plus concentré qu'une ouverture progressive relayée sur plusieurs jours par la presse.

Ce travail de cadrage transforme une question vague, « combien de trafic peut-on attendre », en une hypothèse chiffrée et documentée : par exemple, douze mille personnes informées par e-mail à 9 heures précises, dont on estime qu'un tiers se connectera dans les quinze minutes suivant l'envoi.

## Décomposer le parcours utilisateur en étapes à coût distinct

> L'essentiel à retenir : Le budget se calcule sur un scénario réel, pas un chiffre rond arbitraire ; Chaque étape du parcours utilisateur a son propre coût serveur ; Le test doit inclure la marge de dépassement, pas seulement la moyenne attendue

Un budget de test ne se limite pas à un nombre de requêtes par seconde global : chaque étape du parcours utilisateur sollicite le serveur différemment. Une simple consultation de page d'accueil, souvent mise en cache, coûte nettement moins cher en ressources serveur qu'une authentification suivie d'une soumission de formulaire, qui déclenche des écritures en base de données à chaque tentative.

| Étape du parcours | Coût serveur relatif | Mise en cache possible |
| --- | --- | --- |
| Consultation de la page d'accueil | Faible | Oui, largement |
| Création de compte utilisateur | Élevé | Non, écriture obligatoire |
| Soumission du formulaire principal | Élevé | Non |
| Téléchargement d'un justificatif après validation | Moyen | Partiellement |

Le budget de test doit reproduire cette répartition réelle plutôt qu'une charge uniforme sur une seule page, faute de quoi le test validerait une capacité qui ne correspond pas au parcours effectivement emprunté par les visiteurs le jour de l'ouverture.

## Retenir une marge de dépassement, pas seulement la moyenne attendue

Un scénario cadré sur le trafic moyen attendu laisse peu de marge en cas de dépassement, pourtant fréquent lors d'une ouverture médiatisée. Le budget retenu dans ce cadrage a multiplié par trois le pic estimé du scénario moyen, une marge choisie après avoir observé, sur un précédent lancement comparable, un dépassement réel d'environ deux fois et demie l'estimation initiale.

```
# Exemple de scénario k6 simplifié, ciblant l'étape la plus coûteuse
import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 900 },
    { duration: '3m', target: 900 },
    { duration: '2m', target: 0 },
  ],
};

export default function () {
  http.post('https://service.exemple.fr/wp-json/service/v1/inscription', {
    email: `test${__VU}@exemple.fr`,
  });
  sleep(1);
}
```

Ce scénario cible délibérément l'étape la plus coûteuse identifiée précédemment, la soumission du formulaire d'inscription, plutôt que de répartir uniformément la charge sur l'ensemble des pages du service.

## Ce que le budget doit préciser avant tout lancement de test

1. Le volume de requêtes attendu par étape du parcours, pas seulement un total global.
2. La fenêtre de temps sur laquelle ce volume est censé se concentrer, un pic de quinze minutes n'exigeant pas la même infrastructure qu'une montée en charge sur plusieurs heures.
3. La marge de dépassement retenue, justifiée par un précédent comparable ou, à défaut, par une hypothèse documentée et assumée.
4. Le seuil de dégradation acceptable, c'est-à-dire le temps de réponse maximal toléré avant de considérer le test comme un échec.

> Un test de charge qui ne reproduit pas le parcours réel des visiteurs ne teste rien d'utile : il rassure sur une hypothèse qui ne correspondra jamais au jour J.

## Ce que ce cadrage ne couvre pas

Ce cadrage porte sur la définition du budget de test lui-même, sur la base d'un scénario réaliste ; il ne traite pas du choix d'un outil de test de charge en particulier, plusieurs solutions existantes pouvant exécuter le scénario une fois celui-ci correctement défini.

## En résumé

Un budget de test de charge réaliste part d'un scénario d'ouverture documenté, décompose le parcours utilisateur par coût serveur réel, et retient une marge de dépassement assumée plutôt qu'une simple moyenne. Dans ce cadrage, la marge retenue a représenté trois fois le trafic moyen estimé, une précaution qui s'est révélée justifiée le jour de l'ouverture effective du service.