Qu'est-ce qu'un environnement de préproduction? Testez avant la mise en ligne

Un environnement de préproduction est une copie privée de votre app, configurée le plus près possible de la version en ligne, où vous testez les changements avant que de vrais utilisateurs les voient. Il utilise sa propre base de données, des données de test et des clés d'API de test; ainsi, une fonctionnalité brisée ou une mauvaise modification de données là-bas ne touche personne en dehors de votre équipe. Quand un changement semble correct en préproduction, vous le publiez en production — l'app en ligne qu'utilisent vos clients.

Pourquoi la préproduction compte quand on construit avec l'IA

L'IA rend les changements rapides. Vous pouvez ajouter une fonctionnalité, réécrire une page ou modifier la structure de vos données en quelques minutes. Cette rapidité est formidable, jusqu'à ce qu'un changement qui semblait correct brise discrètement le paiement, ou qu'un « petit nettoyage » supprime une colonne de données clients.

Un endroit pour vérifier les changements avant leur mise en ligne vous aide à :

• Détecter les bris avant vos clients. Essayez les flux d'inscription, de paiement et les parcours clés après chaque changement important.
• Tester dans des conditions réalistes. La préproduction doit se comporter comme la production — même pile technologique, configuration similaire —, afin que les problèmes apparaissent là, et non plus tard.
• Protéger les données réelles. Les changements de base de données, les importations et les modifications en masse peuvent d'abord être répétés sur des données de test.
• Montrer un travail en cours. Un client ou un collègue peut examiner un changement sans que celui-ci soit public.

Une analogie du quotidien

Pensez à la répétition générale d'un théâtre.

• Le développement est la salle de répétition : les acteurs essaient leurs répliques, s'arrêtent, recommencent, expérimentent.
• La préproduction est la répétition générale : costumes complets, vraie scène, vraies lumières — tout comme ce sera à la première, sauf qu'il n'y a pas de public payant.
• La production est la première. Les erreurs surviennent devant tout le monde.

La plupart des problèmes que vous préféreriez éviter à la première apparaissent à la répétition générale : un changement de costume trop long, un mauvais signal lumineux. C'est exactement le rôle de la préproduction.

Les trois environnements courants

Chaque environnement diffère surtout par sa configuration : à quelle base de données il se connecte, quelles clés il utilise, à quelle adresse il se trouve. C'est pourquoi les bonnes apps lisent ces réglages depuis les variables d'environnement et les secrets plutôt que de les coder en dur. Le même code peut alors fonctionner dans chaque environnement avec des réglages différents.

Un exemple concret : modifier les règles d'annulation d'une app de réservation

Vous gérez une app de réservation pour salon de coiffure avec des clients payants. Vous voulez changer la règle pour que les clients puissent annuler jusqu'à 24 heures avant, au lieu de 48, et que les remboursements soient automatiques.

1. Construire en développement. Vous demandez le changement à votre outil de création IA. Il met à jour la logique d'annulation et l'appel de remboursement vers votre fournisseur de paiement.

2. Publier en préproduction. La préproduction exécute le même code, connecté à une base de données de préproduction avec des réservations de test et les clés en mode test de votre fournisseur de paiement.

3. Tester les vrais parcours. Vous et un collègue :

• réservez un rendez-vous de test pour demain et annulez-le 30 heures avant — il devrait être remboursé;
• essayez d'annuler 10 heures avant — il devrait être refusé avec un message clair;
• vérifiez que le remboursement apparaît dans le tableau de bord de test du fournisseur de paiement;
• vérifiez que le courriel de confirmation indique 24 heures, et non 48.

4. Trouver le bogue. En préproduction, vous remarquez que la règle utilise le fuseau horaire du serveur, et non celui du salon; la limite est donc décalée d'une heure. Vous corrigez et retestez.

5. Publier en production. Ce n'est qu'à ce moment que le changement atteint les vrais clients — avec le bogue de fuseau horaire déjà détecté.

