Checklist d'incident de production pour les petites équipes qui ont besoin de clarté

Ce qu'un runbook de production résout pour une petite équipe

Un runbook de production est un court playbook écrit pour quand quelque chose casse en production. Il vous dit où regarder en premier, quelles actions sont sûres et qui communique quoi. Les petites équipes n'ont pas le luxe du « quelqu'un saura ». La bonne personne peut être endormie, occupée ou toute nouvelle.

Pendant un incident, l'objectif est simple : réduire les dégâts, restaurer le service et garder l'équipe coordonnée. L'analyse de la cause racine peut attendre que les clients puissent se connecter, payer ou utiliser le produit à nouveau. Une checklist empêche la panique et les clics aléatoires en transformant le stress en quelques actions claires.

Cette checklist se concentre sur la première heure : triage rapide, décisions de rollback, communication client et une boucle post-incident basique pour éviter les répétitions. Elle ne remplace pas le débogage approfondi, le travail d'architecture à long terme ou un programme de sécurité complet. Elle est conçue pour deux à cinq personnes, y compris des non-spécialistes.

Une règle simple aide les équipes à faire de meilleurs choix sous pression :

• Réparez d'abord l'impact client, même si la solution est temporaire.
• Choisissez le changement à plus faible risque (souvent un rollback) avant un correctif complexe.
• Communiquez tôt et brièvement, puis mettez à jour à une cadence prévisible.
• Gardez l'apprentissage pour après que le service soit stable.

Exemple : si un déploiement provoque des erreurs au checkout, faites un rollback d'abord pour arrêter les paiements échoués. Étudiez ensuite le changement de code une fois que le revenu et la confiance ne sont plus en train de fuir.

Définir la sévérité et les rôles avant d'en avoir besoin

Quand quelque chose casse, les équipes perdent du temps à débattre de la gravité et de qui décide. Une échelle de sévérité simple et des rôles clairs transforment un runbook en action, pas en discussion.

Sévérité en langage clair

Restez bref et lié à l'impact utilisateur. Pour beaucoup de petites équipes, trois niveaux suffisent :

• Mineur : Quelques utilisateurs affectés, contournement existant, pas de risque de perte de données.
• Majeur : Beaucoup d'utilisateurs affectés, fonctionnalité centrale dégradée, risque sur le revenu ou les délais.
• Critique : Service majoritairement down, risque de sécurité ou perte de données probable.

Une règle supplémentaire aide : la sévérité ne peut être relevée que pendant un incident, pas baissée. Cela évite les disputes d'image pendant que vous devez réparer.

Rôles qui enlèvent les goulots d'étranglement

Attribuez des rôles immédiatement, même si vous n'êtes que deux. Une personne pilote les décisions. Une personne gère les mises à jour.

• Incident lead : tient la timeline, choisit les prochaines étapes, évite le thrash des tâches.
• Communicator : publie les mises à jour, répond aux parties prenantes, garde les ingénieurs concentrés.
• Rollback approver : la personne qui peut dire « oui, rollback maintenant » (souvent l'incident lead, plus un backup).
• Scribe (optionnel) : note les moments clés et les actions pour la revue.

Décidez comment joindre rapidement le rollback approver (appel, texto, ce que vous répondez réellement). Notez aussi le backup, car les incidents adorent les vacances.

Enfin, définissez « service restauré » en une phrase. Exemple : « Les utilisateurs peuvent se connecter et charger le tableau de bord en moins de 3 secondes, et le taux d'erreur reste sous 1 % pendant 15 minutes. » Cette phrase évite de crier victoire trop tôt.

Préparations qui rendent la checklist réellement utilisable

Une checklist ne sert que si elle pointe vers des endroits réels accessibles en minutes, pas « on devrait vérifier les logs ». L'objectif est d'enlever l'incertitude en situation de stress.

Commencez par une carte système d'une page. Restez simple : quoi tourne où et de quoi dépend quoi (app web, API, base de données, cache, fournisseur d'auth, jobs en arrière-plan, services tiers). Ajoutez les points de défaillance uniques que vous connaissez déjà.

Notez vos principaux parcours clients, pas chaque endpoint. La plupart des petites équipes vivent et meurent par quelques flux comme connexion, inscription, checkout et une ou deux actions centrales. Si vous pouvez les tester rapidement, vous pouvez confirmer l'impact et savoir quand vous êtes de retour.

