Agence PrestaShop à Paris

Pour 3 900 € HT, la boutique de départ réunit l’essentiel pour vendre : un thème PrestaShop reconnu, adapté à vos couleurs et à votre logo ; vos vingt premiers produits mis en ligne par nous, à partir des textes et des photos que vous fournissez ; le paiement en ligne et vos modes de livraison réglés ; les bases du référencement ; et une formation pour que vous ajoutiez vous-même la suite du catalogue, sans limite de nombre.

Elle ouvre en six à huit semaines. Pendant les trois mois qui suivent l’ouverture, tout défaut de la boutique livrée est corrigé sans frais, et le code comme les accès vous sont remis.

Elle passe au sur-mesure, à partir de 6 000 € HT, quand il faut un design dessiné pour vous plutôt qu’un thème adapté, des modules premium comme la relance des paniers abandonnés, de l’intelligence artificielle, un simulateur ou la vente aux professionnels. La connexion à votre ERP et la rédaction des fiches produits restent en option dans les deux formules.

Après l’ouverture, l’entretien est facultatif : le pack de maintenance Starter revient à 600 € HT pour un an, soit 50 € par mois, avec les mises à jour, les sauvegardes et une heure d’intervention mensuelle.

Oui après audit : version, thème, modules, performances, sécurité, qualité des données et personnalisations réalisées au fil du temps.

L’audit regarde six points dans cet ordre. La version majeure et sa fenêtre de support, qui détermine si une migration est un préalable. Les surcharges du thème, qui sont la cause la plus fréquente d’une mise à jour impossible — un fichier de cœur modifié directement au lieu d’une surcharge propre bloque tout. Les modules et leur maintenance réelle par leur éditeur. L’état de la base, notamment les tables gonflées par des connexions et des paniers abandonnés jamais purgés. La présence d’un environnement de préparation. Et les accès, dont une partie appartient souvent à l’ancien prestataire.

Cet audit prend de un à trois jours et son résultat vous appartient. Il conclut régulièrement à des travaux préalables, chiffrés séparément.

Un seul cas nous fait refuser : un thème dont les sources ne sont pas fournies, parce que toute intervention se ferait à l’aveugle sur du code compilé.

Oui lorsque aucun module existant ne répond correctement au besoin, avec un code documenté, maintenable et compatible avec les mises à jour prévues.

La règle que nous appliquons : chercher d’abord, développer ensuite. Un module du commerce à quatre-vingts euros maintenu par son éditeur coûte moins cher qu’un développement équivalent, et surtout il suit les versions de PrestaShop sans votre budget. Nous ne développons donc que lorsque le besoin est spécifique à votre activité — une règle de prix, un flux vers votre gestion, un configurateur — ou lorsque les modules existants imposent des compromis inacceptables.

Quand nous développons, trois exigences : pas de modification du cœur, des points d’accroche officiels uniquement, et une documentation des paramètres. C’est ce qui permet de mettre à jour PrestaShop ensuite sans casser votre fonction.

Le code du module vous est cédé avec le reste. Un module développé pour vous et conservé par l’agence est une dépendance, et c’est un point à vérifier dans tout devis, y compris les nôtres.

Les correctifs de sécurité sont indispensables. Une montée de version majeure se décide selon les gains attendus, la compatibilité des modules et le coût de la migration.

La distinction est nette. Les correctifs de sécurité s’appliquent, toujours et rapidement : ils ferment des failles publiées, donc connues des attaquants. Une montée majeure — de la 1.6 à la 1.7, de la 1.7 à la 8 ou 9 — est un projet : le thème doit être refait ou adapté, les modules doivent exister dans la nouvelle version, et la migration des données demande une recette complète.

Ce qui déclenche la décision, en pratique : la fin du support de sécurité de votre version, l’incompatibilité d’un module devenu indispensable, ou une version de PHP que votre hébergeur ne maintient plus. Rester sur une version non supportée est le risque le plus sérieux et le plus courant sur les boutiques que nous auditons.

Nous chiffrons la migration avec la liste des modules à remplacer et ce qui n’aura pas d’équivalent. C’est cette liste, pas le prix, qui fait la décision.

Par l’optimisation du thème, du cache, des requêtes, des images, du nombre de modules actifs et de la configuration serveur.

