Marketplace B2B + TMS transport

Marketplace B2B de location de poids lourds avec chauffeur : un marché fragmenté, des réservations encore trop manuelles, et le besoin d’interagir avec plusieurs TMS. Le build, c’est d’abord de l’intégration — les belles pages viennent après.

B2B marketplace for HGV rental with driver: a fragmented market, still-too-manual bookings, and the need to talk to multiple TMS systems. The build is integration first — pretty pages come after.

Innovation Digitale documente ce cas sous l’angle build : pas une success story marketing creuse, un récit problématique → solution → résultat utile aux décideurs PME/ETI. Chaque techno citée renvoie au socle (/socle/) : documentation, communauté, stabilité. Le code, quand nous le livrons, vous appartient — c’est le fil rouge made in France / souveraineté numérique.

Innovation Digitale documents this case as a build story: not a hollow marketing success piece — a problem → solution → result narrative useful to SME decision-makers. Every cited technology links to the stack (/socle/): docs, community, stability. When we ship code, you own it — the Made-in-France / digital sovereignty thread.

Vous vivez un symptôme voisin (dette, silos, livraison fragile) ? Le Brief 45 minutes est gratuit : on clarifie le périmètre, puis un audit build si le sujet tient la route. La stack suit le besoin — jamais l’inverse.

Seeing a similar symptom (debt, silos, fragile delivery)? The 45-min Brief is free: we clarify scope, then a build audit if it holds. The stack follows the need — never the other way around.

Marché fragmenté (artisans vs grandes flottes), réservations manuelles chronophages, intégration complexe de multiples TMS et systèmes externes.

Fragmented market (artisans vs large fleets), time-consuming manual bookings, complex integration of multiple TMS and external systems.

Artisans vs grandes flottes, processus chronophages, connecteurs absents ou fragiles : sans APIs et webhooks stables, une marketplace logistique reste un Excel partagé avec un logo.

Artisans vs large fleets, time-consuming processes, missing or fragile connectors: without stable APIs and webhooks, a logistics marketplace stays a shared spreadsheet with a logo.

En pratique, les équipes compensent : Excel parallèle, emails comme workflow, prestataire unique qui « sait ». Chaque mois qui passe augmente le coût de sortie. L’audit build iD sert précisément à chiffrer ce risque et à proposer une phase 1 réaliste (souvent 6–8 semaines de MVP) plutôt qu’un big-bang.

In practice, teams compensate: parallel Excel, email as workflow, a single vendor who “knows”. Every passing month raises the exit cost. The iD build audit exists to price that risk and propose a realistic phase 1 (often a 6–8 week MVP) instead of a big-bang.

Architecture microservices scalable, connecteurs TMS standardisés, APIs REST documentées, webhooks temps réel, load balancing — marketplace B2B unique location PL + chauffeur.

Scalable microservices architecture, standardised TMS connectors, documented REST APIs, real-time webhooks, load balancing — unique B2B marketplace for HGV + driver rental.

Architecture microservices, connecteurs TMS standardisés, APIs REST documentées, webhooks temps réel, load balancing. Hexagonal pour isoler le domaine des adapters transporteurs.

Microservices architecture, standardised TMS connectors, documented REST APIs, real-time webhooks, load balancing. Hexagonal to isolate the domain from carrier adapters.

Service différenciant sur le transport routier local ; automatisation des processus clés ; interopérabilité TMS ; positionnement B2B clair.

Differentiating service on local road transport; key process automation; TMS interoperability; clear B2B positioning.

Service différenciant sur le transport local, automatisation des réservations, interopérabilité TMS — un positionnement B2B clair parce que le socle technique le permet.

Differentiating local transport service, booking automation, TMS interoperability — clear B2B positioning because the technical foundation allows it.

Sans contrats d’API et connecteurs stables, une marketplace logistique reste un Excel partagé. L’intégration TMS est le produit.

Without API contracts and stable connectors, a logistics marketplace stays a shared spreadsheet. TMS integration is the product.

Chez iD, ce type de projet rappelle une règle : l’intégration est le produit. Redis, API Platform, Docker, CI — les briques du socle existent pour que le métier respire.

At iD, this kind of project recalls a rule: integration is the product. Redis, API Platform, Docker, CI — stack bricks exist so the domain can breathe.

Le transport routier local est un enchevêtrement de systèmes : TMS transporteurs, outils de planning, facturation, parfois encore du téléphone et du PDF. Une marketplace qui ignore ces réalités crée de la double saisie et de la défiance. Le build a donc mis l’accent sur les connecteurs standardisés et les contrats d’API — pagination, erreurs, idempotence, webhooks de statut.

Local road transport is a tangle of systems: carrier TMS, planning tools, billing, sometimes still phone and PDF. A marketplace that ignores that reality creates double entry and distrust. So the build focused on standardised connectors and API contracts — pagination, errors, idempotency, status webhooks.

Architecture microservices et load balancing : pas pour le jargon, pour encaisser des pics de réservation et isoler un connecteur défaillant sans coucher toute la place de marché. Redis pour le cache et les files ; PostgreSQL pour le relationnel métier ; Docker pour reproduire les environnements.

Microservices architecture and load balancing: not for jargon, to absorb booking spikes and isolate a failing connector without taking down the whole marketplace. Redis for cache and queues; PostgreSQL for domain relational data; Docker to reproduce environments.

Côté méthode, l’approche hexagonale protège le domaine « réservation / mission / disponibilité » des idiosyncrasies de chaque TMS. On peut ajouter un transporteur sans réécrire le cœur. La CI et les tests d’intégration sur les adapters évitent le syndrome « ça marche avec le transporteur A uniquement ».

Method-wise, hexagonal architecture protects the “booking / mission / availability” domain from each TMS’s quirks. You can add a carrier without rewriting the core. CI and integration tests on adapters avoid the “only works with carrier A” syndrome.

Résultat business : un service B2B différenciant, automatisation des réservations, meilleure utilisation des ressources. Résultat tech : un SI raccordable. C’est le même message que sur l’industrie froid ou FlyCash — l’API-first n’est pas une mode, c’est la condition pour durer.

Business result: a differentiating B2B service, booking automation, better resource use. Tech result: a connectable IT system. Same message as cold-industry or FlyCash — API-first isn’t fashion, it’s the condition to last.

Vous avez un marché two-sided (offre / demande) avec des SI hétérogènes ? Le Brief 45 min sert à cartographier les intégrations critiques avant de dessiner les écrans.

Running a two-sided market with heterogeneous IT? The 45-min Brief maps critical integrations before you draw screens.