DEV Community

Cover image for Bruno a-t-il un serveur de simulation ? Alternatives et outils
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Bruno a-t-il un serveur de simulation ? Alternatives et outils

Bruno est un client API léger, natif de Git et open-source. Il est pratique pour versionner des collections et exécuter des requêtes, mais il ne fournit pas de serveur de simulation intégré. Si vous devez tester un endpoint qui n’existe pas encore, vous devez soit ajouter un outil externe, soit générer une simulation depuis votre contrat OpenAPI.

Essayez Apidog aujourd'hui

Réponse courte : Bruno permet d’envoyer des requêtes et d’écrire des tests, mais il ne sait pas transformer une requête enregistrée en endpoint factice capable de renvoyer des réponses d’exemple.

Pourquoi utiliser un serveur de simulation API ?

Un serveur de simulation renvoie des réponses réalistes pour des endpoints qui ne sont pas encore disponibles, instables ou difficiles à déclencher dans un environnement réel.

Cas d’usage typiques :

  • Développement parallèle : le front-end ou l’application mobile consomme le contrat API pendant que le backend est encore en cours.
  • Tests d’erreurs : vous forcez des réponses 429, 500, 503, des en-têtes spécifiques ou des payloads invalides.
  • Démos et prototypes : vous présentez un parcours utilisateur sans backend, base de données ou identifiants réels.
  • CI plus stable : vos tests ne dépendent pas d’un serveur de staging indisponible ou soumis à des limites de débit.

Exemples de scénarios à simuler :

Scénario Ce que la simulation renvoie Pourquoi c’est difficile autrement
Limite de débit atteinte 429 + en-tête Retry-After Le backend limite rarement le débit à la demande
Panne serveur 500 ou 503 Vous ne voulez pas casser le staging pour tester
Réponse lente Corps retardé La latence réelle est difficile à reproduire
Résultat vide 200 avec [] Dépend souvent de l’état des données
Payload invalide Corps sans champ requis La validation backend l’empêche généralement

Bruno a-t-il un serveur de simulation ?

Non. Bruno se concentre sur :

  • l’envoi de requêtes HTTP ;
  • l’organisation des collections sous forme de fichiers ;
  • l’exécution d’assertions ;
  • un workflow compatible Git.

Il n’existe pas d’option native pour exposer un endpoint simulé à partir d’une requête Bruno.

En pratique, vous avez deux options.

Option 1 : utiliser un outil de simulation externe

Vous pouvez créer vos mocks dans un outil comme Mockoon, WireMock, Prism ou json-server, puis pointer Bruno vers l’URL générée.

Exemple :

GET http://localhost:3001/users
Enter fullscreen mode Exit fullscreen mode

Puis dans Bruno, vous utilisez cette URL comme base URL de votre environnement local.

Avantage : rapide à mettre en place pour quelques endpoints.

Inconvénient : vos requêtes Bruno, votre spécification et vos définitions de simulation vivent à des endroits différents.

Option 2 : coder un petit serveur de stub

Pour un besoin très local, vous pouvez écrire un serveur minimal.

Exemple avec Express :

import express from "express";

const app = express();

app.get("/users", (req, res) => {
  res.json([
    {
      id: "usr_001",
      name: "Alice Martin",
      email: "alice@example.com"
    }
  ]);
});

app.get("/rate-limit", (req, res) => {
  res.set("Retry-After", "60");
  res.status(429).json({
    error: "rate_limit_exceeded"
  });
});

app.listen(3001, () => {
  console.log("Mock server running on http://localhost:3001");
});
Enter fullscreen mode Exit fullscreen mode

Puis lancez :

node server.js
Enter fullscreen mode Exit fullscreen mode

Et appelez :

curl http://localhost:3001/users
Enter fullscreen mode Exit fullscreen mode

Cette approche fonctionne, mais elle devient vite coûteuse si votre API grandit.

Le coût d’une simulation ajoutée à côté de Bruno

Ajouter une couche de simulation externe est possible, mais plusieurs problèmes apparaissent avec le temps :

  • Dérive du contrat : votre spécification, vos requêtes Bruno et vos mocks peuvent devenir incohérents.
  • Configuration répétée : chaque développeur doit installer et configurer l’outil de simulation.
  • Réponses écrites à la main : chaque endpoint, statut HTTP et payload doit être maintenu manuellement.
  • Données peu réalistes : les stubs statiques renvoient souvent toujours les mêmes valeurs, comme "name": "string".

