Dev, recette et prod : pourquoi votre logiciel a besoin de trois environnements séparés

Les trois environnements en un tableau

Certaines équipes ajoutent un aperçu par branche : une adresse temporaire qui montre une modification isolée, pour la relire avant qu'elle rejoigne les autres en dev.

Pourquoi une petite entreprise en a besoin aussi

Des environnements séparés ressemblent à une procédure de grand groupe, mais les risques sont les mêmes à toute taille. Un développeur qui teste un e-mail de relance sur la base réelle écrit à de vrais clients. Une modification qui marche sur un portable échoue avec les vraies données le lundi à 9 heures. Un paiement de test passe avec une vraie carte. Chacun de ces accidents s'évite par une seule règle : rien ne s'essaie pour la première fois en prod.

Les prestataires de paiement intègrent cette séparation. Stripe, par exemple, fournit des environnements de test (sandboxes) et des clés d'API de test : les transactions de test ne déplacent pas d'argent, les paiements réels exigent des clés réelles, et Stripe demande de ne pas stocker les clés dans le code et de ne pas tester en mode réel avec de vraies cartes. Le même principe vaut pour chaque service externe utilisé par votre application.

Ce qui doit différer d'un environnement à l'autre

Si votre application tourne avec Docker Compose, le guide de Docker sur la production conseille de garder la configuration commune dans un fichier et les seules différences de production (autres ports, variables d'environnement, politique de redémarrage, aucun code monté depuis l'extérieur du conteneur) dans un fichier séparé comme compose.production.yaml, appliqué par-dessus avec docker compose -f. Le même principe vaut pour un fichier de recette.

• Les adresses : chaque environnement a sa propre adresse web, pour ne jamais les confondre.
• Les données : des bases séparées. Les données de prod ne sont copiées en recette qu'en cas de besoin, et anonymisées si elles contiennent des données personnelles.
• Les clés et secrets : des clés d'API propres à chaque environnement (clés de test hors prod), stockées hors du code.
• Les messages sortants : e-mails, SMS et WhatsApp envoyés depuis le dev et la recette vont uniquement à des destinataires de test.
• Les réglages : niveau de journalisation, remontée d'erreurs, adresses des services externes.
• Les accès : moins de personnes peuvent mettre en ligne en prod qu'en dev.

Le trajet d'une modification, du dev à la prod

Les outils savent porter ces étapes. Les environnements de GitHub Actions, par exemple, peuvent exiger l'approbation de relecteurs désignés avant un déploiement, restreindre les branches autorisées à déployer dans un environnement, et réserver des secrets aux seules tâches qui utilisent cet environnement, une fois ses règles de protection satisfaites.

1. Un développeur construit la modification sur une branche et la vérifie dans un aperçu ou en dev.
2. Des contrôles automatiques tournent : compilation, tests, et contrôle de santé de la nouvelle version.
3. La modification part en recette. Vous ou votre équipe la testez sur des scénarios réalistes et la validez.
4. La même version est mise en prod par une personne désignée, de préférence à un moment calme.
5. Les contrôles de santé confirment que la prod va bien ; sinon, la version précédente est restaurée.

Les erreurs fréquentes

• Une seule base pour tout : un test en dev modifie de vraies commandes.
• Des clés de paiement réelles en recette, ou des clés de test oubliées en prod.
• Compiler sur le serveur de production : une compilation ratée fait tomber le site.
• Corriger directement en prod « juste cette fois », puis perdre la correction à la mise en ligne suivante.
• Des données clients réelles copiées en dev sans anonymisation.
• Aucun retour possible : une mise en ligne sans version précédente prête à être restaurée.

Notre façon de livrer chez Takat

Chaque projet que nous construisons a ses environnements de dev, de recette et de prod, avec une adresse d'aperçu par branche. Les compilations tournent sur GitHub Actions, jamais sur le serveur de production ; les applications tournent sous Docker Compose avec des contrôles de santé ; les serveurs prennent des instantanés quotidiens ; et une mise en ligne qui échoue à ses contrôles de santé est annulée automatiquement. Un assistant de devis safari construit pour une entreprise de voyage d'Afrique australe, par exemple, tourne avec des environnements dev, recette et prod séparés. Voir Logiciel sur mesure et Hébergement et DevOps.