Technicien support informatique

Je commence par obtenir une description précise de l'utilisateur : ce qu'il faisait, ce qu'il attendait, et ce qui s'est réellement passé, car des signalements vagues comme 'ça ne marche pas' font perdre les dix premières minutes si je ne demande pas de précisions. Je vérifie d'abord les points évidents : le problème est-il isolé à une machine ou touche-t-il plusieurs utilisateurs, y a-t-il eu un changement récent comme une mise à jour ou une modification de permissions, et puis-je le reproduire moi-même. Je consulte notre base de connaissances interne et l'historique des tickets avant de supposer que ce cas est unique, car la plupart des 'nouveaux' problèmes sont déjà apparus sous une description légèrement différente. Si je ne trouve pas de correspondance, j'isole les variables une à la fois plutôt que de changer plusieurs choses en même temps, pour savoir précisément quel changement a résolu le problème. Je documente ce que j'ai essayé et le résultat au fur et à mesure, pas seulement à la fin, au cas où je devrais escalader et qu'une autre personne doive reprendre là où je m'étais arrêté.

J'abandonne complètement le vocabulaire technique et je décris le problème en fonction de ce que l'utilisateur va vivre et du délai de résolution, plutôt que de la cause sous-jacente. Si le compte de quelqu'un est bloqué à cause d'un échec de synchronisation avec notre fournisseur d'identité, je dis 'votre compte a besoin d'une réinitialisation rapide, cela prendra environ cinq minutes et vous devrez vous reconnecter ensuite' plutôt que d'expliquer l'échec de synchronisation. Je vérifie la compréhension en demandant à la personne de me dire ce qu'elle va faire ensuite, plutôt que de simplement demander 'est-ce que c'est clair', car les gens répondent souvent oui par politesse même quand ils sont encore perdus. J'adapte aussi mon rythme au leur : si quelqu'un s'inquiète de perdre son travail, je traite cette inquiétude directement avant de passer à la correction. Avec les utilisateurs frustrés, je reconnais d'abord la gêne occasionnée, car ils ont besoin de se sentir écoutés avant de pouvoir suivre des instructions.

Je trie selon deux axes : le nombre de personnes concernées et le degré de blocage pour leur travail. Une panne du système de paie touchant toute l'équipe finance passe avant l'imprimante d'un seul utilisateur qui ne se connecte pas, même si ce ticket est arrivé en premier. Je marque comme immédiat tout ce qui touche à la sécurité, à la perte de données ou à un système de production, quel que soit celui qui l'a signalé. Pour le reste, je travaille globalement dans l'ordre d'arrivée, mais je communique de façon proactive : si le ticket de quelqu'un doit attendre une heure, j'envoie une mise à jour rapide plutôt que de le laisser se demander s'il a bien été reçu. Je regroupe aussi les tickets à faible priorité similaires, comme plusieurs demandes de réinitialisation de mot de passe, pour ne pas changer constamment de contexte entre des sujets sans rapport. Quand je ne peux vraiment pas tout traiter pendant mon créneau, je signale le surplus à mon responsable plutôt que de laisser silencieusement des tickets dépasser notre SLA.

J'ai principalement travaillé avec Zendesk et ServiceNow pour la gestion des tickets, et je suis à l'aise avec les deux, même si je trouve la liaison d'actifs de ServiceNow plus utile quand un problème matériel doit être rattaché à l'historique d'un appareil précis. Pour le support à distance, j'ai utilisé TeamViewer et les outils d'assistance à distance intégrés à Windows et macOS, et je confirme toujours avec l'utilisateur avant de prendre le contrôle de son écran plutôt que de me connecter silencieusement. Je garde des notes de ticket suffisamment détaillées pour qu'un collègue puisse reprendre le dossier sans avoir à me poser de questions, y compris les messages d'erreur exacts et les étapes déjà tentées. J'utilise aussi notre wiki interne pour documenter les correctifs des problèmes récurrents, afin que le prochain technicien, ou l'utilisateur lui-même via le self-service, n'ait pas à repartir de zéro. La familiarité avec les outils compte moins pour moi que l'habitude de documenter clairement, car les outils changent d'un employeur à l'autre mais pas cette habitude.

Un petit groupe d'utilisateurs perdait sa connexion VPN toutes les quelques heures, et la solution habituelle était toujours la même : redémarrer le client VPN. J'avais traité le même ticket pour les trois mêmes utilisateurs environ six fois en un mois avant d'arrêter de le considérer comme routinier et de récupérer les logs de connexion. Les trois étaient au même étage du bâtiment et sur le même point d'accès wifi, et les coupures correspondaient à une plage horaire précise chaque après-midi. J'ai découvert que le point d'accès était surchargé pendant une réunion d'équipe récurrente à proximité qui consommait beaucoup de bande passante. J'ai travaillé avec l'équipe réseau pour déplacer ces utilisateurs vers un autre point d'accès et ajuster la configuration des canaux. Les tickets ont complètement cessé. Cela a pris plus de temps que de simplement leur dire de redémarrer le client, mais cela a probablement économisé une vingtaine de tickets par mois à l'équipe, et cela m'a appris à chercher des schémas entre les tickets plutôt que de résoudre chacun isolément.

