La performance relève de l’architecture, pas d’une optimisation après coup

Dans bien trop de projets, la performance est traitée comme une étape de finition – quelque chose à « optimiser plus tard ». À ce stade, c’est déjà un problème d’architecture assorti d’une échéance, et les solutions bon marché ont disparu. Les systèmes rapides sont conçus pour la vitesse dès le départ.

La lenteur vient rarement d’un seul bug : c’est le poids cumulé d’une centaine de petites décisions – des requêtes trop nombreuses, des volumes de données sans limite, aucune stratégie de cache, des traitements qui bloquent le rendu. Lorsque la lenteur devient visible, la corriger implique de modifier l’architecture, pas d’ajuster un paramètre.

La solution consiste à faire de la performance une exigence mesurée à chaque version, et non un simple espoir. Les Core Web Vitals, la latence p95 et les budgets de poids deviennent des seuils bloquants : une modification qui les dégrade n’est pas publiée tant qu’elle n’a pas été corrigée. Ce que l’on mesure et contrôle reste rapide.

• La diffusion en périphérie (edge) et une stratégie de cache réfléchie pour le chemin critique.
• Une couche de données qui ne génère pas de requêtes N+1 sous charge.
• Des volumes de données et des images correctement dimensionnés, servis dans des formats modernes.
• Une observabilité qui permet de détecter les régressions avant les utilisateurs.

Concevez pour le pire jour de l’année – pic de trafic, caches vides, grand lancement – et le jour ordinaire se gère tout seul. La performance n’est pas une finition : c’est de l’architecture.