↓ Aller au contenu
Mornati Blog
  1. Posts/

Des outils aux agents : L'évolution de Nexus-Dev

·1324 mots·7 mins· loading · loading · ·
Marco Mornati
Auteur
Marco Mornati
Je construis, j’héberge et casse parfois des logiciels en production — en écrivant sur l’IA, les agents de code et l’infrastructure.
Sommaire

Si vous avez joué avec le Model Context Protocol (MCP) récemment, vous avez probablement ressenti le pouvoir de donner à votre LLM des outils explicites. Pouvoir dire “Hé Claude, cherche dans mon code” ou “Hé assistant, redémarre le serveur” est magique. Cela transforme un chatbot en centre de commande.

Mais après avoir utilisé MCP sur de vrais projets pendant un moment, j’ai atteint un mur. Les outils sont excellents, mais ils sont passifs. Ils attendent que vous pilotiez. Je ne voulais pas juste un CLI plus intelligent ; je voulais un pair programmeur. Je voulais des Agents.

Aujourd’hui, je suis ravi de partager une mise à jour majeure de Nexus-Dev qui apporte de vrais agents IA configurables à votre IDE, alimentés par le protocole MCP.

Outils vs. Agents : Quelle est la différence ?
#

Avant de nous plonger dans l’implémentation, clarifions ce changement.

Un Outil est une fonction sans état. readFile(path) est un outil. Il fait exactement une chose quand on le demande. Un Agent est un système avec un Objectif, une Persona et une Mémoire.

Andrew Ng a souligné dès 2024 le pouvoir des “workflows agentiques” : où une IA itérativement planifie, exécute et critique son propre travail. Deux ans plus tard, ce n’est plus juste une théorie ; c’est ainsi que nous construisons les logiciels. Gartner prédit maintenant que 40% des applications d’entreprise intégreront des agents IA spécifiques d’ici 2026, et nous voyons cela se dérouler en temps réel.

Dans Nexus-Dev, nous passons de :

Utilisateur : “Trouve le fichier auth.py. Maintenant lis-le. Maintenant trouve la fonction login. Maintenant explique-la.”

À :

Utilisateur : “Demande au Auditeur Sécurité de revoir le flux d’authentification.”

Introduction des agents dynamiques
#

Avec la dernière version, Nexus-Dev scanne votre projet pour un répertoire agents/. À l’intérieur, vous pouvez définir vos propres membres d’équipe IA spécialisés en utilisant de simples fichiers YAML.

Voici à quoi agents/code_reviewer.yaml pourrait ressembler :

name: "code_reviewer"
display_name: "Code Reviewer"
description: "Déléguer les tâches de revue de code à l'agent Code Reviewer."

profile:
  role: "Senior Code Reviewer"
  goal: "Identifier les bugs, problèmes de sécurité et suggérer des améliorations"
  backstory: "Expert développeur avec 10+ ans d'expérience en qualité de code."
  tone: "Professionnel et constructif"

memory:
  enabled: true
  rag_limit: 5
  search_types: ["code", "documentation", "lesson"]

Quand vous démarrez votre IDE, Nexus-Dev enregistre automatiquement un nouvel outil MCP appelé ask_code_reviewer. Quand vous l’invoquez, le serveur instantie cette persona spécifique, charge son contexte mémoire spécifique et exécute la tâche.

Commencer avec les modèles
#

Vous n’avez pas besoin de les écrire from scratch. Nous avons ajouté une commande CLI pour les générer à partir de modèles de bonnes pratiques :

# Lister les modèles disponibles
nexus-agent templates
📋 Available Agent Templates:

  • API Designer (api_designer)
    Role: API Architect
    Model: claude-sonnet-4.5

  • Code Reviewer (code_reviewer)
    Role: Senior Code Reviewer
    Model: claude-sonnet-4.5

  • Debug Detective (debug_detective)
    Role: Debugging Specialist
    Model: claude-sonnet-4.5

  • Documentation Writer (doc_writer)
    Role: Technical Writer
    Model: claude-opus-4.5

  • Performance Optimizer (performance_optimizer)
    Role: Performance Engineer
    Model: gemini-3-pro

  • Refactor Architect (refactor_architect)
    Role: Refactoring Expert
    Model: gemini-3-deep-think

  • Security Auditor (security_auditor)
    Role: Security Analyst
    Model: claude-opus-4.5

  • Test Engineer (test_engineer)
    Role: QA Engineer
    Model: gpt-5.2-codex

# Créer un nouvel agent basé sur un modèle
nexus-agent init nexus_doc_writer --from-template doc_writer
✅ Created agent from template: doc_writer
✅ Created agent: /Users/mmornati/Projects/nexus-dev/agents/nexus_doc_writer.yaml

Next steps:
  1. Edit /Users/marco/nexus-dev/agents/nexus_doc_writer.yaml to customize your agent
  2. Restart the MCP server to activate this agent
  3. Use the 'ask_nexus_doc_writer' tool in your IDE

Les modèles disponibles incluent : code_reviewer, doc_writer, debug_detective, refactor_architect, test_engineer, security_auditor, api_designer, et performance_optimizer.

Le défi technique : La solution de contournement “Refresh”
#

