L’hébergement WordPress infogéré est un produit : une plateforme qui fait tourner les serveurs sous votre site. Les opérations WordPress infogérées sont un service : une équipe qui prend la responsabilité du fonctionnement de votre propre site en production. Tout site a besoin d’un hébergement. Un site a besoin d’opérations quand des revenus, des leads ou une activité d’édition en dépendent et que personne n’est aujourd’hui responsable des mises en ligne, de la supervision, des restaurations et des incidents.
Avant de changer d’hébergeur, vérifiez lequel des deux vous manque. Un vide de responsabilité suit le site chez le prochain hébergeur.
Quelle est la différence entre l’hébergement WordPress infogéré et les opérations WordPress infogérées ?
L’hébergement WordPress infogéré est une plateforme d’hébergement conçue pour WordPress. Le fournisseur applique les correctifs aux serveurs, gère le cache et les sauvegardes au niveau de la plateforme, et répond aux questions sur la plateforme. WP Engine, Kinsta et des entreprises semblables vendent ce produit. Les forfaits se choisissent habituellement dans une grille publique. Ils sont dimensionnés selon des mesures comme les visites, la bande passante, le stockage ou le nombre de sites.
Les opérations WordPress infogérées, souvent appelées infogérance WordPress, sont un travail continu sur l’environnement d’un seul client. Elles couvrent une supervision qu’une personne lit et une réponse aux incidents avec une escalade définie. Elles couvrent aussi une cadence de mises à jour planifiée avec un retour arrière testé, des sauvegardes avec tests de restauration, le travail de performance et le soutien aux mises en ligne. L’environnement peut se trouver chez presque n’importe quel hébergeur, y compris une plateforme WordPress infogérée, un compte cloud ou des serveurs dédiés.
Les deux offres utilisent le mot « infogéré ». Demandez donc ce qui est infogéré au juste. Une plateforme gère ses propres serveurs pour un grand nombre de clients à la fois. Un fournisseur d’opérations gère la vie en production d’un seul site. L’article de la base de connaissances sur l’infogérance WordPress comparée au serveur auto-géré détaille ce qu’une plateforme retire de votre charge de travail et ce qu’elle ne retire jamais.
| Responsabilité | Plateforme WordPress infogérée | Fournisseur d’opérations infogérées | Vos développeurs ou votre agence |
|---|---|---|---|
| Serveurs, système d’exploitation et environnement d’exécution PHP sur lequel tourne WordPress | Responsable | Responsable quand il héberge aussi, sinon travaille dans les limites de l’hébergeur | Non |
| Supervision des pages clés de votre site et du paiement | Santé de la plateforme, parfois une vérification de disponibilité de base | Responsable | Parfois, de façon informelle |
| Mises à jour des plugins et du cœur de WordPress, avec staging et retour arrière | Outils fournis, les décisions de mise en ligne vous reviennent | Responsable de la cadence et du retour arrière | Testent les fonctionnalités |
| Diagnostic d’un conflit de plugins ou d’une requête lente | Souvent hors périmètre | Responsable du diagnostic | Responsables de la correction du code |
| Réponse aux incidents en dehors des heures de bureau | Soutien de la plateforme pour les problèmes de la plateforme | Responsable, sur les forfaits qui l’incluent | Au mieux de leurs disponibilités |
| Développement du thème, des plugins et des fonctionnalités | Non | Non | Responsables |
Comment savoir si mon problème relève de l’hébergement ou des opérations ?
Posez une seule question devant chaque symptôme : un serveur plus gros ou différent le ferait-il disparaître ? Si la réponse est oui, c’est un problème d’hébergement. Si la réponse est non, le problème vous suivra chez le prochain hébergeur.
La page où Stack Harbor explique comment elle cadre et chiffre ses mandats distingue trois couches de travail. La première est la facturation et l’administration de compte, peu coûteuse et souvent prise pour de la gestion. La deuxième est l’exploitation de l’infrastructure : durcissement, correctifs, sauvegardes, surveillance, garde et intervention sur incident. La troisième est l’exploitation applicative, qui comprend le déploiement du code, et les défauts de ce code relèvent du génie logiciel. Quatre des sept symptômes ci-dessous appartiennent à la deuxième couche. Un forfait d’hébergement ne couvre que la part de cette couche qui concerne la plateforme.
| Symptôme | Où se situe le problème | Qui le règle normalement |
|---|---|---|
| Les limites de ressources du forfait sont atteintes avec un trafic ordinaire | Hébergement | L’hébergeur, par un forfait plus gros ou une architecture différente |
| La facture change d’un trimestre à l’autre à cause des frais de dépassement | Hébergement, modèle commercial | Un changement de forfait ou un hébergeur dont les prix sont structurés autrement |
| Une mise à jour de plugin a cassé le paiement en production | Opérations, processus de mise en ligne | La personne responsable du staging, de la cadence des mises à jour et du retour arrière |
| Le soutien répond que le diagnostic est hors périmètre | Opérations | Un fournisseur d’opérations ou un développeur senior |
| Vos clients ont signalé la panne avant que vous en soyez informé | Opérations, supervision et garde | La personne responsable de la supervision et de la garde |
| Les sauvegardes existent, et personne n’en a jamais restauré une | Opérations | La personne responsable des tests de restauration |
| Un thème sur mesure génère des erreurs | Application | Vos développeurs |
Dans le cadre d’un mandat, une agence torontoise a consolidé 14 sites clients, et le compte rendu conclut que « l’hébergeur est rarement le vrai problème ».
Quand une plateforme WordPress infogérée suffit-elle ?
Une plateforme WordPress infogérée, sans rien autour, est souvent le bon achat. Restez sur la plateforme, et n’ajoutez rien, quand ces conditions sont réunies :
- Le site correspond à la conception de la plateforme. Il utilise des plugins courants, n’a besoin d’aucun accès au serveur et ne fait tourner aucun service sur mesure.
- Le trafic est prévisible, donc le forfait le couvre et le coût annuel peut être prévu.
- Un développeur ou une agence réactive est responsable des conflits de plugins, des mises à jour et des mises en ligne, et répond quand un problème survient.
- Votre public est éveillé en même temps que votre équipe, donc une panne de nuit coûte peu.
- Une heure de panne est un désagrément, pas une perte mesurable de ventes, de leads ou de revenus publicitaires.
Si les cinq conditions sont vraies, un contrat d’opérations infogérées est une dépense superflue.
Quand une plateforme WordPress infogérée cesse-t-elle de convenir ?
Une plateforme WordPress infogérée cesse de convenir de deux façons, et les remèdes ne sont pas les mêmes.
La première est une limite de conception. Les plateformes mutualisées restreignent l’accès au serveur, limitent certains plugins et fixent leurs prix par paliers d’utilisation. Ce sont des choix raisonnables pour un produit qui sert beaucoup de clients à la fois. Ils deviennent un problème quand votre site a besoin d’une pile sur mesure, ou quand les frais de dépassement rendent la facture impossible à prévoir. Aucun billet de soutien ne change la conception d’un produit. C’est un problème d’hébergement, et changer d’hébergeur est une réponse légitime.
La deuxième est un vide de responsabilité. La plateforme fonctionne, et le site tombe quand même en panne. Les mises à jour partent directement en production et personne ne surveille le paiement. Le soutien répond qu’un conflit de plugins sort du périmètre du soutien infogéré. La plateforme fait ce qu’elle vend, et la pièce manquante est une fonction d’opérations. C’est ici que l’hébergement et le soutien WordPress d’entreprise se distinguent d’un forfait infogéré : quelqu’un est responsable du résultat pour ce site en particulier. Un article connexe sur l’hébergement WordPress critique explique ce dont un fournisseur doit être responsable au-delà du serveur.
Dans le cadre d’un autre mandat, un éditeur canadien a quitté WP Engine après une proposition de renouvellement supérieure de 22 % à celle de l’année précédente. Les diagnostics de conflits de plugins lui revenaient aussi avec la mention hors périmètre. Le scénario type indique que WP Engine « est un vrai produit » qui a mérité la confiance de l’éditeur pendant les trois premières années. Elle ajoute que ces limites tiennent à la conception d’un produit mutualisé. Après la migration, le coût tout compris était inférieur de 34 % à ce qu’aurait été le renouvellement. La base de comparaison est le renouvellement proposé, et ce chiffre appartient à ce seul mandat.
Faut-il rester, ajouter une couche d’opérations ou migrer ?
Un acheteur installé sur une plateforme WordPress infogérée a trois issues viables, en plus de la voie de l’embauche à l’interne. Le scénario type de Stack Harbor sur l’éditeur qui a quitté WP Engine le dit : la réponse à un renouvellement difficile n’est pas de migrer en panique en trois semaines.
| Option | Choisissez-la quand | Évitez-la quand |
|---|---|---|
| Rester sur la plateforme telle quelle | Le site correspond à la plateforme, le coût est prévisible et un développeur ou une agence est responsable des mises en ligne et des incidents | Des incidents restent sans responsable, ou la même réponse « hors périmètre » revient sans cesse |
| Rester et ajouter une couche d’opérations | L’hébergeur tient la route, et le point sensible concerne les mises à jour, la supervision, les restaurations, la performance ou la réponse aux incidents | La plateforme bloque les accès dont le travail a besoin. Demandez cette limite par écrit |
| Migrer vers un autre hébergeur | La limite tient à la conception de la plateforme : accès, pile sur mesure ou frais de dépassement | Le vrai manque est un vide de responsabilité, parce qu’il réapparaîtra chez le nouvel hébergeur |
| Embaucher à l’interne | Les opérations WordPress occuperaient un poste à temps plein et vous voulez garder ce savoir dans l’équipe | Une seule personne devrait couvrir à elle seule les nuits, les congés et les absences pour maladie |
Une migration comporte ses propres risques. Recherchez un audit écrit avant que quoi que ce soit bouge, un environnement parallèle et une bascule répétée à l’avance. Vérifiez aussi que le plan de retour arrière existe avant la journée de bascule. La base de connaissances explique ce que doit contenir un runbook de retour arrière de migration. Migrer n’est pas toujours le remède. Dans un troisième mandat, les Core Web Vitals d’un éditeur national ont été rebâtis sur place, chez le même hébergeur tiers et au même palier d’hébergement, avec un coût d’hébergement stable. Les Core Web Vitals sont les indicateurs de Google qui mesurent la vitesse et la stabilité des pages.
Combien coûte chaque option ?
Le prix de chaque option ne se calcule pas de la même manière. Comparez donc les facteurs de coût, pas les factures.
Une plateforme WordPress infogérée est tarifée à partir d’une grille de forfaits publique. Les facteurs sont les visites, la bande passante, le stockage, le nombre de sites et les options ajoutées. Le coût est prévisible tant que le trafic ne dépasse pas le forfait. Pour mesurer votre propre exposition, prenez douze mois de factures. Comparez ensuite le prix du forfait avec ce que vous avez payé en frais de dépassement et en changements de palier.
Les opérations infogérées prennent habituellement la forme d’un mandat mensuel cadré selon l’environnement. Les facteurs sont la fenêtre de couverture du soutien, la cible de réponse, le nombre de sites et d’environnements, le trafic et la charge concurrente. S’y ajoutent la cadence de mises en ligne, le nombre de développeurs qui livrent des changements et les besoins de conformité ou de résidence des données. La couverture est le facteur que les acheteurs sous-estiment. Un site dont les clients dorment en même temps que vous n’a peut-être pas besoin d’une réponse 24/7. Un article distinct présente les facteurs derrière le devis d’un hébergement cloud infogéré.
Une migration est un projet ponctuel. Les facteurs sont le nombre de sites, le volume de données, la complexité des dépendances, la tolérance à l’indisponibilité et la fenêtre de soutien après le lancement. Prévoyez au budget deux environnements qui tournent côte à côte pendant la migration. Prévoyez aussi le temps de vos développeurs pour tester le nouvel environnement.
Une embauche à l’interne coûte un salaire et du temps de gestion. Une personne seule ne peut pas couvrir les nuits, les congés et les absences pour maladie. L’article sur le choix entre embaucher un ingénieur DevOps ou impartir les opérations examine ce compromis en détail.
Ne rien faire a aussi un coût. Estimez-le à partir de vos propres chiffres : les revenus ou les leads par heure en période de pointe, multipliés par la durée en heures de vos deux derniers incidents.
Quelles questions poser avant de signer avec une plateforme ou un fournisseur d’opérations ?
Apportez ces questions à l’appel avec le fournisseur. La base de connaissances énumère les exigences d’un hébergement WordPress d’entreprise et la façon de vérifier chacune.
- Où votre périmètre s’arrête-t-il exactement ? Demandez la liste de ce qui est hors périmètre par écrit.
- Qui diagnostique un conflit entre deux plugins, et qui le corrige ?
- Quels niveaux de gravité existent, quel est le délai de réponse confirmée pour chacun, et pendant quelles heures ?
- Le délai de réponse annoncé est-il un engagement ou une cible, et que se passe-t-il quand il n’est pas respecté ?
- Qui applique les mises à jour des plugins et du cœur de WordPress, à quelle cadence, et comment annule-t-on une mauvaise mise à jour ?
- Quand la sauvegarde d’un site client a-t-elle été restaurée pour la dernière fois à titre de test, et pouvons-nous voir le registre ?
- Quels accès obtenons-nous, et de quels accès avez-vous besoin de notre part ou de la part de notre hébergeur ?
- Qu’est-ce qui fait changer le prix, et que se passe-t-il quand le trafic dépasse le forfait ou le périmètre ?
- Que conservons-nous si nous partons : runbooks, schémas, configuration, sauvegardes ?
L’article de la base de connaissances sur les clauses qui décident si le soutien WordPress d’entreprise fonctionne passe en revue le langage contractuel derrière les questions 1 à 4.
Quand un fournisseur d’opérations infogérées est-il le mauvais choix ?
Un fournisseur d’opérations infogérées est le mauvais achat dans les situations suivantes, et chacune a une meilleure solution de rechange.
- Vous voulez un hébergement en libre-service avec des prix affichés dans une grille de forfaits. Une plateforme WordPress infogérée répond bien à ce besoin.
- Vous voulez que quelqu’un corrige les défauts de votre thème ou de vos plugins, ou remplace vos développeurs. C’est du travail de développement, et une agence ou une embauche est la bonne réponse.
- Votre agence est déjà responsable des mises à jour, de la supervision et des incidents, et elle répond quand ça compte.
- Le travail d’opérations occuperait un poste à temps plein dans votre entreprise. Embauchez la personne.
- Vous avez besoin de TI de bureau, de soutien aux postes de travail ou d’un centre d’assistance pour les utilisateurs. C’est une autre catégorie de fournisseur.
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 d’environ 5 à 200 personnes qui opèrent des systèmes de production sans avoir leur propre équipe d’opérations 24/7.
Ses mandats WordPress Entreprise sont cadrés à partir d’une liste qui couvre l’architecture, les opérations, la migration et le soutien, et le client ne paie pas pour chaque élément. Un changement d’hébergement n’est pas nécessaire : si l’hébergeur actuel tient la route, Stack Harbor peut opérer l’environnement autour. Le service Gestion, supervision et soutien opère et supervise des environnements sur AWS, Azure, Google Cloud, OVH, DigitalOcean et des serveurs dédiés, ainsi que sur l’infrastructure de Stack Harbor. Quand l’hébergeur est la contrainte, les services de migration commencent par une découverte, un mandat de cadrage court et payant qui produit un plan écrit et un devis fixe. Stack Harbor peut héberger WordPress dans ses deux centres de données de Montréal quand la résidence des données ou la latence comptent.
Stack Harbor ne remplace ni les développeurs ni une agence. Le travail quotidien passe par le bureau de soutien, et les ingénieurs seniors sont responsables des incidents de gravité 1 (Sev-1). Sur les forfaits qui incluent la couverture des incidents, l’accord de niveau de service (SLA) prévoit un engagement de réponse confirmée en moins de 15 minutes pour les Sev-1, et la résolution est une cible. Stack Harbor ne publie aucun prix : chaque mandat reçoit un devis fixe pour un périmètre écrit, après une évaluation.
Si le tableau de diagnostic a placé la plupart de vos symptômes dans la colonne des opérations, décrivez votre environnement WordPress à Stack Harbor. Si la plupart se trouvaient dans la colonne de l’hébergement et que votre site correspond à la conception d’une plateforme, une plateforme WordPress infogérée et un développeur réactif restent le bon achat.
