Comment ajouter une base de données à votre app (sans perdre de données plus tard)
Pour ajouter une base de données à votre app, choisissez une base relationnelle managée (Postgres est le choix habituel), conservez sa chaîne de connexion dans un secret côté serveur, créez une table par type d'élément que votre app stocke, et faites en sorte que votre backend — jamais le navigateur — lise et écrive dans cette base. Si vous créez votre app avec un outil d'IA, vous pouvez généralement écrire simplement « enregistre ceci dans une base de données » : l'agent crée les tables et le code. Votre rôle est de décrire clairement les données et de vérifier qu'elles sont bien conservées.
Ce guide explique quand vous avez besoin d'une base de données, les principales options, comment décrire vos données et les erreurs qui provoquent une perte ou une fuite de données.
Quand votre app a besoin d'une base de données
Vous avez besoin d'une base de données lorsque votre app doit se souvenir de quelque chose après la fermeture de la page, ou partager des données entre plusieurs personnes. Signes typiques :
- Des visiteurs envoient quelque chose : un formulaire, une inscription, une réservation, une commande
- Les utilisateurs ont des comptes avec leur propre contenu enregistré
- Un administrateur doit voir ou modifier ce que d'autres ont créé
- Vous voulez des rapports ou des comptages dans le temps
Vous n'en avez pas besoin pour un site statique où tout le monde voit le même contenu, comme un portfolio ou une simple page d'accueil. Si vous ne savez pas exactement ce qu'est une base de données, lisez d'abord qu'est-ce qu'une base de données.
Vos options
| Option | Ce que c'est | Idéal pour | Compromis |
|---|---|---|---|
| Base de données intégrée à votre outil de création | Une base créée et connectée à votre projet | La plupart des apps créées avec un outil d'IA | Liée à l'hébergement de cette plateforme ; l'export et les sauvegardes dépendent de la plateforme |
| Postgres ou MySQL managé | Une base relationnelle hébergée que vous souscrivez séparément | Les apps que vous hébergez vous-même, ou que plusieurs services partagent | Vous gérez les clés, les limites de connexions et les forfaits |
| Backend-as-a-service | Base de données, authentification, stockage et API dans un seul produit | Les apps orientées front-end qui veulent une connexion prête à l'emploi | Plus de concepts propres à un fournisseur à apprendre |
| Base de données documentaire (NoSQL) | Stocke des documents souples, de type JSON | Des données très irrégulières | Les relations et les rapports sont plus difficiles |
| Un tableur comme base de données | Google Sheets ou équivalent via une API | Petits outils internes, prototypes | Lent, sans vraies contraintes, se casse lors de modifications simultanées |
Pour la plupart des apps web petites et moyennes, une base relationnelle comme Postgres est le bon choix par défaut. Elle gère bien les relations (un client a plusieurs commandes), garantit la cohérence des données et permet de répondre plus tard à des questions avec SQL. Consultez qu'est-ce que Postgres pour une présentation en termes simples.
Décrivez vos données avant de créer
Le plus utile que vous puissiez faire est de noter les éléments que votre app stocke et comment ils sont liés. Vous n'avez pas besoin de jargon de base de données. Pour une app de réservation :
- Clients : nom, e-mail, téléphone
- Services : nom, durée, prix
- Réservations : quel client, quel service, heure de début, statut (en attente, confirmée, annulée)
Cela fait trois tables. « Quel client » et « quel service » deviennent des liens (clés étrangères) entre elles. Bien faire cela tôt compte beaucoup plus que n'importe quel choix technique, car modifier la structure de données qui contiennent déjà de vraies lignes est plus difficile que modifier la mise en page d'une page.
Quelques règles pratiques :
- Une table par type d'élément. Ne rangez pas les commandes dans une colonne de texte sur le client.
- Donnez à chaque ligne un identifiant et une date de création. Vous en aurez besoin plus tard.
- Utilisez les bons types. Les dates en tant que dates, les montants en centimes entiers ou en type décimal, pas en texte.
- Marquez les champs obligatoires comme tels. Laissez la base de données rejeter les données incorrectes, pas seulement le formulaire.
Exemples de prompts
Commencez par une seule fonctionnalité à la fois plutôt que de tout décrire d'un coup :
Ajoute une base de données à cette app. Crée une table de réservations avec le nom du client, l'e-mail, le service, l'heure de début et le statut (en attente, confirmée, annulée ; par défaut en attente). Enregistre les envois du formulaire de réservation dans cette table, affiche un message de succès, et ajoute une page d'administration qui liste les réservations de la plus récente à la plus ancienne.
Puis enrichissez-la :
Ajoute une table de services (nom, durée en minutes, prix en centimes). Remplace le champ de service en texte libre dans les réservations par un lien vers la table des services, et migre les réservations existantes sans en supprimer.
Et renforcez-la :
Assure-toi que toutes les lectures et écritures dans la base se font côté serveur. Le navigateur ne doit jamais recevoir la chaîne de connexion à la base. Valide l'e-mail et l'heure de début côté serveur avant l'insertion.
Étape par étape
- Listez vos données comme ci-dessus : les éléments, leurs champs et les liens entre eux.
- Créez la base de données. Dans un outil de création par IA, demandez-la dans le chat. Ailleurs, créez une instance Postgres managée et copiez sa chaîne de connexion.
- Stockez la chaîne de connexion comme secret (une variable d'environnement côté serveur), jamais dans le code. Voir variables d'environnement et secrets.
- Créez les tables. Utilisez des migrations, c'est-à-dire des scripts versionnés qui modifient la structure, pour que les changements soient reproductibles et réversibles.
- Construisez les routes serveur qui créent, lisent, modifient et suppriment des lignes (CRUD). Le navigateur appelle ces routes ; il ne parle jamais directement à la base.
- Reliez l'interface à ces routes : formulaires qui enregistrent, listes qui se chargent, états vides quand il n'y a encore rien.
- Testez la persistance. Envoyez quelque chose, rechargez la page, ouvrez l'app dans un autre navigateur. Si les données n'apparaissent pas, elles n'ont pas été enregistrées dans la base.
- Vérifiez les accès. Connectez-vous avec un second utilisateur et confirmez que vous ne pouvez pas voir ni modifier les données du premier.
- Publiez, puis testez à nouveau sur l'URL en ligne, car l'app publiée peut utiliser une connexion différente de celle de l'aperçu.
Erreurs courantes
- Enregistrer dans le navigateur et croire que c'est sauvegardé. localStorage semble fonctionner jusqu'à ce que quelqu'un ouvre l'app sur un autre appareil. Testez toujours dans un second navigateur.
- Mettre la chaîne de connexion dans le code front-end. N'importe qui peut lire le code front-end. Cela donne accès à toute votre base de données.
- Pas de contrôle d'accès. « Afficher mes commandes » doit filtrer par utilisateur connecté côté serveur, pas dans l'interface. C'est la faille de sécurité la plus fréquente des apps créées avec l'IA ; notre checklist de sécurité la couvre.
- Modifications destructives de la structure. Demander de « renommer la table » ou de « changer la structure » peut la supprimer puis la recréer. Quand des données réelles existent, dites « migre les lignes existantes, ne supprime rien ».
- Stocker des fichiers dans la base. Les images et les PDF doivent aller dans un stockage de fichiers, avec seulement leur URL ou leur clé dans une table. Voir comment ajouter le téléversement de fichiers.
- Aucune sauvegarde. Sachez comment votre plateforme sauvegarde les données et comment les restaurer avant d'avoir des clients.
Checklist
- Chaque type d'élément a sa propre table avec un identifiant et une date de création
- Les champs obligatoires et les types sont imposés par la base de données
- La chaîne de connexion n'existe que dans des secrets côté serveur
- Toutes les lectures et écritures passent par des routes serveur
- Chaque utilisateur ne peut lire et modifier que ses propres lignes
- Les données survivent à un rechargement et apparaissent dans un autre navigateur
- Les changements de structure passent par des migrations et conservent les lignes existantes
- Vous savez comment fonctionnent les sauvegardes et les restaurations
- L'app en ligne a été testée après publication
Ajouter une base de données dans Mythex
Sur Mythex, chaque projet peut obtenir sa propre base Postgres dédiée, sur les offres Free et Pro. En général, vous n'avez pas besoin de cliquer sur un bouton « rattacher » séparé : demandez-la dans le chat (« enregistre les e-mails de la liste d'attente dans une base de données ») ou tapez /database, et les informations de connexion sont injectées dans l'espace de travail et dans votre app publiée. Les paramètres du projet indiquent si une base est active.
La base se met en veille après 5 minutes d'inactivité et se réveille à la requête suivante. L'usage publié est facturé pour le temps pendant lequel elle a réellement été active, avec le même solde de crédits que vous utilisez pour créer. Si vous ajoutez une base après avoir déjà publié, publiez à nouveau pour que l'app en ligne la prenne en compte.
Voir Base de données et la recette Créer une app CRUD dans la documentation. Pour le côté connexion des données par utilisateur, lisez comment ajouter une connexion à votre app.
Questions
Ai-je besoin d'une base de données pour mon app ?
Oui, dès que votre app doit se souvenir de quelque chose entre deux visites ou partager des données entre plusieurs utilisateurs : inscriptions, commandes, réservations, publications ou paramètres. Un site statique qui affiche le même contenu à tout le monde n'en a pas besoin.
Quelle base de données utiliser pour une petite app web ?
Une base relationnelle comme Postgres est un choix sûr pour la plupart des petites apps web. Elle gère bien les utilisateurs, les commandes, les relations entre données et les rapports, elle est largement supportée, et on la dépasse rarement à petite échelle.
Puis-je stocker des données dans le navigateur au lieu d'une base de données ?
Le stockage du navigateur, comme localStorage, ne vit que sur un appareil, dans un navigateur, et l'utilisateur peut l'effacer à tout moment. Il convient à des préférences, comme le choix d'un thème, mais pas à ce que vous ou d'autres utilisateurs devez retrouver plus tard.
Mythex inclut-il une base de données ?
Oui. Un projet Mythex peut disposer de sa propre base Postgres dédiée, sur les offres Free et Pro. Vous la demandez dans le chat ou via la commande /database, et les informations de connexion sont injectées automatiquement. L'usage est payé avec le même solde de crédits que la création.