Chargement des modèles…

🔄

Machines à états en graphe

Des machines à états finis implémentées sous forme de graphes pour le contrôle des workflows

Complexité: mediumOrchestration de flux de travail

Aperçu en 30 secondes

Quoi: Modélise le flux de travail sous forme d'états reliés par des transitions gardées, en exécutant des chemins déterministes à partir d'événements et de règles de validation.
Quand l'utiliser: Processus en plusieurs étapes avec des frontières d'état nettes, des besoins de retour arrière et des embranchements conditionnels selon le résultat de chaque étape.
Vigilance: L'explosion combinatoire des états et la charge de maintenance augmentent vite à mesure que les cas limites et les chemins d'erreur dépassent la conception initiale.

Interrogez l'expert IA sur ce pattern

Ouvre l'assistant avec votre question préremplie. Vous la relisez avant l'envoi.

Obtenir ce catalogue en serveur MCP Affinez un prompt pour ce pattern

Des machines à états finis implémentées sous forme de graphes pour le contrôle des workflows

State transition management
Event-driven execution
Deterministic flow control
State validation and guards
Rollback capabilities
Visual workflow representation

The Agent Architect

Un pattern, un compromis, une panne de production racontée. Un brief hebdomadaire court pour ceux qui construisent des systèmes agentiques.

Un email par semaine, désinscription en un clic. Votre adresse ne sert qu'à envoyer le brief.

Références

Les articles, spécifications et dépôts sur lesquels repose ce modèle.

Harel (1987): Statecharts - A Visual Formalism for Complex Systems
Murata (1989): Petri Nets - Properties, Analysis and Applications
Workflow Patterns (van der Aalst et al.)

Par l’ingénieur derrière ce catalogue

Faites auditer l’architecture de vos agents

Cette page documente un pattern. Votre système en fait tourner des dizaines, et l’essentiel des pannes se loge dans la façon dont ils s’articulent. Faites relire toute la conception à l’aune des 288 patterns de ce catalogue : architecture, fiabilité, évaluation et coûts, chaque constat relié au pattern qui le corrige.

750 € au lieu de 1 500 €, une semaine, rapport écrit et appel de restitution, jusqu’au 30 septembre

Voir la revue

Modèles

Chargement des modèles…

Modèles et techniques de conception

Chargement des modèles…

🔄

Machines à états en graphe

Des machines à états finis implémentées sous forme de graphes pour le contrôle des workflows

Complexité: mediumOrchestration de flux de travail

Aperçu en 30 secondes

Quoi: Modélise le flux de travail sous forme d'états reliés par des transitions gardées, en exécutant des chemins déterministes à partir d'événements et de règles de validation.
Quand l'utiliser: Processus en plusieurs étapes avec des frontières d'état nettes, des besoins de retour arrière et des embranchements conditionnels selon le résultat de chaque étape.
Vigilance: L'explosion combinatoire des états et la charge de maintenance augmentent vite à mesure que les cas limites et les chemins d'erreur dépassent la conception initiale.

Interrogez l'expert IA sur ce pattern

Ouvre l'assistant avec votre question préremplie. Vous la relisez avant l'envoi.

Obtenir ce catalogue en serveur MCP Affinez un prompt pour ce pattern

Mécanisme central

Les machines à états en graphe représentent le flux de contrôle comme des états (nœuds) et des transitions pilotées par événements (arêtes), avec conditions de garde et actions. Les statecharts y ajoutent des états hiérarchiques, des régions orthogonales (parallélisme) et l'historique, afin de capturer des comportements réels complexes. Cela offre un contrôle de flux déterministe et auditable pour les invocations d'agents et d'outils, les approbations, les réessais et les points de contrôle avec humain dans la boucle.

Déroulement / étapes

Énumérez les états (initial, intermédiaires, terminaux) et définissez le schéma d'état et de contexte.
Listez les événements ; définissez les transitions avec gardes et actions (incluez erreurs et timeouts comme événements).
Concevez le graphe : priorités et transitions par défaut pour chaque état ; ajoutez hiérarchie et régions parallèles si vous utilisez des statecharts.
Implémentez une logique de transition pure ; exécutez les effets de bord dans des handlers d'effets, avec réessais et idempotence.
Persistez l'état et un contexte minimal ; versionnez la machine ; permettez la visualisation depuis les sources.
Testez les transitions (tests pilotés par table), fuzzez les gardes et validez les invariants ; ajoutez de l'observabilité.

Bonnes pratiques

Limitez l'explosion d'états : encodez les vérifications de données dans les gardes, pas dans des états séparés.

