Quand le workflow change : écran, document, règle ou responsabilité

L’exploitation change en permanence

Un éditeur déplace un champ dans le TMS. Un client adopte un nouveau modèle de commande. Une règle de coupure change. L’équipe finance reprend une validation auparavant confiée à l’exploitation. Ces évolutions touchent toutes le workflow, mais pas la même couche.

Vigilo est conçu pour représenter séparément les sources, les règles, les interactions, les contrôles et les responsabilités. Cette séparation permet d’adapter la partie concernée sans reconstruire toute la chaîne ni imposer à l’entreprise une méthode de travail prédéfinie.

Quatre changements, quatre diagnostics

Détecter une dérive sans improviser

La détection vient d’écarts concrets : un élément attendu n’est plus visible, un résultat ne correspond pas à l’action préparée, un document échoue aux contrôles habituels ou les opérateurs corrigent souvent la même décision. Ces signaux indiquent qu’une analyse est nécessaire ; ils n’autorisent pas Vigilo à inventer un nouveau fonctionnement.

Le comportement sûr est défini à l’avance : retenter une lecture, demander une validation, transmettre le dossier ou suspendre l’action concernée. Le reste du workflow peut continuer uniquement si ses dépendances et ses contrôles restent satisfaits.

La boucle d’évolution d’un workflow

1. 01
   Observer

   Rassembler les échecs, corrections et nouveaux cas avec leurs sources et leur contexte.

2. 02
   Qualifier

   Identifier la couche touchée, l’impact métier et les actions qui doivent rester suspendues.

3. 03
   Proposer

   Préparer une nouvelle version de l’écran, du mapping, de la règle ou de la responsabilité.

4. 04
   Tester

   Rejouer des cas normaux, limites, ambigus et historiquement problématiques.

5. 05
   Valider

   Faire approuver la version et son périmètre par les responsables métier et technique.

6. 06
   Déployer progressivement

   Observer les résultats sur un périmètre limité avant extension.

7. 07
   Revenir en arrière si nécessaire

   Conserver la version précédente et la possibilité de suspendre immédiatement la nouvelle.

Ce que le versionnement doit rendre visible

Sans cette visibilité, la maintenance devient une succession de corrections opaques. Avec elle, l’entreprise peut faire évoluer le workflow tout en expliquant le comportement observé sur un dossier donné.

• la modification apportée et sa justification ;
• les systèmes, clients, flux et actions concernés ;
• les cas de test et leurs résultats ;
• les règles, mappings et droits utilisés par chaque action ;
• la date d’activation, le propriétaire et le statut ;
• les exceptions nouvelles, corrigées ou toujours non couvertes.

Faire de l’hétérogénéité un atout

La capacité d’adaptation ne consiste pas à forcer tous les clients dans un écran, un TMS ou une procédure de référence. Elle consiste à réutiliser la même boucle opérationnelle — observer, contextualiser, agir, vérifier et escalader — avec les sources, règles et interfaces propres à chaque organisation.

Cette architecture transforme l’hétérogénéité en paramétrage gouverné plutôt qu’en accumulation de développements isolés. Elle vise une mise à l’échelle maîtrisée : les briques sont réutilisables, tandis que les particularités métier restent explicites, testables et modifiables.

Questions à poser avant la mise en production

• Quels changements le workflow sait-il détecter directement ? ;
• Quelle action est suspendue lorsqu’un contrôle échoue ? ;
• Qui valide une évolution métier et qui valide une évolution technique ? ;
• Quels cas servent de tests de non-régression ? ;
• Peut-on relier chaque décision à la version active ? ;
• Comment suspendre ou restaurer une version sans perdre les dossiers en cours ? ;