Environnement de test pour PrestaShop : monter une copie qui ne dérange personne

Tester les modifications sur une copie de la boutique avant de les mettre en production est l'une des choses les plus sensées que vous puissiez faire. Mais une copie est, par définition, une boutique complète : elle a les mêmes clients, la même configuration d'e-mail, les mêmes clés de passerelles et les mêmes tâches planifiées. Si vous ne la déconnectez pas correctement, elle fait exactement la même chose que la vraie boutique, y compris écrire à vos clients.

Cet article est une liste de ce qu'il faut neutraliser dans une copie de test, dans l'ordre où il convient de le faire.

Où la monter

Il existe trois options courantes, chacune avec ses avantages :

• En local, sur l'ordinateur du développeur ou sur un serveur interne. C'est la plus sûre, car elle n'est pas accessible depuis Internet, mais il est plus difficile de la partager avec la personne qui doit relire.
• Sur un sous-domaine du même hébergement. C'est pratique, mais elle partage le serveur avec la vraie boutique : un test lourd (une importation, une régénération d'images) prend des ressources à la production.
• Sur un serveur à part, avec la même version de PHP et la même configuration que la production. C'est l'idéal pour répéter des mises à jour, car les différences d'environnement ne vous induisent pas en erreur.

Quelle que soit l'option, la copie doit avoir la même version de PHP que la vraie boutique, sauf si c'est justement un changement de PHP que vous testez.

Étape 1 : l'e-mail, en premier

Avant même d'ouvrir la copie dans le navigateur, coupez l'e-mail. Une copie fraîchement importée a la configuration SMTP de production et une base de données avec de vrais clients. Un changement d'état de commande, un panier abandonné qu'un module décide de relancer ou une tâche planifiée qui envoie des newsletters suffisent pour écrire à une vraie personne depuis votre environnement de test.

Options, de la plus à la moins recommandée :

• Capturer l'e-mail avec un serveur SMTP de test qui reçoit tous les messages et les affiche dans une boîte de réception web sans les distribuer. Vous pouvez ainsi vérifier le rendu des e-mails sans risque.
• Désactiver l'envoi dans Paramètres avancés → E-mail, avec l'option de ne jamais envoyer d'e-mails. C'est rapide, mais vous ne pouvez pas voir les e-mails.

Étape 2 : données personnelles anonymisées

Une copie de test n'a pas besoin des vrais noms, e-mails, téléphones et adresses de vos clients. Et les conserver dans un environnement moins protégé que la production est un risque au regard de la protection des données. Remplacez, au minimum :

• Les e-mails des clients par des adresses fictives sur un domaine qui n'existe pas ou que vous contrôlez.
• Les prénoms, noms, téléphones et adresses des clients et des adresses de livraison.
• Les messages des clients, les notes internes et les données d'entreprise comme le NIF (numéro fiscal espagnol).
• Les abonnés à la newsletter et toute table de module qui stocke des données personnelles : formulaires, avis, listes d'envies.

Conservez les commandes, les montants et les produits : c'est ce dont vous avez besoin pour tester. Et changez les mots de passe des employés pour d'autres, différents de ceux de la production.

Étape 3 : paiements en mode test

Chaque passerelle a un mode test avec ses propres clés. Sur la copie, passez-les toutes dans ce mode avant de passer la première commande. Vérifiez en particulier :

• Les clés de production de la passerelle : remplacez-les par les clés de test ; ne vous contentez pas de cocher une case si le module utilise les clés qu'il a enregistrées.
• Les webhooks et notifications : la vraie passerelle continue d'envoyer ses notifications à l'URL de production, et c'est normal. Ce qui ne doit pas arriver, c'est que la copie enregistre dans le compte réel un nouveau webhook qui pointe vers elle-même.
• Le virement et le paiement à la livraison : ils n'encaissent rien, mais génèrent des e-mails au client avec des instructions. Ils sont déjà couverts si l'e-mail est capturé.

Étape 4 : que personne ne la trouve

Une copie accessible depuis Internet finit par être indexée si vous ne l'empêchez pas, et elle concurrence alors votre propre boutique dans Google avec le même contenu.

• Protection par mot de passe sur le serveur web (authentification basique). C'est le plus efficace : ni les moteurs de recherche ni les curieux ne dépassent le premier écran.
• En-tête noindex sur toutes les réponses, comme seconde couche.
• Mode maintenance de PrestaShop avec votre IP autorisée, si vous ne pouvez pas mettre de mot de passe.

Ne vous fiez pas uniquement au robots.txt : il demande aux moteurs de ne pas explorer, mais n'empêche pas qu'une URL liée depuis un autre site apparaisse dans les résultats.

Étape 5 : les connexions avec l'extérieur

C'est là que les surprises sont les plus nombreuses, car chaque boutique a les siennes :

• Tâches planifiées. Si vous copiez aussi la crontab, la copie exécutera les mêmes tâches : exports vers l'ERP, synchronisations avec les marketplaces, envois de newsletters. Désactivez-les et réactivez-les une à une seulement si vous allez les tester.
• ERP et entrepôt. Un connecteur qui crée des commandes ou met à jour le stock dans l'ERP réel est dangereux depuis une copie : il peut dupliquer des commandes ou écraser le stock avec des données de test.
• Marketplaces et flux. Un module qui publie des produits ou synchronise le stock avec une marketplace utilisera les vrais identifiants.
• Pixels de suivi et analytics. Les visites de la copie faussent les statistiques de la vraie boutique et peuvent envoyer de fausses conversions aux plateformes publicitaires.
• Transporteurs. Certains modules génèrent des étiquettes ou demandent des enlèvements via l'API du transporteur.

Étape 6 : le domaine

PrestaShop enregistre le domaine de la boutique dans la base de données (dans la table des URL de la boutique et dans la configuration). Si vous ne le changez pas, la copie redirige vers la vraie boutique dès que vous l'ouvrez. Après l'avoir changé, videz le cache et régénérez le fichier des URL simplifiées. Cherchez aussi l'ancien domaine dans la configuration des modules et dans les contenus CMS : un lien absolu vers la production dans la copie peut vous faire croire que vous testez une chose alors que vous en regardez une autre.

Vérifications avant de travailler

1. Passez une commande de test et vérifiez que l'e-mail apparaît capturé et ne part pas.
2. Cherchez dans la base de données un e-mail de client réel : il ne devrait en rester aucun.
3. Ouvrez la copie sans session depuis un autre navigateur : elle doit demander un mot de passe ou afficher la maintenance.
4. Vérifiez quelles tâches planifiées sont actives et quels modules ont des identifiants de services externes.

Une copie de ce type est un outil que vous pouvez utiliser sans crainte pour chaque mise à jour, chaque nouveau module et chaque modification du thème, et c'est la base pour maintenir la boutique à jour sans que vos clients soient ceux qui testent.

Comment le résoudre dans PrestaShop

Chez Rekire, nous travaillons toujours sur des copies de ce type : e-mail capturé, données anonymisées, passerelles en mode test et connexions externes coupées. Avec un forfait d'heures de support, nous montons la copie de votre boutique et la laissons prête pour répéter mises à jour et modifications, ou nous réalisons nous-mêmes ces modifications sur la copie avant de les mettre en production. Et si vous cherchez un hébergement pensé pour PrestaShop, le Hosting plan profesional de Rekire est notre proposition pour les boutiques qui veulent ne plus se soucier du serveur.