AccueilHome / Services / 02 — WEBPERF
02 · WEBPERF

Performance Web.Web performance.

Parce qu'une application lente coûte des clients.Because a slow application costs customers.

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.A site that takes three seconds to respond is a site people stop visiting. We profile, instrument and optimize your stack — from CDN to database engine — so speed becomes an edge, not a drag.

Diagnostic avant toutDiagnose first

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.Before changing anything, we measure. Traces, flamegraphs, CPU profiles, query plans. Performance isn't guessed — it's measured, then fixed.

  • 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é
  • End-to-end performance audit (front, back, DB)
  • Continuous production profiling
  • N+1, lock and contention hunting
  • Real-user Core Web Vitals measurement
  • Architecture review for scalability

Optimisation à tous les étagesOptimize every floor

Chaîne de requête — chaque milliseconde gagnéeRequest chain — every millisecond wins 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.Tuned Nginx, multi-layer caching, CDN set up right, rewritten SQL queries, indexes placed with judgment, pooled connections. No silver bullet — just meticulous work, layer by layer.

Scalabilité — 100% d'uptime, garantiScalability — 100% uptime, guaranteed

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.When a client requires real availability and a contractual performance SLA, we don't improvise — we deploy a fully redundant architecture. Here's a representative example: a high-traffic institutional site, two mirrored backends, replicated database, shared cache, common NFS storage, and a front proxy distributing load with least_conn. If one box dies, the other takes over — with no visible outage.

Architecture HA — deux backends, un seul serviceHA architecture — two backends, one 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 applicatifapplication service données statefulstateful data replication / syncreplication / 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.What makes this architecture resilient isn't a magic component — it's the discipline of redundancy. Every stateful piece has a plan B: the database is replicated, files live on shared NFS, the cache is reachable from both nodes, deployments replay via rsync from GitLab. We can take a backend down at noon for maintenance — nobody notices.

  • 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
  • Transparent failover at proxy level (least_conn + healthchecks)
  • MariaDB master → replica replication, reads distributed
  • Shared Valkey / Redis cache reachable from both app nodes
  • Common NFS storage: one source of truth for the code
  • Reproducible deploy via GitLab CI + atomic rsync
  • Zero-downtime maintenance: drain a backend, fail over, patch, return

Les autres servicesOther services

Envie d'un regard neuf sur votre infra ? Want a fresh pair of eyes on your infra?

Planifier un appelBook a call