Tous les logisticiens au-dessus d'une certaine taille ont eu cette conversation. Un client clé réclame un vrai portail client, celui du WMS ne fait manifestement pas l'affaire, et quelqu'un dit : « on a des développeurs, faisons-le nous-mêmes. Au moins il fera exactement ce qu'on veut. »
C'est un réflexe raisonnable, et certains 3PL ont livré une v1 dont ils sont fiers. Mais à force d'observer ces projets de l'intérieur, un pattern se dégage : la décision de développer n'échoue presque jamais à cause de la première version. Elle échoue à cause de tout ce qui vient après. Voici le calcul complet, et une grille honnête pour décider.
Ce que développer coûte vraiment
Le coût visible, c'est la première construction : pour un portail qui couvre une vraie collaboration (commandes, modifications, litiges, documents, alertes), comptez 6 à 18 mois de développement avant que le premier client ne se connecte. La plupart des logisticiens budgètent cette partie, plus ou moins juste.
Les coûts qui coulent le projet arrivent ensuite.
L'intégration n'est pas une phase, c'est un tapis roulant. Le portail ne vaut que par sa connexion au WMS. Si vous exploitez plusieurs WMS, chacun demande sa propre intégration. Chaque montée de version casse quelque chose. Chaque nouveau site, chaque acquisition, chaque client avec un flux EDI spécifique ajoute du travail. C'est exactement le genre de backlog ingrat et jamais terminé que les équipes internes dépriorisent dès qu'un projet critique pour l'entrepôt apparaît.
Chaque client veut un portail légèrement différent. Le schéma historique de la logistique contractuelle, c'est un développement sur mesure par compte clé. Ça ne scale pas : dix clients, c'est dix variantes à maintenir, et le coût marginal d'onboarding du onzième client ne baisse jamais. Le portail qui devait être un produit devient une collection de projets.
La roadmap meurt en silence. La v1 sort. Puis votre bande passante IT est réquisitionnée par une migration ERP, une montée de version WMS, l'ouverture d'un site. Pendant ce temps, les éditeurs de portails dédiés livrent l'intégration de commandes par IA, l'analytics conversationnel, les moteurs d'automatisation. Dix-huit mois plus tard, vos clients comparent votre portail à ce qu'ils voient ailleurs, et vous êtes en retard d'une génération, en permanence, avec la facture de maintenance qui continue de tourner.
Sur les logisticiens avec lesquels nous avons travaillé, le coût complet de construction et de maintenance d'un portail comparable ressort à environ 5 fois le coût total de possession d'une solution achetée, pour un time-to-market environ 20 fois plus lent (des mois de développement contre des semaines de déploiement).
La vraie monnaie, ce n'est pas l'argent, c'est la bande passante IT
L'argument historique pour développer, c'était le contrôle : votre marque, vos workflows, pas de dépendance à la roadmap d'un éditeur. Cet argument tenait face aux portails rigides et brandés éditeur. Il tient beaucoup moins face à un portail en marque blanche et agnostique du WMS, où :
- La marque est la vôtre. Vos clients voient votre logo, votre domaine, vos couleurs. En démo d'appel d'offres, le prospect évalue votre expérience digitale, pas celle d'un fournisseur.
- L'intégration est faite pour vous. Spacefill se connecte à 50+ WMS via des connecteurs existants et réalise le travail d'intégration : l'implication de votre équipe IT se mesure en jours, pas en trimestres. Le déploiement prend environ 4 semaines.
- La roadmap se cumule en votre faveur. Les fonctionnalités financées par tout un réseau de logisticiens (traitement de commandes par IA, accès conversationnel aux données, règles d'automatisation) arrivent sans que vous ayez à les staffer.
- Un seul portail couvre tous les clients et tous les sites, quel que soit le WMS en dessous. Exactement ce que les développements sur mesure par client n'atteignent jamais.
Le Groupe Deret, un des premiers logisticiens français, est le cas de référence : plutôt que de redévelopper un portail par client, ils ont déployé un portail agnostique unique sur 25+ entrepôts tournant sur des systèmes différents, en production en quelques mois, avec des APIs ouvertes qui alimentent leur propre plateforme data. Le contrôle était l'argument du développement interne ; ils en ont obtenu davantage en achetant.
La grille en cinq questions
Si vous pesez la décision, répondez honnêtement à ceci :
- Avez-vous (et voulez-vous financer) une équipe produit permanente, pas seulement une équipe projet ponctuelle ? Un portail est un produit : sans équipe permanente, pas de roadmap, et un portail sans roadmap est un passif dès la deuxième année.
- Combien de WMS exploitez-vous aujourd'hui, et dans trois ans ? Chacun multiplie la charge d'intégration. À partir de deux, le développement interne survit rarement au contact du réel.
- Combien de clients devez-vous onboarder dans les 24 prochains mois ? L'approche sur mesure par client s'effondre au-delà d'une poignée ; seule une approche produit fait baisser le coût d'onboarding dans le temps.
- Qu'est-ce qui gagne vos appels d'offres : votre logiciel ou votre logistique ? Ce qui gagne mérite votre bande passante IT. Le reste doit s'acheter.
- Combien coûte un retard de 18 mois ? Pas le coût de développement : les appels d'offres perdus entre-temps face à des concurrents qui démontrent un portail fini dès le trimestre prochain.
Si vos réponses pointent vers le développement interne, faites-le avec un engagement total : équipe produit staffée, budget pluriannuel, stratégie d'intégration. Sinon (et pour la plupart des 3PL, c'est sinon), l'option d'achat moderne a fait disparaître les raisons historiques de développer.
