Premiers pas

Cette section aide un nouvel utilisateur à passer du premier accès à un premier workflow fiable en une seule session. À la fin, tu disposeras d'un modèle de domaine fonctionnel avec des données associées, d'une API GraphQL opérationnelle que tu peux interroger, et d'une compréhension claire des prochaines étapes.

Ce que tu vas construire

Dans ce guide, tu vas :

1. Accéder à Mockomat et choisir ton mode de travail.
2. Créer une table de domaine représentant un concept métier réel.
3. Ajouter des attributs avec les types et associations appropriés.
4. Établir au moins une relation avec une autre entité.
5. Prévisualiser ton modèle via le runtime en direct.
6. Valider que l'API retourne les structures de données attendues.

L'ensemble du processus prend environ 15 minutes.

gs-01-start-entryMissing

Point d'entrée de la page d'accueil vers le workspace applicatif.

Étape 1 : Choisis ton mode d'accès

Mockomat propose deux modes d'accès, chacun conçu pour une phase de travail différente :

Mode invité (démarrage rapide)

Le mode invité est le moyen le plus rapide d'obtenir une API mock fonctionnelle. Aucune inscription, aucune configuration — ouvre simplement Mockomat et commence à modéliser.

Ce que tu obtiens :

• Un projet temporaire dont l'endpoint mock s'ouvre avec son token de partage
• Accès complet au board de modélisation, à la configuration des attributs et à la prévisualisation
• Le même pool de données partagé et les mêmes types d'association que sur tous les forfaits
• Un endpoint GraphQL opérationnel que tu peux interroger immédiatement

Limitations :

• Ton travail reste dans ce navigateur jusqu'à la fin de ta session invité de 24 heures. Les 24 heures courent à partir du début de ta session invité, que l'application démarre à ta première ouverture dans ce navigateur : un projet créé plus tard dispose donc de moins de temps. Un nettoyage qui s'exécute toutes les heures supprime ensuite le projet, qui peut donc rester jusqu'à une heure de plus.
• Effacer les cookies fait perdre ton travail plus tôt ; inscris-toi pour le conserver — l'application propose de déplacer le projet dans ton compte
• Un seul projet à la fois
• Pas de partage en équipe
• Pas de clés API — l'endpoint s'ouvre avec le token de partage du projet

Le mode invité est idéal pour la validation rapide d'idées, les démonstrations et l'évaluation de la pertinence de Mockomat pour ton workflow.

Mode compte (workspace persistant)

Le mode compte ajoute la persistance, la gestion de projets et la possibilité d'évoluer dans le temps.

Ce que tu obtiens (Starter, gratuit) :

• 1 projet sauvegardé (davantage à partir de Professional)
• Modèles persistants qui survivent aux sessions navigateur
• 1 000 requêtes API par jour
• L'aperçu runtime de chaque projet dans l'application (les appels depuis ton propre code nécessitent des clés API — à partir du forfait Professional)

Quand basculer :

• Lorsque ton premier modèle s'avère utile et que tu souhaites le conserver
• Lorsque tu souhaites partager ton travail — via des liens d'aperçu et de collaboration, ou, à partir de Professional, en invitant des membres d'équipe
• Lorsque tu souhaites itérer sur plusieurs sessions

Conseil pour Guest et Starter

Free User

Commence en mode invité pour tester rapidement un scénario de domaine concret. Concentre-toi sur la clarté du nommage, les champs obligatoires et le comportement des données. Si ton modèle tient après quelques requêtes, crée un compte gratuit pour le sauvegarder.

Conseil pour utilisateur registered

Registered User

Passe en mode compte dès que ton premier modèle est utile. La persistance et la répétabilité deviennent plus précieuses que la seule vitesse immédiate. Avec un compte, ton projet reste jusqu'à ce que tu le supprimes, et à partir de Professional tu peux inviter ton équipe.

gs-02-guest-workspaceMissing

Workspace invité avec première table de domaine.

Étape 2 : Modélise une tranche de domaine réelle

