Configurer les environnements d’une application Laravel ou Node.js

Objectif

Ce guide aide à distinguer le code déployé de la configuration propre à chaque environnement. Vous apprendrez à préparer développement, préproduction et production, à stocker les secrets hors du dépôt et à vérifier qu’une modification de variable est effectivement prise en compte.

Pour un projet applicatif, reliez cette procédure à un serveur VPS et au guide pour déployer une application depuis Git.

Dans Laravel, les fichiers de configuration se trouvent dans config, tandis que les valeurs d’environnement peuvent être fournies par .env ou par des variables externes [1]. Dans Node.js, process.env expose les variables de l’environnement du processus et les fichiers .env suivent une syntaxe de paires clé-valeur définie par Node.js [2].

Prérequis

Préparez un inventaire des variables, leur type attendu, leur caractère secret et l’environnement concerné. Vous devez connaître le point d’entrée de l’application, la version de PHP ou Node.js visée, le mode de redémarrage et l’emplacement où NovaHoster permet éventuellement de définir les variables. Ces possibilités dépendent du forfait et des droits : ne supposez pas qu’un fichier .env éditable, un coffre de secrets ou un redémarrage à distance est disponible.

Procédure

1. Établir une matrice de configuration. Séparez les variables publiques, les identifiants et les clés critiques. Par exemple, APP_URL peut être propre à chaque environnement ; une clé de chiffrement, un mot de passe de base ou un webhook doivent rester confidentiels.

1. Créer un modèle documenté. Conservez un .env.example sans mot de passe ni jeton. Décrivez les valeurs obligatoires dans la documentation du projet. Pour Node.js, retenez que les valeurs chargées depuis un fichier .env sont interprétées comme des chaînes ; true, 0 et un objet JSON ne deviennent pas automatiquement un booléen, un nombre ou un objet [2]. Convertissez explicitement les valeurs dans le code.

1. Configurer Laravel. Placez les valeurs dans le mécanisme autorisé par l’hébergement. Utilisez env() dans les fichiers de configuration, puis lisez la configuration avec config(). Après php artisan config:cache, Laravel ne charge plus le .env pendant les requêtes et les appels directs à env() hors des fichiers de configuration peuvent retourner null [1].

1. Configurer Node.js. Lisez les variables avec process.env.PORT, process.env.NODE_ENV ou les noms propres à l’application. Pour les fichiers .env, utilisez le mécanisme disponible dans la version Node.js du serveur, par exemple l’option --env-file si elle est supportée, ou la méthode validée par votre projet [2]. Ne placez jamais un secret dans le bundle frontend : toute valeur livrée au navigateur est considérée comme publique.

1. Définir le mode de production. Pour Laravel, mettez APP_DEBUG=false en production : la documentation indique qu’un mode debug actif peut exposer des informations sensibles [3]. Pour Node.js, la documentation recommande d’exécuter l’application avec NODE_ENV=production, car des bibliothèques npm utilisent cette variable pour leurs réglages par défaut [4]. Cela ne remplace pas les tests de votre application.

1. Vérifier les formats. Contrôlez les URL, ports, booléens, listes séparées par des virgules, certificats et chaînes multilignes. Dans un fichier .env Node.js, les noms doivent respecter le format prévu et les valeurs contenant des espaces ou # doivent être correctement entourées de guillemets [2].

1. Redémarrer ou recharger selon le runtime. Une variable est lue par un processus au démarrage ou selon le mécanisme de configuration. Après modification, utilisez l’action de redémarrage prévue par NovaHoster, si votre offre la propose. Confirmez avec le support si un worker, un cache PHP, un processus Node.js ou un service persistant doit aussi être relancé.

1. Valider sans divulguer. Utilisez une commande ou une page d’administration qui indique uniquement la présence et la forme générale d’une variable, jamais sa valeur complète. Testez ensuite une requête réelle, la base, l’envoi de courriel et les appels externes dans un environnement non public avant la production.

1. Documenter la rotation. Notez quelle variable a changé, pourquoi, qui l’a modifiée et quels processus ont été redémarrés. En cas de fuite, révoquez immédiatement le secret auprès du service concerné et remplacez-le dans l’Espace client, sans le recopier dans un ticket non sécurisé.

Cas d’erreur et diagnostic

Quand contacter l’Espace client

Contactez NovaHoster pour confirmer l’emplacement de configuration des variables, la taille et les caractères autorisés, la nécessité d’un redémarrage, la disponibilité de workers ou de tâches planifiées, et les limites applicables à votre offre. Contactez également le support si une variable semble ignorée après reconstruction du cache ou si vous suspectez une fuite de secret. Ne joignez pas la valeur confidentielle ; transmettez seulement le nom de la variable et un exemple anonymisé.

Maillage interne suggéré

• [Déployer une application depuis Git sur NovaHoster](#guide-1--déployer-une-application-depuis-git-sur-novahoster)
• [Lire les logs et diagnostiquer une application en production](#guide-3--lire-les-logs-et-diagnostiquer-une-application-en-production)
• [Sécuriser un fichier .env]
• [Configurer une base de données]
• [Préparer une application pour la production]

Sources techniques

[1] Laravel — Configuration [2] Node.js — Environment Variables [3] Laravel — Deployment [4] Node.js — The difference between development and production