---
title: Héberger plusieurs projets sur un seul serveur
description: >-
  Hébergez plusieurs projets et bases de données sur un seul serveur au lieu de
  payer par service. La réponse générale, les limites, et comment le
  dimensionner.
date: '2026-09-02'
lastUpdated: '2026-09-02'
keywords:
  - héberger plusieurs projets sur un serveur
  - auto-hébergement de plusieurs projets
  - éviter la facturation par projet
  - une VM plusieurs applications et bases de données
  - Coolify plusieurs projets
  - alternative à la facturation par service
type: article
author: Ross Hill
locale: fr_CA
site_name: MapleDeploy
slogan: Hébergement performant en sol canadien
organization_url: 'https://mapledeploy.ca/'
logo: 'https://mapledeploy.ca//api/logo/lockup'
creator: MapleDeploy
publisher: MapleDeploy
founding_date: '2026-01-13'
email: hello@mapledeploy.ca
geo_region: CA-QC
geo_placename: Montréal
address_country: CA
area_served: Canada
application_category: DeveloperApplication
app_url: 'https://app.mapledeploy.ca'
llms_txt: 'https://mapledeploy.ca/fr/llms.txt'
offers: >-
  Starter $45/mo, Pro $95/mo, Ultra $195/mo, Ultra 32 $395/mo, Ultra 64 $695/mo
  CAD
in_language: fr-CA
canonical_url: 'https://mapledeploy.ca/fr/blog/run-side-projects-one-server'
---

Mettez-les tous sur un seul serveur, derrière une plateforme de déploiement, et faites tourner une seule instance Postgres avec une base de données distincte par projet plutôt qu'un service de base de données par projet. Voilà toute la réponse. Le reste de cet article couvre l'arithmétique qui justifie la démarche, et les précautions qui la rendent viable.

Le problème que vous cherchez à résoudre est réel. Sur les plateformes facturées par service, une application web plus un processus en arrière-plan plus une base de données, c'est trois lignes de facturation distinctes. Cinq projets personnels construits de la même façon, c'est quinze. La plupart de ces projets reçoivent une poignée de visites par mois. Payer le plein tarif par service sur chacun d'eux, c'est comment une pile de projets personnels finit par coûter plus cher qu'un loyer.

## Pourquoi la facturation par projet s'accumule

Quelques exemples concrets, parce que « ça s'accumule » est facile à dire et difficile à visualiser.

Sur [Render](/fr/compare/render), un service web Starter coûte 7 $ US/mois, une base de données PostgreSQL de base coûte 6 $ US/mois, et un processus en arrière-plan ajoute 7 $ US de plus. Un seul petit projet avec un worker atteint déjà 20 $ US/mois avant même d'avoir du trafic. Cinq projets construits de la même façon, exécutés séparément, montent à 100 $ US/mois.

