Agence PrestaShop à Aix-en-Provence : faire auditer une boutique devenue lente

Votre boutique allait vite. Maintenant, chaque page met du temps à s’ouvrir.

Vos clients partent avant d’acheter, et personne ne sait dire pourquoi. Cet article vous aide à trouver une agence PrestaShop à Aix-en-Provence capable de repérer la cause.

• Agence PrestaShop à Aix-en-Provence : auditer une boutique devenue lente
• Un audit de boutique lente combine tests contrôlés et données terrain
• Cache, modules et serveur demandent des corrections différentes
• Hébergement et CDN n’agissent pas sur les mêmes ralentissements
• Images et scripts peuvent alléger les pages, avec des tests
• Les tarifs d’audit dépendent du périmètre et des corrections
• Foire aux questions

Agence PrestaShop à Aix-en-Provence : auditer une boutique devenue lente

500 à 1 500 € HT^* pour un audit de performance PrestaShop. Le prix varie selon le nombre de pages, de modules et le niveau de diagnostic demandé. Une agence à Aix-en-Provence ne suffit pas : vérifiez ses références PrestaShop et sa capacité à analyser le serveur.

Avant de contacter une agence PrestaShop à Aix-en-Provence, vérifiez ces points

Cochez ce qui est clair dans le devis ou la réponse de l’agence avant de signer.

• Vous avez les références d’au moins deux boutiques comparables, même version de PrestaShop et taille de catalogue proche.

  Une boutique de 200 produits ne présente pas les mêmes risques qu’un site de 30 000 références relié à un ERP.

• Le devis précise les pages testées : accueil, catégorie, fiche produit, panier et tunnel de commande.

  Sans ce périmètre, l’audit peut passer à côté du vrai ralentissement.

• L’agence teste sur mobile et sur ordinateur, avec un visiteur connecté et non connecté.
• Vous savez quels accès vous donnerez : Back Office, fichiers, base de données et statistiques du serveur.

  Sans eux, l’agence ne peut pas savoir si le ralentissement vient d’une image, d’une requête PHP ou d’un module.

• Le rapport prévu contient les mesures avant intervention, les URL testées et un plan d’action chiffré.

  Chaque recommandation doit indiquer la difficulté, le temps prévu, le risque et le gain attendu.

• L’audit et les corrections apparaissent sur deux lignes distinctes du devis.

  Vous savez ainsi ce que vous payez pour le diagnostic et ce que vous payez pour l’intervention.

• Une copie de préproduction est prévue avant toute modification des modules de paiement ou de transport.

  Ne coupez jamais directement un module de paiement ou de transport en production.

Points cochés : sur 7. Rien n'est envoyé ni enregistré : la liste reste dans votre navigateur.

Une adresse à Aix-en-Provence ne garantit pas l’expertise

Vérifiez l’adresse dans les mentions légales et contrôlez le numéro SIRET. Une agence peut travailler à distance. Elle doit pourtant dire qui réalisera les mesures et où se trouve son équipe.

L’annuaire officiel des agences PrestaShop certifiées donne un premier repère. Il ne remplace pas une discussion technique.

Demandez deux références comparables. Elles doivent utiliser la même version de PrestaShop, avoir un catalogue de taille proche et partager vos modules de paiement ou de livraison. Une boutique de 200 produits ne présente pas les mêmes risques qu’un site de 30 000 références relié à un ERP.

Comment évaluer le devis ? Regardez d’abord les pages et les situations que l’agence prévoit de tester.

Le devis doit préciser les pages, les appareils et les accès

Un audit exploitable couvre au minimum l’accueil, une catégorie, une fiche produit, le panier et le tunnel de commande. Les tests doivent porter sur mobile et ordinateur, avec un visiteur connecté comme non connecté.

L’agence a besoin d’un accès temporaire au Back Office, aux fichiers, à la base de données et aux statistiques du serveur. Sans eux, elle observe le navigateur sans savoir si le ralentissement vient d’une image lourde, d’une requête PHP ou d’un module appelé dans un hook (point d’accroche du code).

Il faut croiser quatre compétences : PrestaShop, PHP, base de données et infrastructure web. Un score PageSpeed ne repère pas seul un module qui ajoute une requête sur chaque fiche produit.

