Les équipes résistent souvent à la logique de machine à états parce que le CRUD paraît plus rapide. Cela tient jusqu’au moment où le produit cesse de ressembler à une table et commence à ressembler à un processus avec de vraies règles de transition.
Dès que le support demande “comment est-on arrivé à cet état ?”, le problème n’est plus un simple CRUD.
Le problème
Dans les systèmes orientés workflow, le statut reste traité trop longtemps comme un simple champ. Chaque client, outil admin et worker devient alors responsable de décider quelles transitions sont valides, quels effets de bord doivent partir et quels changements sont rejouables.
Ce qui casse en pratique
- Des transitions invalides sont écrites parce que l’endpoint d’update n’a aucun garde-fou métier.
- Des effets de bord partent sur des changements d’état techniquement acceptés mais opérationnellement illégaux.
- Le support voit le statut courant sans avoir le chemin qui a produit cet état.
- Les différentes surfaces produit dérivent sur la signification réelle de
pending ou confirmed.
Décisions de conception
- Modéliser explicitement les transitions autorisées pour rejeter les chemins illégaux avant que la dérive ne se propage.
- Garder les gardes de transition côté backend afin que le frontend ne devienne pas propriétaire caché de la cohérence.
- Attacher les effets de bord à des événements de transition explicites plutôt qu’à un changement générique de champ.
- Conserver l’historique des transitions afin que les opérateurs puissent expliquer l’état courant et le chemin pris.
Arbitrages
- Une modélisation en machine à états demande plus de conception qu’un endpoint d’update générique.
- Les API orientées transition peuvent paraître plus lentes à faire évoluer au départ.
- Un contrôle plus fort réduit une certaine flexibilité accidentelle, mais c’est souvent justement le but dans des flux sensibles.
Patterns de production
- Tables de transitions explicites ou services de garde.
- Audit trail indiquant qui a déclenché la transition et pourquoi elle était autorisée.
- Effets de bord pilotés par événements de transition acceptée.
- Outillage opérateur montrant état courant, état précédent et prochaines actions sûres.
Ce que je ferais différemment
- Introduire plus tôt l’historique de transition au lieu d’attendre un besoin de reconstitution support.
- Rendre visibles les métriques de transitions invalides car elles révèlent très vite les défauts UX et contrat.
- Formaliser plus tôt un langage commun autour des statuts pour éviter les débats produit/technique dans les tickets.