Un socle de production, pas un boilerplate de plus.
Douzième authentification, douzième intégration Stripe, douzième jeu de migrations. Kubbler vous rend la plomberie : 22 capacités écrites, testées et exploitées en production, en JavaScript lisible sur Next.js. Vous gardez le clavier, le dépôt et l'architecture.
- capacités écrites et testées, en JavaScript lisible
- 22capacités écrites et testées, en JavaScript lisible
- boîte noire dans votre dépôt
- 0boîte noire dans votre dépôt
- clic pour déployer l'ensemble, secrets compris
- 1clic pour déployer l'ensemble, secrets compris
La plomberie n'a jamais rien appris à personne. Elle coûte quand même des semaines.
Chaque nouveau projet recommence par les mêmes trois semaines : câbler l'authentification et les sessions, gérer les rôles et les invitations, signer les webhooks Stripe et se prémunir de la double facturation, écrire les migrations, les validateurs, les emails transactionnels dans chaque langue, durcir la CSP et la limitation de débit, puis monter un pipeline de déploiement qu'il faudra maintenir. Ce code ne distingue pas votre produit. Il est pourtant celui qui vous coûte le plus cher en incidents.
Les boilerplates et les starters promettent de régler ça et s'arrêtent à mi-chemin : un squelette à forker, qui diverge dès la première semaine et que personne ne maintient pour vous. Les générateurs de code par IA vont plus loin et plus vite, mais réécrivent une couche d'authentification différente à chaque projet (donc des failles différentes à chaque projet) et laissent une base sans migration qu'on n'ose plus faire évoluer.
Kubbler est un socle exploité, pas un template. Les fondations sont écrites une fois, par des ingénieurs, relues, testées, et corrigées pour tous les projets en même temps. L'IA n'y touche pas : elle interprète l'intention métier pour assembler la couche produit (écrans, modèle de données, parcours) dans les conventions du socle. Vous récupérez le tout en JavaScript lisible, exportable vers GitHub à tout moment, avec un déploiement conteneurisé, des secrets chiffrés par environnement et des sauvegardes.
Le code que vous n'aviez aucune envie de réécrire.
Ce que vous reprenez à zéro sur chaque projet, et ce qu'il vous reste à écrire une fois que le socle est déjà là.
Ce que vous récupérez, tel quel.
Pur JavaScript, des conventions documentées, rien de propriétaire à apprendre pour être productif le premier jour.
Le socle
Écrit une fois, relu, exploité, corrigé pour tout le monde en même temps.
Authentification complète
Inscription, sessions, 2FA (TOTP, email, SMS), rôles, organisations, invitations, anti-fraude.
Données
Schémas versionnés, validation à l'entrée, migrations générées, cache Redis avec invalidation.
Tâches & files
Planification, files avec reprise sur erreur, priorités, journalisation et métriques.
La sortie
Ce que vous emportez le jour où vous décidez de partir : condition d'entrée, pas option.
Export du code
Vers GitHub, à tout moment, depuis l'éditeur. Lisible, conventionné, documenté.
Déploiement
Conteneur dédié, domaine, HTTPS, sauvegardes, environnements séparés. Un clic.
Secrets
Coffre chiffré de bout en bout, par environnement, injecté au déploiement. Jamais dans le navigateur.
Ce que vous pouvez construire avec.
Trois projets typiques, et la part de chacun que vous n'écrirez pas : celle qui ne vous aurait rien appris.
Un back-office métier complet
Modèle de données, validation, tableaux, filtres, rôles et permissions : le CRUD que vous n'écrirez pas une treizième fois. Vous gardez la logique métier, le socle tient le reste.
Une API versionnée avec ses écrans
Le schéma se dessine, l'API en découle avec sa validation et ses migrations, le front la consomme. Le tout part sur GitHub quand vous le décidez, avec une documentation OpenAPI générée.
Un produit multi-tenant, isolé par client
Chaque client sa base, ses secrets, son domaine, ses sauvegardes, sans écrire une ligne de cette isolation. Vous ajoutez un tenant par configuration, pas par déploiement.
Comment ça se passe, concrètement.
Quatre étapes, trois acteurs : vous décidez de l'architecture métier, l'IA interprète, et les ingénieurs qui ont écrit le socle répondent des fondations.
Vous cadrez le métier
Le domaine, les entités, les parcours, les règles. Vous pouvez le décrire en langage naturel ou dessiner le schéma directement : l'API en découle, le front la consomme.
L'IA interprète
Elle traduit le cadre en modèle de données versionné, en routes et en écrans, en composant avec les 81 blocs et les capacités du socle. Elle travaille dans les conventions du framework, pas à côté.
Le socle porte
Authentification et sessions, rôles et organisations, paiements Stripe idempotents, validation et migrations, files de tâches, cache, CSP, quotas : écrits et relus par des ingénieurs, exploités en production, corrigés pour tous.
Vous reprenez le clavier
Export GitHub quand vous voulez, ou travail dans l'éditeur de code intégré. Environnements de dev et de prod séparés, secrets injectés au déploiement. Vous promptez le lundi, vous codez le mardi, sur le même dépôt.
Pourquoi Kubbler, pour un développeur.
Quatre raisons qui ne relèvent pas du marketing mais de la façon dont le socle est écrit et exploité.
Du code que vous pouvez lire
Pas de DSL, pas de runtime propriétaire : du JavaScript conventionné sur Next.js et Node.js, des schémas JSON versionnés, des conventions documentées. Vous êtes productif le premier jour, et vous pouvez répondre de chaque ligne devant un pair.
Le dépôt est à vous
Export vers GitHub à tout moment, depuis l'éditeur. Vous branchez votre intégration continue, vos revues, vos outils. Kubbler n'est pas une cage : c'est un socle dont vous pouvez sortir quand vous voulez, en emportant tout.
Les fondations ne sont pas générées
L'IA assemble la couche produit dans les conventions du socle ; elle n'écrit jamais l'authentification, les paiements ni les migrations. Ces briques sont écrites, relues et exploitées en production par des ingénieurs, et une correction profite à tous les projets : le vôtre compris.
La sécurité est réglée à la source
Secrets chiffrés de bout en bout par environnement, CSP et CORS durcis, limitation de débit, anti-fraude, double authentification, validation systématique à l'entrée. Ce n'est pas une checklist à cocher projet après projet : c'est le comportement par défaut.
Les questions qu'on nous pose.
Des réponses précises, parce que les décisions se prennent sur des faits, pas sur des promesses.
Next.js (App Router), React et Redux Toolkit côté front ; une API Node.js sur MongoDB avec modèle de données versionné, validation à l'entrée et migrations générées ; Redis pour le cache et l'état ; Stripe pour les paiements. Le tout en JavaScript (ES Modules), sans TypeScript imposé, avec des conventions documentées.
Oui. L'export vers GitHub est disponible à tout moment depuis l'éditeur : vous relisez, versionnez et faites évoluer le code dans votre propre dépôt, avec votre propre intégration continue. Vous pouvez aussi continuer à travailler dans Kubbler, en alternant prompt et code sur le même projet.
Sur la couche produit, oui : écrans, textes, agencement, modèle de données, routes métier, dans les conventions du socle. Jamais sur les fondations : authentification, paiements, sécurité, migrations, déploiement sont du code écrit et relu par des humains, identique pour tous les projets. Ce que l'IA produit est vérifié avant d'être enregistré : le projet doit construire et respecter les conventions.
Oui : la logique métier vit dans des contrôleurs, des modules et des hooks qui vous appartiennent, et vous importez les bibliothèques que vous voulez. Le socle fournit le contexte (session, validation, accès aux données, files de tâches) et vérifie la sortie ; ce que vous écrivez dedans est libre.
Les corrections et les évolutions du socle sont déployées pour tous les projets en même temps, sans intervention de votre part : une faille corrigée chez l'un est corrigée chez tous. Votre couche produit, elle, ne bouge que quand vous le décidez.
Regardez le code avant de nous croire.
Gratuit pendant la bêta. Générez un projet, ouvrez le dépôt, lisez les conventions, jugez sur pièce : c'est la seule démonstration qui compte pour un développeur.
Un coffre chiffré de bout en bout, par environnement ; les variables sont injectées au déploiement, jamais dans le code du navigateur, jamais dans une image. Développement et production sont séparés, avec une version de test avant chaque mise en ligne sur les plans qui l'incluent.