Decision Log et communication de crise : le registre des décisions comme antidote aux contradictions

En communication de crise, on imagine souvent que tout se joue dans la prise de parole : le communiqué envoyé aux rédactions des grands médias, la conférence de presse avec les principaux journalistes, le post sur les réseaux sociaux, la FAQ, le porte-parole pour répondre aux questions difficiles de la presse. En réalité, la plupart des organisations ne perdent pas une crise parce qu’elles “ont mal parlé”. Elles la perdent parce qu’elles n’ont pas su décider ou parce qu’elles ont décidé, mais sans le documenter, sans l’assumer, sans aligner l’interne et l’externe, et sans pouvoir expliquer, quelques heures plus tard, pourquoi elles ont changé de cap.

C’est ici qu’intervient un outil aussi simple que redoutablement efficace : le Decision Log (registre des décisions). Le Decision Log est la colonne vertébrale silencieuse de la communication de crise insiste Florian Silnicki, Expert en communication de crise et Président Fondateur de l’agence LaFrenchCom. Il ne “fait” pas de la communication ; il rend la communication possible, cohérente, vérifiable. Il permet de sortir de l’improvisation, de limiter les contradictions, d’accélérer les validations, de sécuriser le juridique, et de fournir au porte-parole un socle robuste : non pas des opinions, mais des décisions datées, attribuées, justifiées.

Qu’est-ce qu’un Decision Log, exactement ?

Un Decision Log est un registre horodaté, structuré et traçable des décisions significatives prises pendant une crise.

Ce n’est pas :

• un compte rendu de réunion,
• une to-do list (liste d’actions),
• un fil de discussion,
• une succession de “on a dit que…”.

C’est un document (ou un outil) qui répond à cinq questions fondamentales :

1. Quelle décision a été prise ? (formulation claire)
2. Quand a-t-elle été prise ? (date/heure, fuseau si besoin)
3. Par qui et avec quelle autorité ? (décideur + niveau d’approbation)
4. Pourquoi ? (rationale : objectifs, risques, contraintes, alternatives)
5. Quelles conséquences ? (actions, communication, obligations, impact)

Dans une crise, les faits évoluent et les options se referment. Une organisation doit décider avec une information imparfaite, sous pression médiatique et émotionnelle. Le Decision Log n’a pas pour but de “justifier” après coup : il a pour but de piloter. Il met de l’ordre dans un moment où l’organisation est naturellement tentée de réagir au bruit, aux rumeurs, ou aux injonctions externes.

Pourquoi le Decision Log est un outil de communication (même s’il est interne)

La communication de crise est jugée sur trois critères, souvent invisibles mais décisifs :

• Cohérence : l’organisation se contredit-elle ?
• Crédibilité : peut-elle prouver ce qu’elle affirme ?
• Maîtrise du processus : sait-elle ce qu’elle fait et pourquoi ?

Or, ces trois critères reposent sur la capacité à dire : “Voici ce que nous avons décidé, quand, et pourquoi.”

La cohérence dépend des décisions, pas des slogans

Quand le public perçoit une contradiction (“hier vous disiez A, aujourd’hui B”), le problème n’est pas seulement rhétorique. Le problème est souvent organisationnel : la décision a changé, ou a été interprétée différemment par plusieurs équipes, ou n’a pas été formalisée. Le Decision Log réduit ce risque en imposant une vérité interne commune.

La crédibilité dépend de la traçabilité

Dans une crise, tout est capturé, archivé, comparé. Les journalistes, les autorités, les clients, les salariés confrontent vos déclarations aux actes. Un Decision Log est une “preuve de pilotage” : il montre que l’organisation n’est pas dans la réaction aléatoire, mais dans une séquence de décisions structurées.

La maîtrise du processus est une réponse à l’incertitude

Le public accepte parfois que vous ne sachiez pas tout. Il accepte beaucoup moins que vous ayez l’air de naviguer à vue. Le Decision Log permet une communication de “méthode” : même si les causes ne sont pas établies, vous pouvez démontrer que les décisions prioritaires (sécurité, assistance, enquête, continuité) sont prises et suivies.

