Checklist de reprise après incident pour un client du secteur associatif

Quarante-sept minutes d’indisponibilité totale, dont douze minutes où seul le formulaire de don restait inaccessible pendant que le reste du site répondait normalement : c’est le bilan d’un incident récent chez un client du secteur associatif, provoqué par une saturation de connexions à la base de données pendant un pic de trafic lié à une campagne de collecte relayée sur les réseaux sociaux.

Sur ce type de structure, la remise en service technique n’est que la première moitié du travail. Le trésorier et la direction ont besoin de savoir, dans l’heure, si des dons ont été perdus, combien, et ce qui a été fait pour que cela ne se reproduise pas pendant la prochaine campagne. Cette checklist est celle que nous suivons désormais systématiquement après tout incident touchant un client dont l’activité dépend directement de la disponibilité d’un formulaire de paiement.

1. Confirmer techniquement la fin de l’incident

1. Vérifier que le site répond en HTTP 200 depuis au moins trois emplacements géographiques différents, pas uniquement depuis le poste de l’équipe technique.
2. Contrôler les logs du serveur de base de données pour s’assurer que le nombre de connexions actives est revenu sous le seuil d’alerte, pas seulement sous le seuil de blocage.
3. Tester manuellement le parcours de don complet, du clic sur le bouton jusqu’à la page de confirmation, avec une carte de test si le prestataire de paiement le permet.

2. Chiffrer l’impact réel sur les dons

C’est l’étape la plus sensible et souvent la plus négligée dans l’urgence. Il faut croiser trois sources : les logs du serveur web pour identifier les requêtes échouées vers l’URL du formulaire de don, le tableau de bord du prestataire de paiement pour repérer les tentatives de transaction en erreur pendant la même fenêtre, et les statistiques d’audience pour estimer le nombre de visiteurs concernés par la fenêtre d’indisponibilité.

grep "POST /faire-un-don" /var/log/nginx/access.log \
  | awk '{print $4, $9}' \
  | grep -E "14:0[0-9]:.* (500|502|503|504)"

Sur cet incident précis, ce croisement a permis d’estimer à sept le nombre de tentatives de don ayant échoué pendant la fenêtre critique, un chiffre à la fois précis et rassurant à communiquer plutôt qu’une estimation vague.

3. Vérifier qu’aucun don n’est resté en état incertain

• Contrôler dans le tableau de bord du prestataire de paiement les transactions marquées comme « en attente » ou « incertaines » sur la période, qui peuvent correspondre à des dons prélevés mais non confirmés côté site.
• Rapprocher ces transactions avec les entrées correspondantes dans la base WordPress ou le CRM de dons, pour identifier tout don prélevé sans confirmation envoyée au donateur.
• En cas d’écart, préparer une liste nominative pour que l’association puisse contacter directement chaque donateur concerné, plutôt que d’attendre une réclamation.

4. Préparer la communication interne avant la communication externe

Le trésorier ou la direction a besoin d’un message court et factuel avant de décider s’il communique aux donateurs. Notre format tient en quatre lignes : durée exacte de l’incident, cause identifiée, nombre de dons potentiellement affectés, mesures déjà prises. Ce message est transmis dans l’heure qui suit la confirmation technique de la fin de l’incident, jamais avant, pour éviter d’annoncer une résolution qui ne tiendrait pas.

5. Documenter pour la prochaine campagne

L’incident a révélé que le nombre maximal de connexions à la base de données n’avait jamais été dimensionné pour un pic de trafic de campagne, seulement pour le trafic quotidien habituel. Le correctif immédiat a été une augmentation temporaire du pool de connexions ; le correctif durable, ajouté à la documentation du projet, consiste à prévenir l’équipe technique avant chaque campagne de communication planifiée par l’association, pour ajuster les ressources en amont plutôt qu’en réaction.

Sur un site associatif, l’incident technique et l’incident de confiance ne sont pas la même chose. Le premier se résout en minutes, le second se répare avec des chiffres précis et une communication rapide.

Notre retour d’expérience

Cette checklist n’a rien d’exceptionnel techniquement ; sa valeur tient à l’ordre des étapes. Vérifier avant de communiquer, chiffrer avant de rassurer, et documenter avant d’oublier : sur un client dont l’activité dépend de la confiance des donateurs, ces trois réflexes évitent qu’un incident technique de moins d’une heure ne devienne un sujet de discussion pendant des mois.