Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Postman: le guide pour tester une API REST et automatiser ses requêtes

Date de l'article:15-09-2025
Postman Newman
Découvrez comment utiliser Postman pour automatiser vos tests API, chaîner vos requêtes et simuler des scénarios réalistes avec authentification
Introduction : Qu'est-ce que Postman ?

Tester une API sans interface graphique peut vite devenir complexe.
C'est là qu'intervient Postman, l'outil incontournable pour tous les développeurs backend, QA et DevOps

Postman permet de tester, documenter et automatiser des API REST sans écrire de code complexe. Il agit comme un client HTTP avancé capable de simuler des requêtes et d'analyser précisément les réponses du serveur.

Dans cette page, on va voir comment :
  • Créer et exécuter des requêtes HTTP (GET, POST, etc.)
  • Gérer l'authentification et les headers
  • Automatiser vos tests API
  • Intégrer Postman dans un pipeline CI/CD
L'interface de Postman
L'interface de Postman est pensée pour maximiser la productivité.
Elle se compose de plusieurs zones clés:
  • Request Builder : création et envoi des requêtes HTTP
  • Params / Headers / Body / Tests : configuration avancée de la requête
  • Response Viewer : analyse détaillée de la réponse
  • Collections : organisation des requêtes en scénarios réutilisables
  • Environments : gestion des variables (URL de base, tokens, etc.)

Une bonne maîtrise de ces éléments permet de transformer Postman
      en véritable plateforme de test API

Liens utiles: Communauté Postman           Documentation officielle
JSONPlaceholder                    Collection d'exemples publique
Request Builder (Constructeur de requête)
Les types de requêtes :

Chaque appel API repose sur une méthode HTTP.

Les types de requêtes:
  • GET : récupérer des données
  • POST : créer une ressource
  • PUT / PATCH : modifier une ressource
  • DELETE : supprimer une ressource

Postman permet de tester ces comportements sans frontend
      ce qui accélère considérablement le développement.

GET : récupérer une liste de posts
  1. New → HTTP Request (ou + New Tab)
  2. Méthode : GET
  3. URL : https://jsonplaceholder.typicode.com/posts
  4. Cliquez "Send"

Résultat attendu : Statut 200 OK, 100 posts JSON, temps de réponse affiché.

GET un post spécifique
  1. URL : https://jsonplaceholder.typicode.com/posts/1
  2. Send → Un seul objet JSON avec id: 1
Requêtes POST / PUT / PATCH / DELETE
POST : créer un post
1. Méthode : POST
2. URL : https://jsonplaceholder.typicode.com/posts
3. Body → raw → JSON : 
{
  "title": "Mon premier post Postman",
  "body": "Ceci est un test automatisé",
  "userId": 1
}
4. Send → 201 Created + ID : 101
PUT vs PATCH
PUT /posts/1
→ Remplace tout l'objet
PATCH /posts/1
→ Modifie un seul champ

DELETE : supprimer
  1. Méthode : DELETE
  2. URL : https://jsonplaceholder.typicode.com/posts/1
  3. Send → 200 OK (corps de réponse vide)
Headers, Params et Authentification
Les en-têtes (Headers)
Configurées dans l'onglet "Headers". Elles transmettent des métadonnées au serveur.
Headers essentiels :
  • Content-Type: application/json
  • Authorization: Bearer {{token}}
  • Accept: application/json
Les paramètres (Params)

Configurés dans l'onglet "Params"

Ils sont ajoutés automatiquement à l'URL sous forme de "query string"

Exemple: /posts?userId=1&_limit=5
L'authentification
Onglet " Authorization"
Bearer Token:
standard
Basic Auth:
par login / mot de passe
API Key:
clé d'accès transmise via header ou paramètre

Bonne pratique : Ne stockez jamais vos tokens en dur dans les requêtes. Utilisez des variables d'environnement.

Utiliser les variables et environnements
Les variables permettent d'éviter de répéter des informations (ex : URL de base, token d'authentification)
Exemple : Créez un environnement "Development" :
  1. Cliquez sur le sélecteur d'environnement en haut à droite → Gérer les environnements
  2. Cliquez sur "Ajouter" pour créer un nouvel environnement. Donnez-lui un nom genre: "Development"
  3. Ajoutez des variables clé-valeur, par exemple : base_url = https://localhost:8080/api
  4. Dans vos requêtes, utilisez la syntaxe : {{base_url}}/user-list
  5. Sélectionnez l'environnement souhaité avant d'envoyer la requête
En créant ainsi plusieurs environements, vous pouvez passer facilement passer de l'un a l'autre en 1 click
Collections: Organisez vos tests

Les collections regroupent les requêtes en scénarios cohérents.

Exemple de création (collection):
  1. New → Collection → "Placeholder CRUD"
  2. Après chaque requête → Save to Collection
  3. ⋯ → Run collection
