Il est 8 h 47. La première personne arrivée au bureau essaie d'ouvrir un dossier partagé et obtient un message d'erreur. Elle pense à un problème sur son poste, redémarre, réessaie. À 8 h 55, une deuxième personne signale la même chose. À 9 h 10, tout le monde a compris : le serveur ne répond plus, et la journée qui devait commencer ne commencera pas.
Cette scène se joue plusieurs fois par an dans les entreprises que nous accompagnons. Ce qui varie n'est pas la panne, c'est ce qui se passe pendant les vingt minutes suivantes. Dans certaines structures, quelqu'un applique une série de vérifications simples et trouve la cause en un quart d'heure. Dans d'autres, on débranche des choses au hasard, on redémarre trois fois la mauvaise machine, et on aggrave un incident qui n'était pas grave.
Cet article est la liste des vérifications que nous demandons au téléphone quand un client nous appelle pour cette panne. Elles ne demandent aucune compétence technique particulière, elles se font en quelques minutes, et elles règlent une partie non négligeable des cas. Pour les autres, elles font gagner un temps considérable à celui qui interviendra.
Avant tout : ce que « le serveur ne répond plus » veut dire, et ne veut pas dire
C'est la phrase que nous entendons, et elle recouvre au moins quatre situations très différentes. Les confondre est la première cause de perte de temps.
Il peut s'agir d'une machine éteinte ou bloquée : le serveur lui-même ne fonctionne plus, plus rien ne répond. Il peut s'agir d'un problème de réseau : le serveur va parfaitement bien, mais plus personne ne peut lui parler, parce qu'un commutateur a lâché ou qu'un câble a été arraché. Il peut s'agir d'un service arrêté : la machine tourne, le réseau fonctionne, mais le partage de fichiers ou la base de données du logiciel métier s'est arrêté. Il peut enfin s'agir d'un problème sur un seul poste, celui de la personne qui a signalé l'incident, ce qui n'a rien à voir avec le serveur.
La différence est majeure. Un service arrêté se relance en quelques secondes. Un disque système mort demande une restauration. Un câble débranché se rebranche. Tant qu'on ne sait pas dans quelle catégorie on se trouve, toute action est un pari.
Vérification 1 : est-ce que le problème touche tout le monde ?
C'est la question la plus rentable, et celle qu'on oublie systématiquement dans la précipitation. Demandez à deux ou trois personnes, sur des postes différents, d'essayer d'ouvrir le même dossier ou le même logiciel.
Si une seule personne est touchée, le serveur va probablement bien. Le problème est sur son poste, son câble, sa session ou ses droits d'accès. Vous venez d'économiser une intervention sur une machine qui n'a rien.
Si tout le monde est touché, le problème est en amont : le serveur, le réseau, ou l'électricité. On passe à la suite.
Si certains sont touchés et d'autres non, regardez ce qui les distingue. Les personnes en difficulté sont-elles toutes dans le même bureau, sur le même étage, en Wi-Fi plutôt qu'en filaire ? Ce découpage désigne presque toujours l'équipement fautif : un commutateur d'étage, une borne, une prise murale.
Vérification 2 : regarder la machine, physiquement
Cela paraît trivial, et pourtant c'est l'étape que personne ne fait, souvent parce que le serveur est dans un local qu'on n'ouvre jamais. Allez le voir. Trois choses se lisent en dix secondes.
Le voyant d'alimentation. S'il est éteint, la question n'est plus informatique : elle est électrique. Vérifiez la prise, l'onduleur, le disjoncteur. Un onduleur en fin de vie qui a cessé de délivrer du courant est une cause bien plus fréquente qu'on ne l'imagine, et il n'a prévenu personne.
Les voyants de disque. Sur la plupart des serveurs et des baies, un disque défaillant s'annonce par un voyant orange ou rouge. Si vous en voyez un, notez sa position exacte : c'est une information précieuse pour celui qui interviendra, et cela évite de toucher au mauvais disque.
Le bruit et la chaleur. Un serveur dont les ventilateurs hurlent, ou un local nettement plus chaud que d'habitude, indique un problème de refroidissement. En été, dans un placard mal ventilé, c'est une cause de panne classique. Si la pièce est brûlante, ouvrez la porte avant toute chose.
Vérification 3 : le réseau entre le serveur et vous
Si la machine est allumée et paraît normale, le problème est peut-être entre elle et vos postes. Là encore, quelques observations valent mieux qu'un redémarrage.
Sur le serveur, regardez le voyant du port réseau : il doit clignoter. S'il est éteint, le câble est débranché, coupé, ou le commutateur en face est hors service. Sur le commutateur, vérifiez que les voyants s'allument normalement et qu'aucun port ne clignote de façon anarchique.
Un cas particulier mérite d'être connu : après un déplacement de mobilier, des travaux ou un ménage un peu énergique, un câble à demi sorti de sa prise produit une panne intermittente, la pire à diagnostiquer. Enfoncez fermement les câbles réseau du serveur et du commutateur, vous entendrez le clic.
Autre grand classique, en particulier dans les entreprises qui ont grandi sans plan : quelqu'un a branché un nouvel équipement, et deux câbles relient maintenant le même commutateur à lui-même. Le réseau s'effondre alors sans qu'aucune machine ne soit en cause. Si un câble a été touché la veille, c'est la première piste.
Vérification 4 : la machine répond-elle du tout ?
Si vous êtes à l'aise, une seule commande vous dira beaucoup. Depuis un poste, ouvrez une invite de commandes et tapez ping suivi de l'adresse du serveur, que votre prestataire vous a normalement communiquée.
Si le serveur répond, la machine est vivante et le réseau fonctionne. Votre problème est un service arrêté, une session bloquée ou un souci de droits. C'est plutôt une bonne nouvelle : ces incidents se règlent souvent à distance, en quelques minutes, sans déplacement.
Si le serveur ne répond pas, soit la machine est éteinte ou plantée, soit le chemin réseau est coupé. Croisez avec ce que vous avez vu sur les voyants pour trancher.
Notez la réponse exacte, même si elle ne vous parle pas. « Délai d'attente dépassé » et « hôte de destination inaccessible » ne veulent pas dire la même chose, et cette nuance oriente immédiatement le diagnostic de celui que vous appellerez.
Le tableau des symptômes les plus fréquents
| Ce que vous observez | Cause la plus probable | Ce que vous pouvez faire |
|---|---|---|
| Une seule personne est bloquée, les autres travaillent | Poste, câble ou session de cette personne | Redémarrer son poste, essayer une autre prise réseau |
| Tout le monde est bloqué, le serveur est éteint | Alimentation, onduleur ou disjoncteur | Vérifier la prise et l'onduleur, ne pas rallumer en boucle |
| Le serveur est allumé mais ne répond pas au ping | Machine plantée, ou lien réseau coupé | Regarder le voyant du port réseau et celui du commutateur |
| Le serveur répond au ping, mais le logiciel ne s'ouvre pas | Un service ou une base de données arrêté | Appeler : cela se relance en général à distance |
| Lenteurs extrêmes, sans blocage complet | Disque saturé, disque en train de lâcher, ou sauvegarde en cours | Noter l'heure exacte et signaler tout voyant orange |
| Panne après une coupure de courant | Serveur non redémarré, ou système de fichiers à vérifier | Ne pas forcer plusieurs redémarrages successifs |
Votre « serveur » en est-il vraiment un ?
La question n'est pas rhétorique, et la réponse change les vérifications à faire. Dans les TPE que nous accompagnons, le mot « serveur » désigne au moins trois objets très différents.
Ce peut être un vrai serveur, une machine conçue pour tourner en continu, avec plusieurs disques en grappe et une alimentation redondante. Ce peut être un NAS, ce boîtier à deux ou quatre disques qui sert de dossier partagé commun et que tout le monde appelle le serveur par commodité. Ce peut enfin être un simple ordinateur de bureau promu serveur au fil des ans, posé sous une table, qui héberge le logiciel de gestion parce qu'un jour il a fallu faire vite.
Le troisième cas est plus répandu qu'on ne l'admet, et il mérite d'être identifié à froid plutôt qu'un matin de panne. Un poste de bureau n'est pas fait pour fonctionner nuit et jour : son disque unique n'a aucune redondance, son alimentation n'est pas prévue pour cet usage, et il suffit qu'une personne l'éteigne en partant pour bloquer toute l'entreprise le lendemain. Si c'est votre situation, la panne du jour n'est pas un accident, c'est une échéance.
Pour un NAS, les vérifications de cet article s'appliquent presque toutes, avec une nuance : ces boîtiers ont souvent une interface accessible depuis un navigateur, et le fait qu'elle réponde ou non est une information de diagnostic à part entière. Nous consacrons un article entier au cas où un NAS disparaît du réseau.
Ce qu'il faut dire quand vous appelez
La qualité de votre appel détermine largement la vitesse de la résolution. Un technicien qui reçoit les bonnes informations en deux minutes peut souvent agir immédiatement ; le même, face à « ça ne marche plus », passe un quart d'heure à poser des questions.
Dites d'abord qui est touché : tout le monde, un service, une personne. C'est l'information la plus discriminante, et c'est celle qu'on oublie le plus.
Dites ensuite depuis quand, et ce qui a changé la veille. Une mise à jour, un nouvel équipement branché, une coupure de courant, des travaux, une intervention d'un autre prestataire. Les pannes surgissent rarement toutes seules, et cette phrase oriente le diagnostic plus sûrement que n'importe quel message d'erreur.
Dites ce que vous avez déjà fait, y compris ce qui vous paraît anodin ou maladroit. Savoir que la machine a été redémarrée quatre fois, ou qu'un câble a été échangé, évite de repartir sur de fausses pistes. Personne ne vous jugera : cette information fait gagner du temps.
Enfin, lisez le message d'erreur exact, mot pour mot, plutôt que de le résumer. Photographiez l'écran si c'est plus simple. Un intitulé précis désigne souvent la cause à lui seul, là où une reformulation approximative envoie chercher ailleurs.
Les trois gestes à ne surtout pas faire
Ne redémarrez pas le serveur en boucle. C'est le réflexe le plus naturel et le plus dangereux. Sur une machine dont un disque est en train de mourir, chaque redémarrage forcé réduit les chances de récupérer les données intactes. Un redémarrage propre, une fois, est acceptable. Cinq coupures d'alimentation d'affilée transforment un incident réparable en perte de données.
Ne débranchez pas de disque pour « voir ». Dans une grappe de disques, retirer le mauvais disque pendant que le système tente de se reconstruire est la manœuvre qui fait passer d'une panne à un sinistre. Si un voyant est orange, notez sa position et laissez la machine tranquille.
N'effacez rien pour faire de la place. Quand un disque saturé provoque une panne, la tentation est de supprimer des fichiers rapidement. C'est souvent ainsi que disparaissent des données dont personne n'avait mesuré l'importance, ou que l'espace libéré est immédiatement repris par le même processus qui l'avait rempli. Signalez la saturation, ne la traitez pas dans l'urgence.
Quand arrêter de chercher et passer un appel
Nous encourageons ces vérifications, mais nous encourageons tout autant à savoir s'arrêter. Appelez sans attendre dans trois situations.
Dès qu'un voyant de disque est anormal. C'est le seul cas où chaque minute compte réellement, parce qu'une grappe dégradée peut encore se reconstruire tant qu'un second disque n'a pas lâché.
Dès que la panne suit un événement inhabituel : orage, coupure de courant, dégât des eaux, travaux. L'incident visible cache souvent un dommage plus large.
Dès que vous envisagez une manipulation dont vous ne maîtrisez pas les conséquences. Un quart d'heure d'attente coûte toujours moins cher qu'une fausse manœuvre. Nous qualifions ces demandes par téléphone le jour même, et la majorité des incidents réseau, serveur et logiciel se règle par une prise de main sécurisée, sans déplacement.
Ce que cette panne révèle presque toujours
Quand nous intervenons sur un serveur qui ne répond plus, la panne du jour est rarement le sujet principal. Ce que nous trouvons derrière est presque toujours le même trio.
Une sauvegarde qui ne tournait plus depuis des semaines ou des mois, sans que personne ait été alerté. C'est le point le plus grave, et il ne se découvre qu'au pire moment. Une sauvegarde dont personne n'a jamais tenté la restauration n'est pas une sauvegarde, c'est une intention.
Un équipement en bout de course dont les signes avant-coureurs étaient visibles depuis longtemps : disque en préalarme, ventilateur bruyant, redémarrages inexpliqués. Aucun de ces signaux n'était surveillé, donc aucun n'a été vu.
Une dépendance non documentée : personne ne savait que le logiciel de facturation, la caisse ou le partage des devis reposaient tous sur cette même machine. L'entreprise découvre son propre point de fragilité le jour où il cède.
C'est précisément ce que change la supervision. Un disque qui commence à générer des erreurs, une sauvegarde en échec, un espace disque qui se remplit : ce sont des événements qui s'annoncent, souvent des jours à l'avance. Encore faut-il que quelqu'un les reçoive. Nous détaillons cette logique dans notre guide de l'infogérance et de la maintenance, et la question de la sauvegarde dans votre sauvegarde n'a jamais été restaurée.
Préparer la prochaine fois, en une demi-heure
Il y aura une prochaine fois : c'est la seule certitude en matière de matériel. Une demi-heure de préparation, prise un jour calme, change complètement le déroulement.
Écrivez une fiche d'urgence et affichez-la dans le local technique : l'adresse du serveur, le numéro de votre prestataire, l'emplacement de l'onduleur et du disjoncteur, la liste de ce qui dépend de cette machine. Une page suffit. Le jour de la panne, elle vaut de l'or, y compris quand la personne qui sait tout est en congé.
Décidez à l'avance de ce qui doit repartir en premier. Toutes les fonctions n'ont pas la même urgence : encaisser, facturer et accéder aux dossiers en cours passent généralement avant la messagerie ou l'archive. Cet ordre, écrit une fois, évite des discussions au pire moment.
Enfin, faites vérifier votre sauvegarde par une restauration réelle, sur un fichier quelconque. C'est le seul test qui prouve quelque chose, et il prend dix minutes. Notre article sur la règle du 3-2-1 explique quoi viser.
Un serveur muet ne doit pas arrêter votre entreprise
La plupart des pannes de serveur que nous traitons n'étaient ni imprévisibles ni graves : elles étaient simplement invisibles jusqu'au moment où elles ont bloqué tout le monde. Les vérifications de cet article vous feront gagner du temps le jour venu, et vous éviteront surtout les trois gestes qui transforment un incident en perte de données.
Chez ELS Conseil, à Saint-Rémy-de-Provence, nous administrons et surveillons les serveurs des TPE et PME des Bouches-du-Rhône et du Vaucluse limitrophe, d'Arles à Salon-de-Provence, de Châteaurenard à Avignon. Nous qualifions votre panne par téléphone dans la journée, nous la traitons le plus souvent à distance, et nous nous déplaçons sous 24 à 48 heures quand il faut remplacer un équipement, sans contrat préalable. Si votre serveur vous inquiète, ou s'il vient de vous lâcher, appelez-nous au 04 13 41 85 81, écrivez-nous depuis notre page Contact, ou voyez le déroulé complet sur notre page dépannage réseau, serveur et logiciel.