Votre directeur régional envoie un email à 16h : la nouvelle acquisition boutique à Charleston doit être en ligne dans huit semaines, normes de marque obligatoires, moteur de réservation intégré, sans exception. Vous ouvrez votre configuration multi-sites actuelle—dix-sept installations WordPress, chacune avec son propre dédale de plugins, chacune échouant différemment après les mises à jour, chacune nécessitant un environnement de staging séparé. Votre équipe dev estime un minimum de douze semaines. J'ai vu ce scénario exact tuer les délais de lancement pour des groupes hôteliers exploitant 8, 25, voire 47 propriétés. La décision architecturale que vous prenez aujourd'hui détermine si votre prochaine propriété sera lancée en trois jours ou trois mois. La plupart des groupes choisissent le chemin qui semble sûr—puis passent deux ans à le démêler. Voici l'approche Next.js qui permet à une seule plateforme d'alimenter chaque propriété sans le chaos.

Il existe une meilleure façon. Une seule application Next.js—correctement architecturée—peut servir chaque propriété d'un groupe hôtelier à partir d'une seule base de code, un seul pipeline de déploiement et une seule couche de gestion de contenu. Chaque propriété obtient sa propre marque, son propre contenu, son propre domaine. L'équipe d'ingénierie retrouve sa santé mentale.

Cet article détaille exactement comment construire ce système. Pas de théorie—des modèles d'architecture réels que nous avons utilisés sur des projets réels de groupes hôteliers.

Table des matières

Hotel Group Websites: Multi-Property Architecture with Next.js

Pourquoi les groupes hôteliers ont besoin d'une plateforme unifiée

La situation typique d'un site web de groupe hôtelier ressemble à ceci : la propriété A fonctionne sous WordPress avec un thème de 2019. La propriété B est sur Squarespace parce que le neveu du directeur général l'a mis en place. La propriété C a un site PHP personnalisé que personne ne veut toucher. Le site d'entreprise est sur une plateforme entièrement différente.

Chaque mise à jour de propriété nécessite un workflow différent. La cohérence de marque est un rêve lointain. La stratégie SEO est fragmentée sur des dizaines de domaines sans autorité partagée. Lorsque l'entreprise décide d'ajouter un nouveau badge d'équipement ou de mettre à jour le widget de réservation, quelqu'un doit faire ce changement dans 15 endroits différents.

Les coûts s'accumulent :

  • Surcharge de maintenance : chaque plateforme nécessite son propre hébergement, ses correctifs de sécurité, ses mises à jour de plugins
  • Dérives de marque : les propriétés s'écartent lentement des directives de marque
  • Changement de contexte des développeurs : votre équipe (ou agence) a besoin d'expertise sur plusieurs plates-formes
  • Lancements de propriétés lents : les acquisitions nouvelles prennent des mois pour être mises en ligne
  • Fragmentation analytique : aucune vue unifiée des performances sur l'ensemble du portefeuille

Une plateforme multi-propriétés centralisée résout tout cela. Une seule base de code. Un seul déploiement. Un seul CMS. Le contenu par propriété et la marque sont livrés par configuration, pas par des bases de code séparées.

Aperçu de l'architecture : une base de code, plusieurs propriétés

Voici l'architecture de haut niveau qui fonctionne :

┌─────────────────────────────────────────────┐
│              CDN / Réseau Edge                │
│    (Vercel, Cloudflare, Fastly)              │
├─────────────────────────────────────────────┤
│        Application Next.js                   │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐     │
│  │ Résolution│ │ Moteur   │ │ Lecteur   │     │
│  │ Propriété │ │ Thème    │ │ Contenu   │     │
│  │ Middleware│ │          │ │           │     │
│  └──────────┘ └──────────┘ └──────────┘     │
├─────────────────────────────────────────────┤
│              Couche API                      │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐     │
│  │ CMS       │ │ Moteur   │ │ CDN       │     │
│  │ sans      │ │ Réser-   │ │ Média     │     │
│  │ interface │ │ vation   │ │           │     │
│  └──────────┘ └──────────┘ └──────────┘     │
└─────────────────────────────────────────────┘

