Concepts essentiels

Avant de toucher au moindre bouton, il vaut la peine de fixer une demi-douzaine d'idées. Tout le reste de la plateforme — chaque menu, chaque panneau, chaque décision que vous allez prendre — repose sur ces concepts. Cette page les définit une fois, tranquillement ; les chapitres suivants supposent que vous les connaissez.

#L'app — l'unité de tout

Une App est une application complète et autonome : ses écrans, son modèle de données, ses APIs, ses scripts, ses rapports, ses paramètres et ses utilisateurs vivent ensemble et voyagent ensemble. Chaque app a :

Propriété	Ce que c'est
Nom	Comment l'app apparaît dans la liste et dans l'espace de travail. Ex. : Gestion de Clients.
Slug	La forme courte du nom, dérivée automatiquement, qui entre dans les adresses. Ex. : gestao-clientes.
Icône	Le symbole de l'app dans la barre latérale et dans la liste.
Description	Une phrase libre, visible dans l'en-tête de l'arborescence de l'app.

Être autonome a deux conséquences pratiques :

• Une app peut être exportée sous forme de fichier .keplinapp puis importée dans une autre installation — elle emporte tout avec elle.
• Supprimer une app supprime son monde (design, données, fichiers) sans toucher aux autres apps ni aux bases de données externes auxquelles elle se connectait.

#Écrans — les pages de l'application

Un Écran est une page de l'app construite, dessinée dans un éditeur visuel : vous glissez des widgets (tables, formulaires, graphiques, calendriers, …) sur un canvas, vous les reliez à des données et vous définissez ce qui se passe à chaque clic. Chaque écran a une Route — le chemin dans l'adresse de l'app — et peut recevoir des paramètres (par exemple, le numéro du client à afficher dans une fiche).

Trois types d'écran méritent un nom à part :

• Écrans normaux — ceux que vous créez et organisez librement dans l'arborescence.
• Écrans système — ils existent dans toutes les apps dès la première seconde : Login, Récupérer le mot de passe et Inscription. Vous en modifiez l'apparence dans le même éditeur, mais la route et l'accès sont fixes.
• Écrans publics — servis sans session ouverte, pour des pages que n'importe qui peut voir. Ils ne peuvent lire que les données d'APIs marquées comme publiques.

La colle entre les écrans, c'est la Navigation : le menu de l'app (barre supérieure ou latérale), avec ses entrées, ses sous-menus et ses raccourcis, dessiné dans son propre éditeur.

#Le modèle de données

Le modèle de données est la carte des entités de l'app — tables, champs, relations et enums — construite sur les Datasources (les bases de données auxquelles l'app se connecte). Vous importez dans le modèle les tables qui vous intéressent, vous leur donnez des noms conviviaux, et à partir de là tout le reste de la plateforme parle la langue du modèle : les APIs de table en génèrent des opérations complètes, les écrans choisissent les champs par leur nom convivial, les enums alimentent les listes d'options.

Le point essentiel : le modèle décrit, il ne duplique pas. Les données continuent de vivre dans les bases de données ; le modèle est la couche qui les rend utilisables par les écrans et par les APIs sans écrire deux fois la même logique.

#Versions — travailler sans peur

Chaque app a des Versions, et la première s'appelle toujours main. Une version est une copie complète du design et des données de l'app à cet instant — créer la version « 2.0 » à partir de main vous donne une branche où vous pouvez tout bouger sans toucher à ce qui est en service.

Ce qu'il faut retenir :

• La version de travail est la vôtre. Chaque personne choisit la version sur laquelle elle travaille ; changer de version ne change celle de personne d'autre.
• Les versions ne partagent pas les données. Une nouvelle version naît avec les données copiées de l'origine ; à partir de là, chacune suit sa propre vie.
• Chaque version a un historique. Tous les enregistrements sont consignés, avec deux façons de revenir en arrière : Restaurer l'app dans cet état (tout revient à un instant donné) et Revenir sur cette modification (annule un enregistrement précis). Aucune des deux ne réécrit l'histoire — annuler est toujours un nouveau pas dans le journal.
• Vous pouvez transporter des éléments entre versions — un écran terminé dans la « 2.0 » peut être ramené dans main sans ramener le reste.

#Publication — quelle version sert chaque adresse

Publier n'est pas un bouton « mettre en ligne » — c'est une association : chaque adresse (hôte) sert UNE version de l'app. Dans la section Publication des paramètres de l'app, vous associez un hôte (ex. : crm.entreprise.com) à une version ; qui visite cette adresse voit cette version, et rien qu'elle.

Tant que vous n'avez publié aucun hôte, l'app répond quand même — à l'adresse interne /app/<slug> (ex. : /app/gestao-clientes), avec la version de travail. C'est l'endroit naturel pour expérimenter pendant la construction.

#Deux populations d'utilisateurs

Il y a deux façons d'être dans Keplin, avec des comptes séparés et des portes séparées :

	Ceux qui construisent	Ceux qui utilisent
Entrent par	La page de connexion de la plateforme	L'adresse de l'app publiée (ou /app/<slug>)
Voient	L'espace de travail : arborescence, éditeurs, versions	Les écrans de l'app construite — et rien d'autre
Compte géré dans	Utilisateurs (menu global, administrateurs)	Utilisateurs de l'app, dans les paramètres de chaque app
Profils	admin (tout, dans toutes les apps) et developer (seulement les apps attribuées)	Ceux que vous définirez dans les Permissions de l'app

Les utilisateurs de l'app ne savent même pas que Keplin existe : la connexion, l'inscription et la récupération de mot de passe qu'ils voient sont les écrans système de l'app, avec le thème et la langue de l'app. Cette séparation se répète partout — et c'est pour cela que les paramètres de chaque app (thème, traductions, comptes, permissions) voyagent avec elle quand vous l'exportez.