Les cinq couches, de la plus proche du code à la plus proche du visiteur

1. Le cache Smarty (gabarits)

PrestaShop compile vos fichiers .tpl en PHP. Tant que la version compilée existe, votre modification de gabarit reste invisible. Réglage dans Paramètres avancés → Performances : « Recompiler les gabarits si les fichiers ont été mis à jour » en développement, « Ne jamais recompiler » en production.

Piège fréquent : PrestaShop se base sur la date de modification du fichier. Un transfert FTP qui préserve l’horodatage d’origine peut donc passer inaperçu.

2. Le cache du cœur (var/cache/)

Conteneur de services, routes, traductions, définitions de modules. C’est lui qui garde en mémoire qu’un module existe, quels hooks il utilise, quelles classes il surcharge. Après avoir ajouté un override ou modifié la configuration d’un module, c’est ce cache qu’il faut vider — par le back-office, ou en supprimant le contenu du dossier par FTP.

3. Le CCC (CSS et JavaScript combinés)

La couche qui fait perdre le plus de temps. Activé, le CCC fusionne vos feuilles de style et vos scripts en un fichier unique, servi avec un nom construit à partir de son contenu, et mis en cache longtemps.

Conséquence : vous modifiez custom.css, vous videz le cache, et le navigateur continue de charger l’ancien paquet. La parade la plus fiable, celle que j’utilise systématiquement sur les boutiques en production, consiste à changer le nom du fichier (custom.css devient custom-2.css, avec la référence mise à jour). Une nouvelle adresse ne peut pas être servie depuis un cache : c’est imparable.

4. Le cache pleine page

Module dédié ou cache serveur : la page HTML complète est stockée et renvoyée sans exécuter PHP. Excellent pour la vitesse, redoutable en développement, car plus rien de ce que vous changez côté PHP n’a d’effet visible tant que la page en cache n’est pas invalidée.

Vérifiez sa présence en regardant les en-têtes de réponse de vos pages : les modules de cache y ajoutent presque toujours une mention de leur état. Beaucoup tournent aussi en mode test, où ils annoncent un cache actif sans rien mettre en cache — un détail qui explique bien des mesures de performance contradictoires.

5. CDN et navigateur

Si vos fichiers statiques passent par un CDN, il conserve sa propre copie, avec sa propre durée de vie. Et votre navigateur garde la sienne. Pour tester : fenêtre de navigation privée, ou rechargement forcé. Mais attention — votre navigateur n’est pas celui de vos clients : ne concluez jamais « c’est bon » sur la seule foi de votre propre écran.

Diagnostiquer en trois minutes

La question à se poser est toujours : quelle couche sert encore l’ancienne version ?

  1. Ouvrez la page en navigation privée. Si la modification apparaît, c’est votre navigateur — rien à corriger côté serveur.
  2. Regardez l’adresse du fichier CSS ou JS chargé dans les outils de développement. Si c’est un fichier combiné, vous avez affaire au CCC.
  3. Ouvrez directement l’adresse du fichier concerné. Votre modification y figure-t-elle ? Si oui, le fichier est bien déployé et le problème est en aval. Si non, le transfert a échoué — ou vous avez modifié un autre fichier que celui réellement chargé.
  4. Ajoutez un paramètre inutilisé à l’adresse de la page (par exemple ?test=1). Si la page change de comportement, un cache pleine page est en jeu.
  5. Vérifiez les en-têtes de réponse pour repérer un cache serveur ou un CDN.

En trois minutes, vous savez laquelle des cinq couches vous bloque.

Le bon réglage selon le contexte

En développement ou en préproduction

  • Smarty : recompiler à chaque modification, cache Smarty désactivé.
  • CCC : tout désactivé.
  • Cache pleine page : désactivé.
  • Mode debug activé — sur un environnement non public uniquement.

Vous perdez en vitesse, vous gagnez en certitude. C’est le bon compromis quand on travaille.

En production

  • Smarty : ne jamais recompiler, cache activé.
  • CCC : activé, en gardant en tête qu’un déploiement CSS exige de régénérer le paquet.
  • Cache pleine page : activé, avec les bonnes exclusions — panier, tunnel de commande, compte client, et tout bloc qui dépend du visiteur.

