Accueil / Services / 02 — WEBPERF
02 · WEBPERF

Performance Web.

Parce qu'une application lente coûte des clients.

Le site qui met trois secondes à répondre, c'est le site qu'on ne visite plus. Nous profilons, instrumentons et optimisons votre stack — du CDN au moteur de base de données — pour que la vitesse redevienne un avantage compétitif, pas un frein.

Diagnostic avant tout

Avant de changer quoi que ce soit, nous mesurons. Traces, flamegraphs, profils CPU, plans de requêtes. La performance ne se devine pas — elle se mesure, puis se corrige.

  • Audit de performance end-to-end (front, back, DB)
  • Profilage continu en production
  • Identification des N+1, locks, contentions
  • Mesures Core Web Vitals en conditions réelles
  • Revue d'architecture pour la scalabilité

Optimisation à tous les étages

Chaîne de requête — chaque milliseconde gagnée p99 < 120ms · target
user CDN edge cache 1-8 ms nginx / lb tls · routing 2 ms redis hot cache < 1 ms app stateless pod 15-40 ms postgres pooled · indexed 6-20 ms OBSERVABILITY prometheus flamegraphs · trace

Nginx tuné, cache multi-niveaux, CDN bien configuré, requêtes SQL réécrites, index posés avec discernement, connexions poolées. Pas de silver bullet — juste du travail méticuleux, layer par layer.

Scalabilité — 100% d'uptime, garanti

Quand un client exige une disponibilité réelle et un engagement contractuel sur les performances, on ne bricole pas — on déploie une architecture redondée de bout en bout. Voici un exemple représentatif : un site institutionnel à fort trafic, deux backends miroirs, base de données répliquée, cache partagé, stockage NFS commun, et un proxy en frontal qui distribue la charge en least_conn. Si une machine tombe, l'autre prend le relais — sans coupure visible.

Architecture HA — deux backends, un seul service uptime 100% · least_conn
users / browsers https nginx reverse proxy tls · cache · load balancer FRONTEND least_conn BACKEND 1 apache + php-fpm mariadb 12.2 master · reads + writes valkey (redis) · :6379 nfs server /var/www/site BACKEND 2 apache + php-fpm mariadb 12.2 replica · reads only nfs mount /var/www/site replication tcp 6379 nfs gitlab ci/cd rsync solr search solr.srv:8981 · external index
service applicatif données stateful replication / sync

Ce qui rend cette architecture résiliente, ce n'est pas un composant magique — c'est la discipline de la redondance. Chaque pièce stateful a un plan B : la base est répliquée, les fichiers sont sur NFS partagé, le cache est joignable depuis les deux noeuds, le déploiement est rejoué via rsync depuis GitLab. On peut couper un backend en pleine journée pour faire de la maintenance — personne ne s'en rend compte.

  • Failover transparent au niveau du proxy (least_conn + healthchecks)
  • Réplication MariaDB master → replica, lectures distribuées
  • Cache Valkey / Redis partagé entre les deux noeuds applicatifs
  • Stockage NFS commun : une seule source de vérité pour le code
  • Déploiement reproductible via GitLab CI + rsync atomique
  • Maintenance sans coupure : drainage d'un backend, on bascule, on patche, on remet

Les autres services

Envie d'un regard neuf sur votre infra ?

Planifier un appel