---
term: 'Opérations CRUD'
seoTitle: "Qu'est-ce que CRUD ? Créer, lire, mettre à jour, supprimer expliqués"
headline: "Qu'est-ce que CRUD (créer, lire, mettre à jour, supprimer) ?"
slug: operations-crud
category: database
shortDefinition: "CRUD est l'acronyme de créer, lire, mettre à jour, supprimer — les quatre opérations de base que tout stockage de données persistant doit prendre en charge."
relatedTerms:
  - auto-generated-database-apis
  - rest-api
  - database-queries
  - backend-sdk
  - graphql-vs-rest
contrastsWith:
  - graphql-vs-rest
faq:
  - question: 'Que signifie CRUD ?'
    answer: "Create, Read, Update, Delete — créer, lire, mettre à jour, supprimer : les quatre opérations fondamentales du stockage persistant, et le minimum que toute application adossée à des données doit prendre en charge. L'acronyme a été popularisé par James Martin dans son livre de 1983 Managing the Data-base Environment, avec une sémantique associée formalisée par Haim Kilov en 1990 — ce qui en fait l'un des plus anciens termes encore utilisés chaque jour dans le vocabulaire du backend."
  - question: 'Comment CRUD se mappe-t-il sur SQL et sur HTTP ?'
    answer: "Deux mappings propres que chaque développeur mémorise une fois : en SQL, créer est INSERT, lire est SELECT, mettre à jour est UPDATE, supprimer est DELETE. Sur HTTP, créer est POST, lire est GET, mettre à jour est PUT pour un remplacement complet ou PATCH pour des changements partiels, et supprimer est DELETE — avec 201, 200 et 204 comme codes de statut du chemin nominal, respectivement."
  - question: 'CRUD est-il la même chose que REST ?'
    answer: "Non — ils répondent à des questions différentes. CRUD nomme ce que vous faites aux données ; REST est un style architectural pour la façon dont les clients interagissent avec des ressources sur HTTP, avec des contraintes comme l'absence d'état et une interface uniforme. Les endpoints REST se mappent souvent proprement sur CRUD, mais REST peut exposer des actions non-CRUD, et CRUD vit très bien hors de HTTP — dans des sessions SQL, des SDK et des files."
  - question: 'Quelle est la différence entre PUT et PATCH ?'
    answer: "La portée de la mise à jour. PUT remplace la ressource entière par la représentation que vous envoyez — idempotent par définition, puisque l'envoyer deux fois produit le même état. PATCH applique une modification partielle — seuls les champs que vous envoyez changent. La plupart du trafic réel de « mise à jour » a la forme d'un PATCH, ce qui explique pourquoi les méthodes save() des SDK n'envoient que les champs modifiés."
  - question: "Qu'est-ce qu'une app CRUD ?"
    answer: "Une application dont la boucle centrale consiste à créer, consulter, éditer et supprimer des enregistrements — panneaux d'administration, CMS, CRM, systèmes de stock et de réservation. C'est un terme légèrement dédaigneux qui ne devrait pas l'être : la majorité des logiciels métier sont du CRUD au fond, ce qui est exactement la raison pour laquelle les plateformes qui génèrent la couche CRUD automatiquement suppriment autant de travail."
  - question: "Qu'est-ce qu'un soft delete ?"
    answer: "Marquer un enregistrement comme supprimé — un flag ou un timestamp — au lieu de le retirer. Cela préserve l'historique d'audit, l'intégrité référentielle et l'annulation, au prix de filtrer chaque requête et de compliquer les contraintes d'unicité. Son pendant, le hard delete, est le retrait réel, que des régimes de confidentialité comme les demandes d'effacement du RGPD peuvent réellement exiger. La plupart des systèmes ont besoin d'une politique délibérée par classe, pas d'un comportement par défaut."
  - question: 'Quand CRUD ne suffit-il pas ?'
    answer: "Quand le domaine porte sur des événements et un historique plutôt que sur l'état courant. La mise à jour en place détruit le passé — l'event sourcing garde un journal en ajout seul et en dérive l'état ; CQRS sépare entièrement les modèles de lecture et d'écriture. Et des actions métier comme « approuver la facture » ou « passer commande » sont des workflows, pas des modifications de lignes — les modéliser comme de simples updates masque le domaine. CRUD est le plancher de l'accès aux données, pas le plafond."
  - question: 'Que sont les variantes de CRUD comme CRUDL et BREAD ?'
    answer: "Des extensions et des réécritures de la même idée : CRUDL ajoute List comme opération distincte de la lecture d'un seul enregistrement ; BREAD l'épelle Browse, Read, Edit, Add, Delete. Elles reconnaissent la vérité pratique que lister des collections — avec filtrage et pagination — est une opération à part entière avec ses propres décisions de conception, pas seulement « lire, au pluriel »."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Create, read, update and delete (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Create,_read,_update_and_delete'
  - name: 'CRUD — MDN Web Docs Glossary'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/CRUD'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'REST API guide'
    url: 'https://docs.parseplatform.org/rest/guide/'
cta:
  title: 'La couche CRUD, déjà écrite'
  text: "Définissez une classe sur Back4app et toute sa surface CRUD existe instantanément : endpoints REST, mutations GraphQL et méthodes de SDK pour chaque plateforme — avec permissions, hooks de validation et pagination intégrés. Les quatre verbes cessent d'être votre code."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-09'
translationKey: crud-operations
---

**CRUD est l'acronyme de créer, lire, mettre à jour, supprimer — les quatre opérations de base que tout stockage de données persistant doit prendre en charge.** Forgé dans *Managing the Data-base Environment* de James Martin (1983), il reste l'acronyme le plus durable du travail backend parce qu'il nomme le plancher : quoi que fasse votre système par ailleurs, les enregistrements doivent naître, être retrouvés, changer et disparaître.

## Points clés

| Question | Réponse |
| --- | --- |
| Les quatre verbes | Créer · Lire · Mettre à jour · Supprimer — le minimum de la persistance |
| En SQL | INSERT · SELECT · UPDATE · DELETE |
| Sur HTTP | POST · GET · PUT/PATCH · DELETE |
| vs. REST | CRUD est ce que vous faites aux données ; REST est la façon dont les clients atteignent les ressources |
| Le geste moderne | La couche CRUD se génère, elle ne s'écrit pas |

## CRUD en quatre langages

```sql
-- CRUD en SQL : le mapping d'origine
INSERT INTO tasks (title) VALUES ('Write the launch post');   -- C
SELECT * FROM tasks WHERE done = false;                       -- R
UPDATE tasks SET done = true WHERE id = 42;                   -- U
DELETE FROM tasks WHERE id = 42;                              -- D
```

Et le même cycle tel qu'un SDK l'exprime — la forme que la plupart du code applicatif écrit réellement :

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The full CRUD cycle on one object
const task = new Parse.Object('Task');
task.set('title', 'Write the launch post');            // C — create
await task.save();

const fetched = await new Parse.Query('Task')
  .equalTo('done', false).first();                     // R — read

fetched.set('done', true);                             // U — update
await fetched.save();

await fetched.destroy();                               // D — delete
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The full CRUD cycle on one object
final task = ParseObject('Task')..set('title', 'Write the launch post');
await task.save();                                     // C — create

final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false);
final fetched = (await query.query()).results!.first;  // R — read

