Un incident applicatif est un événement qui impacte la disponibilité ou les fonctionnalités d'une application en production. Sa gestion détermine la durée de l'impact pour les utilisateurs et la qualité de la communication vers les parties prenantes.
Nticstudio applique un processus structuré de gestion des incidents dans le cadre de l'offre Run.
Détection : automatique vs signalement utilisateur
La détection automatique (monitoring, alertes) doit précéder le signalement utilisateur. Quand un utilisateur signale un problème, l'incident s'est déjà produit depuis plusieurs minutes au minimum. Le monitoring permet d'être informé en même temps que le problème apparaît, pas après.
Les sources de détection automatique : alertes de disponibilité (uptime monitoring), erreurs applicatives en hausse anormale (Sentry), métriques d'usage anormalement bas (chute des transactions, des inscriptions), et alertes d'infrastructure (CPU, mémoire, espace disque).
Qualification et déclaration de l'incident
À la réception d'une alerte ou d'un signalement, la première étape est la qualification : l'incident est-il réel ? Quelle est sa criticité ? Combien d'utilisateurs sont impactés ? La qualification prend 5 à 15 minutes et conditionne la mobilisation des ressources.
Un incident confirmé est déclaré avec : son niveau de criticité (P0 à P3), une première estimation de l'impact, et l'ouverture d'un canal de communication dédié (fil Slack, bridge téléphonique pour les P0).
Résolution et communication pendant l'incident
Pendant l'incident, deux activités en parallèle : la résolution technique (investigation de la cause, mise en place d'une solution temporaire si possible, déploiement du correctif) et la communication (mises à jour régulières vers les parties prenantes).
La fréquence de communication dépend de la criticité : toutes les 30 minutes pour un P0, toutes les 2 heures pour un P1. L'absence de mise à jour est pire qu'une mise à jour « nous n'avons pas encore trouvé la cause ».
Post-mortem et prévention
Après résolution, le post-mortem documente : la chronologie de l'incident, la cause racine, les actions menées, et les mesures préventives pour éviter la récurrence. Il est rédigé dans un esprit non-punitif : l'objectif est d'apprendre, pas de chercher un responsable.
Les actions correctives identifiées dans le post-mortem sont tracées et intégrées au backlog de maintenance. Les incidents récurrents sont un signal que le système a un problème structurel qui mérite un chantier dédié.