Pour une analyse plus large de ces limites, consultez cette comparaison autour d’une plateforme API tout-en-un alternative à Bruno.

Générer un serveur de simulation depuis OpenAPI

L’approche la plus maintenable consiste à dériver la simulation du contrat que vous maintenez déjà : votre spécification OpenAPI.

Avec Apidog, vous pouvez importer ou écrire une spécification OpenAPI, puis générer une URL de simulation à partir des mêmes définitions utilisées pour la conception, les tests et la documentation.

Interface Apidog

L’intérêt principal : une seule source de vérité.

Au lieu de maintenir séparément :

  • la spécification OpenAPI ;
  • les requêtes Bruno ;
  • les réponses de simulation ;

vous partez du contrat API et vous générez les réponses simulées depuis ce contrat.

Exemple de contrat OpenAPI à simuler

Voici un exemple minimal :

openapi: 3.0.3
info:
  title: Users API
  version: 1.0.0

paths:
  /users:
    get:
      summary: Liste les utilisateurs
      responses:
        "200":
          description: Liste des utilisateurs
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/User"

        "429":
          description: Limite de débit atteinte
          headers:
            Retry-After:
              schema:
                type: integer
              description: Nombre de secondes avant de réessayer
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string

components:
  schemas:
    User:
      type: object
      required:
        - id
        - name
        - email
      properties:
        id:
          type: string
          example: usr_001
        name:
          type: string
          example: Alice Martin
        email:
          type: string
          format: email
          example: alice@example.com
        created_at:
          type: string
          format: date-time
Enter fullscreen mode Exit fullscreen mode

Une fois importé dans un outil de simulation basé sur OpenAPI, ce contrat contient déjà les informations nécessaires :

  • chemins ;
  • méthodes HTTP ;
  • codes de statut ;
  • schémas de réponse ;
  • types de champs ;
  • exemples éventuels.

Guide rapide : de la spécification à l’URL de simulation

Voici un workflow concret.

1. Importer la spécification OpenAPI

Importez votre fichier OpenAPI ou Swagger, ou utilisez l’URL de votre spécification.

Exemples de sources possibles :

openapi.yaml
Enter fullscreen mode Exit fullscreen mode

ou :

https://example.com/openapi.json
Enter fullscreen mode Exit fullscreen mode

Les endpoints, schémas et réponses sont importés tels quels.

2. Vérifier les endpoints importés

Contrôlez que chaque endpoint dispose bien :

  • d’un chemin, par exemple /users ;
  • d’une méthode HTTP, par exemple GET ;
  • d’au moins une réponse, par exemple 200 ;
  • d’un schéma de réponse.

Sans schéma, la simulation ne peut pas générer de payload utile.

3. Récupérer l’URL de simulation

Apidog expose une URL de simulation pour appeler vos endpoints sans déployer de serveur supplémentaire.

Vous pouvez ensuite appeler cette URL depuis votre terminal, votre front-end ou Bruno.

Exemple avec curl :

curl "$MOCK_BASE_URL/users"
Enter fullscreen mode Exit fullscreen mode

Réponse attendue :

[
  {
    "id": "usr_001",
    "name": "Alice Martin",
    "email": "alice@example.com",
    "created_at": "2026-06-02T10:00:00Z"
  }
]
Enter fullscreen mode Exit fullscreen mode

4. Pointer votre application vers le mock

Dans votre front-end, vous pouvez isoler l’URL de base dans une variable d’environnement.

Exemple :

VITE_API_BASE_URL=https://mock.example.com
Enter fullscreen mode Exit fullscreen mode

Puis dans votre code :

const API_BASE_URL = import.meta.env.VITE_API_BASE_URL;

export async function fetchUsers() {
  const response = await fetch(`${API_BASE_URL}/users`);

  if (!response.ok) {
    throw new Error(`API error: ${response.status}`);
  }

  return response.json();
}
Enter fullscreen mode Exit fullscreen mode

Votre front-end peut avancer même si le backend réel n’est pas encore disponible.

5. Tester les cas limites

Ajoutez ou utilisez des réponses spécifiques pour tester les chemins d’erreur.