L’ordre des gains est assez stable sur les boutiques que nous reprenons. Les images d’abord : servies au mauvais format et aux mauvaises dimensions, elles représentent souvent la majorité du poids d’une page de rayon. Le format moderne et le chargement différé sous la ligne de flottaison divisent ce poids sans toucher au code.

Les modules ensuite : une boutique à quarante modules actifs charge quarante fois des fichiers de style et de script, dont une partie sur toutes les pages alors qu’ils ne servent qu’au panier. Désactiver ce qui ne sert plus et restreindre le chargement au contexte utile produit des gains immédiats.

Le cache enfin, à trois niveaux : le cache PrestaShop, un cache d’objets en mémoire, et un cache de page en amont pour les visiteurs non connectés. C’est ce dernier qui encaisse les pics.

Nous mesurons avant et après, sur mobile et en conditions réseau dégradées, parce que c’est là que se joue la transformation.

Oui. Les flux de catalogue, prix, stocks, clients et commandes sont définis avec les fréquences, les règles de correspondance et la gestion des erreurs.

Sur PrestaShop, deux voies existent. Un module d’échange générique, qui convient quand les données sont propres et la correspondance simple : c’est rapide et peu coûteux. Ou un développement spécifique, nécessaire dès que les règles de prix sont complexes, que les déclinaisons doivent être construites depuis des attributs du PIM, ou que la reprise sur erreur doit être fiable.

Le PIM change le partage des rôles et c’est une bonne nouvelle : il devient la source du catalogue, et la boutique n’est plus l’endroit où l’on saisit les fiches. Le sens du flux est alors unique, ce qui supprime la question des écrasements — sauf pour les contenus propres à la boutique, qui doivent être exclus de l’import.

Nous commençons toujours par un import à blanc sur l’environnement de préparation, avec un rapport de volumes. Il révèle l’état réel des données, qui est rarement celui qu’on attendait.

L’évaluation porte sur le risque, les alternatives et le coût de remplacement ou de reprise, en tenant compte de la criticité de la fonction.

Un module abandonné n’est pas dangereux le jour où son éditeur disparaît : il le devient à la prochaine montée de version de PrestaShop ou de PHP, qu’il ne suivra pas. Le risque est donc daté, et cela permet de planifier plutôt que de subir.

Trois issues selon la fonction. Si elle est secondaire, on la retire — et il faut l’accepter, car beaucoup de modules installés il y a des années ne servent plus à personne. Si elle existe ailleurs, on remplace, en vérifiant la reprise des données que le module stockait dans ses propres tables. Si elle est critique et sans équivalent, on reprend le code : cela suppose que les sources soient lisibles, et cela transfère la maintenance chez nous, ce que le devis doit dire.

L’audit liste ces modules avec leur criticité et l’échéance à laquelle chacun deviendra bloquant. C’est le document qui permet de budgéter.

Sur un environnement de préparation, avec des scénarios d’achat, des tests de compatibilité et un contrôle des performances avant la mise en ligne.

Les scénarios minimaux pour toute évolution qui touche au parcours : un achat complet avec le moyen de paiement principal, un achat avec code promotionnel, un achat d’un produit à déclinaisons, un abandon puis retour au panier, et une commande avec livraison dans une zone à tarif particulier. Ces cinq passages attrapent la grande majorité des régressions.

S’y ajoute un contrôle de compatibilité entre modules : sur PrestaShop, deux modules qui s’accrochent au même point d’exécution se gênent, et le symptôme apparaît ailleurs que là où on a modifié. Nous vérifions donc les pages non concernées par l’évolution, ce qui est contre-intuitif et nécessaire.

Et une mesure de performance avant-après. Une évolution fonctionnellement juste qui ajoute une seconde au chargement de la page produit coûte des ventes, et l’effet ne se voit pas en recette fonctionnelle.

Oui. La maintenance couvre les mises à jour, la surveillance, les sauvegardes et les correctifs. Les évolutions font l’objet d’un chiffrage distinct.

La frontière : la maintenance remet en état ce qui existe, une évolution ajoute ce qui n’existait pas. Corriger un module de livraison qui ne calcule plus les frais est de la maintenance ; ajouter un nouveau transporteur est une évolution, même si cela prend une heure.

Nous prévoyons souvent un forfait de deux à quatre heures par mois pour les petites demandes — un texte, une image, un tarif de port —, ce qui évite d’émettre un devis pour un quart d’heure. Son solde figure au compte rendu mensuel.

