Que testent vraiment les entretiens de technicien support informatique ?

Qui est réellement dans la salle

Pour la plupart des postes de support de première ou deuxième ligne, vous ne rencontrerez pas un recruteur professionnel. Vous rencontrerez le responsable d'équipe du service desk ou le responsable informatique qui gère actuellement les tickets que vous prendriez, parfois accompagné d'un technicien en poste qui pose les questions techniques parce que c'est lui qui doit faire confiance à vos corrections. Dans les petites structures, ce sera peut-être l'unique administrateur système, qui vous reçoit en partie parce qu'il est fatigué et veut quelqu'un capable de prendre des tickets sans en créer de nouveaux.

Il y a souvent un premier échange bref avec les RH ou un recruteur, surtout pour vérifier les attentes salariales, le droit de travailler et le préavis. Cette conversation ne teste pas votre jugement technique et vous ne devez pas trop analyser son déroulement. L'entretien qui détermine l'issue est celui avec la personne qui sera assise près de vous.

L'évaluation pratique, et ce qu'elle vérifie vraiment

Beaucoup d'entretiens pour technicien support incluent quelque chose de pratique, parce que parler de diagnostic et le faire sont deux compétences différentes. La forme varie selon l'employeur, mais les versions courantes sont :

• Un ordinateur portable ou de bureau devant vous avec un défaut introduit volontairement — pas de connexion réseau, un profil utilisateur corrompu, une imprimante qui ne met pas en file d'attente, une machine qui ne dépasse pas l'écran de connexion — et on vous demande de trouver et réparer en expliquant vos étapes à voix haute.
• Un scénario au tableau blanc ou verbal : « un utilisateur appelle et dit que son PC ne peut pas accéder au lecteur partagé, décrivez-moi ce que vous faites ».
• Parfois un test court écrit ou en ligne couvrant des choses comme le calcul de sous-réseaux, les numéros de ports courants, ou la lecture d'une sortie ipconfig /all pour repérer ce qui ne va pas.
• Parfois un appel simulé ou un jeu de rôle, où quelqu'un joue un utilisateur non technique frustré et vous devez obtenir des informations utiles et expliquer une solution sans jargon.

Ce qu'ils vérifient n'est pas si vous trouvez la bonne réponse immédiatement. C'est si vous avez une méthode. Un problème réseau, par exemple, a un ordre d'élimination assez standard : le câble est-il branché, l'adaptateur est-il activé, ipconfig montre-t-il une IP valide ou une adresse APIPA (169.254.x.x, qui vous dit que le DHCP a échoué), pouvez-vous pinguer la passerelle, pouvez-vous pinguer par IP mais pas par nom (ce qui indique du DNS), pouvez-vous résoudre en externe mais pas en interne (ce qui indique un serveur DNS spécifique ou un problème de tunnel fractionné VPN). Un candidat qui commence par là, à voix haute, montre quelque chose qu'un candidat qui dit « j'essaierais de redémarrer, puis réinstaller le pilote réseau, puis réimager » ne montre pas. La seconde réponse pourrait finir par fonctionner. Ce n'est pas du diagnostic, c'est une séquence de suppositions, et quiconque a géré un service desk peut faire la différence en moins d'une minute.

Les questions qui sondent vraiment la compétence

Quelques questions reviennent constamment, et elles accomplissent plus de travail qu'il n'y paraît.

« Décrivez-moi comment vous diagnostiqueriez [X]. » C'est la question centrale. Ils ne veulent pas la destination, ils veulent l'ordre des opérations et le raisonnement à chaque embranchement. Une bonne réponse réduit le problème systématiquement — matériel versus logiciel, local versus réseau, un utilisateur versus plusieurs — et indique ce que chaque test révélerait avant de l'exécuter. Une réponse faible saute directement à la correction qui a fonctionné la dernière fois sur quelque chose de similaire.

« Parlez-moi d'une fois où votre première correction n'a pas fonctionné. » Ceci vérifie deux choses : si vous traitez réellement les tickets de manière autonome plutôt que de toujours faire remonter, et si vous documentez et retestez plutôt que d'essayer des choses au hasard jusqu'à ce que l'une fonctionne. Si votre réponse ne mentionne pas la vérification du journal des événements, le retest après chaque changement, ou la mise à jour du ticket avec ce que vous avez écarté, c'est une lacune qu'ils remarqueront.

« Comment priorisez-vous votre file d'attente ? » Les vrais services desk fonctionnent sur une version de priorité et de SLA — un utilisateur VIP bloqué n'est pas le même ticket qu'un bourrage d'imprimante, et une panne P1 affectant tout un étage prime sur les deux. Si vous parlez de niveaux de priorité, d'impact versus urgence, ou de comment vous géreriez une P1 qui arrive pendant que vous êtes en pleine correction d'autre chose, vous répondez par expérience. Si vous dites « je les traite simplement dans l'ordre », cela leur dit que soit vous n'avez pas travaillé dans un système de tickets avec de vrais SLA, soit vous n'y avez pas réfléchi.

