5.4Déploiement & CI/CD (Render, Railway, VPS)
L'essentiel en 30 secondes
- Déployer = mettre en ligne : faire tourner l'app sur un serveur accessible — PaaS simple pour débuter, VPS pour le contrôle.
- CI/CD = livraison auto : à chaque push, tester (CI) puis déployer si tout passe (CD) — fini le déploiement manuel risqué.
- Secrets hors du code : config et secrets en variables d'environnement — jamais dans le code ni dans Git.
Mini-cas filé — Salim met en ligne à Alger
L'API conteneurisée de Salim tourne bien — mais seulement sur les postes de l'équipe à Alger. Il la déploie sur une plateforme : dépôt connecté, variables d'environnement renseignées sur la plateforme, HTTPS actif. Puis il ajoute un pipeline : à chaque push, les tests tournent, et le déploiement suit seulement s'ils passent. Dernier épisode des cas 5.1-5.3 — Salim livre un vrai service en ligne.
Dernier épisode des cas 5.1-5.3 — Salim boucle typage, performance et Docker avec la mise en production.
1. Déployer : PaaS ou VPS
Le déploiement fait tourner l'application sur un serveur accessible sur Internet (au lieu de localhost). Les plateformes PaaS simplifient tout : on connecte son dépôt Git, la plateforme construit, lance, gère serveur, HTTPS et mise à l'échelle de base — avec un niveau d'entrée accessible pour commencer — idéales pour débuter. À l'autre bout, un VPS (serveur virtuel loué) donne plus de contrôle mais plus de responsabilités : installer Node, configurer, sécuriser, gérer PM2, un reverse proxy, le HTTPS — plus complexe, mais formateur. Les grands clouds offrent une palette puissante avec une courbe d'apprentissage. Salim commence par une PaaS : son API est en ligne en suivant la documentation de la plateforme, sans administrer de serveur.
Recommandation : PaaS pour mettre ses projets en ligne vite, VPS pour apprendre l'administration ou gagner en contrôle, cloud pour les besoins avancés.
2. CI/CD et essentiels de production
Le CI/CD automatise le chemin code → production. L'intégration continue : à chaque push, un pipeline lance les tests et le linting pour attraper les problèmes tôt. Le déploiement continu : si tout passe, le code est déployé automatiquement. GitHub Actions crée ces pipelines. Bénéfices : automatisation (plus de gestes manuels fastidieux), fiabilité (rien de cassé ne part en production), rapidité (livrer souvent en confiance), traçabilité (chaque déploiement lié à un commit). Essentiels : variables d'environnement (config + secrets, jamais dans le code/Git), HTTPS, logs et monitoring, environnements séparés (dev/staging/prod). Salim écrit son premier pipeline : installer, tester, déployer si vert — c'est l'aboutissement, non seulement créer mais livrer.
Même simple, un pipeline change tout : les tests ne sont plus jamais « oubliés » avant un déploiement.
3. Choisir sans se tromper
Le compromis fondamental : simplicité contre contrôle. PaaS : simplicité extrême, moins de contrôle fin, dépendance à la plateforme — parfait pour débuter et beaucoup de projets. VPS : contrôle total et flexibilité, mais vous gérez tout (sécurité, mises à jour, sauvegardes) — formateur, plus exigeant. Pour un prototype ou un exercice, un déploiement manuel suffit ; dès qu'un projet est sérieux, déployé régulièrement ou en équipe, même un CI/CD simple apporte une vraie valeur. Salim compare les offres des hébergeurs (formules et limites évoluant souvent, il vérifie la documentation actuelle au moment de choisir) et fait valider le choix d'infrastructure sensible par sa DSI avant d'exposer des données réelles.
Dans tous les cas, les essentiels restent : secrets en variables d'environnement, HTTPS, logs et monitoring, environnements séparés.
🔎 Exemple concret — Le pipeline de Salim
À chaque push : installer, tester, déployer si vert.
# GitHub Actions (.github/workflows/ci.yml)
# à chaque push :
# npm install → npm test → déployer si vert
# secrets & config : variables d'environnement de la plateforme
# PaaS : construit depuis le dépôt, HTTPS autoLecture : le pipeline est la porte : rien de cassé ne passe.
Leçon : les secrets vivent dans l'environnement, jamais dans le code.
Vocabulaire de la section
- Déploiement
- Faire tourner l'app sur un serveur accessible sur Internet.
Exemple simple : L'API de Salim quitte localhost pour une adresse publique.
Ce que ce n'est pas : copier des fichiers à la main sans pipeline.
Réflexe : mon app est-elle accessible hors de mon poste ?
- PaaS
- Plateforme qui construit et héberge l'app depuis le dépôt Git.
Exemple simple : Salim connecte son dépôt, la plateforme gère serveur et HTTPS.
Ce que ce n'est pas : un serveur qu'on administre soi-même.
Réflexe : ai-je besoin de contrôle, ou de simplicité ?
- VPS
- Serveur virtuel loué qu'on administre soi-même.
Exemple simple : Salim y installerait Node, PM2 et le HTTPS lui-même.
Ce que ce n'est pas : une plateforme qui gère l'infrastructure.
Réflexe : suis-je prêt à assumer sécurité et maintenance ?
- CI/CD
- Pipeline qui teste à chaque push et déploie si tout passe.
Exemple simple : Le push de Salim déclenche tests puis mise en ligne auto.
Ce que ce n'est pas : un déploiement manuel à coups de commandes.
Réflexe : un push peut-il partir en prod sans tests ?
- Variables d'environnement
- Config et secrets fournis par l'environnement, hors du code.
Exemple simple : La clé de Salim vit sur la plateforme, jamais dans Git.
Ce que ce n'est pas : un secret écrit en dur dans le code.
Réflexe : un secret traîne-t-il dans mon dépôt ?
En pratique — Déployer et automatiser une application
- Déployez une application Node sur une plateforme PaaS simple : connectez votre dépôt Git, la plateforme construit et lance l'application, avec HTTPS.
- Configurez les variables d'environnement sur la plateforme (secrets, config) — jamais dans le code ni Git.
- Mettez en place un pipeline CI/CD (GitHub Actions) : à chaque push, lancer les tests et déployer automatiquement si tout passe.
- Assurez les essentiels de production : HTTPS, logs/monitoring, et des environnements séparés (dev/staging/prod).
Script prêt à dire — annoncer la mise en ligne
« Notre API est prête à sortir de localhost : je la déploie sur une plateforme — dépôt connecté, secrets en variables d'environnement, HTTPS actif. J'ajoute un pipeline simple : tests à chaque push, déploiement seulement si tout passe. Avant d'exposer des données réelles, je fais valider le choix d'infrastructure par la DSI. »
À dire au responsable pour faire valider la mise en ligne et le circuit DSI sur les données sensibles.
Modèle copier-coller — pipeline CI générique
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm install
- run: npm testSolo / petit budget
Salim seul : une PaaS + un pipeline qui teste à chaque push suffit — pas de serveur à administrer.
TPE / équipe réduite
Environnements dev et prod séparés, secrets sur la plateforme : chaque push testé avant mise en ligne.
PME à Alger
Salim fait valider l'hébergeur et les accès par la DSI à Alger avant d'exposer des données clients réelles.
Équipe qui démarre
Binôme : l'un écrit le pipeline, l'autre vérifie secrets et HTTPS ; revue avant le premier déploiement auto.
✓ Bonnes pratiques
- Débuter avec une plateforme PaaS : simple, HTTPS géré.
- Mettre config et secrets en variables d'environnement (jamais dans Git).
- Automatiser tests + déploiement avec un pipeline CI/CD (GitHub Actions).
✗ Pièges fréquents
- Mettre des secrets dans le code ou le dépôt Git.
- Déployer sans HTTPS (mots de passe et données en clair).
- Déployer manuellement et à l'aveugle (sans tests automatisés en amont).
Points clés à retenir
- DÉPLOIEMENT : faire tourner l'app sur un serveur accessible (au lieu de localhost). PaaS (simple) ou VPS/cloud (plus de contrôle).
- CI/CD (GitHub Actions) automatise code → production : CI (tester à chaque push), CD (déployer si tout passe). Automatisation, fiabilité, rapidité, traçabilité.
- Essentiels de production : VARIABLES D'ENVIRONNEMENT (config + secrets, jamais dans le code/Git), HTTPS, logs/monitoring, environnements séparés.
- C'est l'aboutissement du parcours : non seulement CRÉER une application, mais la LIVRER — un service réel, en ligne, fiable.
Défi 48h — appliquez demain
Déployez 1 app sur une plateforme (dépôt connecté + HTTPS) avec ses secrets en variables d'environnement : un push déclenche-t-il les tests ?
- Je peux expliquer CI vs CD en une phrase.
- Mon app est en ligne (HTTPS) sans secret dans Git.
- Je sais quand passer de PaaS à VPS.
Questions fréquentes
PaaS, VPS ou cloud : comment choisir où déployer mon application Node ?
Selon votre besoin et votre niveau. Les plateformes PaaS simplifient énormément : on connecte son dépôt Git, la plateforme construit et lance l'application, gère le serveur, le HTTPS et la mise à l'échelle de base — idéales pour débuter et pour beaucoup de projets. Un VPS (serveur virtuel loué) donne plus de contrôle mais plus de responsabilités : vous administrez tout (Node, PM2, reverse proxy, HTTPS) — plus complexe, mais formateur. Les grands clouds offrent une palette puissante avec une courbe d'apprentissage. Recommandation : commencez par une PaaS pour mettre vos projets en ligne ; passez au VPS pour apprendre l'administration ; explorez le cloud pour des besoins avancés. Comparez les offres au moment de choisir (elles évoluent) et faites valider par la DSI avant d'exposer des données sensibles.
Pourquoi mettre en place un CI/CD, et est-ce nécessaire pour de petits projets ?
Le CI/CD automatise le chemin du code vers la production : CI (à chaque push, le pipeline vérifie — tests, linting), CD (si tout passe, déploiement auto). Bénéfices : automatisation (fini le manuel fastidieux et risqué), fiabilité (rien de cassé ne part en production), rapidité (livrer souvent en confiance), traçabilité (chaque déploiement lié à un commit). Pour un prototype jetable, pas strictement nécessaire. Dès qu'un projet est sérieux, déployé régulièrement ou en équipe, même un pipeline simple apporte une vraie valeur. Commencez simple : installer, tester, déployer si tout passe.
Que fait un pipeline CI/CD ?