Catégorie : Architecture & Ingénierie Web

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.

La simplicité est mal comprise dans notre métier. Elle est souvent confondue avec le manque de moyens, la solution de débutant, ou l’absence d’ambition. C’est presque l’inverse. La simplicité est difficile à atteindre — et facile à perdre. Elle demande plus de discipline que la complexité, parce qu’elle impose de résister à des forces qui poussent en permanence dans l’autre sens. Les développeurs qui écrivent du code simple ont en général compris quelque chose que les développeurs qui écrivent du code sophistiqué sont encore en train d’apprendre.

Le problème — la complexité comme signal de sérieux

Dans beaucoup d’équipes, la complexité technique est lue comme un indicateur de profondeur. Une architecture avec dix services, trois couches d’abstraction et un DSL maison semble plus « sérieuse » qu’un monolithe bien découpé. Un algorithme récursif avec une indirection intelligente impressionne plus qu’une boucle lisible qui fait la même chose.

Ce biais est rationnel dans un contexte précis : la complexité est visible, immédiate, et signale l’effort investi. La simplicité, elle, masque son travail. Un code qu’on peut lire en deux minutes sans contexte semble évident — mais l’évidence est le résultat d’un travail de simplification, pas de son absence.

// Version qui "impressionne"
const transform = (pipeline) =>
  pipeline
    .reduce((acc, fn) => (x) => fn(acc(x)), x => x)
    .call(null, input);

// Version qui dure
function applySteps(input, steps) {
  let result = input;
  for (const step of steps) result = step(result);
  return result;
}

Les deux font la même chose. L’une demandera une explication dans six mois. L’autre, non. La différence de valeur ne s’apprécie qu’avec le temps — et c’est précisément pourquoi la complexité gagne si souvent à court terme.

Ce que la simplicité n’est pas

La nuance est importante : la simplicité n’est pas toujours la bonne réponse. Certains problèmes sont intrinsèquement complexes — les ignorer pour produire une solution « simple » revient à refuser de traiter le problème.

Un moteur de règles métier avec cinquante cas particuliers est complexe — parce que le métier l’est. La complexité n’est pas accidentelle : elle documente la réalité du domaine. Un système de cache distribué avec invalidation conditionnelle est complexe — parce que le problème de cohérence l’exige.

Ce que la simplicité combat, ce n’est pas cette complexité-là. C’est celle qu’on introduit par-dessus la complexité nécessaire : la couche d’abstraction qui généralise trois cas similaires qui n’évolueront jamais ensemble, le pattern qui prépare une extension qui ne viendra pas, l’interface qui cache une seule implémentation.

Le coût cognitif comme métrique principale

La complexité a un coût qui ne figure dans aucun ticket. Il se manifeste dans le temps qu’il faut à un nouveau développeur pour comprendre un flux, dans le nombre d’endroits à modifier pour corriger un bug, dans la confiance qu’inspire (ou non) la suite de tests avant un déploiement. Ces quatre métriques sont rarement mesurées — elles sont pourtant plus révélatrices de la santé d’un codebase que le nombre de tests ou la couverture de code.

La loi de Gall formule cette observation depuis 1975 : « Un système complexe qui fonctionne évolue invariablement d’un système simple qui fonctionnait. » La réciproque est rarement vérifiée.

Les forces qui poussent vers la complexité

La complexité accidentelle ne s’installe pas par malveillance — elle arrive par accumulation de décisions localement raisonnables. Comprendre ces forces est la première étape pour leur résister.

Les marqueurs d’une vraie simplicité

La simplicité n’est pas un état de départ — c’est un résultat. Voici les signaux qui la distinguent de la naïveté technique :

Les résistances — et ce qu’elles révèlent

Pratiques concrètes pour travailler dans cette direction

• La question avant chaque abstraction : « si ce code n’existait que dans un seul fichier, est-ce que ça serait plus difficile à comprendre ? » Si non, l’abstraction n’apporte pas de valeur.
• Le test de suppression : régulièrement, identifier ce qui pourrait être supprimé sans régression fonctionnelle. Ce que le test révèle est plus informatif que ce qu’il préserve.
• La revue de code orientée complexité : poser explicitement « est-ce que ce niveau de sophistication est justifié par le problème ? », en plus des questions habituelles de correction et de style.
• Le benchmark du novice : estimer le temps qu’il faudrait à quelqu’un sans contexte pour comprendre ce module. Si la réponse honnête est « une semaine », la complexité est probablement accidentelle.
• Documenter les décisions de complexité maintenue : quand la complexité est nécessaire, le dire explicitement. Un commentaire « cette indirection existe parce que X » coûte dix lignes et économise des heures de diagnostic.

Nuances — ce que la simplicité ne garantit pas

Trois limites méritent d’être nommées pour ne pas faire de la simplicité une posture dogmatique — ce qu’elle ne devrait jamais être.

Conclusion

La simplicité n’est pas la solution par défaut à tout problème — elle est le résultat d’un travail de conception qui mérite autant de rigueur que les décisions d’architecture les plus ambitieuses. Elle demande de savoir ce qu’on ne fait pas, de résister aux forces qui ajoutent, et d’accepter que le code évident soit souvent la chose la plus difficile à écrire.

Elle est aussi contextuelle. Ce qui est simple pour une infrastructure à charge variable ne l’est pas pour un CRUD. Ce qui est simple pour une équipe de vingt développeurs ne l’est pas pour un développeur seul. Ce qui est simple pour un produit en phase d’exploration ne l’est pas pour un système de paiement en production. La simplicité n’est pas un absolu — c’est une direction qu’on choisit activement, en connaissance des compromis.

Le signe de maturité d’un ingénieur n’est pas la capacité à construire des systèmes complexes — beaucoup peuvent le faire. C’est la capacité à savoir quand ne pas le faire, à choisir la solution plus simple en sachant exactement ce qu’elle ne couvre pas, et à défendre ce choix avec la même rigueur qu’une décision technique sophistiquée.