Cette séparation protège les deux parties. Sans elle, un contrat de maintenance devient un développement continu sans périmètre ni recette, et la discussion arrive en fin d’année sur ce que l’abonnement couvrait. Avec elle, le budget d’évolution est visible et arbitré, ce qui est plus confortable pour tout le monde.

Une boutique de départ commence à 3 900 € HT : un thème PrestaShop adapté à votre marque et vos vingt premiers produits mis en ligne par nous, en six à huit semaines. Une boutique sur mesure se situe généralement entre 6 000 € et 12 000 €, une plateforme avancée entre 15 000 € et 30 000 €, selon le catalogue, les intégrations et les règles de prix.

Ces fourchettes sont celles d’une agence au positionnement standard et proviennent de notre analyse publiée sur le prix d’un site internet. Elles couvrent la conception, l’intégration du thème, la configuration, la recette et la mise en ligne — hors rédaction de contenus et hors services tiers.

Ce qui déplace le chiffre dans la fourchette, par ordre d’effet : le nombre de règles de prix particulières, la présence d’une intégration avec un ERP, le nombre de déclinaisons et d’attributs à modéliser, et le nombre de langues. Le nombre de produits, lui, pèse beaucoup moins qu’on ne le croit — importer mille références coûte à peu près autant que cent, à structure égale.

S’y ajoutent les récurrences : hébergement, licences de modules avec leur renouvellement annuel, commissions de paiement et maintenance. Une boutique modeste se situe souvent entre cinquante et deux cents euros par mois hors commissions.

Une boutique de départ ouvre en six à huit semaines. Une boutique sur mesure demande généralement de huit à douze semaines, une plateforme avancée de trois à six mois, selon la disponibilité des contenus et des interlocuteurs.

Ce calendrier se décompose en gros tiers : cadrage et conception, intégration et développement, recette et mise en ligne. Le troisième tiers est celui qu’on comprime par optimisme, et c’est celui qui produit les mises en ligne repoussées.

Deux facteurs décalent plus que la technique. Les contenus produits : cinq cents fiches à rédiger représentent plusieurs semaines de travail qui n’appartiennent pas au développement, et une boutique techniquement prête sans contenus reste en préproduction. Et la disponibilité des personnes qui valident : une validation qui prend huit jours au lieu de deux, répétée cinq fois, ajoute un mois.

Nous demandons donc au cadrage le nom des valideurs et leurs indisponibilités connues. C’est la question la plus prosaïque du projet et celle qui prédit le mieux sa date de livraison réelle.

À vous. Le thème, les modules développés, les accès et les environnements sont remis avec la documentation nécessaire pour poursuivre avec ou sans nous.

L’inventaire de livraison comprend le dépôt de code avec son historique complet, le thème et ses sources — pas seulement sa version compilée —, les modules développés pour vous, les accès d’administration et de base, le compte d’hébergement, le nom de domaine enregistré à votre nom, et les licences des modules du commerce avec leur titulaire.

Deux points méritent une vérification, chez nous comme ailleurs. Le nom de domaine : enregistré au nom de l’agence, même de bonne foi, il fait de votre adresse un actif que vous ne contrôlez pas. Et les licences de modules payants : achetées au nom de l’agence, elles ne vous suivent pas si vous changez de prestataire, et il faut les racheter.

Nous les enregistrons donc à votre nom dès l’achat, ce qui suppose une carte bancaire de votre côté au moment de la configuration. C’est un petit inconvénient qui évite un gros.

Oui. La formation porte sur les tâches réellement utiles : catalogue, commandes, promotions, contenus et suivi, avec les supports correspondants.

Le format qui fonctionne : deux demi-journées, sur votre boutique réelle et non sur une démonstration, avec les personnes qui administreront. La première couvre le quotidien — ajouter une référence, modifier un prix, traiter une commande, éditer un contenu. La seconde couvre le périodique et l’exceptionnel : créer une promotion, gérer un retour, comprendre un paiement en attente, retrouver une commande.

Nous ne formons pas au back-office entier. PrestaShop compte des centaines d’écrans dont vous n’ouvrirez jamais la plupart, et les couvrir noie l’essentiel. La formation suit vos tâches, listées avec vous avant la séance.

Le support remis est une suite de procédures illustrées, pas un manuel générique — l’écran de votre boutique, avec vos noms de catégories. C’est ce qui permet à une personne arrivée six mois plus tard de s’en servir, et cette formation a lieu avant la mise en production, pas après.