Comment Vigilo apprend un workflow : de la décision répétée à la règle validée

Un workflow réel ne tient jamais entièrement dans une procédure

Les consignes écrites, contrats, matrices tarifaires et modes opératoires fournissent un cadre précieux. Ils décrivent les sources autorisées, les contrôles attendus et les décisions qui ne doivent pas être automatisées. Pourtant, une partie du travail reste portée par l’expérience de l’équipe : appeler un interlocuteur avant une modification sensible, demander une validation après une heure de coupure ou choisir un créneau en fonction d’une contrainte locale.

Vigilo est conçu pour représenter cette réalité sans réduire l’entreprise à un scénario standard. Il observe les événements et les décisions dans le périmètre convenu, relie chaque choix aux éléments du dossier et rend les pratiques récurrentes explicites. L’objectif n’est pas d’imiter toutes les habitudes, mais de distinguer ce qui relève d’une règle stable, d’une exception ou d’un arbitrage qui doit rester humain.

Ce que Vigilo conserve lorsqu’une décision est prise

Une correction isolée n’explique pas à elle seule pourquoi elle était juste. Pour être exploitable, la décision doit rester reliée à la situation qui l’a provoquée et au résultat qui a été vérifié.

• l’événement initial, son canal, son horodatage et sa source ;
• les versions du dossier et des documents consultés ;
• les contraintes connues au moment de la décision ;
• le choix effectué, son motif et la personne ou le mécanisme qui l’a validé ;
• l’action préparée ou exécutée dans l’outil métier ;
• le résultat réellement observé et les corrections éventuelles.

De la décision répétée à la règle candidate

1. 01
   Observer

   La décision humaine est conservée avec le dossier, les sources et le résultat contrôlé.

2. 02
   Comparer

   Vigilo recherche des situations comparables plutôt qu’une simple ressemblance de mots ou de gestes.

3. 03
   Détecter une récurrence

   Un même arbitrage apparaît dans un contexte suffisamment stable pour mériter un examen.

4. 04
   Formuler une règle candidate

   La proposition décrit les conditions, les exemples qui la justifient, les cas exclus et le niveau d’action envisagé.

5. 05
   Faire valider

   L’équipe confirme le sens métier, corrige le périmètre et choisit si la règle doit rester informative, supervisée ou active.

6. 06
   Versionner et suivre

   Toute évolution reste attribuable à une version, avec un propriétaire, une date et un mécanisme de suspension.

Exemple : une demande arrivée après l’heure de coupure

Plusieurs commandes arrivées après l’heure de coupure sont soumises à validation avant leur création. Le geste semble identique, mais ses raisons peuvent différer : capacité restante, type de marchandise, client concerné ou engagement déjà confirmé. Vigilo conserve ces facteurs avec chaque décision au lieu de conclure immédiatement à une règle générale.

Si le même arbitrage se répète sur des dossiers réellement comparables, Vigilo peut proposer une règle candidate : pour ce type de flux et ce périmètre client, demander une validation au-delà de l’heure définie. L’équipe vérifie les exclusions, désigne le responsable et décide du niveau d’autorisation. Une commande hors périmètre continue d’être transmise à l’exploitant.

L’adaptation devient un actif produit, pas un projet ponctuel

Deux entreprises peuvent utiliser le même TMS tout en ayant des méthodes de travail différentes. Inversement, deux outils distincts peuvent porter un workflow proche. L’adaptabilité de Vigilo repose donc sur des briques stables — événements, dossier, règles, actions, contrôles et escalades — configurées pour le fonctionnement réel de l’entreprise.

Les sources, identifiants, écrans, droits d’action et règles restent spécifiques au périmètre déployé. Leur configuration est testée et versionnée. Cette approche permet de réutiliser le socle produit lorsqu’un nouveau flux ou un nouvel outil est ajouté, sans faire croire qu’une compatibilité existe avant l’étude des accès, des écrans, des volumes et des contrôles nécessaires.

Ce que l’équipe valide avant toute activation

Cette validation ne sert pas uniquement à limiter le risque. Elle transforme un savoir tacite en connaissance transmissible : une nouvelle personne peut comprendre la règle, retrouver les cas qui l’ont fait émerger et savoir quand elle ne doit pas l’appliquer.

• la finalité métier de la règle et les dossiers qui l’expliquent ;
• les clients, flux, entités, outils et périodes auxquels elle s’applique ;
• les cas explicitement exclus et les situations jugées sensibles ;
• les sources qui font foi en cas de contradiction ;
• les actions autorisées et les contrôles exigés après leur exécution ;
• le propriétaire habilité à modifier, suspendre ou retirer la règle.

Quand Vigilo doit s’arrêter

L’adaptabilité ne signifie pas que Vigilo doit traiter tous les cas. Une source contradictoire, une interface modifiée, une donnée obligatoire absente ou une situation hors du périmètre validé doivent provoquer un arrêt explicite. Le dossier transmis à l’équipe contient alors l’événement, le contexte reconstitué, la règle envisagée et la raison de l’arrêt.

Ce comportement fait partie du workflow. Il permet de faire évoluer l’autonomie sur des faits observables, sans masquer les zones où l’organisation, l’outil ou la règle ont changé.

Une progression mesurable

1. 01
   Observer sans agir

   Comparer la reconstitution de Vigilo aux décisions prises par les équipes.

2. 02
   Proposer

   Présenter des actions et des règles candidates sans modifier les logiciels.

3. 03
   Autoriser un périmètre précis

   Activer seulement les cas, outils et actions dont les contrôles ont été validés.

4. 04
   Étendre ou réduire

   Faire évoluer la couverture selon les résultats, les changements d’outil et les nouveaux cas rencontrés.