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.
# Exemple de structure d'environnements chez WP Engine
production -> exemple-site.wpengine.com
staging -> exemple-site-staging.wpengine.com
dev -> exemple-site-dev.wpengine.comLa 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.
