Pourquoi LScript ?
La logique métier est le cœur de votre application.
Elle mérite mieux que d'être noyée dans du code.
🚨 Le problème
Dans la plupart des projets, les règles métier sont dispersées dans le code. Elles sont difficiles à trouver, à comprendre, à modifier.
Règles enfouies
La logique d'autorisation est cachée dans des contrôleurs, des middlewares, des services. Personne ne sait exactement où elle se trouve.
Conditions illisibles
Des if imbriqués sur 15 lignes. Même l'auteur ne comprend plus ce que ça fait après 3 mois.
Duplication silencieuse
La même règle, copiée dans 4 endroits différents. Avec des variations subtiles. Et des bugs.
Décisions inexplicables
"Pourquoi cet utilisateur a été refusé ?" — Personne ne sait. Le code ne l'explique pas.
Résultat : les développeurs passent du temps à débugger la logique métier, et les équipes produit ne peuvent pas la comprendre sans passer par les devs.
💡 Ce que LScript change
LScript sort la logique métier du code et la rend lisible, testable, explicable.
Les règles métier vivent dans des fichiers .ls, versionnés avec Git, séparés du code applicatif.
Les règles s'écrivent en français. Un PM peut les lire. Un nouveau dev peut les comprendre en 30 secondes.
Chaque règle peut être testée indépendamment avec un contexte JSON. Pas besoin de monter toute l'application.
Chaque décision retourne le nom de la règle appliquée et le message associé. Fini les "pourquoi ça a refusé ?".
📊 Avant / Après
Voyez la différence en un coup d'œil.
if (user.role === 'admin' && user.active === true) {
if (subscription.plan !== 'free' || user.trial) {
if (feature.requiredLevel <= user.level) {
return { allowed: true };
}
}
}
return { allowed: false, reason: '???' };Logique noyée. Aucun message d'erreur clair. Impossible à expliquer.
regle "Accès Fonctionnalité Premium"
quand utilisateur.role est "admin"
et utilisateur.actif est vrai
et abonnement.plan n'est pas "gratuit"
alors autoriser
sinon refuser "Abonnement premium requis"
finRègle lisible. Décision explicite. Message pour l'utilisateur.
👥 À qui s'adresse LScript
Développeurs backend
Vous voulez sortir la logique métier de vos contrôleurs et la rendre testable.
CTO & Tech Leads
Vous cherchez à réduire la dette technique liée aux règles métier dispersées.
Product Managers techniques
Vous voulez pouvoir lire et valider les règles sans passer par les développeurs.
Studios de jeux
FiveM, Roblox, ou jeux Lua — vous avez besoin de règles claires pour les systèmes de jeu.
SaaS avec règles complexes
Permissions, accès, pricing, workflows — vos règles métier méritent un langage dédié.
🚫 À qui LScript ne s'adresse pas
LScript n'est pas une solution universelle. Voici les cas où il n'est probablement pas adapté.
- Projets ultra simples — Si votre application a 2-3 conditions, un
ifsuffit. - Scripts jetables — Pour un script ponctuel qui ne sera jamais relu, LScript ajoute une complexité inutile.
- Logique purement technique — LScript est pour les règles métier, pas pour la gestion de cache ou les connexions réseau.
- Équipes qui n'ont pas besoin d'explicabilité — Si personne ne demande jamais "pourquoi cette décision ?", LScript n'apporte pas de valeur.
Cette honnêteté est intentionnelle. LScript résout un problème précis. Si ce n'est pas votre problème, utilisez autre chose.
🚀 Comment commencer
Deux liens. Pas plus.