- Pour qui ?
- DSI, responsables sécurité, directions des opérations et propriétaires de processus
- Question traitée
- Préparer les données et les droits nécessaires au déploiement d’un premier workflow Vigilo.
À retenir
- Les accès se définissent par étape du workflow, pas par application entière.
- Lire, préparer, écrire, valider et administrer sont des droits différents.
- Chaque action doit rester reliée à sa source, à la règle utilisée et au résultat observé.
- Un droit manquant, une donnée ambiguë ou un contrôle impossible doit arrêter le traitement proprement.
Commencer par une boucle complète, pas par toutes les données
Prenons un premier périmètre : traiter les demandes de modification de créneau reçues par e-mail pour un type de transport, préparer la mise à jour dans le TMS et soumettre les cas reçus à moins de 24 heures à l’exploitation. Le workflow doit également vérifier que la valeur finale enregistrée correspond à la décision.
Ce scénario exige quelques sources précises. Il n’exige ni l’historique complet de l’entreprise ni un compte administrateur sur le TMS. Le cadrage consiste à relier chaque étape à la donnée minimale, au droit minimal et à la preuve attendue.
Les sources minimales du scénario
| Source | Données utiles | Pourquoi elles sont nécessaires | Limite à définir |
|---|---|---|---|
| Boîte ou file e-mail dédiée | Émetteur, destinataires, horodatage, objet, corps et pièces autorisées. | Détecter la demande et conserver sa formulation d’origine. | Dossiers, libellés, expéditeurs et durée de conservation couverts. |
| TMS | Référence, client, créneau courant, statut et champs du transport concerné. | Rattacher la demande et connaître l’état avant action. | Entités, types de transport, champs et écrans accessibles. |
| Référentiel de règles | Règle des 24 heures, périmètre, version, propriétaire et exceptions. | Déterminer si une validation est obligatoire. | Seules les règles actives et approuvées sont exécutables. |
| Source de disponibilité | Créneaux ou contraintes réellement utilisés par l’équipe. | Éviter de proposer une valeur indisponible. | Lecture limitée aux sites et périodes du pilote. |
| Historique du dossier | Événements, décisions, validations et résultats du périmètre. | Expliquer l’état courant et éviter une mise à jour contradictoire. | Accès limité au contexte nécessaire au workflow. |
Une matrice de permissions, étape par étape
| Étape | Droit minimal | Action interdite par défaut | Arrêt attendu |
|---|---|---|---|
| Observer l’e-mail | Lire la file et les pièces du périmètre. | Parcourir d’autres boîtes ou envoyer un message. | Source hors périmètre, pièce illisible ou type non reconnu. |
| Rattacher le dossier | Rechercher et lire les champs nécessaires du TMS. | Consulter des entités ou dossiers non concernés. | Aucun candidat fiable ou plusieurs candidats plausibles. |
| Appliquer la règle | Lire la version active et ses exceptions. | Créer, modifier ou activer une règle. | Règle absente, expirée, contradictoire ou hors périmètre. |
| Préparer la modification | Construire une proposition sans écriture. | Changer l’état réel du dossier. | Donnée obligatoire manquante ou créneau non vérifiable. |
| Faire valider | Présenter le contexte et recevoir une décision autorisée. | Se substituer au valideur requis. | Refus, absence de décision ou identité non autorisée. |
| Mettre à jour le TMS | Écrire uniquement les champs autorisés du dossier ciblé. | Supprimer le dossier, changer d’autres champs ou étendre le périmètre. | Session invalide, écran inattendu ou valeur concurrente modifiée. |
| Contrôler le résultat | Relire l’état et le rapprocher de l’attendu. | Considérer le clic comme une preuve de succès. | Valeur absente, différente ou impossible à relire. |
Lire, préparer et agir ne donnent pas la même responsabilité
Ces niveaux peuvent coexister dans le même workflow. Une modification standard peut être autorisée tandis qu’une demande tardive reste supervisée. Le droit doit suivre la nature de la décision, pas une notion globale d’« autonomie » accordée à l’application.
- 01Observation
Vigilo reconstruit le dossier et journalise ce qu’il aurait proposé, sans modifier les outils.
- 02Préparation
Vigilo remplit une proposition que l’opérateur relit et soumet lui-même.
- 03Exécution supervisée
Une personne valide l’action précise avant son exécution.
- 04Exécution autorisée
Vigilo agit seul uniquement pour les cas couverts par une règle, des droits et des contrôles actifs.
Ce que le journal doit permettre de reconstruire
Journaliser ne signifie pas recopier toutes les données disponibles. Le journal doit être utile à l’explication, au contrôle et à la résolution, avec des règles de conservation et d’accès adaptées à la sensibilité des informations.
- l’événement déclencheur, sa source et son horodatage ;
- le dossier retenu et les candidats écartés lorsque cela est pertinent ;
- les valeurs lues, leur origine et la version utile à la décision ;
- la règle appliquée, son statut et sa version ;
- la proposition produite et la validation humaine éventuelle ;
- l’identité technique qui a effectué l’action et le droit mobilisé ;
- l’état avant action, l’état attendu et l’état réellement relu ;
- la cause d’un arrêt, d’une reprise ou d’une correction.
API ou interface : les mêmes exigences de contrôle
Lorsqu’une API expose l’action et le niveau de contrôle nécessaires, elle fournit généralement une voie structurée. Lorsque le workflow doit utiliser un écran, l’accès est cadré sur les mêmes principes : compte dédié si possible, rôles limités, environnement validé, champs autorisés et lecture du résultat.
L’interaction avec l’interface permet de s’adapter à des TMS et à des outils hétérogènes, mais elle ne dispense ni du cadrage ni des tests. Un changement d’écran, une fenêtre inattendue ou une session expirée doit être détecté comme un motif d’arrêt, pas contourné au hasard.
Les arrêts à décider avant le pilote
| Famille d’arrêt | Exemple | Reprise utile |
|---|---|---|
| Identité | Deux transports correspondent à la référence de l’e-mail. | Présenter les candidats et les éléments discriminants. |
| Donnée | Le nouveau créneau est absent ou contradictoire. | Demander la donnée manquante avec le dossier déjà préparé. |
| Règle | La demande est tardive mais aucune règle active ne couvre ce client. | Transmettre la décision et signaler le manque de règle. |
| Droit | Le compte peut lire le dossier mais pas modifier le créneau. | Conserver la proposition et prévenir le propriétaire du workflow. |
| Interface | Le TMS affiche une étape ou un champ inattendu. | Suspendre l’écriture et joindre l’état observé. |
| Contrôle | La valeur relue diffère de la valeur soumise. | Marquer l’action comme non confirmée et transmettre les deux états. |
La checklist d’un premier cadrage
- un événement déclencheur et un résultat attendu clairement nommés ;
- un propriétaire métier et un propriétaire technique ;
- les sources, entités et périodes incluses ;
- les comptes et rôles limités au périmètre ;
- les règles actives, leurs versions et leurs exceptions ;
- les étapes qui exigent une validation humaine ;
- les contrôles avant et après chaque action ;
- les motifs d’arrêt et les destinataires de la reprise ;
- la journalisation, la conservation et les accès au journal ;
- les critères permettant de rester en observation ou d’autoriser une étape supplémentaire.
Questions fréquentes
Réponses directes
Faut-il donner un compte administrateur à Vigilo ?
Non par principe. Les rôles doivent être limités aux lectures et actions du workflow. Un besoin exceptionnel doit être justifié, testé et gouverné séparément.
Vigilo doit-il copier toutes les données du TMS ?
Non. Le workflow accède aux données nécessaires à son contexte et à ses contrôles selon le périmètre convenu. Les règles de conservation et d’accès doivent être définies avec l’entreprise.
Peut-on commencer en lecture seule ?
Oui. Une phase d’observation permet de mesurer le rattachement, les décisions proposées et les motifs d’arrêt avant d’autoriser une écriture.
Que se passe-t-il si l’interface du TMS change ?
Le changement doit être détecté par les contrôles du parcours. L’action est suspendue jusqu’à validation ou adaptation du composant concerné.
Les mêmes droits conviennent-ils à tous les workflows ?
Non. Les sources, champs, règles et risques diffèrent. Les permissions se définissent pour chaque workflow et chaque environnement.
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.