L'essentiel résumé pour vous :
- Un bon message de panne informatique répond à cinq questions :
- qu'est-ce qui ne fonctionne pas ;
- qui est concerné ;
- que faire en attendant ;
- ce que fait la DSI ;
- quand arrive la prochaine information.
- La longueur dépend du canal. Un pop-up se lit en dix secondes, un e-mail peut entrer dans le détail.
- Prévoyez un canal qui ne dépend pas de la messagerie. Le jour où Outlook ou Microsoft 365 tombe, vos modèles d'e-mail ne servent plus à rien.
Lundi, 8 h 47. La messagerie ne répond plus. En quelques minutes, le téléphone du support sonne sans interruption, chacun redémarre son poste « au cas où » et les rumeurs circulent plus vite que l'information. La panne n'est pas encore réglée que la DSI fait face à un second problème : le silence.
Ce second problème se prévient. Un message de panne clair, envoyé tôt et sur le bon canal, suffit à faire retomber la pression. Il dit ce qui est touché, qui est concerné, quoi faire en attendant, et quand aura lieu le prochain point.
Vous trouverez ci-dessous 12 modèles prêts à copier, classés par phase : avant une maintenance, pendant une panne, après l'incident. Chacun indique le canal conseillé et reste assez court pour être lu en quelques secondes. En bonus : trois versions SMS, une checklist pour préparer votre kit, et la réponse à la question la plus piégeuse : comment prévenir les collaborateurs quand l'e-mail est lui-même en panne ?
Que doit contenir un message de panne informatique ?
Un message de panne informatique doit répondre à cinq questions : quoi, qui, que faire, que fait la DSI, et quand aura lieu le prochain point. Chaque question laissée sans réponse devient un appel au support.
- Quoi : le service touché, avec les mots des utilisateurs. Écrivez « la messagerie est indisponible », évitez « incident sur le cluster Exchange ».
- Qui : le périmètre. Écrivez « les sites de Lyon et de Grenoble », évitez « certains utilisateurs ».
- Que faire : une seule action, ou l'absence d'action. « Inutile de redémarrer votre poste » évite à lui seul des dizaines de tickets.
- Ce que fait la DSI : une phrase pour rassurer. « Nos équipes sont mobilisées » suffit. Inutile de détailler le diagnostic.
- Prochain point : une heure précise. Écrivez « prochaine information à 10 h 30 », évitez « dès que possible ».
La longueur, elle, dépend du canal. Voici les repères que nous recommandons chez IDERI :
Avant : annoncer une maintenance planifiée
Une maintenance bien annoncée se communique en trois temps : une annonce détaillée quelques jours avant, un rappel le jour même, puis un message de fin. Le rappel est le message le plus souvent oublié. C'est pourtant lui qui évite les documents perdus et les réunions interrompues.
Modèle 1 — Annonce de maintenance (J-7, e-mail ou intranet)
Quand l'envoyer : une semaine avant, pour laisser le temps de s'organiser.
Objet : Maintenance informatique le [jour date], de [heure] à [heure]
Bonjour,
Une maintenance est prévue le [jour date] de [heure début] à [heure fin]
sur [service : messagerie / réseau / application X].
Pendant ce créneau : [impact : service indisponible / ralentissements /
redémarrage de votre poste].
Ce que nous vous conseillons : [enregistrer vos documents avant
[heure] / ne pas planifier de réunion Teams sur ce créneau].
Un rappel s'affichera sur votre poste le jour même.
Une question ? [contact / numéro du support].
Le service informatique
Modèle 2 — Rappel de maintenance (jour J, pop-up)
Quand l'envoyer : une à deux heures avant le début.
Rappel : maintenance de [service] aujourd'hui de [heure] à [heure].
Pensez à enregistrer vos documents avant [heure].
Le service sera indisponible pendant environ [durée].Modèle 3 — Pendant la maintenance (bandeau défilant)
Quand l'afficher : pendant toute la durée de l'intervention.
Maintenance [service] en cours — retour prévu à [heure]. Inutile de contacter le support.Modèle 4 — Fin de maintenance (pop-up)
Quand l'envoyer : dès la fin de l'intervention, avant les premiers tests des utilisateurs.
La maintenance de [service] est terminée : tout fonctionne à nouveau.
En cas de problème, redémarrez [application], puis contactez le support
au [numéro] en précisant « maintenance [date] ».Pendant : signaler une panne ou un incident
Envoyez le premier message dès que la panne est confirmée, même si vous n'en connaissez pas encore la cause. Reconnaître le problème montre que la DSI a la main, et c'est ce qui fait baisser le volume d'appels.
Modèle 5 — Premier message de panne (pop-up)
Quand l'envoyer : dans les minutes qui suivent la confirmation de la panne.
Panne en cours : [service] est indisponible depuis [heure].
Nos équipes sont mobilisées. Inutile de redémarrer votre poste
ou d'appeler le support. Prochaine information à [heure].Modèle 6 — Point d'étape (bandeau défilant ou pop-up)
Quand l'envoyer : à l'heure annoncée dans le message précédent, sans exception.
Point [heure] : panne [service] — cause identifiée, rétablissement estimé
à [heure]. Prochain point à [heure].Si la cause n'est pas encore connue, dites-le simplement : « Recherche de la cause en cours ». Un point d'étape sans nouveauté rassure davantage qu'un silence.
Modèle 7 — Panne de messagerie ou de Microsoft 365 (pop-up, jamais par e-mail)
Quand l'envoyer : dès que la messagerie est confirmée hors service. Par définition, ce message ne peut pas partir par e-mail.
La messagerie [Outlook / Microsoft 365] est actuellement indisponible.
Les e-mails envoyés pendant la panne pourraient arriver en retard.
Pour une urgence, utilisez [téléphone / Teams si disponible].
Prochaine information à [heure].Modèle 8 — Panne limitée à un site ou un réseau (pop-up ciblé)
Quand l'envoyer : uniquement aux postes du site concerné.
[Site / bâtiment / étage] : le réseau est perturbé depuis [heure].
Les autres sites ne sont pas concernés.
Un technicien intervient, retour estimé à [heure].Ne diffusez pas une panne locale à toute l'entreprise. Chaque message qui ne concerne pas son destinataire l'habitue à ignorer le suivant.
Modèle 9 — Application métier indisponible (pop-up)
Quand l'envoyer : aux seuls utilisateurs de l'application, avec la procédure de repli.
[Application : ERP / DPI / logiciel de caisse] est indisponible depuis [heure].
Procédure de secours : [mode dégradé / formulaire papier / autre poste].
Retour estimé à [heure].Modèle 10 — Alerte phishing en cours (plein écran)
Quand l'envoyer : dès le premier signalement d'un faux e-mail qui circule en interne.
ATTENTION : un faux e-mail « [objet du message] » circule en ce moment.
Ne cliquez sur aucun lien et n'ouvrez pas la pièce jointe.
Si vous l'avez déjà fait, appelez immédiatement le [numéro].Modèle 11 — Suspicion de cyberattaque (plein écran)
Quand l'envoyer : sur décision de la cellule de crise, selon votre plan de réponse à incident.
INCIDENT DE SÉCURITÉ EN COURS
N'éteignez pas et ne redémarrez pas votre poste, sauf consigne du service
informatique. Suivez uniquement les instructions de la DSI.
Signalez tout comportement anormal au [numéro].Ces consignes suivent la fiche réflexe de Cybermalveillance.gouv.fr sur les rançongiciels. Elle recommande notamment de déconnecter du réseau les machines touchées, sans les éteindre, pour préserver les éléments utiles à l'enquête. Adaptez ce modèle à votre propre plan de réponse à incident.
Après : clôturer l'incident
Un message de fin d'incident confirme le retour à la normale, précise ce que l'utilisateur doit éventuellement faire et donne, si possible, une explication simple. Sans lui, beaucoup d'utilisateurs continuent de contourner un service qui fonctionne pourtant à nouveau.
Modèle 12 — Résolution d'incident (pop-up + e-mail récapitulatif)
Quand l'envoyer : dès le rétablissement confirmé, puis l'e-mail récapitulatif dans la journée.
Incident résolu : [service] fonctionne à nouveau depuis [heure].
Si le problème persiste sur votre poste, fermez puis rouvrez [application].
Cause : [explication en une phrase]. Merci pour votre patience.L'e-mail récapitulatif qui suit peut tenir en cinq lignes :
- Ce qui s'est passé, en une phrase ;
- La durée de l'interruption ;
- L'impact : services et sites touchés ;
- La cause, sans jargon ;
- La mesure prise pour éviter que l'incident se reproduise.
Bonus : la version notification push, quand le réseau du site est coupé
Quand le réseau d'un site entier tombe, les postes ne reçoivent plus rien : la notification push sur smartphone prend le relais. Ces trois messages tiennent en 160 caractères : une fois les crochets remplis, vérifiez que c'est toujours le cas.
[Entreprise] Réseau indisponible sur le site de [ville] depuis [heure]. Équipes mobilisées. Prochaine info à [heure]. Inutile d'appeler le support.[Entreprise] Point [heure] : panne réseau [ville] en cours de résolution. Retour estimé à [heure]. Prochaine info à [heure].[Entreprise] Réseau rétabli sur le site de [ville]. Si votre poste ne se reconnecte pas, redémarrez-le. Merci de votre patience.Quand l'e-mail est lui-même en panne : quel canal utiliser ?
Si la messagerie tombe, il vous faut un canal qui ne dépend pas d'elle et qui s'affiche directement sur le poste ou le téléphone. Un modèle d'e-mail, aussi bien écrit soit-il, n'atteindra alors personne.
Conclusion pratique : combinez un canal sur le poste (pop-up, bandeau) pour la grande majorité des pannes, et un canal mobile (push ou SMS) pour le cas où le réseau du site lui-même est coupé. Gardez enfin une consigne papier pour le pire des scénarios.
Un outil de notification IT sur le poste de travail comme IDERI note affiche vos messages en pop-up, en bandeau ou en plein écran, sans passer par la messagerie. Il les complète par des notifications push sur smartphone.
Préparer votre kit de communication avant la prochaine panne
Le meilleur moment pour écrire un message de panne, c'est avant la panne. Sous pression, personne ne rédige clairement. Ces six éléments prêts à l'avance font toute la différence.
- Les 12 modèles de cet article, enregistrés dans votre outil de diffusion et adaptés à vos services.
- Des groupes de destinataires prêts à l'emploi : par site, par service, par application métier.
- Un binôme désigné pour rédiger et valider, avec un suppléant pour les congés et les astreintes.
- Un canal de secours testé, qui fonctionne sans la messagerie et, si possible, sans le réseau du site.
- Un rythme de points d'étape convenu à l'avance, pour ne pas l'improviser pendant la crise.
- Une consigne papier affichée dans les services critiques, pour le scénario où plus rien ne fonctionne.
8 règles d'écriture, avec des exemples avant / après
Les messages qui réduisent vraiment les appels au support sont courts, précis sur l'heure, bien ciblés et suivis jusqu'à la fin de l'incident.
- Une heure, pas une promesse. Avant : « Retour rapide. » Après : « Retour estimé à 10 h 30. »
- Les mots des utilisateurs. Avant : « Incident sur SRV-EXCH02. » Après : « La messagerie est indisponible. »
- Une seule action demandée par message. Si vous devez en demander deux, envoyez deux messages.
- Dites aussi ce qu'il ne faut pas faire. « Inutile de redémarrer votre poste » est une consigne aussi utile qu'une action.
- Ciblez le bon périmètre. Avant : un message à toute l'entreprise pour l'imprimante du 2e étage. Après : un message au seul 2e étage.
- Signez. « Le service informatique » rend le message reconnaissable comme officiel, un point essentiel quand un phishing circule.
- Tenez le rythme annoncé. Un point d'étape promis à 10 h 30 part à 10 h 30, même sans nouveauté.
- Retirez le message à la fin. Un bandeau encore affiché après la résolution fait douter de tous les autres.
Mesurer l'efficacité de vos messages
Deux indicateurs suffisent pour savoir si vos messages fonctionnent : le taux de lecture et le nombre de tickets ouverts pendant l'incident. Les accusés de lecture montrent qui a vu le message. La comparaison des tickets entre deux incidents similaires montre ce que le message a évité.
Ce que constatent les clients d'IDERI note :
« En ce qui concerne les incidents majeurs, nos demandes d'assistance informatique ont diminué de 80 à 90 %. »
— Hôpital Bethanien Moers (Allemagne), client IDERI note
« Dès qu'un message est envoyé via IDERI note, le nombre de demandes que nous recevons tend vers zéro. »
— Schwarzwald-Baar Klinikum (Allemagne), client IDERI note
« La notification est envoyée avant même que les utilisateurs ne remarquent le dysfonctionnement. »
— Roller, client IDERI note
D'autres retours sont réunis sur la page témoignages des clients IDERI note. Pour la dimension organisationnelle, voir aussi notre article sur la communication IT proactive dans la gestion des incidents.
Automatiser le premier message depuis votre monitoring
Le moyen le plus rapide de prévenir vos utilisateurs, c'est de laisser votre outil de monitoring envoyer le premier message dès qu'une panne est détectée. Le modèle 5 part alors en quelques secondes, avant même le premier appel.
IDERI note se connecte aux outils de monitoring informatique les plus répandus : Nagios, Checkmk, Icinga et PRTG. Il accepte aussi les déclenchements par API REST, SDK ou PowerShell. Pour la mise en œuvre, voir nos guides pour connecter IDERI note à PRTG et à Checkmk.
Pour les maintenances, programmez vos messages avec une heure de début et de fin : le rappel du modèle 2 s'affiche seul au bon moment, puis disparaît à la fin du créneau. Pour une vue d'ensemble, lisez notre article sur le système de notification pour les entreprises.
Conclusion : des modèles prêts, et un canal qui tient quand tout le reste tombe
Une panne se gère en deux temps : la réparer, et en parler. Le second se prépare aujourd'hui, à froid. Enregistrez les 12 modèles, adaptez les crochets à vos services, désignez qui les envoie.
Puis vérifiez l'essentiel : le jour où la messagerie s'arrête, votre canal principal fonctionne-t-il encore ? C'est ce jour-là qu'il sert vraiment.
