---
title: 'Requestly : simuler une réponse API dans Chrome'
description: 'Teste une interface avec une réponse JSON modifiée par Requestly : exemple local, règle ciblée, vérification et limites de l’extension Chrome.'
pubDate: 2024-10-09
updatedDate: 2026-10-18
family: 'api-donnees'
tags: []
heroImage: /images/modifier-les-reponses-de-toutes-les-api-avec-cette-extension-chrome-requestly.webp
videoUrl: 'https://youtu.be/ZHE8RFAg5w4'
---

Tu veux voir comment ton interface réagit à un produit indisponible, sans changer les données du
backend ? Une règle Requestly peut remplacer la réponse JSON lue par ta page. Tu testes alors un
scénario côté client ; tu ne modifies ni le code du serveur ni sa base de données.

L'ancien titre promettait de modifier « toutes les API ». Le périmètre utile est plus précis : dans
l'extension, la règle **Modify API Response** vise les requêtes XHR et Fetch des pages web, pas
l'ensemble du trafic de ta machine. La [documentation de dépannage officielle](https://interceptor-docs.requestly.com/troubleshoot/http-rules/rules-not-working)
distingue ce cas de la modification des fichiers HTML, CSS et JavaScript, réservée à l'application
desktop pour ce type de règle.

Cette réécriture ajoute un scénario reproductible et ces limites, à partir des sources officielles.
Elle ne prétend pas décrire les manipulations exactes de la vidéo initiale.

## Installer le bon composant

