Qu'est-ce qu'une base de données ? Guide pour les créateurs d'applications
Une base de données est un stock d'informations organisé, dans lequel une application écrit et lit — ses utilisateurs, commandes, réservations, messages. Contrairement aux informations conservées uniquement dans un onglet de navigateur, les données d'une base restent là après un rechargement ou un redémarrage, et tous ceux qui utilisent l'application voient les mêmes enregistrements. La plupart des bases organisent les données en tables, un peu comme les feuilles d'un tableur, mais avec des règles strictes qui garantissent leur cohérence.
Pourquoi c'est important quand on construit avec l'IA
La surprise la plus courante pour qui construit avec l'IA est une application qui semble terminée mais oublie tout. Vous ajoutez un client, vous rechargez la page, et il a disparu. Cela signifie en général que l'application gardait les données dans la mémoire du navigateur, et non dans une base de données.
Une base de données est aussi l'endroit où vivent beaucoup de vos décisions les plus importantes, que vous en ayez conscience ou non :
- Ce que vous enregistrez. Si vous ne stockez pas le statut d'une réservation, vous ne pourrez pas afficher lesquelles ont été annulées.
- Comment les choses se relient. Qu'un client puisse avoir plusieurs réservations, ou qu'une réservation regroupe plusieurs prestations, façonne toute l'application.
- Qui peut voir quoi. La plupart des erreurs de confidentialité concernent les enregistrements qu'un utilisateur peut lire.
Vous n'avez pas besoin de concevoir vous-même la base de données. Mais comprendre les bases vous permet de décrire clairement vos données et de repérer les problèmes tôt.
Une analogie du quotidien
Imaginez une armoire à dossiers bien tenue dans un petit bureau.
Chaque tiroir contient un type de chose : un tiroir pour les clients, un pour les rendez-vous, un pour les factures. Dans chaque tiroir, chaque dossier suit le même format, avec les mêmes champs remplis. Chaque dossier a un numéro de référence unique, et lorsqu'une facture appartient à un client, le dossier de la facture note le numéro de ce client au lieu de photocopier tout son dossier.
C'est une base relationnelle. Les tiroirs sont les tables, les dossiers sont les lignes, les champs sont les colonnes, les numéros de référence sont les clés primaires, et les notes qui pointent vers un autre dossier sont les clés étrangères. Un bon responsable de bureau applique aussi des règles — pas de rendez-vous sans date, pas deux clients avec le même numéro — comme le fait une base de données.
Un exemple concret : une application de réservation pour un salon de coiffure
Imaginons que vous demandiez à une IA de construire un site de réservation pour un salon de coiffure. Une base sensée comporterait quatre tables.
services
| id | nom | durée_minutes | prix |
|---|---|---|---|
| 1 | Coupe | 45 | 40,00 |
| 2 | Coloration | 90 | 95,00 |
personnel
| id | nom | |
|---|---|---|
| 1 | Sara | sara@example.com |
| 2 | Omar | omar@example.com |
clients
| id | nom | téléphone | |
|---|---|---|---|
| 101 | Lena Park | lena@example.com | 555-0100 |
réservations
| id | client_id | service_id | personnel_id | début | statut |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmée |
Regardez la table réservations. Elle ne recopie pas le nom et le téléphone de Lena dans chaque réservation ; elle stocke client_id = 101. Si Lena change de numéro de téléphone, cela change à un seul endroit, et chaque réservation affiche le nouveau. C'est l'idée centrale d'une base relationnelle : stocker chaque information une seule fois, et faire des liens vers elle.
La même structure répond à des questions utiles :
- « Quels créneaux sont libres pour Omar vendredi ? » — regarder les réservations d'Omar ce jour-là.
- « Combien ont rapporté les colorations ce mois-ci ? » — relier les réservations aux prestations et additionner les prix.
- « Quels clients n'ont pas réservé depuis 90 jours ? » — comparer les clients à leur dernière réservation.
Termes courants expliqués
| Terme | Signification |
|---|---|
| Table | Un ensemble d'enregistrements d'un même type, comme les clients ou les réservations. |
| Ligne (enregistrement) | Un élément d'une table : un client, une réservation. |
| Colonne (champ) | Une information que chaque ligne possède, comme l'e-mail ou le prix. |
| Clé primaire | Un identifiant unique pour chaque ligne, en général un nombre ou une chaîne aléatoire. |
| Clé étrangère | Une colonne qui pointe vers une ligne d'une autre table, comme client_id dans les réservations. |
| Schéma | La conception d'ensemble : quelles tables existent, leurs colonnes et leurs liens. |
| Requête | Une demande pour lire ou modifier des données, par exemple « toutes les réservations de demain ». |
| SQL | Structured Query Language, le langage standard pour interroger les bases relationnelles. |
| Migration | Une modification du schéma enregistrée et reproductible, comme l'ajout d'une colonne. |
| Index | Une structure de recherche qui accélère les recherches sur une colonne, comme l'index d'un livre. |
| CRUD | Create, Read, Update, Delete — les quatre opérations de base que font les applications sur les données. |
| Sauvegarde | Une copie des données que vous pouvez restaurer en cas de problème. |
Types de bases de données
| Type | Mode de stockage | Exemples | Adapté à |
|---|---|---|---|
| Relationnelle (SQL) | Tables aux colonnes fixes et liens entre elles | Postgres, MySQL, SQLite | La plupart des applications professionnelles : réservations, boutiques, CRM, SaaS |
| Documentaire (NoSQL) | Documents souples de type JSON | MongoDB, Firestore | Des données dont la forme varie beaucoup d'un enregistrement à l'autre |
| Clé-valeur | Une valeur stockée sous une clé | Redis | Le cache, les données de courte durée comme les sessions |
Pour presque tout ce qu'un entrepreneur ou une petite entreprise construit en premier, une base relationnelle est le choix sûr par défaut.
Où se situe la base de données dans votre application
Les visiteurs ne parlent jamais directement à la base de données. La page dans leur navigateur (le frontend) demande des données à votre serveur (le backend), généralement via une API. Le serveur vérifie qui demande et si la personne en a le droit, interroge la base de données, puis renvoie uniquement ce que cette personne doit voir.
Cette étape intermédiaire est importante. Si le navigateur pouvait interroger directement la base avec un accès complet, n'importe qui pourrait ouvrir les outils de développement et tout lire.
Erreurs courantes et idées reçues
- Garder les données uniquement dans le navigateur. Le stockage du navigateur (comme localStorage) reste sur un seul appareil et dans un seul navigateur. C'est acceptable pour un filtre mémorisé, pas pour des commandes.
- Tout entasser dans une seule table. Une seule table « réservations » qui recopie le nom du client, son téléphone et le prix de la prestation dans chaque ligne se désynchronise très vite.
- Stocker les mots de passe en clair. Les mots de passe doivent être hachés, jamais stockés lisibles. Voir qu'est-ce que l'authentification.
- Aucune règle sur les données. Sans champs obligatoires et règles d'unicité, vous obtiendrez des réservations sans date et des clients en double.
- Oublier la suppression. Décidez si supprimer un client supprime ses réservations, les conserve, ou est bloqué.
- Utiliser les données de production pour expérimenter. Testez les modifications risquées ailleurs, en sécurité, et conservez des sauvegardes.
- Considérer le tableur comme la base de données pour toujours. Les tableurs sont parfaits pour démarrer, mais ils peinent avec de nombreux utilisateurs simultanés et les droits. Voir comment transformer un tableur en application.
Ce qu'il faut demander à votre créateur par IA
- « Enregistre ceci dans une base de données, pas dans le navigateur. Dis-moi quelles tables tu vas créer. »
- « Montre-moi le schéma sous forme de tableau simple : chaque table, ses colonnes et la manière dont elles se relient. »
- « Un client peut avoir plusieurs réservations ; chaque réservation a exactement une prestation et un membre du personnel. »
- « Rends l'e-mail obligatoire et unique pour les clients. »
- « Empêche deux réservations du même membre du personnel de se chevaucher. »
- « Seul le propriétaire connecté peut lire toutes les réservations ; les clients ne voient que les leurs. Applique cela côté serveur. »
- « Quand je supprime une prestation, ne supprime pas les réservations passées : désactive simplement la prestation. »
Bases de données dans Mythex
Quand votre application doit enregistrer des données, Mythex ajoute au projet une base Postgres dédiée — vous pouvez le demander dans le chat (« enregistre les inscriptions à la liste d'attente dans une base de données ») ou utiliser la commande /database. Les informations de connexion sont transmises automatiquement à votre application, et l'agent crée les tables. La base se met en veille après cinq minutes d'inactivité et se réveille à la requête suivante ; l'usage en ligne est facturé pour le temps pendant lequel elle a été éveillée, sur le même solde de crédits que la construction. Elle est disponible sur les formules Free et Pro. La documentation sur les bases de données détaille le fonctionnement, et les modèles d'applications proposent des points de départ basés sur les données.
Questions
Qu'est-ce qu'une base de données, en termes simples ?
Une base de données est un stock d'informations organisé dans lequel une application peut écrire et lire, par exemple des utilisateurs, des commandes ou des réservations. Contrairement aux données conservées uniquement dans un onglet de navigateur, elles restent là après un rechargement, un redémarrage, ou lorsqu'on ouvre l'application depuis un autre appareil.
Un tableur est-il une base de données ?
Un tableur peut contenir le même type de données, mais il n'est pas conçu pour les applications. Une vraie base de données impose des règles sur le contenu de chaque colonne, relie les tables de façon fiable, gère de nombreuses personnes qui écrivent en même temps et contrôle qui peut lire quoi.
Quelle est la différence entre les bases SQL et NoSQL ?
Les bases SQL (relationnelles), comme Postgres et MySQL, stockent les données dans des tables aux colonnes définies, reliées entre elles. Les bases NoSQL, comme MongoDB, stockent des documents plus souples. La plupart des applications professionnelles — réservations, CRM, boutiques — s'adaptent très bien au modèle relationnel.
Mon application a-t-elle besoin d'une base de données ?
Si elle doit retenir quoi que ce soit saisi par les personnes — inscriptions, commandes, messages, réglages — et l'afficher plus tard ou à quelqu'un d'autre, oui. Un site purement informatif, sans formulaire qui enregistre des données, n'en a généralement pas besoin.