Hébergement pour agences avec plusieurs sites WordPress : modèles, marges et risques

Une agence qui gère plusieurs sites WordPress peut les héberger de quatre façons. Elle peut prendre un forfait agence sur une plateforme WordPress infogérée, avoir son propre compte revendeur ou serveur cPanel, bâtir elle-même des serveurs cloud, ou faire opérer ses hébergeurs actuels par un partenaire d’infrastructure en marque blanche. Le bon choix dépend de trois choses plus que de l’hébergeur : qui assure la garde, qui parle au client et ce qu’il advient de la marge de l’agence. Un petit portefeuille de sites vitrines semblables a généralement sa place sur un forfait agence de plateforme. Un portefeuille qui a fait d’un développeur senior l’administrateur système par défaut a besoin d’un modèle de soutien, et un nouvel hébergeur ne le fournira pas à lui seul.

Quels sont les modèles d’hébergement pour une agence qui a plusieurs sites WordPress ?

Un forfait agence sur une plateforme WordPress infogérée. Les plateformes d’hébergement WordPress infogéré comme WP Engine et Kinsta vendent des forfaits conçus pour les agences. Avec ce type de forfait, la plateforme exploite les serveurs, la couche de cache et les sauvegardes au niveau de la plateforme. L’agence dispose habituellement d’un seul tableau de bord et n’a aucun accès root. Le soutien de la plateforme couvre la plateforme. Le travail propre à un site reste généralement à l’agence : un conflit de plugins, une release ratée ou la conversation avec le client.

Un compte revendeur ou le serveur cPanel de l’agence. L’hébergement revendeur est un compte sur le serveur d’un hébergeur qui permet à l’agence de créer et de facturer des comptes clients distincts. Un serveur entier sous cPanel et WHM (WebHost Manager, la couche d’administration de cPanel) donne à l’agence les mêmes outils avec un contrôle complet. Les deux formules laissent une marge d’hébergement à l’agence. Sur un serveur entier, l’agence devient aussi l’administrateur système, responsable des correctifs, du courriel, du nettoyage des maliciels et des restaurations. La base de connaissances explique quand un compte revendeur suffit et quand il faut un serveur entier, et ce que suppose un modèle d’affaires en marque blanche sur cPanel.

Des serveurs cloud que l’agence bâtit et exploite. L’agence loue un VPS (serveur privé virtuel) ou un compte chez un fournisseur de cloud public comme AWS (Amazon Web Services) et conçoit la pile elle-même. Le contrôle est complet, et la responsabilité de tout ce qui se trouve au-dessus de la machine virtuelle l’est aussi. La base de connaissances décrit comment les agences opèrent des comptes AWS clients sans équipe infonuagique.

Un partenaire d’infrastructure en marque blanche. Un partenaire d’exploitation opère la couche d’hébergement derrière la marque de l’agence : supervision, correctifs, sauvegardes, garde et réponse aux incidents. En marque blanche, le client voit le nom de l’agence pendant qu’une autre entreprise fait le travail. Les sites peuvent rester chez leurs hébergeurs actuels. L’agence garde la relation client, le travail de développement et le plan d’entretien. Un plan d’entretien est le mandat mensuel de maintenance qu’une agence vend à ses clients.

WordPress multisite est parfois proposé comme cinquième option. Le mode multisite fait tourner plusieurs sites à partir d’une seule base de code et d’une seule base de données, ce qui supprime la séparation entre eux. Il convient rarement à des clients sans lien entre eux, qui s’attendent à avoir leurs propres données et leur ensemble de plugins, et à pouvoir partir sans complications. La base de connaissances traite de l’exploitation d’un multisite WordPress en production.

Comment se comparent les quatre modèles d’hébergement pour agences ?

Les quatre modèles d’hébergement pour agences se distinguent surtout par qui assure la garde, qui parle au client et d’où vient la marge de l’agence.

Qui assure la garde quand le site d’un client tombe ?

Assurer la garde, c’est être la personne qui reçoit l’alerte, et dont on attend une action, quand un site tombe en dehors des heures de bureau. Avec un forfait de plateforme, un compte revendeur, un serveur opéré par l’agence ou un cloud bâti à l’interne, l’agence assure la garde pour tout ce qui est propre à un site. Une plateforme ou un hébergeur revendeur corrige ses propres pannes. En général, ni l’un ni l’autre ne cherche pourquoi le passage en caisse d’un client a cessé de fonctionner après une mise à jour.

Dans beaucoup d’agences, la garde est un arrangement non écrit : le cellulaire d’un fondateur ou d’un développeur principal. Une agence peut mettre son arrangement à l’épreuve en écrivant quatre réponses pour une panne un samedi soir :

1. Qui est alerté, et par quel système, avant que le client s’en aperçoive.
2. En combien de temps cette personne doit confirmer qu’elle a reçu l’alerte.
3. Si cette personne a les accès nécessaires pour agir.
4. S’il existe un runbook. Un runbook est une procédure écrite pour une défaillance connue sur un environnement précis.