Qu’est-ce qu’une “décision” à logger ? La règle des décisions “engageantes”

Tout ne mérite pas d’entrer dans un Decision Log, sinon il devient illisible. Le point clé est de définir ce qui constitue une décision engageante.

On logge généralement les décisions qui :

1. Engagent la sécurité ou la protection
   Exemple : arrêt d’une ligne, évacuation, rappel produit, confinement d’un système.
2. Engagent un public externe (promesse, compensation, calendrier, politique)
   Exemple : indemnisation, gratuité, extension de garantie, monitoring offert, politique de remboursement.
3. Engagent l’organisation juridiquement ou réglementairement
   Exemple : notification à une autorité, dépôt de plainte, communication officielle, conservation de preuves.
4. Engagent la réputation (posture, excuses, reconnaissance, choix de porte-parole)
   Exemple : le CEO s’exprime, choix d’un audit indépendant, publication d’indicateurs.
5. Modifient la stratégie ou le périmètre de la gestion de crise
   Exemple : passage d’un incident local à une crise nationale, activation du plan de continuité, fermeture temporaire de points de vente.
6. Sont potentiellement contestables (et donc nécessitent un “pourquoi”)
   Exemple : ne pas communiquer une information à un moment donné, refuser une demande médiatique, modérer certains contenus.

À l’inverse, on ne logge pas (ou on logge ailleurs) les micro-tâches : “appeler tel prestataire”, “créer tel visuel”, “répondre à tel commentaire”. Ces éléments vont dans un Action Log. Le Decision Log doit rester le registre des choix structurants.

La structure d’un Decision Log : le format qui résiste au stress

Un bon Decision Log doit être :

• horodaté,
• concis,
• scannable,
• stable dans sa structure,
• traçable.

Voici les champs les plus utiles, avec une logique “crise + communication” :

1. ID de décision (D-001, D-002…)
2. Date/heure (+ fuseau)
3. Titre court de la décision (une ligne)
4. Décision (formulation complète) (ce qui est décidé, précisément)
5. Décideur (nom/fonction) + niveau d’autorité
6. Participants consultés (opérations, juridique, RH, etc.)
7. Contexte / déclencheur (fait(s) qui motivent la décision)
8. Objectif (sécurité, conformité, continuité, confiance…)
9. Options considérées (2–3 max)
10. Rationale (pourquoi ce choix)
11. Risques / contraintes (juridique, sécurité, délai, coût)
12. Actions associées (owner + échéance)
13. Implications communication (message, canal, timing, Q&A)
14. Statut (actif / remplacé / annulé / en attente)
15. Décision remplacée (si applicable) + raison du changement

Ce qui rend ce format puissant, c’est la section Implications communication. Trop d’organisations séparent tellement “décision” et “communication” qu’elles se retrouvent avec des décisions techniquement bonnes… mais communicablement fragiles. En crise, une décision n’est jamais neutre : elle crée des attentes, des obligations, des interprétations. Le Decision Log force l’organisation à regarder ces effets en face.

Gouvernance : qui écrit, qui valide, qui tranche ?

Un Decision Log n’existe pas “tout seul”. Il a besoin d’une gouvernance claire, sinon il devient un document disputé (“ce n’est pas exactement ce qu’on a dit”), ou un document abandonné (“on n’a pas le temps”).

Le “Decision Log Keeper” : un rôle à part entière

C’est souvent le secrétaire de crise ou un responsable “planning/intelligence”. Sa mission :

• capter les décisions en temps réel,
• reformuler de manière claire,
• faire valider la formulation par le décideur,
• publier la version à jour au bon cercle de diffusion,
• gérer le versioning (décisions remplacées),
• garantir l’horodatage et la traçabilité.

Il ne “décide” pas. Mais il rend la décision utilisable.

Le décideur : celui qui assume

Une crise se perd quand personne n’assume. Le Decision Log oblige à nommer le décideur. C’est plus qu’une formalité : c’est une discipline de leadership.