Cette dernière précision est essentielle : un cache pleine page mal exclu peut servir à un client le panier d’un autre. C’est le genre d’incident dont une boutique se remet difficilement en termes de confiance.

Les pièges qui font perdre des heures

Vider le cache ne régénère pas le paquet CCC. C’est la cause numéro un du « j’ai pourtant vidé le cache ». Renommer le fichier reste la solution la plus fiable.

Le back-office affiche la modification, pas la boutique. Normal : ce sont deux contextes distincts, avec des caches distincts. Testez toujours côté client.

Le cache par boutique en multiboutique. Certains caches sont segmentés par identifiant de boutique. Vider depuis une boutique ne vide pas les autres.

Le FTP qui conserve la date d’origine. Si votre client FTP préserve l’horodatage, PrestaShop peut considérer le fichier comme inchangé. Vérifiez la date sur le serveur après envoi.

Le cache du module de cache. Certains modules de performance conservent leur propre index, qui survit au vidage du cache PrestaShop. Il faut le purger depuis la configuration du module lui-même.

La méthode que j’applique en production

Sur une boutique qui vend, je ne bascule jamais les réglages de cache en mode développement : cela dégrade la vitesse pour tous les visiteurs pendant la durée de l’intervention. Je procède autrement :

  1. Les fichiers statiques sont versionnés par leur nom. Chaque déploiement CSS ou JS passe par un nouveau nom de fichier. Aucun cache ne peut servir l’ancien.
  2. Je teste en préproduction, où tous les caches sont désactivés, avant d’envoyer quoi que ce soit en production.
  3. Je purge dans l’ordre : cache du module de performance, puis cache PrestaShop, puis CDN le cas échéant.
  4. Je vérifie côté visiteur, en navigation privée et sur un vrai téléphone — pas seulement dans le simulateur mobile du navigateur.

Cette discipline évite l’essentiel des « ça ne marche pas » qui n’en sont pas. C’est aussi ce qui distingue une intervention propre d’un bricolage : sur les boutiques que je suis en maintenance, les déploiements suivent toujours ce chemin.

Checklist

  • Tester d’abord en navigation privée pour écarter le cache navigateur
  • Identifier si le fichier chargé est un paquet combiné (CCC)
  • Ouvrir directement l’adresse du fichier pour vérifier son contenu réel
  • Renommer le fichier statique plutôt que d’espérer une purge complète
  • Vider var/cache/ après tout ajout d’override ou de module
  • Vérifier la présence d’un cache pleine page dans les en-têtes de réponse
  • Purger le CDN si vos fichiers statiques passent par lui
  • Contrôler que le tunnel de commande est exclu du cache pleine page
  • Vérifier le résultat sur un vrai appareil mobile

Questions fréquentes

Faut-il désactiver le CCC ?

En production, non : il réduit le nombre de requêtes et le poids des fichiers. Le désactiver pour se simplifier la vie revient à faire payer à vos visiteurs le confort du développeur. En préproduction, en revanche, désactivez-le sans hésiter.

Mon module de cache pleine page semble actif mais rien n’est mis en cache.

Vérifiez s’il n’est pas en mode test : plusieurs modules de performance proposent ce mode, où ils se comportent comme actifs sans rien mettre en cache. Les en-têtes de réponse le disent en général explicitement. J’ai déjà vu une boutique tourner des mois ainsi, en croyant bénéficier d’un cache qui ne servait rien.

Pourquoi mes clients voient-ils encore l’ancienne version ?

Parce que leur navigateur a mis en cache un fichier dont l’adresse n’a pas changé, souvent avec une durée de vie longue. Vous ne pouvez pas purger le cache de vos visiteurs à distance : la seule solution fiable est de changer l’adresse du fichier.

Le cache peut-il causer des erreurs, pas seulement de l’affichage figé ?

Oui. Un cache du cœur corrompu, référençant des classes supprimées, provoque des erreurs 500 ou des pages blanches. C’est d’ailleurs pourquoi vider var/cache/ est le premier geste de tout dépannage PrestaShop.