TL;DRUn prestataire vient de vous envoyer une documentation d'API et une clé d'accès. Vous devez brancher un transporteur, un ERP ou un outil marketing sur votre boutique. Avant d'écrire du code, vous voulez savoir deux choses : est-ce que ça répond, et qu'est-ce que ça renvoie ?

Ce postman tutoriel répond à ce besoin précis. Vous allez envoyer votre première requête, lire une réponse JSON, gérer une clé API et organiser vos tests. Ensuite, vous verrez comment les automatiser.

Je l'écris avec mon expérience d'intégrateur PrestaShop et Symfony. J'ouvre Postman presque tous les jours pour vérifier une API avant de coder un connecteur.

C'est quoi Postman et à quoi ça sert ?#

Postman est un logiciel qui envoie des requêtes à une API et affiche ses réponses, sans écrire de code. Vous saisissez une adresse, vous choisissez une méthode, vous ajoutez si besoin des données, puis vous cliquez sur Send. Postman affiche le résultat, le code de statut et le temps de réponse.

Une API est une porte d'entrée qui permet à deux logiciels d'échanger des données. Votre boutique demande par exemple le statut d'un colis à l'API d'un transporteur.

Quatre termes reviennent sans arrêt :

  • Requête : le message que vous envoyez à l'API.
  • Réponse : ce que l'API vous renvoie, souvent au format JSON (un format texte structuré en paires clé et valeur).
  • Endpoint : l'adresse précise d'une ressource, par exemple /api/products.
  • Méthode : l'action demandée. GET lit, POST crée, PUT ou PATCH modifie, DELETE supprime.

Tester une API avec Postman, c'est voir à la main ce qu'elle renvoie et le comprendre avant de coder. C'est pour cela que le duo Postman et API est devenu un réflexe chez les intégrateurs.

Postman tutoriel : installer l'outil et créer son espace de travail#

Postman existe en application de bureau pour Windows, macOS et Linux, et en version web. Téléchargez-le depuis le site officiel, créez un compte, puis créez un espace de travail. C'est le dossier principal où vous rangerez vos requêtes, collections et environnements.

L'application de bureau est la plus pratique. Elle peut appeler des API locales, comme un site PrestaShop qui tourne sur votre machine. Pour faire la même chose, la version web demande un petit agent à installer.

Un espace de travail (workspace) regroupe tout ce qui concerne un projet. Je conseille d'en créer un par client ou par intégration. Vous évitez ainsi de mélanger les clés et les adresses.

Sans compte, l'application de bureau ouvre un client léger : vous envoyez des requêtes et gardez l'historique en local. Les collections, les environnements et les variables demandent en revanche un compte et un espace de travail. Pour suivre ce tutoriel jusqu'au bout, créez-en un.

Envoyer une première requête GET et lire la réponse JSON#

Pour une première requête GET, cliquez sur New puis HTTP Request, laissez la méthode GET, collez l'adresse de l'endpoint et cliquez sur Send. La réponse s'affiche en bas : le corps en JSON, le code de statut, le temps de réponse et les en-têtes renvoyés par le serveur.

Pour vous entraîner, utilisez une API publique de test comme JSONPlaceholder :

GET https://jsonplaceholder.typicode.com/users/1

La réponse ressemble à ceci :

{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "Sincere@april.biz",
  "address": {
    "city": "Gwenborough",
    "zipcode": "92998-3874"
  }
}

Regardez d'abord le code de statut, en haut à droite de la réponse. Les plus courants :

  • 200 : tout va bien.
  • 201 : la ressource a été créée.
  • 400 : la requête est mal formée.
  • 401 ou 403 : problème d'authentification ou de droits.
  • 404 : l'endpoint ou la ressource n'existe pas.
  • 500 : erreur côté serveur.

L'onglet Params sert à ajouter des paramètres de requête, c'est-à-dire des filtres placés après le ? dans l'URL. Par exemple _limit=5 pour limiter le nombre de résultats.

Requête POST : envoyer des données, en-têtes et corps de requête#

