Gestion des Incidents SaaS

La classification de la gravité des incidents est la première décision dans chaque incident — elle détermine qui est alerté, à quelle vitesse, et quels SLA de communication s'appliquent. Un modèle de gravité pratique : SEV-1 (Critique) : panne complète du produit ou événement de perte de données. Aucun utilisateur ne peut accéder au produit principal OU violation confirmée de l'intégrité des données. Réponse : appel de conférence immédiat pour toutes les équipes, notification du PDG et du conseil d'administration dans l'heure, mise à jour de la page de statut publique dans les 15 minutes, notification client dans les 30 minutes. SEV-2 (Majeur) : indisponibilité significative d'une fonctionnalité affectant > 10 % de la base d'utilisateurs actifs, ou une fonctionnalité critique défaillante pour tous les comptes de niveau entreprise. Réponse : responsable de l'ingénierie et rotation d'astreinte immédiatement engagés, réunion de coordination interfonctionnelle dans les 30 minutes, notification client dans l'heure. SEV-3 (Mineur) : dégradation isolée d'une fonctionnalité affectant < 10 % des utilisateurs ou une fonctionnalité non critique défaillante. Réponse : ingénieur assigné, escalade pendant les heures de travail standard, page de statut mise à jour si visible publiquement, pas de contact client proactif sauf si la fonctionnalité affectée est couramment utilisée. SEV-4 (Faible) : bug mineur avec solution de contournement connue, pas d'impact client généralisé. Réponse : enregistré comme un bug suivi dans le backlog d'ingénierie, pas d'escalade.

La qualité de la communication d'incident affecte considérablement la confiance des clients et le risque de churn, souvent plus que l'incident lui-même. Principes : communiquez tôt et souvent, même lorsque vous n'avez rien à signaler — le silence est interprété comme de l'incompétence ou de l'évasion. Structurez la communication d'incident sur trois canaux : (1) Page de statut publique (Statuspage.io est la norme) : mise à jour dans les 15 minutes suivant la classification de l'incident. Mise à jour initiale : "Nous sommes conscients d'un problème affectant [Fonctionnalité X] et enquêtons. Nous mettrons à jour toutes les 30 minutes." Mises à jour ultérieures toutes les 30 minutes avec exactement trois éléments : ce qui est toujours impacté, ce que l'équipe a appris, et l'heure de la prochaine mise à jour. Mise à jour de résolution : "Cet incident a été résolu. Toutes les fonctionnalités de [Fonctionnalité X] ont été restaurées à partir de [heure]. Nous publierons un post-mortem complet dans les 48 heures." (2) E-mail proactif aux comptes affectés : pour les SEV-1 et SEV-2, l'équipe Support ou CS envoie un e-mail direct à tous les comptes de niveau entreprise pour les informer de l'impact avant qu'ils ne le rencontrent. Être le premier à informer est significativement mieux que d'attendre que les clients découvrent et se plaignent. (3) Bannière in-app pendant un incident actif : une bannière visible dans l'interface utilisateur du produit reconnaissant le problème afin que les utilisateurs rencontrant des problèmes comprennent immédiatement qu'il est connu, et non une erreur de l'utilisateur.

L'examen post-incident (PIR, également appelé post-mortem dans la culture d'ingénierie) est le débriefing structuré qui transforme un incident douloureux en apprentissage organisationnel. Un PIR efficace est sans reproche — axé sur les améliorations systémiques des processus et de l'infrastructure, et non sur la recherche et la critique de l'individu qui a commis une erreur. La technique des "cinq pourquoi" : demandez "pourquoi cela s'est-il produit ?" puis demandez "pourquoi" à chaque réponse, cinq fois. Cet exercice révèle presque toujours que ce qui semblait être une erreur humaine (un ingénieur a effectué une mauvaise modification de configuration) était en fait une défaillance systémique (le processus de modification n'incluait pas une étape de révision qui aurait détecté l'erreur, la surveillance n'a pas alerté à temps, le runbook a mal dirigé l'ingénieur d'astreinte). Structure du PIR : reconstruction de la chronologie (un compte rendu précis minute par minute de ce qui s'est passé, validé par les membres de l'équipe impliqués) ; quantification de l'impact (combien de clients affectés, pendant combien de temps, quel était l'ARR estimé à risque ?) ; analyse des causes profondes (quelles conditions systémiques ont permis cet incident ?) ; mesures d'atténuation immédiates complétées ; et — le plus important — les éléments d'action. Les éléments d'action du PIR doivent être spécifiques, attribués et planifiés : "Mehmet ajoutera l'étape de révision de la modification de la configuration de déploiement au runbook d'ici le 15 mars." Product Ops suit les éléments d'action du PIR mensuellement et rapporte les taux d'achèvement à la direction de l'ingénierie.