Maintenant, parlons des défis spécifiques pour construire cela sur MCP. Ce n’était pas tout simple.

Le problème “Quel projet ?”
#

Les serveurs MCP sont souvent des processus système globaux (démarrés par la configuration de votre IDE). Mais vos agents sont locaux à votre projet. Quand vous ouvrez VS Code ou Cursor, le serveur MCP démarre, mais il ne connaît pas inhérément le fait que vous venez d’ouvrir /Users/marco/projects/my-app. Il fonctionne juste.

Cela signifie que nous ne pouvons pas efficacement pré-charger vos agents spécifiques au projet au démarrage parce que nous ne savons pas encore où est “ici”.

La spécification MCP aujourd’hui
#

Si vous avez suivi MCP, vous savez que le protocole a mûri significativement. La mise à jour de juin 2025 a introduit les sorties d’outils structurées (rendant les réponses d’outils plus fiables) et l’autorisation basée sur OAuth. La révision de novembre 2025 a ajouté la primitive Tasks pour les opérations asynchrones de longue durée et une meilleure découverte de serveur via les URLs .well-known.

Crucialement, la spec supporte depuis longtemps notifications/tools/list_changed : un mécanisme pour que les serveurs disent aux clients “ma liste d’outils a changé, veuillez la re-récupérer.”

L’écart de support client
#

Le problème n’est pas le protocole ; c’est les implémentations clients.

Idéalement, quand vous ouvrez un projet, le client (IDE) devrait :

  1. Dire au serveur “Hé, je suis dans ce dossier.”

  2. Le serveur émettrait notifications/tools/list_changed.

  3. Le client re-récupérerait la liste d’outils.

En pratique :

  1. Sens du contexte : Passer le répertoire de travail actuel de manière fiable pendant la négociation d’initialisation n’est pas toujours standardisé à travers les différents clients.

  2. Gestion des notifications : Tous les clients ne réagissent pas instantanément à notifications/tools/list_changed. Certains mettent en cache les listes d’outils de manière agressive. Certains n’implémentent pas du tout le gestionnaire de notification.

  3. Support du sampling : Pour que les agents fonctionnent, le client doit supporter la capacité MCP Sampling (permettant au serveur de demander des complétions LLM). Pas tous les IDEs supportent pleinement cela encore.

C’est un paysage en évolution. Au fur et à mesure que les clients MCP mûrissent, ces écarts se comblent.

La solution : refresh_agents
#

Pour combler cet écart aujourd’hui, nous avons introduit une solution pragmatique : l’outil refresh_agents.

Quand vous démarrez une session, ou si vous ajoutez un nouveau fichier YAML d’agent, vous (ou le modèle) invoquez simplement :

refresh_agents()

Cela force le serveur Nexus-Dev à :

  1. Demander à l’IDE le chemin du projet actif actuel (découvert via la variable d’environnement NEXUS_PROJECT_ROOT ou inféré du contexte).

  2. Scanner le dossier agents/.

  3. Enregistrer dynamiquement les outils ask_<agent_name>.

  4. Émettre notifications/tools/list_changed pour dire au client de mettre à jour son UI.

C’est un petit pas supplémentaire, mais ça débloque la capacité d’avoir des équipes IA完全 personnalisées par projet sans avoir besoin d’une gestion complexe de configuration globale.

Astuce : La configuration idéale est de configurer les paramètres MCP de votre IDE avec NEXUS_PROJECT_ROOT pointant vers votre projet. Cela élimine le besoin de rafraîchissement manuel dans la plupart des cas. Voir le Guide de démarrage rapide pour des exemples de configuration.

Pourquoi c’est important
#

Cette mise à jour transforme Nexus-Dev d’un “Moteur de recherche RAG” en un “Système de gestion d’équipe” pour votre IA. Vous pouvez maintenant curer l’aide exacte dont vous avez besoin.

  • Refactoring ? Lancez un refactor_architect.

  • Écrire des docs ? Utilisez le doc_writer.

  • Apprendre une nouvelle base de code ? Demandez à l’onboarding_buddy.

Le passage des outils aux agents reflète la tendance plus large dans le développement logiciel : nous passons de commander des machines à collaborer avec elles. Votre IA n’est pas juste un grep plus rapide ; c’est un coéquipier avec un rôle et une responsabilité définis.

Qu’est-ce qui vient ensuite ?
#

L’écosystème MCP évolue rapidement. Je garde un œil sur :

  • Meilleurs outils côté client : Au fur et à mesure que les IDEs comme Cursor et VS Code mûrissent leurs implémentations MCP, le besoin de refresh_agents diminuera.

  • Collaboration multi-agents : La capacité d’avoir des agents qui parlent entre eux, un security_auditor qui signale les problèmes, qu’un code_reviewers adresse ensuite, est un domaine de recherche actif.

  • Découverte de serveur : Le MCP Registry (maintenant en preview disponibilité générale) rendra le partage et la découverte d’agents utiles beaucoup plus faciles.

Allez-y et essayez. L’avenir du codage ne consiste pas juste à taper plus vite ; c’est mieux déléguer.

Découvrez la documentation sur GitHub pour commencer.