Le bon hébergement WordPress infogéré pour une boutique WooCommerce se choisit d’après la façon dont le fournisseur traite les parties d’une boutique qui ne peuvent pas être mises en cache : le panier, le paiement, les comptes clients et les données de commandes. Comparez les fournisseurs sur les exclusions de cache, le comportement à la limite de capacité, le staging, le périmètre du soutien pour les conflits de plugins, les sauvegardes de commandes avec restaurations testées, la supervision du paiement et la méthode de migration. Une petite boutique au trafic stable et aux plugins courants est habituellement bien servie par un forfait standard d’une plateforme WordPress infogérée. Une boutique qui connaît des pics saisonniers, ou dont le paiement repose sur beaucoup de plugins, a besoin d’un fournisseur qui assume ces éléments par écrit.
En quoi l’hébergement d’une boutique WooCommerce diffère-t-il de celui d’un site de contenu WordPress ?
Un site de contenu envoie la même page à tous les visiteurs non connectés. Un cache de pages peut répondre à la plupart de ces requêtes sans solliciter WordPress. Un réseau de diffusion de contenu (CDN), qui sert des copies stockées depuis des emplacements proches du visiteur, fait de même.
Une boutique WooCommerce cesse de fonctionner ainsi dès qu’un acheteur ajoute un produit au panier. Les pages du panier, du paiement et du compte sont propres à chaque acheteur, et chacune est donc générée de nouveau à chaque requête. Chaque page ainsi générée occupe un processus PHP (PHP worker), le processus serveur qui exécute WordPress pour une requête. Elle lit et écrit aussi dans la base de données. Les visites mensuelles et le stockage en disent peu là-dessus. Le chiffre qui compte est le nombre de requêtes non mises en cache que l’environnement peut servir en même temps.
Une boutique écrit aussi des données toute la journée : commandes, niveaux de stock, fiches clients et renouvellements d’abonnements. La sauvegarde de la nuit dernière ne contient pas les commandes de ce matin.
Quels critères comptent pour comparer des hébergeurs WordPress infogérés pour une boutique WooCommerce ?
Huit critères départagent les hébergeurs WordPress infogérés pour une boutique WooCommerce. La plupart n’apparaissent pas dans un tableau comparatif de forfaits, et cet article ne classe pas les fournisseurs.
| Critère | Pourquoi il compte pour une boutique | Preuve à demander |
|---|---|---|
| Exclusions de cache | Les pages du panier, du paiement et du compte ne doivent jamais venir d’un cache, alors que les pages du catalogue devraient en venir | La liste écrite des exclusions, et la façon dont elle est revalidée après un changement |
| Comportement à la limite de capacité | Les requêtes non mises en cache attendent quand tous les processus PHP sont occupés | La limite de concurrence, ce qui se passe quand elle est atteinte (file d’attente, erreur ou frais de dépassement), et si un test de charge est permis |
| Base de données et cache objet | Le paiement est un travail de base de données, et un cache objet comme Redis garde en mémoire les résultats des requêtes répétées | Si la base de données est partagée, et si un cache objet persistant est inclus |
| Staging et mises en ligne | Une mise à jour de plugin qui casse le paiement est une panne courante | Si le staging reproduit la production, et comment se fait le retour arrière après une mauvaise mise en ligne |
| Périmètre du soutien | Beaucoup de défaillances se situent entre la plateforme et le code | La liste de ce qui est hors périmètre, par écrit |
| Sauvegardes des commandes | Une boutique écrit des données en continu | La fréquence des sauvegardes de la base de données, la restauration à un instant précis, et la date du dernier test de restauration |
| Supervision du paiement | La page d’accueil peut répondre pendant que le paiement échoue | Une vérification scriptée du parcours d’achat, le destinataire de l’alerte et les heures couvertes |
| Méthode de migration | Des commandes arrivent pendant que la boutique est déplacée | Une synchronisation finale des données à la bascule, des tests de paiement en staging et un plan de retour arrière |
La base de connaissances énumère les exigences d’un hébergement WordPress d’entreprise et la façon de vérifier chacune sur un compte d’essai.
Que doit mettre en cache un hébergeur WooCommerce, et que ne doit-il jamais mettre en cache ?
Un hébergeur WooCommerce devrait mettre en cache les pages du catalogue, des catégories et du contenu pour les visiteurs dont le panier est vide. Il ne doit jamais mettre en cache le panier, le paiement, les pages du compte ni aucune réponse qui porte la session d’un acheteur. Une mauvaise règle peut montrer le panier d’un client à un autre client.
Demandez à chaque fournisseur sa liste d’exclusions et la façon dont il teste les règles après un changement de plugin ou de thème. La base de connaissances explique quelles pages WooCommerce mettre en cache et lesquelles ne jamais mettre en cache.
Un hébergement WordPress infogéré suffit-il à une boutique WooCommerce qui connaît des pics saisonniers ?
Un hébergement WordPress infogéré suffit à une boutique qui connaît des pics saisonniers quand les limites du forfait se situent au-dessus du pic et que quelqu’un l’a vérifié avant le solde. Dans un scénario type, une boutique canadienne qui se préparait au Vendredi fou était passée à un forfait WordPress infogéré supérieur deux semaines avant le solde, deux années de suite. Le paiement s’était dégradé les deux fois. La troisième année, le solde est venu après un audit, un redimensionnement de la pile, une réécriture des règles de cache et des tests de charge progressifs. Le scénario type rapporte zéro échec de paiement pendant la période de ce solde.
L’autoscaling pour les pics connus aide quand le niveau applicatif est sans état. Dans la plupart des architectures de petite et moyenne taille, la base de données principale ne se met pas à l’échelle automatiquement, et le paiement s’appuie sur la base de données. Se préparer à un pic coûte aussi de l’argent. Dans le même mandat, la dépense totale d’infrastructure a augmenté d’environ 9 % d’une année à l’autre, pour environ 22 % de marge de capacité supplémentaire en période de pointe. C’est le résultat d’une seule boutique, pas un chiffre typique.
Qui répare un paiement WooCommerce qui casse : l’hébergeur, le développeur ou un fournisseur d’opérations ?
Un paiement qui casse a trois responsables possibles, et la partie coûteuse consiste à trouver lequel. L’hébergeur est responsable des défaillances de sa plateforme. Le développeur ou l’agence est responsable des défauts du code du thème et des plugins. Entre les deux se trouve le diagnostic : une requête lente, une passerelle de paiement qui répond en retard, un bassin de processus PHP saturé ou un conflit entre deux plugins. La base de connaissances montre comment trouver l’étape lente d’un paiement WooCommerce.
Beaucoup de plateformes WordPress infogérées placent ce diagnostic hors du périmètre de leur soutien. Dans un scénario type, un éditeur doté d’un programme d’adhésion WooCommerce qui a quitté WP Engine s’était fait répondre que le diagnostic des conflits de plugins était hors du périmètre du soutien infogéré. Le même scénario type écrit que WP Engine « est un vrai produit » et présente cette limite comme un élément de la conception d’une plateforme mutualisée. La comparaison entre l’hébergement WordPress infogéré et les opérations WordPress infogérées précise qui est responsable de quoi.
Quel type de fournisseur convient à quelle boutique WooCommerce ?
Trois types de fournisseurs font tourner des boutiques WooCommerce, et chacun convient à une boutique différente.
| Type de fournisseur | Ce qu’il gère | Convient à une boutique quand | Point faible pour une boutique |
|---|---|---|---|
| Plateforme WordPress infogérée, comme WP Engine ou Kinsta | Les serveurs, le cache, les sauvegardes et le soutien de la plateforme | Le trafic est stable, les plugins sont courants et un développeur s’occupe des mises à jour | Les limites du forfait en période de pointe, un accès restreint au serveur, et un diagnostic des conflits de plugins souvent hors du périmètre du soutien |
| Serveur cloud opéré par un pigiste ou une agence | Ce que cette personne met en place | La boutique a besoin d’une pile sur mesure, et la personne est compétente et joignable | Une seule personne couvre les nuits, les congés et les absences pour maladie |
| Fournisseur d’opérations infogérées, sur son propre hébergement ou sur le vôtre | Le dimensionnement, la supervision, le soutien aux mises en ligne et la réponse aux incidents, selon un périmètre écrit | La boutique connaît des pics ou son paiement repose sur beaucoup de plugins, et elle n’a pas d’équipe d’opérations | Il coûte plus cher qu’un forfait, commence par un appel de cadrage et ne corrige pas votre code |
Une équipe qui ne veut opérer aucun logiciel a une quatrième option, une plateforme de commerce électronique hébergée. La base de connaissances propose un guide pour choisir entre WooCommerce et Shopify.
Quels facteurs déterminent le coût d’un hébergement WordPress infogéré pour une boutique WooCommerce ?
Le coût d’hébergement d’une boutique WooCommerce dépend du modèle de tarification autant que de la taille de la boutique. Une plateforme WordPress infogérée fixe habituellement ses prix à partir d’une grille de forfaits publique, selon des mesures comme les visites, la bande passante, le stockage et le nombre de sites. Une boutique peut dépasser un forfait sur la concurrence avant de le dépasser sur le nombre de visites. Pour mesurer votre exposition, comparez douze mois de factures au prix du forfait.
Les opérations infogérées prennent habituellement la forme d’un mandat mensuel cadré selon l’environnement. Les facteurs sont le trafic et la charge concurrente, la cible de disponibilité et la fenêtre de soutien, et le nombre de sites et d’environnements. S’y ajoutent la cadence de mises en ligne, la complexité de la migration et les besoins de conformité ou de résidence des données.
La préparation d’un pic est un coût distinct : tests de charge, capacité temporaire et temps de vos développeurs. Comparez-le à ce que vous coûte, selon vos propres chiffres, une heure de paiement en échec en période de pointe. Un article distinct explique comment est tarifé l’hébergement cloud infogéré.
Que faut-il vérifier avant de déplacer une boutique WooCommerce chez un nouvel hébergeur ?
Avant de déplacer une boutique WooCommerce, vérifiez comment la migration protège les commandes passées pendant que le déplacement est en cours. L’ancienne boutique continue de prendre des commandes entre la première copie et la bascule.
Un plan de migration solide comprend une copie de staging que vous pouvez valider. Il prévoit aussi une synchronisation finale des commandes, des clients et des abonnements à la bascule. Les passerelles de paiement et la facturation récurrente sont testées en staging. Un plan de retour arrière écrit garde l’ancien environnement disponible jusqu’à ce que le nouveau fonctionne correctement. La base de connaissances couvre l’audit préalable à une migration WooCommerce. Pour les données de commandes après le déplacement, consultez la stratégie de sauvegarde WooCommerce bâtie autour des exercices de restauration.
Une migration est parfois le mauvais remède. Une mauvaise règle de cache, une requête lente ou un processus de mise en ligne sans responsable suivent la boutique chez le nouvel hébergeur.
Comment les données de carte et la résidence des données au Canada influencent-elles le choix d’un hébergeur ?
Beaucoup de boutiques WooCommerce confient la saisie de la carte à un processeur de paiement comme Stripe ou PayPal. Dans ces intégrations, les numéros de carte restent hors du serveur de la boutique. Cela réduit les obligations de la boutique selon la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS), sans les supprimer. Votre banque acquéreuse ou votre évaluateur de sécurité qualifié (QSA) décide quelles exigences s’appliquent. Si votre évaluateur exige un hébergeur qui détient sa propre attestation PCI DSS, appliquez ce critère en premier, parce qu’il élimine beaucoup de fournisseurs.
Si les fiches clients doivent rester au Canada, demandez où se trouvent l’environnement principal, l’environnement de secours et les sauvegardes. Demandez cet emplacement par écrit. L’article sur ce qu’il faut exiger d’un hébergeur pour la résidence des données au Canada énumère les questions.
Quand un forfait WordPress infogéré standard est-il le bon choix pour une boutique WooCommerce ?
Un forfait WordPress infogéré standard est le bon choix pour une boutique WooCommerce quand ces conditions sont réunies :
- Le catalogue est de taille petite ou moyenne, et les plugins sont courants et bien entretenus.
- Le trafic est stable, et la journée la plus achalandée ne dépasse pas de beaucoup une journée ordinaire.
- Un développeur ou une agence s’occupe des mises à jour et répond quand quelque chose casse.
- La boutique n’a besoin d’aucun accès au serveur ni d’aucun service sur mesure.
- Une heure de paiement en échec est un désagrément, pas une perte importante.
Si les cinq conditions sont vraies, une entente plus large est une dépense superflue.
Quand un forfait WordPress infogéré standard ne suffit-il plus à une boutique WooCommerce ?
Un forfait WordPress infogéré standard ne suffit plus à une boutique WooCommerce quand plusieurs de ces signes apparaissent :
- Le paiement a ralenti ou échoué pendant un solde, et un forfait supérieur n’a pas empêché que cela se reproduise.
- Le soutien a répondu plus d’une fois qu’un diagnostic est hors périmètre.
- Les mises à jour de plugins partent directement en production, parce que le staging ne lui ressemble pas.
- Personne ne peut dire quand une base de données de commandes a été restaurée pour la dernière fois à titre de test.
- Les clients signalent des problèmes de paiement avant que l’équipe en soit informée.
Ce sont surtout des vides de responsabilité. Un autre hébergeur les règle seulement si le périmètre écrit du nouveau fournisseur les couvre.
Comment utiliser ces critères lors d’un appel avec un fournisseur d’hébergement WooCommerce ?
Utilisez les critères comme un questionnaire écrit, et comparez les réponses plutôt que les tableaux de forfaits.
- Envoyez la troisième colonne du tableau des critères à chaque fournisseur et demandez des réponses écrites.
- Placez en tête le comportement à la limite de capacité, le diagnostic des conflits de plugins et le dernier test de restauration, parce que ces réponses varient le plus d’un fournisseur à l’autre.
- Demandez ce que l’accord de niveau de service (SLA) couvre et exclut. Un SLA d’hébergement couvre normalement le réseau et les serveurs, et non l’application WooCommerce.
- Notez pour chaque réponse si l’élément relève du fournisseur, de vous ou de personne.
- Choisissez le fournisseur qui laisse le moins d’éléments sans responsable, compte tenu des revenus en jeu.
Le guide sur quoi rechercher chez un fournisseur d’hébergement infogéré ajoute des critères qui s’appliquent au-delà de WordPress.
Où se situe Stack Harbor
Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) pour les environnements de production, de propriété canadienne, dont le siège est à Montréal. L’entreprise sert des PME et des agences qui opèrent des systèmes de production sans avoir leur propre équipe d’opérations 24/7. Ses mandats WordPress Entreprise couvrent les boutiques WooCommerce. Le périmètre publié nomme la performance du panier, la fiabilité du paiement, l’optimisation du tunnel d’achat, les événements de trafic et la stratégie de cache que WooCommerce demande. Les mandats sont cadrés à partir d’une liste qui comprend le staging, la stratégie de cache, le dimensionnement de la base de données et de Redis, les sauvegardes avec restaurations testées et l’accompagnement des releases. Le service Gestion, supervision et soutien mentionne la supervision synthétique des flux de paiement parmi ses vérifications.
Un changement d’hébergement n’est pas requis quand l’hébergeur actuel tient la route. Quand un déplacement est nécessaire, les services de migration commencent par une découverte, un mandat de cadrage court et payant. Ils comprennent une synchronisation delta finale des commandes à la bascule. Stack Harbor peut héberger WordPress dans ses deux centres de données de Montréal.
Stack Harbor ne remplace pas vos développeurs, et les défauts de code restent du travail de développement. Le travail quotidien passe par le bureau de soutien, et les ingénieurs seniors sont responsables des incidents de gravité 1 (Sev-1). Dans le SLA de Stack Harbor, l’entreprise s’engage à une disponibilité mensuelle de 99,9 % pour son propre réseau et son infrastructure, avec un crédit de service comme seul et unique recours. Cet engagement ne couvre pas l’application WooCommerce. Stack Harbor ne détient aucune certification PCI DSS. La décision de portée appartient à votre évaluateur, et Stack Harbor bâtit selon les contrôles qu’il spécifie, comme l’explique la page Confiance et sécurité. Stack Harbor ne publie ni grille de forfaits ni prix : chaque mandat est cadré selon des facteurs et fait l’objet d’un devis fixe après un appel de découverte.
Un achat guidé par le prix, une inscription en libre-service ou une petite boutique qui tourne bien sur son forfait actuel ont leur place auprès d’une plateforme WordPress infogérée. Si votre boutique présente les signes qu’un forfait standard ne suffit plus, décrivez votre environnement WooCommerce à Stack Harbor.
