Qu'est-ce que le CRUD ? Créer, lire, mettre à jour, supprimer expliqué

CRUD signifie créer, lire, mettre à jour et supprimer — les quatre opérations de base qu'une appli effectue sur des données stockées. Ajouter un nouveau client, c'est créer ; afficher la liste des clients, c'est lire ; changer son numéro de téléphone, c'est mettre à jour ; le retirer, c'est supprimer. La plupart des applis professionnelles — CRM, systèmes de réservation, suivi de stock, tableaux d'administration — sont en grande partie du CRUD, avec des règles et une bonne mise en page par-dessus.

Pourquoi c'est important quand on construit avec l'IA

Le CRUD est le vocabulaire qui transforme une idée d'appli vague en demande précise. « Une appli pour gérer nos fournisseurs » laisse l'IA deviner. « Créer, lister, modifier et supprimer des fournisseurs, avec ces champs » lui indique exactement quels écrans, quelles opérations de base de données et quelles routes serveur construire.

Il fournit aussi une liste de contrôle pour tester. Pour chaque type d'enregistrement de votre appli, vous pouvez vous poser quatre questions : puis-je en ajouter un, les voir, en modifier un et en retirer un — et seules les bonnes personnes peuvent-elles faire chacune de ces actions ? Un nombre surprenant d'applis créées par IA permettent de créer des enregistrements sans pouvoir les modifier, ou laissent n'importe qui tout supprimer.

Une analogie du quotidien : une boîte de fiches de recettes

Imaginez une boîte de fiches de recettes sur une étagère de cuisine.

• Créer : rédiger une nouvelle fiche et la ranger.
• Lire : feuilleter la boîte, ou sortir la fiche de la lasagne.
• Mettre à jour : barrer « 200 g de fromage » et écrire « 250 g ».
• Supprimer : sortir une fiche et la jeter.

Ajoutez maintenant des règles : seul le chef peut jeter des fiches, chaque fiche doit avoir un titre, et personne ne peut ranger deux fiches avec le même nom. C'est une appli CRUD avec validation et permissions — ce qui est le cas de la plupart des applis réelles.

Comment le CRUD apparaît dans chaque couche

Chaque opération apparaît dans l'écran, le serveur et la base de données. Les voir côte à côte explique beaucoup de choses sur la façon dont les applis sont construites.

L'écran est le frontend, la requête API est la façon dont le frontend parle au backend, et le SQL est la façon dont le backend parle à la base de données. Si ces mots sont nouveaux, voir qu'est-ce qu'une API et qu'est-ce qu'une base de données.

Un exemple concret : un suivi de prêt de matériel

Le service multimédia d'un lycée prête caméras et micros aux élèves et perd sans cesse la trace du matériel. Il veut une appli simple.

Les enregistrements. Deux types de choses : le matériel (nom, type, numéro de série, état) et les prêts (quel matériel, quel élève, date de sortie, date limite, date de retour).

CRUD pour le matériel :

• Créer : le personnel ajoute une nouvelle caméra avec son numéro de série. Règle : les numéros de série doivent être uniques.
• Lire : une liste de tout le matériel, filtrable par type et par « disponible maintenant » ; une page de détail affichant l'historique des prêts d'un article.
• Mettre à jour : passer l'état à « à réparer ».
• Supprimer : en général pas une vraie suppression. Si une caméra ayant eu 30 prêts est supprimée, ces enregistrements de prêt perdent leur lien. On la marque donc « retirée » : elle disparaît de la liste des disponibles, mais son historique reste. C'est ce qu'on appelle une suppression logique.

CRUD pour les prêts :

• Créer : sortir un article pour un élève. Règle : on ne peut pas sortir un article déjà prêté.
• Lire : la liste des « prêts en retard » — celle où la date limite est dépassée et sans date de retour.
• Mettre à jour : enregistrer la date de retour quand l'article revient.
• Supprimer : réservé au personnel, pour les prêts saisis par erreur.

