Migration PrestaShop de Hestia vers DirectAdmin
Une migration PrestaShop ne signifie pas nécessairement le déplacement de toute la pile. Dans ce cas, j'ai déplacé le backend d'une ancienne configuration Hestia vers un nouvel hébergement basé sur DirectAdmin en une seule soirée. Le frontend est resté sur sa plateforme existante. Les services de newsletter et de CRM sont restés à leur place. Le périmètre était plus restreint : faire en sorte que le nouveau backend gère les API REST, le cache et les cron pour un système ecommerce multiboutique.
Le travail actif a pris environ trois à quatre heures. Le transfert de fichiers était la partie facile. Le vrai travail consistait à prouver que le routage, Redis, les cron, l'invalidation du cache et les réponses API spécifiques aux boutiques fonctionnaient toujours après le déplacement.
Ce que j'ai déplacé dans la migration PrestaShop
Le backend a atterri sur un plan d'hébergement partagé moderne avec stockage NVMe, CPU alloué et RAM allouée. Le panneau d'hébergement affichait le paquet et le quota disque attendus.
Je n'ai pas tout déplacé, et c'était intentionnel.
Déplacé :
Laissé en place :
Je préfère ce type de migration PrestaShop ciblée car elle réduit le bruit. Si vous déplacez le frontend, la pile marketing et le backend en même temps, vous créez trop de variables. Ici, je voulais valider un seul système métier clair.
Le routage était le premier problème
PrestaShop fonctionne comme un backend multiboutique. Cela signifie qu'un seul backend doit répondre correctement pour deux boutiques. Sur l'ancien hôte, les règles du panneau et le comportement URL existant masquaient une partie de la complexité. Sur le nouvel hôte, les appels REST devaient préserver le contexte de la boutique avant que PrestaShop ne redirige ou ne canonicalise la requête.
La solution consistait à router correctement les appels REST préfixés par la boutique :
Cela semble mineur sur le papier. En pratique, c'est le genre de détail qui donne l'impression qu'une migration est cassée même lorsque les fichiers, la base de données et le DNS sont corrects. Dans mon travail, je vérifie le routage avant de blâmer PHP, Redis ou la base de données.
Redis a aidé, mais le vidage du cache comptait davantage
Redis a été activé via un socket Unix :
text /home/account/.redis/redis.sock
PrestaShop a ensuite utilisé Redis comme backend de cache. Les réponses API se sont améliorées, mais le cache n'a d'importance que s'il se vide au bon moment.
Le back office est la source de vérité. Lorsque quelqu'un modifie un prix, une description de produit, un bloc PageBuilder, une catégorie ou une campagne dans PrestaShop, l'API frontend doit servir des données fraîches. Activer le cache seul ne suffit pas. J'ai également dû connecter le vidage du cache aux hooks PrestaShop pertinents.
J'ai vérifié le comportement directement :
C'est la différence entre « le cache est activé » et « le cache est digne de confiance ». Dans l'ecommerce, cette différence compte immédiatement.
Les tâches cron nécessitaient un filtrage attentif
La première vérification des cron Hestia a trouvé des tâches appartenant à un autre service, et non au backend PrestaShop. Ces tâches n'avaient pas leur place sur le nouvel hôte car ce service ne faisait pas partie de cette migration.
Les tâches PrestaShop pertinentes se trouvaient sur l'ancien serveur Hestia en production :
Je n'ai pas migré une tâche CRM suspendue. J'ai également ignoré les tâches système internes de Hestia. DirectAdmin possède son propre flux de maintenance et de sauvegarde, donc copier les débris du panneau n'aurait fait que créer de la confusion.
Une tâche de dump de base de données a d'abord été mappée comme un dump de développement prudent. Je l'ai supprimée une fois confirmé que le panneau d'hébergement gérait déjà les sauvegardes. Dupliquer les flux de sauvegarde crée du bruit sauf s'il y a une raison claire de récupération.
Résultats de performance suite au déplacement du backend
J'ai testé le même endpoint REST public 12 fois par boutique :
text /rest/pagebuilder/placements
Voici les résultats :
| Environnement | Moyenne Boutique A | Moyenne Boutique B |
|---|---|---|
| --- | ---: | ---: |
| Ancien Hestia en production | 0.500s | 0.420s |
| Hestia de staging | 0.305s | 0.302s |
| Nouvel hôte DirectAdmin | 0.267s | 0.220s |
Le serveur de staging était un serveur de référence simple et répondait de manière cohérente. Le nouvel hôte répondait toujours plus rapidement pour les deux boutiques.
Le nouvel hôte a également affiché une charge moyenne du serveur plus élevée, autour de 10-13. SSH exposait plus de threads CPU sur l'hôte physique que l'allocation du compte, donc ce chiffre n'était pas alarmant en soi. Le compte semblait calme : Redis était presque inactif, les workers PHP ne sollicitaient pas le CPU, et la base de données avait une faible charge de requêtes actives lorsque j'ai vérifié.
C'est pourquoi je traite la charge moyenne avec prudence sur l'hébergement partagé. Elle reflète l'hôte, et pas seulement un compte. Si votre fournisseur vend un plan avec des spécifications claires de CPU et de RAM, il est toujours utile de demander comment ces limites sont appliquées via CloudLinux ou LVE.
Mon flux de travail IA pour la migration
J'ai utilisé Codex comme agent opérationnel pour SSH, le travail avec l'API DirectAdmin, les vérifications du serveur, les modifications de crontab, les tests de timing et le travail de surcharge (override) PrestaShop.
Pour la revue, j'utilise mon flux de travail ouvert ai-collab-bridge. L'idée est simple : une IA implémente le changement, puis une autre IA reçoit un paquet de revue avec le diff, le contexte et des questions ciblées. Claude Code peut alors revoir le travail en tant que second lecteur technique au lieu de réagir à un résumé vague.
Cela compte dans une migration PrestaShop car il y a beaucoup de petites décisions :
L'IA aide lorsqu'elle doit montrer ses vérifications. « Ça marche » ne suffit pas. Une exécution de migration utile montre les commandes, les codes de statut, le comportement du cache, l'état des cron et les parties qui n'ont pas été intentionnellement déplacées.
Leçons tirées de cette migration
Ne copiez pas aveuglément le comportement du panneau. Hestia et DirectAdmin résolvent la maintenance d'hébergement différemment. Le cron du panneau Hestia n'a pas sa place dans DirectAdmin.
Gardez la migration du backend étroite. Si le frontend fonctionne déjà ailleurs, le déplacer ajoute seulement des risques.
Vérifiez le cache du point de vue du back office. Les changements ecommerce se produisent via les prix, les stocks, les textes et les modifications de campagnes. Un cache qui ne se vide pas devient un problème métier.
Mesurez le même endpoint à plusieurs reprises. Une seule requête `curl` en dit peu. Douze exécutions par boutique m'ont donné un signal beaucoup plus clair.
Ne codez pas en dur les mots de passe de base de données dans les scripts. Lisez depuis la configuration existante de l'application lorsque nécessaire, et laissez le panneau d'hébergement gérer les sauvegardes.
Résultat
Après le déplacement, le backend a répondu plus rapidement que l'ancien serveur en production et la référence de staging dans mes tests. Redis et LiteSpeed ont aidé. L'API DirectAdmin était suffisante pour les paramètres de panneau dont j'avais besoin. La mémoire OPcache s'est avérée être un paramètre au niveau de l'hôte, donc cela relève du support d'hébergement plutôt que du code de l'application.
Le résultat principal n'était pas un TTFB plus faible. Le résultat important était que le backend se comportait toujours comme un backend ecommerce : le back office possède les données, l'API répond par boutique, le cache se vide lors des changements, et les cron exécutent uniquement les tâches qui appartiennent au nouvel hôte.
FAQ
Combien de temps a duré la migration ?
La migration active du backend a pris environ trois à quatre heures. Avec les tests de timing, l'inventaire des cron, la vérification du cache et les notes de support, le travail s'est rapproché de quatre à cinq heures.
Pourquoi n'avez-vous pas tout déplacé ?
Le frontend fonctionnait déjà ailleurs. L'automatisation des newsletters et le CRM avaient leurs propres environnements. Un déplacement étroit du backend a réduit les risques.
Pourquoi Redis était-il important ?
Redis a amélioré la vitesse du cache du backend, mais la vraie valeur est apparue lorsque le vidage du cache a été connecté aux hooks PrestaShop. Sans cela, les changements du back office peuvent ne pas atteindre l'API.
Pourquoi la charge moyenne est-elle difficile à lire sur l'hébergement partagé ?
La charge moyenne montre souvent la file d'attente de l'ensemble de l'hôte, et pas seulement votre compte. Dans cette migration, le compte semblait calme tandis que l'hôte affichait une charge plus élevée. C'est pourquoi les limites CloudLinux ou LVE doivent être confirmées par le support.
Pourquoi utiliser l'IA dans une migration de serveur ?
L'IA est utile lorsqu'elle travaille avec des preuves : lectures de configuration, tests de timing, comparaison des cron, vérifications API et changements documentés. La revue par les pairs via un flux de travail ouvert facilite la tâche pour qu'un autre modèle inspecte les risques.