# Un runbook d’incident qui référence directement les tests à relancer > Plutôt qu'une liste de commandes génériques, un document d'incident renvoie vers des scénarios de test précis, capables de confirmer qu'un correctif a réellement résolu le problème. - Auteur : Clément Hadrot - Publié le : 2026-07-17 - Mis à jour le : 2026-07-17 - Catégorie : Tests - URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/runbook-incident-reference-tests-a-relancer/ ## L’essentiel - Un runbook générique dit quoi vérifier en théorie, un runbook lié aux tests dit comment le vérifier en pratique - Chaque type d'incident référencé pointe vers une méthode de test précise à exécuter - Ce lien évite qu'un correctif appliqué en urgence casse silencieusement un autre comportement « Vérifier que le site fonctionne » : cette instruction, présente dans la première version du runbook d'astreinte d'une plateforme de covoiturage solidaire, ne dit rien de concret à la personne d'astreinte à trois heures du matin, seule face à une alerte de paiement en échec. Un runbook utile ne se contente pas de lister des commandes à exécuter, il indique précisément quel scénario de test relancer pour confirmer qu'un correctif a réellement résolu le problème signalé, et non simplement fait disparaître le symptôme visible. La refonte du document a consisté à relier chaque type d'incident déjà rencontré à une méthode de test PHPUnit ou Playwright précise, plutôt qu'à une simple liste de vérifications manuelles à effectuer à l'œil. ## La structure retenue pour chaque type d'incident Chaque entrée du runbook suit le même schéma : le symptôme observé côté monitoring, la cause probable la plus fréquente, la commande de test à exécuter pour confirmer un diagnostic, et la commande à relancer après correctif pour vérifier la résolution. ``` ## Incident : échec de paiement Stripe en cascade Symptôme : taux d'échec de paiement supérieur à 15 % sur 10 minutes. Cause probable : webhook Stripe non traité, statut de commande resté bloqué. Test de diagnostic à relancer en priorité : vendor/bin/phpunit --filter WebhookStripeTest::ilTraiteUnPaiementConfirme Test de vérification après correctif : vendor/bin/phpunit --filter WebhookStripeTest ``` ## Pourquoi référencer un test plutôt qu'une simple commande de vérification > L'essentiel à retenir : Un runbook générique dit quoi vérifier en théorie, un runbook lié aux tests dit comment le vérifier en pratique ; Chaque type d'incident référencé pointe vers une méthode de test précise à exécuter ; Ce lien évite qu'un correctif appliqué en urgence casse silencieusement un autre comportement Une commande de vérification manuelle, du type « se connecter et passer une commande test », dépend de la disponibilité d'un environnement propre et de la mémoire de la personne d'astreinte quant aux étapes précises à suivre. Un test automatisé référencé directement reproduit systématiquement le même scénario, sans dépendre de la vigilance de qui l'exécute à une heure tardive. ### Le cas d'un correctif appliqué en urgence Lors d'un incident réel de blocage de réservation, un correctif rapide appliqué directement en production a résolu le symptôme visible en quelques minutes. Relancer ensuite la suite complète référencée par le runbook, plutôt que de se contenter du symptôme disparu, a révélé que ce correctif cassait un second scénario, celui de l'annulation d'une réservation déjà confirmée, resté invisible sans cette relance systématique. ## Neuf scénarios, un par type d'incident déjà rencontré - Échec de paiement en cascade, référencé plus haut. - Blocage de réservation lors d'un conflit de créneau horaire. - Notification par courriel non envoyée après confirmation de trajet. - Erreur de calcul de partage de frais entre passagers. - Doublon de compte utilisateur après une double soumission de formulaire. - Perte de session lors d'un paiement effectué depuis un navigateur mobile. - Incohérence entre statut affiché et statut réel d'une réservation annulée. - Ralentissement de la recherche de trajets disponibles. - Échec de synchronisation avec le calendrier partagé d'un conducteur. ## Ce que ce runbook ne remplace pas Ce document reste distinct de la suite de tests de fumée exécutée systématiquement avant une intervention planifiée, qui vérifie l'état général du site sans lien avec un incident précis déjà survenu. Le runbook d'astreinte, lui, se construit progressivement, un scénario ajouté après chaque nouvel incident dont la cause a été comprise et testée. > Un correctif qui fait taire une alerte n'a pas nécessairement résolu le problème ; seul un test relancé le confirme. ## En résumé Relier chaque type d'incident référencé dans un runbook d'astreinte à un scénario de test précis, plutôt qu'à une simple liste de commandes génériques, donne à la personne d'astreinte un moyen concret de vérifier qu'un correctif a réellement résolu le problème signalé. Sur cette plateforme de covoiturage solidaire, les neuf scénarios déjà référencés ont permis, à plusieurs reprises, de détecter qu'un correctif d'urgence avait introduit une régression ailleurs, avant que cette régression ne devienne à son tour un incident.