Skip to content

Sous-traitance avec TMS

Le transporteur désigné sur le document (CARRIER) n'effectue pas lui-même le transport : il sous-traite à une autre société de transport, qui dispose elle-même de son propre TMS et de ses propres identifiants API. Ce scénario s'appuie sur la délégation de rôle : le rôle CARRIER reste porté par l'entreprise donneuse d'ordre, mais son accès est délégué à une autre organisation, qui peut elle-même redéléguer en interne (sous-comptes) — voire re-déléguer à son tour à un second niveau de sous-traitance.

Points clés à retenir :

  • La délégation se fait au niveau du rôle (CARRIER), pas au niveau du document entier — le sous-traitant ne voit que ce à quoi son rôle délégué lui donne accès.
  • Le sous-traitant s'authentifie avec ses propres identifiants API — jamais avec ceux du donneur d'ordre.
  • Le sous-traitant peut lui-même déléguer à un sous-compte (par exemple un chauffeur salarié), en scopant la délégation à ce document précis.
  • Le donneur d'ordre continue de recevoir les webhooks de changement de statut, quel que soit le nombre de niveaux de délégation en dessous de lui.
  • Par défaut, le donneur d'ordre ne voit jamais l'identité du sous-traitant — ni dans GET /freightdocuments/{id}, ni dans le payload webhook : le rôle CARRIER reste affiché avec l'identité de l'entreprise donneuse d'ordre elle-même, jamais celle du délégataire. C'est une décision de confidentialité commerciale qui appartient au sous-traitant (le titulaire d'origine du rôle), pas au donneur d'ordre. Le sous-traitant peut choisir d'exposer volontairement son ou ses délégataires actifs via PATCH /freightdocuments/{id}/roles/{role_id}/visibility — voir la référence API.
  • Le chauffeur doit signer sa propre acceptation de collecte (COLLECTION_ACCEPTANCE) avant de pouvoir signer la livraison — bloquée sinon (signature.collection_acceptance_required). L'application chauffeur enchaîne les deux automatiquement, sans action supplémentaire de votre part. Voir Signature électronique.
sequenceDiagram
    participant TMS as TMS donneur d'ordre
    participant API as API e-CMR
    participant SubTMS as TMS sous-traitant
    participant Driver as Chauffeur (app)

    TMS->>API: POST /freightdocuments + issue
    API-->>TMS: 200 OK, status=ISSUED

    Note over TMS,SubTMS: Délégation au niveau document
    TMS->>API: POST delegate (role Carrier vers email sous-traitant)
    API-->>TMS: 200 OK, délégation créée
    API-)SubTMS: Email: accès délégué reçu

    Note over SubTMS,API: Le sous-traitant utilise ses propres identifiants API
    SubTMS->>API: GET /freightdocuments?filters=ownRoles.eq:CARRIER
    API-->>SubTMS: Liste des documents délégués

    Note over SubTMS,Driver: Le sous-traitant délègue à son propre chauffeur
    SubTMS->>API: POST delegate (sous-compte chauffeur, scope=ce document)
    API-->>SubTMS: 200 OK, délégation créée
    SubTMS-)Driver: Mission assignée (dans son propre système)

    Driver->>API: GET /freightdocuments/id (identifiants sous-compte)
    API-->>Driver: Document + ownPermissions

    Driver->>API: POST events (arrivée, chargement)
    Driver->>API: POST signature collecte
    API-->>Driver: 200 OK, status=TRANSIT
    API-)TMS: Webhook STATUS=TRANSIT
    Driver->>API: POST signature collecte-chauffeur (COLLECTION_ACCEPTANCE)
    API-->>Driver: 200 OK, signature enregistrée (statut inchangé)

    Driver->>API: POST events (arrivée, déchargement)
    Driver->>API: POST signature livraison
    API-->>Driver: 200 OK, status=DELIVERED
    API-)TMS: Webhook STATUS=DELIVERED

    SubTMS->>API: GET /freightdocuments/id (suivi de son propre transport)
    API-->>SubTMS: status=DELIVERED