Bonnes pratiques en matière de communication sur les incidents

Communication sur les incidents : qui s'y intéresse ?

Vos clients s'y intéressent. Vos collègues s'y intéressent. Vous devriez vous y intéresser. Un temps d'arrêt mal géré peut être une très mauvaise expérience pour vos clients et vos équipes, et affecter vos résultats. Certains de vos clients peuvent craindre que cette expérience ne soit pas un cas isolé et se tourner vers un concurrent. Vous perdrez de futurs clients en raison du manque de confiance. Le moral de l'équipe peut en pâtir et entraîner une baisse de productivité. Et vous pouvez dire adieu à la bonne publicité par le bouche-à-oreille.

Heureusement, les temps d'arrêt non planifiés ne doivent pas nécessairement virer au cauchemar pour le service client. Il s'avère que si vous communiquez avec les clients sur ce qu'il se passe et ce que vous faites pour résoudre le problème, ils comprendront et auront une réaction beaucoup moins négative à la situation.

Préparation pour la communication sur les incidents

Une bonne préparation permet d'éviter une dégradation des performances. Si la formule est pertinente avant de partir au combat, elle l'est tout autant pour votre stratégie de communication sur les incidents. En cas d'incident, lorsque vous serez dans le feu de l'action, vous vous féliciterez d'avoir consacré du temps à la communication.

Définissez ce que vous considérez comme un incident

Avant de pouvoir communiquer sur les incidents, nous devons déterminer ce qui constitue un incident. De nombreuses SSII s'appuient sur un système standardisé de définition de la gravité à quatre niveaux. Voici un excellent guide sur les définitions de gravité tiré de notre propre manuel de gestion des incidents.

Quels que soient vos seuils de gravité des incidents, il est important de fixer une limite claire (idéalement axée sur une métrique mesurable). Si vous désignez un incident comme étant de gravité 1, il est important que tout membre de votre équipe puisse savoir exactement ce que cela signifie.

Un système de gravité est également utile pour éliminer les doutes et incertitudes inhérents aux temps d'arrêt.

Quel que soit le système que vous choisissez, nous recommandons un plan de communication à tolérance zéro pour tout incident lié à des problèmes de sécurité ou à une perte de données.

Choisissez à l'avance vos solutions, vos canaux et vos modèles de messages pour communiquer

Les équipes de support professionnelles et les ingénieurs chargés de la fiabilité du site ne choisissent pas des canaux de communication de façon impromptue. Ils créent un plan à l'avance.

Il existe six grands canaux pour la communication sur les incidents :

• Page d'état dédiée
• État intégré
• E-mail
• Outil de chat professionnel
• Réseaux sociaux
• SMS

Page d'état dédiée

Nous recommandons aux équipes d'utiliser une page d'état dédiée comme principale solution de communication en cas d'incident. Que vous la développiez vous-même ou que vous utilisiez une solution hébergée comme Statuspage, il est important de fournir à vos clients et collègues une source de référence claire en cas d'incident. Statuspage offre également à vos utilisateurs la possibilité de s'abonner pour recevoir des mises à jour dès leur publication. Vos équipes sont ainsi libérées d'une tâche de support et peuvent se concentrer sur la résolution du problème.

État intégré

Statuspage facilite également l'intégration des informations d'état directement sur n'importe quel site web de nos clients. Nous savons que la plupart des visiteurs sont susceptibles de consulter la page d'accueil ou la page de support d'un fournisseur avant de rechercher une page d'état. Le widget intégré (en voici un exemple) permet facilement d'informer ces visiteurs qu'un incident est en cours. Les visiteurs peuvent également cliquer sur le widget pour accéder à la page d'état.

E-mail

Vous pouvez donner à votre public la possibilité de s'abonner aux mises à jour par e-mail grâce à un produit comme Statuspage. Que vous utilisiez directement votre outil de messagerie ou une page d'état pour déclencher les envois d'e-mails, utilisez un canal fiable pour la communication sur les incidents.

Outils de chat

Réduisez les changements de contexte et le manque d'informations pour les employés et les agents grâce au chat Jira Service Management. Le chat Jira Service Management synchronisera les conversations dans Slack ou Microsoft Teams et vos tickets. Un échange fluide entre les outils de chat populaires et le support permet de bien contextualiser le problème, et donc de le résoudre rapidement.

Réseaux sociaux

De nombreuses équipes utilisent les réseaux sociaux comme Twitter comme moyen de communication lors d'un incident. Il est bon de les intégrer à votre stratégie, mais ne comptez pas sur eux comme seul moyen de communication.

SMS

Les SMS, ou messages texte, constituent souvent le moyen le plus direct de contacter quelqu'un, et une préférence pour beaucoup de personnes lorsqu'il s'agit d'alertes entrantes critiques comme une annonce de temps d'arrêt. C'est également un canal où la fatigue peut rapidement se faire sentir et où les gens se désabonneront s'ils reçoivent trop de messages qui ne sont pas pertinents pour eux.

