« Nous répondons dans les deux heures » peut rassurer une équipe et produire une déception le premier jour. Le collaborateur attend un ordinateur réparé ; le support voulait seulement promettre la lecture de sa demande. Répondre, prendre en charge et résoudre ne sont pas le même engagement. Les confondre transforme un objectif de service en promesse impossible à interpréter.
Un support interne a intérêt à publier des délais compréhensibles, fondés sur sa capacité et sur les conséquences des incidents. Il ne s’agit pas d’ajouter un vocabulaire contractuel à chaque échange. Il faut expliquer ce que le demandeur peut attendre, quand il sera informé et ce qui se passera si le problème dépasse l’équipe.
Définir les événements avant les chiffres
Commencez par décrire la réception. Une confirmation automatique indique que la demande est enregistrée et fournit une référence. Elle peut être immédiate, même lorsque personne ne travaille. Elle ne signifie pas qu’un technicien a compris la panne ou commencé à la traiter.
La première réponse utile apporte davantage : reformulation du problème, demande d’une information nécessaire, indication du prochain pas ou proposition d’un contournement pertinent. La prise en charge désigne l’attribution à une personne ou une équipe responsable. La résolution correspond au rétablissement convenu, qui peut différer d’une correction définitive.
Dans un exemple fictif, un salarié n’arrive plus à accéder à son application. Le support répond, vérifie le périmètre et propose un accès temporaire autorisé. Le travail peut reprendre, mais l’incident reste ouvert jusqu’à la confirmation du rétablissement prévu. Le contournement doit être nommé, pas présenté comme une disparition définitive de la cause.
Choisissez les événements que vous allez suivre et expliquez-les en langage ordinaire. Une seule horloge « délai de traitement » devient vite ambiguë. Deux objectifs distincts, réponse utile et prochaine information, sont souvent plus honnêtes qu’un délai de résolution uniforme pour toutes les pannes.
Compter les heures pendant lesquelles le service existe
Une promesse de quatre heures ne signifie pas la même chose selon qu’elle porte sur des heures calendaires ou sur des heures de service. Précisez les jours, les plages horaires, le fuseau et le traitement des jours fériés. Un support ouvert en journée ne doit pas afficher implicitement une permanence continue.
Prenons un calcul fictif : service du lundi au vendredi, de 9 heures à 17 heures, sans interruption, hors jours fériés ; objectif de première réponse de quatre heures de service. Une demande reçue vendredi à 16 heures consomme une heure ce jour-là. Il reste trois heures lundi : l’échéance est donc lundi à midi, si le lundi est travaillé.
L’attente réelle couvre pourtant tout le week-end. L’échéance visible doit traduire la règle, par exemple « réponse attendue lundi avant midi », plutôt qu’un compteur de quatre heures incompréhensible. Si le demandeur travaille le samedi, cette organisation laisse un besoin non couvert qu’il faut traiter comme tel.
Les outils peuvent intégrer ces calendriers. La documentation Jira Service Management décrit des calendriers de service configurables avec jours, plages horaires, fuseau et jours fériés. La fonction évite certains calculs manuels ; elle ne décide pas des horaires que l’entreprise peut réellement assurer.
Prioriser sur l’impact et l’urgence
Toute demande paraît importante à la personne bloquée. Une priorité stable doit pourtant distinguer les conséquences : activité entière arrêtée, plusieurs personnes touchées, échéance imminente ou gêne contournable. L’intitulé du poste du demandeur ne suffit pas à décrire l’impact.
Demandez quelques informations concrètes : service affecté, nombre de personnes concernées, possibilité de continuer autrement et date à laquelle la situation devient critique. Une imprimante indisponible peut être mineure dans un service et bloquante dans un autre. La priorité vient du contexte, pas seulement de la catégorie technique.
Préparez peu de niveaux et donnez un exemple pour chacun. Le niveau le plus élevé doit déclencher un fonctionnement particulier : alerte, personne mobilisable, canal défini et information des utilisateurs. Sans cette capacité, « critique » n’est qu’une étiquette rouge.
| Situation fictive | Engagement à définir |
|---|---|
| Service collectif indisponible sans contournement | Alerte, mobilisation et fréquence des nouvelles |
| Personne bloquée avec échéance proche | Qualification rapide et recherche de solution provisoire |
| Fonction dégradée avec contournement | Réponse utile et planification de la suite |
| Demande d’évolution | Qualification et décision de programmation |
Ce tableau ne fixe volontairement pas des durées standard. Les délais doivent venir de la capacité disponible, des besoins de l’entreprise et de la dépendance éventuelle à un prestataire.
Mesurer la charge avant de promettre
Examinez des demandes passées sur un périmètre représentatif. Séparez le temps de travail effectif, le temps d’attente et la durée totale écoulée. Dix minutes d’intervention peuvent s’étaler sur trois jours si une information manque ou si un fournisseur doit rétablir son service.
Comptez aussi les interruptions, les absences et le travail préventif. Une équipe dont toute la journée est promise aux demandes entrantes n’a aucune marge pour les incidents simultanés. Les objectifs doivent rester applicables lorsqu’un collègue est absent et que plusieurs demandes arrivent ensemble.
Un exemple fictif illustre la limite : deux personnes disposent ensemble de huit heures quotidiennes pour les demandes. Si les demandes du jour exigent dix heures de travail, le retard augmente d’au moins deux heures de travail, avant même les aléas. Modifier les couleurs du tableau ne crée pas la capacité manquante.
Vous pouvez d’abord publier des objectifs provisoires et observer leur tenue. Précisez la période d’évaluation et le mécanisme de révision. Un objectif interne de service reste un outil d’organisation ; son éventuelle portée contractuelle dépend du cadre dans lequel il est adopté.
Encadrer les pauses et les dépendances externes
Certains chronomètres s’arrêtent lorsque le support attend le demandeur. Cette règle peut être utile, à condition de définir ce qui la déclenche. « En attente » ne devrait pas devenir un moyen de faire disparaître une demande difficile des statistiques.
La question envoyée doit être nécessaire et assez précise pour permettre une réponse. Le demandeur voit ce qui manque et quand il sera relancé. Lorsqu’il répond, la demande revient effectivement dans la file de travail. Une pause de mesure n’efface pas l’attente vécue.
Pour un fournisseur externe, distinguez le délai que vous maîtrisez et celui que vous suivez. Vous pouvez promettre l’escalade, le point d’information et la recherche d’un contournement. Vous ne pouvez pas garantir une correction immédiate sur un service dont vous ne contrôlez pas la remise en état.
Conservez donc deux lectures si nécessaire : délai mesuré selon les règles du service et durée totale depuis la demande. Leur écart aide à comprendre les dépendances, les pièces manquantes et les attentes prolongées. Il ne doit pas servir à opposer une statistique favorable à un salarié toujours bloqué.
Promettre une prochaine information utile
Même sans heure de résolution fiable, le support peut dire quand il donnera des nouvelles. Cette mise à jour précise ce qui est connu, ce qui reste à confirmer et la prochaine étape. « Nous travaillons dessus » répété automatiquement n’apporte pas la même valeur qu’un état factuel.
Pour un incident collectif, centralisez l’information afin d’éviter que chaque personne ouvre une nouvelle demande pour obtenir une date. Les demandes liées peuvent conserver leur référence tout en renvoyant à un suivi commun. Le support réduit ainsi le travail répétitif sans laisser les utilisateurs dans le silence.
Prévoyez l’escalade avant l’échéance dépassée : qui arbitre une priorité, mobilise une autre équipe ou accepte un report ? Une notification de retard sans personne capable d’agir produit seulement une alerte de plus. L’outil doit servir une responsabilité déjà définie.
Revoir le service avec plusieurs indicateurs
Le taux de réponses dans le délai ne suffit pas. Ajoutez les demandes encore ouvertes, leur ancienneté, les réouvertures et la tenue des points d’information. Regardez séparément les catégories : une amélioration sur les demandes simples peut masquer la dégradation des incidents bloquants.
Discutez quelques cas en équipe. Le délai a-t-il été dépassé à cause d’un objectif irréaliste, d’un manque d’information ou d’une attribution tardive ? La réponse diffère selon la cause.
Cette revue permet de corriger la règle ou l’organisation, plutôt que de demander simplement de répondre plus vite.
La formulation à publier doit tenir en quelques phrases : horaires couverts, définition de la réponse, niveaux de priorité, canal d’urgence et engagement d’information. Un délai crédible donne de la visibilité, même lorsqu’il ne peut pas annoncer la fin exacte d’une panne. Le demandeur sait alors quand attendre, quand relancer et à qui signaler que les conséquences ont changé.
