Postman Runner : Variable non persistante - Causes et solutions

TL;DR

Les variables définies lors de l'exécution manuelle d'une requête peuvent disparaître lorsque vous lancez la même collection dans le Collection Runner de Postman. La cause la plus fréquente est une incompatibilité de portée : pm.environment.set écrit dans l’environnement actif, tandis que le runner peut réinitialiser ces valeurs ou s’exécuter sans environnement sélectionné. La correction consiste à choisir la bonne portée (environment, collection, global), à configurer correctement le runner et à journaliser les variables pour vérifier ce qui est réellement lu.

Essayez Apidog aujourd’hui

Introduction

Vous testez une API manuellement dans Postman. Une requête de connexion récupère un jeton, un script le stocke, puis les requêtes suivantes utilisent ce jeton. Tout fonctionne.

Puis vous lancez la même collection avec Run Collection. La requête de connexion réussit, mais la suivante échoue avec un 401 Unauthorized. Le jeton semble absent.

Ce comportement vient rarement de l’API. Il vient le plus souvent de la portée des variables et de la manière dont le Collection Runner initialise, modifie puis réinitialise l’état des variables.

Voici comment diagnostiquer et corriger le problème.

Comprendre la hiérarchie des variables Postman

Postman résout une variable comme {{token}} selon cet ordre de priorité :

1. Variables locales : disponibles uniquement pendant l’exécution du script courant.
2. Variables de données : chargées depuis un fichier CSV ou JSON dans une exécution data-driven.
3. Variables de collection : disponibles dans toute la collection.
4. Variables d’environnement : disponibles dans l’environnement sélectionné.
5. Variables globales : disponibles dans toutes les collections et tous les environnements.

Si plusieurs portées contiennent une variable nommée token, Postman utilise celle qui a la priorité la plus élevée.

Exemple :

console.log(pm.variables.get('token'));

pm.variables.get() applique la résolution automatique. Pour éviter les ambiguïtés pendant le debug, lisez explicitement chaque portée :

console.log('collection token:', pm.collectionVariables.get('token'));
console.log('environment token:', pm.environment.get('token'));
console.log('global token:', pm.globals.get('token'));

Pourquoi les variables disparaissent dans le Collection Runner

1. Valeur initiale vs valeur actuelle

Chaque variable Postman possède deux champs :

• Valeur initiale : synchronisée et partageable.
• Valeur actuelle : locale à votre machine.

Quand vous exécutez ce script :

pm.environment.set('token', pm.response.json().access_token);

Postman met à jour la valeur actuelle de la variable token dans l’environnement actif.

En exécution manuelle, cette valeur reste disponible pendant votre session. Dans le Collection Runner, l’environnement est chargé au début de l’exécution, puis peut être restauré à la fin selon la configuration du runner.

2. pm.environment.set nécessite un environnement actif

Ce code écrit dans l’environnement sélectionné :

pm.environment.set('token', 'abc123');

Si aucun environnement n’est sélectionné dans le runner, il n’y a pas de cible claire pour l’écriture. Le résultat est souvent interprété comme une “variable perdue”.

Avant d’utiliser pm.environment.set, vérifiez donc qu’un environnement est bien sélectionné.

3. Le runner peut réinitialiser les variables après l’exécution

Dans le Collection Runner, l’option Keep variable values / Conserver les valeurs des variables détermine si les modifications faites pendant l’exécution sont conservées après la fin du run.

Si cette option est décochée, les variables modifiées pendant l’exécution peuvent être réinitialisées.

Important : les variables définies pendant une exécution restent disponibles pour les requêtes suivantes de cette même exécution. Le problème concerne surtout leur persistance après la fin du runner ou leur état initial au lancement suivant.

Solution 1 : activer “Conserver les valeurs des variables”

Utilisez cette option si vous voulez que les variables mises à jour par le runner soient conservées après l’exécution.

Étapes :

1. Ouvrez le Collection Runner.
2. Sélectionnez votre collection.
3. Sélectionnez l’environnement requis.
4. Cochez Keep variable values / Conserver les valeurs des variables.
5. Lancez l’exécution.

À utiliser pour :

• conserver un jeton après le run ;
• réutiliser une variable dans une exécution suivante ;
• mettre à jour l’état d’un environnement depuis le runner.

À éviter si :

• vous lancez plusieurs itérations indépendantes ;
• une variable de l’itération 1 ne doit pas polluer l’itération 2 ;
• vous voulez un environnement propre à chaque run.

