Chaque modification de votre application est-elle essayée quelque part avant d'arriver chez vos clients ? Si la réponse est non, ou « je crois », il vous manque un environnement de préproduction : une copie de votre application, identique à celle qui est en ligne, où l'on teste les changements avant de les publier.
Ce n'est pas un luxe de grande entreprise. Pour une PME qui fait évoluer son application régulièrement, a fortiori avec Claude Code, Cursor ou Lovable, c'est la différence entre découvrir un bug en interne et le découvrir par un client mécontent.
Voici à quoi sert une préproduction, ce qu'elle doit contenir, et comment la mettre en place sans en faire un projet à part entière.
Environnement de préproduction : de quoi parle-t-on
Une application qui évolue vit en général à trois endroits :
- le développement : l'ordinateur du développeur, ou l'outil d'IA, où l'on écrit le code ;
- la préproduction (on dit aussi staging ou recette) : un serveur à part, configuré comme la production, où l'on vérifie que tout fonctionne ;
- la production : l'application que vos clients utilisent, avec les vraies données.
La préproduction a deux rôles. Pour le développeur, c'est l'endroit où l'on vérifie que la modification fonctionne en conditions réalistes, et pas seulement « sur ma machine ». Pour vous, c'est l'endroit où vous validez qu'elle fait bien ce que vous aviez demandé, avant que vos clients ne la voient.
Le mot important est identique. La méthode Twelve-Factor App, une référence chez les développeurs, recommande de garder le développement, la préproduction et la production aussi proches que possible, notamment en utilisant partout les mêmes types et versions de base de données et de services (12factor.net, « Dev/prod parity »). Une préproduction qui tourne sur une autre version de base de données que la production laisse passer exactement les bugs qu'elle devait arrêter.
Pourquoi c'est encore plus important avec l'IA
Les outils d'IA ont changé le rythme : une modification qui prenait une journée en prend une heure. C'est une excellente nouvelle, à condition que la vérification suive. Or les agents d'IA ont deux travers bien connus : ils modifient parfois plus que ce qu'on leur a demandé, et ils affirment avec assurance qu'une chose fonctionne alors qu'elle ne fonctionne pas.
L'incident le plus commenté reste celui de Jason Lemkin, investisseur américain, en juillet 2025. Alors qu'il avait demandé de ne plus rien modifier, l'agent de Replit a supprimé sa base de données de production. Le PDG de Replit a ensuite annoncé une séparation automatique entre les bases de développement et de production (TechTarget). Autrement dit, l'éditeur lui-même a répondu en séparant les environnements.
Si l'agent qui écrit le code n'a accès qu'au développement et à la préproduction, une erreur reste une erreur de test. S'il a accès à la production, c'est un incident. Nous détaillons les autres garde-fous dans Agent IA et base de production : les garde-fous à poser avant l'incident.
Les plateformes s'y mettent aussi. Supabase, la base de données sur laquelle s'appuient de nombreuses applications Lovable, propose des « branches » : des environnements isolés pour tester des changements. Sa documentation recommande les branches persistantes pour la préproduction (documentation Supabase, Branching). Vérifiez le statut de cette fonctionnalité et les conditions de votre abonnement avant de vous appuyer dessus.
Ce qu'une bonne préproduction contient, et ce qu'elle ne doit pas contenir
Ce qu'elle doit contenir
- Le même code que la production, plus la modification à tester, déployé de la même façon.
- La même configuration : mêmes versions de PHP et de base de données, mêmes tâches planifiées.
- Des données réalistes : assez de comptes, de commandes et de cas particuliers pour que les tests aient un sens.
- Ses propres accès aux services tiers, en mode test : paiement en mode bac à sable, mails interceptés plutôt qu'envoyés.
- Un accès restreint : mot de passe ou filtrage, et pas d'indexation par les moteurs de recherche.
Ce qu'elle ne doit pas contenir
- Les clés de production. Une préproduction branchée sur le vrai compte de paiement ou le vrai service d'envoi de mails peut débiter un client ou écrire à toute votre clientèle.
- Les données personnelles réelles, telles quelles. Copier la base de production en préproduction est tentant, mais vous multipliez alors les endroits où se trouvent les données de vos clients, souvent moins bien protégés. Préférez des données fictives ou anonymisées. Le sujet est développé dans Application vibe coding et RGPD : où sont vos données, et ce que vous devez vérifier.
- Une connexion à la base de production. C'est l'erreur la plus dangereuse : un test qui croit écrire dans une copie écrit en réalité dans la vraie base.
Le circuit d'une modification, de la demande à la mise en ligne
Une préproduction n'est utile que si elle s'inscrit dans un circuit clair. Voici celui qui fonctionne bien dans une PME :
- La demande est écrite : ce que vous voulez, et comment on saura que c'est fait.
- Le développement se fait sur une branche séparée du code, jamais directement sur la version en ligne.
- Les vérifications automatiques se lancent à chaque modification : tests, analyse du code, recherche de failles connues dans les bibliothèques utilisées.
- Le déploiement en préproduction est automatique, ou se fait en un clic.
- La validation : vous, ou la personne qui a fait la demande, testez en préproduction et donnez votre accord.
- La mise en production se fait de la même manière que le déploiement en préproduction, avec un retour arrière possible.
L'étape 5 est celle qui vous concerne directement, et c'est souvent celle qui manque. Sans elle, le développeur, ou l'IA, décide seul de ce qui est « fini ». Et quand chaque correction risque d'en casser une autre, comme nous l'expliquons dans Application vibe coding : quand chaque correction casse autre chose, c'est en préproduction qu'on repère la casse.
Mettre en place une préproduction sans y passer des semaines
Pour une application de taille raisonnable, une préproduction ne demande pas de lancer un second projet. Les étapes réalistes :
- Un second hébergement, plus modeste que la production, mais avec les mêmes versions logicielles.
- Un déploiement automatisé (ce que les développeurs appellent CI/CD), identique pour les deux environnements : une préproduction déployée à la main finit toujours par s'écarter de la production.
- Un jeu de données de test préparé une fois, et rechargeable à volonté.
- Des réglages séparés, pour que les clés de production n'existent tout simplement pas en préproduction.
- Une règle écrite : rien ne part en production sans être passé par la préproduction et avoir été validé.
La dernière ligne est la plus importante, et la seule qui ne soit pas technique. C'est une décision de dirigeant.
Questions fréquentes
Mon application est petite, ai-je vraiment besoin d'une préproduction ?
Si elle évolue rarement et ne touche ni à vos clients ni à votre chiffre d'affaires, peut-être pas. Dès qu'elle sert vos clients ou votre facturation et qu'elle évolue chaque mois, oui.
La préproduction double-t-elle mes coûts d'hébergement ?
En général, non. Elle n'a besoin ni de la même puissance ni de la même disponibilité que la production. Elle doit avoir les mêmes versions logicielles, pas les mêmes ressources.
Qui doit tester en préproduction ?
Le développeur vérifie que ça fonctionne. Vous, ou la personne métier concernée, vérifiez que ça répond au besoin. Les deux sont nécessaires.
Mettre ce circuit en place, l'outiller et vous accompagner dans les validations, c'est typiquement ce que l'on fait avec l'offre Copilote : une journée de développeur senior par mois à vos côtés, pendant que votre équipe et vous continuez à construire avec l'IA. Si vous voulez savoir par où commencer chez vous, parlons-en simplement.