MockServer : un seul port pour simuler, espionner et casser vos dépendances
MockServer is an HTTP(S) mock server and proxy for testing that lets you mock APIs, inspect and modify live traffic, and inject failures. It supports HTTP/1.1, HTTP/2, gRPC, WebSockets, TCP and more on a single port, with additional support for HTTP/3, message brokers, and AI/LLM APIs.
En bref
- De quoi s’agit-il ?
- MockServer réunit le bouchon HTTP, le proxy d'enregistrement et l'injection de pannes dans un même processus Java. Le point fort est le multiplexage des protocoles sur un port unique. Le point faible est la quantité de configuration à maîtriser avant d'en tirer quelque chose.
- À qui s’adresse-t-il ?
- MockServer convient aux équipes qui doivent simuler plusieurs protocoles à la fois et qui acceptent d'exploiter un composant Java supplémentaire dans leur chaîne de test. Il ne convient pas si vous avez seulement besoin de servir des fichiers statiques sur HTTP ou si personne dans l'équipe ne veut maintenir un processus à part.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Java, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Trois outils dans un seul processus, et c'est là que se joue le choix
MockServer se présente comme trois choses à la fois. Un serveur de bouchon qui répond à la place d'une API absente ou incomplète. Un proxy qui relaie le trafic réel pour l'enregistrer et le modifier en vol. Un injecteur de pannes qui produit latence, connexions coupées et erreurs. Ces trois fonctions partagent le même port et le même plan de contrôle REST.
Le public visé est précis : les équipes qui testent une application dont les dépendances sont nombreuses et pas toujours disponibles. Si votre problème se limite à servir une réponse figée sur une route HTTP, vous n'avez pas besoin de ce projet. Un fichier de configuration dans un serveur web quelconque suffit, et vous éviterez d'exploiter un processus Java de plus.
Le README donne un exemple minimal qui tient en trois commandes : un conteneur Docker sur le port 1080, un PUT vers /mockserver/expectation avec un corps JSON décrivant la requête attendue et la réponse à renvoyer, puis un GET sur la route simulée. Le contrôle et la simulation passent donc par le même port, ce qui évite d'ouvrir une seconde interface d'administration.
Le multiplexage des protocoles sur un port unique
C'est la caractéristique la plus intéressante du projet. HTTP/1.1, HTTPS, HTTP/2, gRPC, gRPC-Web, WebSockets et TCP brut sont détectés automatiquement à partir des premiers octets de chaque connexion. Le README indique explicitement qu'aucune configuration par protocole n'est nécessaire. Concrètement, cela évite de multiplier les ports dans un fichier docker-compose ou dans un manifeste Kubernetes, et cela évite surtout de deviner à l'avance quel protocole un client va négocier.
HTTP/3 fait exception. Il est décrit comme expérimental et s'exécute sur son propre port UDP, ce qui est une contrainte technique liée à QUIC et non un choix de conception contestable. Les courtiers de messages (Kafka, MQTT) sortent eux aussi du modèle : le README parle de tests pilotés par AsyncAPI contre des courtiers externes, donc d'un mode de fonctionnement différent, pas d'un protocole détecté sur le port principal.
Pour le reste, la liste est longue : JSON-RPC pour simuler MCP ou A2A, et des API de complétion de chat pour OpenAI, Anthropic, Gemini, Bedrock, Azure OpenAI et Ollama, streaming compris. Cette dernière partie mérite qu'on s'y arrête, car elle répond à un besoin récent et concret : tester une application qui appelle un modèle sans consommer de jetons ni dépendre de la disponibilité d'un fournisseur.
Le plan de contrôle REST et le templating des réponses
Toute la configuration passe par des requêtes HTTP. L'exemple du README crée une attente avec un PUT sur /mockserver/expectation et un corps JSON contenant les clés httpRequest et httpResponse. La requête simulée se décrit par méthode, chemin, query, en-têtes, cookies et corps, avec correspondance JSON, XML, JSONPath, XPath, expression régulière ou spécification OpenAPI. La réponse se décrit par un code de statut et un corps, comme dans l'exemple où GET /hello renvoie 200 avec le texte Hello World.
Pour les réponses qui doivent varier, le projet propose trois mécanismes de templating : Velocity, Mustache et JavaScript. S'y ajoutent des callbacks sous forme de classes ou de closures, et des webhooks. Le choix de supporter trois moteurs de template plutôt qu'un seul se paie en surface d'apprentissage, mais il évite d'imposer un langage à une équipe qui en utilise déjà un autre.
Deux fonctions complètent l'ensemble. La génération d'attentes directement depuis une spécification OpenAPI ou Swagger, ce qui évite d'écrire à la main des dizaines de routes. Et la vérification : assert sur les requêtes reçues, leur ordre et leur nombre d'occurrences. Cette dernière partie est celle qu'on oublie souvent de mentionner, alors qu'elle transforme un simple bouchon en outil de test à part entière.
Le dashboard accessible sur /mockserver/dashboard affiche requêtes, attentes et journaux en temps réel. C'est pratique pendant la mise au point, mais le README ne précise pas comment cet affichage se comporte en production ni s'il faut le désactiver.
Démarrage : Docker, Homebrew, ou recettes docker-compose
La voie la plus courte reste Docker : docker run -d --rm -p 1080:1080 mockserver/mockserver. Sur macOS et Linux, Homebrew installe une commande directe avec brew install mockserver, puis mockserver run --port 1080. Le projet se lance aussi en JAR, en WAR, via Helm et Kubernetes, ou via Testcontainers, et le README renvoie à un guide d'auto-hébergement pour l'ensemble de ces modes.
Pour les scénarios courants, le dépôt fournit des recettes docker-compose à lancer d'une seule commande : mock depuis une spécification OpenAPI, proxy d'enregistrement et rejeu, proxy validant les contrats, proxy d'injection de pannes. L'exemple donné est celui de mock-from-openapi : on entre dans examples/docker-compose/mock-from-openapi, on lance docker compose up, puis on appelle http://localhost:1080/pets. C'est le chemin le plus rapide pour voir le comportement réel sans écrire de configuration.
Le pilotage peut aussi se faire depuis un client Java, JavaScript/Node, Python ou Ruby, avec un support JUnit et Spring, ou depuis Postman et Bruno grâce aux collections fournies dans examples/postman et examples/bruno. Pour un assistant de code, un serveur MCP intégré est exposé sur /mockserver/mcp.
Un détail d'exploitation à ne pas manquer : le README mentionne un état clusterisé optionnel pour les déploiements multi-instances. C'est une phrase, pas une documentation. Si vous prévoyez plusieurs répliques, c'est le point à creuser en premier, car rien dans le matériel fourni ne décrit le mécanisme de partage d'état.
Ce que le projet ne fera pas pour vous
Le proxy peut enregistrer et modifier du trafic TLS chiffré, y compris via le tunneling CONNECT, et propose des points d'arrêt interactifs pour parcourir chaque échange. Cette capacité a un revers : pour inspecter du HTTPS, il faut accepter une autorité de certification intermédiaire dans la chaîne de confiance. Le README ne détaille pas ce point, mais il découle mécaniquement du fonctionnement annoncé. Dans un environnement où les certificats sont gérés par une équipe sécurité distincte, cela peut bloquer l'adoption avant même le premier test.
Autre limite : le produit est écrit en Java. Les clients Python, Ruby ou JavaScript n'exemptent pas d'exécuter la JVM, sauf à passer par l'image Docker ou le bundle binaire sans JVM mentionné dans le guide d'auto-hébergement. Une équipe qui a banni la JVM de sa chaîne d'intégration devra choisir entre revenir sur cette règle et renoncer à MockServer.
Le périmètre fonctionnel très large constitue lui-même un coût. Trois moteurs de template, des callbacks, des webhooks, la simulation de courtiers de messages, le mock de modèles de langage : chaque fonction ajoute de la configuration, des dépendances et des versions à suivre. Une équipe qui n'a besoin que de routes HTTP statiques paiera ce coût sans contrepartie.
Enfin, HTTP/3 est explicitement étiqueté expérimental. Le README ne dit pas ce que cela implique en pratique, ni quelles garanties de stabilité sont offertes. À traiter comme une fonction à valider soi-même, pas comme un acquis.
WireMock, ou la même idée avec une autre répartition des rôles
WireMock est l'alternative la plus directement comparable : un serveur de bouchon HTTP en Java, piloté par une API JSON et utilisé avec les mêmes bibliothèques de test. La différence porte sur le périmètre. WireMock reste centré sur HTTP et HTTPS, avec une extension pour gRPC. MockServer revendique la détection automatique de HTTP/1.1, HTTP/2, gRPC, gRPC-Web, WebSockets et TCP brut sur un port unique, plus la simulation de courtiers de messages et d'API de modèles de langage.
Le second écart concerne le proxy. MockServer en fait une fonction de premier plan, avec enregistrement, modification en vol, points d'arrêt interactifs et injection de pannes. WireMock propose un mode proxy et enregistrement, mais l'injection de latence et d'erreurs y est traitée comme une fonction secondaire plutôt que comme un pilier du produit, du moins dans la façon dont le projet se présente.
Le choix se fait donc sur deux questions. Avez-vous besoin de simuler autre chose que du HTTP ? Si non, WireMock couvre le besoin avec une surface plus réduite. Avez-vous besoin de casser volontairement une dépendance pour observer la réaction de votre application ? Si oui, la partie chaos engineering de MockServer est plus fournie, et le README en fait un usage explicite avec les recettes docker-compose dédiées.
Licence, maintenance et coût de mise à jour
Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le texte de licence, et de signaler les fichiers modifiés. Elle inclut une clause de brevets. Rien dans le matériel fourni n'indique de composant sous licence plus restrictive, mais je n'ai pas d'inventaire des dépendances, donc ce point reste à vérifier de votre côté si la conformité est un sujet.
Le rythme de publication est soutenu. Le dépôt liste trois versions récentes sur une période d'environ six semaines : 7.4.0, 7.5.0 et 7.6.0, cette dernière datée du 17 août 2026. La branche par défaut est master, le dépôt n'est pas archivé, et le dernier push est daté du 9 septembre 2026. Un changelog est maintenu à la racine du dépôt.
Ce rythme a une conséquence pratique : une équipe qui épingle une version devra prévoir du temps pour lire le changelog à chaque montée de version, d'autant que le produit couvre beaucoup de protocoles et de fonctions. À l'inverse, rester sur une version ancienne expose à des écarts de comportement avec la documentation en ligne, qui décrit l'état courant du projet. Le README ne donne aucune politique de support à long terme ni d'engagement de compatibilité entre versions majeures, ce qui est une information manquante pour arbitrer.
Conclusion éditoriale
MockServer convient aux équipes qui doivent simuler plusieurs protocoles à la fois et qui acceptent d'exploiter un composant Java supplémentaire dans leur chaîne de test. Il ne convient pas si vous avez seulement besoin de servir des fichiers statiques sur HTTP ou si personne dans l'équipe ne veut maintenir un processus à part. Avant d'adopter, vérifiez deux choses concrètement : que le multiplexage des protocoles fonctionne avec vos clients réels, et que le mode cluster répond à vos besoins de persistance, car la documentation ne détaille pas ce point.
Notes de la communauté