Dans ce cas, réinitialisez explicitement les variables au début de chaque itération ou utilisez des fichiers de données.

Solution 2 : utiliser des variables de collection pour l’état interne au run

Si une variable sert uniquement à chaîner les requêtes d’une même collection, utilisez une variable de collection.

Exemple : dans la requête de connexion, ajoutez ce script post-réponse :

const body = pm.response.json();

pm.collectionVariables.set('token', body.access_token);

Dans les requêtes suivantes, utilisez le jeton dans l’onglet Authorization ou dans les headers :

Authorization: Bearer {{token}}

Ou lisez-le explicitement dans un script de pré-requête :

const token = pm.collectionVariables.get('token');

console.log('token utilisé:', token);

Avantage : les variables de collection sont disponibles dans le runner même si aucun environnement n’est sélectionné. Elles sont adaptées aux valeurs produites et consommées dans une seule collection.

Solution 3 : sélectionner un environnement avant le run

Si vous utilisez pm.environment.set, sélectionnez toujours un environnement dans le runner.

Checklist rapide :

• Un environnement est-il sélectionné dans le menu du runner ?
• La variable existe-t-elle dans cet environnement ?
• La variable est-elle définie en valeur initiale si elle doit exister dès le départ ?
• L’option Conserver les valeurs des variables est-elle nécessaire pour votre cas ?

Exemple défensif dans un script :

if (!pm.environment.name) {
  console.warn('Aucun environnement actif. Utilisez pm.collectionVariables.set à la place.');
}

pm.environment.set('token', pm.response.json().access_token);

Solution 4 : définir les valeurs initiales pour les variables requises au démarrage

Si une variable comme baseUrl doit être disponible dès la première requête, ne définissez pas uniquement sa valeur actuelle.

Dans l’éditeur d’environnement :

1. Ouvrez votre environnement.
2. Ajoutez baseUrl.
3. Remplissez Initial value.
4. Remplissez aussi Current value si nécessaire.
5. Sauvegardez.

Exemple :

Variable	Initial value	Current value
baseUrl	https://api.example.com	https://api.example.com
token	vide ou valeur de test	valeur locale générée

Si seule la valeur actuelle est définie, un coéquipier, Newman ou un runner exécuté avec un environnement exporté peut démarrer avec une variable vide.

Solution 5 : journaliser chaque portée pendant le debug

Ajoutez des logs dans les scripts de pré-requête et post-réponse.

Script de pré-requête :

console.log('--- Pré-requête ---');
console.log('collection token:', pm.collectionVariables.get('token'));
console.log('environment token:', pm.environment.get('token'));
console.log('resolved token:', pm.variables.get('token'));

Script post-réponse de la requête de connexion :

const body = pm.response.json();

console.log('access_token reçu:', body.access_token);

pm.collectionVariables.set('token', body.access_token);

console.log('token stocké en collection:', pm.collectionVariables.get('token'));

Puis ouvrez la console Postman :

View > Show Postman Console

Vous pourrez vérifier :

• si le token est bien reçu ;
• dans quelle portée il est écrit ;
• quelle valeur est réellement résolue par {{token}} ;
• si une variable d’une autre portée écrase celle attendue.

Exemple complet : chaîner une connexion et une requête protégée

Requête 1 : POST /login

Script post-réponse :

pm.test('Login réussi', function () {
  pm.response.to.have.status(200);
});

const json = pm.response.json();

pm.test('access_token présent', function () {
  pm.expect(json.access_token).to.exist;
});

pm.collectionVariables.set('token', json.access_token);

console.log('Token sauvegardé:', pm.collectionVariables.get('token'));

Requête 2 : GET /me

Header :

Authorization: Bearer {{token}}

Script de pré-requête :

const token = pm.collectionVariables.get('token');

if (!token) {
  throw new Error('Token manquant. Vérifiez que la requête /login est exécutée avant /me.');
}

Avec cette approche, le runner n’a pas besoin d’un environnement pour transmettre le token entre les deux requêtes.

Cas Newman

Newman suit le même modèle de portée.

Si vous exécutez une collection avec un environnement exporté :

newman run collection.json -e environment.json

Les modifications faites pendant l’exécution ne sont pas automatiquement persistées dans environment.json.

Pour écrire l’état final de l’environnement, utilisez :

newman run collection.json \
  -e environment.json \
  --export-environment environment.updated.json

Vous pouvez ensuite réutiliser le fichier mis à jour :

