Architecture des domaines

Surface canonique v1, sous-domaines réservés mais non provisionnés, enregistrements DNS, frontière de sécurité et constantes de domaine.

La page publique Adresses officielles liste les URL que les utilisateurs doivent employer. Cette page porte la décision d’architecture qui les fonde. Pour changer de domaine, suivre le runbook Changer de domaine.

Surface canonique v1

Usage	URL canonique	Déploiement
Produit Orbit	`orbit.easyconnector.app`	application web Orbit
Documentation	`docs.easyconnector.app`	projet de documentation dédié
API publique	`orbit.easyconnector.app/api/v1/*`	application web Orbit
MCP	`orbit.easyconnector.app/api/mcp`	application web Orbit
OAuth	`orbit.easyconnector.app/oauth/*` et métadonnées `.well-known`	application web Orbit
Studio	`orbit.easyconnector.app/studio/*`	application web Orbit
Brain	`orbit.easyconnector.app/brain/*`	application web Orbit

Réservés, non provisionnés

`api.easyconnector.app`

Ne pas le créer en v1 : l’API reste en même origine sous /api/v1.

Un nom d’hôte d’API dédié ne se justifie que si l’API devient un service déployé indépendamment, exige une politique de runtime, de région ou de montée en charge distincte, ou doit avoir une frontière de sécurité et de limitation de débit propre.

`mcp.easyconnector.app`

Ne pas le créer en v1 : le point d’entrée MCP reste /api/mcp, à côté de ses métadonnées de ressource protégée OAuth et de son flux d’autorisation.

Ne l’introduire que si le serveur MCP devient un serveur de ressources déployé indépendamment.

`studio.easyconnector.app`

Ne pas le créer en v1 : Studio est un tool d’Orbit, sa surface canonique est /studio.

Un nom d’hôte dédié se justifie si Studio obtient son propre rythme de déploiement ou son propre runtime, ou devient une application exploitée indépendamment.

`cdn.easyconnector.app`

Ne pas le créer pour de simples fichiers statiques : Vercel sert déjà les ressources du framework sur son réseau edge, et le stockage géré peut garder son hôte natif de ressources.

Ne créer un hôte CDN personnalisé que si Orbit adopte délibérément une origine de ressources séparée (par exemple un stockage objet avec CDN), exige des URL publiques de ressources stables et à sa marque, ou a besoin de règles de cache isolées de l’application web.

Enregistrements DNS à préparer maintenant

Seuls les enregistrements produit suivants sont nécessaires à la première bascule :

orbit.easyconnector.app
docs.easyconnector.app

Ne pas poser de joker *.easyconnector.app pour Orbit, sauf si une vraie fonction de sous-domaines multi-tenant est introduite.

Frontière de sécurité

easyconnector.app héberge aujourd’hui un produit distinct. Orbit ne doit donc pas reposer sur des cookies à l’échelle du domaine.

Règles :

préférer des cookies de session sécurisés limités à l’hôte ;
ne jamais poser Domain=.easyconnector.app pour les sessions Orbit par défaut ;
ne pas partager par accident de secret d’authentification ou de session avec l’application EasyConnector existante ;
limiter le CORS à des origines explicites ;
garder les URI de redirection OAuth explicites ;
traiter un SSO inter-sous-domaines comme une décision d’architecture future et délibérée, jamais comme un effet de bord implicite.

Constantes de domaine

Le code et la documentation côté produit utilisent des constantes de domaine EasyConnector plutôt que des hôtes historiques écrits en dur. Le domaine n’est écrit qu’à un seul endroit du code de l’application (apps/web/src/config/domains.ts), et un test de l’application refuse qu’il soit écrit ailleurs.

Valeurs cibles :

APP_ORIGIN=https://orbit.easyconnector.app
DOCS_ORIGIN=https://docs.easyconnector.app
API_BASE_URL=https://orbit.easyconnector.app/api/v1
MCP_URL=https://orbit.easyconnector.app/api/mcp

Les domaines de produit historiques ne peuvent apparaître que dans des documents de migration qui documentent explicitement leur provenance.

Was this page helpful?