Applis IA avec un vrai backend et une vraie base de données : le guide complet (2026)

Quels générateurs d'applications IA créent un vrai backend — et qu'est-ce qui compte comme « vrai » ?

Réponse courte : un vrai backend, ce sont des données PostgreSQL persistantes, une authentification côté serveur et des API REST qui font respecter les règles sur le serveur — pas un beau frontend React où le formulaire de connexion n'authentifie personne et où les graphiques du dashboard rendent du JSON codé en dur. La plupart des générateurs d'applications IA produisent la deuxième chose. VULK (notre produit — transparence ci-dessous) génère et déploie la première : quand votre prompt décrit des comptes, des données sauvegardées ou des rôles d'admin, il provisionne automatiquement un vrai backend — schéma PostgreSQL, endpoints CRUD, auth JWT avec rôles — aux côtés du frontend, câblé et déployé. Lovable et Bolt prennent une route différente et légitime : ils délèguent le backend à Supabase, ce qui fonctionne bien mais signifie opérer une deuxième plateforme. Les outils frontend-first vous laissent construire vous-même les 60 % difficiles.

La demande n'est pas un cas limite : 62 % de toutes les applis générées sur VULK incluent un schéma SQL (données de la plateforme VULK, juillet 2026, sur 11 355 applis générées) — la plupart des gens qui promptent une « appli » décrivent quelque chose avec des utilisateurs et des données, qu'ils le réalisent ou non. Ce guide couvre tout : les quatre tests d'un vrai backend, le fonctionnement du provisioning automatique, à quoi ressemblent vraiment le schéma et l'auth générés, les patterns de sécurité, le déploiement, six prompts complets à copier-coller, et — la partie que les vendeurs marmonnent — l'histoire honnête de l'export et de la portabilité, la nôtre incluse. Transparence : VULK est notre produit. Mis à jour le 17 juillet 2026.

Tableau comparatif : comment les builders IA gèrent le backend

Trois architectures se cachent derrière l'étiquette « builder IA full-stack ». Généré (VULK, Databutton) : l'IA écrit votre schéma, vos endpoints et votre auth comme partie de l'appli — le plus intégré, et vous faites confiance à du code serveur généré (il est inspectable ; inspectez-le). Délégué (Lovable, Bolt → Supabase) : l'outil câble votre frontend à un BaaS managé — excellente DX et portabilité des données propre, mais vous opérez deux plateformes et héritez de la forme du BaaS. Embarqué (Base44) : zéro configuration, zéro sortie. Aucune n'est fausse ; elles échouent différemment à mesure que vous grandissez. Tarifs vérifiés le 17 juillet 2026.

Que manque-t-il vraiment aux applis IA frontend-only ?

Faites passer n'importe quelle démo de « générateur d'applications IA » par quatre tests :

1. Persistance : créez des données, redéployez — sont-elles encore là ? Les applis à données factices se réinitialisent. Les applis localStorage prennent les données en otage dans un navigateur.
2. Vraie auth : le formulaire de connexion vérifie-t-il les identifiants sur un serveur et émet-il une session ? L'« auth » côté client est de la décoration — n'importe qui ouvre les DevTools et passe à côté.
3. Règles imposées côté serveur : l'utilisateur A peut-il récupérer les enregistrements de l'utilisateur B en changeant un ID dans la requête ? Si la validation ne vit que dans React, la réponse est oui.
4. Données inspectables : pouvez-vous exécuter du SQL sur votre propre base ?

Échouez à ces tests et vous avez un prototype — réellement utile pour valider une idée, et c'est là que des outils comme v0 brillent. Mais l'écart entre ce prototype et un produit, c'est précisément le backend : comptes, rôles, validation, relations, migrations. C'est la partie qui a historiquement mangé le plus de temps d'ingénierie — et celle dont 62 % des générations VULK finissent par avoir besoin (données de la plateforme VULK, juillet 2026).

Comment VULK provisionne-t-il un backend automatiquement ?

Vous ne dites jamais « ajoute un backend ». La détection lit votre prompt à la recherche de signaux :

• Signaux d'auth — « connexion », « inscription », « comptes utilisateurs », « panneau d'admin », « rôles » : déclenchent le système d'auth.
• Signaux de persistance — « sauvegarder », « stocker », « historique », « enregistrements », « base de données » : déclenchent la génération schéma + CRUD.
• Signaux d'API — « endpoint », « REST », « webhook » : déclenchent la génération de routes.

