# Retour d’expérience après une migration de Kinsta vers WP Engine > Deux hébergements infogérés, deux façons différentes de gérer le cache, les environnements et le support. Ce qui change concrètement une fois la migration terminée. - Auteur : WordPress Développement - Publié le : 2021-02-01 - Mis à jour le : 2021-02-01 - Catégorie : Hébergement & serveurs - URL : https://www.wpmoderne.fr/hebergement/migration-kinsta-vers-wp-engine-retour-experience/ ## L’essentiel - Le cache objet et le cache de page ne fonctionnent pas de la même façon d'un hébergeur à l'autre - Les environnements de recette ne se manipulent pas à l'identique - Le support technique répond différemment selon le canal utilisé Kinsta d'un côté, WP Engine de l'autre : deux hébergeurs infogérés WordPress parmi les plus reconnus, mais dont le fonctionnement interne diffère suffisamment pour que la migration de l'un vers l'autre ne se limite pas à un simple transfert de fichiers. Ce dossier documente ce qui a réellement changé après la bascule d'un site à trafic soutenu, dans les semaines qui ont suivi. La question n'était pas de savoir lequel des deux hébergeurs est « meilleur » dans l'absolu, mais de comprendre, une fois la décision prise, quelles habitudes opérationnelles allaient devoir être révisées par l'équipe technique en charge du site. ## Le cache : deux philosophies différentes Chez Kinsta, le cache de page repose sur un mécanisme propriétaire directement intégré au niveau du serveur, purgé automatiquement à chaque modification de contenu détectée. Chez WP Engine, le cache s'appuie davantage sur une combinaison de règles Nginx et d'une extension propriétaire installée dans WordPress, avec des options de purge plus granulaires, mais qui demandent une configuration plus explicite pour certains cas particuliers, comme les pages générées dynamiquement par des shortcodes personnalisés. - Purge automatique du cache à la publication d'un article, dans les deux cas - Options de purge ciblée par URL plus détaillées chez WP Engine - Nécessité de revoir les règles d'exclusion de cache pour les pages avec formulaire ## Les environnements de recette, un vrai changement d'habitude Kinsta proposait un unique environnement de préproduction par site, ce qui obligeait l'équipe à choisir entre tester une nouvelle fonctionnalité ou valider un correctif urgent, rarement les deux en parallèle. WP Engine fournit, sur l'offre souscrite, un environnement de développement et un environnement de recette distincts, en plus de la production, ce qui a changé la manière de planifier le travail des développeurs. > L'essentiel à retenir : Le cache objet et le cache de page ne fonctionnent pas de la même façon d'un hébergeur à l'autre ; Les environnements de recette ne se manipulent pas à l'identique ; Le support technique répond différemment selon le canal utilisé ``` # Exemple de structure d'environnements chez WP Engine production -> exemple-site.wpengine.com staging -> exemple-site-staging.wpengine.com dev -> exemple-site-dev.wpengine.com ``` ## La ligne de commande et l'accès SSH Les deux hébergeurs proposent un accès SSH, mais avec des restrictions différentes. WP-CLI est disponible chez les deux, avec toutefois des commandes bloquées ou limitées différemment : par exemple, la modification directe de certains fichiers cœur reste interdite chez les deux hébergeurs, ce qui est cohérent avec leur modèle infogéré, mais les messages d'erreur renvoyés en cas de tentative diffèrent sensiblement, ce qui a demandé une phase d'adaptation pour l'équipe support interne. ## Le support technique, au quotidien Sur ce dossier précis, le support par chat en direct a été utilisé à plusieurs reprises durant les deux premières semaines suivant la migration, principalement pour des questions de configuration de cache et de règles de réécriture. Les délais de réponse observés sont restés comparables entre les deux hébergeurs, avec une différence notable : la documentation technique publique de WP Engine détaille davantage les limitations exactes de l'environnement, ce qui a réduit le nombre de tickets nécessaires une fois l'équipe familiarisée avec ces ressources. > Changer d'hébergeur infogéré ne se résume jamais à comparer une grille tarifaire. Ce sont les détails opérationnels — comportement du cache, structure des environnements, limites de la ligne de commande — qui déterminent si la transition se passe sans accroc pour l'équipe qui travaille sur le site au quotidien. ## Ce qui a dû être réécrit après la bascule Trois éléments ont nécessité une adaptation directe après la migration : - Les règles d'exclusion de cache pour les pages contenant un formulaire de contact dynamique - Le script de déploiement automatisé, qui référençait des chemins spécifiques à l'ancienne infrastructure - La configuration des sauvegardes externes, l'ancien mécanisme n'étant pas directement compatible avec le nouvel environnement ## Ce que retient l'équipe de cette migration Passer d'un hébergeur infogéré à un autre reste, sur le plan technique, une opération maîtrisable, à condition de considérer chaque hébergeur comme un environnement avec ses propres règles internes plutôt que comme un simple espace disque interchangeable. Documenter précisément le fonctionnement du cache et des environnements avant la bascule aurait, sur ce dossier, permis d'éviter une partie des ajustements réalisés dans l'urgence durant la première semaine.