Contexte du projet
BuyStep met en relation des acheteurs professionnels et des fabricants d'équipements énergétiques : panneaux solaires, batteries, onduleurs, stations d'énergie portables. Le constat de départ tient en une phrase, reprise sur le site de BuyStep : le vrai défi n'est pas de trouver des fournisseurs, c'est de prendre la bonne décision. Les données sont auto-déclarées, les certifications difficiles à comparer, et une visite d'usine coûte cher.
La plateforme répond par une position claire : BuyStep ne compare pas les prix, BuyStep compare la fiabilité des fournisseurs. Notre rôle a été de construire l'ensemble : le portail public, les espaces acheteur et fournisseur, le moteur d'audit et de scoring, la facturation par abonnement et l'administration.
Ce que nous avons construit
- Portail public Next.js 16: catalogue de produits, fiches fournisseurs, catégories, recherche, pages éditoriales. Six langues (anglais, français, espagnol, arabe, hindi, chinois), y compris l'écriture de droite à gauche.
- Audit 9.0: chaque fournisseur remplit une structure unique en 9 dimensions et plus de 200 critères, avec ses documents et certifications. Statuts par section, seuil de complétion à 85 %, données auto-déclarées recoupées avec l'historique, l'analyse IA, des outils numériques et, si nécessaire, une visite physique.
- BuyStep Score: le moteur d'analyse qui transforme l'audit en indicateurs de fiabilité. Trois piliers, des règles de notation explicites et des drapeaux de risque, dont les déclencheurs RSE liés à la directive européenne CSDDD.
- Espace fournisseur et espace acheteur: tableau de bord, produits, audit section par section d'un côté ; comparaison, favoris, messagerie et fournisseurs « Vérifié BuyStep » de l'autre.
- Abonnements Stripe: trois niveaux d'offre, webhooks, cycle de vie complet (actif, expiré, annulé, annulation programmée, impayé), paiement SEPA et virement activables par configuration.
- Administration Next.js: modération des entreprises, catégories, coupons, abonnements, actions à traiter, journal d'audit et suivi du revenu récurrent.
Architecture
Une seule API REST .NET 10 sert le portail et l'administration. Elle suit une Clean Architecture en quatre couches (Domain, Application, Infrastructure, WebApi), que des tests d'architecture vérifient à chaque build : une couche ne peut pas en traverser une autre.
- Données : PostgreSQL via EF Core, plus de 55 entités, traductions stockées en base (une entité, une table de traductions), migrations versionnées, Elasticsearch pour la recherche.
- Portail en BFF: les routes API de Next.js font office de Backend-for-Frontend. Elles injectent le jeton JWT côté serveur, gèrent la session et le rafraîchissement des jetons (NextAuth 5) et transforment les DTO en types frontend. Le navigateur ne voit jamais l'API.
- Fichiers et images: stockage objet compatible S3, compression WebP automatique à l'upload.
- Mappings générés à la compilation(Mapperly) à la place d'AutoMapper : pas de réflexion à l'exécution, pas de licence à renouveler.
Qualité et livraison
- Trois niveaux de tests : unitaires (MSTest, Moq), intégration sur un vrai PostgreSQL éphémère (Testcontainers, base remise à zéro entre les tests), et architecture (NetArchTest).
- Pipeline Azure DevOps en cinq étapes: build, tests unitaires en quelques secondes, tests d'intégration avec couverture, images Docker de l'API, de l'administration et du portail, déploiement par branche (développement, production).
- Exploitation: journaux Serilog en fichiers tournants, mesure d'audience Matomo, page de maintenance dédiée pour les fenêtres d'intervention.
Trajectoire de la plateforme
BuyStep n'est pas née dans sa forme actuelle. Les captures ci-dessous sont réelles : nous avons extrait vingt-six commits de l'historique Git, reconstruit chacun d'eux dans des conteneurs avec le SDK et la base de données de son époque, relancé l'application et photographié ses pages. Vingt-cinq ont redémarré. Aucune maquette, aucune image de banque.
Première version: un monolithe Blazor Server sur MySQL. Une page d'accueil, trois offres, un catalogue en construction. Suffisant pour valider l'idée, pas pour scaler.
Version intermédiaire: toujours Blazor, mais un domaine métier complet (entreprises, produits, traductions, abonnements), une API REST et un back-office. Le positionnement se resserre sur l'énergie.
Portail actuel : le monolithe a été découpé en un monorepo apps/ + libs/, la base migrée de MySQL vers PostgreSQL, le framework porté sur .NET 10 et le front réécrit en Next.js 16. Le code hérité a été supprimé une fois le portail au niveau : pas de double maintenance.
Résultats
- Une structure de données unique par fournisseur, comparable d'un fabricant à l'autre : 9 dimensions, 200+ critères, documents à l'appui.
- Six languesservies par un seul portail, avec des traductions d'entités en base plutôt que des fichiers dupliqués.
- Plus de 1 700 commits et 140 fusions en production, couverts par des tests unitaires, d'intégration et d'architecture exécutés à chaque livraison.
- Une migration de socle complète (framework, base de données, front) sans réécriture du domaine métier : la Clean Architecture a tenu son rôle.
Conclusion
BuyStep montre ce qu'une application métier devient quand elle est conçue pour durer : un domaine stable, des couches étanches, et des socles techniques que l'on peut remplacer un par un. La marketplace sert aujourd'hui acheteurs et fabricants dans six langues, et son audit fournisseurs est devenu le cœur de la proposition de valeur.
Pour aller plus loin
- Choisir un fournisseur d'énergie sur des preuves — ce que fait la plateforme : Audit 9.0, BuyStep Score, et où l'IA intervient réellement.
- Deux ans d'aléas, un socle qui n'a pas bougé — deux ans d'aléas encaissés sans réécrire le domaine métier, migration par migration.
- Anatomie d'un virage à trois semaines — comment le socle a pu être remplacé entièrement sans réécrire le domaine métier.
- Rejouer deux ans de commits dans Docker — l'outillage qui a produit ces captures, et ce qu'il révèle d'un dépôt.