Quand un site e-commerce commence à nécessiter un serveur web, un serveur SQL et un moteur de recherche séparé juste pour rester stable, on sait que le vrai sujet n’est plus seulement la feature suivante. Chez nous, cette situation a existé sur des projets PrestaShop historiques. Sur certains dossiers, une requête SQL trop lourde pouvait créer un goulot d’étranglement. Un module tiers qui faisait un appel externe sans timeout pouvait fragiliser toute la plateforme. Côté front, travailler encore sur une base Bootstrap 2 voulait dire ajouter des couches de correction là où on aurait préféré construire proprement.
C’est à partir de ce type de cas concret que nous avons fait évoluer FroggShop et choisi Shopware comme socle technologique.
Ce choix ne vient pas d’un rejet de PrestaShop
Nous avons environ 15 ans d’historique sur PrestaShop. Nous savons donc très bien ce que ce socle nous a permis de faire. Il nous a aidés à livrer vite, à répondre à des besoins très spécifiques, et à accompagner beaucoup de projets e-commerce. Le sujet n’a jamais été de dire que PrestaShop “ne vaut plus rien” ou qu’il faudrait changer de technologie par effet de mode.
Le sujet était plus simple, et plus important : notre trajectoire technique.
Avec le temps, nous avons accumulé des projets historiques, des personnalisations, des dépendances, des habitudes de développement, et une dette technique de plus en plus coûteuse à porter. Certains environnements legacy devenaient plus difficiles à reproduire. Des versions PHP anciennes restaient à maintenir. Les builds devenaient plus fragiles. La même fonctionnalité pouvait être développée différemment selon les projets. Et côté front, modifier un design ou faire évoluer une base commune demandait souvent d’aller toucher de nombreux fichiers.
Autrement dit, nous n’avions pas un “problème de CMS”. Nous avions un problème de pérennité, de maintenabilité et de standardisation.
Le vrai changement : sortir de l’empilement et reprendre une trajectoire claire
Un exemple backend résume bien le problème.
Sur PrestaShop, il était possible d’aller vite. Parfois très vite. Mais cette vitesse avait un coût à long terme. Le code pouvait se disperser. La logique métier pouvait se retrouver à plusieurs endroits. Une implémentation efficace pour un projet devenait difficile à réutiliser proprement sur un autre. À l’échelle d’une agence qui fait du sur-mesure, cette liberté finit par produire beaucoup de cas particuliers.
Nous voulions sortir de cette logique.
Shopware nous a intéressés parce qu’il impose plus de cadre. L’architecture est plus stricte. La séparation des responsabilités est plus nette. Il faut mieux structurer ce qui relève de l’API, du contrôle, du rendu, des données, des extensions. En pratique, cela force à penser plus proprement. Ce n’est pas toujours agréable au début. Plusieurs développeurs de l’équipe ont vécu cette phase comme une vraie friction. Les premières fonctionnalités prenaient plus de temps qu’avant. Mais ce temps n’était pas perdu. Il servait à construire une base plus robuste.
C’est là que se situe notre choix de fond : nous ne cherchions pas juste une technologie différente. Nous cherchions un socle capable de supporter des développements sur mesure sans reproduire, projet après projet, le même chaos.
Un cas concret : développer une fois, activer plusieurs fois
Le meilleur exemple est probablement celui des points relais.
Dans une organisation classique, ce type de besoin peut être traité séparément pour chaque client. Un marchand a besoin de Colissimo. Un autre de Mondial Relay. Un troisième de Chronopost. À chaque fois, on adapte, on recode, on branche. Le besoin est couvert, mais la maintenance s’accumule aussi.
Avec FroggShop, nous avons voulu faire l’inverse. La fonctionnalité est pensée dans un socle commun, puis activée et configurée selon le projet. Cela change beaucoup de choses. On ne duplique pas la logique métier. On ne refait pas la même brique plusieurs fois. On maintient une base unique, que l’on fait évoluer proprement.
C’est important de le dire clairement : ce bénéfice ne vient pas de Shopware seul. Il vient du couple Shopware + FroggShop.
Shopware nous apporte un cadre plus sain pour développer. FroggShop apporte la couche de mutualisation qui donne du sens à ce cadre à l’échelle de l’agence et des projets clients. C’est cette combinaison qui nous permet de faire du développement Shopware sur mesure sans repartir de zéro à chaque dossier.
Même logique côté front : moins de rustines, plus de système
Le frontend raconte la même histoire.
Sur plusieurs projets historiques PrestaShop, les thèmes étaient très différents d’un client à l’autre. Il n’y avait pas toujours de design system complet partagé. Résultat : faire évoluer une charte graphique ou harmoniser des composants demandait beaucoup d’interventions dispersées. En plus, quand la base repose encore sur Bootstrap 2, l’intégration moderne devient plus coûteuse. Les équipes front doivent corriger, contourner, surcharger.
Avec Shopware, nous avons pu repartir sur une base front plus moderne, notamment avec Twig et Bootstrap 5. Mais là encore, le vrai gain ne tient pas seulement à la technologie. Il tient à ce que nous avons construit dessus.
Nous avons mis en place un design system multi-projets. Une partie des réglages globaux passe par le back-office. Une autre partie reste dans un fichier de configuration. Cela permet de décliner plusieurs projets plus vite, avec une base commune, tout en gardant le niveau de contrôle nécessaire sur le détail.
Pour un client, cela veut dire quoi ? Cela veut dire qu’un site sur mesure ne devient pas automatiquement un site impossible à maintenir. Cela veut dire que les évolutions graphiques peuvent être mieux absorbées. Cela veut dire aussi que le socle reste lisible pour l’équipe qui le maintient dans le temps.
Le choix de Shopware a aussi changé notre manière de livrer
La bascule ne s’est pas jouée uniquement dans le code applicatif. Elle a aussi transformé notre manière de déployer, de collaborer et d’exploiter.
Un exemple simple : une partie de nos anciens outils de déploiement reposait sur des scripts Bash. Ils faisaient le travail, mais restaient surtout dans le périmètre des profils infra. En modernisant FroggShop, nous avons aussi fait évoluer cette couche. Une partie de l’outillage a été repensée dans un environnement plus naturel pour nos développeurs PHP.
Le résultat a été concret. Les développeurs se sont davantage impliqués sur les crons, les workers, la préproduction et certains sujets de mise en production. La frontière entre développement et exploitation est devenue plus fluide. Cela ne veut pas dire que “tout le monde fait tout”. Cela veut dire que l’équipe travaille sur une base plus cohérente, avec moins de silos.
Même logique sur la CI/CD. Là où des process plus humains pouvaient créer de l’aléa, nous avons renforcé l’automatisation et les garde-fous. C’est plus exigeant. Cela demande plus de rigueur. Mais cela améliore la fiabilité du delivery. Et dans l’e-commerce, la fiabilité n’est pas un détail technique. C’est un sujet business.
Pourquoi ce choix est rassurant pour un client
Prenons un cas simple : un site qui doit évoluer, rester performant, absorber du sur-mesure et éviter de devenir obsolète à chaque changement de version.
C’est exactement le problème que nous cherchions à mieux résoudre.
Nous avons choisi Shopware parce qu’il répond mieux à ce que nous voulions construire : un socle plus rigoureux, plus maintenable, plus cohérent avec des développements sur mesure. Nous avons construit FroggShop au-dessus pour mutualiser ce qui doit l’être, garder la main sur la qualité, et éviter que chaque projet devienne une exception ingérable.
Ce choix demande plus d’expertise. Il demande aussi plus de méthode. Mais c’est justement ce qui nous intéresse. Parce qu’un bon socle e-commerce ne se juge pas seulement à la vitesse d’un premier développement. Il se juge à sa capacité à tenir dans le temps, à rester propre, à bien se déployer, à mieux absorber la charge, et à continuer d’évoluer sans tout remettre à plat.
C’est pour cela que nous avons choisi Shopware pour FroggShop.
Pas pour changer d’étiquette.
Pour mieux résoudre les vrais problèmes techniques de nos clients.
