Expérience pratique de remplacement de la pile d'automation par des serveurs MCP et des LLM locaux

Configuration et matériel

Le développeur utilise un mélange de Qwen 2.5 32B (quantifié) et Llama 3.3 70B sur une configuration à double 3090. Chaque tâche d'automatisation dispose de son propre serveur MCP qui expose des outils que le modèle peut appeler, fonctionnant comme une API consommée par un LLM plutôt que par un humain.

Ce qui fonctionne bien

• Automatisation de la revue de code : Pointer le modèle vers un diff git via les outils MCP permet de détecter de vrais problèmes, y compris des bugs logiques, une gestion d'erreurs manquante et des conditions de concurrence. Fonctionne à environ 70 % de l'efficacité d'une revue par un développeur senior.
• Analyse des logs et alerte : Le serveur MCP se connecte à la pile ELK, avec le modèle surveillant les motifs d'anomalies. Il a détecté 3 problèmes de production avant que les alertes Grafana ne se déclenchent. La clé est de fournir suffisamment de contexte sur ce qui est "normal" pour votre système.
• Génération de documentation : Le modèle lit la base de code via les outils de fichiers MCP et génère/mets à jour la documentation API, économisant des heures par semaine avec une qualité de sortie vraiment bonne.

Ce qui ne fonctionne pas (encore)

• Chaînes de raisonnement multi-étapes : Tout ce qui nécessite plus de 3-4 appels d'outils en séquence commence à dérailler car le modèle perd le contexte de l'objectif initial. Des fenêtres de contexte plus petites aggravent ce problème. L'incitation à la chaîne de pensée aide mais ne le résout pas.
• Prise de décision en temps réel : La latence sur les modèles 70B signifie que cela ne peut pas être utilisé pour des tâches sensibles au temps. Le pipeline de revue de code prend 2-3 minutes par PR, ce qui le rend adapté aux workflows asynchrones mais inutile pour les applications en temps réel.
• Résolution créative de problèmes : Les modèles locaux ont du mal avec les tâches nécessitant des approches peu représentées dans les données d'entraînement. Les modèles API (Claude, GPT-4) sont nettement meilleurs ici.

Leçons architecturales clés

• Gardez les serveurs MCP sans état. Laissez le modèle gérer l'état via les appels d'outils, pas via une session côté serveur.
• Intégrez la logique de réessai dans votre client MCP, pas dans le serveur. Les modèles feront des appels d'outils malformés environ 5 % du temps.
• Enregistrez chaque appel d'outil et réponse pour déboguer lorsque le modèle fait quelque chose d'inattendu.
• Utilisez une sortie structurée (mode JSON) pour tout ce que les systèmes en aval consomment. La sortie en texte libre est un cauchemar de débogage.