Le juridique : pas un veto permanent, un cadrage

Le juridique est essentiel, mais le risque est la paralysie. Le Decision Log aide à sortir du bras de fer : il permet de documenter les contraintes et d’acter des décisions de communication “prudentes mais humaines”.

Le chef de cellule : arbitre des arbitrages

Quand com, juridique, opérations ne sont pas d’accord, il faut un arbitre. Le Decision Log consigne le choix final et la justification : cela évite les “replays” interminables.

Le workflow : comment une décision entre dans le registre (sans ralentir)

Le piège, c’est de croire que logger une décision va “ralentir”. En réalité, ne pas logger ralentit plus encore, parce que la crise devient un théâtre de répétitions : on rediscute les mêmes sujets, on oublie ce qui a été tranché, on perd du temps à reconstruire la chronologie.

Un workflow simple, efficace :

1. Capture : la décision est prise (en réunion, call, terrain).
2. Reformulation (30–60 secondes) : le keeper reformule en une phrase claire.
3. Validation flash : “Oui, c’est bien ça.” (par le décideur)
4. Publication interne : mise à jour du registre + notification aux acteurs concernés.
5. Traduction communication (si besoin) : message pack, Q&A, calendrier.
6. Revue périodique : à chaque point de cellule (ex. toutes les 2h), on vérifie décisions à venir, décisions remplacées, décisions à communiquer.

Ce workflow doit être une habitude. Comme pour un SITREP, la régularité et la structure sont la clé.

Decision Log et SITREP : deux documents, deux fonctions, une synergie

Le SITREP répond : où en sommes-nous ?
Le Decision Log répond : qu’avons-nous décidé ?

En crise, les deux doivent dialoguer :

• Le SITREP alimente le contexte des décisions.
• Le Decision Log alimente les actions et la communication.

Une cellule mature organise souvent ses réunions ainsi :

1. SITREP (faits, impacts, risques)
2. Décisions (ce qui doit être tranché)
3. Decision Log (consigner)
4. Message pack (transformer en communication)

Sans Decision Log, on a des SITREP riches… mais une exécution floue. Sans SITREP, on a des décisions… mais sur une base factuelle fragile. Les deux forment un système.

Comment le Decision Log stabilise la communication : 6 effets immédiats

Il empêche les contradictions entre canaux

En crise, on parle à des publics multiples : presse, réseaux sociaux, clients, salariés, autorités. Le Decision Log fournit la “source” des engagements : la communication peut s’y référer pour aligner les versions.

Il accélère la validation des messages

Beaucoup de blocages viennent de cette question : “Est-ce vraiment décidé ?”
Si la décision est loggée, validée, attribuée, le communicant peut écrire sans attendre une chaîne de confirmations.

Il renforce la transparence de méthode

Si une décision est “nous publions un point de situation à 18h”, alors la communication peut annoncer ce rendez-vous. La confiance se construit dans la tenue des engagements.

Il outille le porte-parole

Le porte-parole ne doit pas improviser la stratégie. Il doit incarner des décisions déjà prises. Le Decision Log est son bouclier : il réduit le risque de promesses involontaires.

Il structure la gestion des rumeurs

Une rumeur impose souvent une “demande” : démentir, confirmer, expliquer. Le Decision Log peut consigner la décision “nous corrigeons cette fausse information”, avec message et canal. C’est une réponse organisée, pas un réflexe émotionnel.

Il protège l’organisation dans le temps long

Après la crise, les questions arrivent : “Pourquoi avez-vous fait ça ?” “Qui a décidé ?” “Quand ?”
Le Decision Log répond sans mémoire reconstruite à l’approximation.

Rendre une décision “communicable” : l’idée de “comm-readiness”

Toutes les décisions ne sont pas immédiatement communicables. Certaines doivent être gardées internes (sécurité, enquête, données personnelles). Mais même dans ces cas, le Decision Log peut forcer une réflexion : quelle part est communicable et quand ?

Une décision “comm-ready” est une décision qui a :

