Déploiement et hébergement d'apps fullstack

Tant que ton application tourne sur localhost:3000, elle n'existe que pour une seule personne : toi, sur cette machine, tant qu'elle est allumée. Déployer, c'est faire passer ton app de ce monde privé à un monde public : une vraie adresse, joignable depuis n'importe où, qui survit à la fermeture de ton laptop. C'est l'étape qui transforme un projet « qui marche chez moi » en un produit que d'autres peuvent réellement utiliser.

Mettre en ligne apporte cinq choses que localhost ne donnera jamais. La disponibilité : ton app répond 24h/24, sans dépendre de ta machine. La scalabilité : elle encaisse plusieurs utilisateur·ices en même temps, pas seulement toi. La sécurité : chiffrement HTTPS, isolation réseau, mises à jour de la plateforme. La collaboration : tu partages une URL de préproduction à un client ou à ton responsable produit, bien plus parlante qu'une capture d'écran. Et la mesure : sans production, pas de vraies métriques d'usage, donc aucune idée de ce qui fonctionne vraiment.

Le réflexe qui change tout, c'est de déployer tôt. Beaucoup de débutant·es gardent leur projet en local pendant des semaines, puis découvrent la veille de la livraison une cascade de problèmes de DNS, de certificat, de variables d'environnement ou de build. Fais l'inverse : mets en ligne une simple page « Hello world » dès le premier jour du projet. Tu affrontes ces frictions quand elles ne coûtent rien, ta chaîne de déploiement est prête, et il ne te restera plus qu'à pousser du code par-dessus. Déployer devient une non-événement plutôt qu'une épreuve.

• Disponibilité : 24/7, sans dépendre que ton laptop reste allumé
• Scalabilité : encaisser plus d'un·e utilisateur·ice à la fois
• Sécurité : HTTPS, isolation réseau, mises à jour automatiques
• Collaboration : partager une URL de staging à un client ou un PO
• Mesure : sans prod, pas de vraies métriques d'usage

Avant de choisir où déployer, il faut comprendre quoi. Une application fullstack n'est pas un bloc unique : c'est un assemblage de briques qui ont chacune leurs contraintes d'hébergement. Confondre ces briques, c'est risquer de payer pour un service inadapté ou de bloquer sur une fonctionnalité que ta plateforme ne supporte pas. Ce chapitre pose la carte du territoire.

On distingue en général six couches. Le frontend, soit statique (HTML/CSS/JS servis tels quels), soit rendu côté serveur (SSR) avec Next.js, Remix ou Astro. Le backend : les routes d'API, mais aussi les tâches de fond comme les jobs planifiés (cron) ou les workers de file d'attente. La base de données (Postgres, MySQL, MongoDB). Le cache (souvent Redis) pour les sessions, la limitation de débit ou les données chaudes. le stockage d'objets (S3, R2) pour les fichiers et images. Et les fonctions edge, exécutées au plus près de l'utilisateur·ice, sur le réseau de diffusion.

Un point mérite d'être martelé, car c'est une erreur classique de junior : en production, la base de données doit être managée (Neon, Supabase, PlanetScale…), pas installée à la main sur un serveur. Une base gérée te fournit les sauvegardes automatiques, les mises à jour de sécurité, la réplication et le chiffrement sans que tu aies à devenir administrateur système. Héberger soi-même sa base « pour économiser » finit presque toujours par coûter bien plus cher en temps et en incidents. Le schéma ci-dessous récapitule comment ces couches s'enchaînent, de l'utilisateur·ice jusqu'au stockage.

• Frontend : statique (HTML/CSS/JS), ou rendu serveur (SSR) avec Next.js, Remix, Astro
• Backend : API REST/GraphQL, jobs cron, workers de file d'attente
• Base de données : Postgres, MySQL, MongoDB. Managées en prod (Neon, Supabase, PlanetScale...)
• Cache : Redis pour sessions, rate limiting, données chaudes
• Storage : S3, R2, Supabase Storage pour fichiers et images
• Edge functions : exécution proche de l'utilisateur·ice (CDN)

Le schéma de référence

Utilisateur·ice
       │
       ▼
[ CDN / Edge ]  ← cache statique + edge functions
       │
       ▼
[ Frontend SSR ]  ← Next.js, Remix
       │
       ▼