newman run collection.json -e environment.updated.json

C’est utile dans un pipeline CI où une première exécution génère un jeton ou une variable utilisée par une étape suivante.

Comment Apidog gère la portée des variables

Apidog utilise une hiérarchie de portée similaire : globale, environnement, collection et locale.

La différence principale se situe dans l’interface et la visibilité de l’état des variables. Les valeurs initiales et actuelles sont affichées clairement, ce qui limite les erreurs de configuration. Lorsqu’un script compatible Postman exécute :

pm.environment.set('token', value);

Apidog affiche la mise à jour dans le panneau des variables, ce qui permet de voir rapidement si la variable a bien été écrite.

Apidog prend aussi en charge les API de scripting Postman courantes, notamment :

pm.collectionVariables.set('token', value);
pm.collectionVariables.get('token');

pm.environment.set('token', value);
pm.environment.get('token');

Pour les collections migrées depuis Postman, vous pouvez donc conserver la même logique de scripts tout en vérifiant plus facilement la portée utilisée.

Résumé des erreurs courantes

Erreur	Symptôme	Correction
Aucun environnement sélectionné	pm.environment.set ne produit pas le résultat attendu	Sélectionnez un environnement ou utilisez pm.collectionVariables.set
Seule la valeur actuelle est définie	Variable absente en CI ou chez un coéquipier	Définissez aussi la valeur initiale
“Conserver les valeurs des variables” décoché	Variables réinitialisées après le runner	Cochez l’option dans la configuration du runner
Variable d’environnement utilisée pour un état interne à la collection	Fonctionne en manuel, échoue ou devient instable dans le runner	Utilisez des variables de collection
Même nom de variable dans plusieurs portées	Mauvaise valeur utilisée	Loggez chaque portée et vérifiez la priorité
Token généré après la requête qui l’utilise	Erreur 401	Réordonnez les requêtes dans la collection

FAQ

Pourquoi pm.environment.set fonctionne-t-il en manuel mais pas dans le runner ?

En manuel, vous travaillez dans une session d’environnement persistante. Dans le runner, l’environnement est chargé au début de l’exécution et peut être restauré à la fin. Les variables définies pendant le run sont disponibles pour les requêtes suivantes de ce run, mais elles ne persistent pas forcément après l’exécution.

Quelle est la différence entre pm.environment.set et pm.collectionVariables.set ?

pm.environment.set écrit dans l’environnement actif. C’est utile pour les valeurs partagées entre plusieurs collections utilisant le même environnement.

pm.collectionVariables.set écrit dans la collection. C’est plus adapté aux valeurs utilisées uniquement par les requêtes de cette collection, comme un token généré au début d’un scénario de test.

Ce problème existe-t-il avec Newman ?

Oui. Newman utilise le même modèle de portée. Par défaut, il démarre avec l’environnement fourni et ne réécrit pas automatiquement le fichier d’environnement après l’exécution. Utilisez --export-environment pour sauvegarder l’état final.

Que fait --export-environment dans Newman ?

Cette option écrit l’état final de l’environnement dans un fichier JSON après l’exécution :

newman run collection.json \
  -e environment.json \
  --export-environment environment.updated.json

Le fichier exporté contient les variables modifiées pendant le run.

Apidog prend-il en charge pm.collectionVariables.set ?

Oui. Apidog prend en charge les méthodes de scripting Postman comme :

pm.collectionVariables.set();
pm.collectionVariables.get();
pm.environment.set();
pm.environment.get();

Les collections migrées depuis Postman peuvent donc conserver la même syntaxe.

Comment transmettre une variable d’une collection à une autre dans Postman ?

Utilisez une variable globale :

pm.globals.set('token', value);

Mais utilisez cette approche avec prudence. Les variables globales ne sont pas limitées à une collection ou à un environnement, ce qui peut créer des conflits de noms. Si possible, préférez une variable d’environnement partagée.

Conclusion

Quand une collection fonctionne en manuel mais échoue dans le runner, vérifiez d’abord la portée des variables.

Les trois corrections les plus efficaces sont :

1. utiliser pm.collectionVariables.set pour les valeurs internes à une collection ;
2. sélectionner un environnement avant d’utiliser pm.environment.set ;
3. activer Conserver les valeurs des variables si vous voulez persister les modifications après le run.

Avec ces règles, vos tests deviennent plus reproductibles, plus faciles à déboguer et moins dépendants de l’état local de votre session Postman.