Hébergement WooCommerce. Du catalogue jusqu'à la commande.

Un site WordPress sert des pages qui se ressemblent d'un visiteur à l'autre : le cache les garde en mémoire et le serveur travaille peu. WooCommerce ajoute trois pages qui ne se mettent jamais en cache, le panier, le compte client et la commande. Sur ces trois pages, chaque acheteur mobilise PHP et la base de données rien que pour lui, alors qu'une simple page de catalogue demande déjà des dizaines de requêtes à la base. C'est pour cela qu'un cache d'objets en mémoire devient indispensable là où un blog s'en passe très bien. S'y ajoutent une file d'attente qui doit avancer même quand personne ne visite, et des commandes qui s'accumulent dans la base année après année. Le marché place le passage à une offre e-commerce autour de quelques centaines de produits, dès que les commandes deviennent régulières. Nous, nous le décidons sur votre trafic mesuré et sur le nombre de commandes que vous traitez vraiment.

Quatre signaux reviennent toujours. Aux heures de pointe, le tunnel de commande met trois ou quatre secondes à s'afficher. Pendant une opération commerciale, le serveur rend une erreur 500 ou 504 à la place de votre boutique, au moment précis où les acheteurs arrivent. Le back-office traîne dès que vous éditez des commandes ou que vous lancez un export. Et les tâches automatiques prennent du retard : WooCommerce les liste lui-même dans son écran des actions planifiées, avec celles qui ont échoué. Pour trancher, testez toujours les quatre mêmes pages : l'accueil, une page catégorie bien remplie, une fiche produit à variations, puis le panier et la commande. La page d'état de WooCommerce dit aussi, d'un coup d'œil, si votre serveur porte les versions et les composants attendus. Nous faisons ce relevé avec vous pendant l'audit, et nous vous disons ce qui vient du serveur, ce qui vient d'une extension et ce qui vient du thème.

Ce qui décide, c'est la forme de votre trafic. L'éditeur le dit clairement : quand un produit part en promotion, tout votre trafic se concentre sur cette fiche et sur le panier. L'indicateur qu'il recommande de suivre est le nombre moyen d'ajouts au panier par minute, et c'est celui que nous regardons avec vous. En pratique, le marché français passe à des ressources dédiées entre 20 000 et 150 000 visites par mois, avec un cache d'objets qui ne se vide pas et des images servies par un CDN, ce réseau qui les rapproche de l'acheteur. Au-delà, ou dès que les opérations commerciales reviennent tous les mois, il devient courant de séparer le serveur web de la base de données et de tester la montée en charge avant chaque opération. Quant au plafond, l'éditeur cite des boutiques de plus de cent mille produits, à plusieurs milliers de transactions chaque minute, à condition d'y mettre l'hébergement et l'équipe de développement qui vont avec. Nos paliers vont du serveur dédié au cluster, ils sont détaillés sur la page Tarifs, et le dimensionnement se décide après l'audit.

Le stockage haute performance des commandes, HPOS, range vos commandes dans leurs propres tables au lieu de les mélanger aux articles de WordPress. Vous y gagnez des index taillés pour elles, une base qui travaille moins à chaque lecture et à chaque écriture, et des commandes que l'on restaure sans remonter tout le reste. Une boutique installée récemment l'a déjà : c'est le comportement par défaut depuis la version 8.2. Sur une boutique plus ancienne, il y a un ordre à respecter : WooCommerce ouvre d'abord un mode de compatibilité qui alimente les deux stockages en même temps, il reprend l'historique par lots de vingt-cinq commandes, et il bloque le basculement tant qu'une extension incompatible reste active. À l'inverse, les extensions qui créent leurs propres contenus, les abonnements et les réservations par exemple, doivent rester allumées pendant l'opération, sous peine d'incohérences dans les données. Nous rejouons donc la bascule sur une préproduction avec vous ou avec votre agence, et nous gardons le mode de compatibilité un moment : tant qu'il est actif, le retour en arrière est immédiat.

Vos serveurs sont sous surveillance continue, 24 h/24 et 7 j/7. La nuit et le week-end, une urgence déclenche une alerte SMS et l'intervention commence, avec quelqu'un qui exploite déjà vos machines. Un incident qui rend la boutique inaccessible ouvre notre délai d'intervention : 30 minutes en heures ouvrées, du lundi au samedi, et 6 heures le reste du temps. Côté sauvegardes, deux serveurs installés dans deux pays européens, chez des fournisseurs autres que celui de votre production, gardent en permanence au moins neuf points de restauration : un par jour sur sept jours glissants, plus deux bimensuels, le 1er et le 16. Nous contrôlons leur intégrité. À partir de nos offres d'infogérance avancées, nous rejouons une restauration complète une fois par an, à la date que vous choisissez. Vos données ne quittent pas l'Union européenne. Et la ligne d'appel 24/7, celle qui vous permet de nous joindre vous-même à trois heures du matin, se souscrit en option.