Aucun de ces canaux n'est une solution miracle pour la communication sur les incidents. Chacun présente des avantages, mais c'est utilisés ensemble qu'ils révèlent leur plein potentiel. Par exemple, chez Atlassian, nous publions des messages sur les incidents sur une page d'état, mais nous les diffusons également sur Twitter. Une annonce concernant l'incident est également visible sur notre portail Jira Service Management. Ces messages redirigent ensuite l'utilisateur vers la page d'état où il trouvera plus d'informations sur l'incident. La gestion des incidents dans Jira Service Management permet d'utiliser plusieurs points de communication sans vous emmêler les pinceaux ni perdre la confiance de vos clients en cours de route.

Adaptez les alertes et les communications au bon public

En cas d'incident, vous devez savoir qui contacter, par quel canal et comment procéder en créant le moins de frictions possible et en utilisant des ressources limitées, afin d'éviter un cauchemar pour le service client et/ou des failles dans la communication. Il est préférable de commencer en interne par une équipe de réponse immédiate, puis de progresser vers l'extérieur en sélectionnant les messages pour le bon public.

Bien que chaque organisation soit différente, il s'avère généralement judicieux de répartir ces publics en cinq groupes distincts avec lesquels communiquer :

1. Équipe d'astreinte principale : la première à être informée en cas de problème, presque dès la survenue (en général, par le biais d'outils de surveillance et d'alerte). Les équipes internes travaillent en coulisse pour détecter, swarmer, contextualiser et résoudre les incidents à l'aide d'outils de communication collaboratifs.
2. Équipe de support de première ligne : elle répond directement aux questions et fournit des mises à jour aux clients pendant l'incident. Il s'agit d'un rôle extrêmement important, c'est pourquoi cette équipe doit obtenir les bonnes informations à transmettre aux utilisateurs finaux.
3. Managers et équipe de direction : l'équipe principale doit communiquer avec ce groupe afin de savoir ce qui se passe, de connaître l'impact potentiel sur les deux groupes ci-dessous, et éventuellement d'obtenir une estimation de la durée du problème.
4. Employés dans leur ensemble : les employés doivent être tenus informés de l'évolution des services auxquels ils font confiance. Communiquer de manière proactive avec ces utilisateurs permet de réduire le nombre de questions sur l'état d'avancement et de tickets de support informatique en double, et de se concentrer davantage sur la résolution des problèmes rencontrés.
5. Clients externes : si l'incident touche des clients externes, il convient d'envoyer une communication pour leur expliquer le problème et à quel moment ils peuvent attendre une résolution, ou au moins des mises à jour régulières. Pour les problèmes qui continuent d'affecter la capacité de vos clients à utiliser votre produit, nous recommandons de ne jamais attendre plus d'une heure sans envoyer de mise à jour. En outre, vous devez toujours indiquer la date de la prochaine mise à jour. S'il s'agit d'un incident suffisamment grave, en particulier un incident impliquant la sécurité ou la perte de données, vous souhaiterez peut-être accélérer les communications externes et faire appel aux autres équipes compétentes (juridique, RH, sécurité, etc.)

Définissez des modèles pour la communication sur les incidents et les pannes

Dans l'urgence d'un incident, la dernière chose dont vous voulez vous préoccuper est la formulation d'une annonce d'incident. Une erreur à ce niveau offre une cible parfaite aux gestionnaires non techniques en quête d'une raison quelconque pour critiquer le processus de réponse de votre équipe.

Choisissez à l'avance un langage commun, faites-le approuver par vos managers et enregistrez-le dans un modèle. Vous pourrez facilement y ajouter des informations pertinentes et l'utiliser en cas d'incident.

Voici deux des modèles d'incident que nous utilisons pour notre propre page d'état :

• La charge du site est actuellement supérieure à la normale, ce qui peut entraîner des ralentissements ou une absence de réponse de certaines pages. Nous étudions la cause et vous fournirons une mise à jour dès que possible.
• Notre fournisseur de stockage pour les données de métriques publiques rencontre actuellement des problèmes d'infrastructure. Des mises à jour seront disponibles au fur et à mesure que la situation évolue ou lorsque nous recevrons plus d'informations.

Découvrez d'autres exemples dans notre bibliothèque de modèles d'incident.

Gérez la communication comme un pro

Le cycle de vie d'un incident impliquera probablement plusieurs points de contact. Lorsqu'il est bien conçu, il s'articule autour de trois volets pour chaque incident : premier contact, mise à jour pendant l'incident, résolution et post-mortem.

Prologue : communication d'équipe interne centralisée

Avant toute chose, les équipes internes en bout de chaîne d'un incident doivent disposer d'une plateforme de communication établie et être prêtes à swarmer lorsqu'un problème survient.

Centralisez et filtrez les alertes dans tous vos outils de surveillance, de journalisation et de CI/CD pour vous assurer que votre équipe réponde au plus vite. Une plateforme comme Jira Service Management permet aux équipes de swarmer rapidement sur un incident, d'obtenir du contexte et de rester en contact pendant toute la durée de cet incident.

