La préprod est la copie de test de votre site, où l'on vérifie chaque modification avant sa mise en ligne. Rôle des environnements, mise en place et pièges à éviter.
La préprod (ou préproduction) est une copie de votre site ou de votre application, installée sur un serveur à part, où l’on teste chaque modification dans des conditions aussi proches que possible du réel avant de la mettre en ligne. Elle se place entre l’environnement de développement, où les développeurs codent, et la production, le site que voient vos clients. Son rôle : attraper les bugs, faire valider le client et éviter les mauvaises surprises le jour de la mise en ligne.
Voici les différents environnements d’un projet web, ce qui distingue la préprod de la prod, comment la mettre en place proprement (y compris pour un site WordPress) et les erreurs qui coûtent cher, comme une préprod indexée par Google ou remplie de vraies données clients.
- Qu’est-ce qu’une préprod ?
- Quels sont les environnements d’un projet web ?
- Quelle différence entre prod et préprod ?
- Pourquoi utiliser une préprod ?
- Comment mettre en place une préprod ?
- Comment faire une préprod pour un site WordPress ?
- Quelles erreurs éviter ?
- Questions fréquentes
- Sources
Qu’est-ce qu’une préprod ?
Le mot « préprod » est l’abréviation de préproduction : l’étape qui précède la mise en production d’un site, d’une application ou d’un logiciel métier. Par extension, on appelle aussi « préprod » le serveur ou l’adresse où tourne cette copie de test, par exemple une adresse du type preprod.votresite.fr.
En anglais, on parle de staging (environnement de mise en scène ou de préparation). Dans un projet d’agence, la préprod sert aussi de lieu de recette : c’est là que le client vérifie et valide les développements avant qu’ils soient publiés.
La préprod s’inscrit dans le cycle de vie du développement logiciel : on code, on intègre, on teste, on valide, puis on déploie. Elle est le dernier filet de sécurité avant les utilisateurs réels.
Quels sont les environnements d’un projet web ?
Un projet web sérieux repose en général sur trois à quatre environnements, chacun avec son rôle :
| Environnement | Où ? | À quoi il sert | Qui y accède ? |
|---|---|---|---|
| Développement (local) | Poste du développeur ou conteneur | Coder, expérimenter, lancer les tests automatisés | Le développeur |
| Intégration | Serveur partagé | Assembler le travail de toute l’équipe et vérifier que l’ensemble fonctionne | L’équipe technique |
| Préproduction (staging, recette) | Serveur séparé, configuré comme la prod | Tests finaux, recette et validation par le client | L’équipe et le client |
| Production | Serveur d’hébergement définitif | Le site ou l’application en service | Les utilisateurs et les moteurs de recherche |
Sur les petits projets, l’intégration et la préprod sont souvent fusionnées. L’essentiel est la règle suivante : les utilisateurs se connectent uniquement à la production, jamais à la préprod.
L’environnement de développement
C’est l’atelier. Chaque développeur doit pouvoir y :
- expérimenter rapidement de nouvelles approches sans risque ;
- travailler sur une architecture proche de la production (même version de PHP, même base de données) ;
- écrire des tests automatisés, qui seront rejoués à chaque intégration.
L’environnement d’intégration
Chaque membre de l’équipe doit pouvoir voir l’état actuel de l’ensemble du projet. L’environnement d’intégration est mis à jour automatiquement, souvent par un outil d’intégration continue relié au dépôt de code (Git), à chaque modification validée. C’est l’une des pratiques au cœur de l’approche DevOps.
L’environnement de préproduction
Avant de déployer quoi que ce soit en ligne, on le teste dans un environnement qui reproduit le plus fidèlement possible la production. C’est ici que l’on réalise :
- les tests d’assurance qualité et la recette fonctionnelle ;
- les tests exploratoires, où l’on cherche activement ce qui peut casser ;
- les tests de sécurité (vulnérabilités, tests d’intrusion) ;
- les tests de performance et de montée en charge ;
- la validation visuelle et éditoriale par le client.
Quelle différence entre prod et préprod ?
La prod (production) est l’environnement stable sur lequel repose votre site ou votre application en service. Il est connu de vos utilisateurs et des moteurs de recherche, il contient les vraies données, il doit être disponible en permanence.
La préprod est son double de test. Elle doit lui ressembler techniquement (mêmes versions, même configuration serveur), mais s’en distinguer sur tout le reste : adresse différente, accès restreint, invisible pour Google, données de test, e-mails et paiements désactivés ou en mode test.
| Critère | Préprod | Prod |
|---|---|---|
| Public | Équipe et client | Tous les visiteurs |
| Indexation Google | Bloquée (mot de passe, noindex) | Autorisée |
| Données | Fictives ou anonymisées | Réelles |
| Paiements, e-mails | Mode test ou désactivés | Actifs |
| Configuration technique | Identique à la prod | Référence |
| Stabilité | Peut casser, c’est son rôle | Doit être disponible en continu |
La méthode The Twelve-Factor App résume bien l’enjeu sous le nom de « parité dev/prod » : garder le développement, la validation et la production aussi proches que possible, pour qu’un code qui fonctionne en test fonctionne aussi en ligne.
Pourquoi utiliser une préprod ?
Utiliser un serveur de préproduction permet de vérifier que les fonctionnalités développées ne buggent pas dans des conditions réelles d’utilisation. La configuration d’un poste de développeur peut être très différente de celle du serveur d’hébergement : version de PHP, modules installés, cache, droits sur les fichiers.
- Mettre à jour sans risque. Les mises à jour d’un CMS, d’une extension ou d’une version de PHP se testent d’abord en préprod. Si quelque chose casse, seuls les testeurs le voient.
- Faire valider le client. Le client consulte les nouveautés sur une vraie adresse, avant publication, et donne son accord.
- Donner une vision commune. Toute l’équipe voit l’état réel du projet et comprend comment son travail s’insère dans l’ensemble.
- Déployer en confiance. Si les tests sont concluants en préprod, la mise en production devient une formalité plutôt qu’un pari.
- Continuer à faire évoluer le site après la livraison. Garder une préprod après le lancement est une bonne idée dès que vous prévoyez des évolutions régulières.
Comment mettre en place une préprod ?
Les environnements nécessaires se prévoient dès le cahier des charges. Voici les étapes classiques :
- Choisir l’emplacement. Un sous-domaine (preprod.votresite.fr) sur le même hébergement, ou un serveur séparé. Beaucoup d’hébergeurs proposent une fonction de staging intégrée.
- Reproduire la configuration de production. Mêmes versions de langage et de base de données, mêmes réglages serveur, même mise en cache.
- Protéger l’accès. Une authentification HTTP (mot de passe demandé par le serveur) ou une restriction par adresse IP empêche à la fois les curieux et les robots d’y accéder.
- Empêcher l’indexation. Ajoutez en complément une directive noindex (balise meta robots ou en-tête HTTP X-Robots-Tag).
- Préparer des données de test. Un jeu de données fictives, ou une copie de la base anonymisée.
- Neutraliser les effets de bord. Paiement en mode test, e-mails redirigés vers une boîte de test, tâches planifiées et connexions aux outils externes (CRM, ERP) désactivées ou pointées vers leurs environnements de test.
- Automatiser les déploiements. Le code passe du dépôt Git à la préprod, puis de la préprod à la prod, par le même processus, pour que ce qui a été testé soit exactement ce qui est publié.
Les tests eux-mêmes gagnent à être en partie automatisés : notre article sur les tests automatisés en développement web détaille comment les organiser.
Comment faire une préprod pour un site WordPress ?
WordPress prévoit un mécanisme officiel pour distinguer les environnements. Depuis la version 5.5, la constante WP_ENVIRONMENT_TYPE accepte les valeurs local, development, staging et production (production par défaut). Les extensions et thèmes peuvent la lire avec la fonction wp_get_environment_type() pour adapter leur comportement, et la documentation demande aux hébergeurs de la régler sur staging pour leurs environnements de préproduction.
// Dans le fichier wp-config.php de la préprod
define( 'WP_ENVIRONMENT_TYPE', 'staging' );Pour une préprod WordPress propre :
- copiez fichiers et base, puis remplacez l’adresse du site dans la base (avec un outil qui gère les données sérialisées, comme la commande search-replace de WP-CLI) ;
- protégez l’accès par mot de passe au niveau du serveur, en plus de l’option « Demander aux moteurs de recherche de ne pas indexer ce site » ;
- désactivez les envois d’e-mails réels et passez WooCommerce et votre passerelle de paiement en mode test ;
- testez les mises à jour du cœur, des extensions et du thème en préprod avant de les appliquer en prod.
Tester les mises à jour avant de les publier fait partie d’une maintenance WordPress sérieuse : c’est souvent la différence entre une mise à jour sans histoire et un site cassé un vendredi soir.
Quelles erreurs éviter avec une préprod ?
Compter sur le robots.txt pour cacher la préprod
C’est l’erreur la plus répandue. Google l’écrit clairement : le fichier robots.txt n’est pas un moyen d’exclure une page de ses résultats. Une URL bloquée par robots.txt peut quand même apparaître dans les résultats si d’autres pages pointent vers elle. Pire, si la page est bloquée par robots.txt, Google ne voit jamais la balise noindex. Pour une préprod, la bonne réponse est la protection par mot de passe, éventuellement doublée d’un noindex. Si une préprod apparaît déjà dans Google, notre article sur les erreurs noindex dans la Search Console vous aidera à diagnostiquer.
Copier la base de production telle quelle
Le guide RGPD du développeur publié par la CNIL est explicite : les données réelles de production ne doivent pas être utilisées pour le développement et les tests. Les réutiliser revient à les détourner de leur finalité et multiplie les risques de fuite. La CNIL recommande de construire un jeu de données fictives ; à défaut, l’environnement de test doit bénéficier des mêmes mesures de sécurité que la production.
Laisser la préprod envoyer de vrais e-mails ou encaisser de vrais paiements
Une préprod copiée d’un site marchand peut relancer des clients, envoyer des newsletters ou déclencher des commandes vers un logisticien. Neutralisez systématiquement ces fonctions avant la première connexion.
Une préprod qui ne ressemble plus à la prod
Version de PHP différente, extensions non mises à jour, cache absent : une préprod qui dérive ne sert plus à rien, car elle ne reproduit plus les bugs de la prod. Resynchronisez-la régulièrement.
Modifier directement en production
Une « petite correction » faite directement en ligne ne sera pas dans le dépôt de code et sera écrasée au prochain déploiement. Toute modification doit suivre le même chemin : développement, préprod, prod.
Questions fréquentes
Quelle est la définition de la préproduction ?
La préproduction, ou préprod, est l’étape qui précède la mise en production d’un service ou d’un produit numérique. Par extension, c’est l’environnement de test qui reproduit la production.
Qu’est-ce qu’un site de préproduction ?
C’est une copie privée du site, sur une adresse séparée, où l’on teste les nouveautés et où le client valide les développements avant leur publication.
Préprod, staging et recette, est-ce la même chose ?
Dans la pratique, oui : staging est le terme anglais, et la recette désigne l’activité de validation qui s’y déroule. Certaines équipes séparent un environnement de recette et un environnement de préprod, plus proche encore de la prod.
Une petite entreprise a-t-elle besoin d’une préprod ?
Dès que le site génère du chiffre d’affaires ou des contacts, oui, au moins pour tester les mises à jour. Pour un site vitrine qui évolue peu, une sauvegarde fiable et une préprod ponctuelle au moment des grosses mises à jour peuvent suffire.
Comment empêcher Google d’indexer la préprod ?
Protégez-la par mot de passe au niveau du serveur. Le noindex est un complément utile ; le robots.txt seul ne suffit pas.
Besoin d’une préprod pour votre site, ou d’un site livré avec ses environnements de test dès le départ ? Écrivez-nous à contact@osmova.com ou via le formulaire de contact.