Une requête POST envoie des données à l'API pour créer une ressource. Dans Postman, choisissez POST, ouvrez l'onglet Body, sélectionnez raw puis JSON, et écrivez vos données. Postman ajoute alors l'en-tête Content-Type, qui indique au serveur le format des données envoyées.

Le corps de requête (body) contient les données envoyées. Les en-têtes (headers) sont des informations techniques qui accompagnent la requête : format, langue, authentification.

POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json
{
  "title": "Test depuis Postman",
  "body": "Ma première requête POST",
  "userId": 1
}

Réponse attendue, avec un code 201 :

{
  "title": "Test depuis Postman",
  "body": "Ma première requête POST",
  "userId": 1,
  "id": 101
}

JSONPlaceholder simule la création sans rien enregistrer. C'est parfait pour s'entraîner sans risque.

Si vous développez votre propre API, la logique est la même. J'en parle dans API Platform ou contrôleur classique en Symfony.

Authentification : clé API, Bearer token et Basic Auth#

La plupart des API demandent une preuve d'identité. Dans Postman, l'onglet Authorization gère les cas courants : clé API dans un en-tête ou dans l'URL, Bearer token pour les jetons temporaires, Basic Auth pour un identifiant et un mot de passe. Choisissez le type indiqué dans la documentation.

Clé API : une chaîne secrète fournie par le service. Elle passe souvent dans un en-tête :

GET {{base_url}}/v1/ressource
X-API-Key: {{api_key}}

Bearer token : un jeton, souvent temporaire, obtenu après une première requête de connexion. Il passe dans l'en-tête Authorization :

GET {{base_url}}/v1/ressource
Authorization: Bearer {{token}}

Basic Auth : un identifiant et un mot de passe encodés automatiquement par Postman. PrestaShop utilise ce mode.

Beaucoup d'API françaises fonctionnent ainsi. Vous le verrez dans mes comparatifs des API SIRET et données légales et des API d'adresse et de géolocalisation.

Une règle simple : n'écrivez jamais une clé en dur dans une requête partagée. Utilisez des variables, comme dans la section suivante.

Postman collection et variables d'environnement : passer du test à la production#

Une collection est un dossier de requêtes enregistrées, rangées par thème. Un environnement est un jeu de variables, comme l'URL de base ou la clé API, propre à un contexte : local, préproduction, production. Vous changez d'environnement en un clic sans réécrire vos requêtes.

Une variable est un nom qui remplace une valeur. Dans Postman, on l'écrit entre doubles accolades :

GET {{base_url}}/api/products

Créez ensuite un environnement par contexte :

VariableLocalPréproductionProduction
base_urlhttp://localhost:8080https://preprod.exemple.comhttps://www.exemple.com
api_keyCLE_LOCALECLE_PREPRODCLE_PROD

Postman distingue la valeur initiale, partagée avec l'équipe, et la valeur courante, qui reste sur votre poste. Gardez les vraies clés dans la valeur courante.

Vous pouvez aussi récupérer un token et l'enregistrer automatiquement. Ce script se place dans l'onglet Scripts de la requête de connexion :

const data = pm.response.json();
pm.environment.set("token", data.access_token);

Toutes les requêtes suivantes utilisent {{token}} sans copier-coller.

Mon retour d'expérience Sur notre intégration de l'API de facturation électronique B2Brouter, le piège venait du croisement entre clé et environnement. Une clé de production utilisée sur l'URL de test, ou l'inverse, échouait sans message clair. La solution : une configuration clé et URL strictement séparée par environnement. Le détail est dans l'étude de cas facturation électronique.

Exemple concret : tester l'API PrestaShop avec Postman#

Pour tester l'API PrestaShop, activez le webservice dans le back-office, créez une clé avec des droits limités, puis appelez /api/products en Basic Auth. La clé sert d'identifiant et le mot de passe reste vide. Ajoutez output_format=JSON pour obtenir du JSON au lieu du XML.

Côté back-office, ouvrez Paramètres avancés > Webservice. Activez le service, générez une clé et cochez uniquement les droits utiles. Pour un test, GET sur products et orders suffit.

