Question 1Parmi les trois étapes du déploiement, laquelle réunit app.js et les fichiers dont il a besoin dans une forme que le serveur public sait exécuter ?
Déploiement et variables d'environnement — de ce qui marche chez toi à la mise en ligne
Cet article fait partie du cours Les bases de l'informatique, qui construit depuis zéro les connaissances informatiques pratiques indispensables pour programmer et faire du vibe coding.
Quand quelque chose marche chez toi mais plus une fois publié, la cause est en dehors du code. Des schémas montrent les trois étapes du build, de la mise en place et de la mise en ligne, ainsi que les variables d'environnement qui changent de valeur selon l'environnement.
Cet article traite du déploiement, la suite d'étapes qui mène d'une application qui tourne chez toi à une application publiée, et des variables d'environnement qui changent de valeur selon la destination.
Le même app.js tourne à deux endroits : ton ordinateur et le serveur public.
Quand quelque chose marche chez toi mais pas sur le serveur public, la cause est en dehors du code.
C'est la différence entre ces deux endroits qui explique que ça ne marche plus une fois publié.
Le déploiement se compose de trois étapes : build, mise en place et mise en ligne
Le déploiement, c'est le travail qui consiste à poser l'application sur un serveur public pour que tout le monde puisse l'utiliser, et il se compose de trois étapes : le build, la mise en place et la mise en ligne.
La première étape est le build — réunir app.js et les fichiers dont il a besoin dans une forme que le serveur public sait exécuter — et l'ensemble de fichiers obtenu est l'artefact (build output).
Les fichiers de configuration utilisés uniquement chez toi restent hors de l'artefact et demeurent sur ton ordinateur.
Ce qui arrive sur le serveur public, c'est uniquement l'artefact assemblé.
Revenir à l'artefact précédent, c'est le rollback.
Le mot deploy désigne parfois la seule mise en place, parfois les trois étapes.
Tu rencontreras aussi le terme CI/CD (Continuous Integration / Continuous Delivery : le mécanisme qui exécute automatiquement ces trois étapes à chaque enregistrement du code), mais seule l'automatisation change, les étapes restent les mêmes.
Le déploiement est le nom donné à trois travaux réunis
Déployer, c'est enchaîner trois choses : réunir, envoyer, accepter.
Réunir, c'est le build ; envoyer et démarrer, c'est la mise en place ; accepter les demandes sur l'URL, c'est la mise en ligne. Les fichiers de configuration utilisés uniquement chez toi n'entrent pas dans ce qui est réuni, donc ils n'arrivent jamais sur le serveur public.
Environnement de développement et environnement de production — même code, mais ce qui l'entoure diffère
Si le fichier app.js qui tournait chez toi ne tourne pas sur le serveur public, ce n'est pas parce que le code a changé.
C'est parce que l'environnement — l'ensemble formé par l'ordinateur, l'OS, l'environnement d'exécution, la base de données et les valeurs de configuration réunis pour faire tourner app.js — est différent.
Dans l'article « Qu'est-ce qu'un environnement de développement », l'environnement de développement est une combinaison d'outils ; ici, c'est l'endroit où tu fais tourner les choses avec ces outils.
Deux environnements, un seul app.js
- Le fichier app.js exécuté est le même dans les deux environnements
Développement — ton ordinateur
- node que tu as installé
- Une base de données sur le même ordinateur
- Un réglage qui affiche le détail des erreurs à l'écran
Production — le serveur public
- node installé sur le serveur
- Une base de données sur un autre serveur
- Un réglage qui garde les erreurs hors de l'écran et dans les logs
Le cadre extérieur contient deux environnements, et le fichier app.js qu'ils exécutent est le même.
Seul le code est identique : l'URL que tu ouvres, l'emplacement de la base de données et la clé API sont tous différents.
| Hypothèse valable chez toi | Sur le serveur public | Ce qui arrive une fois publié |
|---|---|---|
| Se connecte à localhost:5432 | Aucune base de données de ce nom | Erreur à l'enregistrement |
| La clé API est une clé de test | Les clés de test ne passent pas | Le service externe refuse |
| Les erreurs s'affichent à l'écran | Elles apparaissent telles quelles à l'écran de l'utilisateur | Le détail devient visible |
| Le contenu de app.js | Le même app.js | Tourne tel quel |
Les trois premières lignes sont des hypothèses qui ne tenaient que chez toi.
Quand ça ne marche plus après publication, soupçonne l'extérieur avant le code.
Si tu te connectes au serveur public pour corriger l'artefact ou la configuration à la main, le déploiement suivant les remplace et tes corrections disparaissent.
Corrige le fichier app.js de l'environnement de développement, puis déploie une nouvelle fois.
Seul le code est identique
L'environnement, c'est tout ce qui est réuni autour de app.js pour qu'il puisse tourner.
Ton ordinateur est l'environnement de développement et le serveur public l'environnement de production ; même quand les deux côtés ont des éléments de même rôle, l'adresse de connexion et les clés n'ont pas les mêmes valeurs, donc quand ça ne marche pas après la publication, commence par vérifier cet extérieur.
Les variables d'environnement changent les valeurs selon l'environnement, sans toucher au code
Placer la valeur en dehors du code et ne laisser au code que le nom à lire, c'est ce qu'est une variable d'environnement — une valeur définie en dehors du programme et lue par son nom au moment de l'exécution.
Dans app.js, tu n'écris que le nom ; chez toi, tu écris la valeur dans .env (un fichier qui aligne les noms et les valeurs des variables d'environnement).
Ton ordinateur (développement)
Le dossier my-app
- app.js — tu n'écris que le nom DATABASE_URL
- .env — tu écris la valeur, DATABASE_URL=localhost:5432
- .env reste hors de l'artefact et hors de Git
Serveur public (production)
Dossier d'artefact
- app.js — arrive avec le seul nom écrit dedans
Réglages du déploiement
- Tu enregistres DATABASE_URL=db.example.com
- Une fois démarré, app.js lit cette valeur par son nom
Ton .env local n'est lu qu'à l'intérieur de l'ordinateur où tu l'as posé.
Comme .env contient des clés API, il n'est pas enregistré dans Git, et il n'est pas non plus dans l'artefact, donc il n'arrive jamais dans l'environnement de production.
Quand un guide dit « configure les variables d'environnement de production », il s'agit d'enregistrer les mêmes noms du côté du serveur public.
| Lieu de démarrage | D'où vient la valeur | Valeur de DATABASE_URL | Résultat de la connexion |
|---|---|---|---|
| Ton ordinateur | Ton .env local | localhost:5432 | Vers la base de données locale |
| Serveur public, enregistré | Réglages du déploiement | db.example.com | Vers la base de données de production |
| Serveur public, oubli d'enregistrement | Nulle part | Reste vide | Connexion impossible, arrêt sur erreur |
Avec le même app.js, la valeur lue change selon le lieu de démarrage.
La valeur est lue au démarrage, donc après avoir changé une valeur, redémarre.
Ce qui tourne dans le cadre de gauche et dans celui de droite, c'est le même app.js.
La seule différence, ce sont les valeurs placées à l'extérieur.
Le nom dans le code, la valeur dans l'environnement
Une variable d'environnement, c'est une valeur placée en dehors du code et appelée par son nom.
Chez toi tu l'écris dans un fichier nommé .env, et sur le serveur public tu enregistres le même nom comme réglage de cet endroit, donc quand ça ne marche pas après la publication, regarde d'abord si tu n'as pas oublié cet enregistrement.
Les secrets vont uniquement dans les variables d'environnement, jamais dans le code source ni dans l'artefact
Parmi les valeurs placées dans les variables d'environnement, celles qui demandent le plus d'attention sont les secrets (secret : une chaîne qui permet à quelqu'un d'autre de se faire passer pour toi s'il en prend connaissance), au premier rang desquels les clés API et les mots de passe.
Les variables d'environnement lues par le frontend voient leur valeur inscrite dans l'artefact au moment du build.
La valeur inscrite arrive telle quelle sur l'appareil de qui ouvre l'URL.
Place les secrets uniquement dans les variables d'environnement de production, qui restent hors de l'artefact, et enregistre-les dans l'écran de configuration de la cible de déploiement.
La valeur enregistrée n'entre pas dans l'artefact, et le serveur public la transmet quand il démarre app.js.
Si tu oublies l'enregistrement, ça démarre avec le nom présent mais sans valeur.
La valeur enregistrée n'existe que du côté du serveur public, et elle n'est recopiée ni dans l'artefact ni dans ton .env local.
Une fois publié, la valeur elle-même n'existe qu'à un seul endroit.
Serveur public
Variables de prod
- API_KEY contient la valeur de production
- Seuls app.js une fois démarré et les personnes qui peuvent intervenir sur le serveur peuvent la lire
Dossier d'artefact
- app.js ne contient que le nom API_KEY
- La valeur elle-même n'y est pas écrite
Appareil utilisateur
- Seuls le HTML et le JavaScript de l'écran arrivent
- Aucune valeur secrète n'y figure
La valeur n'est que dans les variables d'environnement de production, ni dans l'artefact ni sur l'appareil de l'utilisateur.
Combien de personnes peuvent lire un emplacement donné est traité dans l'article « Les points à surveiller en sécurité ».
Un seul endroit pour la valeur
Un secret, c'est une chaîne que d'autres peuvent utiliser s'ils en prennent connaissance.
Écrit dans le code, il est réuni par le build et livré jusqu'à l'appareil de l'utilisateur, donc au lieu d'écrire la valeur, enregistre-la comme réglage du serveur public et n'écris que le nom dans le code.
QUIZ
Vérification des connaissances
Répondez à chaque question une par une.
Question 2my-app tournait chez toi, mais après publication il s'est arrêté sur une erreur. Quelle cause donnée dans cet article est correcte ?
Question 3Quel emplacement pour les secrets comme les clés API et les mots de passe de base de données correspond à ce que décrit cet article ?