L'application Next.js agit comme couche de rendu. Un middleware détermine quelle propriété est demandée (via domaine, sous-domaine ou chemin). Le moteur de thème applique les styles spécifiques à la propriété. Le lecteur de contenu extrait le contenu à portée de propriété du CMS sans interface.

Tout ce qui est en aval—le CMS, le moteur de réservation, le stockage de médias—est interrogé avec un identifiant de propriété. Cet identifiant est le fil conducteur qui lie l'ensemble du système.

Modèles multi-locataires dans Next.js

Il y a trois approches principales du multi-locataire dans Next.js. Chacune a des compromis.

Modèle 1 : Routage basé sur les sous-domaines

Chaque propriété obtient un sous-domaine : grandplaza.hotelgroup.com, seasideresort.hotelgroup.com.

Le middleware Next.js intercepte la requête, extrait le sous-domaine et résout la config de propriété :

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
import { getPropertyByDomain } from '@/lib/properties';

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const subdomain = hostname.split('.')[0];
  
  const property = getPropertyByDomain(subdomain);
  
  if (!property) {
    return NextResponse.redirect(new URL('/not-found', request.url));
  }
  
  // Injecter le contexte de propriété dans les en-têtes pour une utilisation en aval
  const response = NextResponse.next();
  response.headers.set('x-property-id', property.id);
  response.headers.set('x-property-slug', property.slug);
  
  return response;
}

Avantages : URLs propres, isolation facile de la propriété, bon pour le SEO si les propriétés n'ont pas besoin de TLD séparés.
Inconvénients : gestion des certificats SSL pour wildcards, moins d'indépendance de marque par propriété.

Modèle 2 : Mappage de domaine personnalisé

Chaque propriété a son propre domaine : grandplazahotel.com, seasideresort.com.

C'est ce que veulent réellement la plupart des groupes hôteliers. La logique du middleware est similaire, mais vous correspondez à une table de recherche de domaine :

const DOMAIN_MAP: Record<string, string> = {
  'grandplazahotel.com': 'grand-plaza',
  'www.grandplazahotel.com': 'grand-plaza',
  'seasideresort.com': 'seaside-resort',
  'www.seasideresort.com': 'seaside-resort',
};

Vercel supporte nativement les domaines personnalisés par projet, et vous pouvez mapper jusqu'à 50 domaines sur leur plan Pro ($20/mois en 2026). Pour les portefeuilles plus importants, leur plan Enterprise supprime cette limite.

Avantages : indépendance complète de marque, équité de domaine existante préservée.
Inconvénients : surcharge de gestion DNS, approvisionnement SSL plus complexe.

Modèle 3 : Routage basé sur le chemin

Toutes les propriétés sous un domaine : hotelgroup.com/properties/grand-plaza, hotelgroup.com/properties/seaside-resort.

Avantages : implémentation la plus simple, autorité de domaine consolidée pour le SEO.
Inconvénients : moins d'identité de marque par propriété, structure d'URL semble d'entreprise.

Modèle Indépendance de marque Flexibilité SEO Complexité d'implémentation Idéal pour
Sous-domaine Moyen Moyen Faible Groupes économiques
Domaine personnalisé Élevée Élevée Moyen Marques établies
Basé sur le chemin Faible Élevée (consolidée) Le plus faible Sites de nouveau portefeuille

La plupart des groupes hôteliers avec lesquels nous travaillons chez Social Animal finissent par choisir le mappage de domaine personnalisé. Les propriétés ont une équité de marque dans leurs domaines, et les équipes marketing veulent l'indépendance.

Hotel Group Websites: Multi-Property Architecture with Next.js - architecture

Stratégie CMS sans interface pour les groupes hôteliers

Le choix du CMS fait ou défait cette architecture. Vous avez besoin d'un système qui supporte le multi-locataire au niveau du contenu—où les éditeurs de la propriété A ne peuvent pas accidentellement modifier le contenu de la propriété B, mais les administrateurs d'entreprise peuvent tout gérer.

Options CMS qui fonctionnent bien

Sanity est mon premier choix pour les groupes hôteliers. Ses autorisations au niveau du document, sa configuration studio personnalisée et son langage de requête GROQ rendent la récupération de contenu à portée de propriété triviale. Vous pouvez construire un seul Sanity Studio avec des vues par espace de travail. La tarification commence à 99 $/mois pour le plan Team (prix 2026), et elle s'adapte bien aux gros volumes de contenu.

