IT Support Done Right: A Practical Field Guide

La plupart des travaux IT support sont jugés sur la vitesse, mais la vitesse sans méthode ne fait que déplacer le même problème ailleurs. Un ticket fermé en cinq minutes qui réapparaît en trois jours coûte plus cher qu'un ticket qui prend vingt minutes et qui est vraiment réglé. Ce guide couvre les pratiques qui distinguent quelqu'un qui ferme des tickets de quelqu'un qui résout des problèmes.

Commencer par une vraie collecte d'informations, pas une supposition

Avant de toucher à une machine, faites décrire le problème par l'utilisateur dans ses propres termes, puis posez trois questions de suivi : quand cela a-t-il commencé, qu'est-ce qui a changé récemment, et est-ce que cela arrive à chaque fois ou par intermittence. "Mon internet est lent" pourrait signifier une résolution DNS, un canal Wi-Fi saturé, une carte réseau défaillante, ou un navigateur avec quarante onglets ouverts. Notez le texte d'erreur exact s'il y en a un. Des captures d'écran battent les descriptions à chaque fois — demandez-en une avant de demander à l'utilisateur d'essayer quoi que ce soit.

Résistez à l'envie de sauter directement à « avez-vous essayé de redémarrer ». Ça marche assez souvent pour que les gens en fassent leur réflexe par défaut, mais si vous sautez la collecte d'informations vous allez rater des schémas. Si trois personnes sur le même switch signalent le même ralentissement à la même heure, c'est un ticket différent d'un ordinateur portable avec un mauvais pilote.

Reproduire avant de réparer

Si vous ne pouvez pas reproduire un problème, vous ne pouvez pas confirmer que vous l'avez réglé. Demandez à l'utilisateur de parcourir les étapes exactes lors d'un partage d'écran, ou faites-le vous-même sur sa machine si les outils à distance le permettent. Vérifiez ipconfig /all sur Windows ou ip a sur Linux pour la santé basique du réseau, consultez l'Observateur d'événements (eventvwr.msc) pour les erreurs d'application et système autour du moment signalé, et vérifiez journalctl -xe --since "1 hour ago" sur les machines Linux pour la même fenêtre.

Pour les plantages d'application, obtenez le numéro exact de la build et la version de l'OS. "Ça a planté" ne vous dit rien ; "Outlook 16.0.17726 plante lors de l'ouverture d'une invitation de calendrier avec une pièce jointe .ics" vous dit où chercher. Comparez avec les problèmes connus dans les notes de version du fournisseur avant de supposer que c'est local.

Triez par impact, pas par qui crie le plus fort

Un utilisateur unique verrouillé hors de l'email est gênant. Un serveur de fichiers partagé inaccessible pour quarante personnes est une panne. Construisez une échelle de sévérité simple — quelque chose comme P1 pour les pannes affectant plusieurs utilisateurs ou les systèmes critiques, P2 pour les blocages utilisateur unique, P3 pour dégradé mais fonctionnel, P4 pour les demandes cosmétiques ou de confort — et appliquez-la de façon cohérente, même sous la pression d'un manager qui veut que son truc soit traité en premier.

Documentez la décision de sévérité dans le ticket lui-même. Cela vous protège plus tard quand quelqu'un demande pourquoi son P3 a attendu deux jours pendant que vous traitiez trois P1.

Corriger la cause racine, pas le symptôme

Redémarrer un service qui continue de planter gagne du temps, pas une solution. Si un spouleur d'impression meurt chaque jour, vérifiez Get-WinEvent -LogName Application -MaxEvents 50 pour l'erreur réelle avant de le redémarrer à nouveau. Si le mot de passe d'un utilisateur expire de façon inattendue, vérifiez la stratégie de groupe appliquée à son unité d'organisation plutôt que de le réinitialiser et de continuer.

Conservez un journal personnel des corrections récurrentes. Si vous vous trouvez en train de taper la même commande PowerShell ou le même correctif de registre trois fois, c'est un signe qu'il devrait être dans un script ou un runbook documenté, pas dans votre tête.

Documentez comme si quelqu'un d'autre allait le lire

Chaque résolution de ticket devrait répondre : quelle était la cause réelle, quel était le correctif, et qu'est-ce que vous vérifieriez en premier si cela se reproduisait. "Réglé" comme note de résolution n'a aucune valeur pour le prochain technicien, y compris vous-même dans six mois sans souvenir de ce ticket.

Une bonne note de résolution ressemble à : "Cause racine : l'étendue DHCP sur VLAN 20 épuisée, les nouveaux appareils ont obtenu des adresses APIPA. Correctif : étendue élargie de /24 à /23, réservation pour l'imprimante ajoutée. Vérification : vérifier le nombre de baux DHCP mensuellement, seuil d'alerte défini à 90 %." Cette troisième phrase est celle que la plupart des techniciens sautent, et c'est celle qui empêche le ticket en double.

Escalader avec du contexte, pas juste un transfert

Quand un ticket va au niveau 2 ou à un fournisseur, incluez ce que vous avez déjà éliminé. "Vérifiés câblages, port changé, config VLAN confirmée, toujours pas de voyant de lien" économise à la personne suivante de refaire vos premières vingt minutes. Les escalades vagues comme "l'utilisateur dit que c'est cassé, veuillez conseiller" ne font que déplacer le délai au lieu de l'éliminer.

Fermer la boucle avec l'utilisateur

Dites à l'utilisateur ce qui était mal en langage simple, pas juste "réglé". Les gens font davantage confiance au support quand ils comprennent ce qui s'est passé, et cela réduit le nombre de fois où la même personne file le même ticket le mois suivant parce qu'elle ne réalise pas que c'est connecté.

Si vous voulez approfondir le côté technique de tout cela — les fondamentaux du réseau, les journaux d'événements Windows, ou le scripting de vos propres outils de diagnostic — Korra Studio a des segments sur Networking, Systems et Scripting qui valent la peine d'être explorés ensuite.