Un champ comme état = "en attente" semble suffisant jusqu’à ce que le processus accumule des approbations, des exceptions et des actions qui dépendent de la manière dont il est arrivé à ce stade. Des questions pratiques se posent alors : peut-on annuler après une approbation ? Qui peut rouvrir un dossier ? Que se passe-t-il si la même demande est reçue deux fois ? Une machine à états aide à y répondre en décrivant non seulement l’état actuel, mais aussi les changements autorisés et leurs effets.
Tous les flux n’ont pas besoin de ce modèle. Dans un processus court et linéaire, une étiquette d’état et quelques règles simples peuvent être plus faciles à construire et à maintenir. Il s’agit de comparer la complexité réelle du flux au coût nécessaire pour rendre ses règles explicites, et non d’adopter un modèle à l’avance.
État sous forme d’étiquette ou machine à états : ce qui change
Enregistrer un état sous forme d’étiquette représente une situation actuelle : une tâche peut, par exemple, être « en attente » ou « terminée ». À elle seule, cette étiquette n’indique pas quels changements sont valides, quel événement les déclenche ni quelles actions doivent les accompagner. Cette logique se retrouve souvent répartie entre l’interface, le serveur et différentes conditions du code.
Une machine à états décrit le processus comme un ensemble défini d’états et de transitions. Une transition précise quel événement permet de passer d’un état à un autre et, le cas échéant, quelles conditions doivent être remplies ou quelles actions sont exécutées. L’état actuel limite donc les évolutions possibles.
La différence ne tient pas au nombre d’étiquettes dans une base de données. Un champ d’état peut faire partie d’une machine explicite si le système valide les transitions. À l’inverse, une longue liste d’états ne constitue pas en soi un bon modèle si personne ne peut expliquer comment passer de l’un à l’autre.
Les signes qui invitent à définir des transitions explicites
Le modèle commence à apporter de la valeur lorsque les règles dépendent de l’étape du processus et que les erreurs de transition ont des conséquences. Soyez attentif aux signes suivants :
- Des actions autorisées différentes : tout le monde ne peut pas approuver, modifier ou annuler à chaque étape, ou une action n’est disponible qu’après une validation.
- Des parcours alternatifs : une demande peut être approuvée, rejetée, renvoyée pour compléter les informations ou annulée.
- Des règles dispersées : différentes parties de l’application vérifient indépendamment si une opération est valide, au risque de se contredire.
- Des effets associés au changement : une transition doit enregistrer une décision, avertir quelqu’un ou lancer une autre tâche. Il est utile de distinguer cet effet du simple changement d’étiquette.
- Des nouvelles tentatives et de la concurrence : deux personnes ou processus peuvent essayer de modifier le même dossier, ou une intégration peut répéter un événement.
Un bon indice de diagnostic est que l’équipe débat régulièrement de la question de savoir si un changement « devrait être autorisé » à une étape précise. Si la réponse dépend de l’état précédent, de la personne qui agit ou d’un résultat métier, il est préférable d’enregistrer la règle de manière explicite et centralisée.
Quand de simples états suffisent
Un modèle simple suffit généralement lorsque le processus est linéaire, qu’il comporte peu de transitions et que les exceptions sont rares ou faciles à gérer. Une tâche interne qui passe de « en attente » à « terminée » peut, par exemple, ne nécessiter qu’un champ et une vérification claire, surtout en l’absence d’approbations, de nouvelles tentatives ou de conséquences externes.
Le coût opérationnel compte également. Une machine à états introduit des notions, des tests et de la maintenance. Si le flux ne présente aucune ambiguïté, ce coût peut dépasser les avantages. Ne transformez pas chaque changement d’écran, étape d’interface ou variation mineure en état métier : une expérience visuelle ne correspond pas toujours à une étape du processus.
En pratique, commencez par la représentation la plus simple qui permette de faire respecter les règles importantes. Si des conditions répétées, des transitions implicites ou des incidents liés à des changements invalides apparaissent, réexaminez la conception. L’évolution peut être progressive : il n’est pas nécessaire de repenser tout le processus pour commencer par formaliser les transitions les plus risquées.
Critères de décision
Il n’existe pas de nombre universel d’états ou de transitions à partir duquel une machine à états devient nécessaire. Évaluez le fonctionnement du processus et l’impact des erreurs à l’aide de questions concrètes :
- Combien de parcours réels existe-t-il ? Comptez les parcours métier et leurs embranchements, pas seulement les étiquettes. Plusieurs parcours avec des autorisations ou des résultats distincts justifient souvent un modèle explicite.
- Que se passe-t-il si quelqu’un tente une transition invalide ? Si l’effet est gênant mais réversible, une vérification simple peut suffire. S’il peut entraîner une mauvaise décision, du travail en double ou une action difficile à annuler, définissez des contrôles plus clairs.
- Des changements simultanés ou des événements répétés sont-ils possibles ? Si oui, déterminez comment vérifier que l’état n’a pas changé depuis le début de l’opération et comment éviter que le traitement répété d’un même événement ne duplique ses effets.
- Faut-il pouvoir expliquer le parcours ? Si les équipes d’assistance, d’audit ou d’exploitation doivent savoir qui a fait quoi, quand et pourquoi, séparer l’état actuel de l’historique des événements facilite la reconstitution de l’évolution.
- Les règles peuvent-elles être regroupées en un endroit compréhensible ? Si elles nécessitent des exceptions en chaîne dans plusieurs composants, le problème ne se limite plus au nombre d’états : c’est le signe que le flux ne dispose pas d’une définition unique.
Comment nommer les états, les événements et les exceptions
Utilisez des termes qui décrivent des étapes compréhensibles pour l’activité. Un état répond à la question « dans quelle situation se trouve le dossier ? » ; un événement répond à « que s’est-il passé pour le faire changer ? ». Par exemple, « en cours d’examen » peut être un état et « examen approuvé », un événement. Évitez de traiter ces deux notions comme des synonymes.
Séparez aussi l’étape du résultat lorsqu’il s’agit de dimensions différentes. « Clôturé » décrit une étape finale, tandis que « approuvé » ou « rejeté » décrit un résultat. Si ces notions sont mélangées, des états combinés tels que « clôturé et rejeté » peuvent apparaître, multiplier les variantes et compliquer l’analyse des règles.
Indiquez quels états sont terminaux, c’est-à-dire ceux dans lesquels le processus prend normalement fin. Définissez séparément si une annulation ou une réouverture est possible et qui peut l’effectuer. Un état terminal ne doit pas forcément empêcher toute action administrative, mais l’exception doit être délimitée et ne pas devenir une porte dérobée permettant de contourner les règles.
Pour les nouvelles tentatives, évitez de créer un nouvel état à chaque essai si le dossier reste à la même étape. Conservez l’état approprié et enregistrez la tentative dans l’historique ou dans une donnée distincte. Faites de même pour les échecs et les exceptions : créez un état différent uniquement si cela modifie de manière significative les actions métier possibles par la suite.
Exemple hypothétique : une demande soumise à examen
Imaginons une demande qui est reçue, examinée, puis approuvée ou rejetée. Dans la version la plus simple, ses états pourraient être « reçue », « en cours d’examen » et « traitée », avec un résultat associé. Si l’équipe doit demander des informations complémentaires, le flux doit représenter cette pause et définir quel événement permet de reprendre l’examen lorsque la réponse arrive.
Une transition peut préciser que seule une personne habilitée peut approuver ou rejeter une demande lorsqu’elle est « en cours d’examen ». En cas de rejet, le dossier est traité avec le résultat « rejeté » ; si des informations manquent, il passe à l’état « informations en attente ». La machine n’exige pas de plateforme particulière : il suffit que le système valide ces changements de manière cohérente et enregistre les données nécessaires.
Cet exemple est hypothétique ; les noms et les règles doivent être adaptés au processus réel. Si une demande d’informations ne modifie pas les actions disponibles et ne nécessite aucun suivi, une simple note peut suffire. Le modèle doit refléter les différences opérationnelles, et non anticiper toutes les possibilités imaginables.
Erreurs fréquentes et liste de vérification
Un modèle peut devenir plus complexe que le processus s’il crée un état pour chaque détail, mélange les autorisations et les étapes ou ne précise pas ce qu’il advient des anciens dossiers lorsque les règles changent. C’est également une erreur de représenter les transitions dans un diagramme tout en laissant le code les ignorer : la règle doit être appliquée à l’endroit où le changement est accepté.
Avant de choisir ou de réexaminer votre approche, vérifiez les points suivants :
- Chaque état représente-t-il une situation que l’activité peut expliquer ?
- Les événements décrivent-ils des faits et les transitions précisent-elles quels changements ils autorisent ?
- Les parcours alternatifs, les annulations et les réouvertures sont-ils clairement définis ?
- Les opérations invalides sont-elles rejetées, et les événements répétés ou les changements simultanés sont-ils contrôlés ?
- L’historique est-il enregistré lorsqu’il faut reconstituer des décisions ?
- Certains états peuvent-ils être regroupés sans perdre de règles ni d’informations pertinentes ?
Choisissez une machine à états lorsqu’elle permet de rendre visibles et applicables des règles qui seraient autrement dispersées, et lorsque le coût d’une transition incorrecte justifie ce contrôle. Si le processus est linéaire et prévisible, commencez par de simples états. Réexaminez votre décision si les parcours, les exceptions ou les conséquences évoluent : le meilleur modèle est le plus simple qui représente fidèlement l’évolution du travail.