Workflows IA : Skills, Cron Jobs & Outils MCP dans OpenClaw

Tout ce que nous avons appris en construisant 13 cron jobs, 78 outils MCP et des skills de production dans OpenClaw. Exemples prêts à copier, patterns réels et leçons tirées de workflows IA autonomes.

Workflows IA : Skills, Cron Jobs & Outils MCP dans OpenClaw

Construisez vos propres workflows IA : Skills, Cron Jobs) & Outils MCP personnalisés dans OpenClaw

La plupart des gens utilisent les agents IA comme des chatbots améliorés. Vous tapez, il répond, peut-être qu'il cherche sur le web. Sympa, mais c'est comme acheter une voiture de sport et ne l'utiliser que pour aller au supermarché.

Voici ce que nous faisons vraiment : nous exploitons 13 cron jobs, 78 outils MCP personnalisés et plusieurs skills en production. Notre agent publie des articles de blog en quatre langues, gère l'engagement sur les réseaux sociaux, surveille notre boîte mail, génère des images brandées et pilote des pipelines de contenu — le tout de manière autonome. Chaque jour.

Ce n'est pas un guide de démarrage. Pour ça, lisez notre Guide complet OpenClaw. Cet article traite de la construction d'automatisations réelles. Vous repartirez avec des exemples prêts à copier-coller pour les skills, les cron jobs et les outils MCP personnalisés — ainsi que les leçons que nous avons tirées de leur mise en production.

C'est parti.


1. Skills — Enseigner de nouveaux tours à votre agent

Un skill dans OpenClaw est d'une simplicité trompeuse : c'est un fichier Markdown avec un frontmatter YAML. C'est tout. Pas de SDK spécial, pas d'étape de compilation, pas de pipeline de déploiement. Vous écrivez un fichier SKILL.md, vous le placez dans le bon répertoire, et votre agent sait soudainement faire quelque chose de nouveau.

Anatomie d'un skill

~/.openclaw/workspace/skills/my-skill/
├── SKILL.md          # Obligatoire : instructions + frontmatter
├── reference/        # Optionnel : documentation supplémentaire
│   └── api-docs.md
└── scripts/          # Optionnel : scripts utilitaires
    └── validate.sh

Le frontmatter du SKILL.md indique à OpenClaw ce qu'est le skill. Le corps indique à l'agent comment l'utiliser. Voici un exemple réel — une version simplifiée de notre skill de publication de contenu :

---
name: content-publisher
description: Publier des articles de blog et du contenu social media via les outils MCP.
---

# Content Publisher Skill

## Quand utiliser
- L'utilisateur demande de publier un article de blog
- L'utilisateur veut créer du contenu pour les réseaux sociaux

## Workflow
1. Rechercher le sujet avec `web_search`
2. Générer des mots-clés avec l'outil MCP `generate_keywords`
3. Rédiger le contenu en suivant les guidelines SEO
4. Générer l'image hero
5. Publier dans le CMS
6. Diffuser sur les réseaux sociaux

## Règles importantes
- TOUJOURS vérifier que l'URL du blog retourne 200 avant de poster sur les réseaux
- Inclure l'image hero dans TOUS les posts sociaux
- Écrire dans la langue spécifiée — ne pas mélanger les langues
- Les posts sur les réseaux sociaux partent en ANGLAIS avec l'URL du blog anglais

La priorité compte

OpenClaw charge les skills depuis trois emplacements, dans cet ordre :

  1. Workspace (~/.openclaw/workspace/skills/) — vos skills personnalisés, priorité maximale
  2. Managed — skills installés via ClawHub
  3. Bundled — skills intégrés livrés avec OpenClaw

Cela signifie que vous pouvez remplacer n'importe quel skill intégré en créant un skill du même nom dans votre workspace. Nous l'avons fait pour personnaliser le skill de navigation web intégré avec nos flux de connexion spécifiques.

Bonnes pratiques (apprises à la dure)

Soyez directif. N'écrivez pas « envisagez d'utiliser web_search si approprié. » Écrivez « TOUJOURS rechercher le sujet avec web_search avant de rédiger. » L'agent performe mieux avec des directives claires.

Incluez des garde-fous. Notre skill de contenu a une règle : « TOUJOURS vérifier que l'URL du blog retourne 200 avant de poster sur les réseaux. » Nous l'avons ajoutée après que l'agent a posté des liens cassés sur Twitter. Deux fois.

