Qu’est‑ce que Mantis Webservice et comment cela peut‑il vous aider ?

Mantis Webservice : une passerelle API vers MantisBT

Mantis Webservice désigne habituellement les services web de MantisBT, le logiciel libre de suivi d’anomalies et de tickets. En pratique, ce sont des interfaces de programmation, ou API, qui permettent à un autre logiciel de dialoguer avec MantisBT par requêtes HTTP. Un outil de tests peut ainsi ouvrir un ticket lorsqu’un scénario échoue ; un script peut ajouter une note, changer le statut d’une anomalie ou rechercher les tickets déjà existants.

L’intérêt est d’éviter la saisie manuelle répétitive et les copier-coller entre outils. L’API n’est donc pas réservée aux développeurs : elle peut servir à une équipe support, à un responsable qualité ou à un administrateur qui doit consolider des remontées venant de plusieurs applications. Elle ne remplace pas le tri humain : elle transporte et structure l’information vers MantisBT.

API / webservice

Une API est une porte d’entrée documentée pour les logiciels. Au lieu de cliquer dans MantisBT, un programme envoie une demande normalisée, par exemple « créer ce ticket dans ce projet », puis reçoit une réponse indiquant si l’opération a réussi.

REST ou SOAP : quelle interface MantisBT utiliser ?

Le mot « webservice » peut couvrir deux approches. Les installations récentes de MantisBT proposent couramment une API REST, plus simple à appeler depuis un script, un outil d’intégration continue ou une application interne. Les environnements plus anciens utilisent souvent MantisConnect, l’API SOAP historique. SOAP reste pertinent lorsqu’un connecteur existant le réclame ; pour une nouvelle intégration, REST est en général plus facile à maintenir.

Ne choisissez pas un protocole seulement parce qu’un tutoriel le cite. Vérifiez la version exacte de MantisBT, les extensions activées, la documentation livrée avec votre serveur et les contraintes de l’outil à raccorder. Les chemins d’accès, méthodes d’authentification et opérations disponibles peuvent varier selon la version ou la configuration de l’hébergeur.

Dans quels cas Mantis Webservice fait vraiment gagner du temps ?

La meilleure utilisation est celle où une information déjà produite par un système doit devenir un ticket exploitable, sans ressaisie. Par exemple, une chaîne Jenkins ou GitLab CI peut signaler l’échec répété d’un test ; un formulaire de support interne peut ouvrir une anomalie avec son niveau de priorité ; un outil de supervision peut joindre un identifiant d’incident et les traces utiles. L’équipe retrouve alors les tickets au même endroit, avec un propriétaire, un statut et un historique.

L’API est également utile pour lire MantisBT : afficher dans un portail interne les anomalies ouvertes d’un projet, rapprocher des tickets avec des versions livrées, ou envoyer un bilan périodique. Commencez toutefois par un flux unique et concret. Une synchronisation bidirectionnelle entre plusieurs outils paraît séduisante, mais elle crée vite des conflits de statuts, de responsables et de priorités.

Mettre en place Mantis Webservice en 6 étapes

Une première intégration n’a pas besoin d’être vaste. Le bon objectif est un test réversible : créer un ticket dans un projet de démonstration, avec un compte limité, puis vérifier qu’un humain peut le traiter correctement. Les étapes ci-dessous évitent de donner trop de droits ou de remplir la base de tickets inutiles.

Sécuriser les tickets, les jetons et les données personnelles

Un jeton d’API agit comme une clé : toute personne qui le possède peut réaliser les actions autorisées au compte associé. Révoquez immédiatement un jeton affiché par erreur dans un dépôt, un journal CI ou un message. Préférez un jeton par intégration, avec un nom et une date de revue, plutôt qu’un jeton partagé entre plusieurs scripts. Quand un salarié quitte l’équipe ou qu’un prestataire termine sa mission, le compte et ses jetons doivent être revus.

Les tickets peuvent contenir des données sensibles : adresse e-mail, extrait de journal technique, nom de client, identifiant de session ou capture d’écran. Ne transmettez dans MantisBT que les informations nécessaires au diagnostic. Masquez les mots de passe, jetons, données bancaires et données de santé. Si le projet traite des données personnelles, l’organisation reste tenue de respecter le RGPD : durée de conservation, personnes ayant accès aux projets, sécurité de l’hébergement et information des personnes concernées doivent être cadrées.

Enfin, prévoyez une limite de débit et une journalisation raisonnable côté intégration. En cas de boucle logicielle, des centaines de requêtes peuvent ralentir le serveur et déclencher une avalanche de notifications. Gardez les identifiants techniques, les codes de réponse et les messages d’erreur utiles ; ne conservez pas par défaut le contenu complet de secrets dans les logs.

Coût, maintenance et limites à prévoir

MantisBT est un logiciel libre : l’utilisation du logiciel ne réclame généralement pas d’abonnement de licence. En revanche, une intégration a un coût réel de préparation et d’entretien : développement du connecteur, hébergement de MantisBT, sauvegardes, mises à jour, tests après montée de version et traitement des erreurs. Pour un petit besoin, un formulaire bien configuré ou un import ponctuel peut coûter moins de temps qu’une API sur mesure.

La limite la plus fréquente n’est pas technique, mais organisationnelle. Si les équipes ne partagent pas les mêmes règles sur la priorité, les statuts, les versions et le responsable d’un ticket, l’automatisation propage simplement le désordre plus vite. Définissez donc un modèle de ticket court, un propriétaire du flux et une règle claire : qui ferme le ticket créé automatiquement, et dans quelles conditions ?