← Web Dev
🌐

Déploiement & Production Web

Avancé
🧠Comprendre en lisant n'est pas savoir écrire.🧠Un module est fini quand tu peux le reproduire fenêtre fermée.🧠Écris le problème en français avant d'écrire du code.🧠Une question impossible cache trois questions faciles.🧠Retape le code à la main. Puis referme et réécris-le.🧠Essaie d'abord, cherche ensuite.🧠Cherche « comment on écrit ça », jamais « qu'est-ce que je dois faire ».🧠Pour comprendre du code, casse-le.⌨️Une fonction qui plante sur un cas limite n'est pas finie.⌨️Si un bloc a un nom clair, il mérite d'être une fonction.⌨️Savoir lire une erreur vaut plus que connaître dix méthodes.⌨️Diagnostiquer, c'est éliminer dans l'ordre — pas essayer au hasard.⌨️Une optimisation sans mesure avant/après est une croyance.🔍Regarde le fichier avant de le charger.🔍Une performance anormalement bonne est une hypothèse à réfuter.🔍Cette valeur existe-t-elle à l'instant où je dois prédire ?🔍fit sur le train, transform partout.🔍Un chiffre qu'on ne sait pas raconter est un chiffre qu'on n'a pas compris.🔍Un graphique sans question n'a rien à dire.🤖Un score d'entraînement parfait n'est jamais une bonne nouvelle.🤖Le jeu de test ne se regarde qu'une fois.🤖Plus tu essaies de configurations, plus ton meilleur score est optimiste.🤖Un seuil de décision est un arbitrage économique, pas un réglage technique.🤖Commence toujours par une baseline. Note son score.🤖Le meilleur modèle n'est pas le plus précis, c'est celui qu'on peut maintenir.🚀Un modèle en production n'est pas un livrable, c'est un système vivant.🚀Un secret publié est un secret compromis.🚀Pour chaque permission : que se passe-t-il si cette machine est compromise ?🚀Un post-mortem qui cherche un coupable ne produit aucune amélioration.🚀« Nous n'utilisons pas cette variable » n'est pas une garantie d'équité.🚀Rends l'arbitrage explicite et chiffré. Ne le tranche pas en silence.🚀Un résultat qu'on ne sait pas reproduire est une anecdote.

🎯 Objectifs d'apprentissage

À l'issue de ce module, tu seras capable de :

  • 01Déployer une application full stack avec une chaîne CI/CD
  • 02Gérer secrets et variables d'environnement sans jamais les versionner
  • 03Mettre en place supervision et alertes
  • 04Diagnostiquer un incident de production à partir des logs

Prérequis

Module Backend Node.js

📖 Lectures de référence

Sélection d'expert — les ressources gratuites sont signalées.

The Twelve-Factor App

Gratuit

Adam Wiggins

Gratuit, en français, et se lit en une heure. Les 12 principes que suivent toutes les applications cloud sérieuses.

Site Reliability Engineering

Gratuit

Google

Offert par Google. Comment on exploite réellement des services à grande échelle.

Déployer sur Vercel (Next.js) et Railway (Node.js)

⏱ 50 min

Les plateformes modernes rendent le déploiement simple — mais il faut connaître les bonnes pratiques.

Vercel — la plateforme officielle de Next.js

npm install -g vercel
vercel login
vercel                  # déploie le projet courant
vercel --prod           # déploiement en production

Configuration via vercel.json :

{
  "env": {
    "ANTHROPIC_API_KEY": "@anthropic-api-key"
  },
  "regions": ["iad1"],
  "rewrites": [
    { "source": "/api/(.*)", "destination": "/api/$1" }
  ]
}

Railway — backend Node.js + PostgreSQL
Railway déploie automatiquement depuis GitHub et peut provisionner une base PostgreSQL.

# Via railway CLI
npm install -g @railway/cli
railway login
railway init
railway up

Railway détecte automatiquement Node.js et lance npm start.

Variables d'environnement en production
Toutes les plateformes proposent un gestionnaire de secrets :
- Vercel : Project Settings → Environment Variables
- Railway : Variables tab
- AWS : Systems Manager Parameter Store ou Secrets Manager

Ne jamais faire :

# ❌ Committer un .env
git add .env  # JAMAIS

# ✅ .gitignore doit contenir .env*
echo ".env*" >> .gitignore

✍️ Exercices de la leçon

2 exercices

Fais-les dans l'ordre, dans un vrai fichier .py — pas dans ta tête. Ne déplie la correction qu'après avoir écrit quelque chose, même faux.

🔧

Exercice A — Mettre l'application en ligne

Application directe · Tu appliques ce que tu viens de lire.

Déploie ton application Next.js sur Vercel et ton API Node sur Railway :

  1. 1.le dépôt Git connecté, avec un déploiement automatique à chaque push sur main
  2. 2.les variables d'environnement configurées dans l'interface de la plateforme, jamais dans le dépôt
  3. 3.deux environnements distincts : preview (branches) et production (main), avec des secrets différents
  4. 4.vérifie qu'aucun secret n'est présent dans l'historique Git
  5. 5.teste que l'URL de preview et l'URL de production ne pointent pas sur la même base de données

Le point 5 est celui qu'on découvre le plus douloureusement.

🎯

Exercice B — Ça marche en local, ça casse en production

Page blanche · Aucun squelette : à toi de choisir la méthode.

Page blanche. Diagnostic à distance.

Ton application tourne parfaitement en local. Le déploiement échoue — ou pire, il réussit et l'application plante à l'ouverture.

Écris le protocole de diagnostic pour ces trois symptômes, dans l'ordre des causes les plus probables :

  1. 1.le build échoue sur la plateforme mais passe en local
  2. 2.le build réussit, mais l'application affiche une erreur 500 à l'ouverture
  3. 3.tout fonctionne en preview, et casse uniquement en production

Pour chaque symptôme : les causes classées par fréquence, la commande ou l'endroit qui permet de trancher, et le correctif.

Puis donne la commande qui reproduit localement les conditions de la plateforme — celle qui aurait évité la moitié de ces problèmes.

Indice sur le n° 1 : il existe une cause qui ne peut littéralement pas se produire sur un Mac ou sous Windows.

🤖

Question sur cette leçon ? Clique sur 💬 Demander au tuteur en bas à droite.