Qu'est-ce qu'un ORM ? Comment les applis parlent aux bases de données, expliqué

Un ORM (object-relational mapper) est une bibliothèque de code placée entre une appli et une base de données relationnelle. Au lieu d'écrire des requêtes en SQL, les développeurs manipulent les données sous forme d'objets ordinaires de leur langage de programmation — db.booking.create(...) ou Booking.find(...) — et l'ORM traduit cela en SQL, l'exécute, puis reconvertit les résultats en objets. Les exemples populaires sont Prisma et Drizzle pour TypeScript, SQLAlchemy pour Python et Entity Framework Core pour C#.

Pourquoi les ORM comptent quand on construit avec l'IA

Lorsqu'un créateur d'applis par IA ajoute une base de données à votre appli, il ajoute généralement aussi un ORM pour lui parler. Vous n'aurez pas à écrire de code ORM, mais il est utile de savoir qu'il est là :

• Votre modèle de données vit dans le code. Le fichier de schéma de l'ORM est souvent la description la plus claire des données de votre appli : quelles tables existent, quels champs elles ont et comment elles sont liées. Le lire permet de vérifier rapidement que l'IA a bien compris votre appli.
• Les modifications de la base passent par des migrations. Quand vous demandez « ajoute un numéro de téléphone aux clients », l'IA met à jour le modèle et crée une migration. Savoir cela aide à comprendre pourquoi une modification doit parfois être appliquée avant de fonctionner en production.
• Sécurité par défaut. Les ORM construisent les requêtes d'une façon qui protège contre l'injection SQL, l'une des failles les plus courantes dans les applis qui assemblent les requêtes à la main.
• Pièges de performance. Les ORM facilitent l'exécution accidentelle de centaines de petites requêtes là où une seule suffirait. C'est une cause fréquente de pages lentes dans les applis créées par IA.

Une analogie du quotidien

Imaginez un voyageur français et un commerçant japonais qui ne parlent pas la même langue et communiquent par un interprète.

Le voyageur (votre appli) dit : « Je voudrais les trois thés les moins chers que vous avez. » L'interprète (l'ORM) traduit cela en japonais précis (SQL), le transmet au commerçant (la base de données) et traduit la réponse en français.

Le voyageur n'apprend jamais le japonais, et pour la plupart des conversations c'est très bien. Mais pour une négociation complexe, il peut être utile de parler directement — c'est pourquoi la plupart des ORM permettent aux développeurs d'écrire du SQL brut quand c'est nécessaire.

Comment fonctionne un ORM

Des bases de données comme Postgres stockent les données dans des tables de lignes et de colonnes, et s'interrogent en SQL. Les langages de programmation travaillent avec des objets : une réservation avec une date, un client et un statut. L'ORM fait la correspondance entre les deux :

Ces quatre opérations sont les actions CRUD sur lesquelles repose presque toute appli.

Un exemple concret : des réservations avec Prisma

Voici un schéma Prisma simplifié pour une appli de réservation de salon de coiffure. Il décrit deux tables et leur lien :

model Customer {
  id       Int       @id @default(autoincrement())
  name     String
  email    String    @unique
  bookings Booking[]
}

model Booking {
  id         Int      @id @default(autoincrement())
  startsAt   DateTime
  service    String
  customer   Customer @relation(fields: [customerId], references: [id])
  customerId Int
}

En clair : un client a un nom, un e-mail unique et plusieurs réservations ; chaque réservation a une heure de début, une prestation et appartient à un seul client.

Maintenant, l'appli veut « les prochaines réservations de Lena, de la plus proche à la plus lointaine » :

const bookings = await db.booking.findMany({
  where: {
    customer: { email: "lena@example.com" },
    startsAt: { gte: new Date() },
  },
  orderBy: { startsAt: "asc" },
});

L'ORM transforme cela en SQL à peu près comme ceci, l'exécute et renvoie une liste d'objets réservation :

SELECT b.* FROM "Booking" b
JOIN "Customer" c ON c.id = b."customerId"
WHERE c.email = $1 AND b."startsAt" >= $2
ORDER BY b."startsAt" ASC;

Les $1 et $2 sont des emplacements réservés : l'e-mail et la date sont envoyés séparément du texte de la requête, ce qui empêche l'injection SQL.

Migrations

Si vous demandez ensuite « laisser les clients ajouter un numéro de téléphone », l'IA ajoute phone String? au modèle Customer (le ? signifie facultatif) et génère une migration — un petit script SQL du type ALTER TABLE "Customer" ADD COLUMN "phone" TEXT;. Les migrations sont enregistrées dans l'ordre, pour que chaque copie de la base puisse être amenée à la même structure, et l'historique des changements est conservé.

Les ORM courants par langage

Les ORM varient dans la mesure où ils masquent le SQL. Prisma utilise son propre langage de schéma et sa propre syntaxe de requêtes ; Drizzle reste volontairement proche de la forme du SQL tout en gardant tout typé. Des outils plus légers appelés query builders (constructeurs de requêtes), comme Knex ou Kysely pour TypeScript, aident à construire du SQL dans le code sans faire correspondre les lignes à des objets complets.

Termes clés

Idées reçues

• « Un ORM est une base de données. » Non. C'est un traducteur. Il faut toujours une base de données comme Postgres.
• « Avec un ORM, pas besoin de comprendre vos données. » Des tables mal conçues restent pénibles, même via un ORM. Un bon modèle de données compte plus que l'outil.
• « Les ORM sont toujours lents. » Les requêtes courantes vont très bien. La lenteur vient surtout de schémas comme les requêtes N+1 ou les index manquants, qui peuvent être corrigés.
• « ORM signifie aucun risque d'injection SQL, jamais. » Les méthodes standard d'un ORM sont sûres, mais du SQL brut écrit avec des saisies utilisateur collées directement reste dangereux.
• « Modifier le fichier de schéma change la base en production. » Seulement une fois qu'une migration est créée et appliquée à cette base.

Quoi demander à votre créateur d'applis par IA

• « Montre-moi le schéma de la base et explique chaque table et chaque relation en français simple. »
• « Quel ORM ce projet utilise-t-il, et où sont les migrations ? »
• « Avant de modifier une table, dis-moi si les données existantes seront affectées, et ne supprime jamais une colonne contenant des données sans me demander. »
• « Repère les pages les plus lentes qui font des requêtes N+1 et ajoute des index là où les listes sont filtrées ou triées. »
• « Assure-toi que chaque requête qui utilise une saisie utilisateur passe par l'ORM ou utilise des paramètres — aucun SQL construit par concaténation de chaînes. »

Les ORM dans Mythex

Quand votre appli doit enregistrer des données, Mythex ajoute une base Postgres dédiée au projet — demandez-le dans le chat ou utilisez la commande /database — et injecte ses informations de connexion dans l'espace de travail et dans l'appli publiée (Base de données). L'agent écrit ensuite le code qui lit et enregistre vos données. Si vous avez une préférence — « utilise Prisma », « utilise SQLAlchemy » ou « du SQL pur, pas d'ORM » — dites-le dans le chat. Demandez-lui de vous expliquer le schéma quand vous voulez vérifier la structure ; vous pouvez lire les fichiers dans l'éditeur de code. Pour une vue d'ensemble, voir qu'est-ce qu'une base de données et SQL ou NoSQL.

Questions