Cycle de vie d’une règle métier : proposée, validée, active, suspendue

Pourquoi une règle a besoin d’un cycle de vie

Une consigne métier n’est pas une phrase isolée. Elle s’applique à certains clients, certains types de transport, certaines sources et certaines périodes. Elle peut autoriser une simple préparation, exiger une validation ou permettre une action. Sans ces limites, une règle juste dans un cas peut devenir dangereuse ailleurs.

Le cycle de vie rend visibles ces conditions et les décisions de gouvernance. Il sépare la connaissance observée de la permission d’agir, puis permet de suivre l’usage réel, les écarts et les changements apportés au fil du temps.

Les quatre statuts essentiels

Ce qu’une proposition doit démontrer

Vigilo peut repérer qu’une même décision apparaît dans des situations comparables. La proposition doit toutefois montrer les faits qui l’expliquent et les différences entre les dossiers. Elle ne doit pas transformer une corrélation ou une habitude ponctuelle en vérité générale.

• les dossiers, événements et décisions qui ont fait émerger la proposition ;
• le contexte commun et les variations observées ;
• la formulation proposée et le résultat attendu ;
• le périmètre probable : clients, flux, outils, rôles et périodes ;
• les contradictions, contre-exemples et cas encore inconnus ;
• le niveau envisagé : information, préparation, validation obligatoire ou action autorisée.

La validation est une décision de gouvernance

Cette validation peut s’appuyer sur une règle déjà documentée ou sur une pratique révélée par l’observation. Dans les deux cas, l’équipe reste la source de l’autorisation. Vigilo rend la connaissance explicite et testable ; il ne s’attribue pas de nouveaux droits.

1. 01
   Nommer un propriétaire

   Une personne ou une fonction répond du sens métier de la règle et de ses évolutions.

2. 02
   Délimiter le périmètre

   Les clients, opérations, sources, systèmes et rôles concernés sont explicitement définis.

3. 03
   Écrire les exclusions

   Les cas sensibles, ambigus, nouveaux ou contractuellement particuliers sont retirés du champ automatique.

4. 04
   Définir les droits

   La règle précise si Vigilo informe, prépare, demande une validation ou agit.

5. 05
   Choisir les contrôles

   Les vérifications avant et après action, ainsi que les résultats qui imposent un arrêt, sont documentés.

6. 06
   Préparer la suspension

   Le responsable, le déclencheur et le comportement de repli sont décidés avant l’activation.

Versionner pour expliquer chaque décision

Une modification de règle ne doit pas réécrire le passé. Chaque version conserve sa formulation, son périmètre, ses exceptions, son propriétaire, sa date de décision et les contrôles associés. Les actions sur un dossier restent liées à la version effectivement utilisée.

Lorsqu’une règle évolue, une nouvelle version passe à son tour par la validation. L’ancienne peut rester consultable, être limitée à certains dossiers en cours ou être suspendue. Cette traçabilité permet d’expliquer pourquoi deux dossiers proches ont reçu des traitements différents à des dates ou dans des périmètres différents.

Quand suspendre une règle active

La suspension est un mécanisme normal de maîtrise, pas nécessairement le constat d’un échec. Elle protège le workflow lorsqu’une hypothèse n’est plus vraie ou lorsqu’un contrôle ne permet plus de garantir le résultat attendu.

• un écran, une API, un document ou un référentiel a changé ;
• une règle contractuelle ou une responsabilité métier a évolué ;
• des résultats contrôlés montrent un écart nouveau ou récurrent ;
• le propriétaire n’est plus en mesure de confirmer le périmètre ;
• un incident impose une analyse avant toute nouvelle action ;
• la règle entre en contradiction avec une version plus récente ou une source prioritaire.

Au moment de la suspension, les nouveaux cas doivent suivre un comportement connu : transmission contextualisée, préparation sans exécution ou règle de repli déjà validée. Le motif, l’auteur et la date de suspension restent consultables.

L’adaptabilité sans perdre la maîtrise

Chaque entreprise combine ses propres TMS, portails, rôles et manières de traiter les exceptions. Vigilo s’adapte à cette réalité en configurant des briques communes — événements, dossier, règles, actions, contrôles et transmissions — plutôt qu’en imposant un workflow unique.

Cette configuration devient un actif lorsqu’elle est structurée : elle permet de faire évoluer un écran, un processus ou une règle sans repartir de zéro, tout en sachant exactement ce qui change. La portabilité ne signifie pas que tous les systèmes se ressemblent ; elle repose sur une méthode commune pour décrire et gouverner leurs différences.