Guide de test d'API : des bases aux workflows automatisés

Les API sont les contrats qui lient les systèmes logiciels entre eux. Quand une API tombe en panne, tout ce qui en dépend tombe avec elle. Pourtant, les tests d'API sont souvent relégués au second plan — quelque chose qu'on fait manuellement dans un onglet de navigateur juste avant le déploiement. Une stratégie de test d'API rigoureuse détecte les bugs tôt, documente le comportement attendu et vous donne la confiance nécessaire pour livrer.

Qu'est-ce qu'un test d'API ?

Un test d'API envoie une requête HTTP et vérifie certaines propriétés de la réponse :

• Code de statut — Obtient-on 200 OK ou 404 Not Found ?
• Corps de la réponse — La structure des données est-elle correcte ? Les valeurs sont-elles exactes ?
• En-têtes — Content-Type est-il correctement défini ? L'en-tête d'authentification est-il présent ?
• Temps de réponse — L'endpoint répond-il dans un délai acceptable ?
• Gestion des erreurs — Que se passe-t-il avec des données invalides ? Obtient-on des messages d'erreur explicites ?

Les codes de statut HTTP à connaître absolument

Code	Signification	Quand vous le verrez
200	OK	GET, PUT, PATCH réussis
201	Created	POST réussi créant une ressource
204	No Content	DELETE réussi ou action sans corps de réponse
400	Bad Request	Entrée invalide, JSON malformé, champs manquants
401	Unauthorized	Token d'authentification absent ou invalide
403	Forbidden	Authentifié mais non autorisé
404	Not Found	La ressource n'existe pas
409	Conflict	Ressource en doublon, conflit de version
422	Unprocessable Entity	Erreurs de validation sur un JSON valide
429	Too Many Requests	Limite de débit dépassée
500	Internal Server Error	Bug côté serveur
503	Service Unavailable	Serveur hors ligne ou surchargé

401 signifie « qui êtes-vous ? » — 403 signifie « je sais qui vous êtes, mais vous n'avez pas le droit de faire ça. »

Tests manuels avec l'API Request Builder

Avant d'automatiser, explorez vos endpoints manuellement. Notre API Request Builder vous permet de :

• Définir la méthode HTTP (GET, POST, PUT, PATCH, DELETE)
• Ajouter des en-têtes (Authorization, Content-Type, en-têtes personnalisés)
• Construire des paramètres de requête sans encodage URL manuel
• Rédiger un corps de requête JSON avec coloration syntaxique
• Inspecter la réponse complète, y compris les en-têtes et les temps de réponse

C'est idéal pour explorer une nouvelle API, déboguer un endpoint spécifique ou vérifier rapidement un correctif.

Tester les API REST : le cycle CRUD complet

Pour une API /users hypothétique, une suite de tests complète couvre :

Création (POST)

POST /users
Content-Type: application/json

{
  "name": "Alice Chen",
  "email": "alice@example.com",
  "role": "editor"
}

Vérifier :

• Statut 201 Created
• Le corps de la réponse contient l'utilisateur créé avec un id généré
• L'en-tête Location pointe vers la nouvelle ressource (ex. /users/42)

Lecture (GET)

GET /users/42
Authorization: Bearer <token>

Vérifier :

• Statut 200 OK
• Le corps correspond à l'utilisateur créé
• id vaut 42

Mise à jour (PUT / PATCH)

PATCH /users/42
Content-Type: application/json

{ "role": "admin" }

Vérifier :

• Statut 200 OK
• role vaut désormais "admin" dans la réponse
• Les autres champs sont inchangés

Suppression (DELETE)

DELETE /users/42
Authorization: Bearer <token>

Vérifier :

• Statut 204 No Content
• Un GET /users/42 ultérieur retourne 404

Tests négatifs : les tests que la plupart des gens ignorent

Les tests positifs vérifient le chemin nominal. Les tests négatifs vérifient que l'API gère gracieusement les entrées incorrectes :