Sur la [page officielle de téléchargement](https://requestly.com/downloads/), cherche **HTTP
interceptor**, puis **Browser extension / Add to Chrome**. Le site met aussi en avant un client API
desktop : ce n'est pas le composant utilisé ici. Au moment de cette vérification, l'extension
Interceptor est toujours proposée ; le [dépôt officiel Requestly](https://github.com/requestly/requestly)
n'est pas archivé.

Privilégie un profil de navigateur dédié aux tests. N'utilise ni jeton réel ni réponse contenant des
données personnelles dans une règle susceptible d'être partagée ou exportée. Accorde seulement les
accès nécessaires au site de démonstration et retire-les après l'exercice.

## Préparer une API et une page locales

Prérequis : Node.js et curl. Crée un fichier `demo-requestly.cjs` dans un dossier de test. Ce serveur
ne dépend d'aucun paquet externe et n'écoute que sur l'interface locale.

```javascript
const http = require('node:http');

const produit = { nom: 'Carnet de test', disponible: true };
const page = `<!doctype html>
<html lang="fr">
<head><meta charset="utf-8"><title>Test Requestly</title></head>
<body>
  <h1>Produit de démonstration</h1>
  <button id="charger" type="button">Charger le produit</button>
  <p id="resultat" aria-live="polite">Aucune donnée chargée.</p>
  <script>
    document.querySelector('#charger').addEventListener('click', async () => {
      const resultat = document.querySelector('#resultat');
      try {
        const response = await fetch('/api/produit', { cache: 'no-store' });
        if (!response.ok) throw new Error('HTTP ' + response.status);
        const produit = await response.json();
        resultat.textContent = produit.nom + ' : ' +
          (produit.disponible ? 'disponible' : 'indisponible');
      } catch (error) {
        resultat.textContent = 'Erreur : ' + error.message;
      }
    });
  </script>
</body>
</html>`;

http
  .createServer((req, res) => {
    res.setHeader('Cache-Control', 'no-store');
    if (req.method !== 'GET') {
      res.writeHead(405, { Allow: 'GET' });
      return res.end();
    }
    if (req.url === '/api/produit') {
      res.writeHead(200, { 'Content-Type': 'application/json; charset=utf-8' });
      return res.end(JSON.stringify(produit));
    }
    if (req.url === '/') {
      res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
      return res.end(page);
    }
    res.writeHead(404);
    res.end();
  })
  .listen(8080, '127.0.0.1');
```

Lance-le :

```bash
node demo-requestly.cjs
```

Dans un second terminal, vérifie la réponse d'origine :

```bash
curl -i http://127.0.0.1:8080/api/produit
```

Le serveur doit répondre HTTP 200 avec le corps suivant :

```json
{ "nom": "Carnet de test", "disponible": true }
```

Ouvre `http://127.0.0.1:8080/`, puis clique sur **Charger le produit**. Sans règle active,
le résultat attendu est « Carnet de test : disponible ».

## Créer une règle limitée à cet endpoint

La [procédure officielle Modify API Response](https://interceptor-docs.requestly.com/http-rules/rule-types/modify-response-body)
décrit les modes statique et dynamique. Pour ce premier test, reste en statique :

1. Ouvre **HTTP Rules**, puis **New Rule → Modify API Response**.
2. Choisis **REST API** comme type de ressource : notre page utilise Fetch.
3. Configure la condition **URL / Equals** avec `http://127.0.0.1:8080/api/produit`.
4. Laisse le code HTTP inchangé et sélectionne la modification statique du corps.
5. Colle ce JSON à la place de la réponse :

```json
{ "nom": "Carnet de test", "disponible": false }
```

Enregistre avec **Save**, active la règle et son groupe, puis recharge la page avant de cliquer à
nouveau. Le résultat attendu devient « Carnet de test : indisponible ». Désactive la règle et
recommence : le produit doit redevenir disponible. Cette alternance évite de confondre la règle avec
une modification durable du serveur.

Ne coche pas **Serve this response body without making call to the server** pour cet exercice :
la documentation décrit cette option séparément pour servir un corps sans appel au backend. Remplacer
une réponse ne signifie donc pas automatiquement que la requête n'atteint jamais le serveur. Ne teste
pas ce mécanisme sur une opération réelle de paiement, d'envoi ou de suppression.

## Contrôler ce qui a changé, et ce qui n'a pas changé

Relance le même curl : avec uniquement l'extension de navigateur, il doit toujours lire
`disponible: true`. Cette requête ne traverse pas l'extension. Ce contrôle ne s'appliquerait plus de la
même manière si tu avais configuré un proxy système avec l'application desktop ; les deux périmètres
sont distingués dans la [comparaison officielle desktop / extension](https://interceptor-docs.requestly.com/getting-started/difference-between-desktop-app-and-browser-extension).

Pour la réponse consommée par la page, contrôle le texte affiché et utilise le bouton de test de la
règle. La [documentation Requestly](https://interceptor-docs.requestly.com/troubleshoot/http-rules/rules-not-working)
prévient que les modifications de réponse ne sont pas nécessairement visibles dans les DevTools du
navigateur : l'onglet Network seul ne suffit pas à conclure que la règle a échoué.

**Contrôles réellement exécutés pour cet article :** serveur démarré sous Linux avec Node.js 26.7.0 ;
curl a reçu HTTP 200, un type JSON et le produit disponible. La page a répondu 200, une route inconnue
404 et une requête POST 405. Le JSON de remplacement a été validé syntaxiquement. **L'extension
Chrome et son interface n'ont pas été exécutées** : l'activation de la règle et l'alternance de texte
ci-dessus restent une procédure documentée, pas un résultat observé de bout en bout.

## Si la règle ne s'applique pas

Vérifie d'abord que Requestly n'est pas en pause, que la règle et son groupe sont actifs, et que
l'extension a accès au site local. Recharge la page puis déclenche une nouvelle requête.
Compare ensuite l'URL exacte : `localhost` et `127.0.0.1`, un port différent ou un paramètre ajouté
ne correspondent pas à notre condition **Equals**. Garde une condition étroite plutôt que de viser
toutes les URL. Ces vérifications suivent la [checklist officielle des règles](https://interceptor-docs.requestly.com/troubleshoot/http-rules/rules-not-working).

La simulation valide un comportement d'interface, pas le contrat réel de ton backend, ses
permissions ou son intégration avec des services externes. Termine par un test sans règle pour ne
pas garder un faux état pendant tes développements.

Pour compléter cette procédure, tu peux regarder la [vidéo associée](https://youtu.be/ZHE8RFAg5w4).