Objectif
Collecter avant escalade un ensemble d’informations reproductibles qui permette à un autre technicien, un éditeur ou une équipe sécurité de comprendre rapidement le symptôme, son périmètre, sa chronologie et les tests déjà effectués, tout en protégeant les données sensibles.
Prérequis
- Numéro de ticket ou emplacement de collecte et canal sécurisé pour les pièces jointes.
- Accès au poste, serveur ou équipement concerné.
- Nom du service, utilisateur ou application impacté et heure approximative du symptôme.
- Liste des changements récents connus : mise à jour, règle firewall, certificat, mot de passe, migration, déploiement.
- Autorisation de collecter les logs nécessaires selon les règles internes.
Procédure pas à pas
Écrire le symptôme et le résultat attendu
Commencez par deux phrases : ce qui se passe et ce qui devrait se passer. Évitez les formulations vagues comme « ça ne marche pas ». Reproduisez le message exact, le code d’erreur et l’action qui déclenche le problème. Si le symptôme est intermittent, indiquez sa fréquence et la dernière heure connue.
- Le lecteur peut comprendre le problème sans appeler immédiatement l’utilisateur.
Définir l’étendue de l’incident
Précisez si le problème concerne un utilisateur, un poste, un serveur, un VLAN, un site, tous les clients ou une application donnée. Comparez si possible avec un équipement ou un compte fonctionnel. Cette comparaison transforme souvent une escalade générale en hypothèse ciblée : profil utilisateur, réseau local, serveur central ou service cloud.
- Le ticket distingue cas isolé, groupe impacté et impact global.
Créer une chronologie normalisée
Notez l’heure de début, les tentatives de reproduction et les changements récents dans un même fuseau. Pour les environnements multi-sites ou cloud, ajoutez UTC lorsque cela facilite la corrélation. Une chronologie simple suffit : 14:02 erreur utilisateur, 14:07 reproduction technicien, 14:10 règle firewall vérifiée, 14:15 logs exportés.
Get-Date -Format "yyyy-MM-dd HH:mm:ss K"w32tm /query /status- Les événements provenant de plusieurs systèmes peuvent être corrélés sans ambiguïté.
Collecter l’identité technique du système
Relevez nom de machine, OS, version, IP, domaine et version de l’application concernée. Sur Windows, systeminfo et les cmdlets réseau donnent rapidement un état de référence. Sur un équipement réseau, relevez modèle, firmware et numéro de série si l’escalade va vers l’éditeur. N’envoyez pas tout l’inventaire du SI si seul un composant est concerné.
hostnamesysteminfoGet-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber,CsNameipconfig /all- La version exacte du système et sa configuration réseau de base sont connues.
Exporter les journaux autour de l’heure de l’incident
Collectez une fenêtre temporelle limitée autour du problème plutôt qu’un export énorme sans contexte. Sous Windows, filtrez Application, System ou un journal applicatif par StartTime et exportez les événements pertinents. Conservez le fichier EVTX lorsque l’équipe de niveau supérieur doit analyser les champs complets, et ajoutez une courte synthèse des événements qui vous semblent liés.
Get-WinEvent -FilterHashtable @{LogName="System";StartTime=(Get-Date).AddHours(-1)} | Select-Object -First 100 TimeCreated,Id,ProviderName,LevelDisplayName,Messagewevtutil epl System "C:TempSystem-incident.evtx" /q:"*[System[TimeCreated[timediff(@SystemTime) <= 3600000]]]"- Les logs couvrent la période exacte et restent lisibles par l’équipe d’escalade.
Collecter les tests réseau minimaux
Si le symptôme implique une communication, notez DNS, route, port et latence depuis la vraie source. Un ping seul n’est pas suffisant pour un service TCP
Resolve-DnsName <FQDN>Test-NetConnection <FQDN> -Port <PORT> -InformationLevel Detailedtracert <DESTINATION>- La résolution, la destination et le port de service sont documentés depuis la source concernée.
Capturer les preuves visuelles ou réseau nécessaires
Prenez une capture de l’écran contenant le message complet, sans masquer le code d’erreur. Si une capture réseau est réellement nécessaire, filtrez par hôte et port et limitez la durée. N’envoyez pas une capture contenant des secrets d’authentification sans canal sécurisé. Pour un éditeur, nommez les fichiers avec date, système et ticket.
- Chaque pièce jointe est compréhensible et rattachée à la chronologie.
Lister les actions déjà réalisées et leurs résultats
Documentez chaque test : redémarrage de service, changement de port, profil de test, commande, comparaison avec un autre compte. Indiquez le résultat, même s’il est négatif. Évitez de réexécuter des actions destructives juste pour « être sûr ». L’objectif est que le technicien suivant ne recommence pas les mêmes essais et puisse reprendre au point utile.
- L’escalade montre ce qui a été éliminé et ce qui reste à vérifier.
Nettoyer les secrets puis transmettre
Relisez les logs, captures et commandes avant envoi. Supprimez mots de passe, tokens, cookies, clés privées et données personnelles non nécessaires. Conservez les IP, noms de serveur et identifiants techniques lorsqu’ils sont indispensables au diagnostic et que le canal est autorisé. Ajoutez enfin une question d’escalade claire : cause recherchée, confirmation d’un bug ou aide à la collecte complémentaire.
Get-FileHash "C:TempSystem-incident.evtx" -Algorithm SHA256- Le dossier transmis est exploitable, intègre et ne contient pas de secret inutile.
Validation
La procédure est validée lorsque :
- Le ticket contient symptôme, impact, chronologie, versions et changements récents.
- Les logs couvrent la bonne période et les heures utilisent un fuseau explicite.
- Les tests réseau ou applicatifs déjà réalisés sont reproductibles.
- Les pièces jointes ont été relues et ne contiennent aucun secret non nécessaire.
Retour arrière
- Aucun rollback technique n’est requis pour la collecte elle-même.
- Supprimer les captures temporaires du poste après transmission et selon la politique de rétention.
- Annuler toute configuration de test temporaire créée uniquement pour reproduire l’incident.
Dépannage / erreurs fréquentes
- Logs trop volumineux : réduire la fenêtre temporelle et filtrer par fournisseur, Event ID ou composant.
- Échec non reproductible : privilégier la chronologie utilisateur et activer une journalisation ciblée pour la prochaine occurrence plutôt qu’une collecte permanente massive.
- Heures incohérentes : relever fuseau et synchronisation NTP avant de comparer les événements.
- L’escalade demande encore les informations de base : transformer la liste demandée en checklist réutilisable pour le produit concerné.