Le mythe du gros serveur
Face à une application qui rame, le premier réflexe consiste à louer une machine plus puissante. Ça marche, une fois, et ça masque le vrai sujet. Dans la majorité des cas observés, la lenteur ne vient pas du matériel mais d'une requête en base mal construite, répétée des centaines de fois pour afficher une seule page. Doubler le serveur double alors le coût sans rien régler durablement.
La scalabilité commence donc dans le code : ce qu'on demande à la base de données, ce qu'on garde en cache, ce qu'on traite en arrière-plan au lieu de faire attendre l'utilisateur. Un envoi d'emails, une génération de PDF ou un appel à un service externe n'ont rien à faire dans le temps de réponse d'une page.
Grandir horizontalement
Vient ensuite l'infrastructure. Un système conçu pour être répliqué peut absorber un pic en ajoutant des instances, puis les retirer quand le pic retombe. Cela impose des choix dès la conception : ne pas stocker l'état de la session sur le disque d'un serveur, externaliser les fichiers, rendre les traitements reproductibles. Une application qui n'a pas été pensée ainsi ne peut pas être répartie a posteriori sans travail de fond.
Le corollaire est budgétaire. Une architecture élastique ne coûte pas le prix du pic toute l'année : elle coûte le prix de l'usage. C'est souvent l'argument qui fait basculer un hébergement historique vers une approche architecture cloud.
Mesurer avant d'investir
On ne dimensionne pas sur une intuition. Les questions utiles sont concrètes : combien d'utilisateurs simultanés au maximum, quel pic saisonnier, quel temps de réponse acceptable, quelle part du trafic peut être servie depuis un cache. Sans observabilité, ces réponses n'existent pas et l'optimisation se fait au hasard.
La bonne cible n'est jamais « le plus scalable possible », c'est un système qui tient la charge prévue, dont on connaît le point de rupture et dont on sait quoi faire quand il approche. C'est ce cadrage que nous posons dans nos missions cloud et DevOps.
