Héberger cinq sites WordPress clients : isolation, accès et restauration

Le problème : gérer cinq clients sans transformer chaque incident en panne générale

Vous hébergez les vitrines de cinq entreprises différentes. Le client A doit pouvoir modifier son contenu sans voir les fichiers du client B. Si une mise à jour casse le site C, vous voulez restaurer C sans remettre les quatre autres à la date de la veille. Enfin, quand D quitte votre prestation, son départ doit être possible sans lui transmettre votre compte principal. Ce sont ces opérations, et non le nombre maximal de sites annoncé, qui guident la sélection.

Le dossier retient six configurations documentées, pas six garanties de sécurité absolue. Il compare des offres d’agence, des sous-comptes et une plateforme organisée par hébergements. Les prix et documents officiels ont été consultés le 2 novembre 2026. Nous n’avons ouvert aucun compte, testé aucun accès ni réalisé de restauration. Une fonction décrite par un fournisseur reste une preuve documentaire de son offre, pas un essai réussi sur vos cinq sites.

Les hypothèses communes : petits sites, copies de travail et messagerie existante

Notre exemple est volontairement borné : cinq installations WordPress indépendantes, chacune sur son domaine, sans boutique, espace membre volumineux ni diffusion de vidéos depuis le serveur. Nous prévoyons deux gigaoctets par site pour ses fichiers et sa base, soit dix gigaoctets en production. Une copie de travail de même taille pour chaque projet porte l’enveloppe à vingt gigaoctets ; cinq gigaoctets supplémentaires constituent une réserve de croissance illustrative. Le besoin de référence est donc vingt-cinq gigaoctets, pas une mesure réelle de vos données. Le mode de comptage des copies varie selon le fournisseur : cet exemple ne signifie pas que chaque plateforme facture vingt-cinq gigaoctets.

La messagerie reste chez les prestataires déjà choisis par les clients : deux boîtes de cinq gigaoctets par entreprise, soit dix boîtes au total. Leur coût réel demeure extérieur au budget web, il n’est pas réputé nul. Les cinq domaines existants restent également facturés séparément. Pour la charge, nous supposons environ trois mille visites et cinq gigaoctets de transfert mensuel par site. Ces hypothèses aident à discuter une offre ; elles ne prouvent pas sa capacité à absorber des connexions simultanées ou des traitements lourds.

Cinq installations ne sont pas un réseau WordPress multisite

Un réseau multisite permet de gérer plusieurs sites dans une même installation WordPress. Certains éléments y sont communs ; il ne fournit pas automatiquement cinq environnements d’hébergement autonomes. Pour cinq entreprises distinctes qui peuvent changer de prestataire séparément, nous retenons ici cinq installations, une base distincte affectée à chaque site et des utilisateurs techniques distincts lorsque le service le permet. Il s’agit d’un choix d’organisation pour ce scénario, pas d’une interdiction générale du multisite.

Cette distinction change aussi les sauvegardes et les départs. La restauration d’un environnement réseau entier n’est pas la même opération que celle d’une seule installation. Un bouton de transfert prévu pour une installation ne démontre pas qu’il sait extraire un sous-site de réseau. Ne regroupez donc pas les cinq clients dans un réseau uniquement pour entrer dans un petit forfait. Si vous exploitez déjà un réseau, faites étudier son extraction avant d’appliquer cette comparaison.

Trois formes de séparation à examiner sans les confondre

La première séparation concerne les accès : ce que le client voit dans le panneau. La deuxième concerne les données et les processus : ce que le logiciel de son site peut atteindre. La troisième concerne les ressources : ce qu’un traitement gourmand peut consommer. Des dossiers différents ne démontrent pas une barrière entre processus ; un utilisateur limité à un écran ne prouve pas une réserve de mémoire indépendante. Une documentation décrivant des conteneurs ne signifie pas non plus que la facturation ou les quotas sont séparés.

Pour ce portefeuille, demandez une explication applicable aux sites d’un même compte, pas seulement aux comptes de deux acheteurs différents. Chez o2switch, la documentation des lunes distingue le cloisonnement et les ressources selon la formule. Chez Infomaniak, les droits administratifs suivent l’hébergement : notre organisation utilise un hébergement par client. Kinsta décrit un conteneur logiciel par site. Les annonces d’isolation de Hostinger et SiteGround sont attribuées à leurs fournisseurs ; elles ne deviennent pas ici des certifications indépendantes.

Choisir entre sous-comptes, plateforme d’agence et hébergements organisés