[ API / Backend ]  ← routes API, jobs
       │
   ┌───┴───┐
   ▼       ▼
[ DB ]  [ Redis ]
   │
   └── [ Object Storage / S3 ]

Bonne nouvelle : tu n'as plus besoin de louer un serveur nu et de tout configurer à la main pour mettre une app en ligne. Les plateformes modernes (on parle de PaaS, Platform as a Service) s'occupent du système, du build, du certificat et du réseau à ta place ; tu pousses ton code, elles s'occupent du reste. Le vrai choix ne se joue donc pas sur « laquelle est la meilleure » dans l'absolu, mais sur l'adéquation entre ta stack, ton trafic et ton budget.

Une bonne façon de trancher est de partir de ta stack. Une application Next.js et tu veux zéro configuration ? Vercel, conçu par les auteurs du framework. Une app Node ou Python avec une base Postgres pour un premier produit ? Railway, qui te monte la base en quelques clics. Un besoin de connexions persistantes (WebSockets) ou de tâches longues ? Fly.io, qui fait tourner de vrais conteneurs proches des utilisateur·ices. Envie de regrouper plusieurs services dans une seule interface ? Render. Et le jour où tu passes à des millions de requêtes, tu regarderas du côté d'AWS ou GCP — mais surtout pas avant, car leur complexité n'a de sens qu'à cette échelle.

Deux réflexes de prudence pour finir. D'abord, méfie-toi des offres « gratuites » qui deviennent chères une fois le trafic là : lis la grille tarifaire au-delà du plan gratuit avant de t'engager (Heroku, longtemps la référence, a d'ailleurs supprimé son offre gratuite en 2022). Ensuite, garde un œil sur le verrouillage : plus tu utilises de fonctions propriétaires d'une plateforme, plus il sera coûteux d'en changer. Rester proche des standards (un conteneur Docker, des variables d'environnement classiques) te laisse une porte de sortie.

Plateformes recommandées

• Vercel : roi du Next.js, preview deploys automatiques, edge functions. Gratuit pour usage perso, premium au-delà.
• Netlify : très bon pour Astro, Remix, sites statiques. Edge functions.
• Railway : fullstack simple, DB Postgres incluse en quelques clics, idéal MVP
• Fly.io : containers proches des users, multi-régions, supporte WebSockets et long-running tâches
• Render : alternative équilibrée, web service + DB + cron jobs dans une seule interface
• AWS Amplify / GCP Cloud Run : quand tu scales sérieusement (10k+ users actifs)

Critères de choix rapides

• App Next.js et tu veux zéro config → Vercel
• App Node/Python + Postgres pour un MVP → Railway
• App qui a besoin de WebSockets ou de tâches longues → Fly.io
• Tu veux du multi-services dans une même UI → Render
• Tu scales à des millions de requêtes → AWS / GCP

app = "mon-api"
primary_region = "cdg"   # Paris

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  min_machines_running = 0

Ton app est en ligne, mais elle est joignable via une URL technique fournie par la plateforme. Pour une vraie adresse — tonsite.fr — il faut passer par le DNS, le système qui traduit les noms de domaine en adresses de serveurs. Vois-le comme l'annuaire téléphonique d'Internet : les humains retiennent des noms (tonsite.fr), les machines ont besoin d'adresses (une IP ou un autre nom), et le DNS fait la correspondance. Ça effraie beaucoup de débutant·es ; en réalité, cinq types d'enregistrements suffisent à tout comprendre.

Première étape, acheter le domaine chez un registrar. Privilégie ceux qui vendent à prix coûtant et sans mauvaises surprises (Cloudflare Registrar, OVH, Namecheap) et évite les acteurs réputés pour leurs pratiques agressives ou leurs frictions à la revente. Ensuite, tu configures la zone DNS avec quelques enregistrements. Les principaux : A pointe un nom vers une adresse IPv4, AAAA fait pareil en IPv6, CNAME pointe vers un autre nom (parfait pour les sous-domaines comme www ou staging), MX dirige les emails, et TXT sert aux vérifications de propriété et aux réglages anti-spam du mail (SPF, DKIM, DMARC).

