Comment déployer une application localhost publiquement sans VPS

Votre application tourne. Vous avez lancé le serveur de développement, ouvert http://localhost:3000, et elle fait ce qu'elle est censée faire. Puis quelqu'un vous demande un lien, et vous découvrez que l'URL affichée à l'écran ne veut rien dire pour personne d'autre que vous.

Il existe trois façons de donner une URL publique à une application localhost sans VPS, plus une option plus rapide quand l'autre personne est sur votre réseau local, et choisir entre elles n'est pas une question d'outil. C'est une question de durée pendant laquelle l'application doit rester joignable, et de savoir si elle peut tourner ailleurs que sur votre ordinateur portable. Voici chaque méthode, la commande qui donne une URL, et ce qui, précisément, fera cesser de fonctionner cette URL.

En bref

• Quelqu'un sur votre Wi-Fi doit la voir : liez le serveur de développement à toutes les interfaces réseau et communiquez votre IP locale. Prêt en quelques secondes, mort dès que votre visiteur quitte votre réseau.
• Il vous faut un lien que n'importe qui peut ouvrir, pour l'heure qui vient : lancez un tunnel (cloudflared, ngrok, localtunnel, localhost.run). URL HTTPS publique en une minute environ, aucun changement sur le routeur, et elle meurt avec le processus qui l'a lancée.
• Elle doit rester en ligne quand votre ordinateur portable est fermé : poussez l'application vers une offre d'hébergement gratuite. Cela découple l'application de votre ordinateur et introduit de nouvelles règles sur les cartes bancaires, l'usage commercial et la survie de vos données après un redémarrage.
• Votre application n'a besoin d'aucun code serveur au moment de la requête : compilez-la et placez la sortie statique sur un hébergeur statique. Elle peut rester en ligne sans votre ordinateur et n'a aucun processus applicatif à réveiller, tant que le compte et les limites d'utilisation de l'hébergeur le permettent.
• Un comportement par défaut à connaître : next dev et python -m http.server écoutent déjà sur toutes les interfaces réseau sans aucun drapeau. Si vous pensiez que votre serveur de développement était privé, limité à votre ordinateur, ce n'est pas le cas.

Quelle méthode convient à votre application

Trois de ces quatre méthodes donnent à votre application une URL publique sur Internet ; la première n'atteint que votre propre réseau, ce qui la rend à la fois la plus rapide et la plus limitée. Classez-les selon la durée de vie nécessaire de l'URL et le choix se fait presque tout seul.

Les lignes qui vous sont ouvertes dépendent de trois choses que vous pouvez vérifier dans votre propre projet :

• L'application a-t-elle besoin de votre code serveur au moment de la requête ? Une route Flask ou FastAPI, un point de terminaison server.js , ou toute logique serveur propre à la requête exige un hébergeur côté serveur. Du code serveur exécuté à la compilation n'exclut pas automatiquement un déploiement statique : les Server Components de Next.js peuvent s'exécuter pendant next build, et les GET Route Handlers statiques peuvent être prérendus. Si chaque requête à l'exécution peut être servie sous forme de ressources statiques ou envoyée directement du navigateur vers une API externe, la voie statique reste ouverte.
• Lit-elle ou écrit-elle un fichier qu'elle doit conserver ? Un fichier de base de données (.db, .sqlite), un dossier d'uploads, un fichier JSON qu'elle modifie. Si oui, vérifiez le modèle de stockage de l'hébergeur avant de déployer. Les services web gratuits de Render et les instances gratuites de Koyeb utilisent un stockage local éphémère, tandis que les Vercel Functions ont un système de fichiers en lecture seule avec un espace /tmp temporaire. Placez l'état persistant dans un volume durable, une base de données ou un stockage objet, au lieu de supposer que le disque local de l'application survivra.
• A-t-elle besoin d'un secret à l'exécution ? Une clé dans un fichier .env fonctionne telle quelle avec les deux premières méthodes, puisque l'application tourne encore sur votre machine. Avec les deux autres, vous la ressaisissez dans les paramètres d'environnement du fournisseur, et elle ne doit pas traîner dans le dépôt que vous poussez.

