Qu'est-ce qu'un schéma de base de données ?

Un schéma de base de données est un plan qui définit comment les données sont organisées : classes, colonnes, types et relations, mais pas les données. La trinité en une ligne qui mérite d’être retenue : le schéma est le plan, une instance est l’état des données à un instant donné, et la base de données est le bâtiment entier. Les plans changent rarement et délibérément ; les pièces, elles, se remplissent en permanence.

Points clés

Le plan, mis par écrit

Un schéma dans sa langue natale — deux tables, des clés, une contrainte, un index et une vue, soit l’essentiel du vocabulaire :

CREATE TABLE users (
  id     bigserial PRIMARY KEY,
  email  text NOT NULL UNIQUE,               -- contrainte : pas de doublons
  role   text NOT NULL DEFAULT 'member'
);

CREATE TABLE orders (
  id      bigserial PRIMARY KEY,
  user_id bigint NOT NULL REFERENCES users(id),   -- relation
  total   numeric(10,2) CHECK (total >= 0),       -- règle que les données doivent respecter
  placed  timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX orders_by_user ON orders (user_id, placed);  -- couche physique
CREATE VIEW recent_orders AS                              -- couche des vues
  SELECT * FROM orders WHERE placed > now() - interval '30 days';

Le même plan sur une plateforme à schéma flexible pousse à partir de ce que vous enregistrez — des colonnes typées inférées à la première écriture, visibles immédiatement dans un dashboard :

// JavaScript / Node.js — Back4app JS SDK
// The schema grows typed columns from what you save
const event = new Parse.Object('Event');
event.set('name', 'Launch day');                          // String
event.set('seats', 120);                                  // Number
event.set('startsAt', new Date('2026-09-01T18:00:00Z'));  // Date
event.set('venue', new Parse.GeoPoint(38.72, -9.14));     // GeoPoint
await event.save(); // columns exist, typed, visible in the dashboard

// Flutter / Dart — Back4app Flutter SDK
// The schema grows typed columns from what you save
final event = ParseObject('Event')
  ..set('name', 'Launch day')                          // String
  ..set('seats', 120)                                  // Number
  ..set('startsAt', DateTime.parse('2026-09-01T18:00:00Z')) // Date
  ..set('venue', ParseGeoPoint(latitude: 38.72, longitude: -9.14));
await event.save(); // columns exist, typed, visible in the dashboard

// iOS / Swift — Back4app Swift SDK
// The schema is a typed struct — columns mirror the model
struct Event: ParseObject {
  var objectId: String?; var createdAt: Date?
  var updatedAt: Date?; var ACL: ParseACL?; var originalData: Data?
  var name: String?          // String column
  var seats: Int?            // Number column
  var startsAt: Date?        // Date column
  var venue: ParseGeoPoint?  // GeoPoint column
}
var event = Event(); event.name = "Launch day"; event.seats = 120
event.save { _ in } // columns exist, typed, visible in the dashboard

// Android / Kotlin — Back4app Android SDK
// The schema grows typed columns from what you save
val event = ParseObject("Event").apply {
  put("name", "Launch day")                          // String
  put("seats", 120)                                  // Number
  put("startsAt", Date())                            // Date
  put("venue", ParseGeoPoint(38.72, -9.14))          // GeoPoint
}
event.saveInBackground() // columns exist, typed, visible in the dashboard

Logique vs. physique vs. vue

La troisième ligne désamorce une ambiguïté réelle que la plupart des explications esquivent : dans certains moteurs, le mot désigne aussi un namespace — un conteneur de tables muni de permissions — de sorte que “le schéma” peut désigner le plan de votre application ou un dossier à l’intérieur de la base de données, et c’est le contexte qui tranche.

Schema-on-write vs. schema-on-read

Les bases de données “schemaless” ont bien un schéma — elles le facturent simplement autrement. Le schema-on-write valide la structure avant que les données n’atterrissent : mauvais type, champ manquant, référence cassée — rejetés à la porte. Le schema-on-read accepte les écritures avec souplesse et n’impose les attentes qu’à l’usage — itération plus rapide, et chaque lecteur devient un validateur. La position moderne est un curseur, pas une guerre : les plateformes documentaires ajoutent de la validation, les moteurs relationnels ajoutent des colonnes JSON, et les backends gérés coupent la poire en deux — types inférés et imposés par colonne, tandis que de nouvelles colonnes apparaissent sans cérémonie de migration. La question de la rigueur est en réalité une question de responsabilité : qui trouve l’enregistrement malformé, la base de données au moment de l’écriture ou votre code à 2 h du matin ?

Comment les schémas évoluent

Le plan survit à son premier jet, et les migrations sont la façon dont il change sans chaos : chaque changement de schéma est un script versionné — ajouter la colonne, la remplir rétroactivement, resserrer la contrainte — appliqué dans l’ordre, sur chaque environnement, relu comme le code qui en dépend. Deux disciplines portent l’essentiel de la valeur : rendre les changements rétrocompatibles pendant la fenêtre où ancien et nouveau code cohabitent (ajouter, puis migrer, puis supprimer — jamais renommer sur place), et garder la version du schéma dans le dépôt pour que code et structure voyagent ensemble. Sur les plateformes pilotées par dashboard, la même discipline s’applique avec un outillage différent — faites évoluer visuellement, mais délibérément, avec les changements de schéma pilotés par le client désactivés en production.

Cas d’usage courants

• Concevoir un nouveau backend. Le schéma est la sortie de la modélisation de données : entités et arêtes deviennent classes, colonnes et clés.
• Imposer l’intégrité. Les contraintes comme règles exécutables — totaux non négatifs, e-mails uniques — attrapées par le moteur, pas par des rapports de bug.
• Contrat d’équipe. Le schéma est le vocabulaire partagé entre backend, frontend et analytique ; un diagramme entité-association est une documentation qui ne peut pas dériver.
• Fondations de performance. Les index et l’organisation physique — l’étage du dessous du schéma — décident quelles requêtes restent rapides à l’échelle.
• Surface de sécurité. Les permissions au niveau du schéma contrôlent qui peut faire quoi par classe — structure et contrôle d’accès au même endroit.

Quelle rigueur pour votre schéma ? Matrice de décision

Le choix par défaut pragmatique pour un backend applicatif : flexible pendant que vous apprenez, durci au moment de livrer — inférez le schéma en développement, puis figez-le (aucun changement de schéma depuis le client, ajout de champ désactivé) le jour où les vrais utilisateurs arrivent.

Limites et trade-offs

• Le schéma fige des hypothèses. Chaque décision de type de colonne et de cardinalité est gratuite aujourd’hui et une migration demain — concevez pour la taille au-dessus.
• La rigueur taxe l’itération. Chaque expérimentation paie le péage de la migration ; c’est le prix des garanties, pas un défaut.
• La souplesse taxe les lecteurs. Le schema-on-read déplace la validation chez chaque consommateur ; sans discipline, “flexible” devient “cinq formes du même enregistrement”.
• La couche physique est invisible jusqu’à ce qu’elle ne le soit plus. Index et organisation ne changent pas l’exactitude des résultats — seulement la survie des requêtes à la croissance.
• Les permissions de namespace ne sont pas de la conception. CREATE SCHEMA organise et protège des objets ; il ne rend pas le plan bon pour autant.

Le schéma sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Le schéma y est une surface visible et de première classe : définissez classes et colonnes typées dans le dashboard, ou laissez le premier enregistrement les inférer — les onglets de code ci-dessus créent de vraies colonnes typées, avec objectId, createdAt, updatedAt et une ACL ajoutés par défaut à chaque classe. Tout ce que le schéma déclare se reflète instantanément dans les API générées automatiquement, est gardé par les permissions au niveau des classes et se parcourt dans le dashboard visuel — le plan, son application et la documentation en un seul artefact.