Côté HTTPS, la bonne nouvelle est qu'il n'y a quasiment plus rien à faire. Toutes les plateformes modernes s'appuient sur Let's Encrypt pour générer un certificat gratuit dès que tu ajoutes ton domaine, et le renouvellent automatiquement tous les deux mois. Fini l'époque où l'on achetait et installait des certificats à la main. Dernier réflexe, la patience : quand tu modifies un enregistrement DNS, la propagation peut théoriquement prendre jusqu'à 24 heures (souvent quelques minutes en pratique avec Cloudflare). Si une erreur apparaît juste après un changement, attends avant de conclure au bug : c'est très rarement un vrai problème.

Acheter son domaine

• Cloudflare Registrar : prix coûtant, recommandé en 2025
• OVH : registrar français, bonne référence
• Namecheap : alternative connue, interface ok
• Évite GoDaddy (pratiques commerciales agressives) et Google Domains (racheté par Squarespace, friction)

Les enregistrements DNS principaux

• A : pointe un nom de domaine vers une IPv4
• AAAA : pareil mais IPv6
• CNAME : pointe vers un autre nom de domaine (sous-domaines)
• MX : pour le mail (Google Workspace, Mailgun...)
• TXT : vérification de propriété, SPF/DKIM/DMARC pour le mail

Type    Nom              Valeur
A       @                76.76.21.21
CNAME   www              cname.vercel-dns.com
CNAME   staging          cname.vercel-dns.com
TXT     @                v=spf1 include:_spf.mx.cloudflare.net ~all

Certificats HTTPS

Toutes les plateformes modernes (Vercel, Netlify, Railway, Fly.io) configurent Let's Encrypt automatiquement dès que tu ajoutes un domaine. Tu n'as plus rien à gérer côté certificat. C'est gratuit, renouvelé tous les 60 jours automatiquement.

S'il ne fallait retenir qu'une règle de tout ce cours, ce serait celle-ci : on ne commite jamais un secret dans Git. Une clé d'API, un mot de passe de base, un jeton d'accès n'ont rien à faire dans le code. Un secret poussé sur un dépôt, même supprimé cinq minutes plus tard, doit être considéré comme compromis : les robots qui scannent GitHub le trouvent en quelques secondes. La suite du chapitre montre comment organiser ça proprement pour ne jamais avoir à te poser la question dans l'urgence.

La base, c'est de séparer trois environnements. Le développement tourne sur ta machine, avec une base locale ou conteneurisée. La préproduction (staging) est une copie accessible à l'équipe et au responsable produit, soumise aux mêmes contraintes que la vraie prod (HTTPS, base managée) : c'est là qu'on valide avant de livrer. La production, enfin, est ce que voient les vrais utilisateur·ices. Chacun a ses propres valeurs de configuration, et surtout ses propres secrets — jamais partagés entre eux.

Techniquement, ces valeurs vivent dans des variables d'environnement. On commite un fichier .env.example qui liste les clés attendues sans leurs valeurs — un simple modèle qui documente ce dont l'app a besoin. Les vraies valeurs vont dans un .env.local ignoré par Git, et, en production, dans l'interface de la plateforme (Vercel, Railway, Fly.io) qui les stocke chiffrées. Attention à un piège spécifique à Next.js : toute variable préfixée NEXT_PUBLIC_ est injectée dans le code envoyé au navigateur et devient donc publique. Réserve ce préfixe aux URLs et identifiants non sensibles ; une clé secrète nommée ainsi fuite instantanément, qu'on l'affiche à l'écran ou non.

3 environnements minimum

• development : ta machine, DB locale ou containerisée
• staging : preview, accessible à l'équipe et au PO, mêmes contraintes que la prod (HTTPS, DB managée)
• production : ce que voient les vrais utilisateur·ices

Variables d'environnement

DATABASE_URL=postgres://user:pass@host:5432/db
NEXTAUTH_SECRET=
SENTRY_DSN=
NEXT_PUBLIC_API_URL=https://api.tonsite.fr
RESEND_API_KEY=

DATABASE_URL=postgres://anais:pass@localhost:5432/dev
NEXTAUTH_SECRET=valeur-aleatoire-32-bytes
SENTRY_DSN=https://xxx@yyy.ingest.sentry.io/zzz
NEXT_PUBLIC_API_URL=http://localhost:3000
RESEND_API_KEY=re_xxx

Où stocker les secrets

• Vercel / Railway / Fly.io : interface de gestion d'env vars intégrée, secrets chiffrés
• Doppler : SaaS dédié au secret management, intégrations CI/plateformes
• AWS Secrets Manager / GCP Secret Manager : quand tu scales
• 1Password CLI : pour les secrets manipulés en local par l'équipe

