En bref : un exercice sur table informatique simule un incident de sécurité autour d'une table : une animation donne pas à pas de nouvelles informations sur la situation, les participants décident comme en situation réelle, et il en résulte une liste d'améliorations concrètes. Pour les serveurs web, un scénario construit sur le modèle de PHP2Shell convient, car il touche en même temps la technique, les décisions dans l'incertitude, la protection des données et la communication.
Pourquoi un plan n'agit qu'en s'exerçant
De nombreuses entreprises ont désormais un plan d'urgence. Mais on ne voit s'il fonctionne que lorsque quelqu'un l'utilise sous la pression du temps. Le bon numéro de téléphone y figure-t-il ? La direction sait-elle qu'elle doit décider d'une mise hors ligne ? Le prestataire connaît-il les accès ? Un exercice sur table répond à ces questions en quelques heures.
La semaine d'octobre 2026 a montré avec quelle rapidité une situation peut s'aggraver : annonce préalable par php.net le 20/10, correctifs le 21/10 à 16 h, heure allemande, niveau d'alerte orange du BSI (office fédéral allemand de la sécurité des technologies de l'information), mises hors ligne de sites publics selon les médias. Celui qui avait déjà répété cette séquence une fois a dû moins improviser. Le déroulement est décrit en détail dans la chronologie de PHP2Shell. La façon de bâtir le plan lui-même est expliquée dans Établir un plan d'urgence informatique pour les serveurs web ; ici, il s'agit de l'exercice.
Exercice sur table informatique : rôles et préparation
Un bon exercice demande peu de matériel, mais des rôles clairs. L'animation conduit le scénario, introduit les informations et tient le temps. Elle ne participe pas à la discussion, mais pose des questions. Un compte rendu note les décisions, les questions ouvertes et chaque endroit où quelqu'un dit « je ne saurais pas le faire maintenant ». Une autre personne peut en option observer comment se déroule la communication.
Les participants sont les personnes qui agissent réellement en cas de crise : direction, informatique interne ou prestataire externe, délégués à la protection des données, communication, au besoin achats ou service juridique. Il est important que les suppléants soient présents, car les incidents ne tiennent pas compte des plans de congés.
La préparation comprend : le plan d'urgence actuel sur papier, la liste de contacts, un aperçu des sites et serveurs et une salle sans interruption. Précisez d'avance qu'il s'agit d'apprendre, pas de noter. Qui craint de se ridiculiser ne dit pas ce qu'il ignore.
Un scénario prêt à l'emploi : faille PHP critique un vendredi après-midi
Le scénario suivant est fictif, mais s'inspire du modèle d'une situation réelle. Adaptez systèmes et noms à votre environnement. Chaque injection reçoit dix à vingt minutes de discussion.
| Étape | Injection de l'animation | Question directrice au groupe |
|---|---|---|
| 1 | La presse spécialisée signale une faille critique dans PHP, des correctifs sont annoncés, mais pas encore disponibles. | Qui l'apprend en premier, et qui doit être informé ? |
| 2 | Les correctifs paraissent dans l'après-midi. Le BSI recommande une mise à jour immédiate, sinon une mise hors ligne temporaire. | Lesquels de nos systèmes sont concernés, et comment le savons-nous ? |
| 3 | L'hébergeur ne répond pas. Un serveur propre tourne avec une version de PHP sans mise à jour officielle. | Corriger, mettre hors ligne ou attendre, et qui décide ? |
| 4 | La boutique doit lancer une promotion ce week-end. Les ventes insistent pour ne rien couper. | Comment pesons-nous chiffre d'affaires et risque, et comment documentons-nous la décision ? |
| 5 | Un admin trouve lundi un fichier PHP inconnu dans le dossier d'envoi (uploads). | Que faisons-nous d'abord, que laissons-nous volontairement de côté ? Qui conserve les preuves ? |
| 6 | On ne sait pas si des données clients ont fuité. | Qui évalue une éventuelle obligation de notification, et quand le délai court-il ? |
| 7 | Une journaliste demande pourquoi le site est hors ligne. | Qui parle à l'extérieur, et que disons-nous tant que nous savons peu de choses ? |
L'étape 6 touche au RGPD. Dans l'exercice, il suffit de clarifier le déroulement : qui associe les délégués à la protection des données et quand. L'évaluation juridique reste aux spécialistes ; les grandes lignes du délai figurent à l'art. 33 du RGPD.
Constats typiques et comment les consigner
Certaines lacunes apparaissent dans presque chaque premier exercice. Il manque une liste complète indiquant quels sites tournent sur quels serveurs avec quelle version de PHP. Les coordonnées de l'hébergeur sont périmées ou ne sont enregistrées que dans une boîte de réception inaccessible en cas de crise. Personne ne sait avec certitude si la direction peut ordonner elle-même une mise hors ligne ou si quelqu'un doit donner son accord.
Consignez chaque constat en trois parties : ce que nous avons constaté, ce que nous changeons et qui le fait pour quand. D'expérience, un constat sans responsable reste en plan. Classez les points selon leur effet : un numéro d'urgence manquant se corrige vite et aide immédiatement, une nouvelle solution de surveillance demande de la planification.
Pour le bilan structuré après l'exercice, la même démarche que pour un incident réel convient. Elle est décrite dans l'article Retour d'expérience : s'améliorer après l'incident. La liste de contacts, qui montre le plus souvent des faiblesses lors de l'exercice, est traitée dans Contacts d'urgence : qui faut-il prévenir, et quand ?.
Répétez l'exercice au bout de six à douze mois avec un autre scénario, par exemple un site piraté avec redirection vers des sites étrangers. Vous vérifiez ainsi si les mesures du premier tour ont réellement été mises en œuvre.
Comment PHP SOS aide-t-il concrètement ?
- Nous adaptons le scénario à vos sites, serveurs et prestataires réels et préparons les injections.
- Nous animons l'exercice à distance ou en visioconférence et nous retenons nos évaluations jusqu'à ce que le groupe ait décidé.
- Nous livrons ensuite un compte rendu avec constats, actions, responsables et échéances.
- Sur demande, nous répétons ensuite la partie technique, soit l'état des lieux, le correctif et la recherche de traces, comme notre réponse aux incidents la traite en situation réelle.
Conclusion
Un exercice d'urgence sur table est le moyen le moins coûteux de trouver les faiblesses d'un plan d'urgence avant qu'un incident réel ne le fasse. Un après-midi, un scénario réaliste et un bilan honnête suffisent pour commencer. L'essentiel est que chaque constat devienne une tâche avec un nom et une date.
Questions fréquentes
Qu'est-ce qu'un exercice sur table ?
Un exercice au cours duquel les participants discutent ensemble d'un incident autour d'une table, sans travailler sur de vrais systèmes. Une animation introduit progressivement de nouvelles informations, le groupe décide et justifie. Ainsi, les lacunes du plan, des responsabilités et des listes de contacts deviennent visibles.
Qui devrait participer à un exercice d'urgence ?
Tous ceux qui décident ou agissent en cas de crise : direction, informatique ou prestataire, protection des données, communication et, s'il y en a une, la personne chargée des questions d'assurance. Plus de huit à dix personnes alourdissent le tour de table.
Combien de temps dure un exercice sur table ?
Pour un premier passage, deux à trois heures suffisent, bilan compris. Plus important que la durée : que les résultats soient consignés et que les actions soient attribuées avec une échéance.
Le scénario doit-il être réaliste ?
Il doit correspondre à votre environnement, mais pas être exact dans le moindre détail. Un scénario construit sur le modèle d'une situation réelle comme PHP2Shell est crédible et oriente la discussion vers les décisions plutôt que vers les détails techniques.