Build vs. buy : pourquoi les projets logiciels des 3PL finissent tous de la même façon

Chaque prestataire logistique aborde la question logicielle de la même façon. Il regarde le coût d'une solution externe. Il conclut qu'aucun éditeur ne comprend vraiment son métier. Et il décide de construire son propre portail client, ses propres connecteurs, sa propre couche de visibilité.

La plupart sont encore bloqués au même endroit des années plus tard.

L'argument "développer en interne" semble raisonnable, en apparence seulement.

La version 3PL de l'argument est logique : notre WMS gère déjà les stocks. On a juste besoin d'une couche au-dessus pour montrer la donnée à nos clients. On connaît notre métier mieux que n'importe quel éditeur. Notre modèle de facturation, notre mix de services, sont trop spécifiques pour une solution générique.

Cela est logique uniquement à première vue.

Le portail n'est pas la partie difficile. La partie difficile, c'est tout ce dont le portail dépend. Il doit aller chercher des données temps réel dans vos WMS, quels que soient les WMS, quelles que soient leur ancienneté. Il doit présenter ces données différemment pour chaque client chargeur, selon leur propre logique, leur propre nomenclature, leurs propres seuils d'alerte. Il doit se connecter aux ERP, aux plateformes e-commerce et aux systèmes transport de vos clients via des formats EDI et API qui varient par client et qui changent sans préavis quand le chargeur met à jour ses systèmes.

Et tout ça doit fonctionner à l'échelle, pour tous vos clients, le jour où un nouveau client signe, pas trois mois plus tard, une fois l'intégration enfin testée et déployée.

Ce n'est pas un projet de portail. C'est un projet d'infrastructure de connectivité avec un portail posé dessus. La différence ne devient visible qu'une fois le projet lancé.

Les coûts sont toujours sous-estimés

En année 1, le périmètre se résume à un tableau de bord et quelques rapports. La complexité technique semble gérable.

Puis un gros chargeur demande une intégration EDI. Un deuxième veut une confirmation automatique de réception en entrée. Un troisième veut des alertes d'anomalie remontées dans son propre outil. Chaque demande est légitime côté chargeur. Mais chaque demande est un projet technique à part entière de votre côté.

En année 2, le périmètre initial a explosé. Il intègre désormais du travail d'intégration qui ne figurait pas dans le business case de départ. L'équipe a grossi. Le planning a glissé. Le budget est déjà consommé.

En année 3, l'entreprise ne prend plus la décision qu'elle croyait prendre au départ. La question n'est plus de savoir s'il faut construire un portail client. C'est comment gérer un portefeuille grandissant d'intégrations custom avec chaque client chargeur,des intégrations qui cassent différemment quand quelque chose change côté chargeur, et qui nécessitent des développeurs capables de comprendre à la fois le domaine logistique et la spécification technique de cette intégration précise. On se retrouve avec autant de portails clients que de clients.

Le coût, ce n'est pas juste le développement. C'est la maintenance, le support, la réintégration, la dépendance aux personnes qui maintiennent les systèmes et la mémoire institutionnelle nécessaire pour tout tenir ensemble. Rien de tout ça ne figurait dans le business case initial.

Et le problème humain est fondamentalement sous-estimé

La personne la mieux placée pour spécifier ce qu'un portail client 3PL doit faire, c'est votre meilleur responsable commercial ou opérationnel. Celui qui sait exactement ce que vos chargeurs remontent en comité de pilotage. Celui qui comprend pourquoi tel client se plaint chaque fin de mois, et quelle donnée il cherche réellement.

Ce n'est pas une personne que vous pouvez sortir du pilotage client pendant douze mois pour spécifier un produit.

Ce qui se passe en pratique : un compromis. La spécification est écrite par les gens disponibles. L'équipe de développement produit quelque chose de techniquement correct qui rate la réalité opérationnelle de ce que les chargeurs attendent vraiment. Le premier chargeur à tester le portail, le fait au bout de 6 mois avec une boucle de feedback très lente et coûteuse.

L'écart entre ce qui a été spécifié et ce qui était nécessaire n'est pas un échec de l'équipe technique. C'est ce qui arrive quand les gens qui ont la connaissance pour bien spécifier un produit ne peuvent pas lui donner l'attention requise, parce que l'opérationnel les réclame en permanence.