Si vous souhaitez donner un panneau d’hébergement au client tout en gardant une supervision centrale, comparez les lunes Cloud d’o2switch et les packages revendeurs de 20i. L’unité de gestion devient le compte client ou le package. Il faut malgré tout préparer une sauvegarde et une sortie de projet ; changer le nom d’un dossier ne remplace pas cette organisation. La variante 20i étudiée est une offre publique américaine en dollars, avec documentation en anglais et conditions commerciales à confirmer pour votre compte.

Si vous préférez affecter des droits à une installation dans une console commune, examinez Hostinger Agency, SiteGround GoGeek et Kinsta WP 5. Leurs différences apparaissent surtout dans les rôles et le transfert, pas dans la simple présence de WordPress. Infomaniak Cloud managé constitue une autre approche : un serveur organisé en plusieurs hébergements, avec des ressources globales. Aucun de ces modèles ne supprime le besoin d’un responsable qui connaît les cinq projets et garde les accès de secours.

Donner au client le bon accès, sans partager le compte maître

Décidez d’abord ce que chaque client doit faire : publier des pages, gérer sa messagerie, restaurer un site ou manipuler des fichiers. Un rôle WordPress suffit souvent pour les contenus ; il ne donne pas pour autant accès au panneau de l’hébergeur. Conservez des identités séparées pour l’agence, le client et un intervenant temporaire. Le compte de facturation et l’accès global ne doivent pas servir de raccourci partagé entre tous les projets.

Les documents consultés imposent des nuances concrètes. Sur GoGeek, le rôle client par défaut donne un ensemble large d’outils ; les rôles personnalisables décrits par SiteGround relèvent du Cloud. Dans MyKinsta, le développeur de site est limité aux environnements de travail, tandis que l’administrateur de site dispose d’un accès plus large. Chez Infomaniak, inviter un client sur un hébergement contenant les cinq sites lui donnerait accès à cet ensemble. Le découpage doit donc précéder les invitations.

• Avant la mise en service, faites vérifier avec un compte client que seuls son projet et les opérations autorisées sont visibles ; ce contrôle n’a pas été exécuté pour ce dossier.
• Si un autre client apparaît, retirez l’accès concerné et corrigez l’affectation avant d’ouvrir les invitations suivantes.
• Lors d’un départ, révoquez les invitations et les accès techniques devenus inutiles ; conservez une identité d’agence distincte pour assurer le suivi prévu.

Restaurer un site : vérifier le périmètre avant de confirmer

Le besoin minimum est de choisir le projet et une date, puis de remettre ses fichiers et sa base dans un état cohérent. Une restauration reste une écriture : elle peut effacer des changements récents sur ce projet, même si elle ne vise pas les quatre autres. Préservez donc l’état présent avant de revenir en arrière. Si l’origine de l’incident est inconnue, une vieille copie peut aussi contenir la même faille.

Les périmètres diffèrent. JetBackup distingue les fichiers, les bases et les comptes mail ; ne sélectionnez pas tout le compte par habitude. Infomaniak propose une restauration avancée par sites et bases, contrairement à la restauration simple de tout l’hébergement. Hostinger Agency documente une restauration complète du site, mais pas la même restauration fine de fichiers que ses autres gammes. SiteGround et MyKinsta organisent leurs outils autour du site sélectionné. L’existence d’un bouton ne dispense pas de contrôler la cible.

• Relevez le domaine, l’environnement, la base et la date de copie ; arrêtez si l’un de ces éléments ne correspond pas au projet concerné.
• Privilégiez une copie isolée pour évaluer le résultat, avec les notifications et autres effets réels neutralisés.
• Après validation, contrôlez le site restauré et un parcours représentatif sur chacun des autres sites ; aucune absence d’impact n’est présumée avant ce contrôle.

La rétention ne remplace pas votre politique de sauvegarde

Une copie quotidienne et un historique de plusieurs semaines répondent à deux questions différentes : la perte possible depuis la dernière copie et la profondeur de retour disponible. Pour ces vitrines, un objectif de reprise avec au plus une journée de contenu perdu peut servir de point de départ à discuter. Ce n’est ni un engagement des fournisseurs ni une promesse de remise en ligne dans un délai donné. Les contrats clients doivent distinguer ces deux délais.

Gardez également une copie exportable hors du compte principal, avec les fichiers et la base identifiés pour chaque client. Le coût de cet espace externe dépend de votre solution et n’est pas inventé dans les totaux. Une réserve particulière concerne 20i : la documentation de restauration présente Timeline comme abonnement, tandis qu’une page commerciale met en avant des snapshots gratuits. Le périmètre automatique effectivement inclus doit être confirmé ; le prix d’entrée ne vaut donc pas budget complet de protection.