La détection est délibérément conservatrice — une landing page ou un portfolio reste un frontend statique rapide ; un prompt avec « les utilisateurs peuvent publier des annonces et écrire aux vendeurs » reçoit le stack complet. Quand elle se déclenche, une seule génération produit quatre couches coordonnées :

1. Schéma PostgreSQL — tables, types, contraintes, clés étrangères, index, dérivés des entités de votre prompt.
2. API REST — CRUD complet par entité avec validation, pagination et codes de statut corrects, déployé sur le moteur d'API de VULK.
3. Système d'auth — endpoints d'inscription et de connexion, hachage bcrypt des mots de passe, émission de JWT, middleware protégeant les routes privées, vérifications de rôles quand votre prompt en implique.
4. Frontend câblé — l'appli React est générée contre cette API : les appels fetch pointent vers de vrais endpoints, les tokens s'attachent aux requêtes, les états de chargement et d'erreur existent. Le formulaire de connexion vous connecte vraiment. Cette dernière couche est ce qui sépare « a généré un backend » de « a généré deux moitiés que vous aurez le plaisir d'intégrer vous-même ».

L'éditeur vous donne ensuite un panneau Backend : parcourez tables et lignes, exécutez du SQL brut dans un query runner, testez les endpoints avec un testeur d'API et exportez n'importe quelle table en CSV. Vos données ne sont jamais derrière un rideau.

À quoi ressemble le schéma SQL généré ?

La qualité du schéma décide de la qualité de l'application, donc la génération impose les patterns qu'un ingénieur base de données soigneux utiliserait. Pour « un gestionnaire de tâches où les utilisateurs créent des projets et ajoutent des tâches ; les utilisateurs ne voient que leurs propres projets » :

