C'est une réticence naturelle — « c'est plus long de créer le ticket que de régler le problème » — mais tracer systématiquement, même les petits cas, est l'une des marques d'un service IT mature, pour des raisons qui dépassent le cas individuel. D'abord, la mesure : sans traçabilité, il est impossible de connaître la charge réelle du support. Ces « petits problèmes de deux minutes », multipliés par des dizaines par jour, représentent une part énorme de l'activité — et s'ils ne sont pas tracés, ils sont invisibles, ce qui empêche de justifier des moyens, de repérer les surcharges et de dimensionner l'équipe. Ensuite, la détection de tendances : dix « petits » tickets identiques révèlent un problème de fond (un poste mal configuré, une application boguée, un manque de formation des utilisateurs) qu'un traitement au coup par coup ne verrait jamais. Le ticket transforme des incidents isolés en données exploitables qui permettent de traiter la cause, pas seulement les symptômes. Puis la base de connaissances : une solution notée aujourd'hui fait gagner du temps demain, à vous ou à un collègue, surtout pour les problèmes qui reviennent. La continuité aussi : si vous êtes absent, ou si le « petit » problème s'avère finalement plus complexe, l'historique existe. Et la traçabilité : en cas de contestation ou d'audit, il faut pouvoir dire qui a demandé quoi, qui a fait quoi, quand. Cela dit, la réticence contient une part de vérité qu'un bon service prend en compte : la traçabilité ne doit pas devenir un fardeau qui décourage. La solution n'est pas de renoncer à tracer, mais de rendre la création de ticket rapide : modèles pré-remplis pour les cas fréquents, catégories prédéfinies, création en quelques clics. Certains outils permettent même de tracer a posteriori en fin de journée les micro-interventions. La règle professionnelle : on trace tout, mais on rend le traçage léger. Un service qui ne trace « que les gros problèmes » se prive de la vision d'ensemble qui permet de s'améliorer.

Trouver le bon moment pour escalader est un vrai savoir-faire, à mi-chemin entre deux erreurs symétriques : escalader trop tôt (on ne progresse pas, on surcharge le N2, on passe pour incompétent) et escalader trop tard (on fait perdre un temps précieux à l'utilisateur en s'acharnant seul). Plusieurs critères aident à décider. Le premier, le plus clair : le périmètre de compétence et de droits. Certaines interventions dépassent le rôle du N1 par nature — modifier une configuration serveur, agir sur l'Active Directory, toucher au réseau cœur, accéder à des systèmes sensibles — soit parce que vous n'avez pas les compétences, soit parce que vous n'avez pas (et ne devez pas avoir) les droits. Dans ces cas, on escalade sans hésiter : ce n'est pas un échec, c'est le fonctionnement normal des niveaux. Le deuxième critère : le temps raisonnable au regard de l'enjeu. Fixez-vous mentalement une limite proportionnée : quelques minutes pour un problème courant, un peu plus pour un cas inhabituel — mais au-delà, si vous n'avez pas progressé, l'acharnement coûte plus qu'il ne rapporte. Le troisième : l'impact et l'urgence. Un problème qui bloque une personne peut supporter que vous cherchiez un moment ; un problème qui bloque tout un service ou touche à la sécurité doit être escaladé immédiatement, en parallèle de vos propres tentatives — on ne fait pas patienter une panne majeure pour sauver son amour-propre. Le quatrième : votre progression. Si vous avancez, que vous éliminez des pistes, il est légitime de continuer un peu ; si vous tournez en rond et refaites les mêmes tests, c'est le signal d'escalader. Point crucial pour bien escalader : transmettez un dossier complet — le symptôme exact, ce que vous avez déjà testé et écarté, les messages d'erreur, le contexte (dernier changement, nombre de personnes touchées). Une escalade « le PC de M. X ne marche pas » sans contexte fait recommencer tout le diagnostic et agace le N2. Enfin, voyez l'escalade comme un moment d'apprentissage : demandez comment le N2 a résolu le cas, notez-le, et la prochaine fois vous saurez le traiter vous-même. Escalader intelligemment, c'est à la fois servir l'utilisateur et progresser.