Une checklist de mise en ligne se parcourt en cliquant : on passe une commande, on regarde le site sur son téléphone, on relit ses mentions légales. C’est nécessaire, et ça attrape tout ce qui est visible.
Le problème, c’est que les incidents qui ruinent réellement un lancement ne sont pas visibles. Ils sont même souvent invisibles précisément pour la personne qui fait la vérification, parce que sa configuration l’en exempte. Le site marche parfaitement pour elle et pour personne d’autre.
Cette page contient donc les deux niveaux : la vérification fonctionnelle, qui se fait au clic, puis les contrôles qui se font en base ou en ligne de commande et qu’aucun parcours de recette ne remplace.
Au programme :
- Le parcours d’achat testé comme un vrai client, réduit à l’essentiel
- Les cinq contrôles qui ne se cliquent pas, avec les requêtes correspondantes
- Le mode maintenance dont la personne qui vérifie est exemptée
- La requête unique qui affiche l’état complet de la configuration de mise en ligne
- Ce qu’une checklist ne peut pas attraper
Le parcours d’achat, testé comme un vrai client
Le test le plus rentable reste le plus bête : passer une commande complète en partant de Google, pas du back-office. Depuis une navigation privée, avec un compte créé pour l’occasion, jusqu’à la réception du colis.
Les points où ça casse le plus souvent, dans l’ordre :
- Les frais de port et la TVA selon le pays et le transporteur choisis, y compris pour une destination hors métropole
- Le tunnel sur un vrai téléphone, pas dans le simulateur du navigateur : le choix du transporteur et du moyen de paiement sur petit écran est l’endroit où les paniers meurent
- Les e-mails transactionnels, envoyés vers au moins trois adresses de fournisseurs différents pour voir lesquels partent en indésirable
- Le tunnel de retour, presque jamais testé alors qu’il conditionne la confiance
- Le back-office en conditions réelles : rembourser partiellement, annuler avec notification, modifier un stock. Si ces trois gestes ne sont pas fluides, le marchand le paiera tous les jours
- La présence effective de chaque moyen de paiement sur l’appareil concerné. Certains ne s’affichent que sous conditions et disparaissent sans erreur quand elles ne sont pas remplies, ce qui est exactement le mode d’échec d’Apple Pay
Et une vérification de conformité au cahier des charges, ligne par ligne, parce que c’est à ce moment qu’on découvre que le programme de fidélité n’a jamais été branché.
Les cinq contrôles qui ne se cliquent pas
Voici ceux qui manquent à toutes les checklists, et qui sont précisément ceux qui font les lancements ratés.
1. Le domaine est stocké deux fois, et vous n’en changez souvent qu’un
La table qui porte l’identité de la boutique comporte deux colonnes de domaine, pas une :
CREATE TABLE `PREFIX_shop_url` (
`id_shop_url` int(11) unsigned NOT NULL AUTO_INCREMENT,
`id_shop` int(11) unsigned NOT NULL,
`domain` varchar(255) NOT NULL,
`domain_ssl` varchar(255) NOT NULL,
`physical_uri` varchar(64) NOT NULL,
`virtual_uri` varchar(64) NOT NULL,
`main` TINYINT(1) NOT NULL,
`active` TINYINT(1) NOT NULL,
...
)
Une boutique en HTTPS utilise domain_ssl. Corriger uniquement domain après une bascule, ce qui est l’erreur la plus courante, ne produit donc aucun effet visible dans un navigateur qui arrive déjà par la bonne URL.
Sauf que PrestaShop reconstruit les URL canoniques à partir de cette table, et que PS_CANONICAL_REDIRECT est actif par défaut. Autrement dit, si domain_ssl pointe encore vers la préproduction, le site de production redirige ses visiteurs vers la préproduction. Vous ne le verrez pas si votre onglet est déjà ouvert sur la recette.
2. Le mode maintenance dont vous êtes exempté
C’est le plus beau piège du lot, parce que la personne qui vérifie est la seule à ne pas le subir. Voici le code qui décide :
// classes/controller/FrontController.php (PrestaShop 9.0.0)
protected function displayMaintenancePage()
{
if ($this->maintenance == true || !(int) Configuration::get('PS_SHOP_ENABLE')) {
$this->maintenance = true;
if (Tools::isAllowedToBypassMaintenance()) {
return;
}
$allowed_ips = array_map('trim', explode(',', Configuration::get('PS_MAINTENANCE_IP')));
if (!IpUtils::checkIp(Tools::getRemoteAddr(), $allowed_ips)) {
header('HTTP/1.1 503 Service Unavailable');
header('Retry-After: 3600');
Votre adresse IP figure dans PS_MAINTENANCE_IP depuis la recette, donc vous traversez. Tout le monde reçoit un 503 Service Unavailable avec un Retry-After d’une heure, ce qui invite explicitement les robots à repasser plus tard et à ne rien indexer.
Le contrôle qui l’attrape, à faire depuis une connexion qui n’est pas la vôtre, par exemple en partage de connexion mobile :
curl -s -o /dev/null -w 'code %{http_code}\n' https://boutique.fr/
Un 503 ici et vous venez d’éviter un lancement fantôme.
3. Le robots.txt de la préproduction voyage avec les fichiers
Le fichier n’est pas dynamique. Il est écrit sur le disque, à la racine :
// classes/Tools.php
public static function generateRobotsFile($executeHook = false)
{
$robots_file = _PS_ROOT_DIR_ . '/robots.txt';
Rien ne le régénère automatiquement. Un robots.txt de recette contenant Disallow: /, copié avec le reste des fichiers, reste en place indéfiniment. La boutique fonctionne parfaitement, elle vend, et Google ne l’explore jamais. Le symptôme n’apparaît qu’au bout de plusieurs semaines, sous la forme d’une absence.
4. Les URL simplifiées dépendent d’un fichier généré
Activer PS_REWRITING_SETTINGS ne suffit pas : les règles de réécriture vivent dans un .htaccess que PrestaShop régénère, et qui contient un bloc par domaine déclaré. Après un changement de domaine, sans régénération depuis le back-office, les URL simplifiées renvoient des 404 sur des pages qui existent.
5. Les e-mails partent encore par le SMTP de recette
La clé PS_MAIL_METHOD et les paramètres associés survivent à la copie de base. Le cas le plus embêtant n’est pas l’absence d’envoi, qui se voit, mais un SMTP de test qui accepte tout et ne délivre rien, ou qui délivre depuis un domaine sans enregistrement d’authentification. Les mails partent, le back-office les considère envoyés, et ils finissent en indésirable.
La requête qui affiche tout d’un coup
Plutôt que de vérifier ces points un par un dans six écrans différents, une seule requête donne l’état complet :
SELECT name, value
FROM ps_configuration
WHERE name IN (
'PS_SHOP_ENABLE', -- 1 attendu, sinon 503 pour tout le monde
'PS_MAINTENANCE_IP', -- doit être vide en production
'PS_SSL_ENABLED', -- 1 attendu
'PS_CANONICAL_REDIRECT', -- redirige d'après shop_url
'PS_REWRITING_SETTINGS', -- URL simplifiées
'PS_MAIL_METHOD',
'PS_SHOP_NAME' -- pas « My Shop »
)
ORDER BY name;
SELECT id_shop, domain, domain_ssl, physical_uri, virtual_uri, main, active
FROM ps_shop_url;
La lecture prend dix secondes. PS_SHOP_ENABLE à 0, un PS_MAINTENANCE_IP non vide, ou un domain_ssl différent de domain : chacun de ces trois cas est un lancement raté qui ne se serait vu que plusieurs jours plus tard.
Et deux contrôles de fichiers pour compléter :
# Le robots.txt bloque-t-il tout le site ?
grep -E '^Disallow: /$' robots.txt && echo 'ALERTE : site entièrement bloqué'
# Le mode debug est-il resté actif ? (stack traces exposées aux clients)
grep -n "_PS_MODE_DEV_" config/defines.inc.php
Sur le mode debug, notez que le fichier du dépôt officiel porte lui-même l’avertissement : « Don’t forget to disable debug mode in production, produces a significant performance hit. » Le back-office écrit directement dans ce fichier, donc une restauration de fichiers peut le réactiver sans que personne ne touche à l’interface.
Contenus et mentions obligatoires
La partie qui n’a rien de technique mais dont l’oubli coûte le plus cher juridiquement. À avoir en ligne et accessible depuis le pied de page avant la première vente :
- Mentions légales complètes : raison sociale, adresse du siège, contact, SIRET, hébergeur, directeur de publication
- CGV : commande, paiement, livraison, droit de rétractation, service après-vente
- Politique de confidentialité décrivant la collecte et le traitement des données
- Bandeau cookies conforme, avec consentement préalable au dépôt de traceurs
- Médiateur de la consommation désigné, obligatoire pour la vente aux particuliers
Un piège récurrent : de nombreux thèmes affichent encore des contenus de démonstration, du type « Mon entreprise » ou une adresse d’exemple, dans des blocs que personne ne pense à ouvrir parce qu’ils sont dans le pied de page ou dans un module de réassurance.
Côté référencement, l’essentiel tient en quatre points : les URL simplifiées activées, des balises title et description renseignées sur les pages qui comptent, un sitemap généré et soumis, et l’indexation qui n’est bloquée nulle part. Le reste du travail viendra après, mais ces quatre-là se réparent mal une fois que Google s’est fait une idée.
Ce qu’une checklist ne peut pas attraper
Autant être honnête sur les limites de l’exercice.
Elle ne teste qu’un instant. Une boutique qui répond bien le jour du lancement peut s’écrouler à la première vraie affluence, parce que la recette s’est faite à trois personnes sur un serveur au repos. La charge ne se vérifie pas au clic.
Elle ne teste que les chemins prévus. Les incidents des premières semaines viennent presque toujours de combinaisons que personne n’avait imaginées : un code promo cumulé avec une remise de quantité sur un produit en rupture partielle, une adresse de livraison dans un pays activé par erreur.
Elle ne dit rien de ce qui va dériver. Les configurations vérifiées le jour J changent : un module s’installe, une restauration de fichiers réactive le mode debug, un changement de domaine casse les réécritures. C’est la raison d’être d’une surveillance continue plutôt que d’une vérification unique, et c’est aussi pourquoi ces contrôles gagnent à être scriptés plutôt que recopiés dans un document partagé.
Et elle ne remplace pas un plan de retour arrière. Savoir en combien de temps vous pouvez revenir à l’état d’avant vaut mieux que d’espérer n’en avoir jamais besoin.
Le bon ordre
Si vous ne devez retenir qu’une séquence, la voici, du moins coûteux au plus coûteux à réparer.
- La requête de configuration et les deux contrôles de fichiers, dix minutes
- Un
curldepuis une connexion extérieure, pour éliminer le 503 - Une commande complète depuis une navigation privée, sur un vrai téléphone
- Les e-mails transactionnels vers trois fournisseurs différents
- Les mentions obligatoires et les contenus de démonstration résiduels
- La conformité au cahier des charges, ligne par ligne
Les deux premières étapes prennent un quart d’heure et attrapent les pannes les plus coûteuses, celles qui ne produisent aucun symptôme visible. Commencer par elles est ce qui distingue une recette d’une inspection.
Questions fréquentes
Mon site est en ligne mais les visiteurs ne voient rien, alors que tout marche pour moi.
Votre adresse IP est probablement dans PS_MAINTENANCE_IP alors que PS_SHOP_ENABLE vaut 0. Tout le monde reçoit un 503. Vérifiez depuis une connexion extérieure avec un curl, jamais depuis votre poste.
Pourquoi mon site redirige-t-il vers la préproduction ?
Parce que la table ps_shop_url contient deux colonnes de domaine et que domain_ssl n’a pas été mis à jour. Comme la boutique est en HTTPS, c’est celle-là qui sert à construire les URL canoniques.
Mes URL simplifiées renvoient des 404 après le changement de domaine.
Le .htaccess contient un bloc de réécriture par domaine déclaré et n’a pas été régénéré. Passez par le back-office pour le reconstruire.
Google n’indexe rien depuis le lancement.
Vérifiez le robots.txt à la racine. C’est un fichier écrit sur le disque, rien ne le régénère à la mise en ligne, et celui de la préproduction voyage avec les fichiers.
Faut-il tout tester sur un vrai téléphone ?
Au moins le tunnel de commande. Le simulateur du navigateur ne reproduit ni le clavier virtuel, ni les redirections des applications de paiement, ni le comportement réel des sélecteurs de transporteur.
Combien de temps prévoir pour cette recette ?
Comptez une journée pour une boutique standard, et davantage si le cahier des charges comporte des fonctionnalités spécifiques. Les contrôles de configuration, eux, prennent un quart d’heure et devraient être faits en premier.
Vous préparez une mise en ligne et vous voulez que quelqu’un passe derrière avant d’appuyer sur le bouton ? Commencez par la requête de configuration ci-dessus. Si un des trois pièges principaux ressort, écrivez-nous avant le jour J plutôt qu’après.
