Kliv
    Back-end cloud

    Un véritable backend, né avec votre app

    Base de données, connexion, fichiers, fonctions, secrets, e-mail : chaque app Kliv commence par tout cela, créé et géré par l’AI au fur et à mesure de votre construction. Rien à provisionner, rien à câbler, rien à synchroniser.

    Tarifs

    Back-end cloud

    Ce n’est pas un service backend que vous câblez

    La plupart des builders AI génèrent une interface et vous remettent une liste de contrôle : inscrivez-vous à une base de données ici, à un fournisseur d’authentification là, collez les clés, écrivez la colle. Chaque couture de cette stack est à vous. Le backend de Kliv est né avec l’app : un seul système, donc la même conversation qui crée vos pages écrit également vos migrations et vos règles d’accès, et les règles s’appliquent partout.

    Ce avec quoi chaque app est née

    Il ne s’agit pas d’une liste de fonctionnalités que vous activez pièce par pièce. Il s’agit de l’équipement standard de chaque app Kliv. Voici ce qui est exécuté avant que vous ayez fini de décrire la première page.

    01

    Une base de données avec ses propres règles

    Vos données résident dans votre propre base de données et la confidentialité est appliquée au niveau de la ligne : une règle telle que « les clients ne lisent que leurs propres projets » est une propriété des données, vérifiée à chaque requête — et non une instruction if que quelqu’un doit se rappeler d’écrire dans chaque page.

    02

    Connexion et identité

    Les comptes, sessions, rôles et organisations existent avant votre première page. Vos utilisateurs peuvent être des particuliers ou des entreprises entières — et la connexion va bien au-delà des mots de passe, qui possède sa propre section ci-dessous.

    03

    Un stockage de fichiers avec des règles d’accès

    Les téléchargements, les images et les documents comportent leurs propres règles : privés, partagés par organisation ou bloqués derrière un achat. Un lien transféré n’ouvre rien que les règles ne permettent pas : le partage est une décision, pas un accident des URL.

    04

    Fonctions côté serveur, saisies

    Lorsque la logique doit s’exécuter sur le serveur (un calcul, un rappel dans un autre outil, un travail nocturne), l’AI écrit le vrai TypeScript sur un SDK typé que le compilateur vérifie. Les fonctions s’exécutent à la demande, lors d’événements ou selon un calendrier.

    05

    Secrets dans un coffre-fort

    Les clés et informations d’identification API se trouvent dans un coffre-fort, jamais dans le code que le navigateur peut voir. Les fonctions les lisent au moment de l’exécution et rien de sensible n’arrive jamais dans votre source.

    06

    Email qui porte votre nom

    La livraison et les modèles font partie du backend : le courrier envoyé par votre app est marqué comme votre app, écrit une seule fois et envoyé sans service de messagerie tiers à configurer.

    07

    Géré au fur et à mesure de la construction

    La partie qu’aucun service backend ne fait : l’AI maintient tout cela comme un effet secondaire de la construction. Décrivez une fonctionnalité et le changement de schéma arrive sous la forme d’une migration ordonnée et suivie ; les règles d’accès évoluent avec les pages qui en ont besoin. Le backend suit l’app, car ils n’ont jamais été séparés.

    L’équipement standard

    Six pièces, un système, chacune étant déjà connectée aux autres.

    Votre propre base de données

    Sécurité au niveau des lignes appliquée à chaque requête : la confidentialité par utilisateur est une propriété des données, et non une habitude que votre code doit conserver.

    Connexion et identité

    Comptes, organisations et rôles, ainsi que la connexion Google et Facebook, les mots de passe et deux facteurs pour vos utilisateurs.

    Le stockage de fichiers

    Fichiers avec leurs propres règles d’accès : privées, par organisation ou derrière un achat. Les liens seuls n’ouvrent rien.

    Fonctions typées côté serveur

    TypeScript réel par rapport à un SDK vérifié par le compilateur — à la demande, lors d’événements ou selon un calendrier.

    Le coffre à secrets

    Clés et informations d’identification extraites de votre code et du navigateur : les fonctions les lisent au moment de l’exécution.

    Envoi par e-mail

    Modèles et livraison intégrés : courrier portant le nom de votre app, pas celui d’un fournisseur.

    Connexion intégrée

    La plupart des builders vous donnent une adresse e-mail et un mot de passe et appellent cela une identité. Kliv donne aux utilisateurs de votre app la connexion qu’ils attendent de produits réels — et elle appartient à votre app : votre flux, votre image de marque, vos enregistrements.

    E-mail et mot de passe

    Comptes, vérification et réinitialisations — les enjeux de la table, gérés correctement.

    Connectez-vous avec Google et Facebook

    Connectez-vous en un seul clic avec les comptes que vos utilisateurs possèdent déjà.

    Mots-clés

    Connexion résistante au phishing avec Face ID, Touch ID ou une clé de sécurité – aucun mot de passe à voler.

    Authentification à deux facteurs

    Codes TOTP de n’importe quelle app d’authentification, pour les utilisateurs qui souhaitent un deuxième verrou sur la porte.

    Organisations et rôles

    Équipes, rôles et murs d’organisation : la structure sur laquelle les règles de la base de données sont écrites.

    Vos utilisateurs, vos enregistrements

    Chaque compte est une ligne dans votre propre base de données : segmentez-les, exportez-les ou effacez-en un sur demande. La relation est la vôtre.

    Questions courantes

    Le backend est-il un service distinct que je dois gérer ?

    Non, c’est le point. Il est né avec l’app et géré via la même conversation qui l’a construit. Il n’y a pas de dashboard à provisionner, pas de clés à coller dès le premier jour et pas de deuxième système désynchronisé avec votre code.

    Qui écrit les migrations de bases de données ?

    Le AI le fait, comme effet secondaire de la construction. Décrivez la fonctionnalité et le changement de schéma arrive sous la forme d’une migration ordonnée et suivie — lisible si vous voulez regarder, appliquée en séquence afin que l’historique de la base de données soit aussi lisible que celui de l’app.

    Comment la confidentialité par utilisateur est-elle réellement appliquée ?

    Au rang. Chaque requête renvoie uniquement ce que l’utilisateur connecté est autorisé à voir, car la règle repose sur les données elles-mêmes : un bug dans une page ne peut donc pas divulguer ce que la base de données refuse de transmettre.

    Mes utilisateurs peuvent-ils se connecter avec Google ?

    Oui — Google et Facebook, ainsi que les mots de passe et TOTP à deux facteurs. Et il s’agit de la connexion à votre app, et non d’un widget tiers : votre flux, votre image de marque et les enregistrements d’utilisateurs qui résident dans votre propre base de données.

    Où se trouvent les clés et informations d’identification API ?

    Dans le coffre-fort. Les fonctions les lisent au moment de l’exécution ; ils n’apparaissent jamais dans le code que le navigateur peut voir, et rien de sensible n’apparaît dans votre historique source.

    Puis-je récupérer mon code et mes données ?

    Oui. La source de votre app se synchronise dans les deux sens avec votre propre dépôt Git et les données constituent votre propre base de données : exportez-les à tout moment. Le pari de Kliv est que vous restez parce que c’est bien, pas parce que partir est dur.

    Décrivez votre app. Le backend est livré avec.

    Intégré signifie construit ensemble : le checkout, l’agent et les tests s’exécutent tous sur ce même backend – un ensemble de règles, appliquées partout.

    Tarifs