# Passer sous HPOS : une migration WooCommerce ratée puis réussie

> La première tentative de bascule vers le nouveau stockage des commandes s'est soldée par un site inaccessible pendant vingt minutes. La seconde, deux semaines plus tard, s'est déroulée sans incident.

- Auteur : Clément Hadrot
- Publié le : 2023-03-15
- Mis à jour le : 2023-03-15
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/migration-hpos-ratee-puis-reussie-retour-experience/

## L’essentiel

- Une extension de facturation a bloqué la synchronisation initiale
- Le rollback via le mode de compatibilité a évité une catastrophe
- La seconde tentative a fonctionné grâce à un test préalable en environnement isolé

Le client, une boutique de matériel de jardinage avec un peu plus de 60 000 commandes archivées, souhaitait basculer vers le nouveau stockage des commandes de WooCommerce, principalement pour alléger des écrans d'administration devenus lents au fil des années. L'agence avait suivi la documentation officielle, testé la compatibilité annoncée des extensions installées, et planifié la bascule un mardi soir, en dehors des heures de forte affluence.

Vingt minutes après avoir activé le nouveau stockage comme source de vérité, le site est devenu inaccessible, avec une erreur serveur générique sur l'ensemble des pages, y compris l'administration. Ce récit revient sur ce qui s'est mal passé, sur la façon dont l'incident a été résolu dans l'urgence, et sur ce que la seconde tentative, deux semaines plus tard, a fait différemment.

## La première tentative : une bascule qui semblait pourtant prête

L'écran de compatibilité des extensions, consulté avant la bascule, n'affichait aucune extension explicitement marquée incompatible. Cette vérification, pourtant recommandée en priorité, s'est révélée insuffisante : une extension de facturation électronique installée depuis plusieurs années ne déclarait tout simplement rien du tout concernant sa compatibilité HPOS, ni dans un sens ni dans l'autre, ce qui la faisait apparaître comme neutre plutôt que comme un risque identifié.

Cette extension interrogeait pourtant en tâche de fond une colonne de la table `wp_postmeta` propre à l'ancien stockage, à chaque génération de facture programmée par une tâche cron. Une fois le nouveau stockage devenu source de vérité, cette colonne n'était plus alimentée pour les commandes récentes, provoquant une erreur PHP fatale, non interceptée, à chaque exécution de cette tâche cron, ce qui a fini par saturer les processus PHP disponibles sur l'hébergement mutualisé du client.

## Le rollback dans l'urgence

> L'essentiel à retenir : Une extension de facturation a bloqué la synchronisation initiale ; Le rollback via le mode de compatibilité a évité une catastrophe ; La seconde tentative a fonctionné grâce à un test préalable en environnement isolé

Heureusement, le mode de compatibilité HPOS n'avait pas été désactivé, la synchronisation entre ancien et nouveau stockage restant donc active en arrière-plan malgré la bascule. Le retour en arrière a consisté à redéfinir l'ancien stockage comme source de vérité, depuis **WooCommerce › Réglages › Avancé › Fonctionnalités**, puis à désactiver temporairement l'extension de facturation fautive le temps de comprendre l'origine exacte du blocage. Le site est redevenu accessible en quelques minutes après ce retour en arrière, sans perte de donnée de commande grâce à la synchronisation restée active tout du long.

## Deux semaines de préparation supplémentaire

La seconde tentative n'a pas repris le même scénario. L'agence a d'abord contacté l'éditeur de l'extension de facturation pour obtenir une version corrigée, qui a fini par sortir avec une déclaration de compatibilité explicite et un remplacement de sa requête directe par un appel à `$order->get_meta()`. En parallèle, l'équipe a répliqué l'intégralité du catalogue de commandes sur un environnement de type recette, isolé du site en production, pour y reproduire la bascule complète avant de la reproduire en conditions réelles.

Cette répétition en environnement isolé a permis de découvrir un second point d'attention, mineur mais réel : un rapport personnalisé construit par l'agence elle-même, quelques années plus tôt, interrogeait lui aussi directement `wp_postmeta` pour un export comptable mensuel. Corrigé avant la seconde tentative, ce rapport n'a jamais posé de problème en production, contrairement à l'extension tierce découverte trop tard la première fois.

## La seconde bascule, sans incident

Le jour de la seconde tentative, la bascule s'est déroulée sans aucun signe d'instabilité. La synchronisation, laissée active vingt-quatre heures supplémentaires par précaution avant de désactiver définitivement l'ancien stockage, n'a signalé aucun écart via l'outil de vérification intégré. Les écrans d'administration ont montré une amélioration nette de la vitesse d'affichage de la liste des commandes, particulièrement visible sur les filtres combinant plusieurs statuts, un des usages quotidiens les plus fréquents de l'équipe du client.

> Un écran de compatibilité qui n'affiche aucun avertissement ne veut pas dire qu'aucune extension ne pose problème : il ne dit que ce que les extensions ont bien voulu déclarer elles-mêmes.

## Ce que cette expérience a changé dans la méthode de l'agence

Depuis cet incident, l'agence n'aborde plus une migration HPOS sans une étape de reproduction complète sur un environnement isolé représentatif du volume réel de commandes, quelle que soit la taille du client. La vérification de compatibilité déclarée par les extensions reste une première étape utile, mais elle ne remplace en rien un audit manuel des extensions qui manipulent directement les commandes, en particulier celles qui n'ont pas été mises à jour récemment.

- Auditer le code de chaque extension touchant aux commandes, pas seulement lire son statut de compatibilité affiché.
- Toujours laisser le mode de compatibilité actif plusieurs jours après la bascule, jamais désactivé le jour même.
- Reproduire la migration sur un environnement isolé avec un volume de données proche de la production, pas un jeu de données de test réduit.

## En résumé

L'échec initial ne venait ni de WooCommerce ni de sa documentation, mais d'une extension tierce dont la compatibilité, faute de déclaration explicite, n'avait pas été suffisamment vérifiée avant la bascule. La seconde tentative a réussi précisément parce que l'agence a traité cet incident comme un signal méthodologique plutôt que comme un simple accident isolé, en ajoutant un audit manuel là où la vérification automatique s'était révélée insuffisante.