• Champs obligatoires manquants → 400 avec message d'erreur clair
• Types de données invalides ("age": "twenty") → 400
• Ressource inexistante (GET /users/99999) → 404
• Token expiré → 401
• Accès aux données d'un autre utilisateur → 403
• Envoi d'un payload de 10 Mo → 413 Payload Too Large
• Dépassement des limites de débit → 429 avec en-tête Retry-After

Une API bien conçue échoue de manière prévisible et informative.

Stratégies de test de l'authentification

Tokens Bearer (JWT)

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Scénarios à tester :

• Token valide → réponse correcte
• Token expiré → 401 avec message "Token expired"
• Token altéré (modifier un caractère) → 401
• En-tête absent → 401
• Token destiné à un autre environnement → 401

Utilisez notre JWT Decoder pour inspecter les tokens et vérifier les dates d'expiration lors des tests manuels.

Clés API

X-API-Key: sk_live_abc123

Tester : mauvaise clé, clé absente, clé avec des permissions insuffisantes.

Flux OAuth 2.0

OAuth ajoute de la complexité — testez les endpoints d'échange de token séparément des endpoints de ressources.

Valider les corps de réponse

Ne vous contentez pas de vérifier les codes de statut. Validez la structure des réponses :

// Using Jest + supertest
test("GET /users/:id returns the correct user", async () => {
  const response = await request(app).get("/users/42").set("Authorization", `Bearer ${token}`);

  expect(response.status).toBe(200);
  expect(response.headers["content-type"]).toMatch(/json/);
  expect(response.body).toMatchObject({
    id: 42,
    name: expect.any(String),
    email: expect.stringMatching(/^[^\s@]+@[^\s@]+\.[^\s@]+$/),
    role: expect.oneOf(["admin", "editor", "viewer"]),
  });
});

Pour les schémas de réponse plus complexes, utilisez la validation JSON Schema avec notre JSON Schema Validator pour définir la structure attendue une seule fois et tester tous vos endpoints en regard de celle-ci.

Tests de contrat

Dans les microservices, les tests de contrat garantissent que le consommateur et le fournisseur s'accordent sur la forme de l'API. Le consommateur définit ce dont il a besoin ; le fournisseur vérifie qu'il le satisfait. Des outils comme Pact automatisent ce processus.

C'est particulièrement utile lorsque des équipes différentes gèrent des services distincts — un test de contrat échoue immédiatement lorsqu'un champ est renommé ou supprimé, avant même l'intégration.

Tests de performance et de charge

Les tests fonctionnels vous indiquent si l'API fonctionne. Les tests de performance vous indiquent à quel point elle se comporte sous charge :

• Référence (Baseline) — Quels sont les temps de réponse p50/p95/p99 avec un seul utilisateur ?
• Test de charge (Load test) — Comment se comporte-t-elle au pic de trafic attendu ?
• Test de stress (Stress test) — À quel point commence-t-elle à défaillir ?
• Test de pic (Spike test) — Que se passe-t-il avec une augmentation soudaine du trafic de 10× ?

Un objectif courant : < 200ms pour le p95 au pic de charge attendu.

Checklist de test d'API

• Tester toutes les opérations CRUD pour chaque ressource
• Tester les cas négatifs : entrée invalide, authentification manquante, ressource introuvable
• Valider les corps de réponse par rapport à un schéma (et pas seulement les codes de statut)
• Tester les cas limites d'authentification : tokens expirés, manquants ou altérés
• Vérifier que les réponses d'erreur contiennent des messages utiles
• S'assurer que la pagination, le filtrage et le tri fonctionnent correctement
• Tester le comportement en cas de limitation de débit
• Vérifier qu'aucune donnée sensible ne fuite dans les réponses d'erreur
• Contrôler le temps de réponse sous la charge attendue

De bons tests d'API constituent votre filet de sécurité pour la refactorisation et la meilleure documentation possible — ils montrent exactement ce que fait chaque endpoint et ce qu'il attend.