Sans la préproduction, l'étape 4 se serait produite avec le remboursement d'un vrai client.

Termes clés

Idées reçues courantes

• « La préproduction peut partager la base de données de production. » C'est le raccourci le plus dangereux. Un test qui supprime ou modifie des dossiers toucherait de vrais clients. Donnez à la préproduction sa propre base de données.
• « Si ça fonctionne en préproduction, ça ne peut pas briser en production. » La préproduction réduit le risque; elle ne l'élimine pas. Le trafic réel, les vraies données et les services externes peuvent encore vous surprendre. Gardez un moyen de revenir en arrière.
• « La préproduction doit coûter cher. » Elle peut être petite. Elle doit avoir la même configuration que la production, pas la même taille.
• « Utilisez les clés de paiement en direct en préproduction pour être réaliste. » Utilisez le mode test du fournisseur. Réaliste ne veut pas dire de l'argent réel.
• « La préproduction n'est que pour les grandes équipes. » L'idée — tester dans un endroit sûr d'abord — est utile même pour une seule personne. Le niveau de formalité peut s'adapter aux enjeux.
• « La préproduction devrait être publique pour que les gens puissent l'essayer. » Gardez-la privée ou protégée, et empêchez les moteurs de recherche de l'indexer, pour que personne ne la confonde avec la vraie app.

Quoi demander à votre outil de création IA

• « Fais en sorte que chaque réglage propre à un environnement — base de données, clés d'API, URL du site — provienne de variables d'environnement. »
• « Ajoute un script d'amorçage qui remplit une base de données hors production avec des données de test réalistes. »
• « Utilise le mode test du fournisseur de paiement jusqu'à ce que je dise que nous lançons. »
• « Avant que ce changement soit mis en ligne, liste les parcours que je dois tester et ce qui devrait se passer dans chacun. »
• « Ce changement touche-t-il les données existantes? Montre-moi d'abord la migration. »
• « Assure-toi que les copies hors production du site ne sont pas indexées par les moteurs de recherche. »

Pour une configuration pas à pas, consultez comment configurer un environnement de préproduction. Quand les mises en ligne deviennent fréquentes, automatiser le chemin du code vers la préproduction puis la production est le rôle du CI/CD.

Tester avant la publication dans Mythex

Mythex n'a pas de bouton séparé « préproduction ou production »; publier vous donne une seule URL publique en ligne, et la documentation le dit clairement (applications multi-services). Ce qu'il offre, c'est une ligne claire entre construire et mettre en ligne :

• Aperçu exécute votre app dans un bac à sable infonuagique privé pendant que vous construisez. Les changements apparaissent d'abord là, et non sur votre app en ligne.
• Partage crée des liens d'aperçu pour qu'un client ou un collègue puisse examiner le travail en cours sans compte Mythex et sans que vous publiiez. Le lien montre le bac à sable tel qu'il est à ce moment, y compris les changements en cours de construction, et vous pouvez le supprimer à tout moment.
• Publier prend un instantané du projet et le déploie. Tant que vous ne publiez pas à nouveau, l'app en ligne reste telle qu'elle était.
• Points de contrôle sont enregistrés après chaque tour réussi de l'agent, afin que vous puissiez revenir aux fichiers du projet si un changement tourne mal.

Traitez l'aperçu comme votre répétition : gardez les fournisseurs de paiement en mode test jusqu'au lancement, et parcourez vos flux clés avant chaque publication. Une fois que de vrais clients sont concernés, vérifiez avec l'agent quelle base de données et quelles clés votre aperçu utilise avant de tester quoi que ce soit qui écrit ou supprime des données. Si vous avez besoin d'une configuration de préproduction entièrement séparée avec sa propre base de données, demandez à l'agent d'expliquer vos options pour votre projet, ou — avec Pro — exportez le projet ou synchronisez-le avec GitHub pour l'exécuter sur une infrastructure que vous contrôlez.

Questions