Une mise à jour peut faire disparaître des demandes sans que personne ne s’en aperçoive. Selon Andrei Chirtes, fondateur de 2Cafés, il est pourtant souvent possible de retrouver les prospects perdus pendant une panne, et parfois de leur répondre.
Dans l’exemple décrit, une mise à jour un mardi soir provoque un conflit d’extensions, et le formulaire de contact cesse d’envoyer ses notifications. Huit jours plus tard, un appel parvient à l’entreprise : « Je vous ai écrit la semaine dernière, je n’ai pas eu de réponse. » La réparation prend une heure, mais la question reste entière : combien de personnes ont écrit pendant ces huit jours, et où sont passés leurs messages ?
La plupart des équipes surveillent la disponibilité de leur site, mais rares sont celles qui mesurent ce qu’une interruption a coûté en demandes entrantes. La démarche proposée tient en cinq étapes : délimiter la fenêtre d’incident, inventorier les traces disponibles, estimer ce qui manque, reconstituer ce qui peut l’être, puis recontacter. Une sixième étape, présentée comme la plus rentable, consiste à faire en sorte que la prochaine panne coûte beaucoup moins cher.
Panne bruyante, panne silencieuse
Une panne bruyante se signale d’elle-même : le site est inaccessible, ou le formulaire affiche une erreur au moment de l’envoi. Le visiteur sait que sa demande n’est pas partie. Ces demandes n’ont jamais existé dans les systèmes de l’entreprise, il est donc impossible de les retrouver, et on peut tout au plus en estimer le volume.
La panne silencieuse coûte davantage. Le formulaire affiche « merci, votre message a bien été envoyé », puis le message se perd : notification jamais délivrée, soumission non enregistrée, erreur JavaScript introduite par une mise à jour, ou filtre anti-spam devenu trop strict. Le prospect croit avoir écrit, l’entreprise croit n’avoir rien reçu, et personne ne relance personne. Ces demandes ont laissé des traces, et c’est sur elles que porte la reconstitution.
Retrouver les demandes perdues
Il faut d’abord fixer les deux bornes de l’incident : le dernier moment où la chaîne fonctionnait de façon prouvée, et le premier où elle a de nouveau fonctionné. Le journal des mises à jour, les alertes de l’outil de supervision et les dates des dernières demandes reçues aident à les situer. Lorsque ces repères se contredisent, mieux vaut retenir les bornes les plus larges.
Vient ensuite l’inventaire des traces. L’extension de formulaire enregistre souvent chaque soumission en base de données, indépendamment de l’email de notification. Les journaux du serveur, ceux du service d’envoi d’email, les sauvegardes datées de la fenêtre, l’outil de mesure d’audience, les plateformes publicitaires, le standard téléphonique ou les réseaux sociaux peuvent aussi conserver des indices. Autrement dit, « un email perdu ne signifie pas une demande perdue ».
Prenons un cas concret : un site reçoit habituellement douze demandes par semaine. Pendant la semaine de l’incident, l’outil de mesure compte quarante démarrages de formulaire, la base contient neuf entrées, et l’équipe n’a vu passer que trois notifications. Six demandes dorment donc dans la base sans que personne ait été prévenu. Il faut toutefois tenir compte du courrier indésirable, qui peut fausser la comparaison, et raisonner sur les demandes qualifiées plutôt que sur le compteur brut.
Lorsque les demandes existent avec nom, email et message, il suffit de répondre à chacune. Si seules des traces techniques subsistent, la CNIL encadre strictement la prospection par courrier électronique, et l’article rappelle qu’il ne faut pas extraire d’adresses de journaux techniques pour lancer un emailing. Une note visible sur le site peut en revanche inviter les personnes concernées à réécrire.
Éviter que la prochaine panne coûte autant
Pour la suite, il est conseillé de conserver chaque demande en deux exemplaires, une entrée en base et une notification par email, l’email ne devant jamais être le seul support. Il faut aussi tester le parcours complet après chaque mise à jour, et déclencher une alerte quand les soumissions tombent sous la normale hebdomadaire. La supervision de disponibilité ne voit pas les pannes silencieuses, alors qu’une alerte de volume peut les détecter en quelques heures plutôt qu’en quelques semaines.
Pour les réponses, mieux vaut commencer par les demandes à forte intention, un devis ou un rendez-vous par exemple. Une réponse tardive reste utile si elle précise les faits, comme dans l’exemple « votre message du 14 nous est bien parvenu, un incident technique l’a retenu ». Mesurer ensuite le taux de retour permet de savoir ce que l’incident a réellement coûté.
Product offers are temporarily unavailable.