CREATE TABLE users (
  id            SERIAL PRIMARY KEY,
  email         VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  name          VARCHAR(120) NOT NULL,
  role          VARCHAR(20) NOT NULL DEFAULT 'member',
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE projects (
  id         SERIAL PRIMARY KEY,
  user_id    INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  name       VARCHAR(160) NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE tasks (
  id          SERIAL PRIMARY KEY,
  project_id  INTEGER NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  title       VARCHAR(200) NOT NULL,
  description TEXT,
  priority    VARCHAR(10) NOT NULL DEFAULT 'medium'
              CHECK (priority IN ('low','medium','high')),
  status      VARCHAR(12) NOT NULL DEFAULT 'open'
              CHECK (status IN ('open','in_progress','done')),
  due_date    DATE,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_projects_user_id ON projects(user_id);
CREATE INDEX idx_tasks_project_id ON tasks(project_id);
CREATE INDEX idx_users_email ON users(email);

Les choix délibérés, chacun étant un échec courant du code généré naïf :

• password_hash, jamais password. Le nom de colonne lui-même rend le stockage en clair impossible à écrire par accident — une règle imposée au niveau du prompt engineering.
• Clés étrangères au comportement de suppression intentionnel — ON DELETE CASCADE quand les enfants ne doivent pas survivre aux parents ; SET NULL quand les orphelins doivent survivre (des produits qui survivent à une catégorie supprimée).
• Contraintes CHECK pour les valeurs bornées — un statut de tâche ne peut pas devenir silencieusement "donee".
• Des index qui collent aux patterns de requête — clés étrangères, e-mail de lookup à la connexion, colonnes de tri.
• Des timestamps sur chaque table. Ennuyeux jusqu'à ce qu'on en ait besoin ; ensuite, critiques.

Pourquoi PostgreSQL et pas MongoDB ou Firebase ? Parce que les applis que les gens promptent sont massivement relationnelles — les commandes contiennent des articles, les tâches appartiennent à des projets, les projets appartiennent à des utilisateurs — et les clés étrangères avec contraintes expriment cela avec des garanties d'intégrité que les documents ne peuvent pas offrir. Et parce qu'une dépendance à un BaaS tiers casserait « un prompt, une appli déployée qui marche » avec la création d'un compte sur une deuxième plateforme. Postgres est ce que vous choisiriez à la main pour la production — c'est donc ce qui est généré.

Comment fonctionne l'authentification générée ?

Le flux d'auth complet, construit comme il se doit — parce que l'auth est la couche où les raccourcis générés deviennent des brèches :

• POST /api/auth/register — valide l'entrée, hache le mot de passe avec bcrypt (jamais en clair, jamais réversible), le stocke dans password_hash, renvoie un JWT.
• POST /api/auth/login — compare le hash bcrypt, émet un JWT signé en cas de succès. Même erreur pour mauvais e-mail et mauvais mot de passe (pas d'énumération de comptes).
• Middleware sur chaque route protégée vérifiant le JWT côté serveur ; le frontend l'attache automatiquement.
• Propriété au niveau ligne dans les requêtes — WHERE user_id = $1 à partir du token vérifié, pour qu'un ID changé dans l'URL ne puisse pas lire les lignes de quelqu'un d'autre.
• Rôles quand le prompt en demande (« l'admin peut gérer les produits ») — une colonne role vérifiée dans le middleware, des endpoints réservés à l'admin et une UI conditionnelle assortie.

À côté de l'auth, les défauts de sécurité non négociables : requêtes paramétrées partout (pas de SQL concaténé en chaînes), validation d'entrée côté serveur sur chaque endpoint, CORS restreint à l'origine de l'appli et rate limiting sur les endpoints d'auth. Relisez la logique d'autorisation générée avant le lancement comme celle d'un développeur junior rapide — les patterns sont bons ; les règles spécifiques de votre appli sur « qui peut voir les données de qui » méritent des yeux humains.

6 prompts complets à copier-coller pour des applis full-stack

Chacun est complet et sollicite délibérément la génération de backend — comptes, relations, rôles, agrégation. Collez tel quel.

1. Gestionnaire de tâches SaaS avec équipes :

Construis une appli de gestion de tâches nommée Taskframe où les utilisateurs s'inscrivent, créent des projets et ajoutent des tâches avec titre, description, priorité (basse/moyenne/haute), date d'échéance et statut (ouverte/en cours/faite). Les utilisateurs peuvent inviter des coéquipiers à un projet par e-mail ; les membres voient les projets partagés, mais seul le propriétaire du projet peut le supprimer ou retirer des membres. Vues : un tableau groupé par statut avec glisser-déposer entre colonnes, et une vue liste avec tri et filtres. Le dashboard montre mes tâches ouvertes tous projets confondus, triées par échéance, les en-retard en rouge. UI claire et épurée, accent indigo.

2. Boutique e-commerce avec panneau d'admin :

Crée une boutique en ligne de céramique artisanale nommée Kiln & Co. Les clients parcourent une grille de produits avec filtres par catégorie, consultent des pages de détail, ajoutent au panier et passent commande (formulaire d'adresse de livraison + paiement fictif), créant une commande avec historique sauvegardé dans leur compte. Rôle admin : espace /admin séparé avec gestion des produits (créer, modifier, archiver des produits avec nom, prix, stock, catégorie, description), liste des commandes avec mises à jour de statut (en attente/expédiée/livrée) et un récapitulatif du chiffre d'affaires par mois. Le stock décrémente à la commande ; les produits à stock nul affichent épuisé et ne peuvent pas être commandés. Design chaleureux et minimal, accent terracotta.

3. Plateforme de réservation :

Construis une appli de réservation pour un studio de yoga. Public : planning des cours de la semaine (nom, professeur, heure, places restantes), inscription et connexion. Les membres réservent une place dans un cours — capacité imposée côté serveur pour qu'un cours complet refuse d'autres réservations — et peuvent annuler jusqu'à 2 heures avant le début. La page mes réservations montre les cours à venir et passés. Rôle staff : créer et modifier les cours (nom, professeur, jour, heure, capacité), voir les listes par cours et pointer les présences. Empêche la double réservation du même membre dans le même cours. Design apaisant sauge et crème.

4. Board de feedback client :

Crée un board de feedback public façon outil minimal de roadmap produit. Toute personne connectée peut soumettre une idée (titre, description, catégorie) et upvoter les autres — un vote par utilisateur et par idée, togglable. Les idées se trient par votes ou par récence ; chacune a un fil de commentaires. Rôle admin : changer le statut d'une idée (à l'étude/planifiée/en cours/livrée), épingler des idées et supprimer le spam. La page publique de roadmap groupe les idées par statut en colonnes. Les changements de statut apparaissent dans un fil d'activité sur l'idée. Thème sombre, accent bleu électrique.

5. Appli de facturation :

Construis une appli de facturation pour freelances. Les utilisateurs gèrent des clients (société, nom du contact, e-mail, adresse) et créent des factures : client, lignes (description, quantité, prix unitaire), taux de taxe, date d'échéance et un numéro de facture séquentiel auto-généré par utilisateur. Statuts de facture : brouillon, envoyée, payée, en retard — le retard est calculé automatiquement depuis la date d'échéance. Dashboard : encours total, payé ce mois-ci, nombre de retards et un diagramme en barres du chiffre d'affaires sur 6 mois. Page de facture publique en lecture seule via un lien partageable avec une mise en page adaptée à l'impression. Design professionnel ardoise et blanc.

6. Plateforme communautaire de recettes :

Crée une plateforme communautaire de partage de recettes. Les utilisateurs s'inscrivent, publient des recettes (titre, placeholder photo, liste d'ingrédients, étapes numérotées, temps de cuisson, difficulté, tags) et ne modifient ou suppriment que les leurs. Tout le monde navigue par tag ou par recherche plein texte sur les titres et les ingrédients ; chaque recette a des notes en étoiles (une par utilisateur, modifiable) triées par note moyenne, plus des commentaires. Les profils utilisateurs montrent leurs recettes et leurs favoris enregistrés. Page d'accueil : mieux notées cette semaine et plus récentes. Le rôle modérateur peut retirer recettes et commentaires. Design frais vert et crème avec titres en serif.

Le pattern à lire : nommez les entités et leurs champs, dites qui peut faire quoi (« seul le propriétaire peut supprimer »), et mentionnez toute règle qui doit tenir (« capacité imposée côté serveur », « un vote par utilisateur »). Ces phrases deviennent des clés étrangères, du middleware et des contraintes.

Comment fonctionnent le déploiement et les aperçus pour les applis full-stack ?

Pendant la génération, le frontend tourne dans une microVM d'aperçu en direct avec hot reload, déjà en train de parler à la vraie API générée — l'inscription que vous testez dans l'aperçu écrit de vraies lignes que vous voyez immédiatement dans le navigateur de tables du panneau Backend, ou que vous requêtez en SQL brut. Le déploiement expédie le frontend sur l'edge de Cloudflare et le backend + PostgreSQL sur l'infrastructure de VULK — un clic, URL en production, domaines personnalisés pris en charge. Les déploiements backend + PostgreSQL sont inclus à partir de l'offre Builder ($19.99/mois) ; l'itération après déploiement reste la même boucle de prompts de suivi, avec les changements de schéma gérés comme des migrations plutôt que des reconstructions destructrices de données.

Peut-on tout exporter et partir ? (La réponse honnête)

La question à poser à toute plateforme avant d'avoir 10 000 utilisateurs. La réponse de VULK a une moitié forte et une moitié limitée — voici les deux, précisément :

Ce qui s'exporte proprement :

• La source frontend complète — téléchargement ZIP ou push GitHub ; un projet standard React + Vite + TypeScript sans dépendances propriétaires.
• Votre schéma complet — le schema.sql est livré dans l'export de la source.
• Toutes vos données — export CSV par table depuis le panneau Backend (la table entière, pas seulement la page visible), plus l'accès SQL brut via le query runner.

Ce qui ne s'exporte pas : le runtime du backend. Le moteur d'API qui sert les endpoints CRUD générés et l'auth est l'infrastructure hébergée de VULK, et le frontend exporté l'appelle à son URL hébergée. Exportez une appli full-stack et le frontend tourne partout — mais il continue de parler à l'API de VULK. Auto-héberger l'ensemble signifie ré-implémenter la couche API (avec votre schéma et vos données exportés comme spécification complète — une reconstruction bornée en Express-ou-autre, mais du vrai travail).

Pour situer comment le reste du marché répond à la même question : Lovable/Bolt ont la portabilité des données la plus propre — le projet Supabase est à vous, pg_dump et c'est parti (la logique backend en edge functions et politiques RLS doit quand même migrer). Replit donne l'accès complet au code ; c'est votre VM. Base44 n'a aucun export de backend. Les outils frontend-only esquivent la question en n'ayant jamais eu vos données. Quel que soit l'outil choisi : testez le chemin d'export la semaine un, pas le mois douze.