Concepts clés

Cette section explique les briques fondamentales de Mistral Workflows et comment elles s'articulent. Chaque brique dispose de sa propre page détaillée ; commencez ici pour avoir une vue d'ensemble.

Le modèle mental

Le modèle mental

Tout commence par la Workflows API : l'orchestrateur que vous appelez pour démarrer, interroger et signaler des runs. Pour le détail complet des endpoints, consultez la Référence API.

Votre code se trouve en dehors de l'API, dans les Workers : des processus que vous déployez, qui établissent des connexions sortantes vers l'API et en récupèrent le travail. Le code qu'exécute un worker se divise en deux :

  • Un Workflow est votre logique d'orchestration : du code déterministe qui décide quoi faire, dans quel ordre et comment traiter les résultats.
  • Les Activités sont les unités de travail réel que le workflow appelle : un appel à un LLM, une requête HTTP, une écriture en base de données, l'invocation d'un outil. C'est là que se produisent les effets de bord.

Le démarrage d'un workflow produit une Exécution : un run unique, avec son propre identifiant, son résultat et son historique d'Événements. Les événements consignent ce qui se produit pendant le run, comme started, activity completed ou signal received. Ils sont diffusés en temps réel aux clients et conservés dans l'historique de l'exécution.

Les Workers appartiennent à un Déploiement — un groupe nommé qui possède un ensemble de définitions de workflows et reçoit les exécutions correspondant à ces définitions.

Diagramme du modèle mental des Workflows
TermeDéfinition
Workflows APIL'orchestrateur. Le point d'entrée que vous appelez pour démarrer, interroger et signaler des runs.
WorkerUn processus que vous déployez, qui se connecte à l'API et exécute le code de vos workflows et de vos activités.
WorkflowLa logique d'orchestration. Définit ce qui se produit, dans quel ordre et comment traiter les résultats. Déterministe (le réexécuter produit toujours le même plan à partir du même historique).
ActivitéUne unité de travail réel que le workflow appelle, comme un appel à un LLM, une requête HTTP, une écriture en base de données ou l'exécution d'un outil. L'endroit où se produisent les effets de bord.
ExécutionUn run unique d'un workflow. Possède un identifiant unique, un historique d'événements et un résultat.
ÉvénementUne trace de ce qui s'est produit pendant une exécution, comme started, activity completed ou signal received. Diffusée en temps réel et conservée dans l'historique.
DéploiementUn groupe nommé de workers qui partage des définitions de workflows et reçoit les exécutions routées vers ces définitions.
Comment tout s'articule

Comment tout s'articule

Un run type se déroule comme suit :

  1. Un client (votre code, Studio, Vibe Work ou une planification) appelle la Workflows API pour démarrer une exécution.
  2. L'orchestrateur enregistre la requête sous forme d'événement et la route vers le bon déploiement.
  3. Un worker de ce déploiement récupère la tâche, instancie la classe de workflow et exécute le point d'entrée.
  4. Le workflow appelle des activités. Chaque appel d'activité devient une tâche ; n'importe quel worker du déploiement peut la récupérer et l'exécuter.
  5. Chaque étape est enregistrée sous forme d'événement dans l'historique de l'exécution. Les clients peuvent suivre les événements en direct ou consulter l'historique plus tard.
  6. Si un worker tombe en panne en cours de run, un autre worker reprend à partir de l'historique enregistré. L'exécution survit.

L'orchestrateur ne détient jamais votre code — il se contente de distribuer les tâches. Les Workers détiennent votre code et établissent des connexions sortantes. C'est pourquoi les workflows peuvent s'exécuter dans votre réseau privé, sans trafic entrant en provenance de la plateforme.

Aller plus loin

Aller plus loin

Une fois le modèle assimilé, explorez chaque brique :

  • Workflows — logique d'orchestration, déterminisme, rejeu.
  • Activités — unités de travail, nouvelles tentatives, battements de cœur.
  • Exécutions — cycle de vie, statuts, exécutions et runs.
  • Événements — historique des événements, rejeu, streaming.
  • Workers — modèle de processus, enregistrement, tolérance aux pannes.
  • Déploiements — regroupement de workers, isolation, mise à l'échelle.

Pour voir ces briques sous forme de graphe d'activités, de branches et de flux de données, visualisez votre workflow dans Studio.