Contentful fonctionne si vous êtes déjà dans leur écosystème. Leur isolation au niveau de l'espace correspond bien aux propriétés, bien que cela puisse devenir coûteux—chaque espace sur le plan Premium ajoute un coût, et vous regardez plus de 2 500 $/mois pour les besoins d'entreprise à grande échelle des groupes hôteliers.

Strapi (auto-hébergé) est l'option budgétaire. Vous devrez construire vous-même la couche multi-locataire en utilisant des middlewares personnalisés et un contrôle d'accès basé sur les rôles, mais il n'y a pas de coûts de licence par siège.

Nous couvrons le processus complet de sélection CMS dans notre guide de développement CMS sans interface.

Modélisation de contenu pour les hôtels

Voici un modèle de contenu qui fonctionne sur toutes les propriétés :

// Exemple de schéma Sanity
export const property = defineType({
  name: 'property',
  title: 'Propriété',
  type: 'document',
  fields: [
    defineField({ name: 'name', type: 'string' }),
    defineField({ name: 'slug', type: 'slug' }),
    defineField({ name: 'domain', type: 'string' }),
    defineField({ name: 'brand', type: 'reference', to: [{ type: 'brand' }] }),
    defineField({ name: 'location', type: 'geopoint' }),
    defineField({ name: 'theme', type: 'propertyTheme' }),
    defineField({ name: 'bookingEngineId', type: 'string' }),
  ],
});

export const room = defineType({
  name: 'room',
  title: 'Type de chambre',
  type: 'document',
  fields: [
    defineField({ name: 'property', type: 'reference', to: [{ type: 'property' }] }),
    defineField({ name: 'name', type: 'string' }),
    defineField({ name: 'description', type: 'blockContent' }),
    defineField({ name: 'maxOccupancy', type: 'number' }),
    defineField({ name: 'amenities', type: 'array', of: [{ type: 'reference', to: [{ type: 'amenity' }] }] }),
    defineField({ name: 'gallery', type: 'array', of: [{ type: 'image' }] }),
  ],
});

Le modèle clé : chaque document de contenu référence une property. Les requêtes filtrent toujours par propriété. Les éditeurs ne voient que le contenu de leur propriété. Les administrateurs d'entreprise voient tout.

Composants partagés vs personnalisation au niveau de la propriété

C'est ici que l'architecture devient intéressante. Vous voulez que 80 % des composants soient partagés sur les propriétés, avec 20 % permettant la personnalisation par propriété.

La couche de thème

Créez une configuration de thème par propriété qui alimente votre système de composants :

// types/theme.ts
export interface PropertyTheme {
  colors: {
    primary: string;
    secondary: string;
    accent: string;
    background: string;
    text: string;
  };
  typography: {
    headingFont: string;
    bodyFont: string;
  };
  logo: {
    light: string;
    dark: string;
  };
  borderRadius: 'none' | 'sm' | 'md' | 'lg';
  heroStyle: 'fullbleed' | 'contained' | 'split';
}

Tailwind CSS v4 (lancé en 2025) rend ceci significativement plus facile avec sa configuration d'abord CSS et son support natif de la fonction de thème. Vous pouvez définir des propriétés personnalisées CSS au niveau de la mise en page et les faire cascader dans chaque composant :

// app/layout.tsx
export default async function PropertyLayout({ children }: { children: React.ReactNode }) {
  const property = await getCurrentProperty();
  const theme = property.theme;
  
  return (
    <html
      style={{
        '--color-primary': theme.colors.primary,
        '--color-secondary': theme.colors.secondary,
        '--font-heading': theme.typography.headingFont,
        '--font-body': theme.typography.bodyFont,
      } as React.CSSProperties}
    >
      <body className="font-body text-text bg-background">
        {children}
      </body>
    </html>
  );
}

Composition de composants

Les composants partagés acceptent des tokens de thème et se rendent différemment par propriété sans logique de branchement :