• un périmètre clair (quoi, qui, où),
• un calendrier (à partir de quand, jusqu’à quand),
• un owner (qui exécute),
• une justification simple (pourquoi),
• une conséquence pour le public (ce que ça change pour vous),
• un plan de mise à jour (quand on revient).

Si la décision ne coche pas ces cases, elle risque d’être mal comprise, surinterprétée, ou attaquée.

Le cas le plus délicat : les décisions de non-communication

Paradoxalement, l’une des décisions les plus importantes en crise est parfois : ne pas communiquer un élément (pour l’instant).

Exemples :

• ne pas donner un chiffre non stabilisé,
• ne pas spéculer sur une cause,
• ne pas nommer une personne,
• ne pas publier un détail technique qui augmente le risque.

Ces décisions sont souvent attaquées (“ils cachent”). C’est précisément pour cela qu’elles doivent être loggées, avec une justification claire :

• contrainte légale,
• sécurité,
• respect des personnes,
• enquête en cours,
• nécessité de vérification.

En externe, on n’énonce pas toujours la totalité des raisons, mais on peut expliquer la méthode : “Nous ne pouvons pas confirmer ce point à ce stade. Nous reviendrons dès que l’information sera vérifiée.” Le Decision Log permet d’aligner tout le monde sur cette posture, pour éviter qu’un canal “lâche” l’information pendant qu’un autre refuse.

Gérer les changements : versioning, décisions remplacées, et communication des mises à jour

Une crise est un environnement dynamique. Il est normal de changer de décision si les faits changent. Le problème, ce n’est pas le changement : c’est le changement non expliqué.

Le Decision Log doit intégrer un mécanisme de versioning :

• Statut : remplacée
• Référence : “remplace D-014”
• Raison : “nouveaux éléments factuels”, “consigne des autorités”, “découverte d’un impact élargi”
• Implications com : “mise à jour publique nécessaire”, “FAQ à corriger”, “porte-parole briefé”

En communication, une règle d’or : ne jamais corriger en douce quand un sujet est déjà public. Le Decision Log fournit la chronologie et le “pourquoi” qui permettent d’expliquer le changement sans perdre la crédibilité.

Exemple complet : Decision Log (cyberincident) → messages

Prenons un exemple fictif (mais réaliste) de crise cyber avec fuite potentielle.

Extrait de Decision Log (format simplifié)

D-001 — 09:20
Décision : Isoler immédiatement le serveur d’authentification et couper l’accès externe au portail.
Décideur : Responsable IT Sec (autorité opérationnelle) validé par Chef de cellule.
Rationale : Contenir le risque de propagation et préserver les preuves.
Actions : IT Ops (now), Forensic (lancer), Support (message interne).
Implications com : message “indisponibilité” + canal assistance + point à 12:00.

D-004 — 11:45
Décision : Déclencher l’analyse d’exfiltration et préparer notification CNIL si données personnelles confirmées.
Décideur : DPO + Juridique, validé Direction.
Rationale : Conformité RGPD + obligation de notification sous délai.
Implications com : préparer modèle de notification utilisateurs, sans affirmer fuite tant que non confirmée.

D-007 — 14:30
Décision : Informer publiquement qu’une intrusion est confirmée, périmètre en cours d’évaluation, consignes immédiates (mot de passe), et ouverture d’une hotline dédiée.
Décideur : Chef de cellule + Direction.
Rationale : Rumeur en forte hausse + éléments techniques confirmés + nécessité de protection utilisateurs.
Implications com : communiqué + page dédiée + FAQ horodatée + script support.

D-010 — 18:15
Décision : Proposer une surveillance de crédit gratuite (12 mois) aux personnes potentiellement concernées, sous réserve de confirmation du périmètre.
Décideur : Direction.
Rationale : Réduire préjudice potentiel + signal d’assistance + limiter perte de confiance.
Implications com : annoncer la mesure au moment de la notification individuelle, éviter promesse vague publique avant d’identifier les personnes.

Traduction en communication (exemple)

