Limitations de la plateforme
Connaître les limites
La plateforme Workflows de Mistral est en Public Preview (avril 2026). Comme tout système d’orchestration, elle impose des limitations techniques qu’il est essentiel de connaître pour concevoir des workflows robustes. Ignorer ces limites conduit à des erreurs en production difficiles à diagnostiquer.
Vue d’ensemble des limitations
| Limitation | Valeur | Conséquence si dépassée |
|---|---|---|
| Délai entre activités | 2 secondes | Latence incompressible entre chaque appel d'activité |
| Input/output par invocation | 2 MB | Erreur de sérialisation, workflow échoue |
| Événements par exécution | 51 200 | Workflow terminé de force |
| Taille totale par exécution | 50 MB | Workflow terminé de force |
| Timeout par défaut | 1 heure | Workflow annulé (configurable jusqu'à 7 jours) |
| Timeout maximum | 7 jours | Workflow annulé automatiquement |
| I/O dans les workflows | Interdit | Erreur de non-déterminisme lors du replay |
Le délai de 2 secondes entre activités
La plateforme impose un délai minimum de 2 secondes entre chaque appel d’activité dans un workflow. Cette latence est inhérente à l’architecture d’orchestration (persistance de chaque événement).
Impact concret
Si votre workflow enchaîne 10 activités séquentielles, le temps d’orchestration minimal est de 10 x 2 = 20 secondes, indépendamment de la durée des activités elles-mêmes.
Comment optimiser
Regroupez les opérations logiquement liées dans une seule activité plutôt que de les séparer :
# SOUS-OPTIMAL : 3 activités = 6 secondes de latence d'orchestration
@workflows.workflow.define(name="pipeline_lent")
class PipelineLent:
@workflows.workflow.entrypoint
async def run(self, texte: str) -> dict:
tokens = await tokeniser(texte)
embeddings = await calculer_embeddings(tokens)
clusters = await clusteriser(embeddings)
return clusters
# OPTIMISÉ : 1 activité = 2 secondes de latence d'orchestration
@workflows.activity()
async def traitement_nlp_complet(texte: str) -> dict:
tokens = tokeniser_local(texte)
embeddings = calculer_embeddings_local(tokens)
clusters = clusteriser_local(embeddings)
return {"clusters": clusters}
@workflows.workflow.define(name="pipeline_rapide")
class PipelineRapide:
@workflows.workflow.entrypoint
async def run(self, texte: str) -> dict:
return await traitement_nlp_complet(texte)La règle est simple : ne créez une activité séparée que si vous avez besoin de la garantie de persistance entre deux opérations. Si deux opérations peuvent échouer ensemble sans problème, regroupez-les.
La limite de 2 MB par invocation
Chaque appel d’activité est limité à 2 MB en entrée et 2 MB en sortie. Cette limite s’applique à la représentation JSON sérialisée des données.
Comment contourner cette limite
Pour les données volumineuses, utilisez un stockage externe :
@workflows.activity()
async def traiter_gros_fichier(fichier_url: str) -> dict:
"""Télécharge, traite et re-upload le fichier.
Seules les URLs transitent par le workflow."""
async with httpx.AsyncClient() as client:
# Télécharger depuis S3/GCS
response = await client.get(fichier_url)
contenu = response.content # Peut faire 100 MB
# Traiter le fichier
resultat = traiter(contenu)
# Uploader le résultat
await client.put(
"https://storage.example.com/resultats/output.json",
content=resultat
)
return {"url_resultat": "https://storage.example.com/resultats/output.json"}La limite de 51 200 événements
Chaque exécution de workflow est limitée à 51 200 événements. Un événement est généré pour chaque :
- Démarrage d’activité
- Complétion d’activité
- Signal reçu
- Timer déclenché
Estimation du nombre d’événements
En pratique, chaque appel d’activité génère environ 2-3 événements (démarrage + complétion + métadonnées). Un workflow avec 100 activités consomme environ 250-300 événements.
La limite de 51 200 événements permet donc environ 15 000 à 20 000 appels d’activité par exécution, ce qui est largement suffisant pour la plupart des cas d’usage.
Si vous approchez la limite
Pour les workflows très longs (par exemple, traiter 50 000 documents), utilisez le pattern de continuation : le workflow traite un lot, puis lance un nouveau workflow pour le lot suivant.
La limite de 50 MB par exécution
La taille totale de tous les événements d’une exécution ne doit pas dépasser 50 MB. Cette limite est atteinte plus facilement si vos activités retournent des données volumineuses.
Comment rester sous la limite
- Retournez des identifiants plutôt que des données complètes
- Stockez les résultats intermédiaires dans un service externe
- Utilisez la pagination pour les traitements en lots
Pas d’I/O dans les workflows
C’est à la fois une limitation technique et une règle de conception. Le code du workflow ne doit contenir aucune opération d’entrée/sortie :
- Pas d’appels réseau (
httpx,aiohttp,requests) - Pas de lecture/écriture de fichiers (
open,aiofiles) - Pas d’accès base de données
- Pas d’accès aux variables d’environnement pour des branchements
Toutes ces opérations doivent être encapsulées dans des activités.
Points clés à retenir
- 2 secondes de latence minimum entre chaque activité — regroupez les opérations liées
- 2 MB maximum par input/output d’activité — utilisez un stockage externe pour les données volumineuses
- 51 200 événements et 50 MB maximum par exécution — utilisez le pattern de continuation pour les très longs workflows
- Aucune I/O dans le code du workflow — tout va dans les activités
- Ces limitations sont liées à l’architecture Temporal sous-jacente et à la Public Preview