Heroku mérite une nuance ici, parce qu'il existe un forfait qui n'est réellement pas facturé par application. Le forfait Eco coûte 5 $ US/mois pour [1000 heures de dyno partagées entre tous vos dynos Eco](https://devcenter.heroku.com/articles/eco-dyno-hours), et les dynos Eco se mettent en veille après 30 minutes d'inactivité sans consommer d'heures. Si vos projets personnels ne reçoivent vraiment aucun trafic, c'est l'option la moins chère de cette page. Dès que vous voulez quelque chose qui reste allumé en permanence, vous passez à un dyno Basic à 7 $ US/mois plus un module Postgres Essential-0 à 5 $ US/mois, facturés par application. Notre [comparaison Heroku](/fr/compare/heroku) détaille davantage.

Sur [Railway](/fr/compare/railway), la tarification est basée sur l'utilisation plutôt que par application. Le forfait Hobby coûte 5 $ US/mois et inclut 5 $ de crédit d'utilisation, et Pro coûte 20 $ US/mois et en inclut 20 $, donc l'utilisation ne s'ajoute pas au forfait tant que le crédit n'est pas épuisé. Au-delà, les tarifs tournent autour de 20 $ US par vCPU par mois et 10 $ US par Go de RAM par mois. Une base de données, un worker et un processus web puisent chacun dans ce compteur, donc la facture est proportionnelle au nombre de choses que vous exécutez, pas au nombre de serveurs qui les hébergent.

Supabase facture par projet, pas par serveur : le forfait Pro coûte 25 $ US/mois et inclut des crédits de calcul pour un projet, et [chaque projet supplémentaire part à environ 10 $ US/mois](https://supabase.com/pricing). C'est la même logique à l'unité que les autres, comptée en projets plutôt qu'en services.

Aucune de ces plateformes ne fait quoi que ce soit de mal. La facturation par service est honnête et elle descend à zéro pour les projets que personne ne visite. Elle devient aussi coûteuse par projet dès que vous en avez plus d'un ou deux, parce que vous payez pour une isolation dont vous n'avez pas besoin à l'échelle d'un projet personnel.

## La réponse générale : un serveur, une plateforme de déploiement devant

Louez une seule VM. Installez-y une plateforme de déploiement, par exemple [Coolify](/fr/open-source-stack), Dokploy ou CapRover. Déployez chaque projet comme sa propre application ou sa propre pile Docker Compose. Faites tourner une seule instance Postgres (ou MySQL, ou les deux) comme service permanent, et donnez à chaque projet sa propre base de données et son propre utilisateur à l'intérieur de cette instance plutôt que son propre conteneur de base de données.

C'est tout. C'est vrai que vous auto-hébergiez cette pile sur n'importe quelle VM à 10 $/mois de n'importe quel fournisseur, ou que vous payiez quelqu'un pour exploiter le serveur à votre place. L'économie fonctionne de la même manière dans les deux cas : vous payez pour les ressources d'une seule machine plutôt qu'une facture par service.

La partie qui demande vraiment de l'attention, c'est ce qui se passe après le regroupement.

## Ce qui casse quand vous regroupez tout

**La RAM est la contrainte réelle, pas le nombre de projets.** Une dizaine de sites statiques et de tâches planifiées ne coûte presque rien à faire tourner ensemble. Une dizaine d'applications Node ou Python toujours actives, chacune avec son propre bassin de connexions et son propre cache en mémoire, c'est une tout autre histoire. Comptez ce que chaque projet garde réellement en mémoire, pas le nombre de projets que vous avez.

**Un seul serveur, c'est un seul domaine de panne.** Si la VM tombe, tous les projets qu'elle héberge tombent en même temps. C'est un compromis réel par rapport aux plateformes facturées par service, où la panne d'un fournisseur dans une région ne fait pas nécessairement tomber tous les services que vous y exploitez. Pour des projets personnels, la plupart des gens acceptent ce compromis sans hésiter. Pour tout ce dont dépend un client ou un utilisateur payant, mieux vaut le nommer clairement plutôt que de le découvrir pendant un incident.

**Vos propres projets deviennent leurs propres voisins bruyants.** Cette nuance mérite d'être précise, parce que c'est une affirmation différente de celle que font habituellement les fournisseurs hébergés. « Pas de voisins bruyants » sur une plateforme gérée signifie habituellement qu'aucune charge de travail *d'un autre client* n'entre en concurrence avec la vôtre. Sur votre propre serveur regroupé, vos propres projets deviennent maintenant les voisins bruyants les uns des autres. Une compilation qui s'emballe, une fuite de mémoire ou un fichier journal sans limite dans le projet A peut affamer le projet B si rien ne l'en empêche. Les limites de ressources Docker (`mem_limit`, `cpus` dans Compose, ou l'équivalent de votre plateforme) existent exactement pour ça, et valent la peine d'être fixées dès que vous exploitez plus de deux ou trois projets.

**Les sauvegardes comptent davantage quand tout est au même endroit.** Perdre un serveur signifiait autrefois perdre la base de données d'un seul projet. Maintenant, ça signifie les perdre toutes en même temps. Des sauvegardes au niveau des bases de données (un `pg_dump` planifié vers un stockage compatible S3, ou l'outil de sauvegarde intégré à votre plateforme) et une façon de reconstruire l'hôte lui-même méritent d'être en place avant d'en avoir besoin, pas après.

## Dimensionner le serveur : ce que coûtent réellement une petite application et une base de données

Une façon utile de dimensionner le serveur consiste à séparer les frais fixes du coût par projet.

Le coût fixe correspond au système d'exploitation, à Docker et à la plateforme de déploiement elle-même, avant même de déployer quoi que ce soit. Sur un serveur MapleDeploy fraîchement provisionné, cette base se situe généralement entre 0,7 et 0,8 Go de RAM. Peu importe la plateforme utilisée, attendez-vous à un ordre de grandeur similaire : c'est le prix d'entrée avant que vos propres applications n'obtiennent leur part.

