DEV Community

Cover image for Outil de mock API headless : serveurs de simulation pour intégration continue sans GUI
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Outil de mock API headless : serveurs de simulation pour intégration continue sans GUI

Un outil de simulation d'API sans interface graphique (headless) lance une fausse API exploitable depuis une spécification ou une configuration, sans ouvrir d'interface graphique. C'est utile dès que vos tests frontend, vos jobs CI, vos conteneurs Docker ou vos environnements de preview ont besoin d'un backend stable. Ce guide montre comment choisir entre Prism, WireMock, Mockoon CLI et Apidog, puis comment les intégrer dans un workflow automatisé. Pour les bases, commencez par ce qu'est une API de simulation.

Essayez Apidog aujourd'hui

Ce que « headless » signifie pour une API de simulation

Un serveur de simulation répond aux requêtes HTTP avec des réponses fausses mais réalistes. Cela permet à une application frontend, à une suite de tests ou à un agent de génération de code de travailler avant que le backend réel soit disponible.

« Headless » signifie que le serveur de simulation s'exécute sans GUI :

mock-server --config ./api.yaml --port 4010
Enter fullscreen mode Exit fullscreen mode

Vous le démarrez depuis un terminal, un job CI ou un conteneur, puis vos tests appellent son URL.

Les cas d'usage typiques :

  • lancer des tests frontend sans backend réel ;
  • exécuter des tests API dans GitHub Actions, GitLab CI ou Jenkins ;
  • ajouter un backend simulé dans docker-compose ;
  • partager une API stable avec une équipe frontend ;
  • créer un environnement de preview par pull request.

Un outil avec interface graphique est pratique pour concevoir des réponses. Mais pour automatiser, il faut au moins l'un de ces modes :

  • une CLI ;
  • une image Docker ;
  • une URL de simulation hébergée ;
  • un serveur local accessible sur le réseau.

Choisir entre simulation basée sur la spécification et basée sur la configuration

Avant de choisir un outil, identifiez la source de vérité.

Option 1 : simulation basée sur la spécification

L'outil lit une spécification OpenAPI ou un schéma d'API, puis génère les réponses à partir du contrat.

Avantages :

  • moins de configuration manuelle ;
  • meilleure cohérence avec le contrat ;
  • mise à jour automatique quand le schéma change ;
  • utile pour les équipes qui documentent déjà leurs API avec OpenAPI.

Exemple de logique :

paths:
  /users/{id}:
    get:
      responses:
        "200":
          description: Utilisateur trouvé
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: integer
                  email:
                    type: string
                    format: email
Enter fullscreen mode Exit fullscreen mode

Une simulation basée sur le schéma peut renvoyer un objet compatible avec cette structure.

Option 2 : simulation basée sur la configuration

L'outil utilise ses propres fichiers de stubs, règles ou environnements.

Avantages :

  • plus flexible pour les cas limites ;
  • pratique pour simuler des erreurs, délais, états ou workflows complexes ;
  • utile quand aucune spécification OpenAPI n'existe.

Inconvénient : vous devez maintenir cette configuration séparément. Elle peut diverger du backend réel.

En pratique, beaucoup d'équipes utilisent les deux : une simulation basée sur la spécification pour les cas standards, puis des règles personnalisées pour les cas spécifiques. Pour structurer ce workflow, consultez aussi le guide de simulation d'API.

Options de simulation sans interface graphique

Prism

Prism transforme un fichier OpenAPI 2/3 ou une collection Postman en serveur de simulation.

Commande minimale :

prism mock openapi.yaml
Enter fullscreen mode Exit fullscreen mode

Par défaut, Prism écoute sur :

http://127.0.0.1:4010
Enter fullscreen mode Exit fullscreen mode

Prism mock CLI

Prism renvoie les exemples définis dans votre spécification. Si vous voulez générer des données dynamiques à partir des schémas, ajoutez -d :

prism mock -d openapi.yaml
Enter fullscreen mode Exit fullscreen mode

Vous pouvez aussi utiliser x-faker dans votre spécification pour guider la génération de données.

Prism est un bon choix si :

  • votre contrat est déjà dans un fichier OpenAPI ;
  • vous voulez une CLI légère ;
  • vous voulez éviter une configuration de stubs séparée ;
  • vos besoins de simulation restent proches du schéma.

WireMock

WireMock est un serveur de simulation HTTP mature, basé sur Java. Il est très adapté aux règles de correspondance complexes.

Démarrage avec le jar autonome :

java -jar wiremock-standalone-3.x.x.jar --port 9099
Enter fullscreen mode Exit fullscreen mode

WireMock

WireMock repose principalement sur des stubs. Exemple de mapping JSON :

