Glossaire
Une référence complète des termes, concepts et vocabulaire technique utilisés dans la documentation Mockomat. Les termes sont regroupés par catégorie et triés alphabétiquement au sein de chaque groupe.
Plateforme & Produit
Blueprint Un projet Mockomat prêt à l'emploi pour un domaine courant (Utilisateurs & Profils, E-Commerce, Voitures & Véhicules, Immobilier, Meubles & Décoration, Alimentation & Restaurants). Les blueprints peuvent être clonés dans un workspace et adaptés. Voir Blueprints.
Domain Model (modèle de domaine) La fondation sémantique d'un projet. Définit les entités, attributs et relations qui décrivent la structure et le sens de tes données avant toute décision d'API ou d'implémentation.
Domain Slice (tranche de domaine) Un petit sous-ensemble cohérent de ton modèle métier — typiquement une ou deux entités liées utilisées comme point de départ pour la modélisation.
Mockomat Une plateforme SaaS multi-tenant pour la modélisation de domaine, la simulation d'API mock et la génération de code backend. Les utilisateurs définissent des schémas visuellement, associent des données et obtiennent instantanément des APIs GraphQL opérationnelles.
Project (projet) Une définition d'API mock : un modèle de domaine, ses associations de données et sa configuration d'API. Chaque projet a un slug unique et son propre endpoint d'API mock.
Workspace (espace de travail) Un groupe de projets dans ton compte. Chaque compte a un workspace ; à partir de Professional, tu peux en créer d'autres. La section Workspace de cette documentation couvre le board de modélisation, l'éditeur de tables, la vue de conception API et l'aperçu runtime.
Modélisation
Attribute (attribut) Un champ d'une table. Chaque attribut a un nom, un type (par ex. String, Integer, Float, Boolean, Date, JSON, Enum), une association de données et des indicateurs comme obligatoire et recherchable.
Cardinality (cardinalité) La relation quantitative entre entités : un-à-un (1:1), un-à-plusieurs (1:n), ou plusieurs-à-plusieurs (m:n).
Entity / Table (entité / table) Un concept métier central représenté dans le modèle (ex. Customer, Order, Invoice). Visualisé comme une carte de table sur le board de modélisation.
Filterable (filtrable) Un indicateur d'attribut enregistré avec le modèle. Le runtime mock ne le lit pas : le filtrage utilise les paramètres d'une opération (voir API Design (en anglais)).
Hint (indication) Un message dans l'aperçu runtime qui explique pourquoi une table n'affiche pas de données ou quoi configurer ensuite — par exemple, qu'une table n'est pas associée à des données importées.
Modelling Board (board de modélisation) Le canevas visuel dans le workspace où les entités sont créées, positionnées et connectées par interaction glisser-déposer.
Naming Convention (convention de nommage) Patterns standardisés : PascalCase singulier pour les entités (ex. Customer), camelCase pour les attributs (ex. firstName).
Relation Une connexion entre deux entités qui définit comment les données circulent entre elles. A une direction (source → cible) et une cardinalité (1:1, 1:n, m:n).
Required (obligatoire) Un indicateur d'attribut signalant que le champ doit avoir une valeur. L'export OpenAPI le liste comme propriété requise.
Searchable (recherchable) Un indicateur d'attribut qui inclut le champ dans la recherche searchTerm, insensible à la casse, des opérations de liste.
Sortable (triable) Un indicateur d'attribut enregistré avec le modèle et utilisé pour les colonnes de liste de l'export de code. Le runtime mock ne le lit pas : sortField accepte tout attribut lié à une colonne de données.
Table Card (carte de table) La représentation visuelle d'une entité sur le board de modélisation, affichant le nom de la table, les colonnes, les indicateurs de relation et les boutons d'action.
Table Editor (éditeur de table) Le panneau de configuration qui s'ouvre lors de la sélection d'une table sur le board de modélisation, fournissant la configuration détaillée des attributs et des relations.
Sources de données & association
COMPUTED Un type d'association qui enregistre une expression sur d'autres champs du même enregistrement. 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é.
CONSTANT Un type d'association qui fixe une valeur unique sur un attribut (ex. "active" pour un champ de statut) ; 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.
Data Mapping (association de données) La configuration qui lie un attribut d'entité à une source de données, déterminant quelles valeurs le champ retourne au runtime.
Data Object (objet de données) Une colonne d'une table du pool de données de Mockomat, proposée dans le panneau d'association quand tu lies un attribut avec une association SOURCE.
Dataset (jeu de données) Un ensemble de données que Mockomat importe dans son pool de données — des données ouvertes là où une source vérifiée existe, des données d'exemple générées pour les blueprints ; les attributs lisent ses colonnes via des associations SOURCE.
SOURCE (source de données) Un type d'association qui lie un attribut à une colonne des jeux de données importés du pool de données de Mockomat ; le runtime sert les lignes importées et n'invente jamais de valeurs.
Value Pool (pool de valeurs) Une table de valeurs sans contexte (prénoms, rues) à partir de laquelle d'autres tables composent leurs lignes — des combinaisons cohérentes, jamais de valeurs inventées.
API & GraphQL
API Contract (contrat API) La spécification formelle des noms de requêtes, structures de champs et disponibilité des opérations dont les consommateurs externes dépendent.
API Design View (vue de conception API) Une zone du workspace où les utilisateurs contrôlent quelles opérations GraphQL sont exposées et comment les requêtes sont nommées.
Code-First GraphQL L'approche utilisée par Mockomat où les schémas GraphQL sont générés à partir des définitions de modèle et des décorateurs plutôt qu'écrits manuellement comme fichiers SDL.
Detail Query (requête de détail) Une requête GraphQL qui retourne un seul enregistrement par son identifiant (ex. product(id: "abc-123")).
Dynamic Schema Generation (génération dynamique de schéma) Le processus par lequel Mockomat génère un schéma GraphQL entièrement typé à la volée à partir des définitions de modèle d'un projet.
Endpoint Le chemin URL où les consommateurs interrogent une API mock : POST /mock/{slug}/graphql.
Filter Expression (expression de filtre) Un filtre de portée ou un paramètre d'opération qui affine les résultats de requête. Toutes les conditions d'une opération se combinent avec AND.
Filter Operator (opérateur de filtre) Une comparaison utilisée par les paramètres et les filtres de portée : eq, neq, gt, gte, lt, lte, in, like ; les filtres de portée aussi notIn, isNull, isNotNull.
GraphQL Le langage de requête et pattern de conception API utilisé par Mockomat pour l'API de gestion et les endpoints mock runtime.
List Query (requête de liste) Une requête GraphQL qui retourne une collection paginée d'enregistrements avec filtrage et tri optionnels (ex. products(page: 1, pageSize: 20) { items { … } total }).
Page-Based Pagination (pagination par pages) La méthode de pagination utilisée par Mockomat : page (numéro de page, à partir de 1) + pageSize (enregistrements par page, 100 au maximum).
Operation Exposure (exposition des opérations) La configuration de quelles opérations GraphQL (liste, détail) sont disponibles pour chaque entité.
Query Naming (nommage des requêtes) Le nommage personnalisé des points d'entrée GraphQL — les requêtes de liste utilisent par défaut le pluriel (ex. products), les requêtes de détail le singulier (ex. product).
Slug / Project Slug Un identifiant URL-safe pour un projet utilisé dans le chemin de l'endpoint API (ex. customer-portal → /mock/customer-portal/graphql).
Runtime
Aggregation Pipeline (pipeline d'agrégation) Le framework de traitement de données multi-étapes de MongoDB, utilisé par le query builder du runtime pour exécuter les requêtes, filtres, tris et lookups de relations.
Mock Runtime / Runtime Engine (moteur de mock runtime) Le moteur central qui accepte les requêtes GraphQL et les traduit en opérations MongoDB via une pipeline en quatre étapes : parse → plan → build → assemble.
MongoDB Query Builder La troisième étape de la pipeline runtime qui traduit un plan d'exécution en pipeline d'agrégation MongoDB.
Preview (prévisualisation) L'interface runtime intégrée où les utilisateurs testent leur modèle avec des requêtes en direct et inspectent les données de réponse avec les indications de disponibilité.
Query Planner (planificateur de requêtes) La deuxième étape de la pipeline runtime qui analyse une requête parsée conjointement avec les métadonnées du modèle pour créer un plan d'exécution.
Relation Traversal (traversée des relations) La capacité du runtime à simuler des données relationnelles à partir de collections MongoDB plates en construisant des étapes de lookup dans la pipeline d'agrégation.
Request Parser / GraphQL Request Parser (parseur de requêtes) La première étape de la pipeline runtime qui parse une chaîne de requête entrante en un arbre syntaxique abstrait (AST).
Result Assembler (assembleur de résultats) La quatrième étape de la pipeline runtime qui restructure les résultats MongoDB dans la structure de réponse GraphQL attendue.
Runtime Validation (validation runtime) Le processus de confirmation que les décisions de domaine et d'API d'un modèle se comportent correctement sous une exécution de requêtes réelle.
Views (vues) Différentes perspectives sur le même modèle — vue du board, vue de détail de table, vue de conception API, prévisualisation runtime — navigables via des liens croisés.
Export & génération de code
Code Generation / Codegen (génération de code) Le processus automatisé de création d'un projet backend fonctionnel à partir d'un modèle de domaine Mockomat.
DTO (Data Transfer Object) Les classes d'entrée de création et de mise à jour d'un backend généré, une paire par table, avec des décorateurs class-validator.
Export La fonctionnalité qui exporte un projet sous forme de spécification OpenAPI ou, à partir de Professional, de package de code NestJS généré. Le code généré appartient à l'utilisateur. Voir Export.
Generated Backend (backend généré) Le projet NestJS d'un package de code — un module par table avec entité, resolver, service et types d'entrée, plus l'authentification et la configuration.
NestJS Le framework Node.js des backends générés. Le code généré suit les conventions NestJS standard.
Resolver La couche d'API GraphQL du code NestJS généré : les requêtes et mutations d'une table.
TypeORM La bibliothèque ORM (Object-Relational Mapping) des backends générés ; les entités générées ciblent MySQL / MariaDB.
Authentification & sécurité
Actor Token (token d'acteur) Un token optionnel à durée limitée qui distingue les consommateurs d'une même clé API pour le suivi de concurrence. Envoyé dans l'en-tête X-Actor-Token.
API Key (clé API) Un identifiant émis par projet pour authentifier les consommateurs externes auprès de l'API mock de ce projet — obligatoire pour chaque projet d'un compte. Envoyé dans l'en-tête Authorization: Bearer (ou X-API-Key) ; les clés API sont incluses à partir du forfait Professional.
Concurrent Session (session concurrente) Le fait d'être connecté sur plus d'un appareil ou navigateur en même temps. Sur Starter, un compte ne peut être connecté qu'à un seul endroit à la fois : une connexion ailleurs met fin à la session précédente. Sur Professional, Business et Enterprise, le propriétaire du compte peut rester connecté sur plusieurs appareils à la fois. Les membres invités n'en bénéficient pas grâce au compte qu'ils rejoignent : ils ne peuvent être connectés qu'à un seul endroit à la fois, sauf s'ils possèdent eux-mêmes un compte dont le forfait en permet davantage.
JWT (JSON Web Token) Un format de token utilisé pour l'authentification sans état dans l'API de gestion Mockomat.
Private Endpoint (endpoint privé) Un endpoint d'API mock qui nécessite une authentification par clé API — l'endpoint de chaque projet d'un compte.
Public Endpoint (endpoint public) Un endpoint d'API mock accessible sans clé API. Seuls les projets invités en ont un : il s'ouvre avec le token de partage du projet et est soumis à une limitation de débit par IP.
Rate Limiting (limitation de débit) Les limites des requêtes à l'API mock : une limite par adresse IP et le quota de requêtes de ton forfait (par jour ou par mois civil). Toutes deux répondent HTTP 429 (Too Many Requests) en cas de dépassement ; la limite par IP envoie en plus un en-tête Retry-After.
Session Une connexion sur un appareil ou un navigateur. Une session se termine quand tu te déconnectes, après une période sans activité ou quand ton mot de passe change.
Forfaits & accès
Business (forfait) Un niveau payant, facturé mensuellement, qui étend Professional avec des équipes plus grandes, davantage de mainteneurs et l'analytique d'endpoints.
Enterprise (forfait) Un niveau négocié avec notre équipe commerciale (prix sur demande, sans paiement en libre-service) ; ses limites — projets, requêtes, taille de l'équipe — sont ajustées par contrat.
Guest (forfait) Le niveau instantané sans connexion offrant un projet temporaire basé sur la session, dont l'endpoint s'ouvre avec son token de partage. Le travail est conservé dans le navigateur pendant une durée limitée ; à l'inscription, l'application propose de le déplacer dans ton compte.
Professional (forfait) Un niveau payant, facturé mensuellement, offrant des endpoints privés, des clés API, un accès d'équipe basé sur les rôles et un quota mensuel de requêtes.
Starter (forfait) Le niveau gratuit nécessitant l'inscription d'un compte, avec des projets persistants et un quota quotidien de requêtes dans l'application ; appeler l'API mock depuis ton propre code nécessite des clés API (à partir de Professional).
Les limites actuelles de chaque forfait figurent sur la page des tarifs et dans Compte et forfaits.
Équipe & gouvernance
Domain Ownership (propriété de domaine) Responsabilité assignée pour un domaine métier spécifique et ses définitions de modèle au sein de l'équipe.
Éditeur (editor) Un rôle de workspace qui construit le modèle, crée des projets, gère les clés API et lance l'export de code. Comprend tout ce que peut faire un Rapporteur.
Équipe du tenant Les membres de ton compte et leurs rôles de workspace, gérés sous Compte → Tenant → Équipe. Voir Team & Roles (en anglais).
Governance (gouvernance) Politiques et contrôles garantissant la cohérence et la qualité à travers les efforts de modélisation de l'équipe — conventions de nommage, points de contrôle de revue et critères de validation.
Lecture seule (readonly) Un rôle de workspace qui voit les projets, le modèle et l'aperçu des données, et lit les notes du board.
Mainteneur (maintainer) Un rôle de workspace qui ajoute à tout ce que peut faire un Éditeur la suppression de projets, la gestion des membres et de leur accès aux projets, ainsi que la gestion des workspaces. Les mainteneurs voient tous les projets du compte.
Multi-Tenancy (multi-location) L'architecture qui sépare les projets, modèles, membres et la configuration de chaque compte grâce à un accès limité au compte. Les données mock proviennent du pool partagé en lecture seule.
Propriétaire La personne qui a créé le compte. Le propriétaire détient une adhésion de Mainteneur, gère la facturation et ne peut pas être retiré du compte.
Rapporteur (reporter) Un rôle de workspace qui ajoute les notes du board et les commentaires à tout ce que peut faire un membre en Lecture seule.
Review Gate (point de contrôle de revue) Un checkpoint où les changements de modèle, d'API ou d'export sont validés avant que les consommateurs s'y fient — ex. validation runtime avant un export.
Tenant (locataire) Une limite organisationnelle isolée avec ses propres membres, projets, clés API, sa configuration et ses limites de forfait. Les données mock proviennent du pool partagé en lecture seule.
Infrastructure & déploiement
Docker Technologie de conteneurisation. Un package de code contient un fichier Docker Compose qui démarre MySQL et Redis pour le backend généré, mais aucun Dockerfile pour le backend lui-même ; ajoute-en un pour ta plateforme cible afin de l'exécuter dans un conteneur (voir Export).