- Pour qui ?
- Directions transport, responsables exploitation, ADV et équipes SI
- Question traitée
- Comprendre comment Vigilo qualifie l’intention d’un événement avant d’agir sur un dossier transport.
À retenir
- Le même message peut signifier créer, modifier, annuler ou simplement compléter un dossier.
- L’intention est une qualification fondée sur des indices et un contexte traçable, pas une lecture de pensée.
- Vigilo adapte cette qualification aux canaux, au TMS et aux pratiques validées de chaque organisation.
- Une intention incertaine ou une action sensible reste soumise à la règle d’escalade prévue.
- Une modification fiable conserve la valeur précédente, la valeur demandée, sa source et l’état finalement relu dans le TMS.
- Une annulation doit préciser ce qu’elle retire : le transport entier, une modification récente ou seulement une action encore en attente.
- Quand le dossier, l’émetteur ou l’effet attendu reste incertain, demander une validation est une décision opérationnelle à part entière.
Un message ne contient pas toujours son mode d’emploi
« Même transport que lundi, mais livraison vendredi » peut être une nouvelle commande fondée sur un modèle précédent ou la modification d’un dossier déjà ouvert. « Finalement, ne tenez pas compte de mon dernier message » peut annuler une correction sans annuler le transport. Les verbes employés ne suffisent donc pas à déterminer l’action attendue.
Avant toute écriture dans un outil, Vigilo cherche à répondre à une question opérationnelle : qu’est-ce que cet événement change dans le dossier ? Cette étape protège le workflow contre une confusion coûteuse entre création, mise à jour, annulation et simple ajout de pièce.
Les éléments que Vigilo rapproche
Ces éléments n’ont pas le même poids dans toutes les entreprises. Une référence EDI peut être déterminante dans un flux et secondaire dans un autre. Un client peut imposer que toute annulation soit confirmée sur son portail. Le workflow est donc configuré et éprouvé sur les systèmes et méthodes réellement utilisés, plutôt que construit autour d’un schéma TMS supposé universel.
- 01Le signal entrant
Canal, émetteur, date, objet, contenu, pièces jointes et identifiants visibles.
- 02Le dossier candidat
Référence client, ordre TMS, trajet, dates, interlocuteurs et état opérationnel.
- 03La chronologie
Demandes précédentes, versions remplacées, validations et actions déjà réalisées.
- 04Les règles autorisées
Priorité des sources, délais de modification, droits d’annulation et cas nécessitant une validation.
- 05Le résultat attendu
Créer, modifier, annuler, compléter, demander une précision ou transmettre à l’équipe.
Trois intentions proches, trois décisions différentes
| Situation | Entrée observée | Décision | Résultat | Limite |
|---|---|---|---|---|
| Nouvelle commande | Un e-mail transmet un trajet, une date et une référence qui ne correspond à aucun dossier ouvert. | Qualifier la demande comme une création et compléter uniquement les données autorisées. | Un dossier est préparé pour le TMS avec ses sources et les champs restant à confirmer. | Une référence réutilisée ou deux dossiers proches imposent une validation. |
| Modification | Le client avance le créneau et cite une commande existante déjà créée. | Rattacher le message au dossier, comparer l’ancienne et la nouvelle valeur, puis appliquer la règle de modification. | Le créneau est mis à jour ou proposé à l’exploitant ; la valeur précédente reste dans l’historique. | Un changement tardif, contradictoire ou hors périmètre est transmis à l’équipe. |
| Annulation | Un message demande de « laisser tomber le transport » et reprend une référence connue. | Vérifier le dossier visé, l’autorité de l’émetteur et les conditions d’annulation. | L’annulation est préparée ou exécutée selon le niveau d’autorisation, avec conservation de la demande. | Un langage ambigu ou une conséquence sensible interdit une annulation silencieuse. |
Exemple : une modification reçue moins de 24 heures avant le chargement
Un chargeur écrit : « Pour la commande 2847, livraison décalée à 14 h demain ». La référence correspond à un dossier actif, mais le nouveau créneau intervient moins de 24 heures avant le chargement. Vigilo reconnaît qu’il ne s’agit ni d’une nouvelle commande ni d’une information sans effet : le message demande une modification du dossier existant.
Le workflow consulte alors la règle applicable à ce client et à ce type de transport. Si toute modification à moins de 24 heures requiert l’accord de l’exploitation, Vigilo prépare la différence entre l’ancien et le nouveau créneau, rassemble le message source et l’état du TMS, puis sollicite la validation prévue. L’adaptabilité se trouve ici dans le cadrage : le seuil, les personnes sollicitées et le mode d’action suivent le fonctionnement de l’entreprise concernée.
Comprendre comme un opérateur, sans reproduire ses implicites à l’aveugle
Un opérateur expérimenté ne lit pas seulement le dernier e-mail. Il reconnaît l’interlocuteur, se rappelle les échanges précédents, consulte le dossier et sait quelles habitudes sont pertinentes. Vigilo poursuit la même continuité de raisonnement en rendant les éléments utilisés visibles et vérifiables.
Les procédures déjà écrites accélèrent le cadrage. Lorsque des décisions humaines similaires se répètent dans des contextes comparables, Vigilo peut aussi faire apparaître une règle candidate. Cette proposition conserve les cas qui l’expliquent ; elle n’est activée qu’après validation de son sens, de son périmètre et de ses exceptions.
Une adaptation qui porte sur le workflow complet
Cette capacité d’adaptation ne signifie pas que tous les TMS et tous les cas sont couverts sans préparation. Elle signifie que Vigilo s’appuie sur des briques réutilisables — observation, contexte, règles, action et vérification — puis les configure sur un périmètre réel. La couverture s’étend à mesure que les cas sont observés, testés et validés.
- les canaux par lesquels les événements sont reçus ;
- les identifiants disponibles pour rattacher un dossier ;
- le vocabulaire et les formats employés par les partenaires ;
- les champs, écrans et états du TMS en place ;
- les règles d’autorisation, de contrôle et d’escalade ;
- les preuves que l’équipe souhaite conserver.
Ce qu’une équipe doit pouvoir auditer
Un pilote utile mesure séparément la qualité du rattachement, celle de la qualification et celle de l’action. Une bonne lecture du message ne compense pas un rattachement incertain ; une intention correctement reconnue ne garantit pas non plus que l’outil cible ait accepté l’action. Chaque étape doit rester observable.
- l’événement qui a déclenché la qualification ;
- le dossier et les sources utilisés pour la décision ;
- l’intention retenue et les alternatives écartées ;
- la règle ou la validation qui autorise l’action ;
- le résultat obtenu et la raison d’une éventuelle escalade.
Avant/après : rendre une modification contrôlable
Une modification ne devrait jamais écraser une valeur sans laisser apparaître ce qui a changé. Le dossier doit relier l’état relu avant l’action, la demande reçue, la règle ou la validation appliquée, puis l’état relu après l’action. Cette comparaison protège contre trois erreurs différentes : modifier le mauvais transport, reporter une valeur incomplète ou croire qu’une écriture a réussi alors que le TMS a conservé l’ancien état.
Exemple fictif : le dossier TMS TR-2847 affiche une livraison le 11 septembre entre 8 h et 10 h, pour 18 palettes. À 09:42, un interlocuteur autorisé demande de livrer le 12 septembre entre 14 h et 16 h, sans changer la quantité. L’action préparée porte uniquement sur la date et le créneau. Après exécution, la relecture attendue est donc : livraison le 12 septembre, de 14 h à 16 h, 18 palettes, même référence de dossier. Toute autre différence ou l’absence de mise à jour suspend la clôture du cas.
| Élément | Avant | Demande reçue | Après attendu | Contrôle |
|---|---|---|---|---|
| Date de livraison | 11 septembre | Reporter au 12 septembre | 12 septembre | Relire la date enregistrée dans le dossier ciblé. |
| Créneau | 8 h–10 h | Passer à 14 h–16 h | 14 h–16 h | Comparer les deux bornes du créneau. |
| Quantité | 18 palettes | Aucun changement demandé | 18 palettes | Vérifier qu’un champ non visé n’a pas été altéré. |
| Version et preuve | Version courante du TMS | E-mail reçu à 09:42 | Nouvelle version reliée à l’e-mail | Conserver source, horodatage et résultat relu. |
Chronologie : distinguer l’annulation du transport de l’annulation d’une modification
Le dernier message ne peut être interprété correctement qu’avec les événements qui le précèdent. « Annulez mon changement » et « annulez le transport » ne portent pas sur le même objet. Dans le premier cas, le dossier peut devoir revenir à sa version antérieure ; dans le second, le transport lui-même change d’état. Si la formulation ne permet pas de trancher, aucune de ces deux actions ne doit être déduite silencieusement.
- 0108:10 · Création
Une commande est reçue, rattachée à une référence client et créée pour une livraison le 11 septembre.
- 0209:42 · Modification demandée
Le client demande un report au 12 septembre. L’événement reste lié à la commande initiale et porte une nouvelle version attendue.
- 0309:51 · Message ambigu
Le client écrit : « Annulez, nous gardons finalement la première date. » Le mot « annulez » vise vraisemblablement la demande de report, mais pas nécessairement le transport.
- 04Décision · Validation ciblée
Le workflow présente la version initiale, la modification et le message reçu, puis demande de confirmer : revenir au 11 septembre ou annuler le transport entier ?
- 05Après décision · Action et relecture
Seule l’action confirmée est exécutée. Le statut, la date et la version du dossier sont ensuite relus avant clôture.
Matrice de décision : créer, modifier, annuler ou demander validation
La qualification de l’intention doit aboutir à une décision explicite. La matrice ci-dessous constitue une méthode générale : les références déterminantes, les droits et les contrôles sont à configurer et à éprouver pour chaque workflow. Un mot-clé ne suffit jamais à lui seul pour choisir une ligne.
| Décision | Conditions minimales observables | Action préparée | Contrôle avant clôture | Quand ne pas agir |
|---|---|---|---|---|
| Créer | Aucun dossier correspondant n’est retrouvé ; la demande contient les éléments requis ou une règle autorise leur complément. | Préparer un nouveau dossier sans reprendre une ancienne référence comme preuve de rattachement. | Retrouver la nouvelle référence TMS et relire les champs structurants. | Un dossier proche existe, une référence est réutilisée ou des données critiques manquent. |
| Modifier | Un dossier unique est identifié ; les valeurs à remplacer sont explicites ; l’émetteur et la règle autorisent le changement. | Appliquer uniquement les différences approuvées et conserver les valeurs remplacées. | Relire les champs modifiés, les champs critiques non visés et la version du dossier. | Deux dossiers sont plausibles, les sources se contredisent ou le changement sort du périmètre autorisé. |
| Annuler | Le dossier visé, l’objet de l’annulation, l’autorité de l’émetteur et la procédure applicable sont établis. | Préparer ou exécuter le changement d’état prévu, sans supprimer l’historique ni les preuves. | Relire le statut et vérifier qu’aucun autre transport ou événement n’a été annulé. | Le message peut viser une modification, une option ou une action en attente plutôt que le transport entier. |
| Demander validation | Une condition nécessaire reste incertaine ou l’action exige explicitement un accord humain. | Présenter les dossiers candidats, le avant/après, les sources contradictoires et une question fermée. | Enregistrer la décision, son auteur, sa portée et l’état relu après l’éventuelle action. | Ne pas transformer l’absence de réponse en autorisation implicite. |
Questions fréquentes
Réponses directes
Vigilo reconnaît-il toutes les formulations possibles ?
Non. La qualité dépend des sources disponibles, du contexte et du périmètre éprouvé. Une formulation ou une situation incertaine est transmise selon les règles prévues.
Faut-il rédiger toutes les règles avant de commencer ?
Non. Les règles existantes accélèrent le déploiement. Une phase d’observation peut aussi révéler des décisions récurrentes, qui deviennent des règles candidates avant toute activation.
Comment Vigilo s’adapte-t-il à un TMS spécifique ?
Le workflow est configuré sur les champs, écrans, états, accès et contrôles du TMS concerné. Une API peut être utilisée lorsqu’elle est adaptée ; une interaction d’interface peut compléter le périmètre lorsqu’elle est validée.
Une annulation peut-elle être automatisée ?
Seulement si le périmètre, l’autorité, les contrôles et le niveau d’autorisation ont été explicitement validés. Elle peut rester une action préparée ou entièrement humaine.
Comment éviter qu’une modification crée un doublon dans le TMS ?
Il faut d’abord rattacher l’événement à un dossier unique, comparer son état courant à la demande et relire ce même dossier après l’action. Si le rattachement reste ambigu, le workflow demande une validation au lieu de créer ou modifier.
Que faire lorsqu’un client écrit seulement « annulez la modification » ?
Reconstituer la chronologie pour identifier la version concernée et l’état auquel revenir. Si plusieurs changements se succèdent ou si le message peut viser le transport entier, demander une confirmation explicite avant toute action.
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.