La plupart des boutiques WooCommerce essaient d’accélérer en installant un plugin de cache supplémentaire. Cela fonctionne jusqu’à un certain point, mais le plafond réel est fixé par le serveur : PHP, la base de données, le cache d’objets et surtout ce WP-Cron qui se déclenche à chaque visite. Quand tout cela est bien réglé au niveau système, la boutique vole. Quand ce n’est pas le cas, aucun plugin ne vous sauve en campagne.
Je m’occupe de la couche système : le serveur, le système d’exploitation et tous les services sur lesquels tournent WordPress et WooCommerce. La boutique elle-même — thème, plugins, code et mises à jour de WordPress/WooCommerce — est gérée par l’agence ou votre équipe de développement. Mon rôle est de m’assurer que l’environnement où vit la boutique est rapide, sécurisé, surveillé et disponible.
Je travaille principalement avec des agences et des développeurs qui ont besoin d’un spécialiste systèmes pour leurs projets WooCommerce sans l’intégrer à l’équipe, et aussi directement avec des responsables e-commerce qui veulent une boutique robuste. En arrière-plan, comme une extension de votre équipe.
Point de départ : les problèmes que je rencontre habituellement
La plupart des projets WooCommerce arrivent avec l’un de ces symptômes :
- La boutique est lente et le plugin de cache ne suffit pas. TTFB élevé, panier et checkout lourds, wp-admin qui traîne. Le plugin met en cache la page d’accueil, mais les pages qui comptent vraiment dans une boutique ne peuvent pas être cachées de la même façon — et c’est là que le serveur se révèle.
- WP-Cron incontrôlable. Les tâches planifiées de WordPress se déclenchent à chaque visite, chargeant le serveur précisément quand le trafic est le plus élevé. C’est l’un des goulots d’étranglement les plus courants et il se résout au niveau système.
- Elle tombe exactement quand elle vend le plus. Soldes, Black Friday, une newsletter qui fonctionne trop bien… et le serveur rend les armes au pire moment possible.
- Attaques sur wp-login et xmlrpc. WordPress est le CMS le plus attaqué au monde : force brute sur le login, abus de XML-RPC, bots incessants. Une grande partie peut être coupée avant même d’atteindre PHP.
- Une migration ou un nouveau serveur. Sortie d’un hébergement mutualisé devenu trop petit, changement de serveur ou consolidation, sans perdre de ventes ni de SEO. (Les mises à jour de la boutique sont coordonnées par votre équipe ; moi je prépare et migre l’infrastructure.)
Si l’un de ces points vous parle, c’est là que j’interviens.
Comment je résous le problème
Je ne vends pas de recettes magiques, d’« optimisations » génériques ni un énième plugin. La méthode est toujours la même : mesurer, dimensionner et affiner le stack précis de votre boutique au niveau du serveur.
Je pars de données réelles (métriques serveur, profilage des services, logs de trafic des campagnes précédentes) pour identifier le vrai goulot d’étranglement avant de toucher quoi que ce soit. Ensuite j’ajuste chaque service du stack — serveur web, PHP, base de données, cache d’objets — selon le profil de charge réel de votre boutique, je laisse tout documenté et reproductible, et je reste disponible pour les pics. L’idée est que l’infrastructure soit prête avant la campagne, pas à éteindre des incendies pendant. La boutique tourne au-dessus ; je m’assure qu’elle a un sol solide sous les pieds.
Ce que cela inclut
Voici ce que j’apporte au niveau système dans un projet WooCommerce. Vous n’avez pas besoin de tout prendre : c’est adapté aux besoins du projet.
Performance et optimisation du stack
- Réglage de PHP-FPM et OPcache selon le profil de charge réel de la boutique (pools, workers, mémoire).
- Configuration du serveur web (Nginx ou Apache) avec FastCGI cache, compression, cache des statiques et HTTP/2 ou HTTP/3.
- Cache de pages au niveau serveur excluant correctement le panier, le checkout et le compte client — exactement ce qu’un plugin de cache fait généralement mal dans une boutique.
- Provisionnement et configuration de Redis / Memcached comme cache d’objets persistant pour WordPress.
- WP-Cron désactivé et remplacé par un vrai cron système, pour que les tâches planifiées cessent de se déclencher à chaque visite.
- Réglage de MariaDB/MySQL (buffer pool, connexions, requêtes lentes) — très sensible au poids de
wp_options, des transients et des plugins. - Provisionnement du service de recherche (ex. Elasticsearch pour ElasticPress) si le projet le requiert.
Préparation aux campagnes et aux pics
- Tests de charge préalables pour connaître le plafond réel du serveur avant l’événement.
- Dimensionnement des ressources (vertical et, le cas échéant, horizontal avec répartition de charge) pour absorber le pic.
- Plan de contingence et disponibilité renforcée (on-call) pendant la fenêtre critique.
Sécurité et hardening
- Hardening serveur et protection de wp-login.php et XML-RPC (limites de débit, fail2ban, blocage de la force brute) avant que la requête n’atteigne PHP.
- Mises à jour de sécurité système : OS, kernel et services du stack à jour. (Les mises à jour de WordPress, des plugins et du thème relèvent de votre équipe ; je sécurise ce qui est en dessous.)
- WAF devant la boutique (Cloudflare, ModSecurity ou autres) et mitigation des bots et du scraping.
- Pare-feu, permissions de fichiers correctes et en-têtes de sécurité au niveau du serveur web.
- Bonnes pratiques orientées conformité PCI-DSS côté infrastructure, et gestion des certificats TLS avec renouvellement automatique.
Migrations d’infrastructure
- Migrations d’hébergement ou de serveur sans downtime perceptible et sans perte de SEO.
- Sortie de l’hébergement mutualisé vers un environnement dédié ou cloud correctement dimensionné.
- Provisionnement d’environnements staging et production équivalents, pour que votre équipe déploie et teste sur une base solide.
- Migration des données et services au niveau système, avec un plan de retour en arrière clair en cas de problème.
Sauvegardes et supervision
- Sauvegardes chiffrées, externalisées et testées (règle 3-2-1) : une sauvegarde qui n’a jamais été restaurée ne compte pas.
- Supervision continue du serveur, des services et de la disponibilité — pour que vous le sachiez avant votre client.