🇬🇧 English version

Guide comparatif des ProcessTypes

Prérequis : Vue d'ensemble et YAML et Builders

Vue d'ensemble

Orkeon propose 6 stratégies d'orchestration via le value object ProcessType (Domain layer). Chaque stratégie définit comment les agents se coordonnent pour exécuter les tâches d'une Crew. Le choix du ProcessType est le levier architectural le plus impactant sur le comportement d'un système multi-agents.

// Orkeon.Domain.SharedKernel.ValueObjects.ProcessType (sealed record)
ProcessType.Sequential    // Pipeline linéaire
ProcessType.Hierarchical  // Manager + workers
ProcessType.Parallel      // Exécution concurrente
ProcessType.Consensual    // Vote et consensus
ProcessType.Graph         // Graphe d'états avec cycles contrôlés
ProcessType.Autonomous    // Auto-organisation avec budget

Architecture d'implémentation

ProcessType (Domain — Value Object)
     │
     ▼
IProcessStrategy (Domain — Interface)
     │
     ▼
ProcessStrategyFactory (Infrastructure)
     │
     ├── SequentialProcessStrategy
     ├── HierarchicalProcessStrategy
     ├── ParallelProcessStrategy
     ├── ConsensualProcessStrategy      ← IConsensualProcessStrategy
     ├── GraphProcessStrategy
     └── AutonomousProcessStrategy

Le ProcessStrategyFactory résout la stratégie appropriée via un switch sur ProcessType.Value, injecté par DI.

Matrice de comparaison rapide

Critère	Sequential	Hierarchical	Parallel	Consensual	Graph	Autonomous
Modèle d'exécution	Linéaire	Linéaire + revue	Concurrent	Parallèle + vote	Machine à états	Auto-organisé
Coordination	Round-robin	Manager LLM	Round-robin	Consensus LLM	Round-robin + routing	LLM + canal A2A
Dépendances entre tâches	Oui (chaînées)	Oui (via manager)	Oui (vagues)	Non	Oui (edges)	Oui (délégation)
Circuit breaker	—	—	—	—	✅ 4 mécanismes	—
Budget d'exécution	—	—	—	—	—	✅ 5 dimensions
Retry automatique	—	Révisions (max 3)	—	Rounds de vote	✅ configurable	Via délégation
Spawn dynamique	—	—	—	—	—	✅ SpawnAgentTool
Complexité	⭐	⭐⭐	⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
Coût LLM relatif	Bas	Moyen	Bas	Élevé	Moyen	Variable
Cas d'usage principal	Pipelines ETL	QA, revue de code	Tâches indépendantes	Décisions critiques	Workflows complexes	Exploration, R&D

1. Sequential — Pipeline linéaire

Principe

Les tâches s'exécutent une par une, dans l'ordre défini par l'ExecutionPlan. Chaque tâche reçoit en contexte les résultats des tâches précédentes. L'assignation agent se fait en round-robin (sauf assignation explicite via task.AssignedAgent).

