Comment générer des bases de données d'application avec l'IA sans enfreindre les règles de conception

Vous avez probablement vu les démos de générateurs de code propulsés par l’IA. Vous tapez un prompt du type “construis un SaaS de gestion de projet multi-tenant”, et quelques minutes plus tard, vous avez un magnifique tableau de bord, un routeur frontend et un schéma de base de données généré en arrière-plan. Cela semble incroyablement rapide, mais dès que l’on regarde sous le capot - particulièrement le schéma de la base de données - la magie commence à montrer ses failles.

Les grands modèles de langage (LLM) sont excellents pour prédire du texte et écrire des composants d’interface, mais ils ne comprennent pas l’algèbre relationnelle. Lorsqu’un agent IA structure une base de données, il optimise le chemin le plus court pour afficher un élément visuel. Le résultat est presque toujours une collection de tables plates, dénormalisées et fragiles qui planteront dès que vous chargerez de vraies données de production.

Si vous construisez une application avec des générateurs de code IA modernes comme Bolt ou Lovable, vous ne pouvez pas laisser l’IA prendre des décisions arbitraires sur la base de données. Vous devez la guider. Vous pouvez écrire des prompts qui forcent l’IA à respecter les règles classiques des bases de données, à garder vos schémas relationnels propres et à protéger l’intégrité de vos données.

Pourquoi les LLM échouent-ils dans la conception de bases de données relationnelles

Les moteurs de base de données fonctionnent sur une théorie mathématique stricte des ensembles. Pour éviter les anomalies de données, les conflits de mise à jour et les requêtes lentes, une base de données nécessite un modèle relationnel structuré. Les LLM, en revanche, fonctionnent sur la probabilité sémantique. Ils écrivent des schémas basés sur ce qui semble visuellement plausible dans le code, ce qui introduit trois défaillances architecturales courantes.

Le piège de la table plate dénormalisée

Les outils d’IA détestent créer des tables de jointure. Pour un LLM, il est beaucoup plus facile de créer une seule table users et d’y entasser une liste de tags séparés par des virgules dans un champ texte que de mettre en place une véritable table de liaison. Lorsque votre frontend doit filtrer les utilisateurs par tags, l’IA écrit des expressions régulières complexes et non indexées pour analyser ce champ texte. Cette approche fonctionne très bien avec trois enregistrements de test dans votre navigateur, mais elle fera s’effondrer le CPU de votre base de données dès que votre base d’utilisateurs augmentera.

Le contournement des contraintes

Dans une base de données relationnelle, les contraintes sont votre dernière ligne de défense. Elles empêchent les enregistrements vides, garantissent des emails uniques et assurent que la suppression d’un enregistrement parent nettoie ses enregistrements enfants. Comme les contraintes nécessitent une configuration logique stricte, les générateurs d’IA les omettent régulièrement. Ils créeront des tables sans clés primaires, oublieront les indicateurs NOT NULL sur les champs obligatoires et ignoreront complètement les clés étrangères. Cela rend la base de données extrêmement fragile : un seul bug dans votre couche applicative peut corrompre l’ensemble de vos données.

Dérive du schéma et boucles de régression

Si vous laissez votre constructeur IA générer des modifications de base de données progressivement alors que vous modifiez visuellement le frontend, vous rencontrerez rapidement une dérive du schéma. L’IA écrira un nouveau fichier de migration qui entre en conflit avec vos tables existantes, supprimera des colonnes contenant des données réelles pour résoudre un conflit de renommage, ou créera des tables redondantes pour supporter un nouveau composant visuel.

Pour éviter ces problèmes, vous devez imposer les règles des bases de données relationnelles dès le premier prompt.

Règle 1 : Imposer la troisième forme normale (3NF)

Pour garder vos données propres et vos requêtes rapides, vos tables doivent être normalisées. La normalisation est le processus d’organisation des données pour minimiser la redondance et la dépendance. Dans une application professionnelle, vous devriez viser la troisième forme normale (3NF).

Pour obtenir des tables normalisées de la part d’une IA, vous devez définir explicitement comment elle doit gérer les attributs :

