Vérifié à l’aune de PrestaShop 9 et des modèles tarifaires SaaS actuels. Nous sommes éditeur de modules PrestaShop (mypresta.rocks) : considérez donc notre parti pris comme clairement annoncé, et le verdict ci-dessous comme volontairement équilibré.
Il y a une question que la plupart des marchands ne se posent qu’au moment où la réponse devient coûteuse : si mon fournisseur de plateforme changeait les règles demain, que pourrais-je vraiment faire ? Sur une boutique SaaS hébergée, la réponse honnête est : « demander poliment et attendre ». Sur une plateforme open source comme PrestaShop, la réponse est : « ouvrir le fichier et le modifier ». Cette différence peut sembler abstraite, jusqu’au jour où un palier tarifaire double, où une fonctionnalité essentielle à votre activité est abandonnée, ou où une application autour de laquelle vous avez construit votre organisation disparaît d’une place de marché. Cet article parle précisément de cette différence, la propriété du code comme gestion du risque, et de ce que cela signifie concrètement dans une boutique PrestaShop. Ce n’est pas un duel fonctionnalité par fonctionnalité entre plateformes (nous gardons ces comparaisons séparées et honnêtes : PrestaShop vs Shopify, PrestaShop vs WooCommerce, PrestaShop vs Magento).
Ce que « posséder son code » signifie vraiment avec PrestaShop
L’expression « open source » est souvent utilisée de façon vague. Avec PrestaShop, elle est très concrète, et vous pouvez vérifier chaque affirmation ci-dessous en ouvrant votre propre installation via SFTP. Toute l’application est fournie sous forme de PHP lisible, de templates Smarty/Twig et de SQL. Il n’y a pas de binaire compilé qu’il vous serait interdit d’inspecter, ni de fonctionnalité serveur verrouillée derrière un palier de facturation. En pratique :
- Vous pouvez lire la logique qui fait fonctionner votre boutique. La classe qui construit une commande se trouve dans classes/order/Order.php ; le parcours de commande côté front-office passe par controllers/front/OrderController.php ; les règles fiscales se trouvent dans classes/tax/. Quand quelque chose se comporte étrangement, le comportement correspond à un fichier que vous pouvez ouvrir, pas à un ticket de support envoyé dans une boîte noire.
- Vous pouvez modifier le comportement sans forker le cœur. Le système de hooks de PrestaShop (classes/Hook.php, enregistrés via les tables hook et hook_module) permet à un module d’injecter sa logique à des centaines de points définis, actionValidateOrder, displayProductAdditionalInfo, actionCartSave, etc. Le système d’overrides (override/) vous permet de remplacer une seule méthode d’une classe du cœur sans modifier l’original. Les hooks sont le chemin de mise à jour le plus sûr ; les overrides évitent de toucher au cœur, mais doivent être retestés lors des mises à jour.
- Vous possédez la base de données. Vos produits, clients, commandes et configurations se trouvent dans une base MySQL/MariaDB dont vous détenez les identifiants. Un export complet mysqldump, accompagné de vos dossiers img/ et themes/, représente toute votre boutique, portable vers n’importe quel hébergeur. Pas de file d’export, pas de limite de débit API, pas de « contactez-nous pour une migration entreprise ».
- Vous pouvez faire appel à qui vous voulez. Tout développeur PHP qui connaît Symfony et les conventions de PrestaShop peut intervenir. Vous n’êtes pas limité au répertoire de partenaires certifiés d’un fournisseur, et vous ne vous retrouvez pas en concurrence avec toutes les autres boutiques de la même plateforme pour les mêmes spécialistes rares.
Et alors ? Chacun de ces points est un levier que vous gardez entre vos mains. La valeur d’un levier que l’on utilise rarement tient précisément au fait qu’il existe le jour où l’on en a besoin.
La carte des dépendances : qui contrôle quoi
La façon la plus claire de comprendre la propriété consiste à demander, pour chaque couche de votre boutique : « si cela doit changer, qui doit donner son accord ? » Voici cette carte pour une boutique SaaS hébergée par rapport à une boutique PrestaShop auto-hébergée.
| Couche | SaaS hébergé | PrestaShop auto-hébergé |
|---|---|---|
| Lieu d’exécution | Serveurs du fournisseur, région du fournisseur | L’hébergeur de votre choix ; vous pouvez déplacer la boutique en un week-end |
| Parcours de commande | Ce que la plateforme expose ; les modifications profondes sont souvent bloquées | Modifiable, override de OrderController, voire remplacement complet du tunnel de commande |
| Logique de tarifs & promotions | Règles intégrées uniquement | Règles de prix personnalisées, logique de prix spécifiques, tarifs de groupes B2B dans le code |
| Ajout d’une fonctionnalité | Trouver une application, sinon rien ne se passe | Installer un module, surcharger une classe ou écrire votre propre solution |
| Vos données | Export dans les limites et formats imposés par le fournisseur | Accès direct à la base de données et aux fichiers ; export complet à tout moment |
| Évolution des coûts | Paliers d’abonnement + frais par transaction qui augmentent avec le chiffre d’affaires | Hébergement fixe + développements que vous commandez quand vous le décidez |
| Continuité si le fournisseur change de cap | Vous vous adaptez à sa décision | Vous pouvez rester sur votre version, ou forker ; le code ne peut pas vous être retiré |
Rien de tout cela ne rend le SaaS « mauvais », pour une boutique de cinq produits lancée par un fondateur non technique, une plateforme hébergée est un départ pragmatique. Le point est plus précis : la colonne de droite représente un ensemble de décisions que vous n’avez jamais besoin d’escalader à un fournisseur.
La propriété du code comme gestion du risque, pas comme philosophie
« Vous possédez votre code » peut ressembler à un slogan idéologique. Ce n’en est pas un : c’est une protection concrète contre quatre modes d’échec qui sont tous déjà arrivés à de vrais marchands.
- Changements tarifaires de la plateforme. Les frais en pourcentage des transactions et la hausse des paliers d’abonnement signifient que plus vous vendez, plus vous payez pour la même capacité. En open source, le succès ne déclenche pas une renégociation, votre facture d’hébergement augmente avec le trafic, pas avec la stratégie tarifaire d’un fournisseur.
- Abandon de fonctionnalités. Un fournisseur SaaS peut supprimer une capacité autour de laquelle vous avez construit un processus, selon son propre calendrier. Avec PrestaShop, une fonctionnalité dont vous dépendez est du code que vous contrôlez ; elle reste en place jusqu’à ce que vous décidiez de la modifier, et vous pouvez figer une version fonctionnelle pendant que vous planifiez la suite.
- Fragilité de l’écosystème d’applications. Lorsque le comportement de votre boutique dépend d’une application tierce sur la place de marché d’un fournisseur, cette application peut être retirée, vendue ou laissée à l’abandon, et vous n’avez pas accès au code source pour la maintenir en vie. Un module PrestaShop que vous avez acquis est livré sous forme de fichiers dans modules/ sur votre serveur ; même si son auteur disparaît, la copie installée continue de fonctionner et un développeur peut la lire et la corriger.
- Verrouillage fournisseur au moment de partir. Les données les plus difficiles à extraire d’une plateforme hébergée sont généralement celles dont vous auriez besoin pour la quitter : plans de redirections 301, métadonnées SEO, hachages des mots de passe clients, historique détaillé des commandes. Avec PrestaShop, ces données sont des lignes dans des tables que vous possédez.
Nous le disons en tant que personnes qui exploitent des boutiques, pas seulement qui en construisent : la valeur ici, c’est une tranquillité d’esprit que vous pouvez chiffrer. Les scénarios négatifs ci-dessus ont une faible probabilité sur une année donnée, mais ils coûtent très cher lorsqu’ils surviennent. Posséder le code est une façon de plafonner ce risque extrême.
Le vrai coût de la propriété
Posséder le code signifie aussi assumer les responsabilités qu’un fournisseur SaaS absorberait autrement. Prétendre le contraire serait vous rendre un mauvais service.
- Vous (ou votre hébergeur) gérez le serveur. Version de PHP, MySQL, renouvellement SSL, sauvegardes, correctifs de sécurité du système d’exploitation. Un hébergement PrestaShop managé prend en charge l’essentiel de ces points, mais cela reste une ligne de coût, pas zéro.
- Les mises à jour du cœur et des modules relèvent de votre décision. Quand un correctif de sécurité PrestaShop sort, son application vous incombe. Le revers positif, c’est que rien ne se met à jour automatiquement sous vos pieds pour casser un tunnel de commande un vendredi soir sans prévenir.
- La mise en place initiale est plus approfondie. Une boutique hébergée peut être en ligne en un après-midi. Une boutique PrestaShop auto-hébergée configurée correctement, performance, cache, moyens de paiement et transporteurs, règles fiscales, GDPR/RGPD, représente quelques jours de travail.
- Vous avez besoin de ressources techniques disponibles. Soit une compétence interne, soit une relation avec un développeur. C’est le véritable coût de la liberté, et il est récurrent.
La même règle d’honnêteté s’applique aussi aux modules : la propriété ne signifie pas que chaque module gratuit est une bonne affaire. Un module gratuit mal construit devient une responsabilité que vous possédez désormais. Nous détaillons ce point dans le coût réel des modules gratuits et pourquoi la qualité des modules compte plus que leur quantité.
Là où la propriété paie d’abord : les personnalisations que le SaaS ne vous laissera pas construire
La propriété cesse d’être abstraite dès que vous avez besoin de quelque chose qu’un modèle ne propose pas. Voici quelques cas où l’architecture ouverte de PrestaShop justifie pleinement son choix, avec le hook ou la couche concrète concernée :
- De vrais tarifs B2B. Prix différents par groupe client, tarifs négociés, paliers de volume, prix nets pour comptes professionnels. PrestaShop modélise cela nativement avec les Groupes clients et la table specific_price, et vous pouvez étendre la logique dans le calcul de prix de classes/Product.php au lieu d’espérer qu’une application prenne en charge exactement votre règle.
- Comportement de commande personnalisé. Moyens de paiement conditionnels, champs propres à certains pays, parcours de commande réellement différent : tout cela est atteignable en surchargeant OrderController ou en se branchant sur les étapes de commande, sans approbation d’un fournisseur.
- Intégrations profondes. ERP, comptabilité, WMS tiers, flux vers une place de marché européenne, vous pouvez écrire dans la base de données, exposer l’API webservice ou construire un module qui communique avec votre système selon votre schéma. Pour vendre au-delà de votre propre boutique, consultez place de marché ou boutique en propre et le guide multicanal Amazon.
- Complexité multi-pays. Règles fiscales par zone et localisation sous International, plusieurs transporteurs avec tranches de poids/prix sous Livraison, tout se configure dans le back-office, et s’étend en code lorsque la configuration atteint ses limites.
L’autre face de la propriété : un écosystème de modules que vous possédez réellement
L’open source a deux effets sur les extensions, et c’est ici que le modèle PrestaShop se distingue nettement d’une boutique d’applications contrôlée par un seul fournisseur. Comme n’importe qui peut créer des modules, l’écosystème est diversifié et concurrentiel plutôt que contrôlé par une seule entreprise prélevant une commission sur chaque installation. Ce qui maintient des prix raisonnables et fait avancer l’innovation. La contrepartie, c’est que la qualité varie ; bien acheter compte donc vraiment. C’est le sujet de notre guide d’achat de la place de marché Addons.
Le point lié à la propriété se joue après l’achat : un module PrestaShop correctement construit s’installe dans modules/, enregistre ses hooks, puis devient à vous. Les modules traditionnels autonomes sont des fichiers sur votre serveur ; vérifiez toutefois la licence, les conditions de mise à jour et les éventuels services externes avant d’acheter. Chez mypresta.rocks, nous construisons volontairement selon ce standard : code propre, compatibilité stricte avec le cœur de PrestaShop et les versions de PHP, configuration depuis votre back-office plutôt qu’une facture développeur. Qu’est-ce que cela change pour vous ? Une capacité que vous ajoutez une fois et conservez, avec un support direct du développeur et aucun intermédiaire entre vous et la personne qui a écrit le code. Si vous équipez une nouvelle boutique, notre sélection des premiers modules à installer se trouve dans les modules que toute nouvelle boutique devrait installer en premier, ainsi que dans la liste des modules essentiels.
L’open source est-il le bon choix pour votre boutique ?
La propriété vaut son coût à partir d’un certain niveau d’activité et de complexité, et elle peut réellement être excessive en dessous. Voici un cadre de décision approximatif, issu d’années passées à observer des marchands des deux côtés de cette ligne :
| Votre situation | Orientation probable |
|---|---|
| Quelques produits, aucune ressource technique, validation d’une idée | Commencer en hébergé, la vitesse compte davantage que le contrôle à ce stade |
| Un chiffre d’affaires où les frais en pourcentage et les paliers d’abonnement deviennent un vrai montant mensuel | Open source, les coûts fixes commencent à gagner le calcul |
| Vous avez besoin de personnalisations que les modèles ne permettent pas (tarifs, commande, intégrations) | Open source. C’est exactement ce que l’accès au code permet d’obtenir |
| Vous vendez dans plusieurs pays avec une fiscalité et une livraison complexes | Open source, le modèle natif multi-zones et multi-transporteurs de PrestaShop |
| B2B : tarifs personnalisés, facturation, délais de paiement, comptes professionnels | Open source, tarifs de groupe et logique de prix spécifiques que vous contrôlez |
| La propriété des données et l’indépendance à long terme sont un sujet stratégique | Open source, c’est tout l’intérêt de la colonne de droite ci-dessus |
Si vous êtes déjà convaincu et que la question est « depuis quelle plateforme vers PrestaShop ? », les mécanismes de migration sont un sujet à part : depuis Shopify, depuis WooCommerce et depuis Magento. Et pour le récit sans filtre de la raison pour laquelle nous avons nous-mêmes choisi cette plateforme après dix ans de développement dessus, lisez pourquoi nous avons choisi PrestaShop et les leçons qui ont vraiment compté.
Questions fréquentes sur la propriété de votre code e-commerce
Si je ne prévois jamais de modifier du PHP moi-même, est-ce que « posséder le code » m’aide vraiment ?
Oui, et c’est précisément ce que la plupart des discours sur la propriété expliquent mal. La valeur n’est pas que vous ouvriez le fichier, la plupart des marchands ne le feront jamais. Elle tient au fait que ce fichier peut être ouvert par quelqu’un que vous choisissez, selon votre calendrier. La feuille de route, les prix et les abandons de fonctionnalités d’une plateforme hébergée sont des décisions prises pour vous ; avec PrestaShop, chacun de ces sujets devient une mission que vous pouvez confier, au lieu d’un mur contre lequel vous butez. Vous achetez une marge de manœuvre, pas un loisir de développeur.
PrestaShop auto-hébergé est-il réellement moins cher qu’une plateforme hébergée ?
Pas toujours, et cela dépend du chiffre d’affaires. En dessous du seuil approximatif où les frais en pourcentage des transactions et les paliers d’abonnement deviennent un vrai montant mensuel, une plateforme hébergée peut coûter moins cher une fois intégrés l’hébergement managé, la relation avec un développeur et votre propre temps de mise en place. Le point de bascule arrive avec la croissance : les coûts hébergés tendent à augmenter avec votre chiffre d’affaires (frais, paliers supérieurs), tandis que les coûts auto-hébergés augmentent avec votre trafic et votre complexité (hébergement, développements ponctuels). Faites vos propres calculs, hébergement plus thème plus modules plus développement, sur trois ans, plutôt que de croire le chiffre mis en avant par l’un ou l’autre camp.
Qu’arrive-t-il à ma boutique si l’auteur d’un module PrestaShop disparaît ?
La copie installée continue de fonctionner. Ce sont des fichiers dans modules/ sur votre propre serveur, pas un service distant qui peut être coupé. C’est la différence structurelle avec une dépendance à une boutique d’applications SaaS. Les limites : un module qui appelle un service externe perdra ce service si l’auteur l’arrête, et un module non maintenu ne recevra pas de correctifs de compatibilité pour les futures versions de PrestaShop. L’accès au code protège donc la continuité, mais il ne remplace pas le choix de modules bien maintenus dès le départ, voir pourquoi la qualité des modules compte plus que leur quantité.
Posséder le code ne signifie-t-il pas aussi posséder tous les problèmes de sécurité ?
Vous possédez les correctifs, oui, mais « open source = moins sécurisé » relève surtout du FUD. Le nombre de CVE publiques reflète le nombre de regards qui auditent le code et la transparence avec laquelle les correctifs sont publiés, pas le niveau d’exploitabilité d’une boutique donnée. Le compromis honnête est que vous (ou votre hébergeur) devez appliquer rapidement les mises à jour de sécurité de PrestaShop et des modules ; l’avantage, c’est que rien ne se met automatiquement à jour sous vos pieds en cassant le tunnel de commande sans prévenir, et que vous pouvez lire exactement ce qu’un correctif modifie avant de l’appliquer.
Est-il difficile de quitter PrestaShop plus tard si je change d’avis ?
C’est plus simple que de quitter la plupart des plateformes hébergées, parce que les données dont vous auriez besoin sont déjà à vous : un mysqldump complet, plus vos dossiers img/ et themes/, constituent toute la boutique dans des formats lisibles par n’importe quel développeur. Les éléments les plus difficiles à extraire d’une plateforme hébergée, plans de redirections, métadonnées SEO, historique détaillé des commandes, hachages de mots de passe, sont ici de simples lignes dans des tables que vous contrôlez. Une migration reste un vrai travail, mais vous partez d’un accès complet plutôt que d’une file d’export limitée par le fournisseur.
En résumé
Posséder votre code ne consiste pas à pouvoir réécrire votre boutique sur un coup de tête, la plupart des marchands ne touchent jamais une ligne de PHP, et ne devraient pas avoir à le faire. Il s’agit de savoir où se trouve le pouvoir d’agir. Sur une plateforme louée, chaque changement important passe par la feuille de route, les prix et les autorisations d’un fournisseur. Avec PrestaShop, les leviers, le tunnel de commande, la logique tarifaire, les données, le choix du développeur, le choix de l’hébergeur, restent entre vos mains, prêts le jour où une décision fournisseur serait autrement devenue votre problème. Voilà ce que l’open source achète réellement : pas une fonctionnalité, mais la capacité de décider de l’avenir de votre propre boutique sans demander la permission.
Continuer la lecture
- PrestaShop vs Shopify : posséder ou louer, le même arbitrage de propriété face à une plateforme hébergée.
- PrestaShop vs Magento : quand l’open source se complique, de l’open source que vous possédez, mais à des niveaux de coût très différents.
- Leçons de 10 ans de développement PrestaShop, pourquoi la propriété ne paie que si les modules respectent le chemin de mise à jour de la plateforme.
