Commencer par les exigences d'exploitation
Avant de comparer les configurations, recueillez pour chaque projet la pile applicative, la base de données, les téléversements, les tâches planifiées, les intégrations et les changements attendus. Identifiez qui a besoin d'un accès au contenu, d'un accès au déploiement et d'une administration de l'hôte. Ce sont des rôles différents. Un client qui modifie une page peut n'avoir besoin que d'un compte applicatif ; un prestataire qui maintient le système d'exploitation nécessite une autorité nettement plus étendue.
Consignez aussi la fenêtre de maintenance acceptable, qui approuve l'indisponibilité, où sont conservées les copies de récupération et qui paie le travail opérationnel. Notez toute exigence client d'un serveur ou d'un compte séparé comme contrainte de décision. Un tableur de ressources ne peut pas trancher une exigence de propriété ou d'accès.
- Nommez l'opérateur principal et un remplaçant pour chaque projet.
- Listez les dépendances partagées : accès DNS, identifiants de déploiement, services de base de données et destinations de sauvegarde.
- Signalez les exigences inconnues pour une décision client avant de vous engager dans l'accord.
Choisir la frontière d'accès avant la taille du serveur
OWASP recommande d'accorder uniquement les autorisations nécessaires au travail d'une personne et de valider que les restrictions prévues tiennent. Appliquez ce principe au plan d'hébergement : utilisez des identités individuelles, des identifiants d'application spécifiques au projet et un chemin de déploiement documenté. Un répertoire nommé d'après un client est une aide organisationnelle, pas une politique d'accès.
Si vous utilisez Docker, considérez l'accès à son démon comme une responsabilité au niveau de l'hôte. La documentation de sécurité de Docker explique qu'un opérateur de démon de confiance peut monter et modifier les fichiers de l'hôte. Confier à un sous-traitant externe un contrôle Docker sans restriction est donc mal adapté à un hôte contenant les données d'un client sans lien.
Des instances VPS séparées permettent une administration du système d'exploitation et des décisions de version distinctes. Elles exigent toujours des autorisations soigneuses au sein de chaque projet. Des identifiants d'agence communs ou un compte de déploiement partagé peuvent reconnecter les risques que vous vouliez séparer.
Examiner deux briefs clients fictifs
Les clients ci-dessous sont des exemples fictifs, pas des historiques clients. L'agence exploite les deux projets aujourd'hui, mais leurs exigences d'accès et de calendrier diffèrent.
Placer ces deux projets ensemble ferait de l'accès du sous-traitant de Morrow et de son calendrier de lancement une part du risque opérationnel d'Aster. La décision de serveurs séparés découle de ces contraintes ; elle n'affirme pas que Morrow a besoin d'un nombre particulier de processeurs ni qu'Aster est sans risque.
Faites défiler horizontalement pour toutes les colonnes du tableau.
| Facteur de décision | Aster Furniture : site vitrine | Morrow Workshops : site d'inscription |
|---|---|---|
| Charge de travail | Pages publiques et mises à jour occasionnelles du contenu | Formulaires, une base de données et des exports d'inscriptions planifiés |
| Accès | Le client modifie le contenu ; l'agence déploie | Un développeur externe a besoin de l'administration de l'hôte |
| Maintenance | Une fenêtre convenue en soirée | Aucun changement planifié pendant un lancement de réservation |
| Impact d'un incident | Une panne temporaire de page peut être discutée | Des soumissions perdues ou dupliquées nécessitent une investigation |
| Exigence de sortie | Exporter le contenu et déplacer l'application | Transférer un environnement exploité de manière indépendante |
| Décision provisoire | Envisager un partage avec des sites compatibles gérés par l'agence | Utiliser un VPS séparé et des identifiants de projet séparés |
Comparer le coût complet des deux arrangements
Construisez deux versions budgétaires en utilisant le configurateur actuel : une configuration partagée et une configuration par projet. Pour chacune, listez séparément le total d'hébergement pour la période sélectionnée, les options récurrentes, les services externes et le temps de maintenance de l'agence. Évitez de copier un ancien prix dans le brief client. Notez quand la configuration a été préparée et qui a approuvé l'allocation.
Pour un hôte partagé, convenez de la façon dont les clients répartissent les coûts fixes et de ce qui se passe lorsqu'un part ou nécessite une mise à niveau. Des parts égales sont simples mais peuvent être inadaptées lorsqu'un projet cause la majeure partie de la croissance du stockage ou du travail opérationnel. Des serveurs séparés rendent l'attribution plus claire tout en ajoutant des tâches distinctes de correctifs, de surveillance et de récupération.
Laissez une marge de ressources pour les versions, les sauvegardes et le travail temporaire. Les conteneurs Docker n'ont aucune contrainte de processeur ou de mémoire par défaut ; configurez des limites appropriées et évaluez la charge de travail combinée. Une simple liste de conteneurs ne démontre pas un budget de ressources viable.
Rendre la maintenance et la récupération propres à chaque projet
Sur un hôte partagé, un redémarrage du système d'exploitation affecte chaque projet résident. Placez la maintenance de l'hôte sur un calendrier commun et identifiez qui contacte chaque client. Gardez les versions d'application séparées lorsque c'est pratique, et évitez de planifier l'export de données d'un projet pendant un lancement important d'un autre.
Les notes de récupération doivent identifier la base de données, les fichiers, la configuration et les identifiants requis d'un projet sans copier de secrets dans les notes. Planifiez la restauration vers une destination de test séparée. Restaurer un hôte partagé entier comme première réponse pourrait remplacer des changements sains appartenant à l'autre client.
Avec des instances VPS séparées, notez les services partagés qui subsistent. Un compte DNS commun, une destination de sauvegarde ou un opérateur peuvent encore affecter les deux projets. La séparation des serveurs ne prouve pas une infrastructure physique indépendante ni une disponibilité garantie.
Valider l'arrangement et définir les déclencheurs de revue
Avant d'accepter l'accord, faites vérifier par un second opérateur qu'une identité de projet peut effectuer son travail assigné et ne peut pas lire les fichiers, sauvegardes ou secrets de l'autre projet. Examinez les autorisations de base de données et les identifiants déployés ainsi que les écrans applicatifs. Utilisez des données de test inoffensives dans un environnement convenu ; ne sondez pas les données de production d'un autre client.
Consignez le résultat comme accepté, rejeté ou en attente d'une correction nommée. Si l'isolation ne peut pas être démontrée, réduisez l'accès ou déplacez le projet avant d'accorder des autorisations plus larges. Une réponse réussie de la page d'accueil n'est pas un contrôle d'accès ou de récupération.
- Conservez un registre de décision avec la disposition choisie, la répartition des coûts approuvée, les responsables et les points non résolus.
- Réexaminez le choix lorsqu'un administrateur externe rejoint, qu'une fenêtre de lancement change, que le stockage augmente ou qu'un client se prépare à partir.
- Utilisez le guide des responsabilités pour transformer le choix technique en accord d'exploitation.
Sources et révision
Les références techniques ont été vérifiées en septembre 12, 2026. Les exemples sont des exercices de planification ; la documentation logicielle citée n'établit pas les capacités de service PrivateHostLab.