• Première forme normale (1NF) : Chaque colonne doit contenir des valeurs atomiques (indivisibles). L’IA ne doit jamais stocker de listes séparées par des virgules, de tableaux JSON ou de chaînes semi-structurées dans un seul champ de base de données.
• Deuxième forme normale (2NF) : Tous les attributs non-clés doivent dépendre entièrement de la clé primaire. Si une table a une clé composite, chaque colonne doit se rapporter à l’ensemble de la clé, et non à une partie seulement.
• Troisième forme normale (3NF) : Aucune colonne ne doit dépendre d’une autre colonne non-clé (pas de dépendances transitives). Par exemple, si vous avez une table projects, ne stockez pas le nom et le téléphone du client directement dedans. Le projet doit être lié à une table clients via une clé étrangère, et les détails du client doivent se trouver là-bas.

Le modèle de prompt de normalisation

Lors de l’initialisation d’une base de données via SQL DDL ou en guidant votre constructeur IA, utilisez une règle système explicite :

“Lors de la génération du schéma de base de données relationnelle, conçois toutes les tables en troisième forme normale (3NF). N’utilise pas de tableaux JSON, de colonnes JSONB ou de champs texte séparés par des virgules pour stocker des attributs ou des relations multi-valeurs. À la place, extrais-les dans des tables enfants normalisées ou des tables de jointure avec des contraintes de clés étrangères. Assure-toi que les attributs non-clés dépendent strictement de la clé primaire, en évitant les dépendances transitives.”

En forçant l’IA à travailler avec ces contraintes, vous l’empêchez de prendre des raccourcis qui augmenteraient la charge de développement côté interface utilisateur.

Règle 2 : Définir explicitement les contraintes d’intégrité des données

Une base de données sans contraintes est une bombe à retardement. Si vous voulez une base de données qui reste propre et cohérente, vous devez demander à l’IA d’écrire des règles explicites directement dans la définition du schéma SQL.

Clés primaires et étrangères

Exigez systématiquement que chaque table possède une clé primaire unique et clairement définie. Pour les applications web modernes, les UUID sont généralement préférés aux entiers auto-incrémentés, car ils empêchent les attaques par énumération d’ID et permettent de générer des ID en toute sécurité côté client avant l’écriture en base de données.

De plus, chaque relation doit utiliser des clés étrangères explicites. Si une table tasks possède un champ project_id, ce champ doit pointer directement vers la table projects. Vous devez également demander à l’IA de spécifier les comportements de suppression :

• Utilisez ON DELETE CASCADE si l’enregistrement enfant doit être supprimé quand le parent l’est (ex: supprimer un projet doit supprimer ses tâches).
• Utilisez ON DELETE RESTRICT ou ON DELETE SET NULL si les enregistrements enfants doivent rester intacts (ex: supprimer un utilisateur ne doit pas supprimer l’historique des logs d’équipe qu’il a écrits).

Contraintes Not Null, Unique et Check

Ne laissez jamais l’IA créer des colonnes acceptant des valeurs NULL par défaut, sauf si le champ est réellement optionnel. Les champs d’email, les noms d’utilisateur et les ID d’organisation doivent toujours être définis en NOT NULL.

Des contraintes d’unicité doivent être explicitement définies sur des champs comme les emails, les tokens ou les slugs personnalisés. Enfin, les contraintes de vérification (CHECK) sont très utiles pour empêcher des états de données invalides avant qu’ils n’atteignent vos tables. Par exemple, une colonne status devrait être limitée à une liste spécifique de chaînes (comme pending, active ou archived).

Le modèle de prompt d’intégrité

Intégrez ces règles dans votre flux de génération :

“Pour chaque table de base de données, tu dois définir une clé primaire utilisant des UUID. Chaque relation doit être appliquée avec une contrainte de clé étrangère, en précisant explicitement la politique de suppression (utilise CASCADE pour les sous-ressources appartenant à l’entité, et RESTRICT ou SET NULL pour les entités indépendantes). Applique NOT NULL à tous les champs obligatoires. Utilise des contraintes UNIQUE pour les colonnes d’identification unique, et des contraintes CHECK pour limiter les colonnes de statut à des ensembles de chaînes valides.”