• À 09:30 : message service (indisponibilité + assistance + prochain point).
• À 14:30 : message de crise (intrusion confirmée + consignes + enquête + rendez-vous).
• Le lendemain : notification individualisée + mesure de protection (surveillance de crédit), conforme à D-010.

Ce qui rend cette séquence cohérente, c’est que la communication suit la logique des décisions : on ne “brode” pas, on accompagne l’action.

Les erreurs fréquentes : comment un mauvais Decision Log aggrave la crise

Erreur 1 : écrire “à la louche”

Décisions vagues (“renforcer la sécurité”, “améliorer la communication”).
Effet : personne ne sait ce qui est réellement décidé, et le public perçoit du flou.

Erreur 2 : oublier le décideur

Effet : guerres internes (“qui a validé ?”), perte de responsabilité, confusion dans les médias.

Erreur 3 : ne pas consigner le “pourquoi”

Effet : décisions contestées, incapacité à expliquer, suspicion d’arbitraire ou de cynisme.

Erreur 4 : confondre décision et action

Effet : registre illisible, incapacité à distinguer les choix structurants des tâches.

Erreur 5 : ne pas gérer les décisions remplacées

Effet : contradictions, corrections “en douce”, porte-parole pris en défaut.

Erreur 6 : ne pas inclure les implications communication

Effet : décisions techniquement bonnes, mais qui créent un chaos relationnel (clients perdus, salariés non informés, réseaux sociaux en feu).

Erreur 7 : laisser le document vivre sans contrôle d’accès

Effet : fuites, interprétations externes, exposition juridique.

Outils et supports : Excel, document, logiciel… l’important est la discipline

Le Decision Log peut être :

• un tableau (Excel, Google Sheets),
• une page dans un outil de gestion de crise,
• un registre dans un outil ITSM,
• une note structurée partagée.

Le support importe moins que les règles :

• horodatage obligatoire,
• nomenclature stable (D-001…),
• validation flash par le décideur,
• diffusion maîtrisée (accès restreint),
• versioning et statut,
• lien avec actions et communication.

En crise, la technologie ne remplace pas la méthode. Un outil sophistiqué sans discipline produit du bruit. Un tableau simple, tenu à jour, peut sauver une crise.

Le Decision Log au service du temps long : retour d’expérience, justice perçue, réputation

Après la phase aiguë, la crise se transforme : enquêtes, audits, réparations, contentieux, retours médiatiques. Le Decision Log devient alors une ressource stratégique :

• pour reconstruire une chronologie fiable,
• pour alimenter un retour d’expérience (REX),
• pour démontrer la diligence (l’organisation a agi),
• pour clarifier ce qui relève de la responsabilité et ce qui relève de l’incertitude,
• pour structurer la communication post-crise (points d’étape, preuves, engagements tenus).

Un Decision Log bien tenu est un outil de confiance interne : il montre que la crise a été pilotée, pas subie. Et il permet à l’organisation de parler de transformation avec crédibilité : “Nous avons décidé cela à telle date, et voici ce qui a été mis en œuvre.”

Template prêt à l’emploi : Decision Log orienté communication

Tu peux utiliser ce modèle tel quel :

Ce template fait une chose essentielle : il force la cellule à penser la décision comme un objet complet, avec effets internes et externes.

La crise se gagne par les décisions… et par la capacité à les rendre lisibles

Le Decision Log n’est pas un document administratif. C’est une discipline de leadership. Dans une crise, les organisations qui s’en sortent ne sont pas celles qui parlent le mieux ; ce sont celles qui décident clairement, exécutent, rendent des comptes, et expliquent les changements sans se contredire.

Le Decision Log est l’outil qui transforme une cellule de crise en système de pilotage :

• il stabilise la cohérence,
• accélère la communication sans sacrifier la vérification,
• protège contre les contradictions,
• soutient le porte-parole,
• outille la transparence de méthode,
• et laisse une trace utile pour l’après-crise.

Si je devais résumer en une phrase :
Une communication de crise solide n’est pas une performance ; c’est la mise en récit honnête de décisions traçables. Le Decision Log est ce qui rend cette mise en récit possible.