Les limites WIP dans Kanban : Pas...
Le Redmine MCP standard couvre la REST API. Le vrai Redmine d’entreprise vit dans les plugins.
Un serveur MCP prêt à l’emploi pour Redmine expose généralement la REST API standard : projets, demandes, commentaires et saisies de temps.
Cela suffit jusqu’au moment où quelqu’un demande une checklist de demande, une colonne de tableau Agile ou des données d’un plugin interne. Là, le modèle se heurte à un mur : il ne voit que le Redmine standard.
Connecter Redmine à l’IA est facile. Connecter le Redmine que votre entreprise utilise réellement, c’est la partie difficile.
Une installation Redmine mature accumule des plugins Agile, Helpdesk, CRM, checklists, reporting et sur mesure. Une grande partie du vrai workflow et des données métier se trouve là, pas dans le cœur de Redmine.
La plupart des intégrations MCP ne connaissent que la Redmine REST API. Les capacités des plugins ne font pas partie de ce contrat tant que vous ne les ajoutez pas.
Pourquoi la Redmine REST API seule ne suffit pas
Ce que nous avons changé : un Redmine MCP extensible
Nous avons d’abord cartographié chaque API de plugin à la main et transformé ses méthodes en outils MCP. Cela fonctionne pour un plugin. Cela s’effondre quand il y en a beaucoup.
Redmine MCP s’exécute dans Redmine et expose un Registry partagé. Les autres plugins y enregistrent leurs propres outils, ressources, prompts et capabilities. Le serveur MCP n’a pas besoin de connaître leur logique métier.
Au lieu d’avoir des serveurs MCP séparés pour Redmine, Agile, Checklists et chaque module interne, il n’y a qu’un chemin : client IA → Redmine MCP → Redmine → le plugin cible.
Un plugin devient une extension MCP, pas un fork du serveur MCP. Si vous pouvez modifier le plugin, placez l’intégration dans `lib/.../mcp.rb`, étendez `RedmineMcp::ExtensionApi` et enregistrez les outils. Les noms suivent le modèle `redmine_<plugin>_<action>`.
Si un plugin tiers ne peut pas être patché, gardez l’adapter dans `redmine_mcp/lib/redmine_mcp/extensions/`. Pas besoin de forker le plugin de quelqu’un d’autre uniquement pour MCP. Les deux voies utilisent la même Extension API et le même Registry.
Une partie de ce travail d’intégration peut être faite par un agent IA. Redmine MCP fournit la skill `redmine-mcp-plugin-integration` : comment lire les API, serializers et services des plugins ; découper les fonctionnalités en outils ; définir les schémas d’entrée et de sortie ; appliquer les permissions ; et tester le résultat.
Workflow : donnez à l’agent le code source du plugin, activez la skill et demandez-lui d’ajouter le support MCP. Pour un plugin de checklist, vous pouvez obtenir `redmine_checklists_get_checklist`, `redmine_checklists_add_checklist_item`, `redmine_checklists_update_checklist_item` et `redmine_checklists_delete_checklist_item`.
Ensuite, un utilisateur peut demander : « Inspecte la demande #1234 et liste les éléments de checklist incomplets. » Le modèle choisit un outil nommé au lieu de deviner l’API privée du plugin.
Le code généré par un agent n’est pas prêt pour la production par défaut. Validez-le par rapport à la vraie API du plugin : permissions, schémas et chemins de succès comme d’échec. Les tests doivent couvrir tout le chemin du Registry : validation → permission → handler → réponse.
Parfois, l’agent a raison du premier coup ; parfois, il lui faut un indice spécifique au plugin. Dans les deux cas, cela coûte moins cher que de concevoir chaque intégration à partir de zéro.
Les permissions restent celles de Redmine. MCP s’authentifie avec la clé API de l’utilisateur. L’accès exige aussi la permission `Use MCP`. Les projets et les demandes utilisent la visibilité standard (`Project.visible`, `Issue.visible`). Un mode global en lecture seule est disponible lorsque les écritures doivent être bloquées.
Les extensions doivent appeler les contrôles de permissions Redmine ou réutiliser un endpoint REST existant du plugin avec l’utilisateur courant. Il n’existe pas de superutilisateur IA contournant l’ACL de Redmine.
Consultez le guide des extensions pour les détails d’implémentation et le README du projet pour l’installation et la configuration du client.
À retenir
Nous n’avons pas construit un MCP qui découvre automatiquement chaque plugin Redmine. Ce n’est pas la bonne cible.
Nous avons construit un Registry où les plugins enregistrent leurs propres outils, plus une skill assez détaillée pour qu’un agent IA puisse rédiger une grande partie de l’intégration.
Quand le plugin suivant a besoin d’un support MCP, nous donnons d’abord son code à un agent. Nous n’intervenons manuellement que si l’agent échoue.
Découvrez nos autres articles
5 signes que votre équipe a besoin de listes de contrôle dans les tâches Kanban
Comment le tableau Kanban accélère les projets dans Redmine : Du chaos des tâches au flux transparent