Le vieux problème « ça marche chez moi » vient d'une chose : ta machine et le serveur n'ont pas la même version de Node, les mêmes bibliothèques système, la même configuration. Un conteneur Docker résout ça en emballant ton application avec son environnement : le même conteneur tourne à l'identique sur ta machine, sur celle de ta collègue, en préproduction et en production. Tu ne déploies plus « du code en espérant que le serveur soit configuré comme il faut », tu déploies une boîte qui contient déjà tout ce dont elle a besoin.

La bonne pratique pour construire cette boîte, c'est le build multi-étapes (multi-stage), illustré ci-dessous. L'idée : une première étape installe toutes les dépendances et compile l'application ; une seconde étape ne récupère que le résultat compilé et les dépendances strictement nécessaires à l'exécution. Résultat, l'image finale est bien plus légère — elle ne trimballe pas les outils de build — donc plus rapide à transférer, à démarrer et plus sûre car sa surface d'attaque est réduite. On y ajoute des réflexes de sécurité comme exécuter le processus avec un utilisateur non-root.

Dernière brique : l'automatisation du déploiement, ce qu'on appelle CI/CD. Plutôt que de déployer à la main, tu décris un enchaînement — à chaque push sur main, on installe, on teste, et si tout est vert, on déploie — qui s'exécute tout seul (par exemple via GitHub Actions). Le déploiement devient fiable et répétable, sans geste manuel oublié. À noter : si tu déploies sur Vercel ou Netlify, tu n'as même pas besoin de rédiger de Dockerfile ni de pipeline — la plateforme détecte ton framework, build et déploie à chaque push. Docker et une CI explicite deviennent utiles quand tu veux davantage de contrôle ou héberger ailleurs.

Dockerfile multi-stage pour Next.js

# Stage 1 : build
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2 : runtime minimal
FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/.next ./.next
COPY --from=build /app/public ./public
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev
USER node
EXPOSE 3000
CMD ["npm", "start"]

Déploiement automatique via GitHub Actions

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm test
      - name: Deploy to Fly.io
        run: flyctl deploy --remote-only
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

Une application en production sans observabilité, c'est piloter les yeux fermés. Le jour où un·e utilisateur·ice signale « ça ne marche pas », tu dois pouvoir savoir quoi, quand et pourquoi — sinon tu répares à l'aveugle. L'observabilité repose sur trois couches complémentaires : les logs (le récit détaillé de ce qui se passe), les métriques et le suivi d'erreurs (les tendances et les incidents), et les alertes (être prévenu·e avant tes utilisateur·ices). On les branche dès la mise en prod, pas « plus tard ».

Première couche, les logs structurés. Oublie le console.log sauvage : en production, on utilise un logger comme Pino qui produit du JSON exploitable. La différence est énorme — au lieu d'une bouillie de texte, tu obtiens des événements filtrables et agrégeables (« montre-moi toutes les erreurs de paiement de l'utilisateur 42 »). Ces logs sont ensuite centralisés dans un outil (Logtail, Datadog, ou les logs intégrés de ta plateforme) où tu peux chercher, corréler et déclencher des alertes.

Deuxième couche, le suivi des erreurs avec un outil comme Sentry. Il capture automatiquement chaque exception, côté front comme back, avec sa trace complète, les source maps pour retrouver le code d'origine, et le contexte (utilisateur, URL, navigateur). C'est la toute première chose à brancher en prod. Troisième couche, la surveillance de disponibilité : un service externe (UptimeRobot, BetterStack) qui interroge régulièrement une route /api/health et t'alerte si l'app ne répond plus. Cette route de health check vérifie les dépendances vitales — la base, le cache — et permet aussi à ta plateforme de router le trafic loin d'une instance malade. Le scénario ci-dessous te fait dérouler exactement ce réflexe « je lis les logs avant tout ».

Logs structurés

Pas de console.log sauvage en prod. Utilise un logger comme Pino qui sort du JSON structuré : tu peux ensuite filtrer, agréger, alerter sur ces logs dans un outil centralisé (Logtail, Datadog, Vercel Logs).

import pino from 'pino';

const logger = pino({
  level: process.env.LOG_LEVEL ?? 'info',
});

