Pourquoi les devs pros abandonnent localhost:3000 pour de vrais domaines

Rien de tel que de voir son environnement local ressembler à du sérieux. Ça change tout.

La semaine dernière, j'ai présenté un outil interne à l'équipe. Le buzz n'était pas sur l'outil. Mais sur le domaine : "T'as payé combien pour www.internaltool.com ?" Certains pensaient à un achat pro pour l'occasion. D'autres à un accès VIP.

Faux. Tout tournait en local. Juste avec un vrai nom de domaine au lieu de localhost:3002.

Le piège de la simplicité moderne

Les frameworks comme Node.js ou Rails ont tout changé. Un npm start, et hop, ton app vit sur le port 3000. Zéro config. Zéro serveur.

Pratique ? Oui. Mais à quel prix ?

Avec trois projets en cours – ports 3000, 3001, 8080 –, ton cerveau cartographie les ports. Tu oublies ton code. Tu jongles avec des numéros.

En équipe, c'est le chaos. Pire : ton local ne ressemble plus à la prod. Les bugs s'y cachent.

La méthode old school qui cartonne toujours

Avant, les devs mappeaient des domaines custom en local. Via le fichier hosts et un reverse proxy comme Nginx.

Pas pour le style. Pour mirrorer la prod sur sa machine.

Résultat ? Des URLs clean : dev.monprojet.com, qa.monprojet.com. Tout pointe vers des ports locaux différents. Pro, clair, collaboratif. Et fidèle à la prod.

Guide complet : domaines custom en local

Étape 1 : Édite ton fichier hosts

Le hosts file ? Ton DNS perso. Il dit à ton PC : "myproject.com = moi, pas le web".

Où le trouver :

• macOS/Linux : /etc/hosts
• Windows : C:\Windows\System32\Drivers\etc\hosts

Ouvre avec sudo/admin. Ajoute :

127.0.0.1 myproject.com
127.0.0.1 dev.myproject.com
127.0.0.1 qa.myproject.com

Ton navigateur résout tout en local.

Étape 2 : Nginx en reverse proxy

myproject.com tape sur le port 80. Ton app ? Sur 3000. Échec.

Nginx écoute 80 et redirige.

Crée un fichier Nginx (dans /etc/nginx/sites-available/ sous Linux). Ajoute :

server {
    listen 80;
    server_name myproject.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name dev.myproject.com;

    location / {
        proxy_pass http://localhost:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name qa.myproject.com;

    location / {
        proxy_pass http://localhost:3002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Redémarre Nginx :

# macOS
brew services restart nginx

# Linux
sudo systemctl restart nginx

Tape myproject.com. Ça marche via ton port 3000.

Astuce WSL2

Sous WSL2, l'IP Linux diffère de Windows. Trouve-la :

wsl hostname -I

Genre 172.x.x.x. Mets-la dans le hosts Windows, pas 127.0.0.1.

Pourquoi ça change la donne

Cosmétique ? Non.

Parité env. Local = prod. Reverse proxy inclus. Bugs détectés tôt.

Équipe. "Va sur dev.internaltool.com" > "port 3000".

Clarté mentale. Des domaines, pas des ports.

Pro mindset. Au-delà du quick & dirty localhost.

Une astuce intemporelle

Ça date. Mais la commodité l'a éclipsée. Erreur.

Prends 20 minutes pour ça. Ton workflow s'envole. Focus sur le code qui compte.

Prochain "pourquoi pas localhost:3000 ?", réponds : "Parce que je bosse comme un pro.