Après le clic : comment Vigilo vérifie qu’une action a réellement réussi

Le clic n’est pas une preuve

Un bouton « Enregistrer » peut avoir été cliqué alors qu’un champ obligatoire bloque la sauvegarde hors de la zone visible. Une API peut répondre positivement avant qu’un traitement asynchrone échoue. Une fenêtre peut se fermer sans que la modification apparaisse dans le dossier. Mesurer seulement l’action envoyée crée donc une fausse impression de fiabilité.

Vigilo sépare l’exécution de la vérification. Avant d’agir, le workflow décrit l’état attendu. Après l’action, il observe à nouveau le système cible et recherche les preuves définies pour ce cas. La boucle n’est close que lorsque le résultat observé correspond aux conditions acceptées.

Définir le résultat avant d’agir

La vérification ne peut pas être ajoutée comme une case générique après le déploiement. Pour chaque action autorisée, l’équipe définit ce qui prouve la réussite, ce qui signale un échec et ce qui demeure indéterminé.

1. 01
   État attendu

   Par exemple : dossier créé avec une référence TMS, créneau modifié ou statut d’annulation confirmé.

2. 02
   Preuve primaire

   L’état relu dans le système qui fait foi pour le workflow.

3. 03
   Contrôles de cohérence

   Valeurs clés, version, montant, statut, horodatage ou présence d’un document.

4. 04
   Délai acceptable

   Temps pendant lequel un traitement peut légitimement rester en attente.

5. 05
   Conduite en cas d’écart

   Nouvelle observation, reprise encadrée ou transmission à l’équipe avec les preuves.

Exemple : créer un ordre dans le TMS

Une demande validée doit créer un ordre pour un enlèvement à Lyon, une livraison à Lille et un créneau de 8 h à 10 h. Vigilo renseigne les champs autorisés puis déclenche l’enregistrement. L’apparition d’une notification verte peut constituer un indice, mais elle ne suffit pas nécessairement.

Le workflow recherche la référence attribuée par le TMS, rouvre ou relit le dossier et compare les champs structurants au dossier préparé. Si le créneau affiché est 10 h–12 h ou si aucun ordre n’est retrouvable, le résultat ne correspond pas à l’intention. Vigilo conserve alors l’état observé et transmet le cas selon la procédure définie.

Quatre niveaux de preuve possibles

Le bon niveau dépend du risque et des possibilités du système. Un changement de commentaire peut demander une preuve plus légère qu’une annulation ou qu’une validation de facture. Plusieurs niveaux peuvent être combinés lorsque l’action a des conséquences aval.

Exemple : une modification à moins de 24 heures et son supplément

Une modification reçue moins de 24 heures avant l’opération entraîne, dans le périmètre validé, une attente à quai et un supplément à contrôler. Vigilo rattache la demande au dossier, met à jour le TMS si l’action est autorisée et vérifie que le nouveau créneau apparaît bien. Il conserve également l’événement qui justifie le contrôle financier ultérieur.

Au moment du rapprochement de facture, la présence de la modification ne suffit pas : le workflow compare la chronologie réelle, la règle applicable et les lignes facturées. Si le supplément attendu manque ou si l’attente à quai n’est pas étayée par les éléments définis, le dossier est signalé avec la différence observée. Vigilo ne conclut pas seul sur un montant lorsque les preuves ou règles nécessaires manquent.

Que faire lorsque le résultat est incertain ?

Le statut « indéterminé » est parfois plus sûr qu’un succès ou un échec supposé. Il permet à l’équipe d’arbitrer sans perdre le contexte et évite qu’une réaction automatique transforme un incident mineur en doublon, en annulation erronée ou en information contradictoire.

• attendre le délai prévu lorsqu’un traitement est asynchrone ;
• relire l’état par une autre vue ou une autre source autorisée ;
• éviter de répéter aveuglément une création qui pourrait produire un doublon ;
• conserver capture, valeur, horodatage et version utiles au diagnostic ;
• présenter à l’opérateur l’intention, l’action tentée et l’écart observé ;
• reprendre uniquement selon une stratégie validée pour ce cas.

API ou interface : la même exigence de résultat

Lorsqu’une API expose l’action et les états nécessaires, elle constitue souvent le chemin le plus direct. Lorsqu’elle ne couvre pas le besoin, une interaction contrôlée avec l’interface peut agir comme le ferait un opérateur. Dans les deux cas, le transport métier ne se résume pas à la réussite technique de l’appel ou du clic.

L’adaptation de Vigilo porte donc aussi sur la preuve : identifier l’état qui fait foi dans le TMS concerné, la manière de le relire et les écarts qui doivent interrompre le workflow. Un changement d’interface ou de comportement du logiciel doit provoquer une détection et une réévaluation, pas une exécution silencieuse coûte que coûte.

La trace utile pour l’exploitation et le contrôle

Cette trace permet de résoudre les exceptions, d’expliquer une décision et d’améliorer les règles. Elle relie aussi l’amont à la facturation : une modification, une attente ou une annulation reste disponible lorsque l’équipe contrôle ce qui a réellement été réalisé et facturé.

• l’événement et le dossier à l’origine de l’action ;
• la règle, la validation et la version utilisées ;
• les données préparées et l’action effectivement envoyée ;
• l’état attendu, l’état observé et le moment du contrôle ;
• l’écart, la reprise ou la décision humaine qui a clos le cas.