Architecture web moderne : couches, responsabilités, risques

Les débats d’architecture web tournent trop souvent autour des technologies — React ou Vue, REST ou GraphQL, monolithe ou microservices. La question structurante n’est pas là. Elle est plus simple et plus difficile à la fois : quelle couche porte quelle responsabilité, et quel risque est introduit quand cette responsabilité est au mauvais endroit ? Une application web moderne opère sur trois couches aux caractéristiques physiques radicalement différentes — Edge, Serveur, Client. Chaque couche a un coût propre, une surface de cache propre, et des contraintes propres. Les problèmes de performance et de maintenabilité les plus courants sont des problèmes de placement de responsabilité, pas des problèmes de technologie.

Les trois couches d’une architecture web moderne

Avant de raisonner sur les responsabilités, il faut nommer les couches et comprendre leurs contraintes physiques. Ce ne sont pas des choix techniques — ce sont des réalités de l’infrastructure réseau.

Les quatre responsabilités à répartir entre les couches

Une architecture web moderne doit allouer explicitement quatre types de responsabilités. Les problèmes apparaissent quand ces allocations sont faites implicitement — par défaut, par commodité, ou par héritage d’une architecture précédente.

Ces allocations ne sont pas définitives — elles évoluent avec le produit. Une page dont les données changent toutes les heures peut être servie depuis l’Edge avec de l’ISR. Si ces mêmes données commencent à changer en temps réel, la responsabilité de cache se déplace vers le serveur. L’architecture suit la nature des données, pas l’inverse.

Le glissement de responsabilité le plus fréquent — l’orchestration côté client

Le pattern le plus répandu — et le plus coûteux en performance — est l’orchestration côté client : le navigateur fait plusieurs appels réseau séquentiels là où le serveur aurait pu les faire en parallèle, en interne, en une fraction du temps.

## Exemple : page catégorie e-commerce avec CMS headless

Pattern actuel — orchestration côté client :
t=0ms    → navigateur charge la page
t=80ms   → Call 1 : GET /api/pages/cat-chaussures  (config, composants, SEO)
t=200ms  → réponse Call 1 reçue — le client sait maintenant quoi demander
t=280ms  → Call 2 : GET /api/products?cat=chaussures  (les produits)
t=460ms  → réponse Call 2 reçue — premier produit visible
→ Total : ~460ms incompressibles sur 4G

Pattern corrigé — orchestration côté serveur (BFF) :
t=0ms    → navigateur charge la page
t=80ms   → Call unique : GET /api/category-page/chaussures
           ↳ BFF fait en parallèle (~1ms réseau interne) :
              · call CMS pour la config
              · call products pour les produits
t=280ms  → réponse unique reçue — page complète
→ Total : ~280ms — soit ~40% de gain sur le Time to Interactive

Les patterns qui repositionnent les responsabilités dans les bonnes couches

Trois patterns résolvent le problème d’orchestration côté client — avec des compromis différents selon le contexte.

// BFF — orchestration en parallèle, réseau interne
app.get('/api/category-page/:slug', async (req, res) => {
  const [config, products] = await Promise.all([
    cmsService.getPageConfig(req.params.slug),   // ~1ms réseau interne
    productService.getProducts(req.params.slug),  // ~1ms réseau interne
  ]);
  res.json(composePageResponse(config, products));
  // Le client ne connaît pas les sources internes
});

// Server Component — le fetch se passe côté serveur, pas côté client
export default function Page({ params }) {
  return (
    <PageShell slug={params.slug}>          // rendu immédiat, pas de fetch
      <Suspense fallback={<ProductSkeleton />}>
        <ProductGrid slug={params.slug} />  // streamé depuis le serveur
      </Suspense>
    </PageShell>
  );
}

async function ProductGrid({ slug }) {
  const products = await fetchProducts(slug);  // 1ms réseau interne
  return <Grid items={products} />;
}

// ISR — config en cache 1h, produits dynamiques en parallèle
export const revalidate = 3600;  // revalidation toutes les heures

export default async function Page({ params }) {
  const [config, products] = await Promise.all([
    fetchPageConfig(params.slug),  // cache CDN ~5ms
    fetchProducts(params.slug),    // call dynamique ~200ms, en parallèle
  ]);
}

Matrice de décision — quand choisir quelle couche

Nuances — ce que cette analyse ne dit pas

Déplacer les responsabilités dans les bonnes couches résout des problèmes de performance et de maintenabilité — et en crée d’autres si le déplacement n’est pas adapté au contexte.

Conclusion

L’architecture web moderne n’est pas une question de technologies — c’est une question de placement de responsabilités. L’orchestration appartient au serveur, où le réseau interne est négligeable. Le cache doit être différencié par la nature des données, pas appliqué uniformément. L’hydratation doit être minimisée, pas assumée. Chaque responsabilité mal placée introduit un coût — en performance, en couplage, ou en maintenabilité — qui s’accumule silencieusement jusqu’à ce qu’il devienne indéniable.

Comprendre une architecture, c’est savoir nommer ce que chaque couche fait — et identifier le risque introduit quand une responsabilité est placée au mauvais endroit. Ce diagnostic précède toujours la solution technique.