Créer un modèle personnalisé
Cette page explique comment créer un modèle personnalisé (Custom Model) dans Artemis AppFlow, quels sont les champs disponibles dans le dialogue de création et ce qui se passe après l'enregistrement. Elle clarifie aussi la différence entre la création du modèle lui‑même et la création de ses attributs, qui se fait uniquement depuis la page du modèle (et non dans le dialogue de création initiale).

Quand créer un modèle personnalisé ?
Créez un modèle personnalisé lorsque vous avez besoin de représenter un nouvel objet métier (ex. : Produit, Salle, Événement, Abonnement). Un modèle définit :
- Son identité (nom + slug)
- Sa position éventuelle dans une hiérarchie (parent)
- Son ou ses locataires (tenants) cibles
- Sa liste d'attributs (créés après coup)
Accéder au dialogue de création
- Ouvrez la page des modèles personnalisés via le menu de côté.
- Cliquez sur le bouton « Nouveau modèle personnalisé ».
- Le dialogue de création s'ouvre avec les champs décrits ci‑dessous.
Note : Aucune définition d'attribut n'est possible à cette étape. Vous ne faites ici que définir l'enveloppe structurelle du modèle.
Champs du formulaire
Nom
Champ texte obligatoire.
Le nom :
- Sert d'étiquette lisible dans l'interface.
- Peut contenir des espaces, lettres accentuées et majuscules.
- Doit être unique dans son contexte fonctionnel (bonne pratique : ne pas réutiliser le même nom pour deux concepts différents, même si la plateforme ne l'interdit pas explicitement selon la configuration).
Bonnes pratiques pour le nom
- Utiliser le singulier (« Produit », « Salle », « Commande ») sauf cas spécifiques.
- Éviter les abréviations obscures.
- Rester cohérent avec la terminologie métier déjà employée.
Slug
Champ texte obligatoire.
Le slug :
- Sert d'identifiant technique stable (ex. :
produit,salle-evenement,commande_client). - Doit être unique et immuable autant que possible après création (éviter de le modifier, car il est souvent utilisé dans des références ou intégrations).
- N'accepte généralement que : minuscules, chiffres, tirets (
-) ou underscores (_) selon la convention projet (recommandé : minuscules + tirets).
Recommandations de génération
- Partir du nom : « Produit vedette » →
produit-vedette. - Retirer accents & caractères spéciaux : « Événement » →
evenement. - Remplacer espaces par tirets.
Astuce : Si le slug est déjà pris, ajoutez un suffixe descriptif plutôt qu'un simple chiffre arbitraire (ex.
produit-digitalplutôt queproduit2).
Parent
Menu déroulant à sélection simple (optionnel) définissant un lien d'héritage.
Le modèle sélectionné comme parent joue le rôle de « base » : le nouveau modèle hérite automatiquement des attributs (existants) du parent. Ces attributs hérités :
- S'affichent dans la page du modèle enfant dans un tableau en lecture seule.
- Ne nécessitent aucune ressaisie lors de la création du modèle enfant.
- Sont mis à jour automatiquement si un attribut du parent est modifié (nom, validation, type) – selon les règles de compatibilité de votre projet.
- Ne peuvent pas être supprimés depuis l'enfant (la suppression se fait au niveau du parent et impacte tous ses enfants).
Le modèle enfant peut ajouter ses propres attributs spécifiques en plus de ceux hérités.
Différence avec une simple relation
Une relation (ex. référence ou lien) se configure via un attribut de type « référence » entre deux modèles existants. L'héritage, lui :
- Introduit un partage structurel de schéma.
- Fournit un point central de maintenance (modifier une seule fois le parent pour propager).
- Permet d'imposer des champs communs normalisés (timestamps, état, identifiants externes, métadonnées, etc.).
Exemples d'héritage
| Parent (base) | Enfant (héritant) | Justification |
|---|---|---|
contenu | article | Article réutilise titre, résumé, statut de publication du contenu générique |
contenu | page | Page partage les mêmes champs éditoriaux de base |
personne | employe | Employé hérite nom, prénom, email et ajoute poste / service |
personne | client | Client hérite identité et ajoute numéro de compte |
media | video | Vidéo hérite nom de fichier, type MIME et ajoute durée / codec |
Conséquences et implications
- Standardisation : garantit un socle uniforme (ex. attribution, audit, statut, codes internes).
- DRY : évite de dupliquer les mêmes attributs dans plusieurs modèles maintenus indépendamment.
- Propagation des évolutions : ajouter un attribut au parent l'expose automatiquement à tous les enfants (vérifier l'impact fonctionnel avant d'ajouter un champ obligatoire).
- Contrainte : un modèle ne peut avoir qu'un seul parent (pas d'héritage multiple) — concevez vos parents comme des abstractions cohérentes.
- Profondeur : évitez des chaînes d'héritage trop longues (lisibilité & complexité de migration). Deux niveaux (parent → enfant) sont souvent suffisants.
Bonnes pratiques pour choisir un parent
- Créer (ou utiliser) un parent lorsqu'au moins 2 modèles partagent ≥ 3–4 attributs stables.
- Ne pas créer de parent prématuré pour un seul modèle (risque de sur‑abstraction).
- Préférer un attribut de référence plutôt qu'un héritage si les champs communs sont peu nombreux ou volatils.
- Nommer le parent de manière générique (« contenu », « personne », « media », « ressource ») et l'enfant de manière spécifique.
Limites et précautions
- Rendre un attribut du parent obligatoire après qu'il existe déjà des enfants peut nécessiter une migration de données (remplissage par défaut).
- Changer le type d'un attribut hérité (ex. texte → nombre) peut être bloqué ou nécessiter une migration; privilégier des évolutions compatibles (ex. augmenter longueur max, ajouter validation souple).
- Changer de parent après création est généralement déconseillé (risque de conflit de noms d'attributs ou de perte de compatibilité). Valider la structure avant diffusion.
Important : Le champ Parent ne permet la sélection que d'un modèle qui existe déjà. Créez toujours le modèle parent avant son ou ses enfants. Un enfant ne peut avoir qu'un seul parent.
Tenant
Menu déroulant à sélection multiple (obligatoire au moins un tenant si votre plateforme est multi‑locataire).
Les tenants déterminent dans quels espaces / organisations / clients le modèle est disponible.
Impacts :
- Visibilité : seules les instances des tenants sélectionnés verront (et pourront instancier) ce modèle.
- Sécurité / découpage : cloisonne les données par tenant.
- Évolutions : ajouter un nouveau tenant après coup peut étendre la portée du modèle (opération généralement sûre). Retirer un tenant peut nécessiter une vérification d'instances existantes.
Bonnes pratiques tenant
- Sélectionner seulement les tenants où le besoin métier est avéré.
- Documenter (hors plateforme) la raison d'exposition si elle n'est pas évidente.
Récapitulatif des règles de validation
| Champ | Obligatoire | Unicité | Remarques |
|---|---|---|---|
| Nom | Oui | Recommandée (fonctionnelle) | Lisible par l'humain |
| Slug | Oui | Technique (fortement recommandé) | Stable, format restreint |
| Parent | Non | N/A | Doit exister ; une seule sélection |
| Tenant | Oui (si multi‑tenant) | N/A | Sélection multiple |
Création des attributs (après l'enregistrement)
Une fois le modèle sauvegardé :
- Vous êtes redirigé vers la page de détail du modèle.
- Une zone (ex. : « Attributs ») liste les attributs déjà définis (initialement vide).
- Vous pouvez ajouter un attribut via un menu déroulant et un bouton d'action (« Nouvel attribut »).
Rappel : On ne crée pas d'attributs dans le dialogue initial pour garder ce dernier simple et rapide et éviter les validations croisées complexes.
Bonnes pratiques globales
- Stabiliser le slug avant diffusion aux intégrations externes.
- Préférer une arborescence parent → enfant simple plutôt qu'une hiérarchie trop profonde (limite cognitive, complexité de requêtage).
- Vérifier l'impact d'un retrait de tenant sur les données existantes avant de confirmer.
Erreurs fréquentes et solutions
| Problème | Cause probable | Solution |
|---|---|---|
| Impossible de sélectionner un parent | Le parent n'existe pas encore | Créer d'abord le modèle parent, puis rééditer l'enfant |
| Modèle non visible pour un utilisateur | Tenant manquant | Ajouter le tenant au modèle ou vérifier droits utilisateur |
FAQ rapide
Puis-je changer le slug après création ? Techniquement possible, mais déconseillé : risque de casser des références.
Puis-je relier un modèle à plusieurs parents ? Non, un seul parent direct (éviter la multiplication des relations : privilégier des attributs de référence si besoin de lier à d'autres modèles secondaires).
Puis-je retirer tous les tenants ? Dans un environnement multi‑tenant, au moins un tenant doit généralement être présent. Sinon le modèle devient orphelin et inutilisable.
Résumé
- Ouvrir le dialogue et saisir Nom + Slug.
- (Optionnel) Choisir un Parent existant.
- Sélectionner un ou plusieurs Tenants.
- Sauvegarder : le modèle est créé.
- Depuis la page du modèle, ajouter les attributs nécessaires.
En suivant cette démarche, vous gardez votre structure de données propre, évolutive et facile à maintenir.