Pattern d'agents en cascade

Le pattern d’agents en cascade connecte deux types d’agents IA dans un workflow de détection-puis-correction. Un agent de surveillance toujours actif (comme OpenClaw) détecte un problème via une vérification planifiée ou un webhook. Si le problème nécessite des modifications de code, il déclenche un agent de code (comme Claude Code) pour investiguer et le corriger. L’agent de surveillance résume ensuite les résultats et les transmet à l’équipe.

Ce pattern est le mécanisme principal par lequel les couches d’une stack IA en couches communiquent entre elles.

Le flux

1. Le cron job OpenClaw détecte un problème
   (ex. test dbt en échec, pic de coût, alerte de fraîcheur)
        │
        ▼
2. OpenClaw effectue le triage
   Problème simple ? → Traiter directement (alerte, redémarrage, log)
   Nécessite du code ? → Déclencher une session Claude Code
        │
        ▼
3. Claude Code investigue
   Lit le contexte du projet (CLAUDE.md, SQL des modèles, lignage)
   Diagnostique la cause racine
   Propose et implémente une correction
   Exécute dbt build pour vérifier
        │
        ▼
4. Claude Code rapporte les résultats
        │
        ▼
5. OpenClaw résume et poste dans Slack
   "Le test X échouait à cause de Y. Correction appliquée dans la branche Z.
    dbt build passe. Prêt pour revue."

Le principe de conception clé est la clarté des frontières. L’agent de surveillance gère la détection et la livraison. L’agent de code gère l’investigation et la réparation. Aucun n’essaie de faire le travail de l’autre. OpenClaw n’écrit pas de SQL. Claude Code ne tourne pas sur un cron schedule.

Pourquoi deux agents plutôt qu’un

Un seul agent qui à la fois surveille et code serait plus simple architecturalement. La séparation existe pour des raisons pratiques :

Profils d’exécution différents. Un agent de surveillance doit être toujours actif, léger et peu coûteux. Il vérifie des choses périodiquement et dort entre les vérifications. Un agent de code a besoin d’un contexte profond, de calcul intensif et d’appels de modèles coûteux. Faire tourner un agent de code 24h/24 “au cas où” est un gaspillage. Le faire tourner à la demande quand il y a réellement un problème à résoudre est efficace.

Postures de sécurité différentes. L’agent de surveillance a besoin d’un accès en lecture aux entrepôts de production. L’agent de code a besoin d’un accès en écriture aux schémas de développement et de la capacité à créer des branches. Séparer ces périmètres limite le rayon d’explosion si l’un est compromis.

Modes de défaillance différents. Si l’agent de surveillance plante, vous manquez une alerte mais aucun changement de code ne se produit. Si l’agent de code plante en cours de correction, l’agent de surveillance peut rapporter l’échec. La séparation crée des frontières de défaillance naturelles.

La décision de triage

Tous les problèmes détectés ne doivent pas être cascadés vers un agent de code. La logique de triage dans l’agent de surveillance détermine le transfert :

Type de problème	Cascade ?	Pourquoi
Vérification de fraîcheur : table source obsolète	Non	Rien à corriger dans le code ; attendre l’upstream ou alerter l’équipe
Alerte de coût : pic de dépenses BigQuery	Non	Investiguer manuellement ; les pics de coûts ont souvent des causes hors code
Test dbt en échec : violation not_null	Parfois	Peut être un problème de données (pas de correction de code) ou un filtre manquant (correction de code)
Test dbt en échec : changement de schéma	Oui	Nécessite probablement des mises à jour des modèles pour gérer les colonnes nouvelles/supprimées
Échec de build : erreur de compilation	Oui	Nécessite définitivement une investigation du code
Anomalie : chute de volume détectée	Non	Alerter d’abord ; investiguer avant de supposer que le code est la correction

La valeur par défaut doit être conservative. La plupart des problèmes doivent alerter d’abord et cascader vers le code uniquement lorsqu’il y a une forte certitude qu’un changement de code est la bonne réponse. Un agent qui corrige automatiquement chaque test en échec créera autant de problèmes qu’il en résout — un test qui échoue ne signifie pas toujours que le code est incorrect. Parfois les données sont incorrectes, ou les attentes du test doivent être mises à jour, ou l’échec est transitoire.

Ce qui connecte les agents

Aujourd’hui, la connexion entre les agents de surveillance et de code est manuelle et quelque peu fragile. Il n’existe pas de protocole standard pour la communication agent-à-agent.

La solution de contournement par fichier Markdown. L’approche la plus pratique : l’agent de surveillance écrit ses findings dans un fichier Markdown dans le référentiel du projet. Le CLAUDE.md de l’agent de code référence ce fichier. Quand Claude Code démarre une session, il lit les findings nocturnes dans le cadre de son contexte de projet.

# .claude/overnight-findings.md (écrit par OpenClaw)

## 2026-03-26 07:00 UTC