Dans Postman, onglet Authorization, choisissez Basic Auth :

  • Username : {{ps_key}}
  • Password : vide

Puis la requête :

GET {{ps_url}}/api/products?output_format=JSON

Réponse type, qui liste les identifiants :

{
  "products": [
    { "id": 1 },
    { "id": 2 },
    { "id": 3 }
  ]
}

Pour avoir plus de champs, ajoutez display. Pour les commandes, combinez filtre, tri et limite :

GET {{ps_url}}/api/products?output_format=JSON&display=[id,reference,price]&limit=5
GET {{ps_url}}/api/orders?output_format=JSON&display=[id,reference,total_paid,current_state]&sort=[id_DESC]&limit=10

Trois pièges que je rencontre souvent :

  • Erreur 401 malgré une bonne clé : certains hébergements suppriment l'en-tête Authorization. Il faut alors ajuster la configuration du serveur.
  • Clé dans l'URL : le paramètre ws_key fonctionne, mais la clé finit dans les logs. Préférez Basic Auth.
  • Droits trop larges : une clé de test n'a jamais besoin de DELETE en production.

Tous les détails sont dans mon guide comment utiliser l'API de PrestaShop.

Mon retour d'expérience Pour un distributeur Kaspersky, nous avons relié une boutique PrestaShop à l'API 2Checkout, protégée par Bearer token et par une liste blanche d'adresses IP. Avant le moindre appel de test, il a fallu obtenir un identifiant partenaire et faire autoriser notre IP de développement. Ensuite, chaque déclinaison produit devait correspondre à la bonne référence côté API. Voir l'étude de cas Kaspersky.

Automatiser : tests, exécution de collection et partage avec l'équipe#

Postman peut vérifier automatiquement chaque réponse grâce à de petits scripts de test en JavaScript. Vous lancez ensuite toute une collection d'un coup avec le Collection Runner, ou en ligne de commande dans un pipeline. Votre série de clics devient un contrôle qui tourne à chaque mise en ligne.

Dans l'onglet Scripts, partie post-réponse, ajoutez vos vérifications :

pm.test("Statut 200", function () {
  pm.response.to.have.status(200);
});

pm.test("La réponse contient des produits", function () {
  const data = pm.response.json();
  pm.expect(data.products).to.be.an("array").that.is.not.empty;
});

pm.test("Réponse en moins d'une seconde", function () {
  pm.expect(pm.response.responseTime).to.be.below(1000);
});

Le Collection Runner exécute toutes les requêtes d'une collection dans l'ordre et affiche les tests réussis ou échoués. Sur les offres payantes, il accepte aussi un fichier de données CSV pour rejouer les tests avec plusieurs jeux de valeurs.

Pour l'intégration continue, c'est-à-dire les tests lancés automatiquement à chaque déploiement, utilisez Newman ou Postman CLI :

newman run ma-collection.json -e preprod.json

Pour partager, invitez vos collègues dans un espace d'équipe, ce qui demande une offre payante, ou exportez la collection en JSON.

Mon retour d'expérience Pour Diyeva, service de secrétariat téléphonique par IA, nous avons reconstruit en Symfony les échanges avec l'API d'agenda d'un centre ophtalmologique. Une collection Postman couvre tout le cycle : token, recherche d'agenda, disponibilités, prise et annulation de rendez-vous. Le taux de réussite des prises de rendez-vous est passé de moins de 40 % à plus de 90 %. Voir l'étude de cas Diyeva.

Postman gratuit : limites de l'offre et moment où il faut payer#

Oui, Postman a une offre gratuite, mais elle est réservée à un seul utilisateur. Elle couvre les requêtes, les collections, les environnements, les tests et le Collection Runner sans limite d'exécutions. Dès que vous voulez travailler à plusieurs dans le même espace, il faut passer à l'offre Team.

