Post-mortem de campagne marketing : une méthode sans blâme fondée sur la chronologie

Qu'est-ce qu'un post-mortem de campagne marketing ?

Un post-mortem de campagne est un document court rédigé après un incident : les conversions ont chuté, les dépenses ont dérapé, les leads se sont arrêtés ou le suivi a cessé de fonctionner. Il explique ce qui s'est passé, ce que cela a coûté, pourquoi c'est arrivé et ce qui change pour que cela ne se reproduise pas.

Le format vient de l'ingénierie de la fiabilité (SRE). Le livre SRE de Google décrit le postmortem comme le compte rendu écrit d'un incident, de son impact, des actions menées pour l'atténuer, des causes racines et des actions de suivi qui évitent qu'il se reproduise. Les équipes marketing peuvent reprendre presque la même structure, car comptes publicitaires, balises et sites tombent en panne de la même façon : quelqu'un publie une modification, quelque chose casse plus loin et personne ne fait le lien pendant des jours.

Un post-mortem n'est pas un bilan de campagne. Le bilan passe en revue toute la campagne une fois terminée : ce qui a marché, ce qu'il faut refaire, ce qu'il faut abandonner. Le post-mortem porte sur un incident et sa cause. Les deux sont utiles ; cet article traite de l'analyse d'incident. Pour la méthode de diagnostic plus large, voir l'analyse des causes racines en marketing.

Quand faut-il mener un post-mortem de campagne ?

Menez-en un quand un incident dépasse un seuil convenu à l'avance, pas quand quelqu'un est contrarié. Le livre SRE de Google recommande de définir les déclencheurs avant les incidents et cite par exemple une dégradation visible au-delà d'un seuil, une perte de données, un retour arrière, un délai de résolution trop long ou une défaillance de la surveillance, quand l'incident a été repéré à la main.

En marketing, des déclencheurs raisonnables sont :

• Performance : un indicateur clé (conversions, leads, ROAS, CPA) sort de la plage convenue pendant deux jours ou plus sans raison prévue.
• Argent : les dépenses dépassent le budget convenu ou partent vers un trafic que vous ne vouliez pas acheter.
• Données : des conversions perdues, comptées en double ou mal attribuées sur une période.
• Retour arrière : une modification a dû être annulée, par exemple une landing page, une stratégie d'enchères ou une version du conteneur de balises.
• Détection : le client ou votre responsable a vu le problème avant l'équipe.

Atlassian, par exemple, mène un post-mortem pour ses incidents de gravité 1 et 2 et le rend facultatif pour les autres. Une règle comparable fonctionne en agence comme en interne : obligatoire quand le client a remarqué l'incident ou qu'il a coûté de l'argent, facultatif sinon. Toute partie prenante doit pouvoir en demander un.

Que doit contenir un modèle de post-mortem marketing ?

Gardez un modèle assez court pour qu'il soit rempli. Le modèle d'incident d'Atlassian couvre résumé, contexte, défaillance, impact, détection, réponse, rétablissement, chronologie, cinq pourquoi, cause racine, récurrence, enseignements et actions correctives. Pour un incident de campagne, ces champs suffisent :

La frise des modifications est le champ que la plupart des équipes sautent, et c'est lui qui détermine si l'analyse vaut quelque chose. Sans elle, la cause racine n'est qu'une hypothèse déguisée en conclusion. Si vous ne consignez pas encore vos modifications, commencez avec un modèle de journal des modifications marketing et remplissez les deux semaines précédant l'incident.

Comment prouver quelle modification a causé l'incident ?

Alignez toutes les modifications des jours précédant le mouvement de l'indicateur, écartez d'abord le suivi des conversions, puis testez une hypothèse à la fois. Le guide d'Atlassian sur le post-mortem sans blâme dit la même chose : mettez-vous d'accord sur une chronologie commune avant d'analyser les causes.

Rassemblez les modifications de toutes les sources, pas seulement du compte publicitaire :

• Les modifications de l'équipe dans Google Ads et Meta Ads : budgets, objectifs d'enchères, audiences, créations.
• Les automatismes des plateformes : recommandations appliquées automatiquement, règles automatiques, scripts.
• Les mises en production du site, les changements de landing pages et du tunnel de paiement.
• Le suivi : versions de Google Tag Manager, bannière de consentement, actions de conversion.
• Les changements dans le CRM et le produit, ainsi que les événements externes comme les jours fériés ou les pannes.