Elles permettent de:
  • Structurer et organiser vos tests API
  • Exécuter toutes les requêtes en série
  • Partager facilement avec l'équipe
  • Exporter au format JSON / Newman
Exemple de scénario utilisateur:
  1. GET /posts : Lister des posts
  2. POST /posts : Créer un post
  3. GET /posts/101: Vérifier la création
  4. DELETE /posts/101: Nettoyage
Exemple de scénario

Tester une API ne consiste pas seulement à envoyer des requêtes isolées, mais à reproduire un parcours utilisateur complet.

Imaginez que vous testez une API de gestion d'utilisateurs:
  • Récupérer la liste des utilisateurs (GET /users)
  • Créer un nouvel utilisateur (POST /users)
  • Vérifier le statut de la réponse (201 Created)
  • Contrôler les données retournées (id, email, rôle)
Déroulement typique:
  • Étape 1 : vérifier que la liste des utilisateurs s'affiche correctement.
  • Étape 2 : envoyer un JSON avec les champs name, email et role.
  • Étape 3 : contrôler que la réponse retourne le statut 201 Created.
  • Étape 4 : vérifier que l'identifiant généré est bien présent dans la réponse.
Ce type de tests permet de valider un parcours complet, comme le ferait un utilisateur réel ou une application cliente.
Automatiser les tests
Le chaînage dynamique : relier deux requêtes entre elles

Le chaînage dynamique permet de transmettre automatiquement des données d'une requête à une autre.
Ce mécanisme est très utilisé pour automatiser des scénarios réalistes : authentification, récupération de données sécurisées, création de ressources, etc.

Objectif :
Relier deux requêtes grâce aux variables Postman :
Requête A → récupération d'un token
Requête B → réutilisation automatique du token
Étape 1 - Requête A: Authentification
Méthode : POST - URL :https://dummyjson.com/auth/login
Body JSON : 
{
  "username": "emilys",
  "password": "emilyspass"
}
Résultat attendu :
Statut : 200 OK
Retourne un token JWT
Étape 2 - Onglet "Tests" de la Requête A
Après l'exécution de la Requête A, Postman exécute automatiquement le script "Tests". Ce script permet de :
  • Récupérer le token retourné par l'API
  • Le sauvegarder dans une variable d'environnement
  • Le rendre disponible pour les requêtes suivantes
const response = pm.response.json();

// récupération du token JWT
const token = response.accessToken;

// sauvegarde dans une variable Postman
pm.environment.set("active_token", token);

console.log("JWT saved:", token);
Étape 3 - Requête B : Requête sécurisée
Cette seconde requête nécessite le token JWT récupéré précédemment.
Méthode : GET -URL : https://dummyjson.com/auth/me
Header : Authorization: {{header_auth}}
Processus
La Requête A récupère un token JWT depuis l'API
Le script "Tests" sauvegarde ce token dans une variable Postman
Avant l'envoi de la Requête B, le script "Pre-request"
      récupère automatiquement ce token
Le header Authorization est construit dynamiquement
Les deux requêtes sont maintenant reliées entre elles
Étape 4 - Script "Pre-request" de la Requête B
Avant l'envoi HTTP de la Requête B,
Postman exécute automatiquement le script "Pre-request".

Ce script récupère le token sauvegardé par la Requête A afin de construire dynamiquement le header Authorization.

// récupération du token sauvegardé
const token = pm.environment.get("active_token");

// construction du header Authorization
pm.variables.set(
    "header_auth",
    "Bearer " + token
);
Exécuter une collection complète (Runner / Newman)
Pour exécuter une collection complète, Postman propose deux méthodes:
Le "Collection Runner" intégré à l'interface, et "Newman" pour la ligne de commande et l'intégration continue
Méthode 1 : Collection Runner (interface Postman)
1. Cliquez sur ᴼ ᴼ ᴼ à côté de votre collection → "Run collection"
2. Configurez l'exécution :
  • Le nombre d'itérations et le délai entre les requêtes
  • L'environnement à utiliser et l'ordre des requêtes si nécessaire
3. Lancez l'exécution:
Les tests s'enchaînent en série avec des statistiques globales.
Le Runner affiche le statut de chaque requête : OK ou KO
Méthode 2 : Newman (ligne de commande)
1. Installez Newman globalement via npm : 
npm install -g newman
2. Exportez votre collection au format "JSON"
3. Dans le terminal, naviguez jusqu'au dossier contenant le fichier
4. Exécutez la commande : 
newman run nom_de_la_collection.json
Postman / Newman en CI/CD

Postman s'intègre très bien dans les pipelines CI/CD grâce à Newman.
Il suffit d'ajouter dans votre pipeline:

  • Une étape pour installer Node.js
  • Une étape pour installer Newman
  • Une étape pour lancer les tests API et générer un rapport