Ce que dit la page des tarifs de Postman, relevée en octobre 2026 :

  • Utilisateurs : un seul sur l'offre gratuite.
  • Collection Runner : exécutions illimitées.
  • Monitoring (collections lancées à intervalle régulier depuis le cloud) : 1 000 requêtes par mois, contre 10 000 sur les offres payantes.
  • Non inclus : fichiers de données dans le Collection Runner, export des résultats de tests, rapports de monitoring et webhooks.
  • IA : un volume réduit de crédits mensuels, sans possibilité d'en racheter.

Côté prix, l'offre Solo coûte 9 $ par mois et l'offre Team 19 $ par utilisateur et par mois, en facturation annuelle. L'offre Enterprise est sur devis. Ces tarifs bougent souvent, vérifiez-les avant de vous engager.

Autre point : Postman synchronise vos données dans son cloud. Pour des clés de production ou des données clients, vérifiez que c'est compatible avec votre politique de sécurité et le RGPD.

Quelle alternative à Postman choisir ?#

Les principales alternatives à Postman sont Bruno, Insomnia, Hoppscotch, Thunder Client et les outils en ligne de commande comme curl ou HTTPie. Choisissez-en une si vous voulez travailler hors ligne, versionner vos requêtes dans Git, rester dans votre éditeur de code ou éviter le stockage dans un cloud.

OutilPoints fortsQuand le choisir
BrunoOpen source, hors ligne, requêtes stockées en fichiersVous voulez versionner vos tests dans Git avec le code
InsomniaInterface proche de PostmanVous voulez une alternative directe
HoppscotchWeb, open source, auto-hébergeableVous voulez un outil léger dans le navigateur
Thunder ClientExtension VS CodeVous ne voulez pas quitter votre éditeur
curl, HTTPieLigne de commandeScripts rapides, serveurs sans interface
Client HTTP de PhpStormFichiers .http dans le projetVous travaillez déjà dans PhpStorm sur du Symfony

Vérifiez la licence et les conditions de chaque outil avant de l'imposer à votre équipe, elles évoluent régulièrement.

FAQ#

Postman est-il gratuit ?#

Oui, pour un seul utilisateur. Elle couvre les requêtes, collections, environnements, tests et le Collection Runner. Le travail en équipe demande l'offre Team, à 19 $ par utilisateur et par mois en facturation annuelle (tarif relevé en octobre 2026).

Peut-on utiliser Postman sans compte ?#

Oui, mais en mode limité. L'application de bureau permet d'envoyer des requêtes et de garder l'historique en local, sans collections, environnements ni variables. Si vous voulez tout cela sans compte ni cloud, regardez Bruno.

Quelle est la différence entre une collection et un environnement ?#

La collection contient vos requêtes. L'environnement contient les valeurs qui changent selon le contexte, comme l'URL ou la clé. La même collection fonctionne en local, en préproduction et en production.

Comment tester l'API PrestaShop avec Postman ?#

Activez le webservice, créez une clé avec des droits limités, puis appelez /api/products?output_format=JSON en Basic Auth. La clé sert d'identifiant et le mot de passe reste vide.

Comment sécuriser ses clés API dans Postman ?#

Stockez-les dans des variables d'environnement, en valeur courante uniquement. Ne publiez jamais un espace de travail qui contient des clés, et utilisez des clés de test aux droits limités.

Postman remplace-t-il les tests automatisés dans le code ?#

Non, il les complète. Postman sert à tester une API de l'extérieur, comme le ferait un client. Les tests unitaires et fonctionnels de votre application restent indispensables.

Passer de Postman à une intégration fiable#

Vous savez maintenant envoyer une requête GET et POST, gérer une clé API ou un token, organiser vos collections et environnements, puis automatiser vos vérifications. Ce postman tutoriel couvre l'essentiel pour tester une API sans écrire de code.

Valider une API dans Postman, c'est la première étape. Construire un connecteur fiable entre PrestaShop, Shopify, Symfony et vos outils métier, c'est un autre chantier : gestion des erreurs, reprises, journalisation, sécurité.

Vous avez une intégration d'API ou un connecteur à mettre en place ? Réservez un échange de 45 minutes et on regarde ensemble votre projet.