Règle 3 : Concevoir des tables de jointure relationnelles

Les relations plusieurs-à-plusieurs sont un point de défaillance courant pour les générateurs d’IA. Si les utilisateurs peuvent appartenir à plusieurs espaces de travail, ou si des projets peuvent avoir plusieurs tags, vous avez besoin d’une table de jointure pour les connecter.

Une table de jointure correcte doit contenir :

• Une clé étrangère pointant vers la première table.
• Une clé étrangère pointant vers la seconde table.
• Une clé primaire composite composée des deux clés étrangères pour éviter les relations en double.
• Des règles de suppression en cascade pour que la suppression d’un utilisateur ou d’un espace de travail nettoie automatiquement l’enregistrement de jointure.

Lorsque vous guidez votre IA, elle essaiera souvent de contourner cette structure car la gestion des jointures dans les composants React demande un peu plus de code frontend. Vous devez résister. Forcez l’IA à utiliser des tables de jointure et laissez-la écrire les requêtes relationnelles (via des instructions JOIN en SQL ou des requêtes relationnelles dans les bibliothèques client Supabase) pour charger les données.

Le flux de travail du constructeur pragmatique : Le schéma d’abord

Pour garder le contrôle total de votre application, vous devriez séparer la conception de la base de données du développement frontend. Laisser une IA écrire votre schéma de base de données pendant qu’elle conçoit vos boutons est la recette idéale pour des boucles de régression.

Suivez plutôt ce flux de travail :

1. Concevoir le schéma d’abord : Demandez à l’IA d’écrire un fichier SQL DDL brut basé sur les règles établies.
2. Réviser le SQL manuellement : Assurez-vous que chaque table est normalisée, que les contraintes sont définies et que les index sont configurés sur les clés étrangères.
3. Exécuter les migrations : Lancez le script SQL directement dans votre éditeur de base de données (comme l’éditeur SQL de Supabase).
4. Importer le schéma dans votre constructeur : Une fois que les tables sont actives, demandez à votre constructeur IA (comme Lovable ou Bolt) de lire le schéma existant plutôt que d’en générer un nouveau.

Cette approche “schéma d’abord” garantit que votre base de données reste propre, standard et parfaitement structurée, même quand l’IA écrit le code frontend.

Une alternative : Le No-Code structuré sans surcharge de base de données

Gérer les migrations SQL, les contraintes de clés étrangères et les structures normalisées demande beaucoup d’efforts de développement, même avec l’aide de l’IA. Si vous créez des outils internes, des annuaires ou des portails clients, vous n’avez pas toujours besoin de gérer une base de données Postgres brute.

C’est là que les constructeurs visuels structurés comme Softr offrent une approche différente. Plutôt que d’écrire du SQL DDL, vous pouvez connecter votre application directement à des plateformes de données structurées comme Airtable, Google Sheets ou SmartSuite.

Ce modèle offre plusieurs avantages distincts :

• Gestion visuelle des relations : Vous pouvez configurer des champs relationnels (comme lier un client à un projet) visuellement dans votre source de données, sans vous soucier des tables de jointure SQL ou des politiques de suppression de clés étrangères.
• Permissions utilisateurs granulaires : Softr gère les permissions et les rôles des utilisateurs visuellement dans l’éditeur, ce qui signifie que vous n’avez pas à écrire des politiques de sécurité de base de données complexes (comme la Row Level Security de Postgres) pour protéger les données clients.
• Développement prévisible : Comme vous configurez des composants pré-construits plutôt que de demander à un LLM de régénérer du code, vous évitez les boucles de régression qui affectent les applications générées. Vous pouvez modifier votre mise en page ou ajouter de nouveaux champs sans risque de casser les requêtes existantes.

Si vous avez besoin d’un MVP SaaS très personnalisé avec des calculs complexes en arrière-plan, l’utilisation de schémas de base de données pour un backend Postgres est une excellente voie. Mais si vous devez déployer un outil opérationnel, utiliser un outil structuré comme Softr vous épargnera des heures de maintenance de base de données.