Mettre son site en ligne
Variables d'environnement, aperçus par branche, et la liste de ce qu'on ne commite jamais.
Le site marche en local. Il reste à le rendre visible, et c'est le moment où trois choses différentes se mélangent : publier des fichiers, gérer les valeurs de configuration qui changent selon l'environnement, et ne pas envoyer de secret dans un dépôt.
La première est simple aujourd'hui. La deuxième est la source de la moitié des « ça marche chez moi ». La troisième est celle qui coûte cher, parce qu'une clé publiée dans un dépôt Git y reste, même après suppression : elle vit dans l'historique.
Ce guide suit cet ordre : sécuriser d'abord, publier ensuite, puis se donner un aperçu par branche pour ne plus jamais tester en production.
Avant de commencer
- Un projet qui se construit sans erreur en local
- Un dépôt Git, poussé sur une forge (GitHub, GitLab)
- Un compte chez un hébergeur qui déploie depuis Git
1Vérifier ce qui est déjà parti
Avant tout le reste. Si un secret est déjà dans l'historique, aucune correction de configuration ne le rattrapera.
Cherche dans l'historique Git complet toute chaine ressemblant a une cle
d'API, un jeton ou un mot de passe : sk-, ghp_, AKIA, xoxb-, PRIVATE KEY,
ainsi que les affectations de variables nommees SECRET, TOKEN, PASSWORD,
KEY. Donne-moi le commit, le fichier et la ligne. Ne modifie rien.
Si quelque chose remonte, la seule réponse correcte est de révoquer et régénérer la clé chez le fournisseur. Réécrire l'historique est possible, mais il faut supposer que la valeur a été vue : dans le doute, elle est brûlée.
Retirer un fichier déjà suivi
Ajouter un fichier à .gitignore ne le retire pas du suivi s'il est déjà
commité. Il faut git rm --cached chemin/du/fichier puis commiter, et
seulement ensuite le .gitignore fait effet. Et cela ne l'efface pas de
l'historique passé.
2Trier ce qui est public et ce qui ne l'est pas
Une règle qui évite la plupart des accidents : tout ce qui est intégré au code envoyé au navigateur est public, quel que soit son nom.
Beaucoup d'outils rendent cette frontière explicite par un préfixe. Dans
Next.js, par exemple, seules les variables préfixées NEXT_PUBLIC_ sont
disponibles côté navigateur : leur valeur est remplacée en dur dans le paquet
JavaScript au moment de la construction. Les autres restent côté serveur.
Deux conséquences à retenir :
- Ne préfixe jamais un secret. Une clé privée nommée
NEXT_PUBLIC_API_KEYest lisible par n'importe quel visiteur dans le code source de la page. - Une valeur publique est figée à la construction. Changer la variable après coup n'a aucun effet tant que le site n'est pas reconstruit.
Où vivent les valeurs en local
La convention la plus répandue est un fichier .env.local à la racine, avec
des paires CLE=valeur. Le modèle par défaut de create-next-app ajoute les
fichiers .env au .gitignore : vérifie que c'est bien le cas chez toi, et
ne le retire pas.
3Déclarer les variables chez l'hébergeur
Les valeurs de production ne vivent pas dans le dépôt, elles vivent dans les réglages du projet chez l'hébergeur. Chez Vercel, chaque variable est associée à un ou plusieurs environnements :
| Environnement | Quand il s'applique |
|---|---|
| Production | Déploiement issu de la branche de production, en général main |
| Preview | Déploiement issu de toute autre branche |
| Development | Exécution locale, valeurs récupérables avec vercel env pull |
Les variables de l'environnement Preview peuvent viser toutes les branches non production, ou une branche précise, auquel cas la valeur spécifique à la branche l'emporte.
Un point qui surprend souvent : une modification de variable ne s'applique pas aux déploiements déjà faits. Elle prend effet au déploiement suivant. Si tu changes une valeur et que rien ne bouge, c'est presque toujours ça.
4Publier, et se donner un aperçu par branche
Le mécanisme est le même chez la plupart des hébergeurs modernes : tu connectes le dépôt, tu pousses, il construit et met en ligne.
Ce qui change vraiment ta façon de travailler, c'est l'aperçu par branche. Chez Vercel, tout envoi sur une branche qui n'est pas la branche de production crée un déploiement d'aperçu, avec sa propre URL. Tu obtiens :
- Une URL à envoyer pour relecture, sans toucher au site en ligne.
- Un endroit pour tester une migration de configuration en conditions réelles.
- Un retour en arrière trivial : la production n'a jamais bougé.
La discipline qui va avec est simple. La branche de production ne reçoit que ce qui a été vu sur un aperçu.
Ouvre l'URL d'apercu [URL]. Compare-la a la production [URL_PROD] : liste
les differences visibles sur la page d'accueil, en 1440 et en 390 px de
large. Signale toute erreur dans la console du navigateur.
5La liste avant chaque mise en ligne
| Vérification | Comment |
|---|---|
| La construction passe | Lancer la commande de build en local, pas seulement le serveur de développement |
| Aucun secret dans le dépôt | Le prompt de l'étape 1, relancé |
| Les variables sont déclarées pour le bon environnement | Regarder les réglages du projet |
| Les liens internes ne pointent pas vers localhost | Chercher localhost dans le code |
| Les pages d'erreur existent | Ouvrir une URL inexistante |
| Le site est lisible sans JavaScript | Regarder le HTML renvoyé par le serveur |
Le build local, pas le serveur de développement
Le mode développement est tolérant : il ignore des erreurs de typage, il recharge à chaud, il ne fait pas les mêmes optimisations. Lance la commande de construction complète avant de pousser. C'est trente secondes contre un déploiement raté.
Ce qu'on ne commite jamais
- Les fichiers
.envet leurs variantes, sauf un.env.examplequi ne contient que les noms des variables et aucune valeur. - Les clés privées, certificats, fichiers de service, sauvegardes de base de données.
- Les dossiers de dépendances et de sortie de construction.
- Les fichiers de configuration locale propres à ta machine.
Un .env.example versionné, listant les noms attendus avec une valeur vide, est
le meilleur compromis : la personne suivante sait ce qu'il faut renseigner, sans
que rien de sensible ne circule.
Quelques prompts pour aller plus loin
| Objectif | Prompt à adapter |
|---|---|
| Chasse aux secrets | Cherche dans l'historique Git complet les chaines ressemblant a des cles d'API ou des jetons. Donne commit, fichier, ligne. |
| Générer l'exemple | Liste toutes les variables d'environnement lues dans le code et genere un .env.example avec leurs noms et un commentaire, sans valeur. |
| Vérifier la frontière | Liste les variables d'environnement exposees au navigateur et dis-moi si l'une d'elles semble etre un secret. |
| Relecture d'un aperçu | Ouvre [URL_APERCU], parcours les pages principales et signale toute erreur console, lien casse ou image manquante. |
| Préparer le retour arrière | Explique-moi, pour ce projet, comment revenir au deploiement precedent et ce que cela ne restaure pas. |
Tu as d’autres ressources comme ça ?
Ce que tu viens de lire est entièrement gratuit. Une nouvelle ressource part chaque semaine dans la newsletter : guides, modèles à copier et liens triés, sans compte à créer.
Me contacter
Une question, un projet, une envie de collaborer ? Écris-moi.
Cette page est en accès libre, n’hésite pas à la partager.