Problème informatique en entreprise : guide de diagnostic avancé et résolution systémique

Face à un incident, l’expert ne traite pas un symptôme : il exécute un protocole de diagnostic différentiel pour isoler la cause racine, rétablir le service et immuniser l’infrastructure contre la récidive. Ce guide structure l’intervention en 4 phases (Triage, Diagnostic, Résolution, Post-Mortem) et fournit les commandes, les indicateurs et les arbres de décision adaptés à un environnement professionnel.

Phase 1 : Triage et qualification de l’incident

Avant toute action, qualifiez l’incident selon trois axes.

Règle de priorisation : un incident de sécurité (ransomware, exfiltration) prime toujours sur une panne matérielle, même si l’impact utilisateur est moindre.

Phase 2 : Diagnostic systémique par couche

Couche 1 - Poste de travail et OS

Ne vous fiez pas au ressenti utilisateur. Collectez les métriques objectives.

# Linux : identifier le goulot d'étranglement
htop                    # CPU/RAM/Processus en temps réel
iostat -x 1 5           # I/O disque (latence, utilisation %)
vmstat 1 5              # Swap, CPU, IO wait

# Logs applicatifs et système
journalctl -u service-name --since "1 hour ago" -p err
dmesg -T | grep -i error # Erreurs noyau (RAM, disque, PCI)

# Windows : diagnostic rapide en CLI
wmic cpu get load
Get-Process | Sort-Object -Property WorkingSet -Descending
# Event Viewer (Event ID critiques : 41 = shutdown inopiné, 1690 = licence)

Indicateur clé : un iowait > 30% ou une latence disque > 50 ms signale un stockage défaillant.

Couche 2 - Réseau

Un ping ne suffit pas. Identifiez le saut défaillant et mesurez la bande passante réelle.

# Traceroute avec métriques
mtr -r -c 50 8.8.8.8

# Test de bande passante bidirectionnel (iperf3)
iperf3 -c <serveur> -b 100M -t 30 -P 4

# Capture sans interface graphique
tshark -i eth0 -Y "http.response.code >= 500" -T fields -e http.host -e http.request.uri

Règle : une perte de paquets > 1% sur un saut interne indique un équipement réseau (switch, câble) à remplacer.

Couche 3 - Stockage et infrastructure

Un expert interroge le firmware, pas l’OS.

# SMART : prédire une panne disque
smartctl -a /dev/sda | grep -E "Reallocated_Sector|Current_Pending|UDMA_CRC"

# Vérification RAID (si matériel)
mdadm --detail /dev/md0
# Vérification batterie contrôleur RAID
hpssacli ctrl all show status

Seuils d’alerte : tout secteur réalloué non nul est un signal de remplacement immédiat.

Couche 4 - Sécurité : panne ou cyberattaque ?

Le diagnostic différentiel est vital. Une erreur de diagnostic peut transformer une simple panne en brèche de sécurité aggravée.

Règle : si le symptôme est un ralentissement généralisé et progressif (pas brutal), privilégiez la piste matérielle. Si le comportement est soudain et ciblé (un seul service, un seul type de fichier), suspectez une attaque, notamment un phishing dopé à l’IA.

Phase 3 : Résolution et rétablissement

Application du correctif

# Rollback d'un snapshot LVM (Linux)
lvcreate --snapshot --size 10G --name snap_pre_fix /dev/vg/root
# Si le correctif échoue :
lvconvert --merge /dev/vg/snap_pre_fix

# Désinstallation silencieuse d'un correctif Windows
msiexec /uninstall C:\patch\hotfix.msi /quiet
# Restauration d'une version antérieure de fichier (VSS)

Vérification de la stabilité

Après intervention, validez la rémission pendant 30 minutes.

# Surveillance continue
watch -n 5 'dmesg -T | tail -20 ; smartctl -a /dev/sda | grep -E "Reallocated|Pending"'
# Test de charge applicatif
ab -n 1000 -c 10 http://service/health

Phase 4 : Analyse post-mortem (RCA)

Un incident n’est clos que lorsque sa cause racine est documentée et éliminée.

1. Méthode des 5 pourquoi : remontez jusqu’à la cause organisationnelle (ex. : « pourquoi la mise à jour n’a pas été testée ? »).
2. Mise à jour des runbooks : ajoutez le symptôme, le diagnostic et la solution dans votre base de connaissances.
3. Automatisation de la détection : créez une alerte monitoring pour ce signal faible (ex. : SMART Reallocated_Sector > 0).

Outils essentiels du diagnostic expert

Indicateurs de performance (KPIs)

FAQ - Niveau expert

Q : Comment automatiser le diagnostic initial sur un parc hétérogène ?
Déployez un RMM (Remote Monitoring & Management) comme GLPI FusionInventory ou OCS Inventory. Couplé à un outil de supervision (Prometheus + Grafana, Zabbix), il remonte les métriques critiques (SMART, charge CPU, latence réseau) avant même l’ouverture d’un ticket.

Q : Quelle stratégie de rollback adopter pour un correctif système ?
Privilégiez les snapshots LVM ou ZFS avant toute modification. Pour Windows, maintenez un point de restauration automatique avant chaque mise à jour via WSUS ou un script PowerShell. Testez toujours le rollback en préprod.

Q : Comment différencier une panne matérielle d’un rançongiciel au premier coup d’œil ?
Un rançongiciel laisse généralement des fichiers de note (.txt, .html) avec une demande de rançon. Une panne matérielle ne crée pas de fichiers lisibles. Vérifiez aussi l’activité réseau : un rançongiciel génère des connexions sortantes vers des IP inconnues (exfiltration / C2). Utilisez netstat -tupn ou lsof -i pour repérer les connexions suspectes. Les experts en IA doivent aussi se méfier des campagnes d’AitM (Adversary-in-the-Middle) qui ciblent spécifiquement leurs outils et plateformes.