← Retour au portail

Fiche 1 - Rédiger un rapport d'incident informatique

Savoir documenter un incident réseau ou système : structure, contenu, vocabulaire et bonnes pratiques pour un rapport professionnel.

Intermédiaire — SISR 2ème année ⏱️ 20 min 📁 Méthodes

🎯 Objectifs de la fiche

  1. Qu'est-ce qu'un rapport d'incident ? — Définition, utilité, cadre ITIL
  2. Structure d'un rapport d'incident — Les 8 sections incontournables
  3. Rédiger la chronologie — Timeline, actions, intervenants
  4. Analyse des causes (RCA) — Root Cause Analysis — cause racine
  5. Plan d'action et prévention — Mesures correctives et préventives

Prérequis

Connaître les bases de l'administration système et réseau. Cette fiche s'applique à tout type d'incident : panne réseau, indisponibilité de service, compromission de sécurité, perte de données.

1. Pourquoi rédiger un rapport d'incident ?

ObjectifBénéfice concret
TraçabilitéGarder un historique des problèmes et des solutions appliquées
CommunicationInformer la hiérarchie, les clients et les équipes de manière factuelle
AméliorationIdentifier les faiblesses et éviter que l'incident ne se reproduise
ConformitéRépondre aux exigences légales (RGPD, ISO 27001) en cas d'incident de sécurité
Base de connaissancesConstituer une documentation réutilisable pour les équipes futures
ℹ️ Dans le cadre ITIL (Information Technology Infrastructure Library), un incident est toute interruption non planifiée ou dégradation d'un service informatique. Le rapport d'incident (post-incident review) est une étape clé du processus de gestion des incidents.

2. Structure d'un rapport d'incident

SectionContenu attendu
1. En-têteDate, heure, numéro d'incident, rédacteur, statut (résolu/en cours)
2. Résumé exécutifDescription synthétique en 3-5 lignes lisible par un non-technicien
3. Description de l'incidentSymptômes observés, systèmes affectés, utilisateurs impactés
4. ChronologieTimeline précise : heure de détection, actions, escalades, résolution
5. Analyse des causesCause immédiate + cause racine (RCA)
6. ImpactDurée d'indisponibilité, nombre d'utilisateurs, pertes financières estimées
7. Actions correctivesCe qui a été fait pour résoudre l'incident
8. Plan de préventionMesures pour éviter la récurrence

3. Le résumé exécutif

Le résumé exécutif s'adresse à la direction — il doit être compréhensible sans connaissances techniques. Il répond aux questions : quoi, quand, qui est impacté, résolu ?

Exemple de résumé exécutif :

Le 10 juin 2026 de 14h22 à 16h45, le service de messagerie de l'établissement
a été indisponible pour l'ensemble des 280 utilisateurs suite à une saturation
de l'espace disque du serveur de messagerie. L'incident a été résolu par
l'extension du volume de stockage et le nettoyage des boîtes mail volumineuses.
Des mesures de surveillance ont été mises en place pour prévenir toute récurrence.

4. La chronologie (timeline)

Format recommandé :

14h22  Détection automatique — alerte Zabbix : espace disque /var/mail à 98%
14h25  Notification envoyée à l'équipe SI par email
14h30  Intervention de G. Hommet — diagnostic : saturation disque confirmée
14h45  Décision d'escalade vers le responsable infrastructure
15h00  Extension du volume LVM de 50 Go approuvée et lancée
15h35  Service de messagerie redémarré — tests concluants
16h00  Communication aux utilisateurs : retour à la normale
16h45  Rapport d'incident transmis à la direction
17h00  Mise en place d'une alerte à 85% sur Zabbix
💡 La chronologie doit être factuelle et précise à la minute. Évitez les approximations ('vers 15h'). Notez TOUTES les actions, même celles qui n'ont pas fonctionné — elles ont de la valeur pour la prévention.

5. Analyse des causes — Root Cause Analysis (RCA)

La RCA distingue la cause immédiate (symptôme visible) de la cause racine (origine profonde). La méthode des 5 Pourquoi est simple et efficace :

Incident : serveur de messagerie indisponible

Pourquoi ? → Le disque est plein
Pourquoi ? → Les boîtes mail n'ont pas de quota défini
Pourquoi ? → La politique de gestion des emails n'a pas été appliquée
Pourquoi ? → Aucune procédure de nettoyage périodique n'existe
Pourquoi ? → La gestion du stockage mail n'a jamais été formalisée

Cause racine : absence de politique de gestion du stockage de messagerie
→ Action : rédiger et appliquer une politique de quotas et de nettoyage

6. Plan d'action

Type d'actionDescriptionResponsableDélai
CorrectiveEtendre le volume disque à 200 GoG. HommetImmédiat
CorrectiveMettre en place des quotas de 2 Go par boîteG. HommetJ+2
PréventiveAlerte Zabbix à 80% de remplissageG. HommetJ+1
PréventiveScript de nettoyage automatique mensuelG. HommetJ+7
OrganisationnelleFormer les utilisateurs à la gestion emailsDirectionJ+30

7. Vocabulaire et niveau de sévérité

NiveauNomDescriptionExemples
P1CritiqueImpact total — service(s) principal(aux) inopérant(s)Coupure réseau totale, ransomware, perte de données
P2MajeurImpact significatif — service dégradé pour tousMessagerie indisponible, VPN hors service
P3ModéréImpact partiel — certains utilisateurs affectésImprimante réseau HS, lenteurs applicatives
P4MineurImpact faible — gêne pour un utilisateurPC lent, mot de passe oublié
🎯 Passer l'évaluation de cette fiche