// components/HeroSection.tsx
export function HeroSection({ property }: { property: Property }) {
  const heroConfig = property.theme.heroStyle;
  
  const variants = {
    fullbleed: 'h-screen w-full',
    contained: 'h-[70vh] max-w-7xl mx-auto rounded-2xl overflow-hidden',
    split: 'grid grid-cols-2 h-[80vh]',
  };
  
  return (
    <section className={variants[heroConfig]}>
      {/* Structure de contenu hero partagée */}
    </section>
  );
}

Intégration du moteur de réservation

Les sites web d'hôtels existent pour une seule raison : générer des réservations. L'intégration du moteur de réservation doit être très robuste.

La plupart des groupes hôteliers utilisent l'un de ces moteurs de réservation : SynXis (Sabre), Pegasus, Bookassist, SiteMinder ou un système central de réservation propriétaire. Le modèle d'intégration est presque toujours le même : transmettre un identifiant de propriété, une plage de dates et un nombre de clients pour obtenir la disponibilité.

// lib/booking.ts
export async function checkAvailability({
  propertyCode,
  checkIn,
  checkOut,
  adults,
  children,
}: BookingQuery) {
  const response = await fetch(`${BOOKING_ENGINE_URL}/availability`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${BOOKING_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      hotel_code: propertyCode,
      arrival: checkIn,
      departure: checkOut,
      guests: { adults, children },
    }),
  });
  
  return response.json();
}

Pour le widget de réservation lui-même, vous avez deux options :

  1. iframe intégré : le moteur de réservation fournit un widget que vous intégrez. Le moins de travail, le moins de contrôle.
  2. Interface utilisateur personnalisée pilotée par API : vous construisez l'interface utilisateur de recherche et de résultats, appelez directement l'API de réservation et cédez au moteur de réservation uniquement pour le paiement. Plus de travail, bien meilleure UX.

L'option 2 est où une architecture Next.js brille vraiment. Vous pouvez construire une expérience de réservation magnifique, rapide et conforme à la marque qui semble native de chaque propriété. Les Server Components peuvent prérécupérer les données de disponibilité. Le flux de réservation reste sur votre domaine, ce qui est mieux pour le suivi des conversions et le SEO.

Routage de domaine et résolution de propriété

Le flux de résolution de propriété doit être rapide. Vraiment rapide. Il s'exécute sur chaque requête.

Voici le modèle qui fonctionne en production :

  1. Le middleware Edge résout domaine → slug de propriété (recherche en mémoire, sous-milliseconde)
  2. La config de propriété est mise en cache au niveau du bord en utilisant Vercel Edge Config ou Cloudflare KV
  3. Les données complètes de propriété (thème, navigation, contenu de pied de page) sont récupérées une fois par build via ISR ou à la demande avec mise en cache
// lib/property-resolver.ts
import { get } from '@vercel/edge-config';

export async function resolveProperty(hostname: string): Promise<PropertyConfig | null> {
  // D'abord : vérifier la config edge (sous-5ms)
  const domainMap = await get<Record<string, string>>('domain-map');
  const propertySlug = domainMap?.[hostname];
  
  if (!propertySlug) return null;
  
  // Deuxièmement : obtenir la config complète de la propriété (mise en cache)
  const propertyConfig = await get<PropertyConfig>(`property:${propertySlug}`);
  return propertyConfig;
}

Vercel Edge Config est parfait pour ceci—c'est un magasin de paires clé-valeur distribué mondialement avec une latence de lecture inférieure à 1 ms. Cela coûte 0 $ sur les plans Pro pour jusqu'à 512 KB de données, ce qui est amplement suffisant pour une table de recherche de propriété.

Performance à l'échelle

Les sites web d'hôtels ont des caractéristiques de performance spécifiques qui importent :

  • Pages riches en images : galeries de chambres, photos de propriété, imagerie de destination
  • Pics de trafic saisonnier : vacances, saison de convention, événements locaux
  • Audience mondiale : voyageurs internationaux naviguant de partout
  • Critique pour les conversions : chaque 100 ms de temps de chargement coûte des réservations

Stratégie de génération statique

Utilisez la régénération statique incrémentale (ISR) pour les pages de propriété. Le contenu hôtelier ne change pas à chaque minute—une période de revalidation de 60 secondes est généralement fine :

// app/[propertySlug]/page.tsx
export async function generateStaticParams() {
  const properties = await getAllProperties();
  return properties.map((p) => ({ propertySlug: p.slug }));
}