Un utilisateur a signalé une corruption de données intermittente dans une feuille de calcul partagée modifiée simultanément par plusieurs personnes. J'ai écarté les causes évidentes : version du navigateur, extensions, conflits de synchronisation de fichiers locaux, mais la corruption continuait à se produire de façon imprévisible. Après environ quatre-vingt-dix minutes d'investigation sans piste claire, j'ai reconnu qu'il s'agissait probablement d'un problème de synchronisation côté backend, hors de ce que je pouvais diagnostiquer depuis le poste client, donc j'ai escaladé vers notre équipe de niveau deux avec un compte-rendu complet : ce que j'avais déjà testé, les horodatages exacts de chaque incident de corruption, et la liste des utilisateurs concernés. Je suis resté impliqué plutôt que de tout transmettre, car j'avais le plus de contexte sur le schéma des occurrences. Il s'est avéré que c'était une race condition dans le service de synchronisation, corrigée par le niveau deux avec un patch. J'essaie d'escalader sur la base d'un signal clair indiquant que j'ai atteint la limite de ce que je peux diagnostiquer, pas sur la base d'une limite de temps seule, car escalader trop tôt fait perdre du temps au niveau deux qui doit refaire des vérifications que j'aurais pu faire moi-même.

Une dirigeante m'a appelé furieuse parce qu'elle avait perdu l'accès à une présentation vingt minutes avant un conseil d'administration. Je l'ai laissée s'expliquer sans l'interrompre, j'ai reconnu à quel point le timing était stressant, et je lui ai clairement indiqué ce que je faisais au fur et à mesure, plutôt que de rester silencieux pendant mon investigation. Il s'est avéré que son compte avait été déconnecté automatiquement par une politique de sécurité après un avertissement d'expiration de mot de passe qu'elle avait ignoré. J'ai réinitialisé sa session et l'ai reconnectée en environ quatre minutes, puis j'ai envoyé un court suivi expliquant ce qui s'était passé pour que cela ne la surprenne plus. Je n'ai pas essayé d'expliquer la cause technique pendant qu'elle était sous pression, car ce n'était pas ce dont elle avait besoin à ce moment-là. Ensuite, j'ai signalé à notre équipe sécurité que l'avertissement d'expiration était trop facile à ignorer sans s'en rendre compte, ce qui a conduit à un petit changement de texte qui a réduit les tickets similaires.

Ma première étape est le confinement, pas l'investigation : je déconnecte la machine du réseau, soit en désactivant la carte réseau à distance si j'ai cet accès, soit en la débranchant physiquement, pour stopper toute propagation ou exfiltration de données potentielle avant de faire quoi que ce soit d'autre. Je n'éteins pas la machine immédiatement, car cela pourrait faire perdre des preuves volatiles en mémoire dont notre équipe sécurité pourrait avoir besoin. Je documente le signalement de l'utilisateur, ce qu'il a remarqué, l'heure exacte, et toute action récente comme l'ouverture d'une pièce jointe ou un clic sur un lien. J'escalade immédiatement vers notre équipe sécurité plutôt que d'essayer de remédier moi-même, car l'investigation de compromission dépasse le périmètre standard du support informatique et une mauvaise manipulation peut détruire des preuves. En attendant la sécurité, je vérifie si les autres comptes du même utilisateur montrent une activité suspecte, comme des connexions depuis des lieux inhabituels, pour le signaler aussi. Je préviens également le responsable de l'utilisateur si le compte a accès à des systèmes sensibles, car le confinement doit parfois s'étendre au-delà d'un seul appareil.

Je commence par demander à l'utilisateur de me montrer exactement ce qu'il essaie de faire, car le partage d'écran révèle souvent un contexte qu'une description écrite laisse échapper. Si je ne connais pas le logiciel, je le dis directement plutôt que de deviner, et je consulte notre documentation interne ou je contacte la personne qui l'a mis en place à l'origine. Je cherche des schémas issus de logiciels que je connais : la plupart des outils hérités suivent encore des conventions courantes sur la gestion des fichiers, les permissions ou les fichiers de configuration, ce qui me permet souvent de cerner où se situe probablement le problème même sans connaissance approfondie. Je fais attention à ne pas modifier des systèmes hérités sans comprendre l'impact complet, car les logiciels anciens ont souvent des dépendances non documentées. Si une correction nécessite un changement dont je ne suis pas sûr, je le teste de façon réversible, par exemple en sauvegardant un fichier de configuration avant de le modifier, plutôt que de modifier directement. Je documente ce que j'apprends sur le système au fur et à mesure, car la connaissance des outils hérités a tendance à ne résider que dans la tête de quelques personnes et disparaît quand elles partent.

Je tiens une liste des tickets qui m'ont posé problème ou pris plus de temps que prévu, et je la relis périodiquement pour identifier mes lacunes plutôt que d'attendre qu'une formation me soit attribuée. Je suis les notes de version des éditeurs pour les outils que nous supportons le plus, en particulier notre fournisseur d'identité et notre plateforme de gestion des postes, car beaucoup de tickets remontent à une mise à jour récente qui a changé un comportement par défaut. Je fais partie de quelques communautés de support informatique en ligne où les gens partagent des correctifs pour des problèmes qui ne figurent pas encore dans la documentation officielle, ce qui est souvent plus rapide que d'attendre le support de l'éditeur. Quand je prends en main un nouvel outil, j'essaie vraiment de le casser dans un environnement de test plutôt que de me contenter d'en lire la documentation, car le réflexe de dépannage ne s'acquiert qu'en ayant soi-même provoqué et résolu des problèmes. Je fais aussi de courtes sessions de partage de connaissances avec l'équipe quand je résous quelque chose d'inhabituel, pour que l'apprentissage ne reste pas seulement avec moi.