Portails en libre-service réellement utilisés : gestion des demandes de service dans Jira Service Management

Un portail en libre-service est utilisé lorsque l’employé y trouve une aide plus rapide qu’en envoyant un e-mail à l’informatique. Cela fonctionne selon trois principes : une structure de catégories claire avec cinq à sept catégories principales, des workflows d’approbation automatisés pour les demandes ayant des conséquences financières, et des articles de connaissance proposés directement dans le flux de recherche.

Dans Jira Service Management, nous mettons cela en œuvre avec les Request Types, les Approvals et la base de connaissances intégrée dans Confluence. La clé est de construire le portail du point de vue des utilisateurs et non comme une copie de l’organigramme interne de l’IT. Un portail bien conçu réduit sensiblement le volume de tickets et le temps de traitement, et peut s’étendre au-delà de l’IT vers les RH, les Facilities et le juridique (Enterprise Service Management, ESM).

En tant qu’Atlassian Platinum Solution Partner en Suisse, Swarmit accompagne la conception du portail, de la structure des catégories jusqu’à l’extension progressive à d’autres départements.

Pourquoi beaucoup de portails restent inutilisés

La majorité des portails en libre-service que nous voyons lors des premiers assessments chez de nouveaux clients présentent le même problème fondamental : ils sont construits selon le fonctionnement de l’équipe IT interne, et non selon la façon de penser d’un employé. Celui qui a besoin d’un nouvel accès à un système métier ne sait pas si cela relève de « Identity & Access », « Support applicatif » ou « Gestion des utilisateurs ». Il envoie donc un e-mail. Ainsi, le portail est contourné et le gain d’efficacité disparaît.

Un bon portail inverse la perspective. Il ne demande pas « quelle équipe IT est responsable ? », mais « que veux-tu accomplir ? ». L’affectation interne se fait ensuite en arrière-plan, soit via des règles d’automatisation, soit, pour des cas plus complexes, par un agent Rovo qui prend en charge la classification.

Catégories et formulaires : moins, c’est mieux

La structure du portail est une décision de design, pas une décision technique. Nous recommandons cinq à sept catégories principales, derrière lesquelles se cachent des Request Types concrets. Les catégories principales s’orientent autour de verbes et d’objectifs : « Obtenir un accès », « Commander du matériel », « Signaler une panne », « Demander un logiciel ».

Deux règles se sont avérées efficaces :

Premièrement : ne pas demander plus de champs que nécessaire. Les formulaires restent aussi succincts que possible, avec des champs conditionnels qui n’apparaissent que lorsqu’ils sont vraiment nécessaires.

Deuxièmement : maintenir la recherche fonctionnelle. Si un employé tape « VPN » dans la barre de recherche, la demande de VPN doit apparaître comme premier résultat. Cela inclut des noms pertinents pour les Request Types (pas « IAM-VPN-P002 », mais « Demander un accès VPN ») et des synonymes appropriés dans le titre ou la description.

Articles de connaissance pour éviter les tickets

Le ticket le plus efficace est celui qui n’existe jamais. JSM relie le portail directement à une base de connaissances basée sur Confluence. Quand un employé ouvre un ticket et saisit « VPN ne fonctionne pas », le portail propose des articles pertinents avant même que le ticket ne soit soumis.

Pour que cela fonctionne, les articles doivent avoir trois caractéristiques :

• Ils répondent à la question dans les deux premières phrases. Qui doit lire trois paragraphes d’introduction abandonne.
• Ils sont à jour. Un article qui renvoie à une version du logiciel d’il y a deux ans fait plus de tort que l’absence d’article.
• Ils sont liés aux Request Types appropriés. Sans ce lien, le portail ne les trouve pas.

Nous recommandons un rythme de maintenance simple : pour chaque ticket fermé qui apparaît, par exemple, plus de trois fois par mois, on vérifie si un article de connaissance existe. Sinon, on en crée un. Cette règle peut être automatisée dans JSM en tant que tâche.

Jira Service Management au-delà de l’IT

Une fois le portail IT établi, beaucoup d’organisations franchissent le deuxième pas : l’Enterprise Service Management. Les RH utilisent la même plateforme pour les demandes d’onboarding, les Facilities pour les cartes d’accès et les signalements de réparations, le juridique pour les relectures de contrats. Du point de vue des employés, il n’y a alors qu’un seul endroit pour toutes les demandes internes.

Techniquement, cette étape dans JSM reste maîtrisable : nouveaux projets, nouvelle structure de portail, nouveaux workflows. Le vrai effort réside dans le travail sur les processus avec les départements concernés. Nous recommandons de commencer par un département et de transférer ensuite l’expérience au suivant.

Questions fréquemment posées

Comment convaincre les employés d’utiliser le portail plutôt que l’e-mail ?

Deux facteurs fonctionnent de manière fiable. Premièrement : le portail doit être objectivement plus rapide que l’e-mail – délais de réponse plus courts, informations de statut plus claires, retours automatiques. Deuxièmement : le chemin classique de l’e-mail est rendu progressivement moins attractif (par exemple via des réponses automatiques renvoyant au portail). L’interdiction par directive fonctionne rarement ; la redirection par une meilleure expérience fonctionne presque toujours.

Jira Service Management peut-il aussi être utilisé pour les demandes RH ou Facilities ?

Oui. JSM est conçu côté plateforme pour l’Enterprise Service Management. Chaque département peut exploiter son propre projet avec ses propres formulaires, workflows et circuits d’approbation. Du point de vue des utilisateurs, cela reste un portail unifié.

Comment Jira Service Management gère-t-il les exigences suisses en matière de protection des données ?

Atlassian Cloud prend en charge la résidence des données en Suisse. Pour les données RH et les données personnelles, qui sont typiquement particulièrement sensibles, c’est un critère central. La configuration de la Data Residency est un point de contrôle à part entière lors du déploiement ESM, que nous coordonnons avec les responsables de la protection des données de l’organisation.

Prochaines étapes

Pour les organisations qui souhaitent évaluer leur portail existant, nous proposons une revue de portail : nous vérifions la structure actuelle, les Request Types les plus utilisés et les statistiques d’utilisation réelles. Le résultat est une liste de priorités avec trois à cinq améliorations pouvant être mises en œuvre à court terme.

Vous souhaitez faire évaluer votre portail ? Contactez-nous pour un échange sans engagement.