export const revalidate = 60;

Pour un groupe de 30 propriétés avec ~20 pages par propriété, vous prégénérez ~600 pages. Next.js gère cela sans transpirer. Les temps de build restent sous 5 minutes.

Optimisation d'image

Le composant Next.js Image avec un chargeur distant gère l'optimisation d'image par propriété. Si vous utilisez Sanity, leur CDN d'image avec conversion de format automatique et redimensionnement est excellent. Cloudinary est une autre option solide à 89 $/mois pour le plan Plus.

Une page de propriété hôtelière typique devrait cibler :

  • LCP inférieur à 2,5 s sur les connexions 4G
  • CLS de 0 (pas de décalage de mise en page lors du chargement des images)
  • Poids total de la page inférieur à 1,5 MB au chargement initial

Tableau de bord de gestion centralisé

Au-delà du CMS, les groupes hôteliers ont besoin de tableaux de bord opérationnels. C'est où vous construisez des outils personnalisés :

  • Aperçu de propriété : statut de chaque site de propriété (en ligne, staging, maintenance)
  • Fraîcheur du contenu : quelles propriétés n'ont pas mis à jour leur contenu saisonnier
  • Surveillance des performances : Core Web Vitals par propriété
  • Agrégation analytique : métriques d'entonnoir de réservation sur toutes les propriétés

Nous construisons généralement ceci comme une application Next.js séparée (souvent avec les capacités côté serveur du App Router) qui se connecte aux mêmes sources de données. Le tableau de bord de gestion est un outil interne—il n'a pas besoin d'être flashy, mais il doit être fonctionnel.

Déploiement et DevOps

Une base de code signifie un pipeline CI/CD. Voici le flux de déploiement :

  1. Modifications de code : PR → révision → fusion à main
  2. Build : Next.js construit toutes les pages statiques sur toutes les propriétés
  3. Déploiement : Vercel (ou similaire) déploie sur le réseau edge
  4. DNS : chaque domaine de propriété pointe vers le déploiement

Les modifications de contenu ne nécessitent pas un déploiement. Le CMS sans interface déclenche la revalidation ISR via webhook :

// app/api/revalidate/route.ts
export async function POST(request: Request) {
  const body = await request.json();
  const { propertySlug, contentType } = body;
  
  // Revalidate des chemins spécifiques pour la propriété modifiée
  revalidatePath(`/${propertySlug}`);
  
  if (contentType === 'room') {
    revalidatePath(`/${propertySlug}/rooms`);
  }
  
  return Response.json({ revalidated: true });
}

Comparaison réelle des coûts

Comparons les coûts réels pour un groupe hôtelier de 20 propriétés :