Si les clients d’une agence ne vendent pas et ne publient pas la nuit, une couverture aux heures de bureau peut être la réponse honnête, à condition que le plan d’entretien le dise. Un autre article du blogue compare les deux façons d’obtenir une rotation de garde : embaucher un ingénieur DevOps ou impartir les opérations.

Que devient la marge de l’agence selon le modèle d’hébergement ?

Une agence tire deux marges différentes de l’hébergement. La première est la marge de revente, soit l’écart entre ce que l’hébergeur facture et ce que le client paie. La deuxième est la marge du plan d’entretien, soit l’écart entre le mandat mensuel et les heures que l’agence consacre à garder le site en santé. Seule la première figure sur une facture.

Une agence peut mesurer le coût caché en un mois. Elle consigne chaque interruption liée à l’hébergement : billets, renouvellements, restaurations, clavardages avec le soutien de l’hébergeur et alertes hors des heures de bureau. Elle multiplie les heures par la valeur facturable de la personne qui s’en est occupée. Elle compare ensuite ce chiffre à la marge d’hébergement du même mois.

Le coût de n’importe quel modèle varie selon les mêmes facteurs. Ces facteurs sont le nombre de sites clients et leur degré de différence, le trafic et le stockage, et l’isolation dont chaque site a besoin. S’y ajoutent la fenêtre de couverture, la rétention des sauvegardes et les tests de restauration, les licences et le volume de migration.

Les honoraires d’un partenaire en marque blanche sont un coût réel, donc la marge passe de la revente au plan d’entretien. Le modèle est rentable quand les heures senior récupérées sont vendues en travail de projet, ou quand le prix des plans d’entretien est révisé pour refléter un travail d’exploitation documenté. Aucun modèle ne promet ce résultat. Dans un scénario type, une agence de 22 personnes avec 14 sites WordPress a consolidé cinq plans d’entretien et les a revalorisés avec une hausse moyenne de 12 %, et tous les clients ont renouvelé. Cette hausse correspond aux prix que l’agence demande à ses propres clients. Elle ne représente ni des honoraires de Stack Harbor ni un résultat typique. Pour la structure derrière les devis des fournisseurs, consultez l’article sur la façon dont l’hébergement cloud infogéré est tarifé.

Quels sont les risques d’héberger soi-même de nombreux sites clients ?

Les risques d’un hébergement opéré par l’agence viennent de l’exploitation, et non du choix du serveur.

• Rayon d’impact. Le rayon d’impact décrit jusqu’où un site compromis ou surchargé peut nuire à ses voisins. Les sites placés dans un même compte d’hébergement partagent un utilisateur, un quota et une sauvegarde. La base de connaissances compare un compte cPanel par site et plusieurs sites dans un même compte.
• Discipline de mise à jour. Une seule mauvaise version d’un plugin peut briser plusieurs sites clients le même après-midi. La base de connaissances décrit comment gérer les mises à jour WordPress sur un parc de sites.
• Des sauvegardes que personne n’a restaurées. Une sauvegarde n’est prouvée que par un test de restauration.
• Un savoir dans une seule tête. Quand le développeur qui a monté le serveur s’en va, l’agence hérite d’un système non documenté.
• Les promesses du plan d’entretien. Les clients tiennent l’agence responsable, peu importe ce que disent les conditions de l’hébergeur.

Quand une agence devrait-elle choisir chaque modèle, et quand l’éviter ?

Forfait agence de plateforme

Choisissez un forfait agence de plateforme quand les sites se ressemblent, qu’aucun n’a besoin de réglages serveur sur mesure et que personne dans l’équipe ne veut d’accès au serveur. Évitez-le quand plusieurs clients ont besoin de plugins ou de configurations que la plateforme n’autorise pas, ou quand les clients s’attendent à ce que l’agence réponde la nuit.

Compte revendeur ou serveur cPanel de l’agence

Choisissez un compte revendeur ou un serveur cPanel quand l’hébergement est une gamme de produits voulue, avec ses propres prix, et que l’agence peut affecter du personnel aux correctifs, au courriel et à la réponse aux abus. Évitez ce modèle quand l’administrateur système est aussi le meilleur développeur de l’agence.

Cloud bâti à l’interne

Choisissez un cloud bâti à l’interne quand l’agence emploie des gens qui ont une vraie expérience d’exploitation et que ses clients ont besoin d’architectures qu’un panneau de contrôle ne permet pas de mettre en place. Évitez-le quand la seule motivation est une facture de serveur plus basse, parce que les heures du personnel coûtent souvent plus cher que l’économie réalisée.

Partenaire d’infrastructure en marque blanche

Choisissez un partenaire d’infrastructure en marque blanche quand des revenus ou une réputation reposent sur les sites clients, que le portefeuille est réparti entre plusieurs hébergeurs et que les développeurs seniors perdent du temps de projet à traiter des billets. Évitez un partenaire quand le portefeuille se résume à quelques sites à faible risque, parce qu’un forfait de plateforme suffit généralement et n’ajoute pas de deuxième fournisseur. Évitez-le aussi quand le modèle d’affaires repose sur une marge de revendeur tirée d’une grille de prix publique, ou quand l’équipe tient à assurer elle-même l’exploitation. Un partenaire opère l’infrastructure et ne bâtit ni ne répare les sites des clients.

