Où héberger une application web : le bon choix selon votre situation

Six familles d'hébergement

Une application web, c'est du code qui répond aux requêtes, une base de données qui garde l'état, et souvent des tâches de fond. Chaque famille d'hébergement en prend en charge une partie.

• Les outils de création par IA publient eux-mêmes : Lovable sur une adresse en lovable.app, avec un backend intégré (base, connexion des utilisateurs, fichiers), Bolt sur une adresse en bolt.host, Replit avec quatre types de déploiement.
• Les plateformes de déploiement (Vercel, Netlify) construisent l'application à chaque envoi de code, la distribuent depuis leur réseau et exécutent le code serveur sous forme de fonctions.
• Les PaaS (Render, Railway, Fly.io) font tourner dans leurs conteneurs les services que vous déclarez : serveur web, worker, tâche planifiée, base.
• Le cloud (AWS, Google Cloud, DigitalOcean) offre un catalogue de briques que vous assemblez : machines, bases gérées, stockage, files de messages.
• Le VPS non géré vous donne un serveur, avec l'accès root : tout ce qui s'y passe vous revient.
• Le VPS géré est le même serveur, exploité par l'hébergeur, qui le tient à jour, le surveille et intervient.

Le comparatif, critère par critère

Le premier tableau montre ce qui reste à votre charge, le second ce que vous payez et où vivent vos données (tarifs et documentations publiés en octobre 2026).

Ce que vous gérez, la base, les tâches de fond

Famille	Ce que vous gérez	Base de données	Tâches de fond, processus permanents
Outils de création par IA	L'application, dans le cadre de l'outil	Intégrée (Lovable) ou reliée, comme Supabase	Selon l'outil (machine réservée et déploiements planifiés chez Replit)
Plateformes de déploiement	Le code et sa configuration	Chez un fournisseur tiers (Neon, Supabase, Upstash par la place de marché de Vercel)	Fonctions à durée bornée : chez Vercel, 300 s par défaut, 800 s en Pro (1 800 s en bêta) ; processus permanents en bêta
PaaS	Le code, les services, leur taille	Proposée par la plateforme, facturée à part	Workers et tâches planifiées, déclarés comme services
Cloud	L'architecture au complet : réseau, machines, accès	Service géré ou base sur une machine	Tout, en assemblant les services
VPS non géré	Le serveur : système, sécurité, sauvegardes, supervision	Sur le serveur, réglée et sauvegardée par vous	Autant que la mémoire le permet
VPS géré	Votre code ; l'hébergeur exploite le serveur	Sur le serveur, sauvegardée par l'hébergeur	Autant que la mémoire le permet, surveillés par l'hébergeur

La facture, les données, la sortie

Famille	Facture	Emplacement des données	Portabilité
Outils de création par IA	Abonnement ; chez Lovable, le backend intégré consomme des crédits	Chez la plateforme et ses fournisseurs	Code synchronisé avec GitHub (Lovable) ; le backend intégré se migre à part
Plateformes de déploiement	Abonnement puis usage : chez Vercel Pro, 20 USD par mois et par membre qui déploie, 20 USD d'usage compris	Fonctions dans une région (iad1 par défaut chez Vercel), base chez son fournisseur	Code standard ; les services propres à la plateforme se remplacent
PaaS	À la ressource : chez Railway, 20 USD par vCPU et 10 USD par Go de mémoire, par mois	Une région au choix (cinq chez Render)	Simple avec un Dockerfile
Cloud	Service par service ; chez AWS, transfert sortant facturé au-delà de 100 Go gratuits par mois	La région de votre choix	Selon les services employés
VPS non géré	Un prix par taille ; transfert parfois facturé au-delà d'un volume inclus (0,01 USD par Gio chez DigitalOcean)	Le centre de données du serveur	Totale : logiciels standard, accès root
VPS géré	Un prix mensuel par taille, exploitation comprise	Le centre de données du serveur ; sauvegardes hors de la machine	Totale : votre code et vos données restent à vous

Trois critères à regarder de près

La facture qui suit le trafic