fetched.set('done', true);
await fetched.save();                                  // U — update

await fetched.delete();                                // D — delete
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The full CRUD cycle on one object
var task = Task()
task.title = "Write the launch post"
let saved = try await task.save()                      // C — create

let fetched = try await Task.query("done" == false)
  .first()                                             // R — read

var updated = fetched
updated.done = true
_ = try await updated.save()                           // U — update

try await updated.delete()                             // D — delete
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The full CRUD cycle on one object
val task = ParseObject("Task").apply {
  put("title", "Write the launch post")
}
task.save()                                            // C — create

val fetched = ParseQuery.getQuery<ParseObject>("Task")
  .whereEqualTo("done", false).first                   // R — read

fetched.put("done", true)
fetched.save()                                         // U — update

fetched.delete()                                       // D — delete
```

## Un tableau pour les mapper tous

Le mapping à six colonnes qu'aucune référence n'assemble seule :

| Opération | SQL | Verbe HTTP | Statut | Base document | Idiome SDK/ORM |
| --- | --- | --- | --- | --- | --- |
| Créer | `INSERT` | POST | 201 | `insertOne` | `object.save()` (nouveau) |
| Lire | `SELECT` | GET | 200 | `find` / `findOne` | `query.find()` / `.get()` |
| Mettre à jour | `UPDATE` | PUT / PATCH | 200 | `updateOne` | `object.save()` (champs modifiés) |
| Supprimer | `DELETE` | DELETE | 204 | `deleteOne` | `object.destroy()` |

Deux notes de bas de page de [la spec HTTP](https://www.rfc-editor.org/rfc/rfc9110) qui valent vraiment la peine d'être connues : GET est *sûr* (aucun changement d'état), PUT et DELETE sont *idempotents* (répétables sans dommage), POST n'est ni l'un ni l'autre — c'est pourquoi la logique de retry les traite différemment, et pourquoi PUT signifie « remplacer le tout » quand PATCH signifie « modifier une partie ».

## Où se joue le CRUD

```mermaid
flowchart LR
  accTitle: Où se jouent les opérations CRUD dans un stack
  accDescr: Une interface utilisateur déclenche des appels SDK ou HTTP ; la couche API mappe les verbes sur des opérations, applique permissions et validation, et exécute les instructions de base de données correspondantes contre le stockage.
  UI["UI<br/>formulaires, listes, boutons"] --> API["Couche API<br/>verbes → opérations<br/>permissions · validation"]
  API --> DB[("Base de données<br/>INSERT · SELECT<br/>UPDATE · DELETE")]
