Conduis un diagnostic et une remédiation

01Commence par le symptôme exact

Un utilisateur dit :

"L'intranet ne marche plus."

Ce message est un point de départ, pas un diagnostic.

Transforme-le en observations :

Quel utilisateur ?
Quel poste ?
Quel réseau ?
Quelle URL ou quel service ?
Depuis quand ?
Tous les utilisateurs ou un seul ?
Erreur affichée ou délai d'attente ?
Le service fonctionne-t-il depuis un autre poste ?
Un changement récent est-il connu ?

Plus le symptôme est précisément borné, moins tu testes au hasard.

02Sépare fait et hypothèse

Fait
Le poste CLIENT-04 résout intranet.soria.lab vers 10.20.30.15.

Fait
La connexion TCP vers 10.20.30.15:443 expire.

Hypothèse
Un pare-feu bloque le flux.

L’hypothèse peut être correcte, mais d’autres causes restent possibles :

service non démarré
service qui n'écoute pas sur la bonne adresse
route absente
ACL intermédiaire
mauvaise passerelle
machine indisponible

N’écris pas une hypothèse comme si elle était déjà prouvée.

03Établis l’état de référence

Avant de chercher la panne, demande : « quel était le comportement attendu ? »

Pour l’intranet :

client autorisé
→ résolution DNS correcte
→ route vers le réseau serveur
→ flux TCP 443 autorisé
→ service en écoute
→ TLS présenté
→ application répond

Cette chaîne te donne les dépendances à vérifier.

Sans état de référence, un résultat inhabituel peut être pris à tort pour la cause.

04Réduis le périmètre

Teste d’abord si le problème est :

un utilisateur
un poste
un VLAN
un site
un service
une application
l'ensemble du système

Exemple :

CLIENT-04 échoue
CLIENT-05 réussit

La panne est alors probablement plus locale que si tous les clients du VLAN échouent.

Le périmètre est une information de diagnostic à part entière.

05Teste les dépendances dans un ordre explicable

Pour un service réseau, une méthode simple consiste à avancer du plus fondamental vers le service final :

1. état du poste
2. adressage local
3. passerelle / route
4. résolution de nom
5. connectivité vers l'hôte
6. port attendu
7. état du service
8. authentification / autorisation
9. comportement applicatif

Ce n’est pas une recette universelle. L’ordre peut changer selon le symptôme, mais tu dois pouvoir expliquer pourquoi tu testes une couche avant une autre.

06Choisis un test discriminant

Un bon test sépare plusieurs hypothèses.

Exemple :

Hypothèse A : DNS incorrect
Hypothèse B : service HTTPS indisponible

Test 1
Résoudre intranet.soria.lab.

Si le nom ne se résout pas : A gagne en crédibilité.
Si le nom se résout correctement : A perd en crédibilité, mais B reste possible.

Test 2
Tester directement 10.20.30.15:443.

Le but n’est pas d’accumuler des commandes. Le but est d’obtenir de l’information qui change ton raisonnement.

07Tiens un tableau d’hypothèses

H1 — DNS incorrect
Indice pour : erreur de résolution observée sur CLIENT-04
Indice contre : CLIENT-05 résout correctement
État : possible, plutôt local au client

H2 — service web arrêté
Indice pour : délai d'attente
Indice contre : CLIENT-05 accède au site
État : peu probable

H3 — configuration réseau locale du CLIENT-04
Indice pour : panne limitée à un poste
État : à tester en priorité

Les états possibles peuvent rester simples :

À TESTER
SOUTENUE
AFFAIBLIE
RÉFUTÉE
INCONCLUSIVE

Une hypothèse inconclusive n’est ni vraie ni fausse : les preuves disponibles ne suffisent pas.

08Observe avant de modifier

Avant une remédiation, conserve les éléments utiles :

configuration actuelle
état des services
routes
règles concernées
journaux autour de l'heure de la panne
ticket ou chronologie
changement récent connu

Évite le réflexe :

redémarrer tout
vider tous les caches
réinitialiser le pare-feu
désactiver la sécurité
réinstaller le service

Ces actions peuvent masquer la cause et agrandir l’impact.

09Choisis la correction la plus bornée

Supposons qu’une mauvaise adresse DNS ait été configurée sur un seul client.

Correction proportionnée :

corriger la configuration DNS du client concerné
→ renouveler ou appliquer la configuration si nécessaire
→ refaire le test de résolution
→ refaire le test du service

Correction disproportionnée :

modifier tous les clients
redémarrer les serveurs DNS
changer la zone DNS

La bonne remédiation traite la cause démontrée avec le plus petit rayon d’impact raisonnable.

10Prépare le retour arrière

Avant un changement qui peut aggraver la situation :

état avant changement
modification prévue
condition de réussite
condition d'arrêt
méthode de retour arrière
preuve après rollback

Exemple :

Changement
modifier une règle de pare-feu de laboratoire.

Condition d'arrêt
un flux qui devait rester interdit devient accessible.

Rollback
restaurer la règle précédente.

Validation
refaire test positif + test négatif.

Un rollback non testé est seulement une intention.

11Vérifie le service, pas seulement la commande

Une correction n’est pas validée parce que la commande s’est exécutée sans erreur.

Après correction :

1. vérifier le composant modifié
2. refaire le test qui échouait
3. vérifier le service du point de vue utilisateur
4. vérifier un comportement qui devait rester intact
5. si pertinent, réaliser un test négatif

Exemple : réparer DNS puis vérifier uniquement nslookup est utile, mais si le besoin était d’accéder à l’intranet, la recette doit aller jusqu’au service attendu.

12Documente le niveau de certitude

Tu n’auras pas toujours la preuve parfaite.

Écris clairement :

Cause confirmée
La modification X reproduit la panne et son rollback la supprime.

Cause fortement soutenue
Plusieurs indices convergent mais la reproduction n'est pas possible.

Cause probable
Les éléments disponibles sont compatibles mais d'autres causes restent ouvertes.

Cause inconnue
Le service est revenu, mais aucune preuve ne permet d'attribuer le rétablissement à une cause certaine.

« Le problème a disparu » n’est pas équivalent à « la cause a été identifiée ».

13Sais quand arrêter ou escalader

Arrête l’expérimentation si :

le changement peut détruire une preuve utile
le périmètre réel dépasse ton autorisation
un risque de perte de données apparaît
l'infrastructure critique est concernée
les informations sont insuffisantes pour agir sûrement
une compétence ou validation externe est nécessaire

Escalader avec un dossier propre est une compétence professionnelle : symptômes, faits, tests déjà faits, hypothèses, résultats et actions évitées.

14Rédige le compte rendu de remédiation

Structure minimale :

Incident
- symptôme
- périmètre
- impact

Diagnostic
- faits initiaux
- hypothèses
- tests
- conclusion et niveau de certitude

Remédiation
- action
- risque
- rollback

Validation
- test initial rejoué
- test de service
- test négatif si pertinent

Limites et suite
- ce qui n'a pas été démontré
- surveillance ou action restante

Cette structure pourra être reliée au ticket, au changement et au dossier de preuves.