Restez concis. Les skills sont injectés dans la fenêtre de contexte du LLM. Un skill de 5 000 mots consume des tokens et embrouille le modèle. Nos skills les plus efficaces font moins de 500 mots.

Ajoutez une section « Quand utiliser ». Cela aide le routage des skills d'OpenClaw à décider quand activer le skill. Sans elle, l'agent pourrait charger votre skill quand il n'en a pas besoin.

Astuce : Les skills sont simplement des prompts structurés — le LLM les lit comme du contexte. Voyez-les comme du « savoir expert à la demande ». L'agent n'exécute pas le skill comme du code ; il lit le skill et suit les instructions selon son propre jugement. C'est puissant : vous pouvez encoder des workflows complexes en langage naturel.


2. Cron Jobs — Le battement de cœur de votre agent

Si les skills donnent à votre agent le savoir, les cron jobs lui donnent un planning. OpenClaw dispose d'un scheduler intégré qui persiste à travers les redémarrages — pas de daemon cron externe, pas de timers systemd, pas de service de planification tiers. Vous définissez un job, et OpenClaw se réveille et l'exécute à l'heure.

Deux modes d'exécution

C'est ici que ça devient intéressant. Les cron jobs peuvent fonctionner selon deux modes :

systemEvent — Injecte un message dans votre session principale. L'agent le voit comme une notification et peut répondre en contexte. Idéal pour les rappels et les vérifications qui bénéficient de l'historique de conversation.

agentTurn — Lance une session isolée. L'agent se réveille, fait le travail et se rendort. Pas d'historique de conversation, pas d'interférence avec votre chat principal. C'est ce que vous voulez pour les workflows autonomes.

Exemple 1 : Rappel simple

{
  "name": "Daily Standup Reminder",
  "schedule": {
    "kind": "cron",
    "expr": "0 9 * * 1-5",
    "tz": "Europe/Berlin"
  },
  "payload": {
    "kind": "systemEvent",
    "text": "Rappel : Vérifier les emails et le calendrier pour les réunions du jour."
  },
  "sessionTarget": "main"
}

Cela se déclenche du lundi au vendredi à 9h00 heure de Berlin. Un rappel arrive dans votre session principale, et l'agent peut alors vérifier votre boîte mail et calendrier avec ses outils disponibles.

Exemple 2 : Pipeline d'engagement autonome

Voici à quoi ressemble un vrai cron job de production — notre engagement matinal sur les réseaux sociaux :

{
  "name": "Social Media Engagement",
  "schedule": {
    "kind": "cron",
    "expr": "0 10 * * *",
    "tz": "Europe/Berlin"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "Run the EU morning engagement round. Read memory/daily-intel.md for today's news. Find trending posts on X and LinkedIn. Reply to 5-8 posts with genuine, specific comments. Log results to memory/engagement-log.md.",
    "model": "anthropic/claude-opus-4-6"
  },
  "sessionTarget": "isolated",
  "delivery": {
    "mode": "announce"
  }
}

Remarquez quelques points :

  • sessionTarget: "isolated" — S'exécute dans sa propre session. Ne pollue pas votre chat principal avec des logs d'engagement.
  • model est explicite — Nous spécifions le modèle car les defaults peuvent changer. Vous ne voulez pas que votre pipeline complexe tourne soudainement sur un modèle plus petit.
  • delivery.mode: "announce" — Quand le job est terminé, OpenClaw envoie un résumé dans votre session principale. Vous restez informé sans être dans la boucle.

Cron vs. Heartbeat

OpenClaw a aussi un système de heartbeat — un poll périodique qui vérifie si quelque chose nécessite attention. Quand utiliser quoi ?

Cron quandHeartbeat quand
Le timing exact compte (« 9h tapantes »)Plusieurs vérifications peuvent être groupées
La tâche nécessite une isolationVous avez besoin du contexte conversationnel
Vous voulez un modèle spécifiqueLe timing peut fluctuer (~30 min)
Planifications ponctuelles ou récurrentesVous voulez réduire les appels API

Leçons apprises

Ne lancez pas de sous-agents depuis les cron jobs. Nous avons essayé de faire spawner des sous-agents par notre cron job d'engagement pour du traitement parallèle. Ils ont perdu le contexte, dupliqué le travail et ont parfois répondu au même tweet deux fois. Gardez les cron jobs autonomes.

