Documentation
Les bases no-code du workspace
Les bases no-code stockent les données de votre workspace dans des tables interrogeables, sans écrire de schéma SQL à la main. On y définit des tables, on les interroge, on ouvre un accès par clé API, et la même base peut alimenter à la fois les sites publiés et le studio no-code. Cette page explique l'organisation des tables et des requêtes, le rôle des clés API, et ce que recouvre la surface publique exposée aux applications qui consomment ces données.
Tables et requêtes
Une base regroupe des tables ; chaque table décrit un type d'enregistrement par ses colonnes (champs). Vous ajoutez, modifiez et supprimez des enregistrements, et vous les interrogez pour ne remonter que ce dont l'application a besoin : filtrer sur un champ, trier, paginer.
Tables et champs
Une table est un ensemble d'enregistrements de même forme. Ses champs typés définissent ce que chaque enregistrement peut contenir.
Requêtes de lecture
Filtrer, trier et paginer pour ne renvoyer que les enregistrements utiles, plutôt que de charger la table entière côté application.
Écritures
Création, mise à jour et suppression d'enregistrements, depuis l'éditeur no-code ou par l'API selon les droits de la clé utilisée.
Clés API
Une clé API donne à un programme un accès à la base sans passer par un compte utilisateur. Elle porte des droits : à quelles tables elle accède, et si elle peut seulement lire ou aussi écrire. C'est le mécanisme qui permet à un site publié ou à un service tiers de consommer les données.
| Aspect | Ce que la clé contrôle | Bonne pratique |
|---|---|---|
| Portée | Les tables et opérations autorisées | Une clé par usage, limitée au strict nécessaire |
| Sens | Lecture seule ou lecture-écriture | Réserver l'écriture aux clés qui en ont réellement besoin |
| Cycle de vie | Création et révocation | Révoquer sans attendre une clé exposée ou inutilisée |
Surface publique
La surface publique d'une base, c'est l'ensemble de ce qui est accessible par API depuis l'extérieur du workspace : les tables ouvertes à une clé et les opérations qu'elle autorise. Cette surface est le point de contact entre vos données et les applications qui les consomment.
Deux consommateurs de premier plan s'appuient dessus. Les sites publiés lisent la base pour afficher du contenu dynamique — voir /docs/plateforme-sites. Le studio no-code s'y branche pour construire des interfaces et des écrans qui lisent et écrivent les enregistrements — voir /docs/plateforme-studio. La même base peut donc servir un site vitrine en lecture et une application interne en lecture-écriture, à condition que les clés distinguent bien les deux usages.
- N'exposez à une clé publique que les tables et champs destinés à être vus de l'extérieur.
- Séparez les clés par consommateur : une pour le site publié en lecture, une autre pour le studio, plutôt qu'une clé unique tout-puissante.
- Traitez la surface publique comme un contrat : renommer ou retirer un champ consommé par un site ou le studio casse leur affichage.
- Auditez régulièrement les clés actives et révoquez celles qui ne correspondent plus à un usage vivant.
Une même base peut-elle servir un site et le studio en même temps ?
Comment révoquer un accès sans casser tout le reste ?
Les bases no-code remplacent-elles une base de données gérée ?
In English
VIGIL-MESH no-code databases store workspace data in tables you define, query with filtering, sorting and pagination, and open to programs through scoped API keys — read-only or read-write, per table.
The public surface of a base is exactly what those keys allow. It is consumed by two first-class clients: published sites read it for dynamic content (/docs/plateforme-sites) and the no-code studio reads and writes it for its screens (/docs/plateforme-studio). Keep keys separate per consumer, expose only what is meant to be public, and treat the surface as a contract that breaks its readers when fields change.