Comment mettre en place un environnement de préproduction pour votre application

Pour mettre en place un environnement de préproduction, déployez une seconde copie de votre application à sa propre URL privée, donnez-lui sa propre base de données et ses propres clés d'API de test, et faites en sorte qu'elle ressemble le plus possible à la production. Ensuite, publiez chaque changement important d'abord en préproduction, parcourez les parcours importants, et ne publiez en production que lorsque la préproduction semble correcte.

Si l'idée vous est nouvelle, ce qu'est un environnement de préproduction explique le concept. Ce guide porte sur la mise en place concrète, pensée pour les personnes qui créent avec des outils d'IA plutôt que pour une équipe DevOps.

Développement, préproduction et production

La plupart des petites applications ont besoin de trois endroits, même si le premier n'est que l'aperçu de votre outil de création :

L'intérêt de la préproduction est qu'elle se comporte comme la production — même code, même pile technologique, même type de configuration —, mais qu'une erreur là-bas ne fait de mal à personne.

Étape 1 : décidez ce que la préproduction doit reproduire

La préproduction n'est utile que si les problèmes apparaissent là-bas avant de se manifester en production. Reproduisez :

• Le même code, publié de la même façon.
• La même pile et les mêmes versions — cadriciel, environnement d'exécution, type de base de données.
• Le même type de configuration — les mêmes noms de variables d'environnement, avec des valeurs de test.
• Les mêmes services — si la production a une application web et une API, la préproduction en a aussi deux.

Elle peut différer par sa taille (une machine plus petite convient) et par ses données.

Étape 2 : créez la copie

L'approche la plus simple : un second déploiement du même projet, à une autre URL, par exemple preprod.votreapp.com ou votreapp-preprod.exemple.com.

La démarche dépend de votre hébergeur :

• Les hébergeurs qui offrent des déploiements d'aperçu ou de préproduction peuvent en créer un automatiquement pour une branche Git.
• Les hébergeurs sans cette fonction : créez une seconde application ou un second projet à partir du même code, et déployez-le séparément.
• Code dans Git : conservez une branche staging ou main qui se déploie en préproduction, et déployez en production à partir d'une version publiée. Voir comment utiliser Git avec une application créée par IA.

Étape 3 : donnez à la préproduction sa propre base de données

C'est l'étape qui vous protège. Si la préproduction et la production partagent une base de données, un test qui supprime des enregistrements supprime de vrais enregistrements.

• Créez une base de données distincte pour la préproduction.
• Remplissez-la de données d'amorçage — des enregistrements fictifs réalistes que l'IA peut générer pour vous.
• Si vous avez besoin d'une copie des données de production, retirez ou brouillez les noms, les courriels et tout ce qui est personnel d'abord.

Écris un script d'amorçage qui remplit une base de données vide avec des données de test réalistes : 20 clients, 50 commandes dans différents états, et deux utilisateurs administrateurs. Utilise des noms manifestement fictifs et des adresses courriel en example.com.

Avant de faire confiance à la configuration, confirmez à quelle base de données chaque copie se connecte. Demandez directement :

À quelle base de données cette application se connecte-t-elle, et d'où vient ce paramètre? Montre-moi le nom de la variable, pas le mot de passe.

Étape 4 : utilisez des clés de test et des réglages séparés

Tout ce qui communique avec un service externe devrait utiliser des identifiants de test en préproduction :

• Paiements en mode test (clés de test de Stripe, par exemple), pour qu'aucune carte réelle ne soit débitée.
• Courriels envoyés à un bac à sable ou seulement à votre propre adresse, pour que les clients ne reçoivent jamais un message de test.
• IA et autres API payantes avec une clé distincte et un plafond de dépenses bas.
• Webhooks pointés vers l'URL de préproduction, et non vers la production.

Gardez les noms des variables identiques dans les deux environnements et ne changez que les valeurs. Ainsi, le code n'a pas besoin de savoir où il s'exécute. Pour en savoir plus, voir comment protéger vos clés d'API.

Étape 5 : gardez la préproduction privée

La préproduction ne devrait pas être publique :

• Placez-la derrière une connexion, un mot de passe, ou une liste d'adresses courriel de l'équipe autorisées.
• Empêchez les moteurs de recherche de l'indexer avec une balise meta noindex ou un en-tête X-Robots-Tag.
• Ne la liez pas depuis votre site public.
• Faites-la paraître différente : une bannière colorée « PRÉPRODUCTION » évite de tester dans le mauvais onglet.