Préparer dès maintenant le départ d’un seul client

Un transfert interne de propriété et une migration vers un autre hébergeur sont deux démarches différentes. Le premier conserve la plateforme mais change son détenteur administratif ; la seconde nécessite une destination compatible, la copie des données et une bascule du domaine. Dans les deux cas, le domaine, les messages, les licences d’extensions et les copies de sécurité doivent figurer dans le périmètre de remise. Ne cédez jamais les sauvegardes des autres clients dans une archive globale.

Les sorties documentées ne sont pas équivalentes. Kinsta prévoit le transfert d’un site entre entreprises, avec acceptation du destinataire. SiteGround décrit le transfert du site et de ses données vers un nouveau propriétaire. 20i impose des conditions sur le type de compte destinataire du package. Chez Hostinger, le transfert automatisé de propriété est actuellement indisponible pour Agency : prévoyez une migration manuelle. Ces limites peuvent peser davantage que quelques euros de différence au lancement.

L’archive téléchargée doit également être examinée avant un départ. Sur Hostinger Agency, la sauvegarde de fichiers WordPress contient wp-config.php et wp-content, sans les fichiers du cœur de WordPress ; la base se récupère séparément. Un téléchargement complet depuis le gestionnaire de fichiers prend l’état présent, pas nécessairement celui de l’ancienne sauvegarde. Préparez donc un ensemble cohérent, avec la version du cœur et les fichiers nécessaires à cette copie, puis faites vérifier sa restauration sur une destination isolée. Un fichier ZIP disponible ne prouve pas, à lui seul, que tout le site peut être remis en service ailleurs.

Construire un budget pour le portefeuille, pas cinq faux prix indépendants

Un forfait acheté pour cinq sites est une dépense commune. Diviser son prix par cinq donne une clé de répartition comptable, pas cinq abonnements transférables. Si un client part, la facture du portefeuille ne baisse pas nécessairement. Prévoyez donc votre budget lorsque seuls quatre clients restent, et dites clairement si le prix facturé au client couvre seulement l’hébergement ou aussi votre travail de maintenance.

Les fiches distinguent les sommes initiales, les cycles et les renouvellements publiés. Les domaines, la messagerie conservée ailleurs, l’archivage indépendant et une intervention humaine éventuelle restent des lignes séparées. Les devises ne sont pas converties artificiellement. Les deux pages européennes de SiteGround consultées lors de la relecture affichent désormais la même promotion GoGeek. Chez Infomaniak, le prix à partir de ne permet pas d’établir le total initial d’une configuration précise. Une promotion reste à vérifier à la commande ; elle ne réduit pas le renouvellement annoncé.

La capacité doit rester observable après la mise en service

Notre enveloppe de stockage rend ces configurations plausibles à examiner ; elle ne constitue pas un banc d’essai. Les sites peuvent partager des quotas, un serveur, une file d’attente de restauration ou un contrat. Une importation massive, une tâche d’entretien ou un module défectueux peut modifier la charge sans augmenter fortement le nombre de visiteurs. Demandez quels indicateurs sont disponibles pour repérer cette situation et quelles mesures nécessitent une formule supérieure.

Préparez un seuil de réévaluation par projet : consommation d’espace, saturation rapportée par l’hébergeur, dépassement de quota ou multiplication des incidents. Cela ne signifie pas activer des limites au hasard. Commencez par observer les informations du panneau et les journaux accessibles, sans installer systématiquement une nouvelle extension. Si un site devient une boutique ou un service critique, requalifiez son besoin plutôt que de considérer qu’il reste petit parce qu’il occupe encore un seul emplacement.

Prendre une décision exploitable et conserver une porte de sortie

Pour une gestion par comptes clients, examinez d’abord l’organisation des lunes ou des packages. Pour un suivi centré sur les sites, comparez les rôles, la restauration et la remise au client dans les consoles d’agence. Pour Infomaniak, vérifiez que les cinq hébergements distincts font bien partie du devis retenu. Une offre dont une condition indispensable reste inconnue n’est pas prête à être achetée, même si elle figure dans cette sélection documentaire.

Avant de payer, faites confirmer la configuration, les taxes, la région et les coûts complémentaires. Avant de migrer, gardez les originaux et fixez une procédure de validation et de retour arrière. Après installation, prévoyez le contrôle des droits et une restauration maîtrisée sur un projet non critique. Le bon résultat n’est pas un compte rempli de cinq domaines : c’est un portefeuille où chaque client possède un périmètre identifiable, récupérable et transmissible sans emporter les autres.