Un rapport de 15 à 30 pages doit déboucher sur des décisions

15 à 30 pages suffisent en général. Le rapport doit contenir les mesures avant intervention, les URL testées, les causes probables, les risques fonctionnels et un plan d’action chiffré. Pour chaque recommandation, demandez la difficulté, le temps prévu, le risque et le gain attendu.

« Optimiser les modules » ne vous dit pas quoi faire. « Désactiver le module de bandeau sur les pages produit, vérifier le panier, puis comparer le temps serveur sur trois passages » est une consigne que votre équipe peut contrôler.

Comptez 600 à 900 € HT^* pour l’audit, puis 1 000 à 3 500 € HT^* pour les corrections courantes. Ce budget convient à une boutique de moins de 3 000 produits. Demandez que l’audit et les corrections apparaissent sur deux lignes distinctes du devis.

Décrire mon besoin →

Un audit de boutique lente combine tests contrôlés et données terrain

Un audit fiable croise les tests contrôlés et les données de vrais visiteurs. PageSpeed Insights associe les mesures de laboratoire de Lighthouse aux données terrain du Chrome User Experience Report. Ces dernières sont calculées sur 28 jours glissants.

Les seuils Core Web Vitals servent de premier repère

• LCP : 2,5 secondes est le seuil d’un bon résultat. Cette mesure porte sur l’affichage du contenu principal.
• INP : 200 millisecondes est le seuil recommandé. Elle mesure la réactivité après une interaction.
• CLS : 0,1 est le seuil à viser. Il mesure les déplacements inattendus de la page.

Ces seuils se lisent au 75e percentile. Ce n’est pas le meilleur essai de votre ordinateur. Une fiche produit peut sembler rapide sur une fibre, mais rester lente sur un téléphone moins puissant.

Une page peut se charger vite et réagir mal au changement de déclinaison. Le LCP mesure le chargement, l’INP l’interaction, le CLS la stabilité visuelle.

PageSpeed donne un résultat, pas toujours sa cause

Les données terrain tiennent compte des appareils, des réseaux et des lieux de vos clients. Elles montrent si le problème vous touche, mais elles évoluent lentement.

Pour les tests contrôlés, lancez un profil mobile cache vidé, puis un profil ordinateur. Gardez les mêmes URL, le même ordre de navigation et le même nombre de passages. Testez au moins quatre types de pages :

• Accueil : elle permet de repérer le poids du thème, des bannières et des scripts marketing.
• Catégorie : elle met en évidence le coût des images, des filtres et du tri.
• Produit : elle révèle l’effet des déclinaisons, des avis, des recommandations et des modules branchés sur les hooks.
• Panier et commande : ces pages font ressortir les appels externes, les calculs de transport et les extensions de paiement.

Faites trois à cinq passages par mesure. Un cache déjà rempli ou une tâche planifiée peut fausser un essai isolé. Après chaque correction, reprenez le même protocole.

Cache, modules et serveur demandent des corrections différentes

Le cache, les modules et le serveur ne se règlent pas de la même façon. Mesurez d’abord, modifiez ensuite, puis comparez le résultat à une valeur de référence. PrestaShop le recommande.

Un réglage de cache adapté évite de ralentir la boutique

En production, réservez « Force compilation » au développement. Ce réglage ralentit le chargement. Pour une boutique en ligne, gardez plutôt le cache avec recompilation après modification seulement.

Le cache Smarty porte sur les modèles d’affichage. Selon la configuration du serveur, le cache PrestaShop peut aussi concerner les données.

La CCC combine, compresse et met en cache les CSS et JavaScript. Elle allège la page, mais peut casser un thème ou un module. Faites une sauvegarde avant de l’activer, puis contrôlez le menu, la recherche, le panier et le paiement.

Un module peut ajouter du temps à chaque page

L’audit doit relever le nom du module, sa version, sa compatibilité avec PrestaShop, les hooks qu’il utilise et les pages qu’il touche. Un module injecte du contenu ou modifie le fonctionnement de la boutique grâce à des hooks, des points d’accroche du code.

Comparez une page avec le module actif à la même page sur une copie de préproduction où il est désactivé. Ne coupez jamais directement un module de paiement ou de transport en production.

