Portails chargeurs : réduire les ressaisies de commandes vers le TMS

Commencer par le flux, pas par le nom du portail

Deux portails peuvent exposer des fonctions différentes ; un même portail peut aussi servir à recevoir une commande, télécharger une pièce, confirmer un créneau ou déclarer un statut. Dire qu’un portail est « connecté » ne précise donc ni ce qui est lu, ni ce qui peut être écrit, ni comment le résultat est contrôlé.

Le cadrage utile se fait par objet et par action. Pour chaque flux, l’équipe identifie le système qui fait foi, l’événement déclencheur, les références disponibles, les droits accordés et l’état attendu dans le TMS. Cette carte permet de séparer ce qui peut être traité de ce qui doit rester en observation ou revenir à l’exploitation.

• commandes nouvelles et versions corrigées ;
• modifications, annulations et confirmations ;
• créneaux, contraintes et statuts opérationnels ;
• documents à télécharger ou à rattacher ;
• accusés, références et preuves de prise en compte.

La matrice à remplir pour chaque portail et chaque objet

La matrice suivante est un exemple fictif de cadrage. Chaque ligne représente un flux distinct à vérifier avec l’exploitant du portail et l’équipe responsable du TMS ; elle ne décrit pas des intégrations déjà déployées.

Une ligne n’est exploitable que si ses termes sont testables. « Accéder au portail » est trop vague ; « lire une nouvelle commande, retrouver sa référence dans le TMS et contrôler les cinq champs définis » donne un périmètre observable. La matrice doit également nommer le propriétaire du contrôle et la conduite à tenir lorsque l’identifiant manque.

Combiner API, fichiers et interface selon le besoin réel

Une API est utile lorsqu’elle expose l’objet, l’action et le retour nécessaires avec des droits adaptés. Un fichier convient à des lots structurés et à un traitement différé si les versions, rejets et accusés sont maîtrisés. Une interaction autorisée avec l’interface peut couvrir une fonction disponible seulement à l’écran, à condition que le parcours, la session et la vérification soient qualifiés. Aucune de ces modalités n’est automatiquement supérieure pour tous les flux.

Un même workflow peut les combiner : une notification signale une nouvelle commande, une API fournit les données, un fichier contient les pièces et une interface permet de vérifier un état non exposé ailleurs. L’architecture doit suivre la source de vérité et le niveau de risque, plutôt que forcer tous les événements dans un canal unique.

1. 01
   Lire

   Choisir l’accès qui fournit la donnée utile avec sa référence et sa version.

2. 02
   Décider

   Appliquer seulement les règles et autorisations validées pour cet objet.

3. 03
   Agir

   Créer ou mettre à jour le TMS par la voie prévue pour cette action.

4. 04
   Vérifier

   Relire l’état qui fait foi et conserver la preuve du résultat.

5. 05
   Transmettre

   Retourner les cas ambigus, interdits ou invérifiables avec leur contexte.

Éviter doublons et divergences de statuts

Le risque principal n’est pas seulement une erreur de champ. Une même commande peut être visible dans un export puis dans l’interface, renvoyée dans un second lot ou modifiée après sa première lecture. Sans clé de rattachement et historique de version, une reprise peut créer deux ordres TMS ou écraser une information plus récente.

Avant toute création, le workflow recherche l’identifiant externe et les clés secondaires autorisées dans le TMS. Avant une mise à jour, il compare la version source à la dernière version traitée et à l’état courant. Une ressemblance de trajet, de date ou de client peut aider à proposer un rapprochement, mais elle ne suffit pas à fusionner silencieusement deux transports.

Prévoir les sessions, les changements et la reprise avant le déploiement

Les accès aux portails évoluent : session expirée, authentification renforcée, droit retiré, libellé modifié, écran réorganisé ou format de fichier changé. Ces événements ne doivent pas être interprétés comme une commande absente ni contournés. Le scénario s’arrête dès qu’il ne reconnaît plus les conditions validées ou qu’il ne peut pas prouver le résultat.

La reprise commence par déterminer si une action a déjà été exécutée. Le workflow relit le portail et le TMS à partir des identifiants connus, puis classe le cas : aucune action constatée, action réussie, résultat partiel ou état indéterminé. Seul le premier cas autorise une nouvelle tentative automatique si la règle le prévoit. Les autres nécessitent une correction encadrée ou une décision humaine pour éviter une double création.

Dans un périmètre qualifié, Vigilo peut relier l’événement du portail au dossier transport, appliquer les règles autorisées, préparer ou exécuter l’action prévue puis en contrôler le résultat. Le déploiement reste spécifique aux sources, objets, identifiants, accès et responsabilités de l’entreprise : il ne constitue pas une promesse de compatibilité instantanée avec un portail ou un TMS donné.

• tester l’expiration et le renouvellement normal de session sans contourner les protections ;
• détecter un écran, un champ, un format ou un droit qui ne correspond plus à la version validée ;
• conserver le dernier point confirmé et les identifiants déjà obtenus ;
• relire les deux systèmes avant toute nouvelle tentative ;
• versionner la cartographie et suspendre le seul flux affecté ;
• transmettre à l’équipe la source, l’action tentée, l’état observé et la décision attendue.