Tests de performance, de charge et de sécurité

Les tests non fonctionnels vérifient comment l'application rend service, et pas seulement ce qu'elle fait : est-elle assez rapide quand beaucoup d'utilisateurs se connectent en même temps (tests de performance et de charge) ? Résiste-t-elle aux usages malveillants (tests de sécurité) ? Ce chapitre montre comment mesurer les performances de l'API de Prêt'Matos avec k6, lire ses indicateurs, et quels tests de sécurité un développeur automatise lui-même.

Les familles de tests de performance

Pour une application interne de 14 salariés, le test de charge suffit souvent : il vérifie que l'application répond correctement à la charge réaliste, avec une marge. Les autres servent pour un service exposé au public, ou avant un événement prévisible (une campagne d'inscriptions, des soldes).

Les indicateurs à mesurer

Un test de charge avec k6

k6, édité par Grafana Labs, est un outil libre de test de charge. Le scénario s'écrit en JavaScript ; l'outil, lui, est un programme autonome écrit en Go, qui s'installe à part (pas avec npm) : brew install k6 sous macOS, winget install k6 --source winget sous Windows, le paquet de la distribution sous Linux, ou l'image Docker grafana/k6. La version 2 est sortie en 2026.

// charge/catalogue.js : 20 utilisateurs qui consultent le catalogue
import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE_URL = __ENV.BASE_URL ?? 'http://localhost:3100';

export const options = {
  stages: [
    { duration: '30s', target: 20 }, // montée progressive à 20 utilisateurs
    { duration: '1m', target: 20 },  // 20 utilisateurs pendant une minute
    { duration: '10s', target: 0 },  // descente
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],   // moins de 1 % d'erreurs
    http_req_duration: ['p(95)<300'], // 95 % des requêtes en moins de 300 ms
  },
};

export default function () {
  const reponse = http.get(`${BASE_URL}/api/materiels`, {
    headers: { Authorization: 'Bearer jeton-julie' },
  });
  check(reponse, { 'statut 200': (r) => r.status === 200 });
  sleep(1); // un utilisateur réel réfléchit entre deux clics
}

On lance le test avec k6 run charge/catalogue.js. À la fin, k6 affiche un résumé : chaque seuil avec une coche ou une croix, puis les métriques. Les plus importantes :

Pour que les mesures veuillent dire quelque chose, l'environnement de test doit ressembler à la production : même type de serveur, même base, un volume de données réaliste (une table de 3 réservations ne révèle pas l'index manquant qui ralentira la table de 30 000 lignes). Et le scénario doit ressembler à l'usage : quelques réservations pour beaucoup de consultations du catalogue, pas l'inverse.

Interpréter un résultat et trouver le goulet

Un test de charge ne dit pas pourquoi l'application est lente, seulement quand. Si le seuil p95 n'est pas atteint, on cherche le goulet d'étranglement :

Les tests de sécurité

Les tests de sécurité vérifient que l'application résiste aux usages malveillants. Certains relèvent de spécialistes : la revue de code orientée sécurité, l'analyse statique (SAST), l'analyse de l'application en fonctionnement (DAST), l'analyse des dépendances (SCA) et le test d'intrusion, toujours mené avec une autorisation écrite et un périmètre défini. Le cours Sécurité applicative les présente (tests de sécurité). Mais une grande partie des tests de sécurité sont des tests automatisés ordinaires, que le développeur écrit lui-même avec les outils des chapitres précédents.

Ces tests ont un grand avantage sur un audit ponctuel : ils sont rejoués à chaque modification. Une route ajoutée sans son middleware d'authentification fait échouer la CI le jour même, au lieu d'attendre le prochain audit. C'est la non-régression appliquée à la sécurité.

Accessibilité et compatibilité

Deux autres familles de tests non fonctionnels concernent directement une application web :

• l'accessibilité : un outil automatique comme axe détecte une partie des défauts (chapitre 9) ; le reste se vérifie à la main, au clavier et avec un lecteur d'écran. En France, le référentiel RGAA décrit les critères à respecter, obligatoires pour les services publics et les grandes entreprises ; depuis le 28 juin 2025, la directive européenne sur l'accessibilité (transposée par la loi du 9 mars 2023) étend l'obligation à de nombreux services numériques privés, comme le commerce en ligne, la banque ou le transport ;
• la compatibilité : Playwright exécute les mêmes tests sur Chromium, Firefox et WebKit, et en taille téléphone, en ajoutant des projets dans sa configuration.

Exercices

describe('GET /api/reservations/:id', () => {
  test('renvoie 401 sans jeton', async () => {
    const reponse = await request(app).get('/api/reservations/1');

    expect(reponse.status).toBe(401);
  });

  test("renvoie 404 quand un salarié demande la réservation d'un autre", async () => {
    const reponse = await request(app).get('/api/reservations/1').set('Authorization', 'Bearer jeton-julie');

    expect(reponse.status).toBe(404);
    expect(reponse.body).not.toHaveProperty('materiel');
  });

  test('renvoie la réservation à la logistique', async () => {
    const reponse = await request(app).get('/api/reservations/1').set('Authorization', 'Bearer jeton-nadia');

    expect(reponse.status).toBe(200);
    expect(reponse.body).toMatchObject({ id: 1, materiel: 'PC-07', salarie: 5 });
  });
});