Enterprise
Enterprise est le forfait des organisations qui dépassent Business : plus de membres d'équipe, aucune limite de catalogue pour les projets et les requêtes, et des limites qui peuvent être adaptées à ton contrat. Cette page explique ce que comprend le forfait, comment Mockomat sépare ton compte des autres et comment garder une modélisation de domaine cohérente entre plusieurs équipes.
Obtenir Enterprise
Enterprise se négocie avec notre équipe commerciale et ne s'achète pas en ligne. Utilise Parler à un commercial dans l'application ou le formulaire de contact ; prix sur demande.
Ce que comprend Enterprise
- Tout ce que comprend Business : clés API, rôles d'équipe, export de code, analytique des endpoints.
- Aucune limite de catalogue pour les projets, workspaces, requêtes API mensuelles, clés API par projet, tables, attributs, relations, opérations et notes du board.
- Jusqu'à 26 membres d'équipe, dont 5 mainteneurs.
- Le package de code Enterprise : l'export de code génère un backend NestJS et un frontend Angular (voir Export).
- Des limites adaptées à ton contrat : notre équipe règle les limites de ton compte sur ce que tu as convenu avec le service commercial.
Pour les limites des autres forfaits, voir Compte et forfaits.
Vue d'ensemble du modèle d'accès au compte et aux projets.
Comment ton compte est séparé
Enterprise utilise la même plateforme que tous les autres forfaits. Ces frontières s'appliquent à chaque compte :
- Ton compte est la frontière. Les projets, modèles, membres, clés API et limites du forfait appartiennent à ton compte. Chaque requête est vérifiée par rapport à lui : les membres d'autres comptes ne peuvent pas ouvrir tes projets.
- Accès aux projets par membre. Les mainteneurs voient tous les projets du compte. Les autres membres voient les projets auxquels ils ont reçu l'accès lors de l'invitation, avec en option une surcharge par projet qui peut restreindre leur rôle, mais jamais l'élever.
- Une clé API par consommateur. Chaque projet d'un compte ne répond sur son API mock qu'aux requêtes munies d'une clé API de ce projet. Les clés peuvent être révoquées à tout moment.
- Données mock partagées, en lecture seule. L'API mock sert des lignes du pool de données de Mockomat, que notre équipe importe et maintient. Tes requêtes ne font que le lire, et il est le même sur tous les forfaits. Tu ne peux pas téléverser tes propres jeux de données.
Frontières du compte, des projets et des données.
Équipe et rôles
| Rôle | Ce qu'il ajoute |
|---|---|
| Lecture seule | Voit les projets, le modèle et l'aperçu des données ; lit les notes du board |
| Rapporteur | Écrit et modifie les notes du board et leurs commentaires |
| Éditeur | Construit le modèle, crée des projets, gère les clés API, lance l'export de code |
| Mainteneur | Supprime des projets, gère les membres et leur accès aux projets, gère les workspaces |
Chaque rôle comprend tout ce que permettent les rôles au-dessus de lui. Le propriétaire du compte est mainteneur et gère la facturation. La liste complète des permissions et le déroulement des invitations se trouvent dans Team & Roles (en anglais).
Gestion des membres de l'équipe et attribution des rôles.
Sessions et consommateurs externes
- Sessions de connexion : sur 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, et une connexion ailleurs met fin à leur session précédente. Tout le monde est déconnecté automatiquement après une période sans activité.
- Consommateurs de l'API : chaque requête à l'API mock porte une clé API du projet. Utilise une clé par consommateur ou par environnement (développement, staging, CI) pour pouvoir en révoquer une sans toucher aux autres.
- Tokens d'acteur (optionnels) : un consommateur peut demander un token d'acteur afin que l'utilisation simultanée d'une clé API puisse être plafonnée. Voir la section « Tokens d'acteur » de la page Intégrateurs.
Modèle de gouvernance
Une approche de gouvernance pragmatique garde la modélisation de domaine cohérente à mesure que de nouvelles équipes arrivent.
Responsabilité des domaines
Attribue une responsabilité claire pour chaque domaine métier :
- Responsable de domaine — responsable du nommage des entités, de la définition des attributs et de la stratégie de relations dans son domaine.
- Relecteurs — membres de l'équipe qui vérifient les changements avant que les consommateurs s'y fient (le rôle Rapporteur convient).
- Consommateurs — développeurs frontend et intégrateurs qui interrogent l'API mock sans modifier le modèle (le rôle Lecture seule convient).
Conventions de nommage partagées
Définis des standards à l'échelle de l'organisation pour :
- Le nommage des entités — PascalCase, noms au singulier, langage métier (par ex.
Customer, pascustomers_tbl) - Le nommage des attributs — camelCase, descriptif, sans abréviations (par ex.
totalAmount, pastot_amt) - Le nommage des relations — direction et cardinalité claires
- Le nommage des opérations — noms au pluriel cohérents pour les opérations de liste, au singulier pour les opérations de détail
Garde un projet de référence qui suit ces conventions et copie-le avec Forker un projet comme point de départ des nouveaux projets.
Points de contrôle de revue
| Étape | Objet de la revue | Qui relit |
|---|---|---|
| Changement de modèle | Cohérence du nommage, complétude des attributs, justesse des relations | Responsable de domaine |
| Changement d'exposition API | Opérations, paramètres, tailles de page | Responsable de domaine + intégrateur |
| Avant l'export | Comportement runtime, paramètres, tri, relations | Responsable de domaine + QA |
| Après l'export | Code généré, limites des modules, entrées | Responsable de l'équipe de développement |
Critères de disponibilité
Définis ce que « prêt » signifie pour chaque entité avant que les consommateurs en dépendent :
- Chaque attribut dont les consommateurs ont besoin est lié à une colonne des données importées
- Les relations se résolvent dans l'aperçu
- Les paramètres d'opération et le tri renvoient les lignes attendues
- La pagination produit des limites de page nettes
Contrôles de gouvernance à travers les étapes de modélisation et de runtime.
Sécurité
- Connexion : l'application utilise un token signé par session de connexion. La déconnexion, l'inactivité et un changement de mot de passe mettent fin aux sessions côté serveur.
- Clés API : les clés sont des secrets. Utilise-les depuis du code côté serveur, depuis la CI ou via un proxy — ne livre jamais une clé dans un bundle frontend — et révoque une clé dès qu'elle n'est plus nécessaire.
- Trafic chiffré : l'application et l'API mock sont servies en HTTPS.
- Aucune donnée de production nécessaire : les API mock servent des lignes du pool de données de Mockomat ; tes environnements de test n'ont donc jamais besoin de vraies données clients.
Vue d'ensemble de la sécurité.
Bonnes pratiques opérationnelles
- Définis des critères de disponibilité par entité avant de l'attribuer à une équipe.
- Intègre des vérifications runtime aux revues — lance l'aperçu avant que les consommateurs dépendent d'un changement.
- Exporte à des jalons — garde le code généré sous contrôle de version et note de quel état du modèle il provient.
- Surveille l'usage — consulte l'analytique des endpoints pour voir quelles opérations les consommateurs appellent avant de les modifier.
- Revois régulièrement — garde les définitions de domaine alignées sur l'évolution des besoins métier.
Validation runtime enterprise et points de contrôle opérationnels.