Aller au contenu
Lioncore
7 min de lecture

Mocksmith : l'API mock que je voulais sur chaque projet

Le front est prêt, le back n'existe pas encore. Mocksmith forge la spec depuis une description ou un builder visuel, puis sert de vrais endpoints CRUD. Mon premier produit avec une vraie facturation.

mocksmithindieproduitapideveloppeur

Le problème que je croise sur presque chaque projet

Le scénario revient sans arrêt : le front est prêt à consommer une API, mais le back n'existe pas encore. Le contrat n'est pas figé, l'équipe back est sur autre chose, ou je suis seul et je n'ai juste pas envie de tout construire dans l'ordre. Résultat, on bricole. Un fichier JSON figé qu'on importe à la main, un faux serveur Express codé pour l'occasion, des données en dur dans le composant, ou pire : on attend que le vrai back arrive.

Chacune de ces rustines a le même défaut. Elle ne fait pas de CRUD : tu ne peux pas vraiment créer, modifier, supprimer et voir l'état changer. Et elle ne tient pas dans le temps : dès que le besoin grossit, la rustine devient un projet à maintenir en parallèle.

Page d'accueil de Mocksmith : « Describe your API. It already exists. »
Page d'accueil de Mocksmith : « Describe your API. It already exists. »

La grille dit Painkiller

Avant de coder, je passe toujours mon idée dans ma grille de validation. Pour Mocksmith, le verdict est immédiat.

QuestionRéponse
Le problème est-il réel et fréquent ?Oui, je le vis sur la quasi-totalité de mes projets
Des gens paient déjà pour résoudre ça ?Oui, le mock d'API est un marché établi (Mockoon, Beeceptor, Postman)
La promesse tient en une phrase ?"Décris ton API, elle existe déjà"

Un Painkiller pour développeurs, et comme pour Calmora, l'utilisateur numéro un, c'est moi. La différence avec Inkindly, que j'avais abandonné parce que le sujet ne me parlait pas : là, je suis exactement dans mon domaine. Des développeurs front qui attendent un back, je sais où ils traînent et je parle leur langue.

Ce que fait Mocksmith

Mocksmith part d'une spec et en fait une API qui marche. Deux façons d'arriver à cette spec :

  • Le builder visuel : tu déclares tes ressources, tes champs, leurs types parmi 94 générateurs (nom, email, pays, date passée, URL d'avatar, entier, flottant...), avec des plages de valeurs, des constantes, des regex de conformité et des relations entre ressources.
  • La description en langage naturel (plan Pro) : tu écris ce que tu veux, l'IA forge la spec, et tu la corriges si besoin.

À partir de là, Mocksmith sert des endpoints CRUD complets, avec pagination et protection optionnelle par clés Bearer :

GET    /m/:slug/users?page=1&limit=20
GET    /m/:slug/users/:id
POST   /m/:slug/users
PUT    /m/:slug/users/:id
PATCH  /m/:slug/users/:id
DELETE /m/:slug/users/:id

Du texte aux endpoints : une description en langage naturel transformée en spec et en routes CRUD.
Du texte aux endpoints : une description en langage naturel transformée en spec et en routes CRUD.

Deux chemins strictement séparés

Le cœur de l'architecture tient dans une séparation que je me suis imposée dès le départ : la génération et le service ne partagent rien.

CheminQuandVitesseLLM
GénérationUne fois, à la créationLent, ça n'a pas d'importanceOui (plan Pro), seul point d'appel
RuntimeÀ chaque requête mockRapide, déterministeJamais

Concrètement : quand ton front tape GET /m/:slug/users, aucune IA n'est sollicitée. Mocksmith lit la spec et les données déjà matérialisées en base, applique le CRUD et répond. Le LLM n'intervient qu'au moment où tu forges la spec, jamais quand tu consommes l'API. C'est ce qui rend les réponses rapides, prévisibles et gratuites à servir.

Des données réalistes et stables

Le piège classique du mock, c'est la donnée qui change à chaque rechargement : impossible d'écrire un test dessus. Mocksmith génère ses données avec un faker seedé et résout les regex de manière déterministe. La même spec rend toujours exactement les mêmes données. Un POST crée vraiment un enregistrement, un DELETE le supprime vraiment, et l'état persiste entre les requêtes. Le front se comporte comme face à un vrai back, sans la surprise d'un jeu de données qui se réécrit tout seul.

Les fonctionnalités de Mocksmith pensées pour le quotidien du développement front-end.
Les fonctionnalités de Mocksmith pensées pour le quotidien du développement front-end.

Mon premier vrai pricing

Calmora n'est pas sortie, Inkindly a été abandonné. Mocksmith est le premier projet que je pousse jusqu'à la facturation, branchée sur Stripe.

FreePro
Builder visuel, 94 types, CRUD, pagination, clés BearerOuiOui
Projets2Illimités
Génération par IA depuis une descriptionNonOui
Simulation réseau (latence, erreurs aléatoires)NonOui
Réponses épinglées par endpointNonOui
Prix0 €2,99 € / mois

Le plan gratuit est volontairement utilisable pour de vrai : tout le flux builder, CRUD et clés d'API marche sans payer. Le gating de l'IA est appliqué côté serveur, pas seulement masqué dans l'UI.

Ce que Mocksmith n'est pas

Ce n'est pas un remplacement de ton back de production, ni un outil de contract testing, ni une passerelle d'API. C'est un échafaudage : il tient pendant que le vrai back se construit, et il dégage quand celui-ci est prêt. La promesse s'arrête là, et c'est volontaire.

La suite

Mocksmith est en ligne sur mocksmith.lioncore.dev, la fiche complète est sur la page projet. Pour une fois, je n'attends pas un signal pour publier : c'est déjà fait. Si tu testes l'app et que tu butes sur un cas que Mocksmith ne couvre pas encore, écris-moi, c'est exactement ce qui oriente la suite.


Partagerfr