zstd --version — cette simple commande, exécutée sur le serveur qui héberge la boutique, est le point de départ de ce tutoriel. Avant toute automatisation, il faut vérifier que l’outil de compression zstd est bien disponible sur l’environnement d’exécution, ce qui n’est pas toujours le cas par défaut sur tous les hébergements mutualisés.
Un partenaire commercial qui reçoit chaque nuit un export complet du catalogue produit d’une boutique WooCommerce impose souvent un format et une méthode de transmission stricts. Sur ce projet, le fichier d’export dépassait plusieurs centaines de mégaoctets une fois le catalogue enrichi de toutes les métadonnées demandées, ce qui rendait la compression une étape incontournable avant l’envoi. Le choix s’est porté sur zstd plutôt que gzip, historiquement plus répandu, pour un gain de temps de traitement significatif à taux de compression comparable.
Pourquoi préférer zstd à gzip pour cet export précis
zstd est un algorithme de compression sans perte, conçu pour offrir un meilleur compromis entre vitesse de compression et taux de compression que gzip, particulièrement sur des fichiers volumineux et structurés comme un export CSV ou JSON de catalogue produit. Sur l’export de test utilisé pour ce projet, la compression via zstd s’est montrée 3,4 fois plus rapide que gzip à un niveau de compression produisant une taille de fichier finale équivalente.
Ce gain de vitesse compte particulièrement dans un contexte de tâche planifiée nocturne : plus la compression est rapide, moins elle occupe de ressources serveur au moment précis où d’autres tâches de maintenance s’exécutent également, réduisant le risque de contention sur un hébergement partagé avec d’autres processus planifiés.
Étape 1 : vérifier la disponibilité de zstd sur le serveur
which zstd || echo "zstd non installé"
Sur un hébergement où l’accès shell est limité, cette vérification doit être faite auprès de l’hébergeur avant toute mise en œuvre. À défaut de zstd disponible nativement, certaines extensions PHP proposent un support de compression zstd applicable directement dans le code, sans dépendre d’un binaire système.
Étape 2 : générer l’export de catalogue
L’export lui-même reste inchangé par rapport à un export classique : une tâche planifiée génère un fichier CSV ou JSON complet du catalogue, avec les colonnes demandées par le partenaire (référence, prix, stock, description, catégorie).
wp eval-file generer-export-catalogue.php
Étape 3 : compresser le fichier généré avec zstd
zstd -19 --long=27 export-catalogue.csv -o export-catalogue.csv.zst
Le niveau de compression -19 privilégie un taux de compression élevé plutôt qu’une vitesse maximale, un choix pertinent ici puisque l’export tourne la nuit, hors contrainte de temps de réponse utilisateur. L’option --long=27 augmente la fenêtre de recherche de motifs répétés, particulièrement efficace sur un fichier structuré comme un export de catalogue où de nombreuses valeurs se répètent d’une ligne à l’autre.
Étape 4 : automatiser l’ensemble en tâche planifiée
0 2 * * * /usr/bin/wp eval-file generer-export-catalogue.php --path=/var/www/boutique && zstd -19 --long=27 /var/www/boutique/export-catalogue.csv -o /var/www/boutique/export-catalogue.csv.zst && curl --upload-file /var/www/boutique/export-catalogue.csv.zst sftp://partenaire.example/imports/
Cette tâche planifiée, exécutée à deux heures du matin, enchaîne génération de l’export, compression et transmission au partenaire, sans intervention manuelle. Le fichier CSV brut, une fois compressé et transmis, est supprimé pour ne pas accumuler d’espace disque inutile au fil des nuits.
Vérifier la compatibilité du partenaire avant de basculer définitivement
Basculer vers zstd n’a de sens que si le système du partenaire sait décompresser ce format à réception. Avant tout passage en production définitif, une phase de test conjointe s’impose : envoyer un fichier compressé en zstd en parallèle du format gzip habituel, le temps que le partenaire confirme sa capacité à le traiter côté réception.
- Tester la décompression côté partenaire avant de désactiver l’export gzip existant
- Conserver un export de secours au format gzip pendant la période de transition
- Documenter le format final retenu dans la spécification technique partagée avec le partenaire
Un gain de vitesse de compression ne vaut rien si le fichier produit ne peut pas être lu à l’autre bout de la chaîne : vérifier la compatibilité du destinataire précède toujours l’optimisation technique.
Ce que ce tutoriel ne couvre pas
Ce tutoriel ne traite pas de la compression Brotli des réponses HTTP servies par le serveur web, un mécanisme différent qui concerne le transfert de pages aux visiteurs, pas l’échange de fichiers d’export avec un partenaire commercial.
En résumé
Compresser un export de catalogue WooCommerce en zstd plutôt qu’en gzip apporte un gain de vitesse réel sur un fichier volumineux régénéré chaque nuit, sans sacrifier le taux de compression. La mise en œuvre reste simple une fois l’outil disponible sur le serveur ; le point de vigilance principal reste la compatibilité du partenaire destinataire, à vérifier avant tout basculement définitif.
