# Retour d'expérience : s'améliorer après l'incident

> Retour d'expérience après un incident : quand tenir la réunion, quelles questions comptent et comment transformer les constats en actions datées.

Source : https://phpsos.de/fr/blog/lessons-learned-nach-vorfall/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** le retour d'expérience après un incident informatique signifie qu'après la clôture technique, tous les participants se réunissent, reconstituent le déroulement, nomment sans chercher de coupable ce qui a bien fonctionné et ce qui n'a pas fonctionné, et en déduisent des actions avec responsables et échéances. Cela vaut aussi pour les quasi-incidents, comme une semaine PHP2Shell qui s'est bien terminée. Ce qui compte n'est pas le compte rendu, mais le contrôle ultérieur de la mise en œuvre des actions.

## Pourquoi la semaine qui suit l'incident est si importante

Lorsque le serveur refonctionne et que les correctifs sont installés, la tentation est grande de revenir vite au quotidien. C'est précisément alors que le savoir le plus précieux se perd : qui a remarqué quoi, et quand ? Où manquait-il une information ? Quelle décision a pris trop de temps ? Dans quelques semaines, plus personne ne le saura exactement.

La semaine d'octobre 2026 en est un bon exemple. De nombreuses entreprises ont corrigé leurs serveurs PHP, écrit à leurs hébergeurs, mis des sites hors ligne par précaution ou sauvegardé des journaux. Même si aucune intrusion n'a été constatée, il y a là beaucoup à apprendre. Combien de temps a-t-il fallu pour établir quels systèmes étaient concernés ? Qui devait autoriser la mise hors ligne, et cette personne était-elle joignable ?