Exemple de test d’un 429 :

curl -i "$MOCK_BASE_URL/users"
Enter fullscreen mode Exit fullscreen mode

Vous voulez vérifier que votre client gère correctement :

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Enter fullscreen mode Exit fullscreen mode

Côté application :

async function fetchWithRateLimitHandling(url) {
  const response = await fetch(url);

  if (response.status === 429) {
    const retryAfter = response.headers.get("Retry-After");

    return {
      retry: true,
      retryAfter: Number(retryAfter ?? 0)
    };
  }

  return response.json();
}
Enter fullscreen mode Exit fullscreen mode

Pourquoi une simulation basée sur OpenAPI réduit la maintenance

Une simulation dérivée de la spécification apporte plusieurs avantages pratiques :

  • Simulation depuis le schéma : les réponses sont générées à partir des types et formats définis dans OpenAPI.
  • Données plus plausibles : un champ email peut produire une valeur de type email, un champ created_at une date.
  • Moins de code à maintenir : vous n’écrivez pas un serveur Express ou Flask pour chaque endpoint.
  • Synchronisation du contrat : quand la spécification change, la simulation suit le même contrat.
  • Documentation cohérente : les mêmes définitions alimentent la conception, la simulation, les tests et la documentation.

Si votre workflow repose sur Git, vous pouvez continuer à versionner votre contrat API et à le relire en pull request. Cette logique s’intègre bien avec un workflow API natif de Git.

Pour approfondir les scénarios couverts par la simulation, consultez aussi ces cas d’utilisation de la simulation d’API.

Quand les solutions de contournement suffisent

Vous n’avez pas toujours besoin d’une simulation basée sur une spécification.

Bruno avec un outil externe léger peut suffire si :

  • vous ne simulez qu’un ou deux endpoints ;
  • vous faites un test local ponctuel ;
  • vos réponses statiques sont suffisantes ;
  • votre équipe utilise déjà Mockoon, WireMock ou Prism ;
  • la maintenance d’une source de vérité supplémentaire ne vous ralentit pas.

Dans ce cas, gardez le setup simple.

En revanche, si votre API évolue vite, que plusieurs équipes consomment le contrat ou que vous devez tester beaucoup de statuts et de payloads, une simulation générée depuis OpenAPI devient plus robuste.

FAQ

Bruno a-t-il un serveur de simulation intégré ?

Non. Bruno est un client API pour envoyer des requêtes et exécuter des tests. Il ne fournit pas de serveur de simulation natif.

Pour simuler des endpoints, vous devez utiliser un outil externe ou écrire votre propre serveur de stub.

Quelle est la manière la plus simple d’ajouter la simulation à un workflow proche de Bruno ?

La méthode la plus maintenable consiste à générer la simulation depuis votre spécification OpenAPI.

Des outils comme Apidog lisent la spécification et produisent une URL de simulation prête à appeler, ce qui évite de maintenir des mocks séparés.

Puis-je continuer à utiliser Bruno avec un serveur de simulation externe ?

Oui. Vous pouvez exécuter Mockoon, WireMock, Prism ou un serveur fait maison, puis pointer Bruno vers l’URL du mock.

Cela fonctionne, mais votre contrat, vos requêtes et vos données simulées peuvent diverger si vous ne les maintenez pas ensemble.

Quand faut-il passer à une simulation basée sur OpenAPI ?

Passez à une simulation basée sur OpenAPI lorsque :

  • votre API contient de nombreux endpoints ;
  • plusieurs équipes consomment le même contrat ;
  • vous devez tester des erreurs spécifiques ;
  • vos mocks statiques deviennent difficiles à maintenir ;
  • vous voulez éviter la dérive entre documentation, tests et simulation.

Conclusion

Bruno reste un bon choix si vous voulez un client API léger et versionnable avec Git. Mais il ne fournit pas de serveur de simulation intégré.

Pour quelques endpoints, un outil externe ou un petit serveur de stub suffit. Pour une API qui grandit, la solution la plus propre consiste à générer la simulation depuis votre spécification OpenAPI.

Importez votre fichier OpenAPI dans Apidog, récupérez une URL de simulation et utilisez-la dans votre front-end, votre application mobile, Bruno ou votre suite de tests.

Top comments (0)