Déplacer tous les sites clients chez un meilleur hébergeur règle-t-il le problème ?

Déplacer tous les sites clients chez un meilleur hébergeur laisse souvent le problème en place, parce que le problème est habituellement l’absence de modèle de soutien. Une scénario type sur la consolidation d’un portefeuille d’agence le dit directement : « l’hébergeur est rarement le vrai problème ».

Dans ce mandat, l’agence exploitait quatorze sites chez quatre hébergeurs, et la consolidation a pris dix semaines. L’indisponibilité moyenne mesurée en périphérie a été de 22 minutes par site, contre une fenêtre de quatre heures communiquée à chaque client. Les billets de soutien entrants des clients avaient baissé de 68 % à 90 jours. Ces chiffres décrivent un seul portefeuille et ne constituent pas une promesse pour un autre.

Décidez d’abord qui est responsable du soutien, puis consolidez seulement là où un déplacement réduit les coûts ou le risque. Un autre article explique la différence entre acheter des serveurs et acheter de l’exploitation : hébergement WordPress infogéré ou opérations WordPress infogérées.

Que devrait demander une agence avant de choisir un modèle d’hébergement ou un fournisseur ?

Posez ces questions lors d’une revue interne ou d’un appel avec un fournisseur.

1. Quels sites feraient perdre de l’argent à un client, ou nuiraient à sa réputation, dans l’heure qui suit une panne ?
2. Qui est alerté quand un de ces sites tombe la nuit, et en combien de temps cette personne doit-elle confirmer l’alerte ?
3. Chaque site a-t-il son propre compte, sa propre base de données et ses propres limites de ressources, ou les sites les partagent-ils ?
4. À quand remonte la dernière restauration d’une sauvegarde à titre de test, et qui détient une copie en dehors de l’hébergeur ?
5. Que promet chaque plan d’entretien par écrit, et la configuration d’hébergement permet-elle de tenir cette promesse ?
6. Le fournisseur exige-t-il un déplacement, ou va-t-il opérer les hébergeurs déjà en place ?
7. Le prix est-il lié à un périmètre écrit, et comment un devis est-il établi pour le travail hors périmètre ?

Où se situe Stack Harbor

Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) de propriété canadienne pour les environnements de production, dont le siège est à Montréal. L’entreprise sert des agences, des entreprises SaaS et des éditeurs, et n’est pas un fournisseur de TI de bureau. Sa solution Infrastructure Agence est conçue pour les agences de 5 à 30 personnes qui opèrent de 5 à 30 sites clients sur WordPress, cPanel et hébergement infonuagique.

Stack Harbor opère les hébergeurs actuels de l’agence et consolide seulement là où un déplacement fait économiser de l’argent ou réduit le risque. L’entreprise ne remplace pas les développeurs de l’agence. La marque blanche est le modèle par défaut parmi trois modèles de partenariat : marque blanche, co-géré et référence directe. Dans la fenêtre de couverture que fixe le périmètre, la garde revient à Stack Harbor, avec une escalade documentée, une supervision avec alertes et un runbook par environnement. Une rotation de garde formée exécute des runbooks conçus par des ingénieurs seniors, et les ingénieurs seniors sont responsables des incidents de Gravité 1 (Sev-1). Les demandes techniques passent par le bureau de soutien, et le téléphone sert à joindre le gestionnaire de compte. Sur les forfaits qui incluent la couverture des incidents, un incident Sev-1 reçoit une réponse confirmée en moins de 15 minutes. La résolution est une cible, pas un engagement.

Pour les agences qui exploitent leurs propres serveurs, la gestion de serveurs cPanel et WHM comporte un niveau Opérations 24/7 qui inclut un soutien pour les portefeuilles d’agence. C’est le seul niveau de cette solution qui comprend la surveillance et la garde 24/7. Là où un déplacement est justifié, les sites sont migrés un à la fois, avec staging, et chaque projet des services de migration est livré avec un plan de retour arrière écrit. Les sites clients qui ont besoin d’un hébergement canadien peuvent être placés dans les deux centres de données de Stack Harbor à Montréal. La page Confiance et sécurité traite de la résidence des données et des engagements de service.

Stack Harbor ne publie pas de prix. Pour les agences, le prix combine un mandat de base et une facturation par site ou par ressource. Une consultation d’infrastructure et une revue de portefeuille mènent à un périmètre fixe et à un devis fixe.

Comment une agence devrait-elle choisir son modèle d’hébergement ?

Une agence qui choisit un modèle d’hébergement devrait partir de la garde, et non du serveur. Une agence qui a quelques sites semblables à faible risque devrait rester sur un forfait agence de plateforme. Une agence qui veut faire de l’hébergement un produit, et qui peut y affecter du personnel, devrait opérer son propre serveur. Une agence dont les développeurs seniors absorbent le travail d’hébergement devrait mesurer ces heures pendant un mois. Si ces heures coûtent plus que ce que rapporte la marge d’hébergement, l’agence devrait confier la couche d’hébergement à un partenaire d’exploitation et garder la relation client.