Table des matières :
- Ce qu’une « agence PrestaShop » doit réellement livrer (et ce que le cœur ne fait pas pour vous)
- Critères techniques de sélection : architecture, qualité de code, performance mesurable
- Sécurité, conformité et supply chain : les questions qui évitent les nuits blanches
- Check-list de brief (copiable) : cadrer scope, intégrations, contraintes et critères d’acceptation
- Grille de scoring, signaux faibles et clauses à exiger avant de signer
Ce qu’une « agence PrestaShop » doit réellement livrer (et ce que le cœur ne fait pas pour vous)
Sélectionner une agence PrestaShop n’est pas une question de “joli thème” ou de nombre de sites livrés. Sur une stack PrestaShop moderne, vous achetez surtout une capacité à livrer et maintenir un système hybride : legacy (controllers/front, overrides, hooks historiques) + composants Symfony (back-office, services, CQRS sur PrestaShop 9). Si l’équipe ne sait pas naviguer entre ces deux mondes, vous hériterez d’un code fragile (overrides en cascade, modules non isolés, régressions sur mises à jour).
Concrètement, demandez à l’agence de positionner le projet sur une matrice Run vs Build : qui assure la TMA (Tierce Maintenance Applicative), qui opère l’infra, qui traite les incidents, qui porte la responsabilité de la performance et de la sécurité. Beaucoup d’intégrateurs livrent un ZIP “ok sur staging” et disparaissent. En e‑commerce, c’est un anti‑pattern : les pics (soldes, TV, TikTok) et les bugs paiement arrivent en production, pas en recette. Si l’agence n’a pas de procédure d’astreinte et de runbooks, vous payez un développement “à usage unique”.
Pour éviter les malentendus, poussez l’agence à formaliser qui fait quoi dès le devis. Exemple de matrice simple (à adapter) :
| Sujet | Build (projet) | Run (exploitation) | Preuve attendue |
|---|---|---|---|
| Déploiements | Agence | Agence ou client | procédure + rôles + fenêtre |
| Incidents paiement | Agence | Agence (astreinte) | runbook + escalade + logs |
| Performance | Agence | Partagé | KPI + monitoring + objectifs |
| Sécurité & patching | Agence | Partagé | calendrier + process urgence |
| Backups / restore | Hébergeur/DSI | Hébergeur/DSI | test de restauration daté |
Ce tableau paraît “administratif”, mais il évite un cas très fréquent : un site qui marche en semaine à trafic normal, puis se dégrade pendant un événement (soldes d’hiver/été, Black Friday, campagne influence), faute d’objectifs SLO, de cache correctement configuré et de procédure de rollback.
Enfin, mettez sur la table les limites connues du cœur PrestaShop : cache applicatif inégal, dépendance aux modules (paiement, recherche, export), complexité de la navigation à facettes et de l’indexation, et dette technique introduite par certains overrides. Les agences sérieuses sont capables de documenter ces points et de proposer des contre‑mesures (cache multi‑niveaux, suppression d’overrides, observabilité). Pour cadrer vos exigences non‑fonctionnelles, appuyez‑vous sur des ressources internes du site : performance et cache (Audit performance PrestaShop : méthode en 6 étapes reproductibles, Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur).
Critères techniques de sélection : architecture, qualité de code, performance mesurable
Une agence PrestaShop “sérieuse” doit être capable de travailler proprement sur PrestaShop 8.1.x et/ou PrestaShop 9.x (au moment de la rédaction, la majorité des projets sont en 8.1, avec une trajectoire vers 9) avec PHP 8.1/8.2 selon l’hébergement. Exigez un discours clair sur : Composer (vendor géré, lock), gestion Node (assets), compatibilité modules, et stratégie de montée de version. Un bon signal : l’agence sait expliquer comment elle traite la compatibilité avant migration (audit modules, environnements, rollback) — voir Compatibilité modules PrestaShop 9 : checklist avant migration sécurisée et Migration PrestaShop 9 : sécurité, tests et plan de rollback.
Un point souvent révélateur : la manière dont l’agence parle des overrides. Une équipe mature ne dit pas “on override”, elle dit plutôt :
- “on cherche d’abord un hook / un décorateur / un service Symfony” ;
- “si on n’a pas le choix, on limite l’override, on le documente, et on teste le chemin de mise à jour”.
Sur la qualité de delivery, le minimum en 2026 : Git + PR obligatoires, conventions (PSR‑12), outillage (PHPStan/Psalm, PHP‑CS‑Fixer), tests (au moins smoke tests E2E sur tunnel de commande), et CI/CD. Martin Fowler résume correctement la base : « Continuous Integration is a software development practice where members of a team integrate their work frequently » (Martin Fowler, Continuous Integration). Si l’agence ne sait pas décrire son pipeline (build, tests, artefacts, déploiements), vous ne sélectionnez pas un prestataire, vous sélectionnez une loterie.
Pour rendre ce critère vérifiable pendant l’avant‑vente, vous pouvez demander une démo sur un projet similaire (sans code propriétaire) : une PR, un pipeline qui tourne, et un déploiement sur un staging. Ce n’est pas intrusif : c’est l’équivalent, côté dev, d’un restaurateur qui vous montre sa cuisine.
Côté performance, ne demandez pas “un site rapide”, demandez des objectifs chiffrés et une méthode : TTFB p95, temps de rendu serveur, taux de cache HIT, coûts SQL (requêtes lentes), et budget Web Vitals. Exemple de KPI réaliste sur un site bien opéré : TTFB p95 < 200–300 ms sur pages cacheables, cache HIT > 80% sur catalogue, et pas de requêtes SQL > 1s hors back‑office. La compétence se vérifie vite : l’agence doit savoir activer et lire un slow query log (Requêtes MySQL lentes PrestaShop : activer slow query log), profiler PrestaShop (PrestaShop debug profiling : activer et analyser performances SQL) et concevoir un cache serveur cohérent (Varnish/Redis/OPcache) (PrestaShop soldes : optimiser caches, CDN et Varnish pour trafic élevé).
Pour structurer la discussion, voici une grille KPI/outils simple (à reprendre dans le brief) :
| Domaine | KPI cible (exemple) | Où mesurer | Qui agit |
|---|---|---|---|
| Serveur | TTFB p95, 5xx/min | logs + APM | agence + infra |
| Cache | HIT ratio catalog | Varnish/NGINX metrics | agence |
| DB | requêtes > 1s, deadlocks | slow log + dashboard | agence |
| Front | LCP/INP/CLS (Web Vitals) | RUM/CrUX/GA4 | agence + UX |
| Checkout | taux d’erreur paiement | back-office + PSP | agence |
L’idée n’est pas de “sur‑monitorer”, mais de rendre la performance défendable : si les KPIs se dégradent, on sait où regarder, et on peut revenir à un état stable.
Sécurité, conformité et supply chain : les questions qui évitent les nuits blanches
En 2026, le risque principal n’est pas “un hacker générique”, c’est la supply chain : modules obsolètes, dépendances PHP, clés API exposées, comptes back‑office trop permissifs. Une agence PrestaShop doit documenter sa politique de patching (core + modules), sa veille CVE et son process d’upgrade. Point concret : demandez comment ils gèrent une vulnérabilité critique sur un module de paiement en production (fenêtre d’intervention, mitigation WAF, rollback). Exemple de cas à intégrer dans votre cahier des charges : retour d’expérience sur un correctif urgent et ses mesures de réduction de risque (ps_checkout : mise à jour et mesures de mitigation).
Ce que vous cherchez, ce n’est pas “zéro risque” (impossible), mais un process. Une réponse attendue ressemble à :
- triage (impact, exposition, version),
- mitigation immédiate (désactivation fonctionnalité, règles WAF, limitation accès BO),
- patch (mise à jour module / hotfix),
- vérification (tests paiement + logs),
- post‑mortem (cause racine, actions préventives).
Sur le contrôle d’accès, la règle à imposer est le moindre privilège (accès SSH, DB, BO, API). Le NIST définit le principe du moindre privilège comme l’attribution des autorisations minimales nécessaires à un utilisateur, un programme ou un processus pour accomplir sa fonction (NIST — least_privilege). Traduction opérationnelle : comptes nominaux, MFA quand possible, pas de partage de superadmin, accès temporaires, et journaux d’audit.
Ajoutez aussi un angle très “terrain” en France/UE : la conformité ne se limite pas au RGPD “papier”. Pour un e‑commerce, ce sont des flux concrets (export clients, logs, SAV, prestataires). À minima, votre prestataire doit savoir expliquer :
- où résident les données (hébergeur, sauvegardes, environnements de test),
- comment on anonymise/pseudonymise un dump de prod pour la préprod,
- combien de temps on conserve les logs et qui y accède,
- comment on gère une demande d’effacement sans casser la comptabilité/facturation (contradictions fréquentes).
Enfin, exigez des preuves d’hygiène sécurité côté serveur et HTTP : durcissement (.htaccess, TLS, headers), protection brute‑force/scan, et supervision. Ces points ne sont pas “bonus”, ils conditionnent la disponibilité et la conformité RGPD (logs, traçabilité). Pour cadrer, renvoyez l’agence vers des exigences explicites : Sécurité PrestaShop : mises à jour, SSL et durcissement .htaccess, HTTP Security Headers en PHP : guide CSP, HSTS, X-Frame-Options et, si vous avez une DSI outillée, la journalisation et la protection API (Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM).
Check-list de brief (copiable) : cadrer scope, intégrations, contraintes et critères d’acceptation
Un brief exploitable par une agence PrestaShop ressemble à un mini‑SOW (Statement of Work) technique : objectifs, périmètre, contraintes, hypothèses, livrables, et critères d’acceptation testables. Le piège classique : “refonte + SEO + perf + ERP” dans un seul paragraphe. À la place, imposez un découpage par lots livrables (MVP, itérations), avec une définition de “Done” (tests passés, monitoring en place, documentation, plan rollback). C’est aussi la meilleure manière de comparer deux devis : mêmes hypothèses, mêmes livrables.
Un détail qui change tout : demandez que chaque lot contienne au moins un livrable opérable (pas uniquement “du code”). Exemple : “MVP checkout” inclut aussi un tableau de bord d’erreurs paiement + un runbook “incident PSP”.
Côté intégrations, soyez précis : quels systèmes (ERP/PIM/CRM/WMS), quels flux (stocks, prix, commandes, retours), quelle latence acceptable (temps réel vs batch), et quelle stratégie de reprise sur incident (rejeu, idempotence, DLQ). Si vous utilisez l’API native, demandez noir sur blanc la stratégie d’auth, de rotation de clés, et de rate limiting. Pour cadrer les prérequis, référence utile : Webservice PrestaShop : activer l’API et créer une clé d’accès et, pour les sujets ERP, Intégration ERP : API, connecteurs et donnée unique en temps réel.
Pour éviter les “intégrations fantômes” (celles qui marchent en démo mais cassent à la première reprise), vous pouvez ajouter au brief une mini‑fiche par flux :
- Flux : ex. stocks depuis ERP → PrestaShop
- Fréquence : toutes les 5 minutes (batch)
- Volumétrie : 20 000 références, delta moyen 1 000/j
- Contrat : champs obligatoires, unités, arrondis prix, devise, TVA
- Reprise : rejeu sur 24h, idempotence par SKU+timestamp
- Observabilité : logs + métrique “lignes traitées / erreurs” + alerte
Pour le SEO et la conversion, évitez les formulations vagues (“optimiser le SEO”). Attendez‑vous à des changements techniques : données structurées, maillage, contrôle des facettes, performance, recherche interne, et tunnel de commande. Votre brief doit indiquer les KPI et où ils sont mesurés (GA4/Matomo, logs serveur, Search Console, outil de search analytics). Points à lier explicitement : recherche interne (Recherche interne PrestaShop : mesurer CTR, zéro résultat et conversion), balisage schema (SEO e-commerce : implémenter schema Product Review Breadcrumb et maillage interne) et optimisation checkout (Passage en caisse PrestaShop : checkout en une page et express checkout).
Check-list de brief (à coller dans votre doc)
- Contexte : version PrestaShop actuelle, PHP/MySQL, hébergeur, volumétrie (produits, catégories, commandes/jour), saisonnalité.
- Objectifs : KPI business (CVR, AOV), KPI tech (TTFB p95, erreurs 5xx), KPI SEO (indexation, impressions, pages valides).
- Périmètre : thème (Classic/Custom), modules à conserver/remplacer, refonte URL, multiboutique, multilingue, B2B.
- Environnements : local (ex. DDEV), staging, préprod, prod ; données anonymisées ; accès (VPN, bastion).
- Intégrations : ERP/PIM, paiement, transporteurs, marketplace, CRM ; protocole (REST/SOAP), fréquence, reprise.
- Exigences perf : cache (Varnish/Redis), CDN, budget SQL, tests de charge, runbooks pics de trafic.
- Sécurité : MFA BO, rotation secrets, WAF/fail2ban, headers, sauvegardes chiffrées, plan patching.
- SEO : schema.org, hreflang, canonical, facettes, pagination, logs crawl, maillage interne.
- Livrables : repo Git, documentation d’archi, scripts d’install, playbooks déploiement, SBOM si possible.
- Recette : critères d’acceptation testables, jeux de tests tunnel commande, plan de rollback, fenêtre de déploiement.
Grille de scoring, signaux faibles et clauses à exiger avant de signer
Pour comparer 3 agences, utilisez une grille pondérée (et assumez que le “meilleur design” ne vaut rien si le delivery est faible). Exemple de pondération pragmatique : 30% delivery (CI/CD, tests, process), 25% expertise PrestaShop (modules, hooks, Symfony/legacy), 20% perf/infra (cache, DB, HA), 15% sécurité/conformité, 10% SEO technique. Une agence qui marque 8/10 en dev mais 2/10 en run vous coûtera plus cher à moyen terme : incidents, downtime, retards.
Pour faciliter la comparaison, vous pouvez transformer cette pondération en tableau (1 à 5) :
| Axe | Poids | Agence A | Agence B | Agence C |
|---|---|---|---|---|
| Delivery / CI-CD / tests | 30% | |||
| Expertise PrestaShop | 25% | |||
| Perf / infra / cache / DB | 20% | |||
| Sécurité / conformité | 15% | |||
| SEO technique | 10% | |||
| Score total | 100% |
L’important n’est pas la “science exacte”, mais la discipline : noter sur des preuves (docs, démo pipeline, exemples de runbooks, exemples de rapports perf), pas sur un feeling.
Signaux faibles typiques d’un mauvais fit technique : (1) dépendance aux overrides comme “solution standard” (risque de conflits et de migrations coûteuses), (2) absence de staging “identique prod”, (3) aucune mention de monitoring/alerting, (4) refus de livrer le code sous votre organisation Git, (5) incapacité à expliquer un plan de rollback. Sur la partie run, vous voulez une capacité à diagnostiquer vite : logs PHP/MySQL/JS, alertes, corrélation d’erreurs — sujet à cadrer avec PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail et Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes.
À l’inverse, quelques signaux “verts” concrets :
- l’agence propose spontanément une recette sur critères mesurables (pas “validation client”),
- elle sait expliquer comment elle évite les régressions (tests + feature flags éventuels + rollback),
- elle parle d’observabilité avant de parler “optimisation” (données avant opinions).
Contractuellement, verrouillez ce qui évite les blocages : propriété du code (modules/thème), accès et réversibilité (documentation + scripts), SLA/TMA (temps de réponse et rétablissement), et conditions d’intervention en période critique (soldes). Exigez aussi des livrables “opérables” : runbooks, procédures de déploiement, sauvegardes et restauration testée. Si vous anticipez des pics, demandez explicitement un plan de charge et d’architecture scalable, en vous appuyant sur des références internes : PrestaShop performance : monitoring, tests de charge et runbooks soldes et PrestaShop pics de trafic : architecture cloud scalable et haute disponibilité.
Un bon “minimum contractuel” (souvent oublié) :
- réversibilité : “à la fin du contrat, remise des accès, dépôts Git, documentation et procédure d’installation” ;
- SLA : distinguer “temps de réponse” et “temps de rétablissement” (et préciser les horaires) ;
- fenêtres sensibles : clause spécifique pour les périodes type soldes (astreinte, gel des changements, procédure d’urgence).
Dernier point, volontairement frontal : une bonne agence PrestaShop n’est pas celle qui dit “oui” à tout, c’est celle qui sait dire “non” avec une justification technique (risque, dette, coût d’opportunité) et une alternative (module standard, simplification, découpage en lots). Si, à la fin du brief, vous avez (a) des KPI mesurables, (b) des critères d’acceptation testables, (c) une stratégie de migration/rollback, et (d) un plan run (monitoring + astreinte), alors vous ne “choisissez pas une agence” : vous mettez en place un système de livraison et d’exploitation qui tient en production.
