- Pour qui ?
- Directions transport, responsables exploitation, DSI, ADV et finance
- Question traitée
- Comprendre le rôle du dossier Vigilo au sein d’un système d’information transport existant.
À retenir
- Le TMS, la messagerie, les portails et les référentiels conservent leur rôle.
- Vigilo maintient le lien entre les événements répartis dans ces systèmes.
- Chaque valeur utile garde sa source, sa version et son effet sur le dossier.
- L’action peut passer par une API ou une interface selon le workflow validé.
- Le modèle du dossier s’adapte aux identifiants et méthodes de l’entreprise sans revendiquer une compatibilité universelle.
Un transport traverse plusieurs systèmes
Une commande peut arriver par EDI, être précisée par e-mail, recevoir un créneau sur un portail, être créée dans un TMS puis complétée par une CMR et une facture. Chacun de ces outils conserve une partie utile de l’opération. Aucun ne possède nécessairement toute l’histoire qui explique la décision suivante.
Le dossier Vigilo fournit cette continuité. Il ne centralise pas tous les contenus par principe : il conserve les liens, les versions et les éléments nécessaires pour qualifier un événement, appliquer une règle autorisée, préparer ou exécuter une action puis vérifier son résultat.
Ce que le dossier relie
| Couche | Ce que Vigilo relie | Pourquoi |
|---|---|---|
| Événements | E-mails, statuts, documents, modifications et signaux retenus | Savoir ce qui vient de se produire et à quelle opération le rattacher |
| Sources | Émetteur, canal, date, document et version consultée | Expliquer l’origine d’une information ou d’un choix |
| Décisions | Règle appliquée, validation humaine, exception et motif | Comprendre pourquoi une action était permise ou interrompue |
| Actions | Valeurs préparées, outil ciblé et niveau d’autorisation | Distinguer une proposition d’une action réellement exécutée |
| Résultats | État observé après l’action, preuve et éventuel écart | Vérifier que l’outil contient bien le résultat attendu |
Ce qui reste dans vos outils
Le TMS reste le système métier choisi pour gérer les ordres, les ressources et les statuts qu’il porte. La messagerie conserve les échanges. Les portails continuent d’exposer leurs informations et fonctions. Les référentiels gardent les données dont ils sont responsables.
Vigilo ne cherche pas à recréer ces applications. Il consulte et utilise uniquement les éléments autorisés pour le workflow. Lorsqu’une donnée doit être modifiée, l’action est réalisée dans le système concerné ; le dossier en conserve la trace et le résultat vérifié.
Une chronologie plutôt qu’une fiche figée
- 01Demande reçue
Le signal est qualifié et rattaché à un dossier nouveau ou existant.
- 02Contexte reconstitué
Les valeurs utiles, leurs sources et les règles applicables sont réunies.
- 03Décision préparée
Vigilo expose l’action possible, les contrôles et les points qui exigent une validation.
- 04Action exécutée
Le logiciel métier est mis à jour par la voie autorisée pour ce workflow.
- 05Résultat vérifié
L’état observé est comparé au résultat attendu et l’écart éventuel est signalé.
- 06Histoire enrichie
Les modifications, preuves et décisions restent disponibles pour le contrôle ultérieur, notamment à la facturation.
Exemple : une commande modifiée moins de 24 heures avant le départ
La commande initiale est créée dans le TMS à partir d’un flux EDI. Le client avance ensuite le créneau par e-mail. Vigilo rattache le message au dossier, conserve l’ancien et le nouveau créneau, puis recherche la règle validée pour ce type de modification.
Si le périmètre autorise la mise à jour, Vigilo prépare ou exécute l’action dans le TMS et vérifie la valeur affichée. Si une validation est requise, l’exploitant reçoit le dossier déjà reconstitué avec les sources, la règle et l’action proposée. Lors du contrôle de facturation, la modification reste reliée au réalisé et aux éventuelles conditions tarifaires.
S’adapter au système d’information réel
Certaines entreprises disposent d’API complètes ; d’autres s’appuient sur des écrans, des portails ou des exports. Certaines organisent le dossier autour d’un identifiant TMS ; d’autres combinent une référence client, un voyage et une pièce. Vigilo configure les sources, les identifiants, les règles et les contrôles en fonction de ce fonctionnement réel.
Cette adaptabilité s’appuie sur un socle commun et versionné. Une intégration API est privilégiée lorsqu’elle expose de façon fiable la fonction attendue. L’interaction avec l’interface peut compléter le workflow lorsqu’elle est nécessaire et validée. Dans les deux cas, les droits, les changements d’écran, les erreurs et la vérification après action font partie du périmètre à tester.
- identifier les systèmes qui font foi pour chaque information ;
- définir les clés de rattachement entre les événements et le dossier ;
- configurer les règles, rôles et niveaux d’autorisation ;
- tester les actions dans les versions d’outils réellement utilisées ;
- versionner les mappings et suspendre un scénario en cas de changement non validé.
Ce que le dossier ne doit pas masquer
Une information peut être introuvable, deux sources peuvent se contredire ou un événement peut correspondre à plusieurs transports. Le dossier ne doit pas donner une impression de certitude artificielle. Il indique les sources retenues, les ambiguïtés et la raison pour laquelle le traitement s’arrête.
L’équipe récupère alors un cas exploitable : ce qui est connu, ce qui manque, les candidats de rattachement et la décision attendue. La continuité reste ainsi utile même lorsqu’aucune action automatique n’est permise.
Du dossier individuel à la mémoire opérationnelle
Quand les dossiers conservent leurs événements, décisions et résultats, l’entreprise peut observer ses propres modes de fonctionnement : sources de reprise, modifications fréquentes, délais de validation ou écarts récurrents. Ces constats restent explicables parce qu’ils renvoient aux dossiers qui les composent.
Les décisions répétées peuvent alors faire émerger des règles candidates. Elles ne sont activées qu’après validation de leur sens et de leur périmètre. Le dossier devient ainsi le point de départ d’une mémoire opérationnelle gouvernée, plutôt qu’une simple accumulation de données.
Questions fréquentes
Réponses directes
Le dossier Vigilo remplace-t-il le TMS ?
Non. Le TMS conserve son rôle de système métier. Vigilo relie le contexte réparti entre les outils et intervient uniquement dans le périmètre autorisé.
Toutes les données sont-elles copiées dans Vigilo ?
Non. Les données et liens conservés dépendent du besoin opérationnel, des droits et des règles de conservation définies avec l’entreprise.
Vigilo fonctionne-t-il seulement avec une API ?
Non. Le workflow peut utiliser une API lorsqu’elle est disponible et adaptée, ou une interaction avec l’interface lorsque celle-ci est nécessaire et suffisamment stable. Chaque modalité doit être validée pour le système concerné.
Peut-on relier un outil spécifique ou ancien ?
Le socle est conçu pour des environnements variés, mais la faisabilité dépend des accès, de l’interface, des volumes et des contrôles possibles. Une étude du workflow est nécessaire avant d’affirmer la compatibilité.
Que se passe-t-il si le TMS ou le portail change ?
La configuration concernée est contrôlée, mise à jour et versionnée. Le scénario peut être suspendu si le changement empêche de garantir le résultat attendu.
Sources et méthode
Cette ressource décrit la méthode produit Axonovia à partir de workflows transport. Les exemples sont illustratifs et ne constituent ni une promesse de performance ni une règle contractuelle universelle.
Relecture produit : Équipe Axonovia · prochaine revue recommandée avant le 31 août 2027 ou lors d’une évolution matérielle du périmètre.