← Tous les projets

• GLPI
• Redmine
• MCP
• Claude Code

GLPI et Redmine couvrent deux besoins complémentaires de gestion : GLPI est avant tout un outil de helpdesk et d’inventaire IT (parc matériel/logiciel, tickets support), tandis que Redmine est un outil de gestion de projet et de suivi de tâches/bugs orienté développement. Les deux exposent une API permettant aujourd’hui de brancher des agents IA capables de créer, mettre à jour et documenter automatiquement des tickets au fil du travail réalisé.

Historique

GLPI est un projet français lancé en 2003, initialement développé pour la gestion de parc informatique d’une collectivité, avant de devenir une référence open source du helpdesk IT. Redmine sort en 2006, écrit en Ruby on Rails, très inspiré de Trac, et s’impose comme outil de gestion de projet agile/bugs dans de nombreuses équipes de développement, grâce à sa flexibilité (workflows configurables, plugins).

Avantages des versions récentes

• API REST modernisée sur GLPI 10.x et Redmine, facilitant l’intégration d’outils externes, y compris des agents IA, sans script fragile.
• Automatisation du cycle de ticket : création, mise à jour de statut, notes de suivi générées automatiquement par un agent au fur et à mesure du travail réalisé - exactement le mécanisme utilisé pour documenter ce site.
• Écosystème de plugins étendu sur les deux outils (rapports, tableaux de bord, workflows personnalisés) réduisant le besoin de développement spécifique.
• Traçabilité renforcée : chaque action d’un agent IA peut être historisée comme n’importe quelle action humaine, gardant l’outil de ticketing comme source de vérité.

Gestion automatique des tickets avec MCP et Claude Code

Le serveur MCP (Model Context Protocol) de Redmine donne à Claude Code un accès direct aux tickets, avec les droits d’un utilisateur dédié : l’agent travaille comme un collaborateur, et chacune de ses actions est tracée dans l’historique du ticket.

Le cycle appliqué à chaque demande :

1. Recherche d’un ticket existant sur le sujet, pour éviter les doublons.
2. Création du ticket s’il n’y en a pas : la demande initiale est recopiée telle quelle dans la description, le ticket est rattaché au bon projet et assigné à l’agent.
3. Travail : développement, configuration ou diagnostic, en gardant le numéro du ticket comme référence.
4. Note de suivi à la fin : la demande, la réponse, les actions effectuées et le résultat, y compris les problèmes restants. Quelqu’un qui n’a pas la conversation sous les yeux comprend l’historique en lisant le ticket.
5. Passage à validation : le ticket est repassé à l’humain pour test, puis résolu une fois le travail validé.

Une demande complémentaire sur le même sujet n’ouvre pas de nouveau ticket : elle s’ajoute en note du ticket existant. Redmine reste la source de vérité, l’agent n’est qu’un contributeur.

Création d’un ticket par e-mail

Un e-mail envoyé à une adresse dédiée devient un ticket sans aucune saisie :

1. Le message arrive dans une boîte aux lettres dédiée.
2. La réception d’e-mails native de Redmine relève la boîte et crée un ticket : le sujet devient le titre, le corps devient la description, les pièces jointes sont conservées.
3. Le ticket atterrit dans un projet d’entrée réservé aux mails entrants non traités.
4. L’agent le prend en charge via MCP, comme n’importe quel autre ticket : lecture, traitement, note de suivi, passage à validation.

Mon expertise

J’utilise Redmine comme source de vérité de mes projets, relié à des agents IA par un serveur MCP :

• un ticket créé pour chaque demande, dans le bon projet, avec la demande initiale recopiée telle quelle ;
• une note de suivi à chaque étape : demande, réponse, actions réalisées et résultat ;
• la création d’un ticket par e-mail, grâce à la réception d’e-mails native de Redmine, puis la prise en charge par l’agent ;
• un historique par projet qu’on peut relire sans avoir accès à la conversation avec l’agent.