Environnements

Ce fichier documente les différents environnements du projet StageConnect.

Environnements Actuels

Environnement	Usage	Statut
Local	Développement individuel	✅ Actif
Production	Utilisateurs réels	✅ Actif
Staging	Tests avant prod	❌ Non configuré

Configuration par Environnement

Local (Développement)

Variable	Valeur
ENVIRONMENT	development
DEBUG	true
ACCESS_TOKEN_EXPIRE_MINUTES	720 (confort dev)
BACKEND_CORS_ORIGINS	http://localhost:3000,http://localhost:3001,http://localhost:3002
REDIS_ENABLED	false (optionnel)

Production

Variable	Valeur
ENVIRONMENT	production
DEBUG	false
ACCESS_TOKEN_EXPIRE_MINUTES	30
BACKEND_CORS_ORIGINS	https://discover.stageconnect.app,https://career.stageconnect.app,https://admin.stageconnect.app
REDIS_ENABLED	true

Validation des Environnements

Le projet utilise un validateur automatique pour vérifier la configuration :

Fichier : app/utils/environment_validator.py

Ce validateur vérifie :

• Que ENVIRONMENT est soit development soit production
• Que les variables sensibles sont présentes en production
• Que les variables non sensibles ont des valeurs valides

Lancer la validation

# Validation automatique au démarrage du backend
python -m app.utils.environment_validator

Accès aux Environnements

Local

• Backend : http://localhost:8000
• Frontends : http://localhost:3000 (Discover), http://localhost:3001 (Career), http://localhost:3002 (Admin)
• Base de données : Supabase cloud (même instance que prod)

Production

• Backend : https://api.stageconnect.app
• Discover : https://discover.stageconnect.app
• Career : https://career.stageconnect.app
• Admin : https://admin.stageconnect.app

Lacunes

Connexion à la base de données de production en local

Les développeurs en local se connectent directement à la base de données de production.

Risques :

• Modification accidentelle de données de production
• Pas de séparation entre les données de test et les données réelles
• Impossible de tester les migrations de schéma sans impacter la production

Cible : Créer un Projet Supabase staging séparé. Date cible : Avant l'arrivée du prochain développeur dans l'équipe.

Absence de staging

Il n'y a pas d'environnement de staging. Tous les tests se font soit en local, soit directement en production (dangereux).

Risques :

• Pas de validation des changements en conditions réelles
• Les migrations de base de données ne peuvent pas être testées avant production
• Risque d'interruption de service lors des déploiements

Plan pour Ajouter Staging

Voir infrastructure/overview.md pour le plan détaillé.

Règle Absolue

Ne jamais tester en production. Si un bug ne se reproduit qu'en production, créer un environnement de reproduction en local ou attendre la mise en place du staging.