{
  "request": {
    "method": "GET",
    "url": "/users/1"
  },
  "response": {
    "status": 200,
    "jsonBody": {
      "id": 1,
      "email": "user@example.com"
    },
    "headers": {
      "Content-Type": "application/json"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

WireMock est pertinent si vous avez besoin de :

  • faire correspondre des requêtes avec des règles fines ;
  • simuler des scénarios avec état ;
  • enregistrer puis rejouer du trafic réel ;
  • intégrer la simulation dans une stack JVM ;
  • tester des comportements réseau ou des erreurs spécifiques.

Mockoon CLI

Mockoon combine une application de bureau et une CLI. Vous construisez vos environnements dans l'interface graphique, puis vous les exécutez sans interface graphique.

Commande de démarrage :

mockoon-cli start --data ./environment.json --port 3000
Enter fullscreen mode Exit fullscreen mode

Mockoon CLI

Mockoon fournit aussi une image Docker et une commande dockerize pour générer un Dockerfile autonome.

Mockoon est utile si :

  • vous préférez concevoir les routes visuellement ;
  • vous voulez ensuite exécuter les mocks en CI ou sur serveur ;
  • vous avez besoin de templating, de règles de réponse ou de proxy ;
  • votre équipe n'utilise pas forcément OpenAPI comme unique source de vérité.

Serveur de simulation Apidog

Apidog est une plateforme API tout-en-un. Son serveur de simulation est basé sur le schéma par défaut : quand vous définissez ou importez une API, Apidog peut générer une simulation sans configuration supplémentaire.

Le Smart Mock lit les noms de champs et les types pour générer des données plus réalistes. Par exemple, des champs comme :

{
  "email": "string",
  "avatar": "string",
  "username": "string",
  "phone": "string",
  "date": "string",
  "ip": "string"
}
Enter fullscreen mode Exit fullscreen mode

peuvent être remplis avec des valeurs pertinentes plutôt qu'avec de simples placeholders.

Pour un contrôle plus précis, vous pouvez utiliser des expressions Faker.js, par exemple :

{{$person.fullName}}
{{$number.int(min=1,max=100)}}
Enter fullscreen mode Exit fullscreen mode

Vous pouvez aussi définir des règles de simulation personnalisées pour des conditions de requête spécifiques.

Apidog Smart Mock

Pour une utilisation headless, Apidog expose une URL de simulation Cloud de type :

https://mock.apidog.com/...
Enter fullscreen mode Exit fullscreen mode

Un job CI, un développeur frontend ou un environnement de preview peut appeler cette URL sans lancer de processus local.

Apidog prend aussi en charge une simulation locale sur 127.0.0.1, avec possibilité de la lier à une IP intranet pour la rendre accessible à d'autres machines du réseau.

Apidog est adapté si vous voulez garder au même endroit :

  • la conception d'API ;
  • la documentation ;
  • les tests ;
  • les mocks ;
  • le contrat utilisé par l'équipe.

Comparaison rapide

Outil Source de vérité Exécution headless Données réalistes Idéal pour
Prism Fichier OpenAPI / Postman prism mock spec.yaml Mode dynamique -d + x-faker Simulation CLI basée sur la spécification
WireMock Stubs / enregistrements Jar autonome Templating des réponses Correspondance complexe, JVM, record/replay
Mockoon CLI Environnements créés dans l'interface graphique mockoon-cli start + Docker Aides au templating Conception visuelle, exécution automatisée
Apidog Schéma d'API dans le projet URL de simulation Cloud + serveur local Smart Mock + Faker.js Mocks liés à la conception, aux docs et aux tests

Il n'y a pas de meilleur outil universel :

  • choisissez Prism si vous voulez une CLI simple autour d'OpenAPI ;
  • choisissez WireMock pour les scénarios complexes et les règles avancées ;
  • choisissez Mockoon si votre équipe préfère concevoir les mocks visuellement ;
  • choisissez Apidog si vous voulez relier simulation, documentation, tests et contrat d'API dans le même projet.

Pour un panorama plus large, consultez le récapitulatif des meilleurs outils de simulation d'API.

Exécuter une simulation headless en CI

Le modèle général est simple :

  1. démarrer le serveur de simulation ;
  2. attendre que le port soit disponible ;
  3. lancer les tests ;
  4. arrêter le serveur.

Exemple avec Prism :

# Démarrer la simulation en arrière-plan
prism mock ./openapi.yaml &
MOCK_PID=$!

# Optionnel : attendre que le serveur réponde
sleep 3

# Exécuter les tests contre http://127.0.0.1:4010
npm test

# Nettoyer le processus
kill $MOCK_PID
Enter fullscreen mode Exit fullscreen mode

Dans un pipeline, vous pouvez aussi rendre l'URL configurable :

API_BASE_URL=http://127.0.0.1:4010 npm test
Enter fullscreen mode Exit fullscreen mode

Côté application, évitez de coder l'URL en dur :

const API_BASE_URL = process.env.API_BASE_URL || "http://localhost:3000";

export async function getUser(id) {
  const response = await fetch(`${API_BASE_URL}/users/${id}`);
  return response.json();
}
Enter fullscreen mode Exit fullscreen mode

Avec Apidog, vous pouvez soit utiliser une simulation locale, soit pointer directement vos tests vers l'URL de simulation Cloud. Cela évite de démarrer un processus dans le pipeline.

Exemple :

API_BASE_URL=https://mock.apidog.com/your-project npm test
Enter fullscreen mode Exit fullscreen mode

La simulation reste liée au schéma du projet. Quand le contrat change, les réponses simulées suivent le même contrat.

Tester la simulation depuis la ligne de commande

Une fois le mock disponible, vous pouvez le tester comme n'importe quelle API.

Exemple avec curl :

curl http://127.0.0.1:4010/users/1
Enter fullscreen mode Exit fullscreen mode

Exemple avec une variable d'environnement :

curl "$API_BASE_URL/users/1"
Enter fullscreen mode Exit fullscreen mode

Apidog propose aussi une CLI headless, apidog-cli. La commande apidog run permet d'exécuter des scénarios de test en CI, avec prise en charge des données CSV ou JSON et génération de rapports CLI, HTML ou JSON.

Pour aller plus loin :

Exemple avec Docker Compose

Une simulation headless devient encore plus utile quand elle fait partie de votre stack locale.

Exemple conceptuel avec un service frontend et un mock :

services:
  frontend:
    build: .
    environment:
      API_BASE_URL: http://mock-api:4010
    depends_on:
      - mock-api

  mock-api:
    image: stoplight/prism:latest
    command: mock -h 0.0.0.0 /tmp/openapi.yaml
    volumes:
      - ./openapi.yaml:/tmp/openapi.yaml
    ports:
      - "4010:4010"
Enter fullscreen mode Exit fullscreen mode

Le frontend appelle http://mock-api:4010 depuis le réseau Docker, tandis que les développeurs peuvent aussi accéder au mock via http://localhost:4010.

Simulations et agents de codage IA

Si vous utilisez Cursor, Claude ou VS Code avec un agent IA, le mock est plus utile quand l'agent connaît aussi le contrat d'API.

Le serveur Apidog MCP permet à un agent IA de lire directement les spécifications d'API. L'agent peut alors générer du code client aligné avec le même schéma que celui utilisé par la simulation.

Le résultat attendu :

  • moins d'hypothèses incorrectes dans le code généré ;
  • des types et payloads plus proches du contrat réel ;
  • une cohérence entre mock, documentation et code client.

Foire aux questions

Une simulation headless est-elle la même chose qu'un serveur de simulation ?

Oui, avec une précision : un serveur de simulation répond aux requêtes avec de fausses réponses. « Headless » indique simplement qu'il fonctionne sans interface graphique, via une commande, un conteneur ou une URL hébergée.

Puis-je générer une simulation headless depuis OpenAPI ?

Oui. Prism lit directement OpenAPI. Apidog peut générer une simulation à partir du schéma de votre projet. Les simulations basées sur la spécification demandent moins de maintenance, car elles suivent le contrat plutôt qu'une configuration séparée. Consultez le guide de simulation d'API pour le workflow complet.

Comment éviter les placeholders comme string ou 0 ?

Utilisez un moteur de données réalistes :

  • Prism propose le mode dynamique avec -d et x-faker ;
  • Apidog propose Smart Mock et des expressions Faker.js ;
  • WireMock et Mockoon peuvent utiliser du templating.

Sans ce type de mécanisme, les mocks retournent souvent des valeurs peu utiles pour les tests frontend.

Dois-je toujours exécuter un serveur local ?

Non. Deux approches existent :

  • exécuter un processus local ou Docker avec Prism, WireMock ou Mockoon CLI ;
  • utiliser une URL de simulation hébergée, comme l'URL de simulation Cloud d'Apidog.

L'URL hébergée réduit la configuration en CI, car le pipeline n'a pas besoin de démarrer ni d'arrêter un serveur de mock.

Conclusion

Un outil de simulation d'API headless permet de faire tourner vos mocks là où votre pipeline en a besoin : CI, Docker, scripts locaux ou environnements de preview. Prism, WireMock et Mockoon CLI couvrent très bien ce besoin avec des approches différentes. Si vous voulez que le mock reste lié au contrat, à la documentation et aux tests, Apidog centralise ces éléments dans un même projet, avec une simulation basée sur le schéma utilisable en local ou via une URL hébergée.

Téléchargez Apidog pour créer une simulation depuis votre spécification et l'utiliser dans votre workflow CI.

Top comments (0)