Sur une plateforme facturée à l'usage, le prix d'un mois dépend de ce que l'application a fait ce mois-là. Chez Vercel, une fois le crédit compris consommé, le temps de processeur des fonctions, leur mémoire, les régénérations de pages et les transformations d'images se facturent à l'unité ; chez Fly.io, les machines se paient à la seconde. Idéal pour démarrer petit, ce modèle demande de garder un œil sur le tableau de bord quand l'application grandit. Sur un VPS, un pic de trafic consomme les ressources du serveur et la facture reste la même : la question devient celle d'une taille qui tient vos pics, avec de la marge.

Les tâches de fond et les processus permanents

Workers de files de tâches, robots de synchronisation, connexions en temps réel, tâches planifiées : beaucoup d'applications ont cette seconde vie. Les plateformes de déploiement sont construites autour de fonctions à durée bornée, et Vercel propose les processus permanents en bêta (Vercel Daemons). Les PaaS les déclarent comme des services à part, un background worker ou un cron job chez Render. Sur un serveur, ce sont des processus comme les autres, lancés et relancés par le système.

L'emplacement des données

Chez Vercel, les fonctions s'exécutent par défaut dans la région iad1 (Washington), et la documentation recommande de placer la base dans la même région : chaque aller-retour vers une base éloignée se paie en latence. Sur un VPS, l'application et sa base partagent la même machine, dans un centre de données identifié, ce que demandent souvent les clients d'affaires et les contrats qui encadrent les renseignements personnels.

Selon votre situation

Votre situation	L'hébergement qui lui correspond
Un prototype, une démo, une idée à tester	L'hébergement de l'outil de création, ou l'offre gratuite d'une plateforme (chez Vercel, l'offre Hobby est réservée à un usage personnel et non commercial)
Une application qui a ses premiers utilisateurs	Un VPS géré ; un PaaS si votre équipe développe et déploie elle-même
Une application d'affaires : données de clients, équipe qui en dépend	Un VPS géré : données à un endroit identifié, sauvegardes, supervision avec intervention
Le développeur est parti, ou l'application a été créée avec l'IA	Un VPS géré, avec la reprise et la migration de l'existant
Une équipe technique qui veut garder la main	Un VPS, avec une assistance pour les questions qui sortent du quotidien
Un site surtout statique, au trafic mondial très variable	Une plateforme de déploiement et son réseau de distribution

Tant que l'application sert à montrer une idée, l'outil qui l'a créée la publie en un clic. Le choix d'un hébergement arrive avec les premiers utilisateurs : des données à protéger, une facture à prévoir.

Dès que l'application a des utilisateurs et que personne, dans l'équipe, n'a vocation à administrer un serveur, la réponse est le VPS géré : l'application tourne sur un serveur qui lui est réservé, avec sa base, ses tâches de fond et ses ressources, et l'hébergeur l'exploite pour vous. Une gestion proactive suit aussi l'application elle-même (erreurs, lenteurs, requêtes coûteuses, espace disque) et vous recommande la correction, que vous appliquez, vous ou votre assistant IA. Le développeur est parti ? Elle reprend l'existant tel qu'il est, migration comprise.

Une équipe qui administre elle-même tire le meilleur d'un serveur dont elle garde la main : le VPS Pro de Simafri comprend l'Assistance intégrale, un diagnostic du système jusqu'au code de l'application.

Changer d'hébergement sans repartir de zéro

Le choix d'aujourd'hui se révise demain, à condition de garder l'application portable :

• Le code dans un dépôt git à vous. Lovable le synchronise avec GitHub, d'où il se déploie ailleurs.
• La configuration dans des variables d'environnement, listées : clés d'API, adresse de la base, secrets.
• Une base de données standard (PostgreSQL, MySQL), qui s'exporte et se réimporte avec ses outils habituels.
• Les services propres à une plateforme repérés à l'avance (stockage de fichiers, tâches planifiées déclarées dans sa configuration) : ce sont eux qui se remplacent.

Next.js en donne un bon exemple : sa documentation indique qu'un serveur Node.js lancé par next build puis next start prend en charge toutes ses fonctionnalités, chez tout hébergeur qui fait tourner Node.js.