Lance un environnement de test full-stack en quelques secondes, sans aucune configuration

Une pull request est envoyée. Le relecteur veut voir le projet en action, pas seulement lire le diff, alors quelqu’un contacte l’équipe : « Je peux avoir un environnement pour ça ? » Selon qui est disponible, ça peut prendre une heure. Ça peut même prendre jusqu’à demain. Le temps que l’environnement soit prêt, le relecteur est déjà passé à autre chose, et récupérer son attention est une tâche à part entière. Et si l’URL de prévisualisation était déjà dans la pull request avant même que quelqu’un ait à la demander ?

Ce que signifie réellement « zéro configuration »

Point clé : le travail de configuration ne se fait qu’une seule fois, lors de la mise en place du projet, et non à chaque fois que quelqu’un ouvre une branche.

Les projets Upsun s’appuient sur un fichier de configuration YAML qui définit l’application, ses services et ses routes, et ce fichier se trouve dans ton dépôt Git. Ce que l’on entend ici par « zéro configuration », c’est ce qui se passe une fois que ce fichier est en place et que tes variables d’environnement sont définies. Une fois le projet configuré, chaque nouvelle branche ou pull request peut disposer automatiquement de son propre environnement, sans qu’aucune configuration supplémentaire ne soit nécessaire pour cette branche spécifique. L’agent d’intégration d’Upsun peut même pré-générer ce fichier de configuration initial à partir de ton dépôt, ce qui rend cette étape de configuration unique presque entièrement automatisée. La version longue de cette affirmation est « aucune configuration supplémentaire par branche pour les déploiements dans de nouveaux environnements », mais on a décidé d’opter pour la version courte pour une explication plus rapide.

Que se passe-t-il quand tu ouvres une branche ?

Point clé : l’environnement est créé, reconstruit et supprimé automatiquement au fur et à mesure que la branche évolue dans son cycle de vie.

Grâce à l’intégration Git d’Upsun, l’ouverture d’une branche ou d’une pull request déclenche le démarrage automatique d’un environnement. Tu pousses de nouveaux commits, et il se reconstruit. Tu fusionnes ou fermes la branche, et il est supprimé automatiquement. Tes développeurs n’ont jamais besoin de remplir un ticket ni d’effectuer aucune étape manuelle pour obtenir leurs environnements de test.

Ce qui s’exécute réellement là-dedans

Point clé : les relecteurs disposent de l’application complète, pas seulement de la modification du code.

L’environnement créé n’est pas un aperçu allégé d’un seul service ou conteneur. Il comprend le code de l’application, une copie de la base de données, l’index de recherche et les fichiers dont l’application dépend, ainsi qu’une URL générée automatiquement qui peut être partagée avec toute personne ayant besoin de la consulter : un réviseur, un responsable de l’assurance qualité, un chef de produit vérifiant une modification de l’interface utilisateur. Beaucoup de bugs et de régressions n’apparaissent qu’une fois que l’ensemble de la pile fonctionne réellement de manière coordonnée.

Pourquoi ça accélère la révision

Point clé : certains bugs n’existent qu’une fois que la stack complète est réellement en marche, et aucune lecture d’un diff ne permettra de les détecter.

Présenter une version fonctionnelle et en direct d’une modification à un relecteur dès l’ouverture d’une PR raccourcit le cycle entre la création d’une modification et sa validation. Ça permet aussi de détecter une autre catégorie de problèmes. Une modification CSS qui semble correcte dans un diff peut quand même poser problème à une largeur d’écran spécifique. Une migration de base de données peut s’exécuter sans problème de manière isolée, mais entrer en conflit avec des données existantes et réelles dès qu’on y touche. Personne n’attend un environnement de préproduction partagé, et personne ne révise en se basant sur une description de ce que fait le code au lieu de le voir fonctionner en vrai.

Qu’advient-il de tous ces environnements au fil du temps ?

Point clé : les environnements inactifs se nettoient tout seuls, ce qui évite qu’ils ne se transforment en un tas d’infrastructures oubliées.

Lancer un environnement complet par branche soulève une question évidente : est-ce que ça ne devient pas coûteux ou compliqué quand il y en a des dizaines qui traînent ? C’est une préoccupation légitime dans tout le secteur : le rapport « 2026 State of the Cloud » de Flexera a révélé que 29 % des dépenses cloud sont gaspillées, et que la puissance de calcul inactive, c’est-à-dire inutilisée, qui correspond à la même catégorie qu’un environnement de test oublié, en est la principale cause. 

Upsun met automatiquement en pause les environnements de test qui n’ont pas été redéployés depuis 14 jours ; ainsi, ceux qui sont inactifs cessent de consommer des ressources sans que personne n’ait à les repérer manuellement. Il suffit de pousser du nouveau code ou de réactiver un environnement en pause pour le réactiver. Fusionne ou ferme la branche, et l’environnement est supprimé définitivement. Ici, rien ne dépend du fait que quelqu’un se souvienne de nettoyer derrière lui.

Pourquoi c’est important pour l’adoption par les nouveaux développeurs

Point clé : un développeur peut constater par lui-même la valeur ajoutée dès la première fois qu’il ouvre une pull request, sans avoir besoin d’une démo ou d’un appel commercial.

C’est aussi pour ça que les aperçus sans configuration ont tendance à bien fonctionner comme déclencheur en libre-service. Un nouveau développeur qui utilise Upsun Cloud pour la première fois n’a pas besoin qu’on lui explique la valeur ajoutée : il ouvre une branche, et l’environnement se construit sans aucune étape supplémentaire.

Prêt à voir une branche se transformer toute seule en environnement de travail ? Commence un essai gratuit de 15 jours et ouvre ta première pull request.

Foire aux questions (FAQ)

Est-ce que ça marche avec n’importe quel fournisseur Git ? 
Upsun propose des intégrations natives pour GitHub, GitLab et Bitbucket, et chacune d’entre elles crée automatiquement des environnements de test pour les pull requests ou les merge requests. Les instances auto-hébergées fonctionnent aussi : GitHub Enterprise, GitLab en gestion autonome et Bitbucket Server. Sur n’importe quel autre hébergeur Git, tu peux toujours pousser vers Upsun depuis ton pipeline CI. Il te suffira simplement de créer toi-même le script d’environnement automatique pour chaque pull request.

Dois-je rédiger une configuration pour chaque nouvel environnement de test ? 
Non. La configuration se trouve au niveau du projet et n’est définie qu’une seule fois. Les nouvelles branches l’héritent automatiquement.

Qu’est-ce qui est inclus dans un environnement de test en plus du code ? 
Une copie de la base de données, de l’index de recherche et des fichiers dont l’application a besoin, ainsi qu’une URL générée automatiquement, correspondant à ce qui tourne réellement en production.

Les environnements de test inactifs continuent-ils à coûter de l’argent indéfiniment ? 
Non. Les environnements qui n’ont pas été redéployés depuis 14 jours sont automatiquement mis en pause, et peuvent également être mis en pause ou réactivés manuellement à tout moment.