Ordre d'exécution sans plan (planning: false, le défaut) : les tâches s'exécutent dans un ordre topologique stable sur leurs dependencies déclarées — une tâche s'exécute après chaque tâche dont elle dépend, et partout où les dépendances le permettent l'ordre déclaré est conservé, si bien qu'une crew sans aucune dépendance s'exécute exactement comme elle est écrite. Cela vaut dans tous les layouts : le layout multi-fichiers (tasks/*.yaml) liste les tâches dans l'ordre ordinal de leurs noms de fichiers, donc sans ce tri consolider.yaml s'exécutait avant l'extraire.yaml dont il dépend. Une dépendance qui nomme un id de tâche inconnu est ignorée ; un cycle ne fait jamais échouer la crew — l'ordre déclaré est conservé pour les tâches prises dans le cycle et un avertissement les nomme. La même règle ordonne les modes hiérarchique, consensuel, graphe et autonome, qui distribuent eux aussi leurs tâches une par une ; le mode parallèle garde sa propre sémantique (des vagues de dépendances, et un cycle est refusé). Avec planning: true, l'ordre du planificateur est pris tel quel. Une tâche dont une dépendance déclarée n'a pas abouti — échouée, ou ignorée à son tour — est ignorée, jamais exécutée sur un contexte qui dit Task failed: … à la place de l'entrée qu'elle attendait : elle apparaît en ⊘ skipped dans AUTO_SUMMARY.md et comme événement task.completed avec skipped: true, les tâches qui n'en dépendent pas s'exécutent quand même, et la crew échoue en nommant chaque tâche échouée et ignorée (LLM-11).

Mécanisme interne

Task 1 → Agent A → output₁
                      ↓ (contexte enrichi)
Task 2 → Agent B → output₂
                      ↓
Task 3 → Agent C → output₃ → résultat final

Classes clés : SequentialProcessStrategy, ExecutionPlan, AgentDelegationToolsProvider

Configuration YAML

# Racine plate — il n'existe pas de clé enveloppe crew:, et agents:/tasks: sont
# des mappings indexés par id (un fichier enveloppé de crew: se charge
# SILENCIEUSEMENT comme une crew vide).
name: "pipeline"
goal: "Démo séquentielle"
process: sequential
tasks:
  collecte:
    description: "Collecter les données"
    expectedOutput: "Données brutes"
  analyse:
    description: "Analyser les données"
    expectedOutput: "Rapport d'analyse"
    dependencies: [collecte]
  recommandations:
    description: "Générer les recommandations"
    expectedOutput: "Plan d'action"
    dependencies: [analyse]

Configuration Fluent Builder

var crew = new CrewBuilder()
    .Sequential()
    .WithAgent(a => a.Role("Collector").Goal("Gather data"))
    .WithAgent(a => a.Role("Analyst").Goal("Analyze data"))
    .WithTask(t => t.Description("Collect").ExpectedOutput("Raw data"))
    .WithTask(t => t.Description("Analyze").ExpectedOutput("Report"))
    .Build();

Avantages

Simplicité maximale : aucune configuration complexe, comportement prévisible
Traçabilité : chaque étape est clairement identifiable dans les logs
Contexte cumulatif : chaque tâche bénéficie des résultats précédents
Déterminisme : même entrée → même parcours d'exécution

Inconvénients

Pas de parallélisme : le temps total est la somme de toutes les tâches
Point de défaillance unique : un échec bloque la suite de la chaîne — ses dépendantes sont ignorées, seules les tâches indépendantes s'exécutent encore
Pas de retry : aucune reprise automatique en cas d'erreur
Rigide : l'ordre est fixe, pas de branchement conditionnel

Quand l'utiliser

Pipelines ETL (extraction → transformation → chargement)
Rédaction séquentielle (recherche → rédaction → relecture)
Workflows où chaque étape dépend strictement de la précédente
Prototypage rapide et POC

Quand ne pas l'utiliser

Tâches indépendantes pouvant s'exécuter en parallèle
Workflows nécessitant des branches conditionnelles
Scénarios exigeant de la résilience (retry, fallback)

2. Hierarchical — Manager + Workers

Principe

Un agent manager (piloté par LLM) coordonne une équipe de workers. Pour chaque tâche, le manager sélectionne l'agent le plus approprié via AssignTaskAsync(), puis revoit la sortie et peut demander jusqu'à 3 révisions.

Mécanisme interne

                  ┌─── Manager Agent ───┐
                  │   AssignTask()      │
                  │   ReviewOutput()    │
                  └────────┬────────────┘
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
        Agent A        Agent B        Agent C
        (choisi)       (en attente)   (en attente)
            │
            ▼
        Output → Review → OK? → oui → tâche suivante
                           → non → révision (max 3)

Classes clés : HierarchicalProcessStrategy, IManagerAgent, LlmBasedManager, TaskAssignment

Interface IManagerAgent :

AssignTaskAsync(task, agents, context) → TaskAssignment (agent sélectionné + justification)
ReviewOutputAsync(output, task) → bool (approuvé ou non)

Configuration YAML

name: "delivery-team"
goal: "Démo hiérarchique"
process: hierarchical
managerAgent: lead          # l'id de l'agent manager (il n'existe pas de clé manager_llm)
llm:                        # LLM par défaut de la crew, appliqué aux agents sans le leur
  model: gpt-4o
agents:
  lead:
    role: "Tech Lead"
    goal: "Coordonner la livraison"
  dev:
    role: "Senior Developer"
    goal: "Écrire le code de production"
  qa:
    role: "QA Engineer"
    goal: "Tester et valider"

Avantages

Allocation intelligente : le manager choisit l'agent le plus adapté à chaque tâche
Contrôle qualité intégré : boucle de révision automatique
Flexibilité : le manager peut adapter la stratégie en cours d'exécution
Traçabilité : chaque assignation est justifiée

Inconvénients

Coût LLM supplémentaire : le manager consomme des tokens pour chaque décision + revue
Goulot d'étranglement : tout passe par le manager (pas de parallélisme)
Révisions limitées : max 3 révisions (hardcodé), pas de retry structurel
Dépendance à la qualité du manager : un mauvais prompt manager dégrade tout le workflow

Quand l'utiliser

Revue de code (le manager assigne le reviewer le plus compétent)
Projets avec des spécialistes hétérogènes (dev, QA, design, rédaction)
Workflows nécessitant une validation humaine simulée
Situations où la qualité prime sur la vitesse

Quand ne pas l'utiliser

Tâches homogènes (round-robin suffit)
Contraintes de coût LLM strictes
Workflows à haute fréquence (le manager est un goulot)

3. Parallel — Exécution concurrente

Principe

Toutes les tâches s'exécutent simultanément via Task.WhenAll(). Chaque tâche dispose d'un contexte d'exécution indépendant (pas de résultats partagés entre tâches). Les résultats sont agrégés à la fin.

Mécanisme interne

        ┌── Task 1 → Agent A → output₁ ──┐
        │                                  │
Start ──┼── Task 2 → Agent B → output₂ ──┼── Agrégation → Résultat
        │                                  │
        └── Task 3 → Agent C → output₃ ──┘

Classes clés : ParallelProcessStrategy

Configuration YAML

name: "market-scan"
goal: "Démo parallèle"
process: parallel
tasks:
  france:
    description: "Analyser le marché français"
    expectedOutput: "Rapport France"
  allemagne:
    description: "Analyser le marché allemand"
    expectedOutput: "Rapport Allemagne"
  espagne:
    description: "Analyser le marché espagnol"
    expectedOutput: "Rapport Espagne"

Avantages

Vitesse maximale : temps total = durée de la tâche la plus longue
Simplicité : pas de coordination complexe
Scalabilité : ajout de tâches sans impact sur le temps total
Isolation : un échec d'une tâche n'impacte pas ses sœurs de vague

Inconvénients

Ordonnancement grossier : les dépendances sont honorées par vagues, pas tâche par tâche — une tâche attend toute sa vague, pas seulement ce qu'elle a déclaré
Consommation API en pic : toutes les requêtes LLM partent en même temps (rate limiting)
Agrégation basique : les résultats sont simplement concaténés
Pas de retry : aucune reprise automatique

Quand l'utiliser

Analyses multi-marchés ou multi-sources indépendantes
Génération de contenu en batch (un article par marché, par langue)
Tâches de classification parallèles
Un fan-out suivi d'une synthèse : les collecteurs tournent ensemble, la synthèse les lit

Quand ne pas l'utiliser

Routage conditionnel ou cycles entre tâches (utiliser Graph)
APIs avec rate limiting strict (les appels simultanés peuvent être throttled)
Scénarios nécessitant une synthèse progressive

4. Consensual — Vote et consensus

Principe

Pour chaque tâche, tous les agents l'exécutent indépendamment, puis un vote détermine le meilleur résultat. Si aucun consensus n'est atteint, des rounds de discussion permettent aux agents de reconsidérer leur position en voyant les résultats des autres. Un mécanisme de fallback tranche en dernier recours.

Mécanisme interne

Task N ──┬── Agent A → résultat A ──┐
         ├── Agent B → résultat B ──┼── Vote ── Consensus? ── oui → Accepté
         └── Agent C → résultat C ──┘              │
                                                   non
                                                    ↓
                                          Discussion (round 2)
                                          Agents voient les autres résultats
                                                    ↓
                                                  Re-vote
                                                    ↓
                                          Échec → Fallback

Classes clés : ConsensualProcessStrategy, IVotingStrategy, IVotingStrategyFactory, Vote, VoteResult, VotingOptions, ConsensualProcessOptions

Types de consensus disponibles

Le mécanisme de vote est sélectionnable par configuration : la valeur de Orkeon:Consensus:VotingOptions:ConsensusType (section .NET appsettings.json) choisit la stratégie dédiée via IVotingStrategyFactory. Sans configuration, le défaut reste Majority (rétro-compatible).

Type	Stratégie résolue	Description	Seuil par défaut
`Majority`	`MajorityVotingStrategy`	Plus de 50% des votes	50%
`SuperMajority`	`SuperMajorityVotingStrategy`	Seuil configurable (défaut 2/3)	66.7%
`Unanimity`	`UnanimityVotingStrategy`	Tous les agents doivent s'accorder	100%
`WeightedConsensus`	`WeightedConsensusStrategy`	Votes pondérés par rôle (`RoleWeights`)	Configurable
`BordaCount`	`BordaCountStrategy`	Classement par score Borda	N/A

Configuration (.NET, section `Orkeon:Consensus`)

{
  "Orkeon": {
    "Consensus": {
      "MaxVotingRounds": 3,
      "VotingOptions": {
        "ConsensusType": "SuperMajority",
        "ConsensusThreshold": 75,
        "QuorumPercent": 60,
        "UseWeightedVotes": true,
        "AllowAbstention": false
      },
      "EnableDiscussion": true,
      "FallbackStrategy": "AcceptBestScore",
      "RoleWeights": {
        "Senior Analyst": 2.0,
        "Junior Analyst": 1.0
      }
    }
  }
}

Note : ConsensusThreshold et QuorumPercent s'expriment en pourcentage (0–100), pas en fraction. Un seuil de super-majorité de 75 % s'écrit 75.

Avantages

Robustesse : réduit les hallucinations et biais individuels
Qualité : la "sagesse collective" produit souvent de meilleurs résultats
Flexibilité du vote : 5 stratégies de consensus, pondération par rôle
Discussion : les agents peuvent s'améliorer mutuellement entre les rounds
Fallback : 3 stratégies de repli (meilleur score, échec, décision manager)

Inconvénients

Coût LLM élevé : chaque tâche est exécutée N fois (N = nombre d'agents) × rounds
Lenteur : multiplication des appels LLM, surtout avec discussion activée
Complexité de configuration : nombreux paramètres (seuil, quorum, pondération, rounds)
Résultat incertain : le fallback peut produire un résultat insatisfaisant

Quand l'utiliser

Décisions critiques (diagnostic médical, évaluation de risque, audit)
Situations où la fiabilité prime sur le coût
Évaluations subjectives nécessitant plusieurs perspectives
Scénarios de "red team" (plusieurs agents tentent de trouver des failles)

Quand ne pas l'utiliser

Tâches factuelles avec une seule réponse correcte
Contraintes de budget LLM (multiplication par N agents × R rounds)
Workflows à haute fréquence (trop lent)

5. Graph — Graphe d'états avec cycles contrôlés

Principe

Les tâches sont organisées dans un graphe d'états typé inspiré de LangGraph. Le graphe supporte des edges conditionnels (routing dynamique) et des cycles contrôlés (retry automatique). Un circuit breaker à 4 mécanismes empêche les boucles infinies.

Mécanisme interne

START ──→ execute_task ──→ route ──┬── succès ──→ execute_task (suivante)
                                   │                      ↓
                                   │               ... (loop) ...
                                   │                      ↓
                                   ├── échec ──→ execute_task (retry)
                                   │
                                   └── terminé ──→ END

Classes clés :

StateGraph<TState> — Définition du graphe (nodes + edges)
GraphRunner<TState> — Moteur d'exécution
GraphProcessStrategy — Implémentation IProcessStrategy
CircuitBreakerPolicy — Protection anti-boucle
CrewGraphState — État typé circulant dans le graphe

`CrewGraphState` — Propriétés de l'état

Propriété	Type	Description
`PendingTaskIds`	`Queue<TaskId>`	Tâches restantes à exécuter
`FailedTaskIds`	`Queue<TaskId>`	Tâches éligibles au retry
`RetryCounts`	`Dict<string, int>`	Compteur de retries par tâche
`MaxRetryCycles`	`int`	Nombre max de retries (défaut: 2)
`ApplicationOutputs`	`IReadOnlyList<ApplicationTaskOutput>`	Sorties accumulées
`TotalTokensUsed`	`int`	Compteur de tokens consommés (propagé aux métadonnées du `CrewOutput` sous `totalTokens`)
`PromptTokensUsed`	`int`	Compteur de tokens côté prompt (0 si le provider ne fournit pas le split)
`CompletionTokensUsed`	`int`	Compteur de tokens côté completion (0 si le provider ne fournit pas le split)

Circuit Breaker — 4 mécanismes de protection

Mécanisme	Strict	Default	Permissive
`MaxTransitions`	50	100	1000
`StateTimeout`	2 min	5 min	30 min
`MaxStateVisits`	5	10	50
`MaxTotalDuration`	10 min	30 min	2 h

Configuration YAML

name: "review-loop"
goal: "Démo graphe"
process: graph
graphConfig:
  circuitBreakerPreset: "strict"   # ou "default", "permissive"
  maxRetryCycles: 3
  # Surcharges individuelles possibles :
  maxTransitions: 75
  maxStateVisits: 10
  maxTotalDurationSeconds: 180

Avantages

Branchement conditionnel : routing dynamique selon le résultat de chaque nœud
Retry intégré : les tâches échouées sont automatiquement re-tentées
Sécurité : circuit breaker à 4 niveaux empêche les exécutions infinies
Observabilité : événements OnNodeCompleted, OnCircuitBroken
Cycles utiles : boucle feedback → correction → validation
Presets : Strict (production) vs Permissive (développement)

Inconvénients

Complexité de conception : définir un graphe correct demande de la réflexion
Debugging : tracer un parcours dans un graphe cyclique est plus difficile
Overhead : le moteur de graphe ajoute une couche de complexité
Circuit breaker : peut couper l'exécution prématurément si mal configuré

Quand l'utiliser

Workflows avec branchements conditionnels (validation → OK/KO → chemins différents)
Pipelines nécessitant du retry avec backoff
Scénarios de correction itérative (rédaction → revue → correction → re-revue)
Workflows réglementaires avec des chemins d'exception

Quand ne pas l'utiliser

Pipelines linéaires simples (Sequential suffit)
Tâches indépendantes (Parallel suffit)
Équipes qui ne sont pas à l'aise avec la modélisation par graphe

Voir aussi : Orchestration FSM pour le détail complet.

6. Autonomous — Auto-organisation avec budget

Principe

Les agents s'auto-organisent : ils revendiquent des tâches, délèguent récursivement à leurs pairs, et peuvent spawner dynamiquement de nouveaux agents. Un budget multi-dimensionnel (5 axes) garantit la terminaison. La communication inter-agents se fait via un canal bidirectionnel (IAgentChannel).

Mécanisme interne

                    ┌─── Budget (5 dimensions) ───┐
                    │  tool calls · depth · time   │
                    │  tokens · spawned agents      │
                    └──────────────┬────────────────┘
                                   │
Manager (LLM) ── assigne ──→ Agent A
                                   │
                    ┌──────────────┼──────────────┐
                    ▼              ▼              ▼
              DelegateWork   SpawnAgent      Exécution
              (child budget)  (via factory)   directe
                    │              │
                    ▼              ▼
                Agent B       Agent D (nouveau)
                    │              │
                    ▼              ▼
              Résultat ←── canal A2A ──→ Résultat

Classes clés :

AutonomousProcessStrategy — Stratégie d'orchestration
AgentExecutionBudget — Budget multi-dimensionnel (Domain)
IAgentChannel / InMemoryAgentChannel — Communication A2A (lock-free)
SpawnAgentTool — Création dynamique d'agents
DelegateWorkTool — Délégation avec budget hérité
BudgetExhaustedException — Exception levée quand un axe est épuisé

Budget multi-dimensionnel — 5 axes

Dimension	Strict	Default	Permissive	Description
`MaxToolCalls`	8	15	50	Nombre max d'appels d'outils
`MaxDelegationDepth`	1	2	4	Profondeur de délégation (A→B→C = 2)
`MaxTokensConsumed`	8 000	16 000	64 000	Tokens LLM consommés
`MaxSpawnedAgents`	1	3	10	Agents créés dynamiquement
`MaxWallTime`	2 min	5 min	15 min	Durée maximale d'exécution

Child budgets : quand un agent délègue, il crée un budget enfant dérivé de ses propres ressources restantes (via CreateChildBudget()). Le budget enfant est toujours inférieur ou égal au budget parent restant.

Communication A2A

// Request/Response
var request = AgentChannelRequest.Create(
    from: analyst.Id,
    to: researcher.Id,
    intent: "find_data",
    payload: "Statistiques marché 2025");

var response = await channel.RequestAsync(request, timeout);

// Broadcast (fire-and-forget)
await channel.BroadcastAsync(analyst.Id, crew.Id, "Résultats disponibles", ct);

Configuration YAML

name: "research-team"
goal: "Démo autonome"
process: autonomous
# Il n'existe AUCUNE clé de budget autonome en YAML : une crew autonome YAML
# tourne toujours sous AgentExecutionBudget.Permissive (50 appels d'outils,
# profondeur 4, 15 min, 64 000 tokens, 10 spawns). Le budget ne se configure
# que par l'API C# — voir le guide Autonomous et yaml-schema.md.

Avantages

Adaptabilité maximale : les agents réagissent au contexte en temps réel
Spawn dynamique : capacité à créer des spécialistes à la demande
Terminaison garantie : budget multi-dimensionnel empêche les exécutions infinies
Communication riche : A2A request/response avec corrélation
Presets : configuration rapide (Strict/Default/Permissive)
Scalabilité : les agents se répartissent le travail organiquement

Inconvénients

Complexité élevée : mode le plus difficile à configurer et débugger
Coût imprévisible : la consommation de tokens dépend des décisions des agents
Non-déterministe : deux exécutions identiques peuvent suivre des chemins différents
Budget trop strict : peut couper l'exécution avant d'obtenir un résultat complet
Observabilité : nécessite un bon logging (BudgetSnapshot) pour comprendre le comportement

Quand l'utiliser

Exploration (recherche, R&D, analyse exploratoire)
Problèmes mal définis où la stratégie optimale n'est pas connue à l'avance
Systèmes nécessitant de l'auto-réparation (un agent détecte un problème → délègue la correction)
Scénarios multi-étapes où chaque étape peut révéler de nouvelles sous-tâches

Quand ne pas l'utiliser

Workflows déterministes et bien définis (Sequential ou Graph)
Environnements à budget LLM contraint sans marge
Scénarios réglementaires nécessitant une traçabilité complète du parcours

Voir aussi : Orchestration Autonome pour le détail complet.

Arbre de décision

Tes tâches ont-elles des dépendances entre elles ?
│
├── NON
│   └── As-tu besoin de fiabilité maximale (multi-perspectives) ?
│       ├── OUI → Consensual
│       └── NON → Parallel
│
└── OUI
    └── Le workflow a-t-il des branches conditionnelles ou des boucles ?
        │
        ├── NON
        │   └── As-tu besoin de contrôle qualité (revue manager) ?
        │       ├── OUI → Hierarchical
        │       └── NON → Sequential
        │
        └── OUI
            └── La stratégie optimale est-elle connue à l'avance ?
                ├── OUI → Graph (workflow modélisable)
                └── NON → Autonomous (exploration)

Combinaisons et complémentarité

Les ProcessTypes ne sont pas mutuellement exclusifs à l'échelle d'un système. Il est courant de combiner plusieurs stratégies :

Graph + FSM : Le Graph orchestre la Crew (niveau inter-tâches), tandis que la FSM gère l'exécution interne de chaque tâche (niveau intra-tâche). Les deux utilisent CircuitBreakerPolicy avec les mêmes presets.

Sequential + Hierarchical : Une Crew séquentielle peut contenir des tâches dont les agents utilisent DelegateWorkTool pour simuler un comportement hiérarchique local.

Autonomous + Graph : Un agent autonome peut décider de créer un sous-workflow Graph pour structurer une sous-tâche complexe qu'il a découverte dynamiquement.

Résumé des coûts et performances

ProcessType	Appels LLM (N tâches, M agents)	Latence	Prévisibilité
Sequential	N	Σ(durées)	⭐⭐⭐⭐⭐
Hierarchical	N × (1 assign + 1-3 reviews)	Σ(durées) × 1.5-3	⭐⭐⭐⭐
Parallel	N	max(durées)	⭐⭐⭐⭐
Consensual	N × M × rounds	Σ(max(durées) × rounds)	⭐⭐⭐
Graph	N × (1 + retries)	Variable	⭐⭐⭐
Autonomous	Imprévisible (budget-bounded)	Variable (wall-time bounded)	⭐⭐

Références croisées

Sujet	Document
Architecture et concepts de base	Vue d'ensemble
Fonctionnalités détaillées	YAML et Builders
Orchestration FSM (intra-tâche)	./fsm.md
Orchestration Graph (inter-tâches)	./graph.md
Orchestration Autonomous	./autonomous.md
Blueprint pour nouveau ProcessType	../../guides/blueprint.md

Table of Contents

Guide comparatif des ProcessTypes

Vue d'ensemble

Architecture d'implémentation

Matrice de comparaison rapide

1. Sequential — Pipeline linéaire

Principe

Mécanisme interne

Configuration YAML

Configuration Fluent Builder

Avantages

Inconvénients

Quand l'utiliser

Quand ne pas l'utiliser

2. Hierarchical — Manager + Workers

Principe

Mécanisme interne

Configuration YAML

Avantages

Inconvénients

Quand l'utiliser

Quand ne pas l'utiliser

3. Parallel — Exécution concurrente

Principe

Mécanisme interne

Configuration YAML

Avantages

Inconvénients

Quand l'utiliser

Quand ne pas l'utiliser

4. Consensual — Vote et consensus

Principe

Mécanisme interne

Types de consensus disponibles

Configuration (.NET, section Orkeon:Consensus)

Avantages

Inconvénients

Quand l'utiliser

Quand ne pas l'utiliser

5. Graph — Graphe d'états avec cycles contrôlés

Principe

Mécanisme interne

CrewGraphState — Propriétés de l'état

Circuit Breaker — 4 mécanismes de protection

Configuration YAML

Avantages

Inconvénients

Quand l'utiliser

Quand ne pas l'utiliser

6. Autonomous — Auto-organisation avec budget

Principe

Mécanisme interne

Budget multi-dimensionnel — 5 axes

Communication A2A

Configuration YAML

Avantages

Inconvénients

Quand l'utiliser

Quand ne pas l'utiliser

Arbre de décision

Combinaisons et complémentarité

Résumé des coûts et performances

Références croisées

Configuration (.NET, section `Orkeon:Consensus`)

`CrewGraphState` — Propriétés de l'état