Nous vous proposons cet article co-signé par Pierre-Malo Bovet, Ingénieur Réseaux, et Akéla Bendjeddou, Responsable Marketing et Communication, au sein de l’équipe France-IX. Bonne lecture !

***************

Aucune manœuvre technique, qu’elle soit initiée par l’homme ou la machine, n’est infaillible. Les pannes, cela arrive, on le sait tous.

En cas d’incident, que faut-il communiquer ? À quelle fréquence ? À qui ? Comment ? Ces questions font figure de casse-tête pour nombre d’entre nous pour qui la qualité de service reste au cœur des priorités, car il n’y a évidemment pas de mode d’emploi unique, au mieux des bonnes pratiques.

À la question : « faut-il communiquer lors d’un incident ? », la réponse est sans conteste oui, dès lors que le service est impacté. Mais qui est impacté quand on parle d’Internet ? Dans le cas de France-IX, une coupure pour un seul acteur à grand débit peut avoir autant d’impact qu’un incident atteignant dix acteurs réunis. Il s’agit alors d’être capable d’évaluer ou du moins d’estimer très rapidement les membres impactés, afin de décider ensuite de l’approche de communication à suivre.

Se pose ensuite la question du timing. Quand faut-il commencer à communiquer à partir du moment où le problème est détecté ? La prudence doit être de mise et un équilibre doit être trouvé entre communiquer trop tôt, et ne pas communiquer assez tôt. Dans le premier cas, communiquer avec des éléments préliminaires et donc incomplets, signifie aussi prendre le risque de revenir sur sa première analyse et ainsi perdre en crédibilité auprès de son audience, en dévoilant un faux-positif par exemple, si l’impact est mal estimé de prime abord, ce qui est humainement possible. Dans le second cas, ne pas communiquer immédiatement peut être assimilé à un manque de transparence par certains clients, voire à une rétention d’informations, et provoquer un bad buzz, extrêmement préjudiciable pour l’image d’une société et la perception de sa qualité de service par le public.

Le critère qui semble prévaloir est donc la précaution : l’équipe technique France-IX, par exemple, met en place une communication en plusieurs temps. Une première alerte informant de l’incident est envoyée aux membres, en précisant le périmètre estimé de l’impact, puis nous fournissons des updates réguliers en fonction de l’évolution de la situation, en étoffant peu à peu les éléments grâce aux résultats de nos investigations sur l’incident. Cette approche est mise en place dans la mesure où l’incident a une portée qui impacte plusieurs membres. Par défaut, une communication au moins une fois toutes les heures en début d’incident est généralement appréciée.

Cette solution intermédiaire permet d’offrir toute la transparence possible à nos membres et d’éviter de nous soumettre à des délais trop longs si nous devions attendre d’avoir assez d’éléments concrets en notre possession.

Une autre question importante concerne le niveau d’informations à donner. Lorsque le public est technique, doit-on entrer dans les détails de l’architecture ? Cependant, fournir des mises à jour tous les quarts d’heure qui plus est, détaillées, demande d’avoir suffisamment de ressources pour résoudre l’incident et être en même temps sur le pont pour communiquer.

Autre question qui peut être considérée comme épineuse, lorsque l’entreprise dispose d’un service communication : est-ce à ce dernier d’assurer le relai d’informations ? Peut-il être réactif, peut-il être assez technique pour délivrer l’information sans faire d’erreurs qui pourraient, quant à elles, avoir des effets pervers ?

Pour que cette option fonctionne, le transfert d’informations entre les équipes doit se faire sans accroc, avec une réactivité optimale de toutes les équipes. Mais encore une fois, nous touchons ici au sujet des ressources et chaque entreprise compose comme elle le souhaite et surtout, comme elle le peut.

Chez France-IX, dire qu’il y a un incident sans en donner la nature revient à s’exposer à des de-peers massifs, c’est-à-dire à l’interruption massive par les membres de leurs sessions de peering. Des coupures qui pourront être interprétées comme étant la conséquence de l’incident alors qu’elles ne sont pas liées directement à celui-ci. Ces réactions en chaîne sont évidemment synonymes de temps d’analyse rallongé, car l’incident doit être analysé dans son ensemble et comme pour toute expérience, la mesure et les biais d’interprétation changent les résultats.

D’un autre côté, si le service technique prend en charge la communication, est-ce du temps qu’il aurait pu plutôt dédier à la résolution de l’incident, en particulier si les ressources sont limitées ? La réponse à cette question réside encore et toujours dans l’arbitrage, car nulle entreprise ne dispose de moyens techniques ou humains illimités.

Le RFO (Reason For Outage) revêt alors une importance capitale pour nos membres qui doivent pouvoir comprendre et justifier à leur hiérarchie ou à leurs propres clients l’impact de l’incident en question.

La tentation d’en dire le moins possible dans le RFO afin d’éviter des débats peut alors se présenter. Tout le monde admettra que plus l’on ajoute de détails, plus l’on s’expose aux critiques. Le bon dosage de l’information est alors primordial, car certains sont tentés d’entamer des discussions qui n’ont pas forcément lieu d’être sur l’architecture réseau par exemple, alors qu’ils ne disposent pas de l’historique de l’infrastructure ou d’éléments de contexte suffisants pour juger de la situation, en particulier dans le cadre d’un incident où l’urgence prévaut.

Chez France-IX, nous donnons un certain nombre de détails sur l’infrastructure mais lorsque nous publions un RFO, nous n’avons pas forcément tous les éléments à disposition tout de suite. Le bon fonctionnement de la plateforme dépend aussi de partenaires de confiance. Communiquer trop vite, ou du moins avant d’avoir suffisamment analysé la situation, peut également être préjudiciable pour eux. Cependant, il est nécessaire de publier le RFO très rapidement, alors nous prenons le parti d’être réactif et de le compléter plus tard si besoin est.

Quoiqu’il en soit, la communication est toujours utile, pertinente et importante, quelle qu’en soit la teneur. Nous tirons tous des enseignements de la communication faite autour d’incidents, puisque le fait de délivrer des informations publiques amène à récolter des retours et recommandations pertinents, qui font avancer la communauté.

Admettre que l’on a eu un incident peut nous faire sentir parfois honteux. Les raisons de l’incident sont souvent humaines car oui, les humains font des erreurs, et parfois même idiotes. Nous établissons des process, nous construisons des architectures résilientes, nous les testons dans des labs pour connaître les réactions de l’équipement mais la qualité même exceptionnelle d’une infrastructure n’en fait pas une infrastructure infaillible.

Il est important de lever le climat de honte qui entoure la communication sur les incidents techniques car le blaming voire shaming envers les acteurs, gros ou petits, qui optent pour la transparence est contre-productif pour tous et incite à l’opacité. Nous devons encourager la transparence, dans l’intérêt collectif, parce qu’elle constitue un incroyable levier pour faire avancer l’ensemble de la communauté. Pensez-y la prochaine fois que vous recevrez une notification d’incident, même si l’explication vous semble idiote, incongrue ou incomplète, voyez plutôt la démarche de transparence à l’initiative de cette communication comme une preuve d’humilité, un moyen d’apprendre et un vecteur d’amélioration.

Nous serions très curieux d’avoir votre avis en commentaire : et vous, comment pensez-vous qu’il faille communiquer ?