KoratLes modules sont la réponse de Korat au problème d’une seule app pour restaurants, hôtels, cliniques et boutiques : la version honnête est quatre apps partageant une connexion, et la version malhonnête une app dont l’écran de réglages est si vaste que chaque commerce y voit surtout ce qui ne le concerne pas. Korat prend une troisième voie : le type d’activité sélectionne un module, le module construit l’interface, et ni la page publique ni la console n’ont de connaissance en dur de ce qu’est un restaurant.
Le contrat de module
Un module déclare un ensemble fixe de choses, et l’app assemble tout le reste à partir d’elles : un identifiant ; les types d’activité qu’il revendique, qui décident s’il s’applique à un commerce donné ; un libellé et un titre de catalogue ; une action principale, le bouton avec lequel la page client s’ouvre ; et une vue de catalogue — une carte pour la restauration, des types de chambres pour l’hébergement, des prestations pour une clinique, des produits pour le détail.
Quatre déclarations supplémentaires sont facultatives, et c’est là que le système gagne son salaire. Un module peut déclarer des capacités, qui deviennent de nouvelles permissions disponibles pour les rôles ; des tuiles de console, qui apparaissent dans la grille du tableau de bord ; un écran de console propre ; et une section de page client, injectée dans la page publique du commerce. Un module qui n’en déclare aucune est un pur catalogue ; un module qui déclare les quatre remodèle les deux côtés de l’app d’un coup.
Il existe aussi une bibliothèque d’interface partagée — bouton d’action principale, ligne de catalogue, puce, libellé de section, état vide — dont les modules sont censés partir. Ce n’est pas du style maison pour lui-même : c’est ce qui fait qu’un module écrit séparément ressemble à une partie de l’app plutôt qu’à un widget encastré.
Les quatre modules cœur sont les types d’activité
Les quatre modules cœur ne sont pas des extensions : ils sont ce que veut dire un type d’activité. Restauration revendique restaurant et café. Hébergement revendique hébergement, hôtel, complexe, appartement, condominium et maison de village — six libellés, un module, parce qu’une location en résidence et une nuit en pension diffèrent par les mots, pas par le mécanisme. Service revendique service et clinique, la variante clinique renommant l’interface en rendez-vous, patients et cures sans dupliquer le code. Commerce de détail revendique le détail.
Comme ce sont des modules et non des branches dans un écran géant, l’écran cuisine et les groupes d’options de la restauration n’existent pas pour un hôtel — ni masqués derrière un drapeau, ni désactivés : absents. La surface qu’un commerce voit est une fonction de ce qu’il a déclaré être.
Sept extensions installables, valables pour tout type
Par-dessus les modules cœur s’installent sept extensions, toutes applicables quel que soit le type. Les permissions d’équipe sont la plus intéressante, parce qu’elles sont construites à partir des autres : l’extension bâtit un éditeur de permissions à partir des capacités déclarées par chaque module installé, si bien qu’installer un nouveau module fait apparaître ses permissions dans l’éditeur sans que personne ne mette une liste à jour. Les mêmes capacités sont ensuite lues côté base par has_capability(), décrite sur la page sécurité.
Les canaux de paiement ajoutent une tuile de configuration et une liste visible des canaux acceptés sur la page publique — une extension qui écrit des deux côtés par deux emplacements de déclaration. Les abonnements et adhésions introduisent des formules qu’un client achète directement depuis la page du commerce. Les rappels de renouvellement gèrent le suivi que créent adhésions et cures. Chacune est un module maison écrit contre le même contrat qu’utiliserait un tiers — une discipline assumée, car un contrat n’est réel que si ses auteurs y sont eux aussi contraints.
Installer et désinstaller, commerce par commerce
Les extensions se gèrent depuis la boutique de modules à l’intérieur de la console, et l’installation est portée par un commerce unique. Un propriétaire de deux boutiques peut installer les adhésions sur l’une et pas sur l’autre, et les deux tableaux de bord diffèrent réellement.
La désinstallation passe par une confirmation, et cette confirmation dit une chose précise : les données ne sont pas supprimées. Cela compte plus qu’il n’y paraît. Si les gens hésitent devant un bouton de désinstallation, c’est qu’ils le supposent destructeur ; ils laissent donc installés des modules qu’ils n’utilisent pas, et la console se remplit de tuiles que personne n’ouvre. Dire ce qui *ne* se produit *pas* est ce qui rend le bouton utilisable. Après désinstallation, l’extension ne contribue plus rien — ni tuile, ni permission dans l’éditeur de rôles, ni section sur la page publique — mais ses enregistrements survivent à une réinstallation.
Ce que ce n’est pas encore
Les plugins tiers ne sont pas ouverts. La boutique de modules le dit elle-même plutôt que de le laisser deviner par un rayon vide où « d’autres arrivent ». Ce qui existe aujourd’hui est une architecture modulaire avec un vrai contrat, quatre modules cœur et sept extensions maison écrites contre lui, tous chargés par le même chemin d’enregistrement. La soumission par des tiers est l’étape annoncée, pas une place de marché en service : il n’y a ni portail développeur, ni file de relecture, ni SDK publié.
Nous le décrivons ainsi parce que l’architecture est la partie intéressante et qu’elle est vraie aujourd’hui, tandis qu’une place de marché est une affirmation sur l’avenir. Le test du contrat est qu’un module écrit entièrement contre lui — tuiles, capacités et section de page, sans toucher au code cœur — se comporte comme une partie native de l’app. Quatre le font. Ouvrir cela à l’extérieur est un problème de politique et de relecture plus que de technique, et il n’est pas résolu.
Pourquoi des modules plutôt que des drapeaux de fonctionnalité
Un drapeau éteint quelque chose ; un module apporte quelque chose. La différence se voit dans l’éditeur de permissions : avec des drapeaux, quelqu’un tient une liste maîtresse de toutes les capacités et doit penser à l’étendre. Avec le contrat, l’extension permissions d’équipe demande à chaque module installé ce qu’il déclare et bâtit l’éditeur à partir des réponses — la liste ne peut pas se périmer. Le même schéma vaut pour la grille du tableau de bord et pour la page publique : aucune n’énumère les fonctionnalités, toutes demandent.
Cela borne aussi le coût d’un nouveau métier. Ajouter un type d’activité que Korat ne sert pas encore, c’est écrire un module : déclarer les types revendiqués, un catalogue, une action principale, et les emplacements facultatifs nécessaires — sans toucher à la console, au rendu de page ni au système de permissions. C’est ce qui rend une super-app traitable au lieu d’une lente accumulation de cas particuliers.
Il n’existe pas de place de marché de plugins tiers. Tout ce qui s’installe aujourd’hui est maison, et la boutique le dit dans l’app. La soumission par des tiers est l’étape annoncée — il n’y a pas encore de portail développeur ni de SDK publié contre lequel construire.
Le code des modules est par ailleurs toujours livré dans l’APK plutôt que chargé module par module à l’usage. C’est une limite connue, et le prérequis évident avant d’ouvrir la boutique à des gens extérieurs au projet.
- Déclarations obligatoires
- identifiant · types revendiqués · libellé · titre de catalogue · action principale · vue de catalogue
- Déclarations facultatives
- capacités · tuiles de console · écran de console · section de page client
- Modules cœur
- Restauration · Hébergement · Service · Commerce de détail
- Extensions
- Permissions d’équipe · Canaux de paiement · Abonnements et adhésions · Rappels de renouvellement
- Portée d’installation
- par commerce
- Désinstallation
- derrière une confirmation qui précise que les données ne sont pas supprimées
- Tiers
- non ouvert — extensions maison uniquement