Aller au contenu principal
Boletolibre

Modèle de communication en cas de panne DNS pour un événement

Quand le domaine d’un événement ne répond plus, les participants doivent savoir ce qui est touché et où lire une information fiable. Préparez un canal indépendant du domaine concerné, puis communiquez uniquement ce que votre équipe a vérifié.

La rédaction de Boletolibre

Publié

Communication d’une panne DNS: impact vérifié, canal indépendant, mises à jour et rétablissement constaté.
Annoncez le rétablissement après avoir vérifié chaque parcours participant.

Télécharger le kit de messages de panne DNS

Télécharger le kit de messages modifiable (Markdown, en anglais)

Le kit modifiable contient des messages pour l’enquête, les mises à jour et le rétablissement, ainsi qu’une matrice d’impact et un journal de validation. Remplacez les champs entre crochets et supprimez toute affirmation non vérifiée. Ce document aide à communiquer; il ne répare pas le DNS.

Établir l’impact confirmé avant de publier

Parcours participantVérification avant de communiquer
Informations événementChargement de la page depuis un réseau indépendant
InscriptionNouvelle inscription et confirmation reçue
Billets et paiementLien officiel et parcours confirmé par le prestataire
E-mail et assistanceEnvoi, réception et contact de secours accessibles

Le site, le formulaire, le paiement, les e-mails ou certains réseaux seulement peuvent être touchés. Testez chaque parcours, puis notez le symptôme, l’heure avec fuseau, la preuve et la personne qui l’a confirmé. N’attribuez pas la cause au fournisseur DNS sans confirmation.

Choisir un canal utilisable pendant la panne

Utilisez une page de statut ou un compte social dont le domaine, la connexion et les notifications ne dépendent pas du domaine en panne. Faites connaître cette adresse à l’avance. Si les e-mails utilisent le même domaine, prévoyez une autre voie. Vérifiez tout lien de billetterie de secours avant sa diffusion.

Mettre à jour sans inventer de délai

Le premier résultat de recherche propose des messages par phase. Pour l’événement, précisez ce qui échoue, ce qui fonctionne, l’heure de la dernière observation, une solution de repli vérifiée et l’heure du prochain point avec fuseau. Sans estimation fiable, dites-le. Publiez aussi à l’heure annoncée si rien n’a changé.[1][2]

Enquête en cours — « Certains participants ne peuvent pas ouvrir [page/inscription]. Constaté à [heure et fuseau]. [Billetterie] est [opérationnelle/non vérifiée]. Suivez [URL indépendante]. Prochain point à [heure et fuseau]. Aucun délai de rétablissement confirmé. »

Vérifier le rétablissement par parcours participant

Avant de déclarer l’incident résolu, testez la page publique, une inscription, le parcours de billetterie et l’envoi des e-mails touchés. Essayez si possible un autre réseau. Une réponse DNS corrigée ne prouve pas à elle seule le retour de tous les services; signalez les problèmes restants.

Retirer les consignes temporaires et tirer les leçons

Après stabilisation, retirez les liens provisoires et épinglez l’état final. Conservez la chronologie des messages et des décisions. Révisez ensuite le canal de secours, les responsables et les coordonnées dans le kit.

Sources et lectures complémentaires

  1. System Outage Notification TemplatesUptimeRobot · Consulté
  2. Incident template libraryAtlassian Statuspage · Consulté
  3. Incident communication templates and examplesAtlassian · Consulté