Le coût par projet est plus petit qu'on ne le croit pour des projets personnels à faible trafic. Une petite API Node, Python ou Go qui reste surtout inactive, sans trafic significatif, occupe habituellement bien moins de quelques centaines de mégaoctets en mémoire résidente. Une base de données Postgres peu utilisée par un petit projet est généralement similaire, davantage si vous augmentez `shared_buffers` ou exécutez des requêtes plus lourdes. Une paire « application web plus Postgres » pour un projet personnel à faible trafic tient donc souvent confortablement dans quelques centaines de mégaoctets au total, et cinq ou six de ces paires ensemble, plus les frais fixes de la plateforme, représentent une charge qu'un serveur de 4 Go peut porter sans drame. Le trafic, les tâches en arrière-plan et tout ce qui garde un gros cache en mémoire font grimper ces chiffres rapidement, alors traitez ceci comme une estimation de départ à vérifier avec l'usage réel de vos propres projets, pas comme une promesse.

Une seule instance, plusieurs bases de données, ça fonctionne bien dans ce contexte. Vous n'avez pas besoin d'un conteneur Postgres distinct par projet. Créez un seul service Postgres, puis `CREATE DATABASE projet_a;`, `CREATE DATABASE projet_b;`, chacune avec son propre utilisateur et ses propres identifiants. C'est la façon habituelle d'exécuter plusieurs petites applications contre un seul moteur de base de données, et c'est beaucoup plus léger qu'un conteneur de base de données par projet.

## Faire le lien avec un forfait

Peu importe la plateforme qui gère le déploiement, vous devez éventuellement dimensionner un serveur pour le total, pas pour la moyenne. Les forfaits MapleDeploy, tous à prix fixe en CAD par mois, sans facturation par projet ni par service :

| Forfait | RAM | vCPU | Stockage | Prix (CAD) |
| --- | --- | --- | --- | --- |
| Starter | 4 Go | 2 | 35 Go | 45 $/mois |
| Pro | 8 Go | 4 | 70 Go | 95 $/mois |
| Ultra | 16 Go | 6 | 125 Go | 195 $/mois |
| Ultra 32 | 32 Go | 8 | 250 Go | 395 $/mois |
| Ultra 64 | 64 Go | 8 | 500 Go | 695 $/mois |

Les forfaits Starter et Pro incluent un essai gratuit de 30 jours, pour que vous puissiez déployer vos vrais projets, observer l'usage réel de mémoire et de processeur dans le tableau de bord, et confirmer que le forfait convient avant de payer. Consultez la [tarification complète](/fr/#pricing) pour tous les paliers.

## Ai-je besoin d'un service de base de données distinct par projet?

Non. Une seule instance Postgres ou MySQL, avec une base de données et un utilisateur par projet, est la façon habituelle de procéder, et c'est considérablement plus léger en RAM qu'un conteneur de base de données par projet. Gardez les identifiants séparés par projet, pour qu'un bogue ou une clé divulguée dans une application n'expose pas les données d'un autre projet.

## Signes que vous poussez le serveur trop loin

- Les déploiements échouent en cours de compilation, non pas à cause de votre code mais parce que le serveur a manqué de mémoire en pleine construction.
- Un pic de trafic sur un projet ralentit visiblement un projet distinct sur la même machine.
- L'usage du disque grimpe régulièrement à cause d'images Docker, de caches de compilation et d'anciens conteneurs accumulés, pas parce que vos données grossissent.
- Vous vérifiez si le serveur fonctionne encore plus souvent que vous ne livrez de nouvelles fonctionnalités.

N'importe lequel de ces signes indique qu'il faut fixer des limites de ressources, déplacer un projet ailleurs, ou passer à un forfait supérieur, pas paniquer. C'est de l'entretien normal pour un serveur partagé, comme ce le serait pour une instance de base de données partagée.

## Si vous préférez ne pas exploiter le serveur vous-même

La version auto-hébergée de tout ceci est réellement une bonne affaire pour bien des gens. C'est aussi du travail continu : correctifs du système d'exploitation, mises à jour de la plateforme, règles de pare-feu et sauvegardes, indéfiniment.

MapleDeploy exploite du Coolify géré sur une machine virtuelle (VM) dédiée à Toronto, et c'est construit exactement pour cet usage : un serveur, plusieurs applications et bases de données, un prix fixe. Chaque client obtient sa propre VM, pas un conteneur partagé, ce qui fait que l'absence de « voisins bruyants » tient réellement pour l'isolation entre clients. Ce que vous déployez sur cette VM, et comment vous répartissez ses ressources entre vos propres projets, reste entre vos mains.

Si vous partez de zéro, notre [guide de déploiement de votre première application](/fr/docs/deploy-your-first-app) explique comment connecter un dépôt et le mettre en ligne, et le même serveur accueille votre deuxième et votre troisième projet de la même façon.

{% cta-section title="Un seul serveur, autant de projets qu'il peut en contenir" %}
Essai gratuit de 30 jours sur Starter et Pro. Tarification forfaitaire en CAD, sans frais par projet.
{% /cta-section %}