Spécifiez toujours le modèle explicitement. Notre pipeline de contenu a un jour tourné sur un modèle plus petit parce que nous avions fait confiance au default. La qualité a notablement baissé, et nous ne l'avons pas remarqué pendant deux jours.

Utilisez les fichiers memory/ pour l'état. Les cron jobs en sessions isolées ne voient pas votre historique de conversation. À la place, nous lisons et écrivons dans des fichiers du répertoire memory/. Le job d'engagement lit daily-intel.md et écrit dans engagement-log.md. Les fichiers sont la couche d'état partagée.


3. Outils MCP personnalisés — Donnez des mains à votre agent

Les skills donnent le savoir. Le cron donne le planning. Les outils MCP donnent à votre agent la capacité de vraiment faire des choses dans le monde réel.

Qu'est-ce que MCP ?

MCP (Model Context Protocol) est un standard ouvert pour connecter des modèles IA à des outils et sources de données externes. Voyez-le comme un système de plugins universel : vous définissez des outils avec un nom, une description et un schéma d'entrée, et tout client compatible MCP (comme OpenClaw) peut les découvrir et les utiliser.

Pourquoi construire des outils personnalisés ?

Par défaut, OpenClaw vous offre la recherche web, les opérations fichier, le contrôle de navigateur et plus encore. Mais tôt ou tard, vous aurez besoin d'actions spécifiques à votre domaine :

  • Publier dans votre CMS
  • Générer des images brandées à partir de templates
  • Interroger votre base de données interne
  • Déclencher des pipelines CI/CD
  • Poster sur les réseaux sociaux avec votre compte de marque

C'est là qu'interviennent les outils MCP personnalisés.

Architecture : Monolithe vs. Microservices

Nous avons commencé avec l'idée de serveurs MCP séparés pour différents domaines — un pour la gestion du blog, un pour la génération d'images, un pour les réseaux sociaux. Après deux semaines, nous avons tout consolidé en un seul serveur avec 78 outils.

Pourquoi ? Raisons pratiques :

  1. Moins de connexions à gérer — OpenClaw se connecte à un serveur, pas dix
  2. Authentification partagée — Une clé API, un flux d'auth
  3. Utilitaires partagés — Upload d'images, gestion d'erreurs, logging — tout réutilisable
  4. Déploiement simplifié — Un projet Vercel, un jeu de variables d'environnement

L'inconvénient est une base de code plus grande, mais pour notre échelle (78 outils), c'est très gérable.

Exemple réel : Construire un générateur d'images hero

Voici une version simplifiée de notre outil d'images hero réel. Il prend des métadonnées d'article, rend un template HTML avec Puppeteer et upload la capture d'écran :

const generateHeroImage: Tool = {
  name: "generate_hero_image",
  description: "Génère une image hero brandée à partir de templates HTML. Accepte le type d'article, le titre, des logos optionnels et une couleur d'accent. Retourne une URL vers l'image uploadée.",
  inputSchema: {
    type: "object",
    properties: {
      type: {
        type: "string",
        enum: ["product-launch", "tutorial", "comparison", "news"],
        description: "Type de template — détermine le layout et le style"
      },
      title: {
        type: "string",
        description: "Titre de l'article à afficher sur l'image"
      },
      logos: {
        type: "array",
        items: { type: "string" },
        description: "IDs de logos depuis le registre (ex. 'openclaw', 'vercel')"
      },
      accentColor: {
        type: "string",
        description: "Couleur hex pour le theming de marque (default: #3B82F6)"
      }
    },
    required: ["type", "title"]
  },
  handler: async (args) => {
    // 1. Charger le template HTML pour le type donné
    const template = await loadTemplate(args.type);

    // 2. Injecter les données — titre, logos, couleurs
    const html = renderTemplate(template, {
      title: args.title,
      logos: await resolveLogos(args.logos || []),
      accentColor: args.accentColor || "#3B82F6"
    });

    // 3. Capture avec Puppeteer (1200x630 pour le partage social)
    const screenshot = await puppeteerScreenshot(html, {
      width: 1200, height: 630
    });

    // 4. Upload vers le stockage
    const url = await uploadToStorage(screenshot, "hero-images");

    // 5. Retourner des données structurées
    return {
      success: true,
      url: url,
      dimensions: { width: 1200, height: 630 }
    };
  }
};

Les descriptions d'outils sont primordiales

