La mise à l’échelle horizontale ajoute des serveurs pour répartir une même charge de calcul applicatif sur davantage de machines. C’est utile quand ce calcul sature. La lenteur d’une application, elle, vient rarement de là.
Si le goulot est une requête lente ou une base saturée, ajouter des serveurs applicatifs envoie juste plus de charge au même endroit : il faut corriger la cause logicielle d’abord, mettre à l’échelle après.
Le malentendu
« C’est lent, on rajoute un serveur. » Je connais peu de réponses aussi coûteuses, et la plupart du temps elle ne change rien. Multiplier les serveurs applicatifs augmente la capacité de calcul, oui. Mais dans la grande majorité des applications poussives que je croise, ce n’est pas ce calcul qui plie.
Le coupable se cache presque toujours dans la base de données : une requête sans index, un N+1 qui part en boucle (l’appli lance une requête par ligne d’une liste au lieu d’une seule), une instance unique qui encaisse tout le trafic. Ajouter des serveurs devant ce mur revient à expédier encore plus de requêtes vers une base déjà à genoux. Vous aggravez la situation, en payant plus cher pour l’aggraver.
Ce que des serveurs n’élargissent pas
Une requête SQL lente reste lente quel que soit le nombre de machines qui la lancent : la distribuer ne fait que la jouer en parallèle par plus de monde. Une base unique saturée, elle, voit chaque serveur ajouté ouvrir ses propres connexions, et c’est toujours elle qui règle l’addition. Quant à un appel vers un service tiers qui traîne, son délai de réponse se moque bien de l’endroit d’où part la requête.
Le verrou sur une ressource partagée joue dans la même cour : plus de processus se le disputent, plus la contention grimpe. Y jeter de la puissance, c’est aligner dix voitures de plus devant un péage à cabine unique.
La bonne séquence
Mesurez d’abord où part le temps. Vos serveurs applicatifs touchent-ils le plafond, ou tournent-ils les pouces pendant que la base ploie ? Sans cette réponse, vous achetez à l’aveugle. Vient ensuite la correction logicielle : poser un index, supprimer un N+1, mettre en cache, déporter un traitement en asynchrone. Souvent une demi-journée de travail, pour un effet durable. La mise à l’échelle arrive en dernier, si la charge la réclame encore — et là elle tient ses promesses, parce que le goulot réel est dégagé.
Un cas concret
Une PME e-commerce avait triplé son parc applicatif avant de m’appeler, persuadée que ça finirait par tenir. La facture cloud avait suivi ; le temps de réponse, non. Tout remontait à une seule requête de catalogue, non indexée, rejouée à chaque chargement de page. Index posé, on est passés de 3 secondes à 400 ms, et l’entreprise a pu rendre la moitié de ses serveurs. Le diagnostic qui aurait évité ce détour tenait dans une matinée.
Là où cette méthode s’arrête
Je ne prétends pas que la cause soit toujours logicielle. Certaines applications saturent vraiment leur calcul applicatif : un traitement d’images, un moteur de calcul, une charge qui grimpe par à-coups réels et imprévisibles. Dans ces cas, ajouter des serveurs est la bonne réponse, et tergiverser dessus fait perdre du temps. La règle n’est donc pas « ne jamais mettre à l’échelle ». Elle est plus modeste : mesurer avant de payer, pour ne pas élargir une route qui n’a jamais été le problème.