Aller au contenu
Kewos

Créer un module sans écrire de code

Tout ce parcours suppose que vous écrivez du code. Une bonne partie des gens qui déploient un ERP n’en écrivent pas, et ont pourtant un besoin métier précis à couvrir. Le Builder est pour eux : décrire un module dans l’interface, et l’obtenir vivant, tout de suite.

Ce n’est pas un mode dégradé. Un module du Builder produit exactement les mêmes objets qu’un module écrit à la main.

Ce qu’un module du Builder produit

Voici, exécuté sur une instance, ce que donne la création d’un module « atelier de reliure » avec un seul modèle et trois champs :

POST /api/v1/admin/builder/modules
  -> {"ok": true, "name": "reliure", "models": ["reliure_chantier"]}

Une vraie table, avec tous les champs système du produit :

id  name  recu_le  etat
created_at  created_by_id  updated_at  updated_by_id  version
deleted_at  deleted_by_id  kws_custom_data

L’horodatage, l’auteur, le numéro de version pour la concurrence, la corbeille, et la colonne des champs ajoutés à chaud. Vous n’avez rien demandé de tout ça : c’est ce que tout modèle Kewos porte.

Une API complète, immédiatement, sans redémarrage :

POST /api/v1/reliure_chantier  {"name": "Dune, dos cassé", "recu_le": "2026-09-06"}
  -> {"id":1, "etat":"recu", "version":1, "created_by_id":1, ...}

L’état vaut recu : la valeur par défaut déclarée dans le formulaire a été appliquée par le serveur.

Un écran, généré à partir du modèle :

GET /api/v1/views/reliure_chantier/effective?kind=list
  -> colonnes: id, name, recu_le, etat ... chacune avec son type et sa clé i18n

Aucune vue n’a été écrite. C’est le même moteur qui rend les écrans des modules codés à la main.

L’IA propose, l’humain confirme

Le Builder sait décrire un module à partir d’une phrase, mais il ne l’installe jamais tout seul. Le flux est en deux temps :

  1. POST .../modules/suggest renvoie une proposition en YAML déclaratif, que vous lisez ;
  2. POST .../modules crée et charge ce que vous avez confirmé.

C’est délibéré. Une IA qui crée des tables sans relecture est une IA qui crée des tables fausses sans relecture. Le YAML intermédiaire est le point de contrôle : il est lisible, modifiable, et c’est lui qui fait foi, pas la phrase de départ.

Désactiver ne supprime rien

POST .../modules/reliure/disable   -> {"state": "disabled"}
  l'API du modèle : 404
  les données en base : toujours là

Le module disparaît de l’interface et de l’API, et la table reste intacte. Réactiver le remet en service :

POST .../modules/reliure/enable    -> {"state": "loaded"}
  l'API du modèle : 200

C’est la même posture que la suspension d’un client : on coupe l’accès, on ne détruit pas les données. Une suppression avec purge existe, séparément, et c’est une décision explicite.

Ce que le Builder ne fait pas

  • Il n’exécute pas de code. Un champ calculé du Builder est une expression d’une grammaire fermée, pas du Python (interdiction n°37). Il n’y a pas d’eval, donc il n’y a pas d’exécution arbitraire à sécuriser.
  • Il ne contourne pas les droits. Créer un module demande le groupe kws_builder_editor, et les modèles produits passent par les mêmes règles d’enregistrement et les mêmes ACL que les autres.
  • Il n’est pas réservé au bac à sable. Créer des tables reste un changement de schéma : en développement il s’applique directement, en production il emprunte le chemin de migration par module (interdictions n°11 et n°12).