### Tests en échec
- `mrt__sales__orders` : not_null sur `customer_id` — 3 lignes NULL détectées
- `int__ga4__sessions_attributed` : unique sur `session_id` — 12 doublons

### Statut du build
- Tous les modèles compilés avec succès
- Aucun changement de schéma détecté

# CLAUDE.md (extrait)
Avant de commencer le travail, vérifiez `.claude/overnight-findings.md` pour tout
problème détecté par l'agent de surveillance pendant la nuit.

Cela fonctionne pour le scénario le plus courant — “voici les tests qui ont échoué cette nuit, corrigez-les” — mais c’est fragile. Le format du fichier n’est pas standardisé. L’agent de code n’a aucun moyen d’indiquer quels findings il a traités. Il n’y a pas de boucle de rétroaction où l’agent de code rapporte sa résolution via le même canal.

Ce qui manque : un protocole de contexte partagé. La solution idéale serait quelque chose comme MCP mais pour la communication agent-à-agent — un protocole standard où un agent peut partager un contexte structuré avec un autre, incluant les descriptions de problèmes, les niveaux de priorité, les chemins de fichiers pertinents et le statut de résolution. Cela n’existe sous aucune forme standard aujourd’hui.

Les concepts émergents les plus proches sont les frameworks multi-agents (CrewAI, AutoGen, LangGraph), mais ils sont conçus pour des agents au sein du même runtime, pas pour des agents indépendants fonctionnant sur des machines différentes avec des contextes de sécurité différents. Le transfert d’agent de surveillance à agent de code est un problème de systèmes distribués, et les outils n’ont pas encore rattrapé leur retard.

Le fossé du contexte partagé

La plus grande limitation du pattern en cascade — et de toute stack IA multi-outils — est qu’il n’y a pas de mémoire partagée entre les outils.

Claude Code ne sait pas ce qu’OpenClaw a trouvé pendant la nuit
OpenClaw ne sait pas ce que vous avez construit dans Cursor pendant la journée
Cursor ne sait pas quels modèles Claude Code vient de refactoriser
Chaque outil démarre chaque session avec son propre contexte

Ce qui maintient les choses ensemble aujourd’hui, ce sont les fichiers de projet partagés : CLAUDE.md pour les conventions, dbt_project.yml pour la configuration, Git pour l’état du code, Slack pour la communication. Chaque outil peut indépendamment lire les mêmes fichiers et suivre les mêmes conventions. Ce n’est pas une couche de mémoire unifiée, mais cela fournit assez de coordination pour un travail pratique.

Le fossé devient le plus douloureux quand le contexte est sensible au temps. Les résultats de surveillance nocturne sont obsolètes au moment où vous démarrez une session Claude Code le matin. Un modèle que vous avez refactorisé dans Cursor à 15h n’est pas reflété dans l’exécution de tests d’OpenClaw à 7h si vous n’avez pas poussé les changements. Git aide, mais seulement si tout le monde (y compris les agents) commit et pull au bon moment.

Un système de compétences unifié

Un fossé connexe : chaque outil d’une stack en couches a son propre format pour les workflows réutilisables.

Claude Code utilise des Skills stockées comme fichiers Markdown dans .claude/commands/
OpenClaw utilise des Skills publiées sur ClawHub
Cursor utilise des règles stockées dans .cursorrules

Il n’y a pas de standard. Une skill écrite pour Claude Code ne peut pas être utilisée par OpenClaw ou Cursor. Une skill ClawHub ne peut pas être invoquée par Claude Code. Si vous voulez le même workflow “analyser les tests en échec et suggérer des corrections” entre les outils, vous l’écrivez trois fois dans trois formats.

Un format de skill unifié — ou au moins une couche de traduction entre les formats — rendrait le pattern d’agents en cascade plus puissant. L’agent de surveillance pourrait invoquer les mêmes skills que l’agent de code utilise, assurant la cohérence dans la façon dont les problèmes sont analysés et résolus. Cela n’existe pas aujourd’hui et n’est pas susceptible d’émerger bientôt, étant donné que chaque éditeur d’outil a des incitations à maintenir son propre écosystème.

Démarrer avec le pattern

Avec OpenClaw pour la surveillance et Claude Code pour le développement :

Configurez OpenClaw pour écrire les résultats des tests dans .claude/overnight-findings.md après chaque exécution planifiée
Ajoutez une ligne dans CLAUDE.md indiquant à Claude Code de lire ce fichier au démarrage de session
Chaque matin, démarrez une session Claude Code et vérifiez les findings nocturnes

Le déclencheur manuel (démarrer la session et donner l’instruction) est intentionnel. L’automatisation complète — OpenClaw déclenchant Claude Code sans intervention humaine — ne devrait suivre qu’après avoir validé que la logique de triage est fiable et que l’agent de code produit des corrections appropriées. Le gradient de confiance s’applique : commencez avec un humain dans la boucle et escaladez après avoir établi la confiance dans le système.