Dans Google Ads, ouvrez « Historique des modifications » dans le menu Campagnes. Il couvre les 2 dernières années et indique l'utilisateur à l'origine de chaque modification ; les modifications automatiques apparaissent sous des noms comme « Google Ads system ». Pour les balises, l'historique des versions de GTM montre qui a publié chaque version. Le guide de l'historique des modifications Google Ads explique les filtres.

Avec toutes les modifications sur une seule frise chronologique, l'incident cesse en général d'être un mystère : vous voyez qu'une balise a été publiée la veille au soir de la chute et que l'objectif d'enchères a changé la veille. Dans Changeline, les modifications Google Ads peuvent être importées automatiquement avec les valeurs avant → après et leur source, et l'équipe consigne le reste sur la même frise du projet.

Exemple : le lundi, le client demande : « Pourquoi les achats Google Ads ont-ils baissé de 40 % ce week-end ? » L'équipe aligne les modifications des jours précédents. Jeudi : ROAS cible passé de 400 % à 500 %. Vendredi : nouveau tunnel de paiement en ligne et une version GTM publiée. Samedi : les achats chutent. Un test montre que la balise d'achat ne se déclenche plus sur la nouvelle page de confirmation, donc le suivi explique la chute. Le changement de ROAS reste dans l'analyse comme facteur à surveiller quand les données reviendront. Noms et chiffres sont fictifs.

Pour prouver la cause plutôt que la supposer, vérifiez trois points : le moment concorde (l'indicateur a bougé après la modification, pas avant), le périmètre concorde (seuls les campagnes, pages ou appareils concernés ont bougé) et, si possible, corriger ou annuler la modification ramène l'indicateur à son niveau.

Comment animer une réunion de post-mortem sans blâme ?

Centrez la réunion sur le système, pas sur la personne qui a fait la modification. Le livre SRE de Google le résume ainsi : on ne peut pas « réparer » les gens, mais on peut réparer les systèmes et les processus. La personne qui a relevé l'objectif d'enchères ou publié la balise a agi avec les informations dont elle disposait ; la vraie question est pourquoi le processus a laissé passer la modification sans contrôle.

Un ordre du jour de 30 minutes qui convient à la plupart des incidents :

1. S'accorder sur la chronologie
2. Confirmer impact et détection
3. Demander pourquoi cinq fois
4. Fixer actions et responsables

Commencez par la chronologie, car elle supprime l'essentiel des désaccords : quand tout le monde voit les mêmes modifications datées, la discussion passe des opinions aux faits. Utilisez ensuite les cinq pourquoi : partez de l'impact et demandez pourquoi jusqu'à trouver ce qui, une fois changé, empêche ce type d'incident. Atlassian définit la cause racine comme ce qui doit changer pour que cette catégorie d'incident ne se reproduise pas. « L'analyste a oublié de tester la balise » n'est pas une cause racine ; « les modifications de balises partent en ligne sans test sur la page de conversion » en est une.

Invitez les personnes qui ont fait les modifications et le responsable du compte. Si le client a remarqué l'incident, envoyez-lui ensuite un résumé écrit plutôt que de l'associer à la discussion interne. Le guide pour expliquer une baisse de conversions à un client vous aide à rédiger ce message.

Comment transformer le post-mortem en actions réellement menées ?

Donnez à chaque action un responsable, une échéance et un endroit où elle est suivie, et passez en revue les actions ouvertes à la réunion d'équipe suivante. Atlassian enregistre chaque action dans le backlog de l'équipe concernée, distingue les actions prioritaires (qui corrigent la cause racine) des actions d'amélioration et fixe un délai de 4 ou 8 semaines pour les prioritaires, selon le service.

De bonnes actions marketing sont précises et limitées, par exemple :

Rangez les post-mortems là où l'équipe les trouvera, à côté du journal des modifications du client. Le livre SRE de Google prévient qu'un postmortem non relu revient à n'avoir jamais existé, et il en va de même pour un document introuvable. Sur un an, la collection montre quels types de modifications causent le plus d'incidents, la meilleure base pour votre processus de modification. Un journal des modifications marketing est l'endroit naturel pour les deux. Avec les forfaits payants de Changeline, le rapport des modifications transforme n'importe quelle période en PDF des modifications consignées ou importées, à joindre à l'analyse.