Utilisez les statecharts pour la hiérarchie et le parallélisme ; exploitez l'historique pour la reprise.

Gardez les fonctions de transition pures ; isolez les I/O et effets de bord avec des clés d'idempotence.

Modélisez explicitement pannes et timeouts ; ajoutez des compensations et des chemins de rollback.

Générez les diagrammes de référence depuis la définition de la machine ; relisez les diffs dans les PR.

Ne persistez que le contexte nécessaire ; externalisez les gros artefacts via des URI ; protégez les données sensibles.

Tests exhaustifs des gardes et transitions ; tests de propriétés pour les invariants de sûreté.

Quand NE PAS l'utiliser

Flux linéaires simples où une fonction séquentielle ou un DAG est plus clair et moins coûteux.

Traitement de données/ETL lourd où les moteurs de flux ou DAG conviennent mieux que des machines à gardes événementielles.

Chemins à latence ultra faible, sensibles au surcoût de la boucle d'événements et de l'évaluation des gardes.

Transactions ACID strictes entre services ; préférez des moteurs de workflow avec sagas ou transactions.

Pièges fréquents

Explosion d'états due à l'encodage de conditions de données fines comme états plutôt que comme gardes.

Gardes ambiguës ou qui se recoupent ; transitions par défaut manquantes → non-déterminisme.

Effets de bord intégrés aux transitions → non-déterminisme et risques lors des réessais.

Absence de persistance ou d'idempotence → effets irrécupérables ou dupliqués lors des réessais.

Régions parallèles sans isolation correcte → courses critiques et interblocages.

Fonctionnalités clés

Sémantique déterministe événement→transition avec gardes et actions

États hiérarchiques et parallèles (statecharts) ; historique et restauration

Transitions explicites d'erreur, de timeout et de compensation

Modèles visuels et raisonnement formel sur l'atteignabilité et les invariants

Sous-machines composables ; réutilisation via régions et machines invoquées

KPI / indicateurs de succès

Couverture des transitions et détection des états inatteignables dans les tests.

Nombre moyen d'étapes jusqu'à l'achèvement ; distribution du temps passé par état ; p50/p95 par transition.

Taux de transitions d'échec et de compensation ; taux de succès des rejeux et reprises.

Pour les étapes LLM : tokens par état et par exécution ; coût par exécution ; taux de succès du cache.

Utilisation des tokens / ressources

Facteurs : appels LLM/outils par état, prompts de validation et d'auto-vérification, croissance du contexte dans les données d'état.

Leviers : budgets de tokens par état ; résumez ou élaguez le contexte ; mettez en cache les étapes déterministes ; bornez la concurrence.

Stockage/CPU : persistez un état minimal et des références ; évitez de journaliser le contexte sensible ; instrumentez le coût par transition.

Meilleurs cas d'usage

Flux de commande, d'approbation et d'exécution avec réessais, compensations et validations humaines.

Contrôleurs d'agents ou de dialogue encadrant les appels d'outils et les contrôles de sécurité à chaque étape.

Workflows de conformité exigeant un rejeu déterministe et des pistes d'audit.

Contrôleurs de dispositifs ou de procédés avec modes hiérarchiques et parallèles.

Références et lectures complémentaires

Articles académiques

Guides d'implémentation

Outils et bibliothèques

XState/Statecharts, AWS Step Functions, Temporal, Camunda BPMN 2.0
LangGraph, LlamaIndex Workflows

Communauté et discussions

Des machines à états finis implémentées sous forme de graphes pour le contrôle des workflows

State transition management
Event-driven execution
Deterministic flow control
State validation and guards
Rollback capabilities
Visual workflow representation

The Agent Architect

Un pattern, un compromis, une panne de production racontée. Un brief hebdomadaire court pour ceux qui construisent des systèmes agentiques.

Un email par semaine, désinscription en un clic. Votre adresse ne sert qu'à envoyer le brief.

Références

Les articles, spécifications et dépôts sur lesquels repose ce modèle.

Harel (1987): Statecharts - A Visual Formalism for Complex Systems
Murata (1989): Petri Nets - Properties, Analysis and Applications
Workflow Patterns (van der Aalst et al.)

Par l’ingénieur derrière ce catalogue

Faites auditer l’architecture de vos agents

750 € au lieu de 1 500 €, une semaine, rapport écrit et appel de restitution, jusqu’au 30 septembre

Voir la revue

Chargement des modèles…

Machines à états en graphe

Aperçu en 30 secondes

Interrogez l'expert IA sur ce pattern