Agents IA d'entreprise : OpenClaw pour les canaux, outils MCP personnalisés, runtime CLI Cursor

L'exécution d'agents IA en production pour la conformité, le DevOps et la finance exige plus que "donner l'accès à l'API au modèle et espérer." OpenClaw brut ne suffisait pas. Voici la recette d'entreprise qui fonctionne.

Un MCP ciblé, pas un MCP fournisseur

Les serveurs MCP génériques encapsulant les API des fournisseurs ne passent pas à l'échelle. Le modèle finit par faire du travail d'intégration : appeler un point d'accès, paginer, réessayer, gérer les erreurs, boucler 1000 fois. Exemple : exposer l'API BoldSign via MCP et laisser l'agent envoyer 1000 documents individuellement entraîne des hallucinations, des appels abandonnés et des lots partiels.

Ce qui fonctionne : un outil déterministe qui gère l'envoi par lots. L'agent décide quoi envoyer et quand ; l'outil fait la partie fiable et ennuyeuse. Même schéma pour Jira, Graph, les rapports de coûts. Construisez des outils MCP par processus, pas par API. L'IA rend la connexion d'une API à MCP quasiment gratuite.

Exemple avec l'API Microsoft Graph : les agents peuvent déployer des applications via Intune, configurer des politiques de sécurité, gérer des incidents, ajouter des indicateurs de sécurité, interroger les logs Sentinel, réinitialiser MFA et mots de passe utilisateur. Mais chaque processus nécessite des limitations détaillées et des frontières de privilèges — par exemple, il peut réinitialiser les identifiants sauf pour les administrateurs. Cela est appliqué via les outils et les paramètres, pas intégré dans le prompt.

OpenClaw pour les canaux, pas pour tout

OpenClaw gère Teams, webhooks, le routage et les sessions — cela a été conservé. Les identifiants restent hors du contexte du modèle. Chaque agent reçoit une liste d'outils restreinte. Une passerelle d'outils partagée unique remplace un processus MCP par agent.

Cursor CLI comme runtime via ACPX

La boucle d'agent proprement dite s'exécute sur cursor-agent et est connectée à OpenClaw via ACPX. Cursor CLI tient mieux le coup sur les tâches longues, le lancement de sous-agents et le maintien du cap que les boucles d'agent génériques. La tarification par niveau de modèle aide — certaines étapes tournent sur des modèles moins chers/plus rapides. Si OpenClaw s'améliore, la commutation est triviale puisque tout est déjà en place.

L'exécution du CLI fournit des logs détaillés de l'agent (réflexion interne, appels d'agent, etc.), renvoyés à un agent de boucle qualité qui détecte la dérive de cible, les hallucinations, etc., et propose des pull requests avec des correctifs dans les outils et les prompts.

Auto-hébergé et règles déterministes

Tout tourne en auto-hébergement dans Kubernetes. Le code de l'agent est immuable, intégré dans l'image, et testé en CI — le comportement de l'agent fait partie de la couverture de test. Les identités gérées dans Azure sont utilisées lorsque possible. Oubliez les agents "auto-apprenants" — fiez-vous à un bon système de mémoire plus des prompts, règles et outils déterministes et bien fondés.

1 agent = 1 backend

Les processus ont besoin d'un état bien pensé, déterministe et durable. Chaque agent reçoit, via son MCP, une API spécifique à la tâche. Construisez d'abord le "backend" pour l'agent (outillage déterministe et stockage de données), puis construisez l'agent par-dessus. N'attendez pas d'un agent qu'il fonctionne à long terme en opérant sur du YAML, des fichiers de balisage, ou ce qu'il improvise.