Conservez une courte section « où regarder » qui reste à jour. Listez quelques métriques de confiance (taux d'erreur, latence, réussite de connexion, profondeur des queues, connexions DB), où sont les tableaux de bord, où sont les logs (app et edge/CDN), et comment voir la dernière version et l'heure du déploiement. Ajoutez une baseline connue comme les chiffres d'hier pour repérer ce qui est « normal ».

Stockez les étapes d'accès d'urgence et les contacts au même endroit : qui peut approuver les changements, qui a l'accès cloud, qui peut rollbacker et comment les joindre.

Documentez où se trouvent les configs et secrets sans les exposer. Écrivez « où et comment faire une rotation », pas les valeurs réelles.

Si vous avez hérité d'une base de code fragile, cette préparation révèle souvent des variables d'environnement manquantes, des secrets codés en dur ou des étapes de déploiement qui n'existent que dans la tête de quelqu'un.

La checklist d'incident des 10 premières minutes (étape par étape)

Quand quelque chose casse, vous avez besoin d'un petit script à suivre sous stress. Cette checklist est conçue pour les 10 premières minutes, quand la rapidité et la sécurité comptent plus qu'un diagnostic parfait.

Commencez par confirmer l'impact en termes simples. Que tentent de faire les utilisateurs et qu'est-ce qui échoue ? Est-ce tout le monde ou un sous-ensemble (région, offre, navigateur, seuls les comptes récents) ? Si vous pouvez reproduire une fois, notez les étapes exactes et le message d'erreur.

Ensuite, stabilisez le système avant de courir après la cause racine. Suspendez les déploiements et évitez les ajustements rapides qui ajoutent du bruit. Si le problème peut se propager, limitez le rayon d'impact (désactivez un job risqué, réduisez le trafic ou désactivez temporairement la fonctionnalité affectée).

Travaillez une petite hypothèse à la fois. Choisissez le déclencheur le plus probable (dernier déploiement, changement de config, panne tierce) et faites une ou deux vérifications rapides pour le confirmer ou l'écarter.

• Minute 0–2 : Confirmer l'impact (ce qui casse, qui est affecté, quand ça a commencé)
• Minute 2–4 : Geler les changements risqués (arrêter les déploiements, éviter de nouvelles migrations, garder la surface d'attaque petite)
• Minute 4–6 : Vérifications rapides (statut du dernier déploiement, taux d'erreur, connectivité auth/DB, statut des tiers si pertinent)
• Minute 6–8 : Choisir une voie (atténuer maintenant via rollback/flag-off, ou continuer l'investigation si l'atténuation est risquée)
• Minute 8–10 : Consigner les actions (horodatages, ce que vous avez changé, ce que vous avez observé et la décision suivante)

Gardez une timeline courante au même endroit. Même une simple note comme « 10:07 rollback build 214, erreurs en baisse » fait gagner des heures lors de la revue.

Où regarder en premier quand quelque chose casse

Commencez par les symptômes, pas les suppositions. Confirmez ce que voient les utilisateurs et l'étendue : pics d'erreur, requêtes lentes, timeouts ou une vague de messages de support. Si possible, notez l'heure exacte du début du problème. Ce timestamp guide tout le reste.

Ensuite, ancrez votre recherche autour de ce qui a changé. La plupart des incidents ont un déclencheur : un déploiement, un tweak de config, une migration de base, une rotation de secret ou un basculement de feature flag. Même si le changement semble mineur, traitez-le comme suspect jusqu'à preuve du contraire.

Un ordre de triage de première passe qui marche pour les petites équipes :

• Confirmer l'impact : taux d'erreur, latence et quels endpoints ou écrans échouent.
• Vérifier les changements des 30–60 dernières minutes : déploiements, edits de config, migrations, jobs en arrière-plan.
• Chercher la capacité et la saturation : CPU, mémoire, espace disque, requêtes lentes, connexions maxées.
• Scanner les logs pour une erreur répétée (même message, même stack trace, même chemin).
• Vérifier les dépendances : authentification, email/SMS, paiements, CDN et APIs tierces.

Quand vous scannez les logs, ne lisez pas tout. Cherchez le motif d'erreur le plus courant et suivez-le. Si vous voyez un « token signature invalid » répété ou « database connection refused », vous avez déjà une piste solide.

Vérifiez aussi les basiques qui échouent silencieusement : certificats expirés, variables d'environnement manquantes et limites de débit. Ils reviennent souvent dans des prototypes jamais durcis pour la production.

Quand vous trouvez une cause probable, notez-la immédiatement (heure, symptôme, preuve). Cette note devient votre timeline et garde l'équipe alignée.

Options d'atténuation rapides avant une correction complète

Quand la production brûle, l'objectif n'est pas une réparation parfaite. C'est réduire l'impact avec le changement le plus sûr, puis gagner du temps pour diagnostiquer.

Commencez par choisir l'action la moins risquée qui change le moins de choses. Évitez les refactors lourds, les montées de dépendances ou les « tant qu'on y est ». Chaque changement supplémentaire ajoute de l'incertitude.

Mouvements d'atténuation courants et efficaces pour les petites équipes :

• Désactiver le comportement nouveau (feature flag, toggle de config ou variable d'environnement) pour revenir à un chemin connu.
• Passer en mode de secours, par exemple lecture seule ou ensemble de fonctionnalités limitées, pour que le cœur du service reste disponible.
• Réduire la pression : appliquer des rate limits, bloquer temporairement des sources abusives ou augmenter le caching pour les endpoints chauds.
• Mettre en pause les opérations risquées si les données sont en jeu (arrêter les écrits, les jobs en arrière-plan ou les imports) jusqu'à compréhension.
• Ajouter une garde rapide : rejeter les entrées manifestement incorrectes, baisser la concurrence ou ajuster les timeouts uniquement si vous savez que ça aide.

Exemple : vous déployez un changement de checkout et le taux d'erreur grimpe. Le premier geste le plus sûr peut être de désactiver le nouveau flux et garder l'ancien. Si les paiements semblent incohérents, vous pouvez mettre en pause les écritures de commandes tout en laissant la navigation produit disponible.

Deux règles évitent que les « aides » ne fassent empirer la situation. D'abord, faites un changement d'atténuation à la fois et surveillez la métrique unique que vous attendez voir s'améliorer (erreurs, latence, profondeur de queue). Ensuite, notez ce que vous avez changé et quand.

Comment rollbacker en sécurité sans aggraver la situation

Le rollback est la bonne option quand le dernier changement a clairement déclenché le problème et que vous pouvez revenir rapidement à un état connu bon. C'est risqué quand le problème touche les données (migrations, jobs en arrière-plan qui écrivent des mauvais enregistrements) ou quand rollbacker corrige une couche mais laisse la config, les feature flags ou les dépendances cassées.

Avant de toucher quoi que ce soit, confirmez ce que vous allez réellement rollbacker. Les équipes restaurent souvent la version de l'app mais oublient qu'une modification de config, une rotation de secret ou une migration de schéma a causé la panne.

Un chemin de rollback simple à garder dans votre runbook :

• Geler les nouveaux déploiements et mettre en pause tout pipeline d'auto-déploiement.
• Identifier la dernière release connue bonne (commit, build ID, tag de conteneur) et ce qui a changé depuis.
• Vérifier les changements non-code : variables d'environnement, feature flags, jobs en file, clés tierces, limites de débit.
• Décider de l'approche base de données : est-ce sûr de revenir en arrière ou avez-vous besoin d'un hotfix forward.
• Rollbacker une chose à la fois et noter les horodatages pour corréler les logs.

Les changements de base de données sont le piège habituel. Si une migration supprime ou remodèle des données, un rollback peut échouer ou faire planter l'app plus fort. Dans ce cas, préférez un petit correctif forward (réajouter une colonne, ajouter une couche de compatibilité ou désactiver le nouveau chemin) plutôt que d'essayer d'annuler le schéma.

Après le rollback, testez sommairement les flux principaux : connexion, inscription, checkout/facturation et une action centrale payante. Si le rollback échoue, n'entrez pas en thrash. Tentez un rollback propre vers la version précédente connue bonne. Restaurez depuis une sauvegarde vérifiée si nécessaire. Si aucune option n'est sûre, stabilisez (mode maintenance, lecture seule) pendant que vous planifiez une correction contrôlée.

Que communiquer pendant un incident (et quoi éviter)

Quand la production est en feu, une communication claire achète du temps et de la confiance. Elle réduit aussi le travail en double. Partagez ce qui est vrai maintenant, ce que les utilisateurs doivent faire et quand vous les recontacterez.

Établissez un rythme interne tôt et tenez-vous-y. Une petite équipe a généralement besoin d'un propriétaire pour publier les mises à jour et d'un canal où toutes les notes vivent (même si ce n'est qu'un fil de discussion). Utilisez une cadence régulière, pas un flux constant.

Checklist de mise à jour interne :

• Qui est en charge (incident lead) et qui agit (assignés)
• Statut actuel (investigation, atténuation, surveillance, résolu)
• Faits confirmés les plus récents (ce qui a changé, ce que vous avez observé)
• Prochaine action et qui en est responsable
• Prochaine mise à jour (par exemple dans 15 minutes)

Pour les clients, restez court et pratique. Dites ce qui est impacté en langage simple, ce qu'ils peuvent faire maintenant (si applicable) et quand vous donnerez la prochaine mise à jour.

Évitez trois choses pendant l'incident : suppositions (« probablement la base »), blâme (« X a cassé ça ») et échéances non vérifiées (« réparé dans 5 minutes »).

Un modèle léger que vous pouvez coller :

Status: [Investigating | Mitigating | Monitoring | Resolved]
Impact: [Who is affected and what they can’t do]
Workaround: [If available, one clear step]
What we know: [1-2 confirmed facts, no guesses]
Next update: [time]

Terminez par une mise à jour finale qui confirme la récupération, note toute action de suivi pour les utilisateurs (comme se reconnecter) et indique la suite (revue de la cause racine et actions préventives).

Scénario d'exemple : panne de connexion juste après un déploiement

Vous êtes deux. Vous avez poussé une petite release à 9:05. À 9:08, les premiers messages de support arrivent : « Je n'arrive pas à me connecter » et « la réinitialisation de mot de passe ne fonctionne pas ». Les nouvelles inscriptions échouent aussi. Le reste charge normalement.

D'abord, confirmez que c'est réel et répandu. Tentez de vous connecter vous-même (navigation privée, compte normal et compte neuf). Si ça échoue, vérifiez les signaux les plus rapides :

• Statut du fournisseur d'auth (panne, limites de débit, dégradation)
• Notes du dernier déploiement : vars d'env, URLs de callback, réglages de cookies, CORS, domaines de redirect
• Logs d'erreur autour du endpoint de login (401 vs 500 a son importance)
• Changements récents de config (rotation de secrets, changements de domaine)
• Vérification rapide DB : la table users ou le stockage de session a-t-il changé ?

Au bout de 5 minutes, vous arrivez souvent à un point de décision. Si les erreurs ont commencé immédiatement après le déploiement et que vous ne pouvez pas les expliquer vite, préférez le rollback. Si vous pouvez isoler le problème à un chemin nouveau derrière un feature flag, désactivez-le. Choisissez un hotfix uniquement quand vous savez exactement quoi changer et pouvez le tester rapidement.

La communication d'incident peut rester simple et calme :

• 5 min : « Nous investiguons un problème de connexion affectant de nombreux utilisateurs. Prochaine mise à jour dans 20 minutes. »
• 30 min : « La cause semble liée au déploiement de 9:05. Nous procédons au rollback maintenant. Prochaine mise à jour dans 15 minutes. »
• Résolu : « La connexion est rétablie. Nous partagerons un court résumé de ce qui s'est passé et comment nous allons éviter les répétitions. »

Pendant que vous travaillez, gardez un petit document de notes : heure du déploiement exact, heure du premier signalement, messages d'erreur, ce que vous avez essayé, ce qui a réparé et ce que vous changerez (tests, vérifications de config, alertes). Si la base de code est difficile à raisonner sous pression, il peut être utile d'obtenir rapidement un regard extérieur.

Erreurs courantes qui ralentissent la récupération

La plupart des incidents s'éternisent non pas parce que le bug est compliqué, mais parce que l'équipe perd le fil.

Changer trop de choses à la fois est l'erreur classique. Quand trois personnes « essayent un correctif rapide » en parallèle, vous obtenez des signaux mixtes : les logs changent, les métriques fluctuent et personne ne sait ce qui a aidé. Traitez chaque changement comme une expérience : une action, un résultat attendu, une vérification rapide.

Le rollback est souvent évité car il semble être un aveu d'échec. C'est le contraire. Un rollback est un retour contrôlé à un état connu bon pendant que vous déboguez sans la pression. Si vous hésitez, demandez : « Y a-t-il un rollback sûr qui réduit le dommage maintenant ? » Si oui, faites-le.

Un autre frein est de ne pas geler les déploiements. Un collègue pousse une petite amélioration et annule votre atténuation, ou un pipeline CI continue d'envoyer des builds pendant que vous stabilisez. Placez un gel des déploiements tôt et rendez-le visible.

L'absence d'un incident lead clair crée du travail dupliqué et contradictoire. Une personne doit coordonner, tenir une timeline courte et assigner les tâches pour que deux personnes ne chassent pas la même piste.

Enfin, les équipes déclarent souvent « réparé » trop tôt. Validez avec un vrai flux utilisateur (ou une vérification proche de la production), confirmez que les métriques clés sont revenues à la normale et observez 10–15 minutes avant de clôturer. Beaucoup de « deuxièmes pannes » sont en fait la première qui revient.

Prévenir les répétitions avec une routine post-incident pratique

Une routine post-incident doit être courte, spécifique et planifiée. Faites-la dans les 24 à 72 heures, pendant que les logs, les notes de déploiement et les souvenirs sont encore frais. Le but n'est pas de blâmer. C'est rendre la prochaine panne plus petite, plus rare et plus facile à gérer.

Gardez la revue concentrée en séparant la cause racine des facteurs contributifs. La cause racine est le déclencheur direct (par exemple une mauvaise migration). Les facteurs contributifs sont ce qui a permis que cela arrive en production ou qui a ralenti la récupération (alerte manquante, propriété floue, déploiement risqué, chemins de code confus).

Un ordre du jour de 30 minutes qui fonctionne

Utilisez une structure simple pour ne pas déraper en opinions :

• Timeline : ce que les utilisateurs ont vu, quand vous l'avez remarqué, quand c'était réparé
• Impact : qui a été affecté et pendant combien de temps
• Cause racine et 2–3 facteurs contributifs principaux
• Ce qui a bien marché (à garder) et ce qui n'a pas marché (à changer)
• Actions avec un propriétaire et une date limite

Transformez les conclusions en travail concret, pas en promesses vagues. Au lieu de « ajouter plus de tests », écrivez « ajouter un test qui échoue si login renvoie 500 quand le cookie de session est manquant ». Au lieu de « améliorer le monitoring », écrivez « alerter si le taux d'erreur dépasse 2 % pendant 5 minutes après un déploiement ».

Après accord sur les tâches, mettez à jour votre runbook avec une vérification nouvelle qui aurait raccourci l'incident. Exemple : « Avant déploiement, vérifier que la var d'env AUTH_SECRET existe en production. » Les petites modifications s'accumulent.

Si la sécurité est impliquée (secrets exposés, injection SQL, mauvais auth), incluez une remédiation claire et une étape de vérification. La remédiation peut être la rotation des clés et le patch du code. La vérification consiste à prouver que c'est corrigé : confirmer que les anciennes clés ne fonctionnent plus, rejouer le scénario d'exploitation et vérifier les logs pour des accès suspects.

Vérifications rapides et prochaines étapes

Quand c'est agité, une checklist courte bat un long document. Épinglez-la là où votre équipe l'utilisera vraiment.

• Détecter : confirmer l'impact, la fenêtre temporelle et ce qui a le plus récemment changé.
• Stabiliser : arrêter l'hémorragie (geler les déploiements, désactiver les jobs risqués, ajouter des rate limits).
• Atténuer : appliquer le contournement le plus rapide et sûr pour restaurer le service.
• Rollback : revenir à la dernière version connue bonne si la réparation est floue ou risquée.
• Vérifier + communiquer : confirmer la récupération avec de vrais flux utilisateurs, puis publier une mise à jour claire.

Après l'incident, assurez-vous que votre runbook contient les bases pour votre stack. Vous voulez des réponses utilisables à 2 h du matin, pas de la théorie.

• Où vérifier en premier : tableaux de bord, logs, tracking d'erreurs et historique de déploiement récent.
• Comment rollbacker : commandes exactes, qui peut le faire et ce à quoi ressemble le succès.
• Toggles sûrs : feature flags, kill switches, étapes de mode maintenance.
• Contacts : propriétaire on-call, chemin d'escalade, contacts fournisseurs/support.
• Zones à risque connues : auth, paiements, jobs en arrière-plan, migrations, secrets.

Faites appel à de l'aide externe quand les incidents se répètent, que personne ne comprend assez l'architecture pour déboguer vite, ou s'il y a un signe de problème de sécurité (secrets exposés, requêtes DB étranges, tentatives d'injection).

Si vous gérez un prototype généré par IA qui casse en production, une équipe de remédiation comme FixMyMess (fixmymess.ai) peut aider en diagnostiquant la codebase, réparant la logique, renforçant la sécurité et la rendant prête pour des déploiements fiables.

Gardez le runbook vivant : assignez un propriétaire unique, révisez-le 15 minutes par mois et mettez-le à jour après chaque incident tant que les détails sont frais.