logger.info({ userId: 42, action: 'login' }, 'User logged in');
logger.error({ err, orderId }, 'Order processing failed');

Error tracking : Sentry

// Installation automatique pour Next.js
// npx @sentry/wizard@latest -i nextjs

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 0.2,           // 20% des requêtes tracées
  environment: process.env.NODE_ENV,
});

Sentry capture les erreurs front et back avec la stack trace complète, les source maps pour voir le code original, et le contexte (user, URL, navigateur). C'est la première chose à brancher en prod.

Uptime monitoring

• UptimeRobot : 50 checks gratuits, alerte par email/Slack
• BetterStack : plus moderne, page de statut publique, intégrations PagerDuty
• Vercel/Fly.io intégré : analytics et health checks de base

Endpoint de health check

import { NextResponse } from 'next/server';
import { db } from '@/lib/db';

export async function GET() {
  try {
    await db.$queryRaw`SELECT 1`;
    return NextResponse.json({ status: 'ok' });
  } catch (err) {
    return NextResponse.json({ status: 'ko' }, { status: 503 });
  }
}

La performance n'est pas un luxe cosmétique : un site lent perd des utilisateur·ices, du référencement et des conversions, chiffres à l'appui. La bonne nouvelle, c'est qu'une poignée de réflexes couvre l'essentiel, sans expertise pointue. Le premier levier est géographique : un CDN (réseau de diffusion de contenu) sert tes fichiers statiques depuis un nœud proche de chaque visiteur. Une personne à Tokyo récupère tes assets depuis Tokyo, pas depuis ton serveur en Europe — la latence est divisée par cinq ou dix. Vercel l'intègre nativement ; Cloudflare, gratuit, se pose devant n'importe quel hébergeur.

Le deuxième levier est le cache HTTP. Plutôt que de recalculer la même réponse à chaque requête, tu dis au CDN de la garder quelques secondes ou minutes. La combinaison la plus utile, montrée ci-dessous, associe une durée de cache courte à la stratégie stale-while-revalidate : pendant un moment après l'expiration, on sert la version un peu périmée immédiatement tout en la rafraîchissant en arrière-plan. L'utilisateur·ice n'attend jamais, et ton serveur travaille beaucoup moins. Troisième levier, les images, souvent le plus gros poids d'une page : un composant comme next/image génère automatiquement les formats modernes (AVIF, WebP) et diffère le chargement des images hors écran.

Reste la résilience : accepter qu'un déploiement casse un jour, et pouvoir revenir en arrière en un clic. Garde toujours la version précédente déployable sans effort (sur Vercel, « Promote to Production » sur un ancien déploiement ; sur Fly.io, la liste des releases), et surtout des sauvegardes de base automatiques et testées — une sauvegarde qu'on n'a jamais essayé de restaurer n'en est pas vraiment une. Le pattern qui résume tout : déploie souvent, en petites bouchées. Plus tes déploiements sont petits et fréquents, moins chacun est risqué, et plus vite tu reviens en arrière si quelque chose dérape. La check-list ci-dessous rassemble les points à cocher avant chaque mise en production.

CDN devant le front

• Vercel Edge : intégré, sans config
• Cloudflare : gratuit, à mettre devant n'importe quel hébergeur
• Fastly : pour les grosses charges

Cache HTTP

// app/api/products/route.ts
export async function GET() {
  const products = await fetchProducts();

  return Response.json(products, {
    headers: {
      'Cache-Control': 's-maxage=60, stale-while-revalidate=300',
    },
  });
}

s-maxage=60 : caché 60 secondes côté CDN. stale-while-revalidate=300 : pendant 5 minutes après expiration, on sert la version stale en arrière-plan le temps de rafraîchir. UX rapide, charge serveur réduite.

Images optimisées

// Avec next/image, formats AVIF / WebP automatiques, lazy loading natif
import Image from 'next/image';

<Image
  src="/portrait.jpg"
  alt="Anaïs"
  width={400}
  height={400}
  loading="lazy"
/>

Résilience : rollback en 1 clic

• Toujours garder la version N-1 déployable sans effort
• Sur Vercel : onglet Deployments → bouton Promote to Production sur l'ancien déploiement
• Sur Fly.io : flyctl releases + flyctl deploy --image <ancienne-image>
• Backups DB automatiques et testés (restaurer pour vérifier que ça marche)