Faire dialoguer deux outils de ticketing peut s’avérer nécessaire pour gagner en efficacité. Techniquement, l’interconnexion passe par une API Web (ou plus rarement, via un transfert de fichiers sécurisés). Mais ce qui prime dans un projet d’interfaçage, plus que la partie technique, c’est la partie fonctionnelle. Celle-ci cadre le partage de données et permet de mettre en place des scénarios d’échange pertinents et performants. Explications.
Interfacer deux outils de ticketing : pour quoi faire ?
En interne : pour augmenter les synergies entre deux équipes (et leur productivité !)
Il n’est pas rare que certaines équipes mettent en place et utilisent leurs propres outils de ticketing pour gagner en efficacité dans leurs tâches quotidiennes (outils en ligne gratuits, logiciels open source…). Seulement, l’utilisation de ces solutions n’a parfois pas l’effet escompté : au lieu d’aider les équipes à gagner en productivité, elles instaurent des pratiques hétérogènes et renforcent les silos entre les services. Résultat : la collaboration entre les équipes n’est pas au beau fixe.
Imaginons par exemple que l’équipe support utilise iTop pour gérer les incidents et les demandes, tandis que l’équipe de développeurs s’appuie sur Jira ou Mantis pour gérer les bugs et les améliorations applicatives. Dans ce cas, les informations ne sont pas croisées et cela peut être dommageable.
Il semble important de faire dialoguer les outils pour garantir aux deux équipes l’accès à l’ensemble de l’information et donc des prises de décision en toute connaissance de cause.
En externe : pour vous adapter aux outils de vos clients sans perturber les utilisateurs
Situation encore plus fréquente : votre client a déjà un outil de ticketing en place — différent du vôtre — et ne compte pas en changer. C’est bien normal, cela évite de modifier les habitudes des utilisateurs et d’entamer une démarche de conduite de changement. En tant qu’entreprise de services IT, vous êtes accoutumée à ce cas de figure. Mais êtes-vous pour autant équipé pour intégrer la solution de votre client ?
L’idéal est que chacun conserve son outil de ticketing, et que ceux-ci communiquent entre eux pour garantir un support performant sans perturber les utilisateurs.
3 étapes pour réussir l’interfaçage avec iTop
Étape 1 — Définir les scénarios d’échange
Contrairement à ce que l’on pourrait croire, l’étape la plus importante lorsqu’il s’agit d’interfacer deux outils de ticketing n’est pas la mise en œuvre technique. L’attention doit en priorité se porter sur celle qui précède et qui consiste à valider les scénarios fonctionnels.
- Dans quel(s) cas un ticket passe-t-il de l’outil A à l’outil B ?
- Quelle(s) action(s) déclenche la création du ticket A dans l’outil B ?
- Quelles sont les informations partagées entre les deux outils?
À ce stade, il faut réunir les équipes représentant et utilisant les deux solutions pour que chacune décrive ce qu’elle souhaite mettre en place. Cela permet de se mettre d’accord sur les spécifications fonctionnelles entre les outils : chacun apporte sa vision à travers un dialogue constructif.
Anticipez tous les scénarios, même les plus simples !
|
Étape 2 — mettre en place les scénarios d’échange
Une fois les scénarios d’échange validés, il convient d’adapter le module satellite iTop, qui permet les échanges entre les deux systèmes. Pour un projet simple, on peut compter entre 4 et 6 scénarios. Les plus complexes peuvent en contenir plus d’une vingtaine. Notons que plus il y a de scénarios, plus la mise en œuvre et le suivi seront compliqués.
Quoi qu’il en soit, il est recommandé de se concentrer sur les statuts et champs ayant une réelle valeur à partager. Ainsi, le ticket se retrouvera dans l’état “En attente système distant” d’un côté, tandis qu’il sera en cours de traitement dans la solution en face.
Étape 3 — Déployer le canal de communication
Pour finaliser l’interfaçage, il reste à mettre en place le canal de communication entre les deux solutions de ticketing : format d’échange entre les APIs respectives, mode d’authentification, etc. À ce stade, il s’agit de connecter les applications entre elles, en explicitant de quelle façon elles doivent “dialoguer”.
Un moteur pensé pour faciliter l’interfaçage
Le logiciel iTop propose un moteur d’échange pour s’interconnecter avec un autre outil ITSM : le Case Exchange – Satellite. Celui-ci permet en outre de :
- Gérer l’authentification et le format des messages échangés avec l’autre outil,
- Réaliser un data mapping ; à savoir établir les correspondances des données entre les solutions ITSM, chacune ayant des modèles de données et des cycles de vie différents. À titre d’exemple, le mapping permettra d’identifier que “résolu” dans iTop se traduit par “solutionné” dans le second outil ou qu’une priorité 4 équivaut à une priorité 3. On garde ainsi le vocabulaire propre à chaque logiciel.
- Gérer l’ordonnancement des messages, le suivi et les reprises sur erreur (ex : appliquer en premier lieu la création d’un ticket avant qu’un message de mise à jour soit joué).
« Nous avons construit une passerelle automatisée entre iTop et l’outil de gestion d’incidents d’un de nos clients. Lorsqu’un incident est créé sur leur solution, il remonte directement dans iTop de notre côté. » Emmanuel Lozachmeur, Ingénieur Services chez Fives Syleps
Attention cependant, l’interconnexion entre deux outils de ticketing est pertinente si la volumétrie de tickets est suffisante et a une réelle valeur ajoutée. Ce type de projet est à réserver aux cas dans lesquels la double saisie est impossible ou trop risquée.
En effet, quand les échanges de tickets ne sont pas nombreux ni critiques, il existe d’autres solutions plus basiques, comme les notifications automatiques par mail ou le WebHook (disponible en natif dans iTop 3.0 et sous forme d’extension en 2.7). Cette nouvelle fonctionnalité permet d’associer sur une action sur un objet iTop (un ticket) à une action distante par API. Elle répond particulièrement bien aux besoins d’interconnexion simples et pour des entreprises aux budgets plus modestes.
Consultant CMDB / ITSM chez Combodo
