- Projet
- Case study
Trouv'li : développer une marketplace accessible avec Symfony et Alpine.js pour l'île Maurice
![Trouv'li : développer une [[marketplace accessible]] avec Symfony et Alpine.js pour l'île Maurice](/_next/image?url=https%3A%2F%2Fsupabase.clementmenczynski.fr%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fimages%2Fprojets%2Ftrouvli.webp&w=3840&q=75)
Trouv'li, c'est une marketplace locale à l'île Maurice, inspirée du Bon Coin. J'ai rejoint le projet aux côtés d'un autre développeur qui gérait le backend, avec une mission claire côté front : construire l'intégralité des interfaces d'une V1 complète pensée pour tester le marché mauricien. Le pari ? Livrer vite, proprement, et avec une accessibilité intégrée dès le départ.
Le brief : une marketplace pensée pour l'île Maurice
Trouv'li, c'est une plateforme où particuliers et professionnels peuvent acheter, vendre ou échanger des biens et services. Rien de révolutionnaire dans le concept, le modèle du Bon Coin a fait ses preuves. Mais l'enjeu était ailleurs : adapter ce modèle au contexte mauricien et en faire une référence dans le paysage numérique local.
Pourquoi le modèle Le Bon Coin adapté au marché mauricien
L'île Maurice est un marché où les plateformes de petites annonces n'ont pas encore la maturité qu'on connaît en Europe. Le client avait une ambition claire : devenir incontournable pour connecter les communautés locales. Le Bon Coin comme modèle d'inspiration, c'était le bon point de départ, un C2C/B2C éprouvé, des mécaniques simples que tout le monde comprend.
Mais le client voulait avant tout tester le marché. Pas question de partir sur une architecture pensée pour des millions d'utilisateurs dès le jour 1. Il fallait une V1 solide, fonctionnelle, mais suffisamment pragmatique pour valider l'appétit du marché avant d'investir davantage. Cette contrainte a dicté tous nos choix techniques.
L'accessibilité comme exigence, pas comme bonus
C'est le volet dont je suis le plus fier sur ce projet. Dès le premier commit, l'accessibilité a été traitée comme une fonctionnalité à part entière, pas comme une checklist à cocher avant la mise en production.
Navigation clavier, contrastes et lecteurs d'écran dès le premier commit
Concrètement, ça veut dire quoi ? Navigation clavier complète sur toute la plateforme. Gestion rigoureuse des contrastes pour que chaque élément soit lisible. Compatibilité avec les lecteurs d'écran testée au fil du développement. L'objectif était d'atteindre le meilleur score possible en s'orientant vers les standards WCAG.
Sur une marketplace, l'accessibilité n'est pas qu'une question d'éthique, c'est une question de marché. Chaque utilisateur qui ne peut pas naviguer correctement, c'est un acheteur ou un vendeur en moins. Dans un contexte où le client veut tester l'adoption, se priver d'une partie de l'audience dès le départ n'aurait eu aucun sens.
Mon rôle couvrait l'intégralité des interfaces utilisateur et de l'accessibilité. Ce qui est intéressant quand on gère les deux en même temps, c'est qu'on ne pense jamais l'accessibilité comme un patch. Elle influence les choix de composants, la structure HTML, la hiérarchie des contenus. Ça produit un code plus propre, plus sémantique, et paradoxalement plus simple à maintenir.
Intégrer l'accessibilité dès le départ coûte presque rien. L'ajouter après coup coûte une refonte.
Les fonctionnalités qui font vivre la plateforme
Une marketplace tient sur quelques briques essentielles, et Trouv'li les couvre toutes. Un système de recherche de produits avec filtrage par catégories, une pagination propre pour naviguer dans les listes d'annonces, une messagerie intégrée entre acheteurs et vendeurs, et des profils utilisateurs pour chaque membre. Côté front, j'ai intégré chacune de ces briques, tandis que la logique serveur et la gestion des données étaient assurées par le développeur backend.
Rien d'extravagant, et c'est voulu. Pour une V1 destinée à valider un marché, chaque fonctionnalité doit justifier sa présence. La recherche avec catégories permet de trouver ce qu'on cherche. La messagerie permet de conclure une transaction. Les profils créent un minimum de confiance. La pagination rend la navigation supportable quand le contenu grandit.
Si c'était à refaire, je garderais exactement ce périmètre fonctionnel. La tentation d'ajouter des favoris, un système de notation, des notifications push, elle est toujours là. Mais pour une première version, moins c'est plus.
Ce que je retiens de ce projet sans surprise
Soyons honnête : techniquement, Trouv'li n'a pas été un projet difficile. Pas de bugs mystérieux, pas de problème de performance inattendu, pas de nuit blanche à debugger un edge case improbable. Le développement s'est déroulé de manière fluide, et le client était satisfait du résultat.
Et c'est justement là qu'il y a quelque chose à en tirer. Un projet qui se passe bien, c'est souvent le signe que les choix en amont étaient les bons. Pas de framework surdimensionné pour un besoin simple. Pas de fonctionnalités superflues quand l'objectif est de tester le marché.
Le vrai apprentissage, il est là : savoir calibrer la réponse technique au besoin réel. C'est moins spectaculaire qu'un war story sur un incident de production, mais c'est une compétence qui fait la différence au quotidien.
Un projet "sans surprise", c'est rarement un hasard. C'est le résultat de choix techniques alignés avec le besoin business.
Sous le capot : une stack SSR légère plutôt qu'une SPA
Pour ceux que la technique intéresse, parlons des choix qui ont rendu tout ça possible.
Dans un écosystème où la tentation est forte de partir sur une SPA avec React ou Vue.js, on a fait le choix inverse. Rendu côté serveur avec Symfony et Twig, interactivité ponctuelle avec Alpine.js, et Tailwind CSS pour aller vite sur l'intégration.
Symfony, Twig, Alpine.js et Tailwind : tester le marché sans sur-ingénierer
Pourquoi Symfony ? C'est un framework PHP robuste, parfaitement adapté aux applications web structurées. Couplé à Twig pour le templating côté serveur, on obtient un socle fiable sans la complexité d'une architecture découplée front/back. Le développeur backend a mis en place toute la logique métier et les API côté Symfony, pendant que je me concentrais sur les interfaces et l'expérience utilisateur avec Twig et Alpine.js.
Le vrai choix différenciant, c'est Alpine.js. Pour une marketplace, on a besoin d'interactivité : des filtres dynamiques, des menus, des modales. Mais a-t-on besoin d'un virtual DOM et de 200 Ko de JavaScript pour ça ? Non. Alpine.js pèse quelques Ko, s'intègre directement dans le HTML, et fait exactement ce qu'on lui demande. Pas de build complexe, pas de state management global, pas de dette technique prématurée.
Tailwind CSS complète le tableau : développement rapide, design cohérent, pas de fichiers CSS qui s'empilent. Pour une V1 où la vitesse de livraison compte autant que la qualité, c'était le bon outil.
Côté base de données, PostgreSQL assure la persistance. Fiable, performant, et suffisamment flexible pour accompagner l'évolution de la plateforme si le marché répond bien.
La meilleure architecture pour une V1, c'est celle qui vous permet de livrer vite, d'apprendre vite, et de pivoter sans tout réécrire.
Conclusion
Trouv'li m'a rappelé qu'un bon projet n'est pas forcément celui qui pousse la stack dans ses retranchements. C'est celui où chaque décision, du framework au périmètre fonctionnel, sert un objectif clair. Ici, livrer une marketplace accessible et fonctionnelle pour tester le marché mauricien.
Si vous travaillez sur un projet similaire ou si vous cherchez un développeur qui sait doser la technique en fonction du besoin, n'hésitez pas à me contacter ou à explorer mes autres projets.
![2 ans et demi comme [[développeur en startup]] : retour d'expérience chez ncScale](/_next/image?url=https%3A%2F%2Fsupabase.clementmenczynski.fr%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fimages%2Fprojets%2Fncscale.webp&w=2048&q=75)