El servidor es lo que aguanta
cuando crece el catálogo.

La plupart des pannes de boutique ne viennent pas du code mais de la machine qui l'exécute. Un import produit qui s'arrête à la moitié, c'est une limite de mémoire ou de temps d'exécution. Une relance de panier qui ne part jamais, c'est un cron qui n'a jamais été déclaré.

Une page catégorie qui met huit secondes alors qu'elle en mettait deux l'an dernier, c'est une base qui a grossi sans que ses index suivent. Ces trois symptômes se ressemblent vus du back-office — tout paraît normal — et ils n'ont rien à voir entre eux. Le travail commence donc par un relevé, pas par une recommandation : quelles limites PHP sont réellement appliquées, quelles tâches planifiées existent et lesquelles ont tourné cette semaine, quelles requêtes lentes s'accumulent, ce que les sauvegardes contiennent vraiment.

Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde — c'est une hypothèse. Ensuite seulement vient le réglage : mémoire et temps d'exécution alignés sur les traitements les plus lourds, OPcache dimensionné, cron déclarés côté serveur plutôt que dépendants d'une visite, index créés là où les requêtes les réclament. Et un monitoring qui prévient avant le client : uptime, certificat, espace disque, échec de sauvegarde.

Je travaille sur l'hébergement que vous avez — mutualisé o2switch, OVH, VPS ou dédié. Changer d'hébergeur est parfois la bonne réponse, mais c'est rarement la première : une boutique lente sur un mutualisé le reste souvent sur un VPS, parce que ce n'était pas la puissance qui manquait.