Pre prod : valider une version sans mettre le site en ligne en danger

La pre prod, ou préproduction, est un environnement où l’on vérifie une version d’un site ou d’une application avant de la rendre accessible aux utilisateurs. Aussi appelée staging, elle reproduit autant que possible la production pour repérer les bugs, les régressions et les problèmes de configuration. Son utilité dépend toutefois de trois conditions : un environnement représentatif, des tests pertinents et une validation organisée.

La préprod, un espace de validation entre développement et production

Le développement sert à construire et à corriger les fonctionnalités. La préproduction sert à vérifier une version candidate dans des conditions proches de son utilisation réelle. La production, enfin, correspond au service en ligne. Cette séparation permet de tester des changements sans perturber directement les visiteurs ou les clients.

Une préprod n’est donc pas simplement une copie du site sur une autre adresse. C’est un environnement contrôlé, associé à une version identifiable et à des scénarios de recette. Le terme staging désigne généralement ce même rôle, même si les appellations peuvent varier selon les équipes.

Dans l’audiovisuel, la préproduction désigne autre chose : la préparation d’un film avant sa réalisation, notamment en animation 3D ou en stop motion. Il s’agit d’une phase créative et organisationnelle, pas d’un environnement informatique.

Reproduire les conditions utiles, pas seulement l’apparence du site

Une page peut fonctionner en préprod et échouer en production si les versions du langage, de la base de données ou des bibliothèques diffèrent. Il faut donc aligner les systèmes, frameworks, dépendances et paramètres qui influencent le comportement de l’application. Les caches, les tâches planifiées et les permissions de fichiers méritent aussi une vérification.

La préproduction peut être hébergée sur une infrastructure distincte ou isolée au sein d’une même plateforme. L’essentiel est d’éviter qu’un test puisse modifier les fichiers ou la base du service réel. Docker peut faciliter la reproduction d’environnements isolés, sans garantir à lui seul une équivalence complète.

Documenter les écarts impossibles à supprimer

Reproduire exactement la production peut coûter cher, notamment pour les ressources de calcul et les services externes. Une préprod plus petite reste utile si ses limites sont explicites. Un résultat de performance obtenu sur une infrastructure réduite ne permet pas, à lui seul, de conclure au comportement du service sous sa charge réelle.

Les connexions externes doivent aussi être maîtrisées : paiement en mode test, courriels dirigés vers une boîte de contrôle, notifications sans destinataires réels. Un environnement techniquement isolé peut encore provoquer des actions réelles s’il utilise les mauvais identifiants.

Protéger les accès et préparer des données vraiment représentatives

Une préprod ne doit pas être considérée comme publique par défaut. Protégez-la par une authentification et, selon les besoins, des restrictions réseau. Donnez à chacun uniquement les permissions nécessaires, retirez les accès devenus inutiles et utilisez des secrets distincts de ceux de production. Une consigne de non-indexation ne constitue pas une protection contre les accès non autorisés.

Les données synthétiques, créées pour les tests, évitent de recopier inutilement des informations personnelles. Une extraction de production peut être envisagée après une anonymisation effective et contrôlée. Remplacer uniquement les noms ne suffit pas si d’autres champs permettent encore de reconnaître une personne.

Pensez au jeu de données comme à une graine reproductible : conservez une recette permettant de recréer les mêmes comptes, commandes et exceptions après chaque remise à zéro. Ajoutez volontairement un panier vide, une adresse incomplète, un produit indisponible ou un historique volumineux. Ce petit « patrimoine de cas limites » permet de reproduire un bug et de vérifier sa correction, au lieu de dépendre d’une base remplie au hasard.

La structure et le volume comptent autant que les valeurs. Une recherche rapide sur quelques fiches peut ralentir sur un catalogue beaucoup plus fourni. Prévoyez donc des données cohérentes avec les usages attendus, ainsi qu’une procédure de rafraîchissement qui ne réintroduit pas d’informations sensibles.

Tester les parcours, les échanges et les effets de bord

La recette doit partir des actions importantes pour l’utilisateur, pas seulement des pages modifiées. Pour une boutique, cela peut couvrir la recherche d’un produit, son ajout au panier, le paiement de test et la confirmation de commande. Chaque parcours doit avoir un résultat attendu explicite.

• Tests fonctionnels : vérifier que chaque fonctionnalité répond aux règles métier, y compris en cas de saisie incorrecte.
• Tests d’intégration : contrôler les échanges entre l’application, la base de données et les services externes.
• Tests de non-régression : vérifier que les fonctionnalités existantes restent opérationnelles après le changement.
• Tests de performance : observer les temps de réponse et les ressources consommées dans des conditions documentées.

Sur un site web, complétez ces contrôles par les affichages mobiles, les droits des différents profils et les comportements après expiration d’une session. Consultez aussi les journaux d’erreurs : un écran apparemment correct peut masquer une requête en échec ou un traitement incomplet.

Attribuer clairement la validation

Les développeurs vérifient la cohérence technique et corrigent les anomalies. L’assurance qualité, ou QA, organise les tests et leur traçabilité. Le responsable produit ou le client confirme que le résultat répond au besoin métier. L’exploitation vérifie les conditions de déploiement et de surveillance. Dans une petite équipe, une même personne peut cumuler ces rôles, mais les décisions doivent rester explicites.

Déployer la version validée et préparer le retour arrière

Le passage en production ne consiste pas à recopier toute la préprod. On déploie le code et les changements prévus, sans écraser les commandes, comptes ou contenus créés entre-temps sur le site réel. Git permet de suivre les modifications et d’identifier précisément la version validée.

1. Intégrer les changements et exécuter les contrôles automatisés.
2. Déployer une version identifiée en préproduction.
3. Réaliser la recette, corriger en développement, puis tester à nouveau.
4. Consigner la validation et préparer sauvegardes, migrations et retour arrière.
5. Déployer la même version en production, puis contrôler les parcours critiques et les erreurs.

Une chaîne automatisée, par exemple avec Jenkins, rend ces étapes plus reproductibles. Lorsque c’est possible, promouvoir le même artefact — le paquet applicatif construit et testé — évite de reconstruire une version potentiellement différente après validation.

Le retour arrière doit être préparé avant la livraison. Revenir au code précédent ne suffit pas toujours : une migration de base de données peut rendre cette version incompatible. Il faut prévoir une stratégie adaptée, tester la restauration lorsque nécessaire et définir qui décide d’interrompre le déploiement.

Enfin, toute correction doit repasser par le circuit de validation. Modifier directement la préprod crée un écart invisible avec le code suivi. Une préproduction fiable reste un environnement reproductible, dont on connaît la version, les données et les limites.