```

Le diagramme est aussi le rappel de sécurité : chaque verbe traverse la couche API, qui est là où les permissions et la validation ont leur place — une surface CRUD sans contrôle d'accès par opération est une base de données publique avec des étapes en plus.

## CRUD vs. REST

| Question | CRUD | REST |
| --- | --- | --- |
| Ce que ça nomme | Des opérations sur les données | Un style architectural pour clients et ressources |
| Défini par | Quatre verbes | Des contraintes : sans état, interface uniforme, cacheable… |
| Vit où | SQL, SDK, files, n'importe où | API HTTP |
| Relation | Le payload habituel des endpoints REST | Se mappe souvent sur CRUD — mais peut exposer des actions non-CRUD |

La leçon pratique : une API REST est fréquemment une API CRUD habillée en HTTP — mais « approuver la facture » a sa place dans votre API et n'est pas un verbe CRUD, et CRUD existe très bien sans HTTP à l'horizon. Les termes coopèrent ; ils ne rivalisent pas.

## Cas d'usage courants

- **L'app CRUD proprement dite.** Panneaux d'administration, CMS, CRM, stock, réservations — la majorité des logiciels métier, honorablement.
- **Prototypage et MVP.** Les quatre verbes sur une poignée de classes *sont* la première version de la plupart des produits.
- **API générées automatiquement.** Schéma en entrée, surface CRUD en sortie — le choix par défaut moderne qui fait des quatre verbes de la configuration plutôt que du code, couvert en détail dans l'[entrée sur les API générées automatiquement](/glossary/fr/apis-generees-automatiquement/).
- **Outillage d'administration et de support.** Des grilles visuelles sur la même surface CRUD, permissions comprises.
- **Le substrat sous tout le reste.** Les systèmes event-sourced et lourds en workflows exposent quand même du CRUD quelque part — paramètres, profils, données de référence.

## Toute action doit-elle être du CRUD ? Matrice de décision

| Modélisez en CRUD quand… | Cherchez plus loin quand… |
| --- | --- |
| L'état courant de l'enregistrement est la vérité | L'historique *est* le domaine → event sourcing |
| L'édition est le modèle mental de l'utilisateur | Lectures et écritures montent en charge différemment → CQRS |
| « Supprimer » peut vraiment retirer | L'audit ou l'annulation exigent des soft deletes |
| Les éditions concurrentes sont rares | Les mises à jour perdues menacent → verrouillage optimiste, versions |
| L'action est « modifier cet enregistrement » | L'action est un verbe métier → nommez le workflow |

La dernière ligne est le design smell qui mérite d'être mémorisé : quand les noms d'endpoints dérivent vers `updateStatus`, le domaine réclame ses propres verbes.

## Limites et trade-offs

- **La mise à jour détruit l'historique.** La mutation en place est l'acte fondateur de CRUD et sa perte fondatrice — tout ce qui a besoin de « à quoi ça ressemblait mardi » veut de la journalisation ou des événements.
- **Supprimer est une politique, pas un verbe.** Soft vs. hard delete échange l'auditabilité contre l'effacement exigé par les régimes de confidentialité et la complexité des requêtes ; décidez par classe, délibérément.
- **Les accès concurrents n'ont pas de prix affiché.** Deux updates, le dernier écrivain gagne, le changement du premier disparaît en silence — champs de version et saves conditionnels sont l'antidote standard.
- **List est le cinquième verbe.** Filtrage, tri et pagination portent l'essentiel du trafic réel de lecture et l'essentiel des bugs de performance — la raison d'être de CRUDL et BREAD.
- **Les API CRUD peuvent devenir anémiques.** Une surface qui n'est que lignes-en-entrée-lignes-en-sortie pousse la logique métier vers les clients ; gardez les workflows côté serveur, à côté des données.

## Les opérations CRUD 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. Sa relation avec cet article est une soustraction : définissez une classe et toute la matrice CRUD ci-dessus existe d'un coup — des [endpoints REST](https://docs.parseplatform.org/rest/guide/) selon la colonne HTTP, des mutations GraphQL et les idiomes de SDK des onglets de code, avec des permissions au niveau des classes qui gardent chaque verbe et des triggers beforeSave qui portent la validation. Les quatre verbes cessent d'être votre code et deviennent votre vocabulaire.