Volet 1 : Premier contact

La mise à jour initiale est la plus importante. Tout, de ce que vous dites à la façon dont vous le dites et au moment où vous le dites, se répercute sur la façon dont votre réponse sera perçue. C'est dans ces moments qu'il est vraiment utile de disposer d'un modèle défini à l'avance.

Votre objectif devrait être de prendre rapidement connaissance du problème, de résumer brièvement l'impact connu, de promettre d'autres mises à jour et, si vous êtes en mesure de le faire, d'atténuer les préoccupations relatives à la sécurité ou à la perte de données. Il est important de reconnaître qu'il y a un problème, même si vous ne connaissez pas encore les détails exacts.

Volet 2 : Mises à jour régulières pendant l'incident

La communication en cours d'incident est essentielle.

Les équipes SRE de Google considèrent la supervision du rôle de responsable des communications comme essentielle lors d'un incident.

Extrait du livre « Site Reliability Engineering » de Google sur le rôle de responsable des communications :

« Cette personne représente notre groupe de travail de réponse aux incidents auprès du public. Ses tâches comprennent la communication de mises à jour périodiques à l'équipe de réponse aux incidents et aux parties prenantes (généralement par e-mail), ainsi que le maintien de l'exactitude et la mise à jour du document d'incident. »

Cette personne sera également chargée de continuer à mettre à jour la page d'état ou de publier des mises à jour sur d'autres canaux au fur et à mesure de l'évolution de la situation. Une simple mise à jour indiquant : « Nous travaillons toujours à la résolution du problème, rien de nouveau à signaler » est préférable à ne rien dire. Les gens laissés dans l'ignorance tendent à s'imaginer le pire.

La communication avec les utilisateurs concernés et les autres parties prenantes est indispensable. Utilisez vos canaux prédéterminés pour tenir les utilisateurs informés de la situation. Sur une page d'accueil, il peut s'agir d'une alerte Statuspage qui permet aux clients de savoir que votre équipe est consciente du problème et aux agents de gagner du temps en cas de redondance. Tenez vos parties prenantes informées via différents canaux de notification, notamment par SMS, par e-mail et par notification Push sur mobile.

Quel que soit l'outil que vous choisissez d'utiliser, nous vous recommandons d'identifier un canal de communication principal et de renvoyer les utilisateurs des autres canaux vers celui-ci. La gestion des communications sur les incidents via Jira Service Management garantit que les bons messages sont transmis aux bonnes personnes.

Volet 3 : Résolution, post-mortem, prochaines étapes

En 2010, Facebook a subi sa plus importante panne à ce jour. Pendant environ 2 heures et demie, le réseau social n'a pas été disponible pour plusieurs millions de son demi-milliard d'utilisateurs.

Le timing n'aurait pas pu être pire pour le géant technologique en plein essor, dont la croissance explosive n'en était encore qu'à ses balbutiements et qui peinait encore à prouver au monde des affaires que son service était à la hauteur du battage médiatique qui l'entourait.

Quand la situation s'est calmée, un ingénieur de Facebook a posté un résumé de 395 mots au sujet de l'incident sur le blog d'ingénierie de l'entreprise.

Extrait du blog :

« Tôt aujourd'hui, Facebook a rencontré une panne et était inaccessible pour beaucoup d'entre vous pendant environ 2,5 heures. Cette panne est la pire que nous ayons eue à déplorer depuis plus de quatre ans, et nous tenions d'abord à nous en excuser. Nous souhaitions également vous fournir plus de détails techniques sur ce qui s'est passé et partager avec vous une grande leçon que nous en avons tiré. »

Le plan du post-mortem est simple :

• Reconnaître le problème, faire preuve d'empathie avec les personnes touchées et présenter des excuses
• Expliquer ce qui a mal tourné et pourquoi
• Expliquer les mesures prises pour corriger l'incident et pour éviter qu'il se reproduise
• Reconnaître le problème, faire preuve d'empathie et présenter à nouveau des excuses

Pour cette communication, inutile d'utiliser un langage châtié ou d'en faire trop. Restez simple et direct. Par exemple, cet extrait tiré du blog de Facebook :

« Nous nous excusons encore une fois pour cette panne. Sachez que nous prenons la performance et la fiabilité de Facebook très au sérieux. »

Ce type de formulation renforce la confiance de vos clients et collègues qui percevront votre équipe comme réfléchie et vigilante. Parcourez notre propre modèle de post-mortem de réponse aux incidents pour en savoir plus.

En réalité, lorsque vous exploitez des services continus, des pannes peuvent parfois survenir. Communiquer efficacement pendant les temps d'arrêt peut renforcer la confiance à la fois avec les collègues et avec les clients. Bien réagir peut faire toute la différence. Nous avons également créé cet outil simple pour vous aider à écrire rapidement des communications efficaces en cas d'incidents.