Rattachez les requêtes SQL lentes, les appels à une API externe et les traitements à chaque affichage à un module ou une page. Une liste brute de requêtes ne vous dira pas quoi corriger.

La version de PHP doit rester compatible avec la boutique

PrestaShop 8 recommande PHP 8.1. Pour PrestaShop 9, vérifiez les versions de PHP, les extensions et la mémoire disponible. Une mise à jour de PHP peut rendre un ancien module incompatible.

Avant toute mise à jour, préparez une copie de préproduction. Testez la connexion client, la commande, le paiement, le transport, les emails, les imports et le Back Office.

Prévoyez 12 à 24 mois si vous voulez faire évoluer la boutique vers PrestaShop 9. L’architecture mêle code historique, Symfony et Twig. Un correctif rapide ne doit pas alourdir davantage votre dette technique.

Décrire mon besoin →

Hébergement et CDN n’agissent pas sur les mêmes ralentissements

Un nouvel hébergement ne corrigera pas une image trop lourde. Un CDN ne réparera pas une requête PHP lente. L’audit doit donc séparer trois choses : le temps de réponse du serveur, le téléchargement des ressources et leur affichage dans le navigateur.

Le temps de réponse du serveur est un premier signal

Mesurez le TTFB : le délai entre la demande du navigateur et la réception du premier octet. Un TTFB élevé vient souvent de PHP, de la base de données ou d’un cache absent.

Comparez l’hébergement à la charge réelle : trafic moyen, pics de commandes, nombre de produits, imports et tâches cron. Une offre mutualisée peut suffire à 100 commandes par mois. Elle saturera pendant une campagne publicitaire.

Un serveur plus puissant se justifie si les processus PHP attendent, si la mémoire manque ou si la base de données sature le processeur. Une agence sérieuse doit montrer ces mesures avant de recommander un changement.

Un CDN accélère surtout les ressources statiques

Demandez au prestataire quels dossiers sont mis en cache, pendant combien de temps et selon quelles règles d’invalidation. Les images, le thème et certains fichiers de module s’y prêtent bien.

Les fichiers liés aux sessions, aux comptes clients et au paiement demandent plus de prudence.

Le gain varie selon la distance au serveur, le taux de cache et le poids des fichiers. Il profite surtout à une boutique qui reçoit des visiteurs européens. Il profite moins à une boutique dont les clients habitent tous la même ville.

Une migration de serveur se contrôle avant et après la bascule

Comptez un à trois jours ouvrés pour une migration simple, plus une période de surveillance. Le délai augmente si le DNS, les emails, les tâches planifiées, les certificats TLS ou les connexions à l’ERP changent.

La bascule se prépare en trois étapes :

1. Copiez les fichiers et la base, puis réduisez le délai DNS si nécessaire.
2. Testez le domaine temporaire.
3. Après la bascule, contrôlez les commandes, les stocks, les emails, les imports, les webhooks et les redirections.

Mesurez le même échantillon de pages avant et après le transfert. Le gain doit se voir dans le TTFB, les temps de chargement et les données terrain. Un score Lighthouse obtenu une seule fois ne suffit pas.

Décrire mon besoin →

Images et scripts peuvent alléger les pages, avec des tests

Les images et les scripts offrent souvent les gains les plus visibles. Mais une optimisation automatique peut casser le thème.

Les images doivent être adaptées à la taille de l’écran

Une image produit ne doit pas partir à sa définition maximale sur un téléphone. Sur mobile, elle s’affiche souvent sur 360 pixels. Les attributs srcset et sizes permettent au navigateur de choisir une version adaptée.

Ajoutez les dimensions width et height. Le navigateur réserve alors l’espace avant le téléchargement. La page bouge moins, et le CLS reste bas.

Le chargement différé convient aux images sous la ligne de flottaison. Ne l’appliquez pas à l’image principale, visible dès l’ouverture. Sinon, le LCP peut se dégrader.

Le nombre de scripts tiers compte autant que leur poids

L’audit repère trois familles de scripts à surveiller :

• le poids et le nombre de fichiers JavaScript et CSS
• les scripts publicitaires, vidéos et chats
• les outils d’analyse et modules de suivi

Un script tiers peut retarder l’affichage. Il peut aussi occuper le processeur pendant une interaction.

La minification ne retire pas un script inutile. Le chargement différé, le découpage des fichiers et la suppression des fonctions inutilisées donnent souvent un meilleur résultat.

