Concepts
Cette page définit les objets que manipule Bastide et dit comment ils s'emboîtent. Lisez-la une fois avant les autres pages : la console, l'API, la ligne de commande et les outils MCP emploient tous ces mots dans le même sens.
Vue d'ensemble
| Objet | Appartient à | Contient ou produit | Identifiant |
|---|---|---|---|
| Compte | une personne | des sessions, des jetons personnels, des seconds facteurs | — |
| Organisation | ses Propriétaires | des membres, des projets, des comptes de service, un plafond de dépense | org_… |
| Projet | une organisation | des environnements, un backend, un palier | prj_… |
| Environnement | un projet | des variables, des déploiements, la release en service | env_… |
| Déploiement | un environnement | une construction, puis une release | dep_… |
| Release | un déploiement | une image construite et signée, promouvable ailleurs | rel_… |
| Travail | un projet | l'avancement d'une opération longue | job_… |
En une phrase : un compte est membre d'une ou plusieurs organisations ; une organisation possède des projets ; chaque projet a ses environnements et son backend ; un déploiement construit une release et la met en service dans un environnement.
Organisation
L'organisation est l'espace commun d'une équipe : elle possède les projets, réunit les membres, porte la facturation et son plafond de dépense. Elle naît avec le compte de la personne qui s'inscrit, qui en devient Propriétaire. Un compte peut appartenir à plusieurs organisations ; la console demande dans laquelle entrer à la connexion. Voir Organisations.
Membre et rang
Un membre est un compte qui tient un rôle dans l'organisation, ou sur un seul projet. Les rôles hiérarchiques, du plus haut au plus bas, sont Propriétaire (owner), Administrateur (admin), Mainteneur (maintainer), Développeur (developer) et Lecteur (reader). Deux rôles transversaux s'y ajoutent : Sécurité (security) et Facturation (billing).
Chaque opération exige un rang minimal : créer un projet demande Mainteneur, demander sa suppression demande Propriétaire, lire un déploiement demande Lecteur. La page de chaque opération, dans la référence MCP, l'indique. Un rôle ne s'attribue jamais au-dessus du rang de celui qui l'attribue, et l'organisation garde toujours un Propriétaire.
Projet
Le projet est l'unité d'hébergement, d'isolation et de facturation : une application, ses environnements et son backend. Il porte un nom (modifiable), un identifiant lisible (slug, définitif, qui entre dans ses adresses), un dépôt Git, une branche de production et un palier. Voir Créer un projet.
Environnement
Un environnement est une instance déployée du projet, avec ses propres variables et sa propre release en service. Il en existe quatre genres :
- Production (
production) : créée avec le projet, elle sert votre site public. La branche de production y déploie. - Préproduction (
staging) : une copie de la production pour valider avant de promouvoir. - Prévisualisation (
preview) : un environnement attaché à une branche, pour relire une modification avant de la fusionner. - Personnalisé (
custom) : un environnement que vous nommez, dans la limite de votre palier.
Un environnement de production peut être épinglé sur une release : les nouveaux déploiements n'y sont plus promus tant que l'épinglage n'est pas levé (environment_unpin). Voir Environnements.
Déploiement et construction
Un déploiement est la demande de mettre une version dans un environnement. Il part d'une référence Git (branche, étiquette ou empreinte) et passe par une construction : récupération du dépôt, détection du cadriciel, installation des dépendances, construction et signature de l'image, dans un constructeur isolé. La construction consomme des minutes de construction, comptées par palier. La bascule vers la nouvelle version suit la sonde de santé. Voir Déployer et Constructions.
Release
La release est ce qu'un déploiement réussi a construit : une image signée, avec son empreinte. Elle se promeut dans un autre environnement sans reconstruire (releaseId), et c'est elle qu'une restauration rétablit : deployment_rollback remet la release précédente en service sans rien reconstruire. Voir Restaurer.
Prévisualisation
Chaque déploiement reçoit une adresse immuable, et chaque branche une adresse mobile qui suit son dernier commit. Les prévisualisations se protègent (quatre modes, dont l'accès réservé aux membres) et leur nombre simultané dépend du palier. Voir Prévisualisations.
Backend
Le backend est fourni avec le projet : une base PostgreSQL, l'authentification des utilisateurs de votre application, le stockage d'objets et le temps réel (à activer par projet). Votre application y accède par ses points d'entrée et une clé publiable ; les clés secrètes se frappent à part et ne sont montrées qu'une fois. Voir Base de données, Authentification, Stockage et Temps réel.
Palier
Le palier fixe les ressources, les quotas et le prix d'un projet. Il y en a quatre : Découverte, Standard, Pro et Souverain. Un projet naît au palier Découverte ; le palier se change par une personne, jamais par un agent, parce qu'il engage une dépense. Voir Facturation et Limites.
Plafond de dépense
Le plafond de dépense borne ce qu'une organisation peut dépenser dans le mois. Une organisation neuve naît avec un plafond de 500 €, que le Propriétaire règle ensuite. Une montée de palier qui le dépasserait est refusée, et le relever demande l'accord de deux personnes distinctes. Voir Facturation.
Jeton
Un jeton est ce qu'on présente dans l'en-tête Authorization: Bearer … pour appeler l'API. Il en existe plusieurs sortes :
- la session de console (
cse_…), ouverte par un mot de passe : huit heures au plus, une heure sans geste ; - le jeton personnel (
pat_…), frappé par une personne pour un script ou un poste : il agit en son nom, dans la limite de son rang et des portées qu'on lui a nommées ; - le jeton de compte de service, qui agit sous son propre nom ;
- le jeton d'agent, délivré à un client MCP après votre consentement.
Les portées (project:read, deploy:write, secrets:write…) disent ce qu'un jeton peut faire, en plus du rang de son titulaire. Voir Compte.
Compte de service
Un compte de service est une identité non humaine, pour une intégration continue ou un automate : ses jetons agissent sous leur propre nom, sur les seuls projets nommés, avec des portées nommées et une échéance de quatre-vingt-dix jours au plus. Un compte de service lit, et ne mène que les écritures que la plateforme lui ouvre par leur nom. Voir Comptes de service.
Outil MCP
Un outil MCP est une opération de la plateforme exposée à un agent par le protocole MCP. Il porte le nom de son opération, avec des soulignés à la place des points : deployment.create devient deployment_create. Certaines opérations ne sont pas des outils, parce qu'elles engagent une dépense ou l'identité d'une personne (changer de palier, frapper un jeton personnel). Voir MCP.
Travail
Une opération longue (un déploiement, une restauration) rend la main tout de suite et met un travail en file (job_…). task_read en lit l'avancement sans maintenir de connexion ouverte : relisez-le à intervalle raisonnable jusqu'à un état final.
Action réversible
Chaque opération porte une classe de réversibilité, qui décide de la confirmation demandée :
| Classe | Sens | Exemple |
|---|---|---|
| N | Lecture seule, aucun effet. | project_read |
| R | Réversible : exécution directe, tracée, annulable. | project_create |
| E | Réversible avec effort : une personne valide avant l'appel, puis cinq minutes pour tout défaire d'un seul appel (action_undo). | project_settings_write, deployment_rollback |
| I | Irréversible : confirmation en deux temps, double validation humaine, vingt-quatre heures de grâce avant l'effet définitif. | project_delete |
Voir Sûreté des agents.
Idempotence
Toute écriture accepte une clé d'idempotence (de 8 à 128 caractères). Rejouée avec la même clé, elle rend la première réponse sans nouvel effet : un appel répété après une coupure du réseau ne crée pas un second projet.