Aller au contenu principal
Dragnoc
Infogérence · Architectures sur mesure

Performance & disponibilité

Load balancing, cache extrême : tenir la charge sans surdimensionner.

Plutôt que de prendre un serveur deux fois plus gros chaque année, on conçoit des architectures qui répartissent la charge intelligemment, mettent en cache ce qui doit l'être et servent le plus possible en statique. Voilà comment ces patterns marchent et quand ils valent vraiment le coup.

Le principe

Un serveur plus gros, c'est rarement la bonne réponse.

Quand un site rame, le réflexe est souvent de prendre une machine plus puissante. C'est rapide à mettre en place, mais ça ne règle aucun des vrais problèmes : point unique de panne, coût qui grimpe linéairement, pas de marge pour les pics, et au final on recommence dans un an.

Une architecture distribuée et cachée revient souvent moins cher, tient mieux les pics, et permet des mises à jour sans coupure. Le vrai travail est de choisir quels patterns appliquer à quels endroits — pas de tout empiler.

Six patterns qu'on utilise

La boîte à outils, expliquée simplement.

01
Répartition

Load balancing — répartir la charge sans point unique de panne

Au lieu d'un seul serveur qui encaisse tout le trafic, deux ou trois (ou plus) se partagent les requêtes. Si un tombe, les autres prennent le relais — sans interruption visible côté visiteur.

Quand l'utiliser

Quand votre site est devenu critique pour votre activité, quand un pic vous fait régulièrement basculer en 502, ou quand un seul redémarrage coupe le service trois minutes.

Outils

HAProxy, Nginx, Traefik, ou load balancer managé (OVH, Scaleway, Cloudflare)

Gain attendu

Disponibilité réelle 99.9% et plus, montées en charge sans drama, mises à jour serveur sans coupure

02
Cache HTTP

Cache HTTP extrême — servir 10 000 requêtes au prix d'une

La majorité des pages d'un site ne change pas à chaque visite. Un cache HTTP bien réglé (Varnish, Nginx fastcgi_cache, CDN) sert la même page à des milliers de visiteurs sans réinterroger PHP ou la base. Le serveur applicatif respire.

Quand l'utiliser

Site WordPress / Drupal qui souffre sous le trafic, blog ou média avec pics éditoriaux, e-commerce hors panier/checkout, API à fort trafic en lecture.

Outils

Varnish, Nginx fastcgi_cache, Cloudflare, Bunny CDN, Fastly

Gain attendu

TTFB divisé par 10 à 50, capacité multipliée par 100, coût serveur réduit

03
Cache applicatif

Cache applicatif — éviter les requêtes inutiles côté code

À l'intérieur même de l'application, on évite de recalculer ce qui ne change pas. Résultats de requêtes SQL lourdes, sessions, données externes, fragments de pages : tout ce qui est coûteux et stable se met en cache mémoire.

Quand l'utiliser

Application Symfony / Laravel / Node lente sur certaines pages, dashboards qui rament, API qui multiplie les appels à des services externes.

Outils

Redis, Memcached, cache HTTP intégré (Symfony HttpCache, Laravel Cache)

Gain attendu

Temps de génération de page sous les 100 ms, charge SQL divisée, expérience utilisateur fluide

04
Statique précompilé

Statique précompilé — la vitesse maximale, sans serveur applicatif

Pour les sites dont le contenu change peu (vitrine, documentation, blog), on génère toutes les pages en HTML statique au moment du build. Pas de PHP, pas de Node, pas de base à interroger : juste des fichiers servis par Nginx ou un CDN.

Quand l'utiliser

Site vitrine, blog éditorial, documentation, marketing, portfolio. Toute la partie publique d'un site quand le "dynamique" se limite à un formulaire de contact.

Outils

Astro, Hugo, Eleventy, Next.js (SSG), Gatsby — déploiement sur Netlify, Vercel, ou simple Nginx

Gain attendu

TTFB < 100 ms, score Lighthouse au plafond, sécurité accrue (pas de surface d'attaque applicative), coût d'hébergement minime

05
Réplication BDD

Réplication base de données — séparer lecture et écriture

La base devient le goulot ? On la réplique sur une ou plusieurs instances en lecture seule. L'écriture reste sur le primaire, les lectures (souvent 80 à 95% des requêtes) se répartissent sur les répliques.

Quand l'utiliser

Application qui fait beaucoup de SELECT, dashboards analytiques, sites e-commerce avec catalogue lourd, recherche full-text qui sollicite la base.

Outils

MariaDB / MySQL replication, PostgreSQL streaming replication, ProxySQL pour le routage

Gain attendu

Charge primaire divisée, latence stable sous le pic, disponibilité accrue (le primaire peut tomber sans tout couper)

06
CDN multi-région

CDN multi-région — rapprocher le contenu de l'utilisateur

Si vos visiteurs sont à l'autre bout du monde, la latence réseau plombe l'expérience même avec un serveur rapide. Un CDN sert les fichiers (images, CSS, JS, voire pages entières) depuis le point de présence le plus proche du visiteur.

Quand l'utiliser

Audience internationale, médias lourds (images, vidéos), e-commerce mondial, API qui doit répondre rapidement partout.

Outils

Cloudflare, Bunny CDN, Fastly, AWS CloudFront

Gain attendu

Latence ramenée sous 50 ms partout dans le monde, réduction massive de la bande passante consommée côté serveur d'origine

Mises en pratique

Quatre stacks, quatre contextes.

À titre d'exemple — chaque projet a ses propres contraintes, mais ces combinaisons reviennent souvent.

Site vitrine de PME

Astro en statique précompilé + Nginx + Cloudflare. Coût d'hébergement marginal, robustesse maximale, TTFB sous 100 ms partout.

E-commerce moyen volume

WordPress / WooCommerce avec Varnish + Redis pour les sessions + CDN pour les médias. Catalogue caché, checkout direct, capacité décuplée.

SaaS B2B en croissance

Load balancing HAProxy + 2 serveurs applicatifs + PostgreSQL en réplication + Redis. Bascule à chaud, montée en charge horizontale, déploiements sans coupure.

Média / blog à pics

Statique précompilé + CDN + invalidation au push. Un article qui passe sur les réseaux ne fait plus tomber le site, il fait juste exploser les analytics.

Comment on s'y prend

Pas de stack à la mode, une réponse à votre charge réelle.

  1. 01

    Mesurer avant d'agir

    Tests de charge, analyse des goulots actuels, courbes de trafic réelles. Pas la peine de paralléliser ce qui n'est pas saturé.

  2. 02

    Choisir le pattern qui correspond

    Un site vitrine n'a pas besoin de réplication BDD. Une API à fort trafic n'a pas forcément besoin de CDN. On choisit ce qui apporte un gain mesurable.

  3. 03

    Mettre en place sans casser

    Migration par étapes, pré-prod réaliste, bascule progressive avec rollback préparé. Pas de big bang.

  4. 04

    Documenter et transmettre

    Schéma d'archi, runbook d'exploitation, procédure de mise à jour, plan de bascule. Pour que ce soit maintenable par vous ou par un autre prestataire.

Concevoir l'archi qui tient ?

On regarde votre charge actuelle, vos pics, vos contraintes — et on propose la stack adaptée. Pas de surdimensionnement, pas de jargon : juste ce qui doit tenir.

Discuter de l'archi → Voir l'offre infogérence