Communiquer avec ses clients pendant un incident

Pendant un incident, la règle tient en trois mots : tôt, régulièrement, simplement. Prévenez vos clients dès que vous constatez un problème qui les touche, donnez des nouvelles à intervalles réguliers en annonçant l'heure de la suivante, décrivez ce qu'ils constatent plutôt que des détails techniques, puis concluez par un message de fin. Quand vous revendez un assistant IA, la difficulté est que la panne est souvent chez l'éditeur : vous devez donc savoir à l'avance comment il vous préviendra, pour pouvoir prévenir vos propres clients.

Avant l'incident : préparer

Un message de crise s'écrit mal sous pression. Préparez à froid :

• la chaîne d'alerte : comment l'éditeur vous prévient, qui chez vous reçoit l'alerte, qui prévient les clients (voir qui fait quoi entre partenaire et éditeur) ;
• la liste des contacts à prévenir chez chaque client, avec un second contact ;
• des modèles de messages pour les étapes ci-dessous ;
• un canal : mail, page d'état, message dans l'espace client.

L'ANSSI, l'autorité nationale chargée de la sécurité des systèmes d'information, publie un guide intitulé « Anticiper et gérer sa communication de crise cyber », dont une nouvelle version est parue le 04/06/2026. Il comprend dix fiches pratiques, dont « créer une boîte à outils dédiée », « rédiger les messages clés », « piloter sa communication de crise interne » puis « externe », et « réaliser son RETEX » (retour d'expérience), ainsi qu'une liste de contrôle (guide de l'ANSSI, consulté le 15/11/2026).

Pendant l'incident : quatre étapes de message

Le guide de PagerDuty sur les pages d'état (les pages publiques qui affichent l'état d'un service) recommande de faire progresser le statut affiché : « Investigating », « Identified », « Monitoring a fix », soit en analyse, cause identifiée, correctif en surveillance (PagerDuty, consulté le 15/11/2026).

Les repères de rythme de PagerDuty :

• accuser réception d'un problème qui touche les clients « within 10 to 15 minutes of detection », dans les 10 à 15 minutes qui suivent sa détection ;
• « For major outages, an update every 30 minutes is a good baseline » : pour une panne majeure, une mise à jour toutes les 30 minutes est une bonne base ;
• ne jamais rester silencieux, même quand la seule nouvelle est que le travail continue ;
• indiquer dans chaque message l'heure de la prochaine mise à jour.

Ces repères sont des conseils, pas une norme : prenez-les comme point de départ, et tenez compte du rythme auquel l'éditeur de votre plateforme vous informe lui-même.

Ce qu'on ne publie pas

PagerDuty déconseille de mettre dans un message public des traces techniques, des abréviations internes ou des détails complexes. Utilisez les noms que le client connaît (« l'assistant de votre site », pas le nom d'un serveur). Soyez honnête sur ce que vous ne savez pas encore : « nous cherchons la cause » vaut mieux que le silence. Ne promettez pas d'heure de retour que vous ne maîtrisez pas, surtout si la correction dépend de l'éditeur.

Le message de fin et l'analyse

Une fois le service rétabli, PagerDuty conseille un message final qui résume la correction et s'engage sur une analyse après incident. Le livre de Google sur l'ingénierie de la fiabilité définit cette analyse comme « a written record of an incident, its impact, the actions taken to mitigate or resolve it », un compte rendu écrit de l'incident, de son impact et des actions menées, complété par les causes et les actions pour éviter qu'il se reproduise (Google SRE, consulté le 15/11/2026). Il insiste sur une analyse « blameless », sans recherche de coupable : on améliore les processus, on ne désigne pas une personne.

Pour vos clients, ce compte rendu tient en quelques lignes : ce qui s'est passé, pendant combien de temps, ce qui a été touché, ce qui a été fait, ce qui change pour éviter que cela se reproduise. Si la cause est chez l'éditeur, demandez-lui son propre compte rendu avant d'écrire le vôtre.

Si l'incident touche des données personnelles

Un incident peut être aussi une violation de données personnelles. La CNIL (Commission nationale de l'informatique et des libertés) rappelle que le sous-traitant « doit notifier au responsable du traitement toute violation de données dans les meilleurs délais », et que le responsable du traitement doit, si la violation présente un risque pour les personnes, la notifier à la CNIL « dans un délai maximal de 72h » (CNIL, consulté le 15/11/2026). Dans un cas fictif consacré à un sous-traitant touché par une cyberattaque, elle décrit des mises à jour « faites de façon régulière auprès des clients » (CNIL). Qui est responsable du traitement et qui est sous-traitant dans votre chaîne dépend de vos contrats : faites-le préciser par un avocat ou un délégué à la protection des données, avant le premier incident.

Après : relire sa procédure

Chaque incident est une répétition générale. Relisez avec votre équipe ce qui a manqué : un contact périmé, un modèle de message absent, une alerte reçue trop tard. Mettez à jour votre procédure d'escalade et la fiche « contacts et escalade » de votre documentation.