Deux coopératives agricoles d’un même bassin de production, l’une spécialisée dans les céréales et l’autre dans le maraîchage, ont décidé de mutualiser un VPS pour héberger chacune son extranet fournisseurs, un espace où leurs adhérents respectifs consultent les commandes groupées d’intrants et les plannings de livraison. La motivation était purement financière : diviser par deux le coût d’un serveur suffisamment puissant pour absorber les pics de connexion en période de commande groupée.
L’idée fonctionne, à condition de traiter le partage de serveur comme ce qu’il est réellement : deux applications sensibles, appartenant à deux structures juridiquement distinctes, qui doivent coexister sans qu’un incident sur l’une ne se propage à l’autre. Un simple sous-dossier partagé sous le même utilisateur système ne suffit pas à garantir cette isolation.
Ce que l’isolation par utilisateur système apporte
La configuration retenue attribue à chaque extranet son propre utilisateur système Linux, avec son propre pool PHP-FPM et ses propres droits de fichiers, plutôt qu’un unique utilisateur partagé pour les deux sites :
[extranet-cereales]
user = cereales
group = cereales
listen = /run/php/php8.2-fpm-cereales.sock
php_admin_value[open_basedir] = /var/www/cereales:/tmp
[extranet-maraichage]
user = maraichage
group = maraichage
listen = /run/php/php8.2-fpm-maraichage.sock
php_admin_value[open_basedir] = /var/www/maraichage:/tmp
La directive open_basedir restreint explicitement chaque pool à son propre dossier, ce qui empêche un script PHP compromis sur l’un des deux extranets de lire ou d’écrire des fichiers appartenant à l’autre, même en cas de vulnérabilité applicative découverte sur l’un des deux WordPress.
Séparer aussi les bases de données
Chaque extranet dispose de sa propre base MySQL, avec un utilisateur de base de données dont les droits sont restreints à cette seule base, une pratique qui évite qu’une injection SQL découverte sur l’un des deux sites ne permette d’accéder aux données de l’autre :
CREATE DATABASE extranet_cereales CHARACTER SET utf8mb4;
CREATE USER 'cereales_user'@'localhost' IDENTIFIED BY 'un_mot_de_passe_genere';
GRANT ALL PRIVILEGES ON extranet_cereales.* TO 'cereales_user'@'localhost';
CREATE DATABASE extranet_maraichage CHARACTER SET utf8mb4;
CREATE USER 'maraichage_user'@'localhost' IDENTIFIED BY 'un_autre_mot_de_passe';
GRANT ALL PRIVILEGES ON extranet_maraichage.* TO 'maraichage_user'@'localhost';
Ce cloisonnement paraît élémentaire, mais il est fréquemment négligé sur ce type de mutualisation informelle entre deux structures, où l’urgence de la mise en place fait souvent passer au second plan la question de l’isolation, réglée « plus tard » et parfois jamais.
Répartir la charge sans se gêner mutuellement
Le second point d’attention concerne les pics de charge. Les deux coopératives ne commandent pas leurs intrants aux mêmes périodes de l’année, mais un pic de connexion simultané reste possible, notamment en fin de mois quand les factures groupées sont mises à disposition sur les deux extranets. Une limite de ressources par pool PHP-FPM, avec pm.max_children fixé indépendamment pour chacun, garantit qu’un pic sur l’extranet céréalier ne prive pas l’extranet maraîcher de ses propres processus disponibles.
Ce que le partage ne doit pas devenir
La question qui s’est posée à mi-parcours du projet a été celle des accès administratifs : fallait-il qu’un administrateur système unique gère les deux sites, avec un accès complet aux deux, ou fallait-il maintenir une séparation même à ce niveau ? La décision retenue a été de conserver un accès SSH partagé pour la maintenance système générale du VPS, mais des accès WordPress totalement distincts, chaque coopérative gardant la main sur l’administration de son propre extranet sans visibilité sur celui de l’autre.
- un utilisateur système et un pool PHP-FPM distincts par extranet ;
- une base de données et un utilisateur de base distincts par extranet ;
- des sauvegardes séparées, chacune restaurable indépendamment de l’autre ;
- un accès administrateur WordPress strictement limité à la structure concernée.
Mutualiser un serveur entre deux structures distinctes n’a de sens que si l’isolation technique est aussi stricte que si chacune payait son propre serveur : le partage de coût ne justifie jamais un partage de risque.
Ce qu’on retient
Le partage d’un VPS entre deux coopératives voisines fonctionne bien à condition de traiter chaque extranet comme un locataire à part entière du serveur, avec son propre utilisateur système, sa propre base de données et ses propres limites de ressources. La mutualisation des coûts d’infrastructure reste une bonne idée entre structures de confiance ; elle ne dispense en rien de mettre en place les mêmes cloisons techniques que si chacune hébergeait son extranet séparément.