Apprenons des erreurs des autres acteurs logistiques pour ne pas les reproduire à nouveau

Les 3PL qui ont construit leurs propres portails et couches d'intégration il y a cinq ans se retrouvent aujourd'hui dans l'une de ces deux positions. Soit ils maintiennent une base de code techniquement fonctionnelle mais commercialement en retard sur ce que la concurrence propose en standard. Soit ils ont la même conversation build vs. buy qu'en 2019 sauf qu'ils ont maintenant un système legacy à remplacer en plus d'un nouveau à construire.

Dans les deux cas, l'équipe commerciale gère les objections des prospects sur des fonctionnalités que des concurrents livrent d'emblée. L'équipe opérationnelle traite des incidents d'intégration qu'une plateforme pré-connectée n'aurait pas générés. Et le budget technologique est absorbé par une maintenance qui ne produit aucune valeur commerciale nouvelle.

Les 3PL qui gagnent des appels d'offres aujourd'hui ne sont pas ceux qui ont les meilleures équipes de développement internes. Ce sont ceux dont les équipes commerciales et opérationnelles passent leur temps sur la qualité de service et les relations clients parce que la question technologique est déjà résolue.

Pourquoi l'IA rend cette décision plus critique que jamais pour les prestataires logistiques

Tous les 3PL sont démarchés sur l'IA aujourd'hui. Détection d'anomalies automatisée, planification de la main-d'œuvre, optimisation du slotting dynamique. Les cas d'usage sont réels, les gains d'efficacité sont significatifs.

Ce que presque personne ne dit clairement : l'IA en logistique nécessite une fondation de données propres, structurées, en temps réel. Elle nécessite une couche qui connecte mouvements de stock, flux entrants, statuts de commandes et événements clients dans un enregistrement cohérent unique. Un portail custom maintenu par des intégrations point-à-point ne fournit pas cette fondation. Un portail natif WMS limité à un seul système ne peut pas la fournir sur une opération multi-sites, multi-WMS.

Les 3PL qui capteront les gains de l'IA ne sont pas ceux qui l'adopteront en premier. Ce sont ceux dont l'infrastructure de données sera prête à l'accueillir.

La décision build vs. buy n'a jamais eu autant d'enjeux qu'aujourd'hui.

Ce que Spacefill a construit pour les prestataires logistiques : un portail client 3PL opérationnel en semaines

Spacefill 360 Portal a été conçu spécifiquement pour ce problème. Ce n’est pas une plateforme générique adaptée à la logistique, mais une solution pensée dès le départ autour de la façon dont les 3PL fonctionnent réellement et de ce que leurs clients chargeurs attendent.

Un portail client en marque blanche opérationnel en semaines, pas en mois. Des connecteurs pré-construits vers plus de 500 entrepôts 3PL et 50 WMS, ERP et CMS dont Shopify, Prestashop, Magento côté e-commerce, et Reflex, Akanea, Generix, EPG, Extensiv, Shiphero, Manhattan, Effitrace, Sinari côté WMS sans projet d'intégration custom pour chaque nouveau client chargeur.

Une logique de facturation qui gère la complexité que les contrats 3PL produisent réellement : au SKU, à la palette, à l'opération, avec des barèmes spécifiques par client configurés sans cycle de développement. Des alertes et rapports remontés directement dans les outils du chargeur (Slack, Teams, Zendesk, Gorgias) sans que votre équipe ne soit dans la boucle de chaque échange.

Résultats mesurés sur la base installée : -75 % de contacts pour savoir où est ma commande (WISMO), 90 % de tâches manuelles supprimées, 94 % d'erreurs de préparation en moins. Un déploiement 3 fois plus rapide qu'un projet traditionnel.

Aucun risque de développement. Aucune charge de maintenance qui mobilise vos meilleurs profils loin de vos clients. Aucune décision d'architecture prise en 2021 qui limite ce que vous pouvez offrir en 2026.

Les DSI ont d’autres sujets plus importants et impactants que de passer des années à construire un nième portail client. Ils le savent déjà. Mais est ce que les directions logistiques, commerciales et générales sont prêtes à l’entendre?

FAQ