Workflows agentiques : structurer un flow fiable
Créez des workflows agentiques fiables : séquentiel, parallèle ou supervisor, avec contrats, garde-fous et exemples OpenClaw actuels.
Introduction
Les workflows agentiques combinent des étapes déterministes avec des décisions confiées à un modèle. Ils deviennent utiles lorsqu’un flux doit choisir un outil, demander du contexte ou reprendre après une sortie incertaine. Ils ne justifient pas de transformer chaque fonction en agent. Ce guide montre comment choisir entre séquentiel, parallèle et supervisor, puis construire un exemple avec les surfaces actuelles d’OpenClaw : Gateway, agents, tools, skills et automations. OpenClaw n’est pas un SDK Python ; si votre pipeline tient dans un script court avec des règles stables, conservez ce script et ajoutez seulement un agent à l’endroit où le jugement apporte une valeur mesurable.
Résumé rapide
| Pattern | À choisir quand | Garde-fou indispensable |
|---|---|---|
| Séquentiel | Chaque étape dépend de la précédente | Contrat et checkpoint par étape |
| Parallèle | Les sous-tâches sont indépendantes | Limite de concurrence et déduplication |
| Fan-out / fan-in | Plusieurs analyses doivent être fusionnées | Agrégateur avec critères explicites |
| Supervisor | Le chemin dépend du contexte | Budget de handoffs et condition d’arrêt |
| Human-in-the-loop | L’action est coûteuse ou irréversible | Approbation liée à l’artefact exact |
Anatomie d'un workflow agentique
Un workflow fiable sépare cinq composants :
- Trigger : message, webhook, événement ou horaire.
- État : identifiant de run, artefacts, statut et checkpoints.
- Décision agentique : classification, planification ou synthèse lorsque des règles seules ne suffisent pas.
- Tools : actions déterministes et permissionnées sur des systèmes externes.
- Sortie : artefact validé, livraison et preuve d’exécution.
La différence avec un script n’est pas le nombre d’étapes. Un script suit un chemin décrit à l’avance ; une étape agentique choisit dans un espace borné à partir du contexte. Le reste devrait demeurer aussi déterministe que possible. Par exemple, le modèle peut classer un email, mais l’allowlist des destinataires, le schéma JSON et l’envoi doivent rester du code ou de la politique.
Chaque passage d’étape utilise un contrat. Un bon contrat contient runId, schemaVersion, données utiles, erreurs et statut. Il exclut le transcript complet et le raisonnement privé du modèle. Les artefacts durables permettent de reprendre sans répéter un effet externe.
OpenClaw fournit une façade pratique pour ces flux : son Gateway reçoit des messages depuis plusieurs canaux, maintient les sessions, charge les skills, expose des tools et exécute des automations persistées. Il peut piloter un workflow conversationnel, mais une transaction métier longue peut toujours nécessiter une queue ou un moteur externe. Pour décider du nombre de rôles, voyez les architectures multi-agents.
Construire le workflow et ses garde-fous
Choisir le pattern le plus simple
Séquentiel. Utilisez-le pour collecte → analyse → rapport. Chaque étape valide son entrée, écrit sa sortie et ne connaît que l’étape suivante. C’est le meilleur défaut : l’ordre est lisible et le replay ciblé.
Parallèle. Réservez-le aux tâches indépendantes, comme lire cinq sources. Fixez une concurrence maximale et un délai global. Deux branches ne doivent pas modifier le même enregistrement sans verrou ou clé d’idempotence.
Fan-out / fan-in. Il combine collecte parallèle et agrégation. L’agrégateur doit connaître les résultats manquants et ne jamais interpréter une branche absente comme un résultat négatif.
Supervisor. Un agent choisit le prochain spécialiste. Ce pattern est utile si le chemin varie fortement, mais il doit avoir une liste fermée de destinations, un nombre maximal de handoffs et une réponse terminale. Sinon, l’autonomous agent chain devient une boucle coûteuse.
Dessiner l’état avant les prompts
Commencez avec un objet indépendant du framework :
{
"schemaVersion": 1,
"runId": "inbox-2026-09-06T080000Z",
"status": "awaiting_approval",
"currentStep": "review",
"artifacts": {
"messages": "artifacts/messages.json",
"drafts": "artifacts/drafts.json"
},
"attempts": { "fetch": 1, "classify": 1, "draft": 1 },
"errors": []
}
Les transitions autorisées doivent être explicites. awaiting_approval ne peut aller que vers approved, rejected ou expired. Le modèle propose une transition ; l’application vérifie qu’elle est valide.
Installer OpenClaw sans faux SDK
Le chemin officiel sur Linux et macOS est :
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
openclaw doctor
openclaw gateway status --require-rpc
La configuration se trouve dans ~/.openclaw/openclaw.json. N’installez pas un prétendu SDK OpenClaw avec pip et n’importez pas de classe Agent depuis un module OpenClaw : ces exemples ne correspondent pas au produit actuel.
Décrire la procédure avec un skill
Un skill indique à l’agent comment conduire le flux avec les tools disponibles. Créez :
mkdir -p ~/.openclaw/workspace/skills/inbox-triage
Puis ~/.openclaw/workspace/skills/inbox-triage/SKILL.md :
---
name: inbox-triage
description: Trie les messages et prépare des brouillons sans les envoyer.
---
# Triage de boîte de réception
1. Lire uniquement les messages non traités fournis par le tool autorisé.
2. Classer chaque message en `urgent`, `action`, `information` ou `spam`.
3. Écrire un artefact JSON conforme au schéma `triage-v1`.
4. Préparer un brouillon seulement pour `urgent` et `action`.
5. Ne jamais envoyer, supprimer ou archiver sans approbation explicite.
Vérifiez :
openclaw skills list
openclaw agent --message "Utilise inbox-triage sur la fixture de test." --json
Un skill n’accorde aucune permission. La politique de tools doit autoriser la lecture et interdire l’envoi tant que l’approbation n’est pas reçue.
Déclencher avec une automation OpenClaw
Pour un triage quotidien :
openclaw automations add \
--name "Triage quotidien" \
--cron "0 8 * * 1-5" \
--tz "Europe/Paris" \
--session isolated \
--message "Applique le skill inbox-triage et prépare le lot pour approbation."
Les automations tournent dans le Gateway, persistent leurs jobs et leur historique dans l’état SQLite, et créent une tâche de fond par run. Le Gateway doit donc rester actif. Consultez les exécutions :
openclaw automations list
openclaw automations runs --id <job-id>
Pour un déclencheur externe, utilisez un webhook authentifié et routez-le vers un agent aux tools restreints. Le contenu d’un webhook est non fiable par défaut.
Bâtir les retries et l’idempotence
Un retry doit être borné, exponentiel et réservé aux erreurs transitoires. Ne réessayez pas une validation de schéma sans changer l’entrée. N’envoyez jamais deux fois un message parce que la réponse du premier envoi a été perdue.
Attribuez une clé d’idempotence à tout effet externe : runId + action + recipient. Avant l’action, vérifiez si cette clé est déjà enregistrée ; après succès, stockez la preuve. Si le transport de la CLI se coupe, consultez la session ou l’historique avant de relancer : le Gateway peut avoir accepté le run.
Ajouter l’approbation humaine au bon endroit
L’approbation protège l’artefact exact, pas une intention vague. Affichez destinataire, contenu, outils demandés et hash ou version de l’artefact. Toute modification après approbation invalide celle-ci.
Placez le contrôle juste avant l’effet irréversible : publication, email externe, dépense ou modification de production. Une approbation au début du workflow n’autorise pas automatiquement toutes les décisions prises ensuite.
Observer le workflow
Chaque run doit fournir : état courant, durée par étape, tentatives, outils invoqués, coût modèle, validation et statut de livraison. Dans OpenClaw, contrôlez au minimum :
openclaw gateway status --require-rpc
openclaw health --json
openclaw logs --follow
openclaw automations runs --id <job-id>
Pour les canaux, ajoutez openclaw channels status --probe. Une session existante ne prouve pas qu’un canal est connecté.
Tester avant la production
Préparez des fixtures pour : entrée vide, document malformé, tool lent, réponse hors schéma, branche parallèle absente, approbation expirée et double déclenchement. Vérifiez que le workflow s’arrête proprement, conserve les artefacts et n’exécute aucun effet externe en cas de doute.
Checklist :
- schémas validés hors LLM ;
- timeouts, concurrence, retries et handoffs bornés ;
- idempotence testée sur les actions externes ;
- approbation liée à une version d’artefact ;
- tools minimaux et contenu non fiable sandboxé ;
- historique et reprise testés après redémarrage du Gateway.
Exemple concret
Une PME reçoit cinquante messages par jour. À 8 h, l’automation ouvre une session isolée et demande le skill inbox-triage. Un tool de lecture retourne dix messages non traités ; il n’expose ni l’envoi ni la suppression. L’agent produit triage.json avec une catégorie, une justification courte et un niveau de confiance.
Le validateur rejette deux entrées sans identifiant. Le workflow relance uniquement la classification de ces deux messages, une fois. Il prépare ensuite trois brouillons, puis passe à awaiting_approval. Dans Slack, un responsable voit chaque destinataire et le texte exact. Il en approuve deux et rejette le troisième.
Un service déterministe vérifie la clé runId:send:messageId, envoie les deux réponses, puis stocke l’identifiant retourné par le fournisseur. Si le run est déclenché de nouveau, ces clés empêchent un doublon. L’opérateur vérifie ensuite :
openclaw automations runs --id <job-id>
openclaw channels status --probe
openclaw logs --follow
Le test de panne coupe le fournisseur après le premier envoi. La reprise détecte sa preuve, saute le premier message et tente seulement le second. Cet exemple démontre qu’un agent peut décider du contenu sans posséder seul l’autorité de l’envoyer.
Bonnes pratiques
Gardez le déterministe autour de l’agent : parsing, schémas, transitions, permissions et écritures finales. Confiez au modèle les tâches ambiguës comme classer, résumer ou choisir parmi une liste fermée.
Réduisez le contexte à chaque étape. Un artefact cité et versionné vaut mieux qu’un transcript complet. Les prompts courts facilitent aussi la comparaison de versions et la maîtrise des coûts.
Séparez les frontières de confiance. Dans OpenClaw, un Gateway convient à un propriétaire ou une équipe mutuellement fiable. Les agents ont des workspaces et sessions distincts, mais la sécurité dépend aussi du sandboxing, des tools et de la visibilité des sessions.
Enfin, mesurez le taux d’intervention humaine et les reprises. Si un supervisor choisit toujours le même chemin, remplacez-le par une transition déterministe. Si une étape échoue souvent, corrigez son contrat avant d’ajouter un agent de secours.
Questions fréquentes
Qu'est-ce qu'un workflow agentique ?
C’est un workflow où au moins une étape utilise un agent pour décider à partir du contexte, tandis que triggers, état, tools et sorties restent orchestrés. Un bon workflow agentique borne les choix, valide les résultats et conserve des checkpoints. Il ne s’agit pas simplement d’une suite de prompts.
Comment créer des workflows agentiques fiables ?
Définissez d’abord l’état et les contrats, choisissez le pattern le plus simple, puis ajoutez timeouts, retries, idempotence et approbations. Testez chaque étape sur des fixtures avant d’automatiser. En production, observez les artefacts, les tools invoqués et la livraison, pas seulement le texte final.
OpenClaw sert-il à orchestrer des workflows Python ?
OpenClaw peut piloter des agents, skills, tools et automations depuis son Gateway Node/TypeScript, mais ce n’est pas un SDK Python. Un tool peut appeler un service Python externe. Pour un graphe d’état applicatif Python avec checkpoints et transitions codées, un moteur comme LangGraph est généralement plus direct.
Quelle différence entre cron et automation OpenClaw ?
Les automations sont le scheduler intégré au Gateway. Elles persistent jobs, état et historique, et peuvent réveiller une session ou lancer un tour isolé. La CLI actuelle utilise openclaw automations; openclaw cron reste un alias. Les schedules ne se déclenchent que lorsque le Gateway fonctionne.
Quand utiliser un supervisor ?
Utilisez-le si le chemin varie réellement selon le contexte et si plusieurs spécialistes ont des frontières utiles. Fixez une liste de destinations, un budget de handoffs et une condition terminale. Si l’ordre est connu, un pipeline séquentiel sera plus lisible, moins cher et plus facile à reprendre.
Articles liés
Les workflows agentiques fiables combinent jugement local et contrôle déterministe. Commencez par un pipeline séquentiel, ajoutez l’idempotence et l’observabilité, puis adoptez le parallèle ou le supervisor seulement si les métriques le justifient. OpenClaw peut fournir la façade conversationnelle et le scheduler sans remplacer votre logique métier.
Restez informé sur les agents IA
Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.