Ajoute une bannière jaune vif en haut de chaque page qui affiche « PRÉPRODUCTION — données de test seulement » lorsque la variable d'environnement APP_ENV vaut « staging ». Ajoute aussi une balise meta noindex dans ce cas.

Étape 6 : établissez une routine de publication

La préproduction n'aide que si vous l'utilisez à chaque fois. Une routine simple :

1. Faites le changement en développement et vérifiez-le dans l'aperçu.
2. Publiez-le en préproduction.
3. Parcourez vos parcours clés : inscription, connexion, fonctionnalité principale, paiements, tout ce que le changement a touché.
4. Si quelque chose casse, corrigez-le et republiez en préproduction.
5. Publiez la même version en production.
6. Vérifiez rapidement la production — les mêmes parcours, brièvement.

Notez les parcours clés dans un court script de test. Voir comment tester votre application avant le lancement pour savoir quoi inclure.

Étape 7 : gérez les changements de base de données avec prudence

Les changements de structure de la base de données — ajouter une colonne, renommer une table — sont là où la préproduction prouve sa valeur.

• Exécutez chaque changement de structure en préproduction d'abord.
• Vérifiez que les données existantes ont survécu, pas seulement que les nouvelles fonctionnalités marchent.
• Faites une sauvegarde de la production avant d'exécuter le même changement là-bas. Voir comment sauvegarder la base de données de votre application.
• Privilégiez les changements qui ajoutent plutôt que ceux qui renomment ou suppriment, pour que l'ancienne version fonctionne encore si vous revenez en arrière.

Exemples de consignes

Explique ce qui arriverait aux données existantes si nous exécutions ce changement de base de données en production. Est-ce qu'on supprime ou renomme quelque chose?

Fais en sorte que tous les paramètres propres à l'environnement — URL d'API, clés, expéditeur des courriels, URL du site lui-même — proviennent de variables d'environnement portant les mêmes noms en préproduction et en production. Liste-les.

Rédige une courte liste de contrôle des parcours à tester en préproduction avant chaque publication, selon ce que fait cette application.

Erreurs courantes

• Base de données partagée. L'erreur la plus dommageable. La préproduction obtient toujours la sienne.
• Clés réelles en préproduction. Vrais débits, vrais courriels envoyés à de vrais clients.
• La préproduction s'éloigne de la production. Des versions ou réglages différents font que la préproduction ne détecte plus les problèmes.
• Un site de préproduction public et indexé qui apparaît dans les résultats de recherche à côté de votre vrai site.
• Sauter la préproduction pour les changements « mineurs ». Les petits changements cassent aussi des choses.
• Tester dans le mauvais onglet. Une bannière visible règle le problème.

Liste de contrôle

• La préproduction exécute le même code, la même pile et les mêmes services que la production.
• La préproduction a sa propre base de données avec des données de test ou nettoyées.
• Les paiements, le courriel et les API payantes utilisent des clés de test en préproduction.
• Les noms de variables sont identiques d'un environnement à l'autre; seules les valeurs diffèrent.
• La préproduction est derrière une connexion ou un mot de passe et n'est pas indexée.
• Une bannière s'affiche lorsque vous êtes en préproduction.
• Chaque publication passe d'abord par la préproduction, avec une liste écrite des parcours à vérifier.
• Les changements de base de données s'exécutent d'abord en préproduction, avec une sauvegarde de production avant la publication.

La préproduction sur Mythex

La fonction Publier de Mythex vous donne une seule URL en ligne par application; il n'y a pas de bouton séparé pour la préproduction. En pratique, vous avez deux options :

• L'aperçu comme vérification avant publication. Chaque projet s'exécute dans un espace de travail infonuagique privé avec un aperçu en direct. /test demande à l'agent de le parcourir comme un utilisateur, et un lien Partager permet à un client ou à un coéquipier d'examiner l'aperçu sans publier. Voir Aperçu et code. Cela suffit pour beaucoup de projets solo.
• Un second projet comme préproduction. Avec le forfait Pro, exportez le projet et importez-le dans un nouveau projet, donnez à celui-ci sa propre base de données et ses propres secrets de test, et publiez-le à son propre identifiant d'URL. Publiez-y avant de publier le projet de production.

Dans les deux cas, demandez à l'agent quelle base de données utilisent l'aperçu et l'application publiée avant de tester quoi que ce soit de destructeur, et utilisez les points de contrôle pour annuler un mauvais changement. Pour mettre une application en ligne de façon plus générale, voir comment faire passer un prototype IA en production.

Questions