Chapitre 1.1 — De localhost à la prod
⏱️ TL;DR — En local, une seule personne (toi) utilise ton appli, sur une machine que tu contrôles, avec des outils de dev qui « pardonnent » tout. En production, ta machine est exposée à Internet, plusieurs personnes l’utilisent en même temps, elle doit rester debout sans toi, résister aux attaques, et survivre aux pannes et aux reboots. « Ça marche chez moi » n’est pas « c’est en prod ». Ce chapitre nomme précisément tout ce qui change — c’est la liste des problèmes que le reste du cours résout.
🎯 Objectifs
- Comprendre pourquoi le dev local cache la moitié des vrais problèmes.
- Lister les différences structurelles entre local et prod (exposition, concurrence, durée de vie, sécurité, données).
- Savoir reconnaître un « ça marche chez moi » et anticiper pourquoi ça cassera en prod.
« Ça marche chez moi » : le piège fondateur
Quand tu lances npm run dev, un serveur de développement démarre sur ton ordinateur. Il est conçu pour te faciliter la vie : il recharge à chaud, affiche les erreurs en clair, sert des fichiers non optimisés, et n’écoute que toi. C’est parfait pour coder — et trompeur pour juger si l’appli est « prête ».
Parce que ton portable te cache tout ce qui rend la prod difficile :
En local (npm run dev) | En production |
|---|---|
| Une seule personne : toi | Beaucoup d’utilisateurs en même temps |
Accessible sur localhost uniquement | Exposée à Internet, joignable par n’importe qui |
| Tu la relances à la main quand tu veux | Doit rester debout 24/7, redémarrer seule après un crash ou un reboot |
| Erreurs affichées, mode debug | Doit logger proprement sans fuiter d’infos sensibles |
| Pas d’attaquant | Attaquée en permanence (bots, scans, bruteforce) |
Secrets en clair dans .env local | Secrets à protéger et sortir du code |
| Données jetables | Données réelles à sauvegarder et à ne jamais perdre |
HTTP sur localhost, personne ne s’en soucie | HTTPS obligatoire (navigateurs, SEO, confiance) |
| Ta machine, tes règles | Machine partagée avec Internet, à durcir |
Chaque ligne de la colonne de droite est un chantier. Le déploiement, ce n’est pas « copier les fichiers sur un serveur » : c’est répondre à toute cette colonne.
Les cinq bascules à intégrer
1. L’exposition
En prod, ta machine a une adresse IP publique et écoute sur Internet. Dès la première minute, des robots la scannent : ils testent le port SSH, cherchent des mots de passe faibles, des failles connues. Ce n’est pas de la paranoïa, c’est un fait mesurable — on le verra dans les logs. D’où : pare-feu, SSH par clés, root désactivé, HTTPS. (Parties 4 et 5.)
2. La concurrence
En local, tu es seul. En prod, N visiteurs frappent en même temps. Ton app doit tenir la charge, et le serveur doit partager CPU, RAM et connexions entre tous. Un next dev mono-utilisateur ne suffit plus : il faut un build de production optimisé, servi en continu, éventuellement en plusieurs instances. (Parties 9 et 15.)
3. La durée de vie
Tu fermes ton terminal → ton npm run dev s’arrête. Inacceptable en prod. L’appli doit tourner détachée de ta session, redémarrer automatiquement si elle plante, et repartir toute seule si le serveur reboote (mise à jour du noyau, coupure électrique). C’est le rôle d’un gestionnaire de services comme systemd. (Partie 3.)
4. La sécurité et les secrets
En dev, ton .env traîne en clair, tu es en HTTP, tu es admin de ta machine. En prod : HTTPS partout, secrets hors du dépôt git et protégés, moindre privilège (on ne travaille pas en root), ports fermés sauf le strict nécessaire. La sécurité n’est pas une option qu’on ajoute à la fin — c’est une manière de construire.
5. Les données
En local, si tu casses ta base, tu la recrées d’un seed. En prod, la base contient les vraies données de tes utilisateurs. Les perdre, c’est parfois fermer boutique (et, avec des données personnelles, un problème RGPD). D’où : base sécurisée, sauvegardes régulières et surtout testées — une sauvegarde qu’on n’a jamais restaurée n’existe pas. (Parties 11 et 15.)
Le schéma mental : deux mondes
À gauche, le confort du dev. À droite, la réalité : plusieurs couches, chacune avec un rôle (filtrer, chiffrer, servir, stocker, sauvegarder, surveiller). Tout le cours consiste à construire la partie droite, couche par couche.
💡 Réflexe — Quand tu dis « c’est prêt », demande-toi : est-ce que ça survit à un reboot ? à 100 visiteurs ? à un bot qui scanne mon IP ? à la perte d’un disque ? Si tu ne sais pas répondre, ce n’est pas prêt — c’est local.
⚠️ Piège — Confondre accessible et en production. Ouvrir ton
next devsur0.0.0.0et donner ton IP à un ami, « ça marche » : le site s’affiche. Mais c’est en HTTP, sans redémarrage auto, sans pare-feu, en mode debug qui fuit tes erreurs, sans sauvegarde. C’est une démo fragile, pas une prod. Le jour où ça compte, ça tombe.
🔒 Sécurité — Le simple fait d’avoir une IP publique fait de toi une cible. Pas parce qu’on t’en veut : parce que des robots balaient Internet en continu à la recherche de machines mal configurées. La bonne nouvelle : les protections de base (clés SSH, root off, pare-feu, MàJ) éliminent l’écrasante majorité de ces attaques opportunistes. On les met en place dès la Partie 5.
🧭 Sur FormaCampus — FormaCampus, notre EdTech fil rouge, tournait jusqu’ici sur un PaaS :
git push, et « c’était en ligne ». Pratique, mais la facture grimpe, les données passent par un tiers (enjeu RGPD), et impossible d’y faire tourner un cron lourd ou un service maison. L’équipe décide de rapatrier la prod sur son propre VPS. Première étape avant de toucher à quoi que ce soit : accepter que « ça marchait sur Vercel » ne dit rien de « on sait opérer notre serveur ». Ce cours est leur (et ton) apprentissage.
Pourquoi apprendre ça plutôt que rester sur un PaaS ?
Question légitime : si Vercel « marche », pourquoi se compliquer la vie ? Réponses honnêtes, qu’on développera au chapitre 1.2 :
- Autonomie : tu n’es plus limité par ce que le PaaS autorise (services longue durée, WebSockets persistants, cron, binaires, bases sur la même machine).
- Coût : à partir d’un certain trafic ou de certains besoins, un VPS à quelques euros remplace des factures cloud qui explosent.
- Compréhension : savoir opérer un serveur fait de toi un meilleur dev, même si tu restes sur un PaaS — tu comprends enfin ce qui se passe « derrière ».
- Contrôle des données : tes données sur ta machine, dans la juridiction que tu choisis.
Ce n’est pas « VPS contre PaaS » de façon dogmatique. C’est savoir faire les deux et choisir en connaissance de cause.
✏️ Exercices
Exercice 1 — Traduis en chantiers. Un ami te dit : « Mon site Next.js marche en local, je veux le mettre en ligne pour de vrai. » Cite-lui cinq choses vraies en prod qui n’existent pas en local, et pour chacune, le risque si on l’ignore.
✅ Solution
Par exemple : (1) Exposition à Internet → sans pare-feu ni SSH durci, la machine se fait attaquer/compromettre. (2) Concurrence → sans build de prod servi en continu, ça rame ou ça tombe sous la charge. (3) Durée de vie → sans service (systemd), l’app s’arrête à la fermeture du terminal ou ne repart pas après un reboot. (4) HTTPS → sans TLS, les navigateurs alertent, les données transitent en clair, le SEO souffre. (5) Données → sans sauvegarde testée, une panne disque = perte définitive. On accepte aussi : secrets à protéger, logs à gérer, monitoring pour être prévenu d’une panne.
Exercice 2 — Démonte le « ça marche ». Tu lances next dev, tu l’ouvres sur 0.0.0.0, tu donnes ton IP publique à un client pour une démo. Le site s’affiche chez lui. Liste trois raisons pour lesquelles ce n’est pas une mise en production, même si « ça marche ».
✅ Solution
(1) C’est un serveur de dev (non optimisé, mode debug qui expose stack traces et détails internes, lent, mono-processus). (2) Aucune permanence : dès que tu fermes ton terminal ou éteins ta machine, tout s’arrête ; rien ne redémarre après un crash/reboot. (3) Aucune sécurité ni HTTPS : trafic en clair, pas de pare-feu, ta machine de dev exposée, aucune sauvegarde. C’est une démo jetable, pas une prod.
🧠 Quiz de révision
1. Cite trois différences structurelles entre le dev local et la production.
Au choix parmi : l’exposition (localhost vs Internet public), la concurrence (un seul utilisateur vs beaucoup en simultané), la durée de vie (relancé à la main vs 24/7 avec redémarrage auto), la sécurité (aucun attaquant vs attaques permanentes, HTTPS requis), les données (jetables vs réelles à sauvegarder).
2. Pourquoi le serveur de développement (npm run dev) ne convient-il pas en prod ?
npm run dev) ne convient-il pas en prod ?Il est optimisé pour le confort du dev, pas pour la performance ni la sécurité : non optimisé, mode debug qui fuit des infos, mono-utilisateur, et il s’arrête avec ta session. La prod exige un build de production servi en continu par un service qui survit aux crashs et aux reboots.
3. « Mon appli est accessible depuis Internet » suffit-il à dire qu’elle est en production ?
Non. Accessible ≠ en prod. Il manque potentiellement HTTPS, redémarrage automatique, pare-feu, gestion des secrets, sauvegardes et monitoring. L’accessibilité n’est qu’une des nombreuses exigences.
4. Pourquoi dit-on que la sécurité est un « fil », pas une étape ?
Parce qu’une machine exposée est attaquée dès la première minute : la sécurité doit être présente à chaque couche (accès SSH, pare-feu, HTTPS, moindre privilège, secrets, sauvegardes) et dès le départ. On ne « sécurise pas à la fin » un système construit sans elle.
5. Donne deux raisons légitimes de passer d’un PaaS à un VPS.
Par exemple : l’autonomie (débloquer ce que le PaaS interdit : services longue durée, cron, bases, WebSockets, contrôle total) et le coût (un VPS bon marché remplace des factures cloud élevées au-delà d’un certain usage). On accepte aussi : contrôle des données/juridiction, et la montée en compétence qui fait un meilleur dev.
Chapitre suivant : PaaS, VPS, cloud : le paysage — les options d’hébergement, leurs forces, leurs limites, et comment choisir.