Permissions. Les élèves peuvent lire ce qui est disponible ; seul le personnel peut créer, modifier ou supprimer. Ces contrôles s'exécutent sur le serveur, pas seulement en masquant des boutons.

Voilà toute l'appli. Les parties intéressantes — pas de double prêt, une liste des retards, un historique par article — sont des règles et des requêtes par-dessus un CRUD simple.

Termes clés

• Enregistrement (ligne) : un élément, comme un fournisseur ou un prêt.
• Entité / ressource : un type d'enregistrement, comme « fournisseurs ». Chacun a en général sa propre table et son propre ensemble d'écrans CRUD.
• Validation : contrôles de la saisie — champs obligatoires, e-mail valide, quantité positive. À faire dans le formulaire par commodité et sur le serveur par sécurité.
• Suppression logique : marquer un enregistrement comme supprimé ou archivé au lieu de le retirer, pour que l'historique et les liens survivent.
• Pagination : afficher une longue liste une page à la fois, pour que l'appli reste rapide.
• Journal d'audit : un relevé de qui a créé, modifié ou supprimé quoi, et quand.
• Tableau d'administration : un ensemble d'écrans CRUD permettant au personnel de gérer les données d'une appli.

Erreurs courantes et idées reçues

• Oublier l'une des quatre opérations. Les applis sortent souvent avec la création et la lecture mais sans modification, donc chaque faute de frappe oblige à supprimer et ressaisir. Vérifiez les quatre pour chaque entité.
• Des suppressions qui cassent des choses. Supprimer un client qui a des factures peut laisser des factures orphelines ou effacer l'historique. Décidez pour chaque entité : bloquer la suppression, la supprimer logiquement, ou supprimer aussi les enregistrements liés.
• Des permissions uniquement dans l'interface. Masquer le bouton Supprimer n'empêche pas quelqu'un d'envoyer la requête DELETE. Le serveur doit vérifier qui demande.
• Mettre à jour par identifiant sans vérifier la propriété. Si l'utilisateur A peut modifier /api/notes/42 en changeant un numéro dans l'URL, il peut modifier la note de l'utilisateur B. Chaque mise à jour et suppression doit confirmer que l'enregistrement appartient au demandeur.
• Aucune confirmation à la suppression. Un seul clic malheureux ne doit pas détruire des données. Demandez une étape de confirmation, ou une annulation.
• « Le CRUD est basique, donc pas la peine de le construire. » Beaucoup de produits utiles sont des applis CRUD qui s'adaptent à un flux de travail mieux qu'un outil générique.

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

Utilisez ce modèle pour chaque entité, une à la fois :

Crée une fonctionnalité fournisseurs avec liste, création, modification et suppression. Champs : nom (obligatoire), e-mail de contact (e-mail valide), téléphone, catégorie (parmi : alimentaire, emballage, nettoyage), notes. Vue en liste avec recherche par nom et filtre par catégorie, 20 par page. Demande confirmation avant suppression ; si un fournisseur a des commandes, archive au lieu de supprimer. Seuls les membres du personnel connectés peuvent créer, modifier ou archiver — applique cela côté serveur.

Testez ensuite les quatre opérations, en tant qu'utilisateur autorisé et en tant que personne qui ne devrait pas avoir accès. Une fois une entité fonctionnelle, ajoutez la suivante. Comment créer un outil interne montre comment des écrans CRUD deviennent une appli d'administration complète, et qu'est-ce que Postgres explique la base de données sur laquelle reposent la plupart de ces applis.

Les applis CRUD sur Mythex

Les applis CRUD font partie des choses que les créateurs d'applis par IA font le mieux, et Mythex ne fait pas exception. Demandez dans le chat l'entité et ses champs, et Mythex attache une base Postgres au projet, crée la table et construit les écrans de liste, de formulaire et de détail dans un aperçu en direct ; vous pouvez ensuite lancer /test pour vérifier le parcours. La documentation propose une recette d'appli CRUD avec un prompt de départ, et le créateur d'outils internes ainsi que les modèles de tableaux de bord sont de bons points de départ.

Questions