SMF·NOCODB-CLOUD
Un prompt peut-il remplacer NocoDB Cloud ?
Bases de données — spreadsheet databases and operational data apps
Bordereau de suivi des pièces
Verdict
Le vrai tour de force de NocoDB — et celui qui vaut la peine d’être copié —, c’est qu’il ne possède pas tes données : il pointe vers une base MySQL, Postgres ou SQLite existante et génère une interface tableur par-dessus les tables déjà présentes. C’est un projet de week-end vraiment constructible sur une base de données que tu as déjà. Ce qui ne survit pas : l’écosystème dans lequel NocoDB lui-même s’est développé (extensions, automatisations, synchro externe) et la finition de plusieurs années de cas limites dans la façon dont il introspecte des schémas inhabituels.
Pièce A — Le prompt
Reçu le31.07.2026Construis un outil qui fait ce que fait réellement NocoDB : pointe-le vers une base PostgreSQL ou MySQL existante via une chaîne de connexion, et fais-lui introspecter le schéma — tables, colonnes, types, clés étrangères — et générer automatiquement une vue en grille modifiable pour chaque table, sans aucune définition manuelle de schéma. Édite les cellules en ligne avec des saisies adaptées au type (texte, nombre, une case à cocher pour les booléens, une liste déroulante pour les colonnes de clé étrangère résolue vers un libellé lisible depuis la ligne référencée). Prends en charge le filtrage et le tri au niveau des colonnes, et une zone de recherche basique sur les colonnes de texte. Ajoute une « vue » enregistrée par table (une combinaison filtre+tri+visibilité de colonnes stockée) pour qu’un utilisateur puisse sauvegarder une configuration de travail sans modifier le schéma sous-jacent. Utilise Next.js/TypeScript avec un pilote Postgres et MySQL (ou ta pile préférée) — c’est explicitement une couche de lecture/écriture par-dessus le schéma de quelqu’un d’autre, pas un concepteur de schéma. Ne construis pas d’outils de migration de schéma, de moteur de formules ou d’automatisation, ni de synchro multi-bases — c’est hors périmètre. Ça n’a besoin que de la chaîne de connexion de la base de données que tu fais déjà tourner ; aucune clé d’API externe.L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 les automatisations et la synchro tierce
- B.2 l’écosystème d’extensions
- B.3 la gestion des cas limites de schémas inhabituels ou hérités
- B.4 l’hébergement géré et les sauvegardes
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : data model flexibility, collaboration, and integrations
L’abonnement paie en réalité la robustesse de l’introspection de schéma sur des bases de données que tu n’as pas conçues pour ça — des années passées à gérer les cas limites SQL qu’un introspecteur maison rencontrera sur la base héritée de quelqu’un d’autre.
Questions
Est-ce que ça crée une nouvelle base de données, ou est-ce que ça utilise celle que j’ai déjà ?
Ça utilise celle que tu as déjà. Pointe-le vers une chaîne de connexion Postgres ou MySQL existante — rien n’est migré ni copié.
Que se passe-t-il si mon schéma change après l’avoir connecté ?
Relance l’étape d’introspection. Il n’y a pas de surveillance de schéma en direct dans ce projet, contrairement à la détection automatique propre à NocoDB — c’est l’un des vrais manques.
Est-ce que plusieurs personnes peuvent modifier la même table en toute sécurité ?
Oui pour les modifications non conflictuelles, puisque chaque écriture va directement vers la vraie base de données — mais il n’y a pas d’avertissement de verrou optimiste si deux personnes modifient la même cellule en même temps, contrairement à NocoDB.
Mes données sont-elles plus ou moins sûres que dans NocoDB Cloud ?
Plus sûres dans un sens — elles ne quittent jamais ta propre base de données — mais tu perds les sauvegardes gérées de NocoDB, donc sauvegarde cette base de données comme tu le ferais pour toute donnée de production.
Outils proches
Récépissé