Catégorie de coût Sites séparés (WordPress) Plateforme Next.js unifiée
Hébergement (mensuel) 2 000–4 000 $ (20 × WP managé) 150–400 $ (Vercel Pro/Team)
Licence CMS 0–600 $ (plugins par site) 99–300 $ (Sanity/Contentful)
Certificats SSL 0–400 $ (si pas Let's Encrypt) 0 $ (auto-approvisionné)
Maintenance (annuel) 40 000–80 000 $ (mises à jour, sécurité) 10 000–20 000 $
Lancement de nouvelle propriété 5 000–15 000 $ par site 500–2 000 $ (contenu + config)
Total annuel (est.) 75 000–150 000 $ 15 000–35 000 $

Les chiffres ne sont même pas proches. Et ceci ne tient pas compte des améliorations de l'expérience développeur—avoir une seule base de code signifie que votre équipe comprend réellement le système. Plus de "quelle version WordPress cette propriété utilise-t-elle?"

Pour les groupes hôteliers envisageant cette approche, nous avons décrit nos capacités de développement Next.js et vous pouvez voir notre structure de tarification pour une estimation plus détaillée.

FAQ

Combien de temps faut-il pour migrer un groupe hôtelier vers une plateforme Next.js unifiée ?

Pour un groupe de 10–20 propriétés, attendez-vous à 3–5 mois à partir du démarrage jusqu'au lancement complet. La première propriété prend le plus longtemps (8–10 semaines) car vous construisez la plateforme. Chaque propriété suivante est principalement une migration de contenu et une configuration de thème, ce qui prend 1–2 semaines chacune. Nous lancons généralement par vagues—3–4 propriétés à la fois.

Les propriétés individuelles peuvent-elles toujours avoir des pages uniques que les autres propriétés n'ont pas ?

Absolument. Le modèle de contenu supporte des types de pages spécifiques à la propriété. Si votre propriété resort a besoin d'une section "Lieux de mariage" mais que votre hôtel d'affaires n'en a pas, c'est une décision au niveau du contenu. Le schéma CMS supporte les types de pages optionnels, et le routage dynamique Next.js gère le rendu de toute page qui existe dans le CMS pour une propriété donnée.

Que se passe-t-il quand vous acquérez un nouvel hôtel et que vous devez l'ajouter à la plateforme ?

C'est l'une des plus grandes victoires. Ajouter une nouvelle propriété signifie : créer une entrée de propriété dans le CMS, configurer le thème (couleurs, polices, logo), ajouter le mappage de domaine et remplir le contenu. Une équipe de contenu compétente peut avoir une nouvelle propriété en ligne en 1–2 semaines. Comparez cela à 2–3 mois pour construire un site web autonome.

Comment gérez-vous le support multilingue sur les propriétés dans différents pays ?

Next.js a un support de routage i18n intégré. Combiné avec un CMS sans interface qui supporte le contenu localisé (Sanity et Contentful font tous deux), vous pouvez servir chaque propriété dans ses langues pertinentes. Une propriété à Barcelone pourrait avoir besoin de l'espagnol, du catalan, de l'anglais et du français. Une propriété à Miami pourrait seulement avoir besoin d'anglais et d'espagnol. La configuration linguistique de chaque propriété est indépendante.

Cette architecture fonctionne-t-elle avec Astro au lieu de Next.js ?

Oui, et pour certains groupes hôteliers c'est réellement le meilleur choix. Si vos propriétés sont principalement pilotées par le contenu avec une interactivité minimale (pas de flux de réservation complexe, par exemple), l'architecture multi-pages d'Astro peut fournir une performance encore meilleure avec moins de JavaScript. Les modèles multi-locataires sont similaires—résolution de propriété basée sur le middleware, CMS sans interface avec scope de propriété, tokens de thème par propriété.

Comment gérez-vous le SEO quand les propriétés sont sur des domaines séparés mais servies à partir d'une seule application ?

Chaque domaine de propriété obtient son propre sitemap, son propre robots.txt, ses propres données structurées (balisage de schéma d'hôtel) et ses propres méta-balises. Du point de vue de Google, ce sont des sites web entièrement séparés. Les URL canoniques pointent vers le domaine de chaque propriété. Vous obtenez également l'avantage de la génération de balisage de schéma centralisé—chaque propriété obtient automatiquement un JSON-LD approprié pour les hôtels, les chambres, les avis et les informations d'entreprise locales.

Qu'en est-il des intégrations spécifiques à la propriété comme les réservations d'activités locales ou les systèmes de réservation de spa ?

L'architecture des composants supporte la configuration d'intégration au niveau de la propriété. Chaque config de propriété dans le CMS peut spécifier les intégrations tierces qu'il utilise. La couche de rendu inclut conditionnellement ces composants d'intégration. Une propriété spa obtient le widget de réservation de spa. Un hôtel d'affaires au centre-ville obtient le configurateur de salle de réunion. Ces sont chargés en tant qu'importations dynamiques donc ils n'affectent pas la taille du bundle pour les propriétés qui ne les utilisent pas.

Y a-t-il un risque qu'un pic de trafic d'une propriété affecte d'autres propriétés ?

Sur une plateforme comme Vercel ou Cloudflare Pages, pas vraiment. Ces plates-formes edge sont conçues pour les pics de trafic. Les pages statiques sont servies depuis le cache CDN, donc un pic sur une propriété ne consomme pas les ressources du serveur qui affecteraient une autre. Pour les routes dynamiques (comme les contrôles de disponibilité en temps réel), vous voudriez une limitation de débit par propriété pour empêcher qu'un moment viral d'une propriété épuise vos quotas d'API de moteur de réservation. Mais c'est une préoccupation au niveau API, pas une préoccupation d'hébergement.