Partagez-la sur votre propre réseau

next dev écoute déjà sur toutes les interfaces réseau de votre machine (c'est tout ce que signifie 0.0.0.0 quand vous le voyez), et il en va de même pour python -m http.server. Aucun des deux n'a besoin d'un drapeau, donc le serveur de développement qui tourne en ce moment est probablement déjà accessible depuis votre téléphone sur le même Wi-Fi.

Next.js documente -H comme le moyen de changer ce nom d'hôte, avec une valeur par défaut de 0.0.0.0, et la documentation de Python indique que le module se lie à toutes les interfaces sauf si vous passez --bind 127.0.0.1. C'est donc le moyen le plus rapide de partager une application localhost : pas de compte, pas d'installation, pas de déploiement. Les autres serveurs de développement courants doivent être configurés explicitement.

# Already listening on all interfaces. Nothing to add.
next dev
python -m http.server 8000
streamlit run app.py

# Needs the flag.
npm run dev -- --host             # Vite
flask run --host=0.0.0.0
uvicorn main:app --host 0.0.0.0   # FastAPI

La documentation de Vite: server.host a pour valeur par défaut localhost, et accepte --host en ligne de commande ou server.host: '0.0.0.0' dans le fichier de configuration. Uvicorn utilise par défaut 127.0.0.1, ce qui couvre FastAPI puisque c'est lui qui l'exécute. Streamlit laisse server.address non défini, et sa référence de configuration précise que le définir restreint l'accès à cette seule adresse : non défini signifie sans restriction.

Il vous faut ensuite l'adresse à communiquer. C'est l'IP de votre machine sur le réseau local, et non localhost:

# macOS
ipconfig getifaddr en0

# Linux
hostname -I

# Windows (PowerShell)
ipconfig | findstr IPv4

Donnez à votre visiteur http://<that-address>:3000 et il est dedans. Le hic, c'est la forme du chemin tout entier : cette adresse ne veut rien dire en dehors de votre réseau. Dès qu'il passe sur un autre Wi-Fi, sur le réseau mobile ou chez lui, le lien est mort pour lui.

Remarque : si la commande s'exécute correctement et que l'autre appareil n'arrive toujours pas à se connecter, c'est le pare-feu du système, pas la commande, presque à chaque fois. La documentation du pare-feu d'Apple indique que macOS affiche une alerte pour une application que vous n'avez pas encore autorisée et refuse la connexion tant que vous n'agissez pas. Windows, lui, demande quel profil réseau s'applique, en gardant des règles distinctes pour les réseaux privés et publics . Choisissez Privé sur un réseau domestique ou de bureau. Jamais Public.

Mettez-la derrière un tunnel

Un tunnel est un petit programme qui tourne à côté de votre application et lui donne une adresse HTTPS publique. Une seule commande vous offre un tunnel gratuit vers localhost en une minute environ, et il vaut mieux savoir dès le départ que l'URL meurt à l'instant où cette commande s'arrête :

cloudflared tunnel --url http://localhost:3000

Rien ne change sur votre routeur, à cause du sens dans lequel la connexion circule. Votre machine ouvre une connexion sortante vers la périphérie du fournisseur, du même type que celle que votre navigateur ouvre pour charger n'importe quelle page, et le fournisseur la maintient ouverte et y renvoie les requêtes entrantes. Les ports entrants de votre côté restent fermés, ce qui explique que cela fonctionne sur le Wi-Fi d'un hôtel, sur un partage de connexion mobile et sur une connexion domestique dont vous ne contrôlez pas le routeur.

Remarque : ce dernier cas mérite une vérification de soixante secondes avant d'envisager plutôt une redirection de port. Ouvrez la page d'état de votre routeur, trouvez l'IP WAN qu'il indique, et comparez-la à votre véritable IP publique obtenue via n'importe quel service « quelle est mon IP ». Si l'IP WAN se trouve dans 100.64.0.0/10, le CGNAT est la cause probable. Si l'IP WAN et l'IP publique diffèrent simplement, vous savez qu'il y a une autre couche NAT en amont, mais il peut s'agir de CGNAT ou d'un double NAT ordinaire. Dans les deux cas, la redirection de port sur ce seul routeur risque de ne pas suffire. Cette plage est réservée par la RFC 6598 comme espace d'adressage partagé, c'est-à-dire ce que votre FAI vous attribue quand il n'a plus d'adresses.

Les options diffèrent surtout par ce qu'elles vous demandent d'abord.

Les tunnels rapides Cloudflare correspondent à la commande ci-dessus : pas de compte, pas de domaine, un sous-domaine aléatoire en trycloudflare.com . Cloudflare les plafonne à 200 requêtes en cours, avec des erreurs 429 au-delà, ne prend pas en charge les Server-Sent Events, et précise dans la même documentation que les tunnels gratuits sont destinés aux tests et au développement, pas au déploiement d'un site web en production.

ngrok exige d'abord une inscription, puis ngrok http 3000. L'offre gratuite actuelle vous donne 5 $ d'utilisation incluse en une seule fois, non renouvelée chaque mois, jusqu'à 3 points de terminaison en ligne, 1 Go de transfert, 20 000 requêtes HTTP/S, et une page d'avertissement intermédiaire que votre visiteur doit cliquer pour passer. Vous obtenez aussi un domaine de développement gratuit attribué automatiquement, que ngrok a annoncé en 2023 pour en finir avec la vieille plainte de l'URL qui change à chaque redémarrage.

localtunnel ne demande ni inscription ni installation au-delà de npx : npx localtunnel --port 3000. Vous obtenez un sous-domaine aléatoire, et le README est explicite : --subdomain demande un nom sans le garantir.

localhost.run n'installe rien, car il utilise le client SSH déjà fourni avec votre système : ssh -R 80:localhost:3000 localhost.run. Sa documentation précise qu'aucun téléchargement n'est nécessaire et qu'aucune création de compte n'est requise pour les domaines gratuits.

VS Code propose cela dans le panneau Ports, pratique si vous vivez déjà dans l'éditeur. Il exige une connexion GitHub ou Microsoft, et la valeur par défaut va vous piéger : un port redirigé est Privé, ce qui signifie que votre visiteur est invité à se connecter avec votre compte tant que vous n'avez pas basculé le port en Public. (Parfait pour un coéquipier. Inutile pour le client qui veut juste cliquer sur un lien.)

Tailscale Funnel fait la même chose, avec deux contraintes qui tranchent généralement : l'URL ne peut vivre que sur le domaine de votre propre tailnet, et il ne peut écouter que sur les ports 443, 8443 et 10000.

Quel que soit votre choix, soyez clair sur ce que vous avez distribué. Avec un tunnel public sans contrôle d'accès, tout ce que sert le serveur de développement est accessible à quiconque détient cette URL, y compris les routes que vous n'avez jamais liées et toute interface de débogage laissée active. Parfait pour une démo de quinze minutes. Beaucoup moins pour une URL collée dans un Discord public.

L'expiration vous prend de court parce qu'elle peut ressembler à une panne de l'application. La plupart des voies rapides présentées ici dépendent encore d'un logiciel de tunnel qui tourne sur votre ordinateur : arrêtez cloudflared, ngrok, localtunnel ou la session SSH de localhost.run et la redirection s'arrête. Tailscale Funnel fait exception quand vous le lancez avec --bg, qui garde la configuration Funnel active en arrière-plan et la restaure après un redémarrage. Aucun d'eux ne peut servir votre application locale quand l'ordinateur lui-même est hors ligne. Vous pouvez laisser un tunnel tourner pendant des jours, et il fonctionnera jusqu'à ce que l'écran se referme ou que vous atteigniez le plafond de requêtes.

Un tunnel est le bon outil pour une démo et le mauvais outil pour l'hébergement : sa disponibilité est celle de votre ordinateur portable.

Laissez l'application quitter votre machine

C'est la première voie où votre ordinateur portable cesse d'être indispensable, et la première où les conditions comptent plus que l'outillage. Ce qui y met fin n'est pas une horloge. C'est une mise en veille, une réinitialisation du système de fichiers, ou une offre qui décide que votre application n'est pas le genre de chose qu'elle veut sur une instance gratuite.

Les options ci-dessous vont des offres gratuites permanentes aux essais courts. Certaines peuvent garder une application en ligne indéfiniment dans leurs limites ; d'autres s'arrêtent après un essai à durée fixe ou exigent un compte payant pour le calcul. Vérifiez les règles de facturation, de mise en veille et de stockage avant de déployer.

Les conditions des offres gratuites ci-dessous ont été vérifiées sur la page de tarification ou de documentation de chaque fournisseur le 7 septembre 2026.

« Non indiqué » signifie que les pages du fournisseur ne répondent pas à la question pour leur offre gratuite. Considérez cela comme une inconnue plutôt que comme un oui ou un non.

Trois de ces lignes méritent un examen supplémentaire avant de commencer. Fly.io n'a pas d'offre gratuite permanente : son essai se termine après 2 heures-machine ou 7 jours. Koyeb inclut une instance gratuite, mais son parcours d'inscription et de facturation demande de l'attention avant de déployer. Hugging Face garde les Static Spaces gratuits, tandis que les nouveaux Spaces Gradio et Docker exigent un compte payant, hormis l'exception limitée de ZeroGPU. Railway n'a plus sa place dans cette liste d'avertissements : après son essai de 30 jours avec 5 $ de crédit, il passe désormais à une offre Free à 0 $ avec 1 $ de crédit ressources par mois.

Vient ensuite la question des données, là où une application qui fonctionne devient discrètement une application cassée. Les services web gratuits de Render tournent sur un système de fichiers éphémère, et sa documentation est sans détour : tout ce qui y est écrit, images téléversées et bases SQLite locales explicitement comprises, est perdu à chaque redéploiement, redémarrage et mise en veille. Les fonctions de Vercel tournent sur un système de fichiers en lecture seule avec un simple espace temporaire, donc un fichier SQLite écrit par votre application n'y est pas en sécurité non plus. Si votre application conserve son état dans un fichier, déplacez-le vers un stockage durable : une base de données hébergée, un stockage objet ou un volume persistant là où la plateforme en propose un.

La mise en veille mérite d'être ressentie avant de s'engager. Sur l'offre gratuite de Render, 15 minutes d'inactivité endorment le service, et la requête suivante le réveille en une minute environ, en affichant une page de chargement à la personne qui a cliqué sur votre lien. Pour un portfolio, un haussement d'épaules. Pour un client qui ouvre le lien pendant un appel, soixante mauvaises secondes.

PythonAnywhere a une version plus subtile du piège. Il n'y a pas de mise en veille pour inactivité, mais une application web gratuite expire au bout d'un mois et s'arrête si vous ne cliquez pas sur le lien de renouvellement que PythonAnywhere vous envoie par e-mail, et les comptes gratuits ont un accès Internet sortant restreint et n'atteignent qu'une liste blanche d'hôtes externes. Une application qui appelle une API hors de cette liste reste parfaitement en ligne et fait échouer chaque requête vers cette API non autorisée (une horreur à déboguer, puisque rien ne semble en panne nulle part).

Livrez-la comme site statique

Si rien de ce que fait votre application n'exige de code serveur au moment de la requête, un hébergeur statique est l'option la plus proche du « configurer et oublier » : elle peut rester en ligne sans votre ordinateur, et aucun processus applicatif n'attend d'être réveillé. Le compte et les limites d'utilisation de l'hébergeur s'appliquent toujours. Plus d'applications sont éligibles que vous ne le pensez, c'est pourquoi la première de ces trois questions mérite une réponse avant de supposer qu'il vous faut un hébergeur côté serveur.

La règle est plus étroite que « a-t-elle un backend ». Votre application est éligible si chaque requête qu'elle émet va soit vers vos propres fichiers statiques, soit directement du navigateur vers l'API de quelqu'un d'autre. Interroger Supabase ou une API publique depuis le navigateur ne pose pas de problème, à une réserve près : une clé placée dans le code du navigateur est une clé que vous avez publiée. Ce qui ferme la porte, c'est le besoin d'exécuter votre propre code sur un serveur à chaque requête.

Si elle est éligible, la marche à suivre est courte :

npm run build   # Vite writes to dist/, a Next.js static export writes to out/

Déployez ensuite cette sortie de build sur un hébergeur statique. Cloudflare Pages, Netlify et Vercel peuvent compiler à partir d'un dépôt connecté. GitHub Pages peut publier des fichiers statiques depuis une branche ou utiliser GitHub Actions pour lancer le build de votre framework et déployer le résultat généré.

GitHub Pages a des contraintes assez tranchées pour compter dès le départ. Statique uniquement, un seul site utilisateur ou organisation par compte, et des conditions d'utilisation précisant que ce n'est pas un hébergement gratuit pour une entreprise, un site d'e-commerce ou un SaaS commercial. Si votre application doit encaisser des paiements, cela l'exclut avant même de commencer.

Cette voie n'a pas d'expiration de processus applicatif. Elle continue de fonctionner tant que le compte d'hébergement reste actif et dans ses limites, et elle cesse de convenir dès que l'application a besoin de travail côté serveur au moment de la requête.

Là où s'arrêtent les voies gratuites

Les voies gratuites échouent à des endroits différents, pas toutes en même temps. Un hébergeur statique règle déjà la question de la disponibilité de l'ordinateur et vous donne une URL stable chez le fournisseur. Un hébergeur d'applications gratuit peut faire de même, et certains incluent désormais du stockage persistant. Un VPS commence à avoir du sens quand les exigences s'accumulent : votre propre processus côté serveur doit rester en ligne, il vous faut un stockage persistant prévisible, et les règles de ressources ou d'utilisation de l'offre gratuite ne conviennent plus.

Ce seuil mérite d'être respecté. Une démo n'est pas une raison d'acheter un serveur, pas plus qu'un projet statique à faible trafic. Restez sur un tunnel pour un partage de courte durée, restez sur un hébergeur statique tant que l'application est réellement statique, et restez sur un hébergeur d'applications gratuit tant que ses limites correspondent à ce que vous faites tourner.

Passez à un VPS quand il vous faut un serveur toujours allumé que vous contrôlez et que vous êtes prêt à assumer le travail opérationnel qui va avec. Notre VPS Linux est une option, et un VPS comparable chez un autre fournisseur peut faire le même travail. Dimensionnez le serveur pour l'application au lieu de supposer que la plus petite offre suffira.

Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.

Voir les plans Linux

Deux choses changent une fois ce pas franchi. Le flux de déploiement « push vers git » que vous offrait une plateforme d'hébergement n'est plus automatique. Vous pouvez le recréer avec un PaaS auto-hébergé comme Coolify ou Dokku, ou construire votre propre chaîne CI/CD, et dans les deux cas les mises à jour et la maintenance vous incombent désormais.

L'autre changement, c'est que la machine contient plus que l'application. Elle se fera un plaisir de faire tourner Code Server et Claude Code si vous préférez que votre éditeur y vive aussi, ce qui est soit un joli bonus, soit un tout nouveau week-end de travail, selon vous.

LIRE

Meilleures alternatives self-hosted à Heroku et Vercel : Coolify, Dokku et plus

Foire aux questions