Une tranche de domaine est un petit sous-ensemble cohérent de ton modèle métier. Commence par une ou deux entités représentant quelque chose de réel dans ton système.

Choisis des noms significatifs

Évite les noms d'exemples génériques. Utilise le vocabulaire métier que ton équipe emploie déjà :

Bons exemples :

• Customer, Subscription, Invoice
• Order, Payment, Shipment
• Product, Category, Review
• Employee, Department, TimeEntry

À éviter :

• Table1, TestEntity, MyModel
• Data, Item, Thing

Des noms significatifs rendent ton modèle auto-documenté et immédiatement utile pour les discussions d'équipe.

Ajoute des attributs

Chaque entité a besoin d'attributs décrivant ses données. Lors de l'ajout d'attributs, considère :

Propriété	Objectif	Exemple
Nom	Identifiant descriptif	firstName, totalAmount, isActive
Type	Type de données	String, Integer, Boolean, Date
Obligatoire	Doit toujours avoir une valeur	true pour email, false pour middleName
Recherchable	Participe à la recherche searchTerm	true pour name, title

Les indicateurs triable et filtrable ne modifient pas l'API mock : tu peux trier par tout attribut lié à une colonne de données, et le filtrage utilise les paramètres que tu définis sur une opération dans l'API design.

Conseil pratique : Commence avec 4 à 6 attributs essentiels par entité. Tu pourras toujours en ajouter plus tard, mais un modèle focalisé fournit un meilleur retour d'information qu'un modèle large et superficiel.

Choisis les associations de données

Chaque attribut a besoin d'une source de données. Mockomat supporte trois types d'association :

Source de données (SOURCE) — Données importées

Lie l'attribut à une colonne du pool de données partagé — des jeux de données importés : des données ouvertes là où une source vérifiée existe, des données d'exemple générées pour les blueprints. Le runtime sert les lignes importées et n'invente jamais de valeurs. Idéal pour les noms, adresses, données produit, catégories, dates et montants.

Constante (CONSTANT) — Valeurs fixes

Fixe une valeur unique sur l'attribut, par ex. un statut par défaut ("active"). Le runtime la retourne sur chaque ligne, aussi bien sur les lignes de données importées que sur les lignes composées à partir de pools de valeurs.

Calculé (COMPUTED) — Expressions

Enregistre une expression sur d'autres champs, par ex. un nom complet à partir du prénom et du nom. Le runtime n'évalue pas les expressions : un champ calculé ne fait donc pas partie de la réponse. L'éditeur d'attributs ne propose plus Calculé ; un attribut qui a déjà une association calculée la conserve et est signalé comme non évalué.

gs-03-first-tableMissing

Création de la première table et configuration des attributs.

Établis une relation

Une fois une entité modélisée, ajoute-en une seconde et connecte-les :

1. Crée une seconde table (ex. Order, si ta première était Customer).
2. Définis le type de relation : un client a-t-il plusieurs commandes (1:n) ? Une commande appartient-elle à exactement un client ?
3. Établis la direction : quelle entité possède la relation ?

Les relations sont essentielles pour tester comment ton API gère les données imbriquées. Un modèle avec au moins une relation te fournit un retour d'information nettement plus riche en prévisualisation.

gs-03b-first-relationMissing

Première configuration de relation entre deux entités.

Étape 3 : Valide via la prévisualisation

La prévisualisation n'est pas uniquement destinée aux démonstrations. C'est un point de contrôle qualité du modèle. Chaque fois que tu modifies ton modèle, exécutes une prévisualisation pour confirmer que le changement se comporte comme attendu.

Ce qu'il faut vérifier

