Un client en logistique ne veut plus décrocher son téléphone pour savoir où est son colis. Il ouvre une application, saisit un numéro de suivi et attend une carte, un statut et une ETA réaliste. S’il ne l’obtient pas chez vous, il trouvera un transporteur qui la lui donnera. C’est pourquoi le suivi des envois et un portail client ont cessé d’être un plus agréable pour devenir une partie du service lui-même.
D’après notre expérience, le goulet d’étranglement est rarement l’idée des fonctionnalités. Le difficile est de construire un système de suivi et traçabilité (track and trace) qui porte le trafic, se branche sur votre TMS et votre télématique, et reste compréhensible pour un client non technique. Même sans présenter un déploiement précis dans ce secteur, nous fournissons les personnes et les compétences qui conçoivent et maintiennent de tels systèmes, en renfort d’équipe ou en équipe dédiée.
Qu’attend réellement un client en logistique aujourd’hui ?
Les attentes se sont nettement déplacées vers le self-service : le client veut se débrouiller seul, à toute heure, sans joindre un chargé de compte. Cela se traduit par quelques exigences fermes pour le logiciel.
- Une visibilité en temps réel - où se trouve l’envoi et ce qui lui est arrivé.
- Une ETA crédible - pas « d’ici la fin de la semaine » mais une fenêtre horaire concrète.
- Une information proactive - une notification avant que le client ne commence à s’inquiéter.
- Un point d’accès unique - un portail montrant toutes les commandes, pas des liens éparpillés.
Répondre à ces attentes réduit le volume d’appels, car la plupart des questions « où est mon envoi » trouvent une réponse sans intervention humaine.
Comment concevoir une page de suivi d’envoi (statuts, événements, ETA) ?
Une page de suivi et traçabilité semble simple, et pourtant elle est événementielle en dessous. Son cœur est l’historique des événements de l’envoi (event log) : réceptionné à l’entrepôt, chargé, transféré au hub, en cours de livraison, livré. Chaque événement porte un horodatage, un lieu et sa source, et nous en déduisons le statut courant et l’ETA prévue.
Nous concevons le modèle de données pour qu’un événement technique (un scan brut, un signal de télématique) reste séparé du statut montré au client, ce qui nous permet d’ajouter une source ou de renommer des statuts sans reconstruire l’écran. Nous calculons l’ETA à partir des données historiques et de la position actuelle du véhicule plutôt que d’un plan figé, car ce n’est qu’ainsi qu’elle vaut quelque chose.
Comment construire un portail client et un portail partenaire (authentification, rôles) ?
Un portail est l’endroit où le client se connecte pour voir l’ensemble de ses commandes, tandis qu’un partenaire ou un transporteur ne voit que sa part. L’authentification et les rôles sont le nœud, car ils décident de qui voit quoi.
- L’authentification - e-mail/mot de passe, connexion d’entreprise (SSO, OAuth) et, en option, un second facteur.
- Le modèle de rôles (RBAC) - expéditeur, destinataire, commissionnaire de transport, transporteur, administrateur du compte.
- Le multi-tenant - un portail qui sert de nombreuses entreprises clientes, avec des données maintenues à part.
- Les droits sur les données - le client voit ses commandes, le partenaire ses tâches, personne ne voit celles des autres.
Le plus gros piège ici n’est pas l’apparence mais l’isolation propre des données entre tenants ; nous concevons donc la séparation des droits dès le premier jour plutôt que de l’ajouter ensuite.
Comment gérer la preuve de livraison (POD : signature, photo, géolocalisation) ?
La preuve de livraison clôt le cycle de vie d’un envoi et sert souvent d’élément de preuve en cas de litige. De nos jours, elle est rarement sur papier : le conducteur confirme la livraison dans une application mobile, et le système réunit un jeu complet de preuves qu’il rattache à la commande.
Cela signifie généralement une signature du destinataire sur l’écran, une photo du colis ou du point de dépôt, et la géolocalisation et l’horodatage de la livraison. Nous concevons cela pour le travail hors ligne, car un conducteur sur la route perd régulièrement le signal : l’application stocke la preuve de livraison localement et la synchronise au retour de la connexion, pour qu’aucune preuve ne soit perdue. La confirmation apparaît ensuite dans le portail client comme élément de l’historique de l’envoi.
Comment construire les notifications et les alertes d’exception (événements) ?
Un bon suivi et traçabilité n’attend pas que le client consulte le statut ; il envoie un signal quand quelque chose compte. Il est utile de séparer deux types de message : les notifications de progression de routine et les alertes d’exception, c’est-à-dire les situations qui exigent une réaction.
- Les notifications d’événement - réceptionné, en cours de livraison, « livraison aujourd’hui », livré.
- Les alertes d’exception - retard, échec de livraison, dommage, blocage en douane.
- Les canaux - e-mail, SMS, push dans l’application, et un webhook pour les clients système.
- Les règles - qui reçoit quelle alerte et au bout de combien de temps une escalade se déclenche.
Nous construisons ces alertes sur le même flux d’événements qui alimente la page de suivi, pour que le client et l’opérateur voient toujours la même chose.
Comment relier le tout au TMS et à la télématique ?
Un portail ne vaut que ce que valent les données qui y arrivent. Ces données naissent rarement dans le portail lui-même, et le vrai travail consiste donc à intégrer le TMS et la télématique embarquée. Du TMS, nous tirons les commandes, les tournées et les statuts opérationnels ; de la télématique et des appareils mobiles des conducteurs, la position GPS et les événements en route.
Nous relions ces sources par une couche d’intégration, généralement via des API et des webhooks, et par fichiers (EDI, CSV) quand un partenaire échange ses données par lots. La normalisation compte : différents transporteurs et appareils décrivent les mêmes événements différemment, nous les mappons donc vers un vocabulaire de statuts commun avant qu’ils n’atteignent le client. Le portail montre alors une image cohérente, quel que soit le nombre de systèmes qui l’alimentent.
Quelles compétences apportons-nous à un projet de ce type ?
Nous façonnons l’équipe autour du périmètre précis, pas « au cas où ». Un projet de suivi et traçabilité couvre un backend événementiel, une application conducteur et des intégrations, il demande donc généralement plusieurs rôles.
- Un développeur backend qui construit le modèle d’événements, les API et la logique des statuts et de l’ETA.
- Un développeur frontend qui assemble le portail client et la page de suivi.
- Un développeur mobile responsable de l’application avec la preuve de livraison et le travail hors ligne.
- Un spécialiste de l’intégration qui branche le TMS, la télématique et l’échange de données partenaires.
- Un spécialiste DevOps qui met en place le cloud, la CI/CD et le monitoring pour le trafic de production.
Nous pourvoyons ces rôles avec des spécialistes vérifiés avant le démarrage. En option, nous ajoutons une couche IA/Data (au sein du groupe RITS, nos équipes IA/LLM/data développent les compétences LLM et data) pour la prédiction de l’ETA ou la détection d’anomalies sur les tournées, mais nous la traitons comme un ensemble de compétences, pas comme une boîte sur étagère.
Comment procédons-nous chez RITS ?
Nous travaillons comme partenaire nearshore depuis la Pologne, avec une expérience des projets industriels et des systèmes qui relient appareils, cloud et applications. Nous ne prétendons pas avoir un suivi et traçabilité tout prêt dans un tiroir ; nous vous donnons plutôt les personnes qui concevront et maintiendront ce système aux côtés de votre équipe.
- Nous pourvoyons les rôles selon le cahier des charges du projet et vérifions les compétences avant toute arrivée.
- Nous intervenons en renfort d’équipe ou en équipe dédiée, selon que vous avez déjà ou non une équipe noyau.
- Nous travaillons dans un fuseau horaire proche, donc les revues de code et les réunions se déroulent sans longue montée en charge.
- Nous concevons le suivi et traçabilité de bout en bout : du flux d’événements à la preuve de livraison, jusqu’aux intégrations.
Pour un produit neuf, c’est plus souvent un projet de logiciel sur mesure ; pour faire évoluer un portail existant, le renfort d’équipe. Nous avons exposé les différences entre ces modèles dans notre article sur les modèles de collaboration IT.
Par où commencer avec le suivi et un portail ?
Partez de la question client qui frappe le plus souvent le support (généralement « où est mon envoi et quand arrivera-t-il »). Y répondre définit le modèle d’événements minimal, le premier écran de suivi et traçabilité et l’intégration à construire en premier. Vous ajoutez le reste du portail par couches une fois cette fondation en place.
Vous construisez un suivi des envois ou un portail client logistique ? Parlons-en - nous ajusterons une équipe et une architecture à votre suivi et traçabilité.
Construisez votre suivi des envois et votre portail client avec nous