C'est parfaitement sérieux, et derrière la blague se cache une vraie logique technique qu'il est utile de comprendre pour l'expliquer sans avoir l'air de botter en touche. Un système en fonctionnement accumule un état : des programmes chargés en mémoire, des processus qui tournent, des fichiers temporaires, des connexions réseau ouvertes, des ressources réservées, des pilotes actifs. Avec le temps ou à la suite d'une opération qui a mal tourné, cet état peut se corrompre : de la mémoire mal libérée, un processus bloqué qui ne rend pas la main, une ressource verrouillée, un service qui s'est arrêté anormalement, une configuration chargée qui ne correspond plus à la réalité. Le redémarrage repart d'un état propre et connu : tout est déchargé puis rechargé proprement, les fichiers temporaires problématiques sont ignorés, les processus bloqués disparaissent, les pilotes se réinitialisent, et de nombreuses opérations en attente (comme certaines mises à jour) se finalisent. C'est pourquoi il résout une part énorme des incidents logiciels — non par magie, mais parce qu'il élimine d'un coup toute une classe de problèmes liés à l'état accumulé. Cela dit, deux nuances de professionnel. D'abord, le redémarrage traite le symptôme, pas toujours la cause : si un problème revient systématiquement après chaque redémarrage, c'est qu'il y a une cause de fond (un logiciel défectueux, un pilote instable, un service mal configuré) qu'il faut identifier et corriger — se contenter de redémarrer en boucle n'est pas une solution. Ensuite, en support, proposer le redémarrage n'est pas se moquer de l'utilisateur : c'est le geste au meilleur rapport efficacité/effort, à tenter tôt dans la démarche. La bonne pratique consiste à le proposer après avoir rapidement cerné le symptôme (pour ne pas passer à côté d'une évidence comme un câble débranché), et à creuser la cause si le problème persiste ou récidive. « Avez-vous redémarré ? » est donc une excellente première étape — à condition de savoir aussi aller plus loin quand elle ne suffit pas.

C'est la première grande bifurcation du diagnostic, et bien la trancher fait gagner énormément de temps. Plusieurs indices et tests permettent d'orienter. Les signaux physiques pointent vers le matériel : bruits anormaux (clic répété d'un disque mourant, ventilateur emballé), bips au démarrage, voyants d'erreur, surchauffe, odeur de brûlé, écran qui ne s'allume pas du tout, machine qui ne démarre pas ou s'éteint brutalement, artefacts à l'écran. Un problème qui survient avant même le chargement de Windows (dès l'allumage, dans le BIOS/UEFI) est presque toujours matériel. Les symptômes logiciels, à l'inverse : messages d'erreur du système ou d'une application, plantage d'un logiciel précis, lenteurs apparues après une mise à jour ou une installation, problème qui ne concerne qu'un utilisateur ou qu'un programme. Le test par substitution est décisif pour le matériel : remplacez l'élément suspect par un équivalent connu comme fonctionnel (un autre câble, un autre écran, une autre souris, une barrette de RAM) ; si le problème disparaît, le composant était en cause. Le test croisé aide aussi : le périphérique fautif fonctionne-t-il sur une autre machine ? La machine fonctionne-t-elle avec un autre périphérique ? Le test logiciel par excellence : démarrer en mode sans échec (Windows charge un minimum de pilotes et de logiciels) — si le problème disparaît en mode sans échec, il est probablement logiciel (un pilote ou un programme au démarrage) ; s'il persiste, la piste matérielle se renforce. Le principe du dernier changement tranche souvent : « ça a cassé juste après une mise à jour / une installation » oriente vers le logiciel ; « juste après un choc, un ajout de matériel, une coupure de courant » oriente vers le matériel. Enfin, l'étendue du problème renseigne : un seul logiciel touché = logiciel ; toute la machine instable de façon aléatoire = souvent matériel (RAM, alimentation, surchauffe). En combinant ces indices — signaux physiques, substitution, mode sans échec, dernier changement, étendue — on classe rapidement la panne du bon côté, ce qui détermine toute la suite du dépannage.