Newman supporte nativement Jenkins, GitLab CI et GitHub Actions.

Exemple avec GitHub Actions: 
- name: Run API Tests
  run: |
    newman run postman/flashcards.postman_collection.json \
      -e postman/local.postman_environment.json \
      --reporters cli,junit \
      --reporter-junit-export newman-functional.xml
en Bonus
Importer de: OpenAPI/Swagger / Exporter (en collections)
L'Import est la vraie fonctionnalité puissante
Si votre API est documentée au format OpenAPI (.yaml/.json),
      Postman génère automatiquement toutes les requêtes
C'est un gain de temps énorme sur des APIs avec beaucoup d'endpoints
Process:
File → Import : Choisissez votre source ou glissez le fichier directement
Postman affiche les détails du fichier detecté. Cliquez sur "Importer":
Une nouvelle Collection portant le nom de l'API apparaît dans l'espace de travail
Exporter une Collection Postman

L'export génère un fichier JSON standardisé

Que nous pouvons ensuite;
Partager avec un collègue, ou notre équipe,
Versionner dans Git,
ou, l'utiliser avec "Newman" dans la CI
Mock Server
Grâce aux Mock Servers, Postman permet de simuler une API qui se comporte comme un faux serveur. Vous définissez vous-même quelle requête il accepte et quelle réponse il retourne.
  • Permet au frontend de travailler en parallèle du backend
  • Utile pour tester des scénarios avant que le backend ne soit développé
Comment le créer (étape par étape):
  1. Cliquez sur File > New → Mock Server
  2. Choisir la méthode (GET, POST..)
  3. Entrez le chemin "/users", le code de réponse "200 "
    et le body JSON que l'ont veut retourner
  4. Donnez un nom au Mock Server → "Create Mock Server"
  5. Postman génère une Mock URL: copiez-la
Depuis le frontend:
  • Utiliser l'URL fournie comme si c'était la vraie API
  • Quand le backend sera prêt, vous n'aurez qu'à remplacer l'URL de base
Vous pouvez également simuler du délai (Network Delay):
Onglet "Mock Servers" > Sélectionnez le serveur et ouvrez ses options,
Ajouter un délai artificiel (par ex: 2000 ms) pour simuler une connexion lente
Debug et résolution des problèmes courants

Lors du test d'une API, les erreurs sont inévitables. Voici comment les diagnostiquer rapidement :

Codes de statut ≠ 200 - cas fréquents :
400 Bad Request données invalides dans le Body
401 Unauthorized problème d'authentification
403 Forbidden accès refusé (droits insuffisants)
404 Not Found endpoint incorrect ou ressource inexistante
500 Internal Server Error erreur côté serveur
Réflexes de debug
  1. Utilisez la console: View → Show Console
  2. Vérifiez: URL, Headers, Body
  3. Lire message d'erreur dans Response
  4. Utilisez console.log(pm.response.json()) dans "Tests"
Problème d'authentification
Symptômes :
401 Unauthorized
403 Forbidden
Utilisez une variable d'environnement pour stocker le token
Vérifiez :
Si le token a expiré
Le header Authorization
La méthode (Bearer vs Basic)
Body mal formaté
Erreurs classiques : JSON invalide mauvais Content-Type
Vérifiez l'id de la ressource et le header Content-Type
Utilisez le mode "raw + JSON" pour éviter les erreurs de formatage
Problème réseau / serveur
Cas fréquents : Serveur non démarré Mauvais port Erreur DNS
Toujours utiliser des variables d'environnement pour :
      {{base_url}} {{token}} {{api_key}}

Vérifiez les ports, l'url, que le backend est bien démarré et accessible (health).. 
http://localhost:8080/actuator/health
Temps de réponse élevé
Postman affiche le temps de réponse dans la barre de résultat.
→   Utile pour détecter des problèmes de performance.
Analysez la base de données (requêtes lentes)
Vérifiez les appels à des services externes
Ajoutez des logs côté backend pour identifier le goulot
Utiliser la console Postman

Accessible via :
     Menu : View → Show Postman Console

Elle permet de visualiser :
Les requêtes envoyées et leurs détails
Les headers complets (envoyés et reçus)
Les logs issus de console.log() dans vos scripts
Debug avec les scripts de test
Ajoutez des logs dans vos onglets Tests ou Pre-request : 
console.log(pm.response.json());
Très utile pour inspecter des réponses JSON complexes ou imbriquées.
Approche recommandée
1. Vérifier la requête (URL, headers, body)
2. Analyser le code HTTP retourné
3. Lire le corps de la réponse serveur
4. Utiliser les logs (console Postman + logs backend)
Conclusion

Que vous soyez développeur backend, testeur QA ou DevOps, maîtriser Postman est un vrai atout dans votre workflow quotidien.
Et personnellement, j'en apprends encore sur Postman

Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.