Résumé de l’articleVous manquez de temps aujourd’hui ? Voici l’essentiel en quelques lignes. Vous pourrez revenir à l’article complet plus tard. Lire le résuméMasquer le résumé
Une mise à jour, et votre menu ne s’ouvre plus. Une extension remplacée, et la boutique refuse les commandes. On préfère découvrir ces surprises avant ses visiteurs… c’est précisément à cela que sert un site de préproduction… c’est la répétition générale du site, où tout est en place sauf le public.
L’essentiel
La préproduction reprend les fichiers et la base de données de votre site à une adresse distincte, fermée au public. On peut y essayer une mise à jour, retravailler le design ou préparer une nouvelle fonction pendant que le site en ligne tourne normalement. Si une page disparaît pendant l’essai, vos visiteurs, eux, la voient toujours.
Regarder si la page d’accueil s’ouvre ne suffit pas. Un site peut sembler intact et avoir perdu une fonction importante. Sur la copie, on parcourt les pages et on essaie les formulaires, jusqu’au parcours de commande. Et les réglages doivent rester proches de ceux du site en ligne, sinon la répétition risque de réserver une surprise le soir de la première.
Cette copie doit aussi rester à sa place. Elle peut avoir emporté les données clients et les connexions aux services extérieurs. On y bloque les e-mails et on passe les paiements en mode test. L’accès se ferme par un identifiant et un mot de passe. La balise noindex demande à Google de ne pas l’afficher dans ses résultats… elle n’empêche personne d’entrer.
Une fois les essais terminés, on rapporte les changements validés sur le site en ligne en préservant ses données récentes. Recopier toute la préproduction par-dessus une boutique qui a continué à vendre, c’est risquer d’effacer les commandes qu’elle n’a jamais connues.
Ce que la lecture complète de l’article apporte en plus
Un bouton chez l’hébergeur, une extension ou une copie montée à la main peuvent fournir cet espace d’essai. L’article explique ce que chaque voie implique et les vérifications qui restent à faire après le clonage.
Vous y verrez aussi pourquoi un filtre par adresse IP placé derrière un cache peut laisser passer des pages gardées en mémoire, et pourquoi on lui préfère un identifiant et un mot de passe demandés par le serveur. Avec les recommandations des éditeurs et de la CNIL, ces repères permettent de poser les bonnes questions à celui qui entretient votre site. « Oui, nous avons une préproduction » est un début de réponse. Reste à savoir ce qu’on y teste vraiment.
Une mise à jour, et votre menu ne s’ouvre plus. Une extension remplacée, et la boutique refuse les commandes. On préfère découvrir ces surprises avant ses visiteurs… c’est précisément à cela que sert un site de préproduction.
Cette copie du site permet d’essayer les mises à jour, de retravailler une mise en page ou de vérifier une nouvelle fonction pendant que le site en ligne continue sa vie. Au théâtre, ce serait la répétition générale. On cherche ce qui coince avant de lever le rideau.
Le mot figure dans certaines offres de maintenance, la mienne comprise, entre la sauvegarde et la surveillance. Il mérite mieux qu’une ligne dans une liste. Une copie que personne ne parcourt et sur laquelle on ne vérifie rien peut attendre sagement dans son coin… elle n’aura pas rendu grand service.
En tant que web designer, je monte moi-même la préproduction des sites que j’entretiens. Les essais permettent de vérifier les changements avant de les appliquer en ligne, mais aussi les protections de la copie elle-même. Elle doit pouvoir subir le chantier sans y entraîner vos visiteurs.
Qu’est-ce qu’un site de préproduction ?
Un site de préproduction est le double de votre site, installé à côté de lui sous une adresse qui lui est propre. On parle aussi de staging, et l’idée reste la même, essayer ailleurs que devant le public.
Le double est complet. Il reprend les fichiers, c’est-à-dire WordPress lui-même, le thème, les extensions et les images, ainsi que la base de données. Cette base est le grand registre du site, un peu comme le cahier où une boutique note ses clients et ses ventes, et c’est là que sont rangés vos textes comme vos réglages.
La production, en face, est le site que vos visiteurs consultent, celui qui porte votre nom de domaine. Une modification faite sur la copie ne se reporte pas d’elle-même sur le site en ligne, et l’inverse vaut aussi. Sans nouvelle synchronisation, la copie vieillit… Les commandes et les contenus ajoutés depuis sa création n’y figurent pas.
Cette séparation se prépare. Il faut bien une copie de la base, pas deux installations qui continueraient à écrire dans les mêmes données. Et l’adresse différente ne ferme aucune porte à elle seule. La protection de l’accès fait partie du montage.
À quoi sert une préproduction ?
Une préproduction sert à essayer sur une copie tout changement qui pourrait casser le site en ligne. Et les occasions ne manquent pas.
- Les mises à jour. Une nouvelle version majeure de WordPress, d’une extension ou du thème peut modifier ce dont dépend le reste du site. Une correction plus petite peut aussi réserver une surprise. On l’essaie d’abord sur la copie.
- Le changement de version de PHP. PHP est le langage qui fait fonctionner une grande partie de WordPress, et sa version se règle sur l’hébergement. Un site qui fonctionne avec une version peut refuser la suivante, parce qu’un thème ou une extension ne la prend pas encore en charge.
- Une nouvelle fonction. Un formulaire de réservation, un nouvel élément de la boutique, etc., se montent et se règlent sans que vos visiteurs voient le chantier.
Une mise à jour qui fait disparaître une page entière est précisément le genre de surprise qu’on préfère réserver à la copie. Si quelque chose casse pendant l’essai, ça casse là, et vos visiteurs continuent de consulter le site en ligne comme si de rien n’était. On peut chercher la cause et reprendre le travail sans leur imposer les essais successifs.
Ce qu’on vérifie vraiment sur la copie
Sur la copie, on vérifie que ce qui fonctionnait fonctionne encore, puis que la nouveauté fait bien ce qu’on attend d’elle. La page d’accueil qui s’ouvre, le logo à sa place, rien qui semble avoir bougé… c’est rassurant, mais ça ne valide encore rien.
Une mise à jour peut laisser le décor intact et dérégler ce qui se passe derrière. Le menu doit toujours s’ouvrir, les liens conduire au bon endroit et les pages garder une mise en page lisible, sur téléphone comme sur ordinateur. Si l’on a changé le design, on regarde aussi les pages qui n’ont pas servi de modèle. Le bandeau d’accueil peut être impeccable pendant qu’une fiche produit déborde de son cadre.
Les fonctions importantes demandent leurs propres essais. Un formulaire se remplit et s’envoie, avec des coordonnées fictives et des messages retenus dans l’environnement de test. Sur une boutique, on ajoute un produit au panier et on parcourt la commande jusqu’au paiement fictif. WooCommerce documente ces essais. Un bouton qui a gardé sa couleur mais ne répond plus reste un bouton en panne.
On choisit les vérifications selon le changement et selon le site. Une réservation n’a pas les mêmes étapes qu’un achat, et une modification du thème appelle d’autres contrôles qu’un changement de version de PHP. Le principe ne change pas. La CNIL recommande elle aussi des tests avant la mise à disposition d’un service ou d’une mise à jour, puis un test de non-régression (la recherche de ce que le changement aurait pu dérégler) ou une revue du code avant la mise en production.
La copie doit enfin ressembler suffisamment au site en ligne pour que l’essai ait du sens. Tester une version récente sur une installation qui n’a pas été actualisée depuis des mois laisse une partie de la question sans réponse. Avant une nouvelle intervention, on regarde donc si la préproduction correspond encore au site que l’on s’apprête à modifier.
Bouton, extension ou copie montée à la main
Certains hébergeurs proposent la préproduction en un clic, et des extensions la fabriquent depuis l’administration de WordPress. Reste la copie montée à la main, qui demande un savoir-faire et permet de tout régler.
Le bouton de l’hébergeur est le chemin le plus court. WordPress.com permet d’« ajouter un site de préproduction » depuis son tableau de bord d’hébergement, et LWS le fait depuis son outil WP Manager, pour les sites de moins de 20 Go selon sa page d’aide, datée du 30 septembre 2024. Du côté des extensions, WP STAGING range par défaut sa copie dans un sous-dossier protégé du site, sur le même hébergement.
| La voie | Où vit la copie | À savoir |
|---|---|---|
| Le bouton de l’hébergeur | Chez l’hébergeur, à une adresse imposée ou choisie selon l’outil | La fonction dépend de l’offre (par exemple LWS la limite aux sites de moins de 20 Go) |
| L’extension de clonage | Dans un sous-dossier pour le montage par défaut de WP STAGING | La copie partage alors l’hébergement et l’espace disque du site en ligne |
| La copie montée à la main | Là où le prestataire la pose | Les réglages et l’isolation sont à sa charge |
Je monte mes préproductions à la main, chez le même hébergeur que le site, avec la même version de PHP et le même outil de cache, cette mémoire qui garde les pages toutes prêtes pour les servir plus vite. L’article sur les modifications qui ne s’affichent pas lui est consacré. Une mise à jour qui passe sur une copie autrement réglée ne dit pas grand-chose de ce qu’elle fera en ligne.
Le mot de passe qui ferme la copie peut toutefois faire passer ses pages à côté du cache… ce qui touche au cache se vérifie donc aussi en ligne, juste après l’intervention.
Le choix de l’outil ne dispense pas de regarder ce qu’il a copié. WP STAGING crée par défaut des tables distinctes dans la même base de données. Il permet aussi, selon la version et le montage, d’utiliser une base séparée. Sur une installation isolée par sa propre base, le compte de connexion peut être limité à celle-ci, sans droit sur la base du site en ligne. Deux copies séparées à l’écran ne disent pas encore comment les données le sont derrière.
Des essais qui restent entre les murs
La copie doit pouvoir recevoir une commande fictive ou un formulaire d’essai sans déclencher une opération chez un vrai client. Elle hérite pourtant des branchements du site, ceux qui la relient au monde réel. On les vérifie avant de commencer.
Les messages et les paiements
Une commande d’essai peut envoyer les mêmes e-mails qu’une vraie. WooCommerce le rappelle dans sa documentation, avec une précision utile, certaines extensions ou certains services peuvent ne pas distinguer les commandes fictives des autres.
Sur les copies que je monte, un verrou dans le code bloque les e-mails de WordPress, et je le mets à l’épreuve en tentant un envoi. Le message ne doit pas sortir. Les extensions qui envoient directement par un service extérieur se vérifient aussi, car elles peuvent emprunter un autre chemin. Petit effet secondaire… « Mot de passe oublié » ne vous sauvera pas la mise si le message de réinitialisation est bloqué. Les accès de la copie se notent donc dès son montage.
Le moyen de paiement d’une préproduction tourne en mode test, un réglage que proposent beaucoup de services de paiement et qui traite des paiements fictifs sans rien débiter. WooCommerce recommande d’ailleurs de faire ces essais uniquement sur une préproduction, pour éviter les complications d’un paiement de test sur le site en ligne.
Encore faut-il que la copie ne reparte pas avec les clés du vrai compte, celles qui encaissent pour de bon. WordPress.com précise que sa préproduction clone jusqu’aux clés API qui relient le site aux services extérieurs. Sur une boutique, la copie que je monte passe en mode test dès son installation.
Le reste suit la même logique. Une commande d’essai ne doit pas lancer une vraie expédition, ni modifier un stock tenu par un service extérieur que la boutique en ligne utilise aussi. Le mode test du paiement ne débranche pas tout le reste.
Un petit essai avant de commencer
Conseil
Sur la copie, utilisez le lien « Mot de passe oublié » d’un compte qui porte votre propre adresse. Si le message arrive dans votre boîte, au moins un envoi sort encore vers l’extérieur. Ce chemin-là se ferme avant les essais.
Une boîte qui reste vide ne donne pas encore le feu vert… le message peut avoir été retardé ou rejeté. Le blocage se vérifie aussi dans les réglages et le code, sans oublier les autres chemins d’envoi du site.
Les données clients ne deviennent pas fictives en changeant d’adresse
Une copie complète emporte les données réelles de vos clients. WordPress.com l’écrit pour les boutiques, toutes les données de WooCommerce sont clonées sur la préproduction, clients et commandes compris.
La CNIL recommande de travailler avec des données fictives ou anonymisées. Sa fiche de 2024 admet des données réelles en préproduction quand les données fictives ne suffisent pas, une fois les tests préalables passés et avec une protection au même niveau que le site en ligne. Mais le fait qu’un outil copie tout ne rend pas tout nécessaire. Pour vérifier un formulaire, votre carnet de clients peut rester où il est.
L’accès à la copie se limite donc aux personnes qui en ont besoin, et les données personnelles conservées doivent répondre au besoin réel de l’essai. Montrer une nouvelle mise en page ne demande pas d’ouvrir le carnet de commandes.
Une copie fermée au public
Une préproduction peut se fermer par un identifiant et un mot de passe que le serveur demande, avant même que WordPress réponde, sur une connexion HTTPS. Ce verrou couvre les pages comme les fichiers. C’est la première serrure. La seconde est la connexion à WordPress, avec ses propres identifiants. Au théâtre, ce seraient la porte de la salle et celle des coulisses.
Le noindex suffit-il à la cacher ?
La balise noindex demande à Google de ne pas garder une page dans son index, mais elle n’empêche personne de l’ouvrir. Google doit pouvoir lire la consigne pour en tenir compte. Le visiteur, lui, peut toujours entrer. Google en décrit lui-même la limite.
« Votre contenu peut continuer d’être relié à d’autres pages Web et reste accessible via un lien, mais il n’apparaît pas dans les résultats de recherche Google. »
Google Search Central, Contrôler ce que vous partagez avec Google, 31 décembre 2025
Pour un contenu privé, la même documentation recommande un mot de passe, « afin que seuls les utilisateurs autorisés puissent y accéder ». Le noindex reste utile en filet, si la serrure venait à manquer. Il ne ferme rien.
Un filtre par adresse IP suffit-il à fermer la porte ?
Un filtre par adresse IP peut laisser passer une page déjà en cache si le contrôle se fait derrière ce cache. Il réserve normalement la copie aux connexions dont l’adresse a été autorisée, celle du bureau par exemple, et il a pour lui le confort… aucun mot de passe à retenir.
Un cache de page garde en mémoire les pages déjà servies et peut les rendre sans rien redemander au serveur qui héberge WordPress. Si le filtre se trouve seulement sur ce serveur, il ne voit jamais passer ces demandes-là. Le cache a ouvert avant que le gardien puisse répondre.
J’ai fait plusieurs essais avant de choisir le verrou de mes préproductions, et j’ai retenu l’identifiant et le mot de passe que demande le serveur, parce que ce verrou-là garde la main, même derrière un cache de page.
Dans sa configuration par défaut, Varnish, un cache de page qui se place devant le serveur, laisse passer sans les garder les demandes qui portent les identifiants d’authentification. Elles arrivent jusqu’au serveur, qui vérifie avant de répondre. Les réglages de l’hébergeur peuvent changer ce comportement. Les accès sans identifiants se testent donc eux aussi, y compris sur une page ou un fichier déjà gardés en cache.
Le retour en production, sans toucher à vos commandes
Ce qui a été validé sur la préproduction doit arriver en ligne sans écraser les commandes reçues depuis. Pour une mise à jour, on peut refaire les mêmes gestes sur le site en ligne. Une refonte peut demander un transfert de fichiers et de réglages. Dans les deux cas, le piège est le même… remplacer la base actuelle par celle de la copie, qui a vieilli entre-temps.
WordPress.com permet de choisir les fichiers à synchroniser et d’inclure ou non la base de données. Ce choix compte. Des changements de mise en page peuvent être enregistrés dans la base, tandis qu’une modification de code peut tenir dans un fichier. Avant de transférer, il faut savoir où vivent les changements et ce que l’opération remplacera.
La mise en garde de WordPress.com sur les boutiques en ligne est explicite.
« Avec les sites de préproduction, vous risquez de perdre définitivement ces données (telles que les commandes et les informations client) lorsque vous remplacez le site de production par la version de préproduction. »
WordPress.com, Créer un site de préproduction, relevé le 13 octobre 2026
Après la générale, on reprend les réglages validés en répétition. Je refais donc sur le site en ligne les gestes essayés sur la copie, et les commandes arrivées entre-temps restent où elles sont. C’est plus lent qu’un bouton, mais le risque que la base de la boutique soit remplacée par son ancien double s’éloigne.
Une sauvegarde récente avant l’intervention et une vérification des fonctions importantes après la mise en ligne complètent le passage. La répétition a préparé le travail. Il reste à voir comment il se joue sur la vraie scène.
La première, sans mauvaise surprise
Une préproduction sert d’abord à chercher ce qui pourrait casser avant que vos visiteurs le découvrent. Encore faut-il y faire de vrais essais, sur une copie assez proche du site en ligne, puis rapporter les changements sans écraser ses données récentes. La fermer et couper ses branchements vers les clients permettent de faire ce travail tranquillement.
Si quelqu’un entretient votre site, demandez-lui quelles mises à jour il teste sur une copie, ce qu’il y vérifie, comment la copie est fermée et comment les changements reviennent en ligne. « Nous avons une préproduction » ne raconte pas encore ce qu’on en fait. Dans les formules de maintenance que je propose, les mises à jour critiques passent par la préproduction aux trois niveaux, et pas seulement dans le plus complet.
Le soir de la première, le public ne voit ni la générale ni les réglages de la veille. Il voit une pièce qui tient debout… et c’est tout ce qu’on lui doit.
Questions fréquentes
Qu’est-ce qu’un site de production ?
C’est le site en ligne, celui que vos visiteurs consultent à votre adresse habituelle. On l’appelle ainsi par opposition à la préproduction, sa copie d’essai fermée au public, où l’on teste les changements avant de les appliquer.
Faut-il une préproduction pour un site vitrine ?
Oui. Elle peut déjà servir sur un site de cinq pages, parce qu’une extension ou un thème peuvent y dérégler une page comme sur une boutique. L’intérêt dépend des changements à essayer et des conséquences d’une panne. Une fonction de réservation par exemple mérite qu’on regarde plus loin que la page d’accueil.
Une sauvegarde ne suffit-elle pas ?
Une sauvegarde sert à réparer après une panne, et la préproduction à la repérer avant qu’elle touche le site en ligne. Les deux se complètent, car restaurer prend du temps. Et si l’on remet une ancienne base à la place de l’actuelle, les commandes arrivées depuis peuvent disparaître avec elle.
Peut-on montrer la préproduction à quelqu’un d’autre ?
Oui, en lui confiant l’identifiant et le mot de passe du verrou, et un compte WordPress à son nom s’il doit y travailler. Si la copie contient des données clients, l’accès se limite à ceux qui en ont besoin. Une fois le travail fini, les accès devenus inutiles se retirent.
Sources
Textes officiels et institutions
- CNIL, Tester vos applications, guide RGPD du développeur, 27 janvier 2020
- CNIL, Sécurité : Encadrer les développements informatiques, 14 mars 2024
Documentation officielle d’un éditeur
- WordPress.org, Mettre en place une copie de développement de WordPress, dernière mise à jour affichée le 4 mai 2021
- WooCommerce, Testing orders (tester les commandes), consulté le 17 octobre 2026
- Varnish Software, Hooks, subroutines, and built-in VCL (fonctionnement des sous-programmes et de la configuration intégrée), consulté le 17 octobre 2026
- Varnish Software, Authentication (authentification), consulté le 17 octobre 2026
- WP STAGING, How to Create a WordPress Staging Site (créer un site de préproduction WordPress), consulté le 17 octobre 2026
- WP STAGING, Make Staging Site Publicly Available and Disable WP Staging login form (rendre une préproduction publique et désactiver son formulaire de connexion), mis à jour le 24 avril 2023, consulté le 17 octobre 2026
- Google Search Central, Contrôler ce que vous partagez avec Google, mise à jour du 31 décembre 2025
- Google Search Central, Bloquer l’indexation dans la recherche avec noindex, mise à jour du 31 décembre 2025
Documentation officielle d’un hébergeur
- WordPress.com, Créer un site de préproduction, consulté le 17 octobre 2026
- WordPress.com, Synchroniser les données entre le site de préproduction et le site de production, consulté le 17 octobre 2026
- LWS, Comment créer une version de pré-production de mon site WordPress ?, consulté le 17 octobre 2026
Ce sujet peut intéresser votre réseau ? Faites-le circuler.
