Aller au contenu principal

Gestion des incidents

Statut

Document de cadrage opérations — version initiale.

Objectif

La gestion des incidents doit permettre de réagir vite, communiquer clairement et restaurer le service sans improvisation.

Elle couvre les incidents techniques, sécurité, modération, paiement, mairie, IA et contenus.

Types d'incidents

TypeExemples
TechniqueAPI indisponible, frontend hors ligne, queue bloquée.
Donnéeserreur de migration, données incohérentes, perte média.
Sécuritéaccès non autorisé, secret exposé, abus automatisé.
Paiementwebhook Stripe en échec, abonnement incohérent.
Modérationcontenu problématique viral, signalement sensible.
Mairiealerte erronée ou information officielle incorrecte.
IAgénération inadaptée, coût anormal, provider indisponible.

État actuel visible

Le workspace contient des éléments utiles :

  • health check API ;
  • logs Nginx ;
  • logs Supervisor ;
  • workers Laravel ;
  • scheduler cron ;
  • jobs d'expiration ;
  • webhooks Stripe ;
  • documentation DevOps et sécurité en cours de structuration.

Un processus d'incident complet n'est pas confirmé dans le repo.

Niveaux de gravité

NiveauDescription
SEV1Service critique indisponible ou risque sécurité majeur.
SEV2Fonction importante dégradée : paiement, mairie, publication, auth.
SEV3Bug fonctionnel contournable ou impact limité.
SEV4Anomalie mineure ou demande d'amélioration.

Processus incident

  1. Détecter ou recevoir l'alerte.
  2. Qualifier la gravité.
  3. Désigner un responsable incident.
  4. Stabiliser : mitigation, rollback, désactivation temporaire si nécessaire.
  5. Communiquer aux personnes concernées.
  6. Résoudre ou contourner.
  7. Vérifier le retour à la normale.
  8. Documenter la cause et les actions.
  9. Ajouter une action préventive si utile.

Communication

La communication doit rester factuelle :

  • ce qui est affecté ;
  • qui est concerné ;
  • ce qui est fait ;
  • contournement éventuel ;
  • prochaine mise à jour ;
  • résolution confirmée.

IA et incidents

L'IA peut aider à :

  • résumer logs et chronologie ;
  • classer un incident ;
  • préparer une communication ;
  • rapprocher incidents similaires.

Elle ne doit pas décider seule d'un rollback, d'une notification publique ou d'une action de sécurité.

Risques et points à clarifier

  • Canal d'alerte officiel.
  • Responsable incident.
  • Procédure de rollback validée.
  • Sauvegardes et restauration.
  • Communication publique ou privée.
  • Registre des incidents.