RÉSEAU · PORTAIL LOGISTIQUE
Votre transitaire vous tient informé par e-mail. L'équipe dispatch saisit les jalons dans un tableur partagé que quelqu'un oublie constamment d'actualiser. Les dates de dédouanement arrivent en captures d'écran PDF. Les barèmes de tarifs vivent dans un dossier SharePoint. Quand le conteneur prend du retard, vous l'apprenez de l'importateur qui demande pourquoi. Votre « fiche d'expédition » est une fiction reconstituée à partir de trois boîtes mail et d'un WhatsApp.
Le Portail logistique dans TradeOS est un cockpit à vos couleurs où vos transitaires, courtiers et transporteurs travaillent directement — même base de données, limitée à ce qu'ils ont besoin de voir. L'Inbox structurée remplace les e-mails ad hoc. Les vrais jalons s'ancrent sur de vrais automates d'état. Douane, dispatch, facturation et échanges, tout sur un seul enregistrement. Identité multi-tenant : un login, plusieurs espaces de travail opérateurs, chacun isolé. Gratuit pour le prestataire. Ne remplace pas un TMS.
Réserver une démoVoir les tarifs →
Sections du portail
7 · inbox, expéditions, dispatch, factures et 3 autres
Modes logistiques
Maritime, aérien, routier, ferroviaire, express et 3 autres
Identité multi-tenant
Un login, plusieurs espaces de travail opérateurs
Coût pour le transitaire
$0 · l'opérateur paie pour TradeOS
Le véritable Dashboard d'accueil — bandeau de bienvenue, widget carte du monde avec les expéditions actives à leurs positions, file d'actions en deux colonnes. Un seul appel backend (GET /portal/logistics/home) retourne l'ensemble des données. Le chrome de marque de l'opérateur (logo, couleur, libellé de l'espace de travail) est rendu depuis les paramètres de tenant de l'opérateur.
LE JALON QUI NE SE MET JAMAIS À JOUR
Le transitaire est compétent. Le courtier est réactif. La page de suivi du transporteur existe. Rien de tout cela n'aide lorsque le système d'enregistrement d'une seule expédition est réparti entre trois boîtes mail, deux feuilles de calcul, un dossier SharePoint et un groupe WhatsApp où personne n'est dans le même fuseau horaire.
01 · LES JALONS VIVENT DANS UN TABLEUR PARTAGÉ
Votre transitaire met à jour un Google Sheet à un rythme différent de celui de l'importateur qui vous relance. L'équipe opérationnelle dispose de deux sources de vérité — le tableur et la page de suivi du transporteur — et elles divergent de trois jours. Le temps que vous obteniez la réponse, le conteneur a franchi la douane sans que personne ne s'en soit aperçu.
02 · LES MISES À JOUR DOUANIÈRES VIVENT DANS DES FILS D'E-MAILS
Le courtier en douane est rapide, mais son canal, c'est la boîte mail qu'il avait ouverte à ce moment-là. La notification de mainlevée arrive en pièce jointe PDF. Vous la transférez à la comptabilité, qui ne retrouve pas le numéro de déclaration parce qu'il est dans la capture d'écran. L'expédition part avec trois jours de retard parce que personne ne savait qu'elle avait été dédouanée.
03 · UN TRANSITAIRE, QUINZE PORTAILS
Vous déployez « votre » portail et demandez à votre transitaire de s'y connecter pour mettre à jour les jalons. Il en a un pour chaque client. Il n'en consulte aucun de façon régulière. Vos données deviennent obsolètes dès qu'il ferme l'onglet du navigateur. Le portail devient un outil que le transitaire traite comme une corvée — jusqu'au moment où il ne le traite plus du tout.
7 SECTIONS · UN SEUL PORTAIL
Données réelles LOGISTICS_NAV.flatLinks issues de client/src/lib/navConfig.ts. La navigation mobile en bas d'écran utilise les quatre premiers éléments : Home · Inbox · Expéditions · Dispatch.
Bandeau d'accueil + carte du monde avec les Expéditions actives + file d'action en 2 colonnes (Needs Response, À risque, Today, Money). Un seul appel backend retourne l'ensemble des données.
La file de réponses structurées. 3 sous-onglets (réservations, RFQs, litiges), chacun avec les sections « Needs Action », « Awaiting Response » et « Recently Decided ». Les contre-offres sans réponse sont automatiquement promues après 48 h.
5 onglets — Tracking, Conteneurs, Coûts, Douanes, Historique. Un seul appel backend (/shipments/overview/all) retourne l'ensemble des données ; les onglets en sont des projections.
Automate à 11 états pour le transport terrestre. assigned → accepted_by_driver → en_route_to_pickup → arrived → loaded → departed → en_route_to_delivery → arrived → unloaded → completed (+ branche d'échec). Clôture conditionnée au POD.
Grilles tarifaires avec date de début / date de fin / version / remplacé par. Suppléments par ligne, paliers de volume, charge minimale. Import en masse de 1 à 500 lignes de manière atomique.
Automate à 10 états. 3 types : par expédition, consolidé mensuel, ad hoc. Branche litige avec suivi de résolution.
Messagerie par fils de discussion, limitée à chaque connexion opérateur. Rattachée à une entité (réservation, RFQ, expédition, facture). Notifications via le même socle que les autres portails.
LA BOÎTE DE RÉCEPTION · 1 252 LIGNES D'IU
Trois types de flux partagent une seule file d'attente, car du point de vue du transitaire ils se ressemblent tous : « réponse structurée, sous contrainte de temps, je suis le goulot d'étranglement » — demandes de réservation, appels d'offres et litiges de facturation. La surface Inbox les regroupe dans une file unique avec des formulaires d'action intégrés, de sorte que le parcours standard ne nécessite aucune navigation.
5 devis soumis · décision de l'opérateur en attente · plus ancien 18h
2 devis remportés · 1 devis perdu · développer pour afficher
EXPÉDITIONS · 5 ONGLETS · UN SEUL APPEL BACKEND
La surface de travail principale du transitaire. GET /portal/logistics/shipments/overview/all retourne tout en une seule requête ; la page conserve les données en mémoire et les projette par onglet. Aucun fan-out depuis le navigateur, aucun rechargement par onglet.
Carte mondiale + liste avec statut, route, dernier jalon et exceptions ouvertes. Cliquez sur une ligne → expansion contextuelle affichant la chronologie complète des jalons et les exceptions ouvertes pour cette expédition.
Chaque conteneur de chaque expédition, avec type, taux d'utilisation (CBM / poids vs maximum du conteneur), numéro de scellé et date de chargement. La vue « quoi est chargé où ».
Revenus par expédition issus des factures, montant payé, solde restant. Totaux agrégés en tête. Accédez au détail d'une facture depuis n'importe quelle ligne.
Déclarations douanières par expédition : juridiction (ISO 3166), type de déclaration (import/export/transit), statut (machine à 7 états), numéro de déclaration, codes HS déclarés. Totaux agrégés dédouané/en attente/bloqué en tête.
Fusion chronologique des événements, jalons et exceptions pour l'ensemble des expéditions de ce transitaire. Fil d'actualité ordonné dans le temps. La surface du journal d'audit.
MACHINES D'ÉTAT · APPLIQUÉES EN BDD
Chaque workflow dispose d'une state machine explicite — types enum Postgres ou contraintes CHECK. Les règles de transition au niveau de la couche service valident quels états peuvent évoluer vers quels autres. Aucune chaîne magique, aucun état côté interface.
RÉSERVATION · 6 ÉTATS
États terminaux : refusée · annulée · expirée. L'acceptation crée l'expédition associée.
APPEL D'OFFRES · 7 ÉTATS
Branches : perdue · refus de devis · expirée · retirée. Le backend impose un seul devis en attente par RFQ.
EXPÉDITION · 11 ÉTATS
Tout état actif peut passer à failed avec un motif. La clôture requiert la capture préalable du POD (verrouillée par une info-bulle dans l'interface).
FACTURE · 10 ÉTATS
Branches : en retard · contestée · passée en pertes. Trois types de facture : par expédition · consolidée mensuelle · ad hoc.
DÉCLARATION DOUANIÈRE · 7 ÉTATS
Branches : bloqué (documents / paiement / inspection en attente) · en question (la douane a posé une question) · rejeté (terminal). Par juridiction × type de déclaration.
EXCEPTIONS · 3+3 ENUM
Sévérité × statut. Le statut évolue selon ouvert → en atténuation → résolu. Distinct des jalons — déclarée, atténuation suivie, résolution auditée.
8 MODES LOGISTIQUES · MODÈLES DE JALONS PAR MODE
L'enum logistics_mode comporte huit valeurs, chacune associée à son propre modèle de jalons par mode (validé côté serveur, et non via un enum DB, ce qui permet d'ajouter de nouveaux jalons sans ALTER TYPE).
UN TRANSITAIRE · PLUSIEURS OPÉRATEURS
Un transitaire qui dessert Pendrew Energy, AcmeCorp, BioMed Global et sept autres clients dispose d'une seule ligne utilisateur, d'un seul login et de dix espaces opérateurs via la table external_memberships (migration 121). Basculez en un clic. Les réservations, barèmes de taux, jalons, factures et conversations de chaque opérateur sont isolés par connection_id — il n'existe aucun chemin API par lequel les données se propagent d'un opérateur à l'autre.
Vos identifiants API transporteur résident au niveau de external_organization (migration 289) — configurés une seule fois, chiffrés via le plugin KMS, et réutilisés dans chaque espace opérateur que vous gérez.
CONFIDENTIALITÉ · ARCHITECTURE
Architecture, pas de poignée de main. Vrai redactFor(entity, row, viewerRole) dans server/src/modules/portal-shell/redaction.ts — même schéma que pour les portails fournisseur et client.
PORTÉE PAR CONNEXION
Il n'existe aucun chemin dans l'API du portail logistique qui se propage entre opérateurs. Les accès inter-opérateurs retournent 404 (et non 403), de sorte que l'existence de la ressource reste masquée — vérifié dans la suite de tests du projecteur (portal-logistics/__tests__/projector.test.ts).
RÉDACTION AU NIVEAU DES CHAMPS
Prix d'achat, prix de vente, marge, base de coût — supprimés avant que la ligne ne quitte la base de données. Les fonctions redactShipmentForClient et redactFor('shipment', raw, 'logistics') appliquent cette règle. L'exception concerne le BOL : les données de consignataire requises par la loi figurent dans le document BOL, régies par la visibilité pilotée par les Incoterms (section suivante).
CONFIDENTIALITÉ DES TARIFS
Les grilles tarifaires sont limitées par logistics_connection_id. Le Marketplace tarifaire côté opérateur sert à comparer les prestataires (fonctionnalité Solo+), non l'inverse — les transitaires ne peuvent pas recenser « qui obtient de meilleurs tarifs que moi ». Les résultats RFQ (gagnés / perdus) sont communiqués au transitaire lui-même, mais jamais agrégés entre transitaires.
INCOTERMS · CONFIGURATION DE VISIBILITÉ
Le JSON visibility_config de la connexion (colonne migration 122 ; documentation du schéma dans 291) définit la visibilité par Incoterm pour l'origine et la destination — pays / port / ville / factory_name / factory_address / full_address. Il inclut également des substitutions par Incoterm et des substitutions d'étiquettes.
DDP · CIF · CFR
L'identité du fabricant est abstraite sur les documents d'expédition. Le transitaire voit l'adresse de l'opérateur comme origine ; les paramètres du tenant de l'opérateur pilotent le champ expéditeur du BOL. Le nom du fabricant n'est jamais affiché au transitaire sauf substitution explicite.
FOB · EXW · FCA
Le fabricant est l'expéditeur légal sur le BOL car l'obligation légale l'impose. Le nom du fabricant et l'adresse d'enlèvement sont visibles par le transitaire ; la visibility_config peut néanmoins restreindre ce que voit le client en aval de l'opérateur (la rédaction dans le portail client s'applique séparément).
CHAUFFEUR · PWA
Les chauffeurs installent le Portail logistique sur leur écran d'accueil — manifest.webmanifest + service worker — se connectent une seule fois et accèdent à la file de dispatching filtrée sur les missions pour lesquelles ils sont le chauffeur assigné. Aucun tarif, aucune facture, aucune autre expédition. Les jalons capturent les coordonnées GPS (latitude/longitude) et les photos téléversées ; le POD exige une signature, le nom et le titre du signataire avant que la transition vers completed soit autorisée.
Six valeurs de source de jalon sont enregistrées par événement : user (saisie manuelle ops), driver (capture mobile), carrier_api, ocr, scheduled_auto_advance, operator_override. La table des jalons est en ajout seul — UPDATE est refusé par déclencheur ; les corrections insèrent de nouvelles lignes avec supersedes_milestone_id pointant vers l'original.
Les transitions automatiques pilotées par géofence, le pipeline OCR pour le téléversement du BOL ainsi que les applications natives iOS et Android figurent dans la feuille de route — l'enum de source de jalon leur réserve déjà leurs emplacements.
CONTRÔLE PAR NIVEAU · 15 FONCTIONNALITÉS
Le registre tier_features réel (migration 291) définit quinze portes de fonctionnalités du portail logistique. Les prestataires logistiques ne voient jamais de barrière payante ; le tier de l'opérateur connecté détermine ce qui est disponible dans votre espace de travail pour cet opérateur.[Feuille de route] Les tags indiquent les fonctionnalités dont la clé tier_feature existe mais dont l'implémentation est post-lancement.
Roadmap = clé tier_features enregistrée dans la migration 291 (voir db/migrations/291_logistics_tier_features_and_visibility_overrides.sql) ; l'implémentation moteur / agrégation / UI sera livrée après le lancement conformément à la Logistics Spec §19, §14, §25.
SUR LA ROADMAP
La v1 embarque sept sections, six machines à états, un journal de jalons en ajout seul, une identité multi-tenant, la rédaction au niveau des champs, une visibilité pilotée par les Incoterms et un tier gating sur quinze clés de fonctionnalité. Plusieurs capacités que l'équipe marketing aimerait déjà revendiquer sont signalées honnêtement comme roadmap.
01
La migration 290 livre le schéma de la table consolidation_groups. Le moteur de suggestion qui alimente cette table est un traitement d'arrière-plan post-lancement ; l'interface v1 n'affiche encore rien. Clé de fonctionnalité de tier logistics.ai_consolidation_suggestions enregistrée pour Business+.
02
Clés de fonctionnalité de tier logistics.cross_tenant_insights et logistics.network_reputation_display enregistrées pour Business+. Le moteur d'agrégation et le seuil anti-inférence à ≥3 opérateurs seront disponibles après le lancement.
03
La consolidation inter-opérateurs nécessite des mécanismes de consentement non encore spécifiés. La migration 290 le reporte explicitement — « intentionally NOT modelled here ». Clé de fonctionnalité de tier réservée.
04
La valeur d'énumération source de milestone 'ocr' est enregistrée ; le service OCR qui ingère une image de BOL, extrait les champs conteneur / navire / sceau / voyage et publie le milestone correspondant est post-lancement.
05
Les transitions d'état de dispatch au franchissement de géofence (arrived_at_pickup, arrived_at_delivery) ne sont pas encore implémentées. La v1 capture le GPS au moment où le chauffeur valide le milestone ; l'avancement automatique par géofence viendra ultérieurement.
06
Registre d'intégrations v1 : project44 (live), Freightos Baltic / Xeneta / Drewry / MarineTraffic / Vizion (taux de fret + visibilité AIS). Les intégrations directes avec Maersk / MSC / CMA CGM / ONE / HMM / Hapag-Lloyd, IATA Cargo IQ pour l'aérien, et FedEx / UPS / DHL / USPS pour l'express terrestre seront câblées au fur et à mesure. logistics_carrier_api_credentials.carrier_name est un champ TEXT libre, l'ajout d'un transporteur ne nécessite donc pas de modification du schéma.
07
La PWA est l'interface chauffeur v1 (manifest + service worker actifs dans client/public/). Les applications natives avec authentification biométrique, API caméra natives et notifications push sont post-lancement.
08
La table logistics_carrier_api_credentials dispose d'une colonne last_polled_at. Le job planifié qui interroge chaque transporteur connecté selon sa cadence (quotidienne pour l'océanique, horaire sur les tronçons aériens critiques, toutes les 12h pour le ferroviaire) est post-lancement.
FAQ
Non. Nous ne concurrençons pas CargoWise, Magaya, Descartes ni Project44. Nous sommes la couche de coordination entre votre TMS et l'opérateur qui vous a mandaté. Conservez votre TMS pour les opérations internes ; utilisez le Portail logistique pour le workflow côté opérateur qui en est exclu — les réservations initiées par l'opérateur, la visibilité sur les jalons dont l'opérateur a besoin, les déclarations douanières sur les Expéditions de l'opérateur, les grilles tarifaires et RFQs que l'opérateur interroge, et les factures de fret que l'opérateur règle. L'intégration TMS pour les opérateurs avec CargoWise / Magaya / Descartes est disponible au niveau Enterprise.
Envoyez un CSV de vos principaux transitaires et une Expédition ouverte. Nous déploierons un Portail logistique en sandbox avec l'identité visuelle de votre tenant, votre liste de transitaires en tant qu'external_organizations, et guiderons un vrai transitaire à travers l'acceptation d'un RFQ, la publication de jalons, la déclaration douanière et l'émission d'une facture. Aucune donnée de démonstration. Vos transitaires, votre Expédition.
Réserver une démoParler aux ventes
Voir le Réseau complet — 4 portals, un seul enregistrement →