Lisibilité des champs — Les noms de champs retournés ont-ils du sens ? Sont-ils cohérents (camelCase partout, pas d'abréviations) ?

Cohérence de la structure de données — Chaque champ retourne-t-il le type attendu ? Les chaînes sont-elles bien des chaînes, les nombres bien des nombres ?

Comportement des relations — Lorsque tu interroges une entité parente, les entités enfants apparaissent-elles correctement imbriquées ? La cardinalité est-elle correcte (tableau pour 1:n, objet unique pour 1:1) ?

Signaux d'association manquante — Si une table n'est pas liée à des données importées, la prévisualisation l'indique et l'API ne renvoie aucune ligne pour elle. Lie la table avant de continuer.

Comportement des filtres et du tri — Essaie un paramètre que tu as défini sur l'opération, et trie par un attribut avec sortField. Les résultats ont-ils du sens ?

Problèmes courants de prévisualisation

Problème	Cause probable	Solution
Un champ retourne null	Aucune association configurée	Lier l'attribut à une colonne de données (association Source de données)
Une relation retourne un tableau vide	Relation mal définie	Vérifier la direction de la relation et l'entité cible
Le tri n'a aucun effet	sortField n'est pas le nom d'un attribut associé	Utiliser le nom d'un attribut lié à une colonne de données
Le filtre retourne tous les enregistrements	L'opération ne définit aucun paramètre pour cet argument	Ajouter le paramètre dans l'API design

gs-04-first-previewMissing

Première prévisualisation avec champs associés et non associés.

Étape 4 : Interroge ton API

Une fois la prévisualisation correcte, ton API mock est déjà opérationnelle. Appelle-la depuis n'importe quel client GraphQL ou HTTP avec une clé API du projet — les clés API sont incluses à partir du forfait Professional. Un projet invité utilise à la place son token de partage (?token=…). Les détails sont dans Intégrateurs.

L'endpoint de ton projet est :

POST /mock/{ton-slug-projet}/graphql
Authorization: Bearer mck_your_api_key

Essaie une requête de liste simple :

query {
  customers(page: 1, pageSize: 10) {
    items {
      id
      firstName
      lastName
      email
      orders {
        id
        totalAmount
        createdAt
      }
    }
    total
  }
}

La réponse contient les lignes importées vers lesquelles pointent tes associations, avec les relations automatiquement résolues.

gs-04b-first-queryMissing

Première requête GraphQL contre l'endpoint mock opérationnel.

Étape 5 : Détermine la suite

Après ton premier cycle modèle-requête réussi, plusieurs directions s'offrent à toi :

• Approfondir ton modèle — ajouter plus d'entités, affiner les attributs, établir d'autres relations.
• Configurer l'exposition API — définir quelles opérations sont disponibles, établir les conventions de nommage des requêtes.
• Aller vers l'export — si le modèle est suffisamment stable, explorer la génération de code pour obtenir un backend NestJS prêt pour la production.
• Utiliser des blueprints — explorer les modèles de domaine préconfigurés pour accélérer les projets futurs.
• Partager avec ton équipe — créer un compte (si en mode invité) et inviter des collaborateurs.

Conseil pour utilisateur paid

Paid User

Après la première validation, standardise le nommage de tes tables et ta stratégie d'opérations. Cela facilite la collaboration et la gouvernance par la suite. Définis les conventions tôt — elles gagnent en valeur à mesure que le projet grandit.

Conseil pour utilisateur enterprise

Enterprise User

Traite le premier workflow comme un projet pilote. Définis tôt les conventions (nommage, responsabilité, critères de validation) et réutilise-les entre équipes. Un pilote bien structuré devient le modèle de chaque projet suivant.

gs-05-next-stepsMissing

Point de décision après le premier cycle de prévisualisation réussi.

Ce que tu as maintenant

À l'issue de ce guide, tu disposes de :

• Un modèle de domaine avec au moins une entité, des attributs significatifs et des associations de données configurées
• Un endpoint d'API GraphQL opérationnel retournant des lignes du pool de données
• La confirmation que ton modèle se comporte comme attendu lors de requêtes réelles
• Une compréhension claire du workflow Modèle → Prévisualisation → Requête

À partir d'ici, explore les Concepts clés pour comprendre l'architecture derrière ce que tu viens de créer, ou plonges dans le Workspace pour un guide détaillé des outils de modélisation.