Panne informatique : que faire dans les premières minutes.

1. Qualifier l’étendue : un poste, une équipe ou tout le site ?

Le premier réflexe n’est pas technique : c’est une question. Qui est touché ? Un seul poste oriente vers un problème local — machine, session, câble. Plusieurs personnes sur la même application orientent vers un serveur, un service ou des droits d’accès. Tout le site, téléphonie et Internet compris, oriente vers le réseau ou le lien opérateur. Cette réponse conditionne la criticité de l’incident et l’ordre des vérifications.

Deux tests rapides aident à situer la panne. Reproduisez l’action depuis un autre poste : si elle fonctionne, le problème est local. Testez ensuite un service en ligne depuis un partage de connexion mobile : s’il répond par ce chemin et pas par votre réseau, la cause est chez vous ou sur votre lien, pas chez le service.

• Un seul poste touché : machine, session ou périphérique.
• Une équipe ou une application : serveur, service ou droits d’accès.
• Tout le site, téléphonie comprise : lien opérateur ou équipement réseau central.

2. Ne pas aggraver : ce qu’il ne faut pas faire

Sous pression, certains réflexes font plus de dégâts que la panne. N’éteignez pas un serveur qui ne répond plus en coupant l’alimentation : un arrêt brutal peut corrompre les données en cours d’écriture et transformer un incident en sinistre. Multiplier les redémarrages efface les indices et retarde le diagnostic.

Si des fichiers deviennent illisibles, changent d’extension ou qu’un message de rançon s’affiche, changez de registre : vous n’êtes plus face à une panne, mais à un incident de sécurité. Isolez la machine du réseau — câble débranché, Wi-Fi coupé — sans l’éteindre, et cessez d’utiliser les comptes concernés. Ne payez pas de rançon : payer finance l’attaquant sans vous assurer de récupérer vos données, et les autorités françaises recommandent de ne pas céder.

Dans tous les cas, n’effacez rien et ne réinstallez rien avant l’analyse : la restauration se fait depuis des copies saines, vers un environnement contrôlé — ce qu’un plan de reprise documente précisément.

3. Collecter les symptômes pendant qu’ils sont visibles

Un message d’erreur exact vaut mieux qu’un résumé de mémoire. Photographiez l’écran avant tout redémarrage : le libellé précis, le code éventuel, l’application concernée. Notez l’heure d’apparition et ce qui fonctionne encore — la messagerie répond mais pas l’application métier, Internet passe mais pas les fichiers partagés. Ces contrastes orientent le diagnostic.

Cherchez ensuite ce qui a changé récemment : une mise à jour, une installation, une coupure électrique, un orage, une intervention dans le local technique. Une panne qui suit un changement a souvent un lien avec lui. Rien de tout cela ne demande de compétence technique — seulement de l’attention, au bon moment.

4. Escalader par un canal unique, avec les bonnes informations

Une panne qui touche toute une équipe ne justifie pas un appel par personne. Désignez un interlocuteur unique côté entreprise et ouvrez un seul ticket — ou passez un seul appel — qui concentre ce que vous avez collecté. Un support organisé enregistre chaque demande, la qualifie par criticité puis l’attribue ; des signalements dispersés ralentissent ce tri au lieu de l’accélérer.

Décrivez l’impact métier sans le minorer ni le dramatiser : quelles fonctions sont arrêtées, quelles échéances approchent — paie, livraison, clôture. C’est cette qualification qui déclenche le niveau de réponse prévu ; les engagements de délai (GTI, GTR) relèvent de votre contrat de service. Le diagnostic commence à distance, et une intervention sur site se planifie lorsqu’elle est nécessaire.

• Le périmètre : qui est touché, depuis quand.
• Les symptômes exacts, et ce qui fonctionne encore.
• Les changements récents et les échéances métier.
• Un numéro de rappel qui ne dépend pas de la panne.

5. Organiser l’attente : mode dégradé et communication

Pendant le diagnostic, la question n’est plus technique mais organisationnelle : que maintient-on, que suspend-on ? Selon la panne, des contournements existent — passage en télétravail si les services en ligne répondent, renvoi de la téléphonie si votre installation le prévoit, bascule sur un lien de secours s’il en existe un. Ces solutions se préparent avant l’incident ; le jour même, on ne fait que les appliquer.

Communiquez factuellement, d’une seule voix : ce qui est touché, ce qui est en cours, la date du prochain point. En interne d’abord, puis vers les clients si l’interruption les concerne. Si l’ampleur dépasse l’incident courant — sinistre, cyberattaque —, la décision d’activer un plan de reprise revient à votre direction, sur la base d’une situation instruite avec votre prestataire.

6. Après le rétablissement : transformer la panne en information

Une panne résolue n’est pas soldée pour autant : elle a révélé quelque chose. Tout incident significatif mérite une analyse de cause, car un incident qui se répète a une cause de fond — un disque qui sature, un correctif absent, une machine en bout de course. Demandez un compte rendu et vérifiez que la résolution est documentée, pour que la connaissance ne reste pas dans la tête d’un seul intervenant.

Observez aussi ce que l’incident dit de votre organisation. La panne a-t-elle été détectée par une supervision ou par les utilisateurs ? Une restauration aurait-elle été possible, et depuis quelles copies ? Le numéro du support était-il connu de tous ? Ces réponses valent un audit : elles indiquent où renforcer avant la prochaine fois.