Ne fusionnez pas les fichiers sans vérifier. Certains modules dépendent d’un ordre d’exécution précis.

Après chaque correction, testez sur mobile :

• la recherche
• les filtres
• les déclinaisons
• le panier
• le tunnel de commande

Décrire mon besoin →

Les tarifs d’audit dépendent du périmètre et des corrections

Comptez en moyenne :

• 200 à 500 € HT^* pour un audit rapide
• 500 à 1 500 € HT^* pour un audit complet
• plus de 1 500 € HT^* pour un accompagnement avec corrections

Ces fourchettes supposent une boutique de 3 000 produits au maximum, avec un périmètre centré sur la performance.

199 € HT^* suffisent pour repérer des ralentissements visibles sur quelques pages. En revanche, ce format ne couvre pas les requêtes SQL, le serveur, les données terrain ni les modules sur mesure.

900 € HT^* deviennent cohérents si le prestataire teste plusieurs familles de pages et remet un plan d’action chiffré. Au-delà de 3 000 produits, de 30 modules actifs ou d’un trafic élevé, demandez un devis spécifique.

Le budget des travaux se fixe après les mesures

300 à 800 € HT^* couvrent des corrections simples sur les images, le cache et quelques fichiers statiques. 1 000 à 3 500 € HT^* sont à prévoir si le chantier touche le thème, les modules, la base de données ou la configuration PHP.

Le développement sur mesure concentre souvent l’incertitude. Demandez un chiffrage séparé pour les corrections prioritaires, les améliorations secondaires et les évolutions à prévoir avant PrestaShop 9.

Vous pouvez faire un premier diagnostic, mais pas tout corriger seul

Un audit rapide reste possible si vous avez accès à PageSpeed Insights, au Back Office, aux sauvegardes et à une copie de préproduction. Limitez-vous aux mesures, aux images, au cache et aux scripts manifestement inutiles.

Faites intervenir un intégrateur si la boutique utilise des modules sur mesure, un thème fortement modifié, un ERP, plusieurs boutiques ou un paiement externe. Le risque fonctionnel peut vite dépasser l’économie de quelques heures de diagnostic.

Demandez aussi si l’agence sait préparer une évolution headless, c’est-à-dire un front séparé du moteur PrestaShop, ou des flux vers les marketplaces.

Ces choix modifient les mesures, les caches et les appels API. Ils influent aussi sur la visibilité des données produit dans les moteurs de recherche et dans les réponses générées par les IA.

Avant de signer un devis, demandez trois choses par écrit : les pages testées, les accès que vous donnez à l’agence et les mesures prises avant toute correction. Si l’audit et les travaux apparaissent sur deux lignes distinctes, vous savez ce que vous payez pour un diagnostic et ce que vous payez pour une intervention. Faites ensuite une copie de préproduction avant de toucher aux modules de paiement ou de transport.

Décrire mon besoin →

Foire aux questions

Une boutique lente doit-elle être migrée vers PrestaShop 9 ?

Pas forcément. Mesurez d’abord les modules, le serveur, le thème et les requêtes, car une migration améliore la base technique mais ajoute un risque de compatibilité. Si vous la lancez, gardez une copie de préproduction pour tester la commande, le paiement et le transport avant la bascule.

Peut-on auditer une boutique pendant qu’elle vend ?

Oui, pour les mesures et les tests. Les mesures publiques et les essais sur une copie se font sans arrêter la vente. En revanche, désactiver un module, changer le cache ou migrer le serveur se planifie sur une fenêtre d’intervention, de préférence hors période de soldes.

Que faire si PageSpeed Insights ne fournit pas de données terrain ?

Commencez par les tests de laboratoire : ils donnent une référence reproductible, même sans trafic suffisant. Les données terrain reposent sur une période glissante de 28 jours et ne couvrent pas immédiatement toutes vos pages. Installez une mesure réelle adaptée à votre trafic, puis comparez-la à votre référence avant et après chaque correction.

* Tarifs et prix moyens constatés en décembre 2025, sur des retours d'appels d'offres provenant de freelances et d'agences. Ces chiffres ne sauraient être une référence de négociation, car les sources varient selon la taille du site et la séniorité du prestataire.