Les étapes techniques après une attaque proprement dite sont traitées dans la [liste de contrôle après un piratage](https://phpsos.de/fr/ratgeber/checkliste-nach-dem-hack/). Cet article commence après : qu'en apprenons-nous ?

## Retour d'expérience d'un incident informatique : règles de base pour le bilan

Un bilan n'est pas un tribunal. Celui qui craint que les erreurs aient des conséquences personnelles ne raconte que la moitié de l'histoire. C'est pourquoi le principe est : nous cherchons des causes dans les procédures, les outils et les informations, pas des coupables. Les personnes ont agi avec les connaissances qu'elles avaient à ce moment-là.

Invitez tous ceux qui ont participé, y compris les externes comme l'hébergeur, l'agence ou les prestataires, dans la mesure du possible. Prévoyez deux heures. Demandez du matériel au préalable : tickets, historiques de discussion, e-mails, notes, extraits de journaux. Il en naît la chronologie, colonne vertébrale de la réunion. La manière de la construire proprement est décrite dans [Établir la chronologie d'un incident](https://phpsos.de/fr/blog/zeitleiste-eines-vorfalls/).

L'animation ne devrait pas être assurée par la personne qui a dirigé l'incident sur le plan opérationnel. Elle évaluerait sinon ses propres décisions. Est neutre, par exemple, quelqu'un d'un autre service ou un partenaire externe.

## Le déroulement en six étapes

1. **Présenter la chronologie :** que s'est-il passé et quand, du premier signalement à la clôture ? Marquer les lacunes de la chronologie, ne pas deviner.
2. **Qu'est-ce qui a bien fonctionné ?** Commencez volontairement par le positif. Cela montre ce qui doit être conservé et détend le groupe.
3. **Où cela a-t-il coincé ?** Chaque retard, chaque information manquante, chaque incertitude est recueillie, d'abord sans discuter des solutions.
4. **Clarifier les causes :** pour les points les plus importants, demandez plusieurs fois pourquoi. « Le correctif est arrivé tard » est un constat, « personne ne savait que PHP tourne encore sur l'ancien serveur » est une cause.
5. **Définir les actions :** pour chaque cause une action concrète, une personne responsable et une échéance.
6. **Convenir du contrôle ultérieur :** une date dans quatre à huit semaines, où l'on vérifie ce qui est mis en œuvre.

## Questions et actions typiques après une situation PHP

Le tableau suivant montre des questions qui se posent souvent après une situation comme PHP2Shell, et des réponses possibles sous forme d'actions. Toutes ne conviennent pas à chaque entreprise ; il doit aiguiser le regard.

| Question lors du bilan | Constat typique | Action possible |
|---|---|---|
| Comment avons-nous appris l'existence de la faille ? | Par hasard, dans les actualités | S'abonner de manière ciblée aux alertes de sécurité de php.net et du BSI |
| Savions-nous quels systèmes étaient concernés ? | Liste incomplète, ancien système oublié | Inventaire de tous les sites et serveurs avec la version de PHP |
| Qui avait le droit de décider de la mise hors ligne ? | Flou, décision retardée | Inscrire le pouvoir de décision dans le plan d'urgence |
| L'hébergeur a-t-il confirmé le correctif ? | Seulement oralement ou pas du tout | Demander une confirmation écrite, compléter le contrat |
| Tous les processus PHP ont-ils été redémarrés ? | Non vérifié | Intégrer le redémarrage et le contrôle comme étape fixe |
| Les journaux étaient-ils disponibles à partir du 20/10 ? | Déjà partiellement écrasés | Allonger la durée de conservation, sauvegarder les journaux de façon centralisée |
| Comment s'est déroulée la communication interne et externe ? | Les collaborateurs l'ont appris par la presse | Préparer une première information interne |

Consignez aussi ce que vous ne changez volontairement pas. Parfois un constat est connu, mais l'action serait disproportionnée. Une décision documentée vaut mieux qu'un oubli silencieux.

> **Astuce:**
> Séparez dans le compte rendu les faits établis, les hypothèses probables et les questions ouvertes. Précisément après PHP2Shell, pour lequel il n'existe aucun indicateur de compromission publié et confirmé, cette séparation est importante.

## Du compte rendu au changement

L'échec le plus fréquent d'un retour d'expérience est banal : le compte rendu est envoyé, puis rien ne se passe. Trois habitudes aident. Premièrement, chaque action va dans le système où l'on travaille de toute façon, donc le système de tickets ou la liste de tâches, pas dans un document séparé. Deuxièmement, le contrôle ultérieur reçoit une date fixe dans l'agenda de la direction. Troisièmement, les résultats alimentent le plan d'urgence, la liste de contacts et les exercices.

Celui qui veut vérifier les constats sans attendre le prochain incident réel peut les rejouer dans un [exercice d'urgence sur table](https://phpsos.de/fr/blog/notfalluebung-am-tisch/). Et là où le bilan montre que les mises à jour dépendaient trop du hasard, la transformation en [gestion des correctifs comme processus](https://phpsos.de/fr/blog/patch-management-prozess/) vaut la peine.

Pour la protection des données, l'assurance et le cas échéant les autorités, le rapport final est en outre un document important. L'évaluation juridique, par exemple de la nécessité d'une notification au titre de l'art. 33 du RGPD, relève toutefois du délégué à la protection des données ou de l'avocat, pas du bilan technique.

## Comment PHP SOS aide-t-il concrètement ?

- Nous établissons à partir des journaux, tickets et notes une chronologie de l'incident et signalons les lacunes.
- Nous animons le bilan comme instance neutre et veillons à ce que l'on cherche des causes plutôt que des coupables.
- Nous traduisons les constats techniques en actions avec estimation de l'effort et priorité.
- Nous accompagnons le contrôle ultérieur et mettons en œuvre sur demande nous-mêmes les mesures techniques, comme prévu dans notre [réponse aux incidents](https://phpsos.de/fr/leistungen/incident-response/).

## Conclusion

Un incident est déjà assez coûteux. Celui qui ne l'exploite pas paie une seconde fois la prochaine fois. Un bilan honnête sans recherche de coupable, une chronologie propre et des actions avec nom et échéance font d'une semaine difficile un gain durable de sécurité.


## Questions fréquentes

**Quand la réunion de retour d'expérience doit-elle avoir lieu ?**  
Lorsque l'incident est techniquement clos, mais que les souvenirs sont encore frais. En pratique, une date environ une à deux semaines après la clôture a fait ses preuves. Avant, le recul manque souvent ; plus tard, les détails s'estompent.

**Faut-il aussi faire un bilan après un quasi-incident ?**  
Cela vaut la peine. Une situation comme PHP2Shell, où rien ne s'est finalement produit, montre quand même où des procédures ont coincé. Ces constats sont particulièrement précieux, car ils ont été obtenus sans dommage.

**Qui anime le bilan ?**  
Idéalement quelqu'un qui n'a pas dirigé lui-même l'incident sur le plan opérationnel. L'animation reste ainsi neutre et personne n'a à défendre ses propres décisions. Cela peut aussi être un prestataire externe.

**Qu'advient-il des résultats ?**  
Chaque constat devient une action avec une personne responsable et une échéance. Le plan d'urgence, la liste de contacts et la documentation sont adaptés. Après quelques semaines, quelqu'un vérifie ce qui a réellement été mis en œuvre.

## Sources

- [BSI : informations pour les entreprises](https://www.bsi.bund.de/)
- [php.net : avis de sécurité](https://www.php.net/)
- [RGPD, art. 33 (texte allemand : DSGVO)](https://dsgvo-gesetz.de/art-33-dsgvo/)