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

CRUD signifie create, read, update et delete — soit créer, lire, mettre à jour et supprimer, les quatre opérations de base d'une app 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; et le retirer, c'est supprimer. La plupart des apps d'affaires — CRM, systèmes de réservation, suivis d'inventaire, panneaux d'administration — sont en grande partie du CRUD auquel on ajoute des règles et une bonne présentation.

Pourquoi c'est important quand vous construisez avec l'IA

Le CRUD est le vocabulaire qui transforme une idée d'app vague en demande précise. « Une app 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 vous donne aussi une liste de vérification pour tester. Pour chaque type d'enregistrement de votre app, vous pouvez poser quatre questions : puis-je en ajouter un, les voir, en modifier un et en retirer un — et seules les bonnes personnes peuvent faire chacune de ces actions? Un nombre surprenant d'apps construites par IA permettent de créer des enregistrements sans pouvoir les modifier, ou laissent n'importe qui tout supprimer.

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

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

• Créer : écrire une nouvelle fiche et la ranger.
• Lire : feuilleter la boîte, ou sortir la fiche des lasagnes.
• 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 en chef peut jeter des fiches, chaque fiche doit avoir un titre, et personne ne peut ranger deux fiches au même nom. C'est une app CRUD avec validation et permissions — ce que sont la plupart des vraies apps.

Comment le CRUD se retrouve à chaque niveau

Chaque opération apparaît à l'écran, sur le serveur et dans la base de données. Les voir côte à côte explique beaucoup de choses sur la construction des apps.

L'écran est l'interface, la requête API est la façon dont l'interface parle au serveur, et le SQL est la façon dont le serveur 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 d'équipement

Le département média d'une école prête des caméras et des microphones aux élèves et perd constamment la trace de ce matériel. Il veut une app simple.

Les enregistrements. Deux types de choses : équipement (nom, type, numéro de série, état) et prêts (quel équipement, quel élève, date de sortie, date de retour prévue, date de retour effectif).

CRUD pour l'équipement :

• 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 l'équipement, filtrable par type et par « disponible maintenant »; une page de détail montrant l'historique des prêts d'un article.
• Mettre à jour : changer l'état en « à réparer ».
• Supprimer : habituellement pas une vraie suppression. Si une caméra ayant eu 30 prêts est supprimée, ces prêts perdent leur lien. Il vaut mieux la marquer « retirée » pour qu'elle disparaisse de la liste des disponibles, tout en conservant son historique. C'est ce qu'on appelle une suppression logique.

CRUD pour les prêts :

• Créer : sortir un article à un élève. Règle : on ne peut pas sortir un article déjà prêté.
• Lire : « prêts en retard » — une liste où la date de retour est passée et où il n'y a pas de date de retour effective.
• 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 consulter ce qui est disponible; seul le personnel peut créer, modifier ou supprimer. Ces vérifications s'exécutent sur le serveur, et pas seulement en cachant des boutons.

C'est toute l'app. Les parties intéressantes — pas de double prêt, une liste de retards, un historique par article — sont des règles et des requêtes par-dessus le CRUD de base.

Termes clés

• Enregistrement (ligne) : un élément, comme un fournisseur ou un prêt.
• Entité / ressource : un type d'enregistrement, comme « fournisseurs ». Chacun reçoit habituellement sa propre table et son propre ensemble d'écrans CRUD.
• Validation : contrôles sur les données saisies — champs obligatoires, courriel 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'app reste rapide.
• Journal d'audit : un registre de qui a créé, modifié ou supprimé quoi, et quand.
• Panneau d'administration : un ensemble d'écrans CRUD permettant au personnel de gérer les données d'une app.

Erreurs courantes et idées fausses

• Oublier l'une des quatre opérations. Les apps sortent souvent avec la création et la lecture, mais sans modification, si bien que chaque faute de frappe oblige à supprimer et à tout ressaisir. Vérifiez les quatre pour chaque entité.
• Des suppressions qui brisent 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, faire une suppression logique, ou supprimer aussi les enregistrements liés.
• Des permissions seulement dans l'interface. Cacher 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 à la personne qui fait la demande.
• Aucune confirmation à la suppression. Un seul clic malheureux ne devrait pas détruire des données. Demandez une étape de confirmation, ou une fonction d'annulation.
• « Le CRUD est basique, donc il ne vaut pas la peine d'être construit. » Beaucoup de produits de valeur sont des apps CRUD qui s'adaptent à un flux de travail mieux qu'un outil générique.

Quoi demander à votre créateur d'apps 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), courriel de contact (courriel valide), téléphone, catégorie (une parmi : alimentation, emballage, nettoyage), notes. Vue en liste avec recherche par nom et filtre par catégorie, 20 par page. Demande confirmation avant de supprimer; si un fournisseur a des commandes, archive-le au lieu de le supprimer. Seuls les membres du personnel connectés peuvent créer, modifier ou archiver — applique cela sur le 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 qu'une entité fonctionne, ajoutez la suivante. Comment construire un outil interne montre comment les écrans CRUD deviennent une app d'administration complète, et qu'est-ce que Postgres explique la base de données sur laquelle reposent la plupart de ces apps.

Les apps CRUD sur Mythex

Les apps CRUD sont l'une des choses que les créateurs d'apps IA font le mieux, et Mythex ne fait pas exception. Demandez dans le chat l'entité et ses champs, et Mythex attache une base de données 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 exécuter /test pour vérifier le parcours. La documentation propose une recette d'app CRUD avec une consigne de départ, et le créateur d'outils internes et les modèles de tableaux de bord sont de bons points de départ.

Questions