Voici quelque chose qui n'est pas évident : le LLM lit vos descriptions d'outils pour décider quel outil appeler. Une description vague comme « génère des images » fera appeler votre outil pour de mauvaises raisons. Une description spécifique comme « Génère une image hero brandée à partir de templates HTML. Accepte le type d'article, le titre, des logos optionnels et une couleur d'accent. » — c'est ce qui fait que l'agent l'utilise correctement.

Nous avons passé plus de temps à affiner les descriptions d'outils qu'à écrire la logique réelle des outils. Ça en vaut la peine.

Retournez des données structurées, pas de la prose

Au début, nos outils retournaient des messages comme « Image générée avec succès à https://... ». L'agent devait ensuite parser cette chaîne pour extraire l'URL. Maintenant nous retournons du JSON structuré :

{
  "success": true,
  "url": "https://storage.example.com/hero-images/abc123.png",
  "dimensions": { "width": 1200, "height": 630 }
}

L'agent peut utiliser l'URL directement dans les appels d'outils suivants. Pas de parsing, pas d'ambiguïté.

Tester avec mcporter

OpenClaw inclut mcporter, un outil CLI pour tester les serveurs MCP directement :

mcporter call myserver.generate_hero_image \
  type="tutorial" \
  title="Mon article" \
  logos='["openclaw"]' \
  accentColor="#EF4444"

C'est inestimable pendant le développement. Vous pouvez tester des outils sans passer par la boucle complète de l'agent — itération plus rapide, débogage plus facile.


4. Tout assembler

C'est ici que la magie opère. Aucune de ces pièces n'est impressionnante seule. Un fichier Markdown ? Une expression cron ? Un schéma JSON ? Et alors. Mais composées ensemble, elles transforment votre agent de chatbot en collaborateur autonome.

Notre pipeline de contenu matinal

Voici comment fonctionne notre véritable pipeline de production, chaque matin :

  1. 06:00 — Un cron job déclenche un agent turn isolé
  2. L'agent lit le skill de contenu — Il connaît maintenant le workflow complet de publication : recherche → rédaction → image → publication → social
  3. Recherche les news tendance via les outils MCP de recherche — research_topic, search_knowledge_base
  4. Génère des propositions de sujets avec des mots-clés SEO de generate_keywords
  5. Crée une image hero via notre outil MCP basé sur des templates
  6. Envoie les propositions sur Telegram avec des boutons inline — « Approuver », « Modifier » ou « Passer »
  7. Sur approbation — Rédige le post en 4 langues (EN, DE, FR, IT), publie toutes les versions, génère les posts sociaux et diffuse sur X, LinkedIn et Facebook

L'ensemble de la pipeline — du déclenchement cron au post de blog publié et promu — prend environ 8 minutes. Sans intervention humaine (sauf si nous voulons relire).

Le pattern de composition

Pensez-y comme trois couches :

  • Skills = Savoir (« voici comment publier un article de blog »)
  • Cron = Planning (« fais-le chaque matin à 6h »)
  • Outils MCP = Actions (« voici comment créer le post, générer l'image, publier dans le CMS »)

Chaque couche seule est utile. Les trois ensemble créent des workflows autonomes qui fonctionnent réellement.

Ce que nous ferions différemment

Si nous recommencions :

  1. Commencer avec un skill, un cron job, un outil MCP. Faire fonctionner la boucle de bout en bout avant de monter en charge. Nous avons construit 30 outils avant de tester la pipeline complète et avons dû en réécrire la moitié.
  2. Tout logger dans des fichiers. L'historique de conversation est compressé. Les fichiers persistent. Chaque étape de pipeline devrait écrire sa sortie sur disque.
  3. Utiliser des sessions isolées pour les cron jobs dès le premier jour. Nous avons commencé avec des événements en session principale et l'avons vite regretté — le chat est devenu bruyant.

Et ensuite

OpenClaw est encore jeune, et l'écosystème grandit. ClawHub devient un dépôt communautaire pour les skills — vous pouvez partager les vôtres et utiliser ceux des autres. La documentation OpenClaw contient des références détaillées pour tout ce qui a été couvert ici.

Si vous voulez l'histoire complète de la mise en production — comment nous configurons OpenClaw, gérons les workflows multi-agents et gérons l'automatisation du navigateur — consultez notre Guide complet OpenClaw.

Toutes les pièces sont là. Les skills pour le savoir, le cron pour la planification, les outils MCP pour les actions. Qu'allez-vous construire ?

Contactez-nous chez Context Studios ou trouvez-nous sur X @_contextstudios.

Partager l'article

Share: