Une boutique peut enregistrer des ventes correctement tout en utilisant une extension ancienne pour ses exports ou sa préparation de colis. Le passage à HPOS doit donc être évalué sur l’ensemble de ces usages. L’objectif consiste à changer le stockage des commandes sans interrompre les opérations qui en dépendent.
Comprendre ce que HPOS modifie
HPOS, pour High-Performance Order Storage, utilise des tables dédiées aux commandes. La documentation WooCommerce distingue le stockage faisant autorité et les copies synchronisées. Pour une boutique existante, il faut savoir où la boutique lit et écrit réellement ses commandes.
Cette évolution ne remplace pas le contrôle des extensions, des ressources ou des requêtes coûteuses. Une lenteur dans un connecteur ne disparaît pas automatiquement parce que le stockage a changé. Mesurez le parcours concerné avant et après pour vérifier le bénéfice réel sur votre installation.
Inventorier les dépendances
Listez les extensions de paiement, de livraison, de facturation, de synchronisation et de reporting. Ajoutez le code personnalisé et les exports réalisés hors de WordPress. Un script qui lit directement les anciennes tables mérite une vérification spécifique. La compatibilité déclarée d’une extension ne suffit pas à valider un assemblage complet avec vos réglages.
Exemple fictif : une boutique reçoit des commandes dans l’administration, mais son ancien export quotidien ne les trouve plus après une bascule. Le test de création était réussi ; le test d’exploitation manquait. Intégrez donc les personnes qui préparent les colis et rapprochent les règlements à votre recette.
Préparer une copie et la synchronisation
Travaillez d’abord sur une copie récente dont les services externes sont maîtrisés. Prévoyez une sauvegarde exploitable et relevez les réglages de stockage. La documentation précise que le changement de tables faisant autorité est empêché lorsque des commandes attendent encore leur synchronisation. Vérifiez l’état réel de cette synchronisation, sans considérer un écran simplement ouvert comme une preuve de fin.
La préproduction WordPress doit éviter d’envoyer des messages ou des opérations commerciales à de vrais clients. Utilisez des données de test appropriées et un mode de paiement de test lorsque le connecteur le permet. Documentez le retour arrière avant de décider la bascule en production.
Tester les commandes du début à la fin
Créez une commande de test, modifiez son état et vérifiez sa lecture par chaque outil concerné. Essayez aussi une commande historique, une recherche, un export et un remboursement de test. Le guide sur les remboursements WooCommerce aide à distinguer le statut affiché du mouvement réellement exécuté.
Contrôlez les tâches de synchronisation et les notifications associées. Si elles attendent ou échouent, revenez au diagnostic de WP-Cron et Action Scheduler avant d’accumuler les relances. Notez les identifiants d’exemple et le résultat attendu pour pouvoir reproduire une anomalie.
Décider à partir de la recette
La publication dépend des usages vérifiés, de la synchronisation terminée et du retour arrière préparé. Si un connecteur essentiel reste incompatible, reportez la bascule plutôt que de contourner son contrôle. L’accompagnement WooCommerce présenté par WPASSIST peut servir à cadrer une intervention sur cette chaîne. Transmettez la liste des dépendances et les scénarios testés ; ils donnent une base concrète à la décision.
Sources et vérification
Sources primaires consultées le 30 septembre 2026.