« Expliquez [un défaut technique] à quelqu'un qui n'a jamais utilisé d'ordinateur. » Ce n'est pas une question de remplissage sur les compétences relationnelles. Les techniciens support passent la majeure partie de leur journée à traduire, et quelqu'un qui ne peut pas le faire en salle d'entretien, sans vraie pression, ne le fera pas bien lors d'un appel avec un utilisateur en colère à 16h45. Observez les candidats qui trouvent une analogie et restent brefs, versus ceux qui simplifient le vocabulaire mais gardent la même explication interminable.

Questions sur l'annuaire et les accès. Selon l'environnement, attendez-vous à quelque chose de concret : comment déverrouillez-vous un compte Active Directory, quelle est la différence entre réinitialiser un mot de passe et forcer un changement à la prochaine connexion, comment ajouteriez-vous un utilisateur à un groupe de sécurité versus un groupe de distribution, que vérifiez-vous avant d'accorder un accès élevé à quelqu'un qui l'a demandé. Ce ne sont pas des questions pièges. Elles vérifient que vous avez réellement utilisé AD Users and Computers, ou Intune, ou ce que l'entreprise utilise, plutôt que d'en avoir simplement lu.

Une question de sécurité, presque toujours. Quelque chose comme « un utilisateur vous envoie un email disant qu'il a cliqué sur un lien et maintenant sa machine se comporte bizarrement, que faites-vous en premier ? » Ils veulent l'isolation avant l'investigation — déconnecter du réseau, ne pas encore redémarrer s'il y a une chance de suivi forensique, remonter l'information, ne pas juste lancer un scan antivirus et passer à autre chose. Et quelque part ils sonderont si on vous a déjà demandé votre mot de passe administrateur par quelqu'un prétendant être un manager pressé, et ce que vous avez fait.

À quoi ressemble une réponse superficielle

Les recruteurs peuvent généralement dire en une phrase ou deux quand une réponse est mémorisée plutôt que vécue. Quelques schémas reviennent souvent :

• Nommer la correction sans le diagnostic. « Je réimagerais » comme première ligne de réponse, sans mentionner ce qui vous dirait qu'une réimagerie est réellement nécessaire.
• Traiter le système de tickets comme de la paperasse plutôt qu'un registre. Si vous ne pouvez pas dire ce que vous écririez dans les notes du ticket, ou si vous décrivez la fermeture de tickets sans confirmer la correction avec l'utilisateur, c'est remarqué.
• Réciter du contenu de certification sans histoire attachée. Savoir que le DNS fonctionne sur le port 53 n'est pas la même chose qu'avoir réellement traqué un problème DNS. Si vous détenez CompTIA A+ ou Network+, ou un certificat ITIL Foundation, attendez-vous à ce que cela soit évoqué — mais l'intervieweur sait déjà que beaucoup de gens réussissent ces examens sans pouvoir rien réparer. Ils poseront une question de suivi qui exige que vous ayez réellement fait la chose, pas seulement étudié.
• Langage de propriété vague. « On l'a réparé » ou « l'équipe l'a résolu » quand on demande ce que vous avez personnellement fait.
• Aucune mention de l'utilisateur. Une réponse techniquement correcte qui ne mentionne jamais la vérification auprès de la personne qui a créé le ticket se lit comme quelqu'un qui répare des machines, pas les problèmes des gens.

Ce qu'il faut vraiment préparer

Ayez deux ou trois tickets réels prêts à détailler — pas la panne intéressante qui arrive une fois par an, mais des ordinaires : une imprimante qui ne mettait pas en file d'attente, une déconnexion VPN pour un utilisateur, un verrouillage de compte qui s'est révélé être un identifiant en cache sur un téléphone. Soyez prêt à énoncer, sans qu'on vous le demande, ce que vous avez vérifié et dans quel ordre, et ce que vous auriez fait ensuite si la première chose n'avait pas fonctionné. Si votre poste actuel ou le plus récent utilise une pile spécifique — ServiceNow, Zendesk, Intune, SCCM, une structure AD particulière — connaissez les termes réels que vous utilisez là-bas, car une description vague se lit comme de l'inexpérience même quand ce n'est pas le cas. Et si on vous demande un scénario que vous n'avez vraiment pas géré, dites-le et raisonnez quand même à voix haute ; c'est plus proche de ce qu'est réellement le travail que d'avoir toutes les bonnes réponses.

Si vous envoyez des candidatures et n'obtenez pas de retour avant même d'arriver à cette étape, jobmarket.pro lit l'annonce en entier, la compare à votre expérience réelle, et prépare la candidature à partir de cela plutôt que d'un CV générique.